Internet-facing zero-day vulnerabilities were the most commonly used types of bugs in 2021 attacks, according to the international Joint Cybersecurity Advisory (JCSA).

Log4Shell, despite being disclosed only at the end of the year, topped 2021's list of most-exploited vulnerabilities, according to the Cybersecurity and Infrastructure Agency (CISA). The agency compiled the findings along with the cybersecurity agencies of Australia, Canada, New Zealand, and the United Kingdom. 

"Globally in 2021, malicious cyberactors targeted Internet-facing systems, such as email servers and virtual private network (VPN) servers, with exploits of newly disclosed vulnerabilities," CISA reported in its announcement of the findings.  "For most of the top exploited vulnerabilities, researchers or other actors released proof-of-concept (PoC) code within two weeks of the vulnerability’s disclosure, likely facilitating exploitation by a broader range of malicious actors." 

The top most commonly exploited vulnerabilities, according to CISA, include Log4Shell, which affects Apache’s Log4j library, and the ProxyLogon and ProxyShell vulnerabilities, which are bugs in Microsoft Exchange email servers.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CISA: Log4Shell Was the Most-Exploited Vulnerability in 2021

The four-year-old firm, started by two industry veterans, focuses on gaining visibility into Internet-facing services as more companies seek insight into what attackers see.

Vulnerability and cybersecurity assessment firm Tenable announced on Tuesday plans to acquire 4-year-old startup Bit Discovery, becoming the latest company to acquire an attack-surface management business in the past year.

With the $44.5 million deal, Tenable aims to strengthen its capabilities for gathering external information on networks and deliver to customers more visibility into their digital footprints. Visibility is key, as misconfigured and vulnerable assets are a significant security weakness for most companies. Tenable intends to integrate the technology into all of its products, including its Nessus vulnerability scanning platform, and use the technology to augment its ability to analyze internal networks.

Acquiring Bit Discovery's technology gives Tenable and its customers an attacker's eye view of company networks, says Glen Pendley, chief technology officer at Tenable.

"Visibility is  literally the first step in every single cybersecurity framework," he says. "When you look at our acquisitions and strategy ... over the last few years, we are getting a bigger breadth of coverage over the attack surface. This is the biggest part of the attack surface that Tenable has yet to get visibility of."

The acquisition is the latest industry move to underscore the importance of the technologies and services that deliver attack surface management (ASM) capabilities. This month, Google announced it would buy Mandiant, which had previously acquired Intrigue, an ASM startup, in August 2021. In February, cybersecurity automation firm Darktrace announced it would acquire ASM firm Cybersprint for nearly $54 million. And in November, cyber-risk firm Team Cymru stated it would purchase Amplicy, a 2-year-old startup company focused on attack surface discovery for an undisclosed amount.

**ASM on the Rise  
**The interest is unsurprising. Business intelligence firm Gartner named ASM as the top trend in security and risk management for 2022, breaking down the technologies into three areas: cyber asset ASM, external ASM, and digital risk protection services (DRPS). Bit Discovery falls squarely in the external attack surface management (EASM) segment.

Companies should know all of the assets visible to attackers from the Internet, Gartner stated in the March announcement of its top 7 security and risk-management trends.

"Risks associated with the use of cyber-physical systems and IoT, open-source code, cloud applications, complex digital supply chains, social media and more have brought organizations’ exposed surfaces outside of a set of controllable assets," the firm stated. "Organizations must look beyond traditional approaches to security monitoring, detection and response to manage a wider set of security exposures."

Part of the growing importance of ASM is because companies are getting better about doing the basics. Businesses are paying more attention to common points of entry, such as remote desktop protocol (RDP) servers and virtual private network (VPN) appliances, but need to look beyond securing the front door, says Jeremiah Grossman, CEO of Bit Discovery.

"We got away with not knowing all of our assets for a long time in infosec because everything was just that insecure," he says. "But now the main front doors are getting sufficiently hardened, so the adversaries are looking for secondary and tertiary ways in."

Team Cymru, a cybersecurity risk firm, estimates that 60% of breaches start with the compromise of an exposed, unmanaged asset with an unpatched vulnerability. In addition, the company's research found that three-quarters of midsize to large companies have to rely on spreadsheets to track assets. Those companies were not ready for the shift to cloud infrastructure and employees working from home, says Lewis Henderson, a senior product manager at Team Cymru.

"The last two years have thrust organizations to expand far beyond their already eroded borders — \[basically\] digital transformation on steroids," he says. "When those organizations went to lean on their security vendors to understand what external assets, risks, vulnerabilities and threats they had, they were left totally exposed and on their own to figure it out."

EASM firms evolved to fill the gaps, he says.

**Four Years, $45 Million  
**Bit Discovery launched in March 2018 with $2.7 million in funding, upon the merger with OutsideIntel, a startup founded by Robert Hansen, a cybersecurity veteran who had discovered vulnerabilities under the handle "RSnake" and had previously worked with Grossman at WhiteHat Security. Last June, Bit Discovery gained another $4 million in investment during a Series B round of funding.

Grossman estimates that about half of breaches are enabled by a vulnerable asset that the company previously did not know about. He pointed to the massive data breach as Equifax as an example of the hazards.

"Nothing is more embarrassing than getting exploited by an asset that you didn't know you owned," he says. "That was the case with Equifax. Yes, they didn't patch the \[Apache\] Struts vuln, but they would have if they knew the asset existed."

While the deal must still weather the closing process, Tenable expects to complete the acquisition this quarter and integrate Bit Discovery’s external ASM technology across its other products and services. In the end, the company wants to provide businesses with ways to get meaningful visibility into the state of their security, both on the internal network and from an external view, says Tenable's Pendley.

"We want to reduce noise," he says. "That has been a problem in this space forever, and it's something we can improve."

Tenable's Bit Discovery Buy Underscores Demand for Deeper Visibility of IT Assets

The Stormous ransomware group is offering purportedly stolen Coca-Cola data for sale on its leak site, but the soda giant hasn't confirmed that the heist happened.

The Russian-speaking ransomware group Stormous is claiming to have stolen 161GB of data from Coca-Cola -- and it's offering to sell the supposed cache for 1.65 Bitcoin (about $64,000).

But when asked for confirmation of the breach by Dark Reading, Coca Cola’s global vice president of external and financial communications, Scott Leith, provided the following statement: “We are aware of this matter and are investigating to determine the validity of the claim. We are coordinating with law enforcement."

According to Chris Morgan, senior cyberthreat intelligence analyst at Digital Shadows, "There are screenshots reportedly highlighting documents taken from Coca Cola's network. However, these cannot be independently verified. Some researchers have suggested that many of their attacks are either a scam or the group is exaggerating their claims. This is not uncommon for cybercriminal groups, who often embellish the details of their activity in order to coerce victims into paying a ransom."

He also told Dark Reading, "It is also realistically possible that Stormous may be involved in 'scavenger operations,' which indicates a cybercriminal actor attempting to extort companies whose data had been breached by another threat actor in a previous attack."

John Bambenek, principal threat hunter at Netenrich, notes that the comparatively small ransom demand is also perplexing.

“Stormous has had a history of making headlines of stealing large amounts of data from its ransomware victims,” he said via email. “However, with the very low amount they are requesting for the dump from Coca-Cola, I’m somewhat suspect that they have truly valuable information and certainly they aren’t selling it exclusively to anyone. From Stormous’ description, it doesn’t seem like the most valuable trade secrets are in the dump file (or that Stormous can’t tell if they are there).”

Bambeneck added, “What’s important for any organization in this kind of position is to rapidly assess what information was taken and what its value is to inform decision makers in situations like this where days of analysis just aren’t in the cards.”

For its part, Stormous has previously been linked with Russia, according to researchers, and has breached data from Ukrainian companies in the past.

“With the ongoing hostilities between Russia and Ukraine, and with America supporting Ukraine in their defense, it is not surprising that pro-Russian groups have decided to target American organizations for attack,” said Erich Kron, security awareness advocate with KnowBe4, in a statement about the reports.

Coca-Cola Investigates Data-Theft Claims After Ransomware Attack

What 5,800+ pentests show us: Companies have been struggling with the same known and preventable security bugs year over year. Bandwidth stands at the heart of the problem.

Cybercrime can cause major disruption when it comes to the sustainability and long-term success of companies. Teams want to have robust security but often struggle to meet that objective. It's crucial for security professionals to leverage insights into emerging trends in cybersecurity to pinpoint which vulnerabilities put organizations at the greatest risk, and Cobalt's "State of Pentesting" reports explore how to achieve efficiency to strengthen security.

The "State of Pentesting 2022" surveyed 602 cybersecurity and software development professionals and analyzed data from 2,380 pentests conducted over the course of 2021 to pull key insights that are relevant to security and development teams when it comes to fixing vulnerabilities.

As a result of the data collected, the top five most common vulnerability categories outlined in this year's "State of Pentesting" report include:

1.  Server Security Misconfigurations
2.  Cross-Site Scripting (XSS)
3.  Broken Access Control
4.  Sensitive Data Exposure
5.  Authentication and Sessions

Surprisingly — yet predictably — these vulnerability categories have stayed at the top of the list for at least the last five years in a row. They're also recognizable to those who are familiar with OWASP Top 10 list for Web Application Security Risks.

The majority of these findings are connected to missing configurations, outdated software, and a lack of access management controls — all common and easily preventable security flaws. So, what's holding companies back from preventing well-known security flaws? Why does this come as a surprise?

Because these flaws are common and appear to be less of a major threat, they are often overlooked as teams deal with talent shortages and increased workload. Standing alone, these issues might not cause a lot of concern, but they can build up to create more critical situations that are difficult to tackle and remediate.

Security and development teams need access to more resources and talent to prevent and fix common vulnerabilities in the future. Talent shortages have impacted security programs as teams are struggling to maintain security standards and vulnerabilities are more likely to go undetected and unremedied.

Findings from the "State of Pentesting 2022" point to key strategies organizations can implement for vulnerability management and retention.

1\. **Focus on learning:** Provide the right security training and resources with teams such as the OWASP Top 10 list and the "State of Pentesting" reports_._

2\. **Review your security configurations:** Consistently monitoring access/user matrixes, SSL certificates, software versions, and security headers can help with the top vulnerabilities we see each year. 

3\. **Clearly communicate risk:** It's important to show leadership and team members how insufficient resources and open vulnerabilities of all types can turn into much bigger security problems for the broader organization.

4\. **Outsource to agile vendors:** Find vendors who help you to achieve your security goals, integrate well with your systems, and create the right efficiencies to bring to your workflows.

Security and development teams have clearly been struggling with the same vulnerabilities for five years in a row, and although this can come as a surprise, there are steps teams can take to break the trend.

In addition to these tips for vulnerability management and retention, security assessments like pentesting can be a useful additional resource for development teams to patch vulnerabilities and remediate risk. Pentesting can help defend organizations against vulnerabilities that disrupt the organizational flow, reputation, financial circumstances, and more.  

**About the Author**

    

  
Jay Paz is Cobalt's Senior Director of Delivery. He has more than 12 years of experience in information security and 19+ years of information technology experience, including system analysis, design, and implementation for enterprise-level solutions. At Cobalt, he lays the groundwork for innovation and scale as he oversees operations and day to-day management for Cobalt's pentester community.

5-Year Vulnerability Trends Are Both Surprising and Sadly Predictable

Here's how to reduce security risk and gain the benefits of open source software.

Security has long been a point of concern in the open source community. If not managed carefully, the same openness that allows innovative code contributions from global users can also present vulnerable attack surfaces for malicious actors. In fact, when asked about roadblocks preventing their organizations' use of open source, respondents to Anaconda’s 2021 State of Data Science report cited "Fear of CVEs, potential exposures, or risks" (41%) and "Open source software is deemed insecure, so it's not allowed," (26%) among other concerns.

Yet open source drives innovation, and there are ways to dramatically decrease the potential risks that arise from the use of open source software. This is why many organizations take a “best of both worlds” approach, adopting open source while prioritizing security measures.

If you think of open source security as a spectrum, with “no security controls” on one end and “locked-down controls” on the other, technically advanced organizations tend to fall somewhere in the middle. Here are some lessons you can learn from their approaches.

**1\. Everyone Should Be Involved  
**Setting up open source security parameters should not be left solely up to the IT and data science teams. To be successful, you need buy-in from the whole organization, including executive leadership. Together, leaders must consider the tradeoffs of security risks and innovation rewards, and create a framework to define an acceptable level of risk for using open source software.

In creating security frameworks across organizations, preventative and containment-based perspectives are necessary. Since open source projects are open to globally dispersed contributors, the code doesn’t have the same level of built-in security as private vendor applications. For that reason, you need to have a proactive approach to security, setting clear risk parameters and pre-emptively implementing safeguards in the event of a breach. A key aspect of the latter component is the idea of a software bill of materials (SBOM), which lists the origin of all the code running in each application or package. With an SBOM in place, when an incident like last year’s Log4j incident occurs, you can quickly identify which areas of your infrastructure are impacted.

**2\. Take a Nuanced Approach  
**If the security framework is a hard-and-fast set of nonspecific rules, you’ll likely run into two problems. First, you risk security becoming an exercise of box-checking, where practitioners aren’t necessarily thinking critically about their actions and are just crossing items off a security checklist. Second, you’ll likely miss out on the best innovation open source has to offer.

Of course, there are a few areas where you want to be very firm in your security protocols, such as implementing access controls and firewalls and using only repositories that have been built on or are being mirrored from a secure environment.

However, there are other areas where you can introduce some nuance, such as parameters around acceptable CVE scores. For example, there are tens of thousands of open source packages in the Python realm alone. If you set automated filters that allow your data scientists to use only packages with a CVE score of 6 or lower, you could miss out on a package with key functionality that has a score of 7 but whose vulnerability would not be exposed in your particular use case.

Another approach is to establish different risk tolerance levels in development and production environments. This gives developers and data scientists more freedom to explore packages in the dev environment, which can be separated behind a firewall. Then, when it comes time to move workflows into production, you can enforce stricter security protocols. If a given package doesn’t meet those requirements, it’s an opportunity to explore whether to introduce more nuance into the rules.

**3\. Give Back to the Open Source Community  
**It might be tempting to think that forking an open source project and bringing the fork inhouse would help mitigate security issues by giving you tighter control over the code distribution. However, that path has several downsides, as noted in a recent memorandum from the Department of Defense. These include increased support risk (due to the loss of several pairs of eyes checking over code), decreased access to community-driven innovations, and increased code maintenance costs.

Instead of forking a project, many industry leaders work closely with the open source community to help surface, mitigate, and patch vulnerabilities when needed. Most projects rely on volunteer effort, and any resource contributions (including developer time, monetary support, and in-kind donations like server space) will benefit everyone who uses a project.

**Conclusion**Security is a journey, and everyone progresses at a different pace. It’s important to implement systems and strategies that work for your industry, resource level, and expertise. At the same time, it’s worthwhile to continually refine your security posture and adopt more sophisticated practices. The cyber threat landscape is ever evolving, so it’s incumbent on us as technologists to evolve and adapt so that we can stay protected, secure, and one step ahead.

How Industry Leaders Should Approach Open Source Security

Four months after the Log4Shell vulnerability was disclosed, most affected open source components remain unpatched, and companies continue to use vulnerable versions of the logging tool.

Attackers who want to exploit the critical remote code execution vulnerability disclosed in the Apache Log4j logging tool over four months ago still have a vast array of targets to go after.

In a recent scan using the Shodan search engine, Rezilion found more than 90,000 Internet-exposed servers containing a vulnerable version of the software. The security vendor believes the number represents only a small fraction of available attacker targets because it only considers publicly facing servers running open source software. If internal network servers and servers running proprietary applications are factored in, the total number of vulnerable targets is likely much higher, Rezilion said.

A Rezilion report this week that summarized the results of its study pointed to other data points that appear to bolster the company's conclusion.

Among them is data from a Google open source scanning service called Open Source Insights, which showed that just 7,140 Java packages out of a total of 17,840 affected packages have been patched for Log4Shell since the flaw was disclosed. Another data point from Sonatype found that as of Apr. 20, 2022, some 36% of Log4j versions being actively downloaded from the Maven Central Java application repository were still vulnerable to Log4Shell — a number that has remained largely unchanged since February.

"Similar to other historic high-profile vulnerabilities, even though four months have passed, there is still a huge attack surface that is vulnerable to Log4Shell," says Yotam Perkal, director of vulnerability research at Rezilion. "The 90,000 publicly accessible vulnerable servers are probably only the tip of the iceberg in terms of actual vulnerable attack surface."

The Apache Foundation disclosed the Log4Shell vulnerability (CVE-2021-44228) along with an updated and fixed version of the software on Dec. 9, 2021. The flaw is present in virtually every Java application environment, is considered trivially easy to exploit, and gives attackers a way to gain complete control over vulnerable systems. Many security experts consider the flaw to be one of the most dangerous to be disclosed in recent memory, and they have urged organizations to install the updated and fixed version of the software as soon as possible.

Despite the high concerns, there have been very few publicly reported instances of the flaw being exploited in a major breach. However, there are considerable fears that in many cases attackers may have already quietly exploited the flaw to gain access to enterprise networks and are waiting for an opportune moment to strike.

Security experts have pointed to the ubiquity of the flaw and the difficulty involved in detecting it — Java files containing the flaw can sometimes be buried deep inside applications — as potential reasons for the slow remediation pace so far.

Rezilion said one issue is that many people are unwittingly using software that relies on vulnerable versions of Log4j either because they don't have visibility into their software components or are using vulnerable third-party software. The Log4j flaw has also proven to be challenging to detect in production environments.

**Tip of the Iceberg?**  
Perkal says that the 90,000 vulnerable servers that Rezilion found via a Shodan search contained open source components with obsolete — and therefore potentially vulnerable — versions of Log4j; components with up-to-date Log4j versions that contained evidence of use of previous, potential vulnerable versions; and public-facing Minecraft servers with vulnerable Log4j versions.

"There are probably a lot of servers running these applications on internal networks and hence not visible publicly through Shodan," Perkal says. "We must assume that there are also proprietary applications as well as commercial products still running vulnerable versions of Log4j."

Significantly, all the exposed open source components contained a significant number of additional vulnerabilities that were unrelated to Log4j. On average, half of the vulnerabilities were disclosed prior to 2020 but were still present in the "latest" version of the open source components, he says. Rezilion's analysis showed that in many cases when open source components were patched, it took more than 100 days for the patched version to become available via platforms like Docker Hub.

Nicolai Thorndahl, head of professional services at Logpoint, says flaw detection continues to be a challenge for many organizations because while Log4j is used for logging in many applications, the providers of software don't always disclose its presence in software notes. "So, many companies don't actually know if it is being used in their system or not," Thorndahl says.

Often, many applications are using old versions of Log4j that are no longer being supported and are vulnerable. "Very few, if any, companies have a \[configuration management database\] so detailed that it would show where they are using Log4j," he says.

Thorndahl expects there will be more attacks exploiting the flaw, even though there have been very few so far.

"Most likely what we will see down the line, maybe four months, maybe a year, as we have seen before, is that incidents will be disclosed \[where\] companies detected they have been breached and the Log4j vulnerability was used and they probably had access for a long period of time," he says.

Log4j Attack Surface Remains Massive

If security leaders focus on visibility and metrics, they can demonstrate their programs' value to company leadership and boards.

**Question: How do I report my security program's return on investment (ROI)?**

**John Ayers, Vice President of Product, Advanced Detection and Response, Optiv:** Measuring ROI for any security program really starts by stating early and clearly what the desired outcome is that a company is looking to achieve out of said program. This obviously varies on a program-by-program and company-by-company basis. What a $40 billion financial services organization and a $500 million manufacturing organization view as ROI when it comes to security is certain to vary.

When it comes down to it, however, both of those organizations are looking to reduce and manage their risk. The fundamental goal, despite wildly different budgets and maturity levels, is the same.

How can we do that?

*   By transforming where data lives.
*   By implementing asset (devices or data sources) management.
*   By implementing new frameworks, such as zero trust or managed extended detection and response (MXDR).

But those are costs, right? How does that improve security value? Because we can measure the data, and we can report on it and the associated metrics. If you can feel more comfortable with your security program, great, but if you can't measure it or see results, then how do you know? You have to be able to validate your programs via monitoring and data detection.

Examples of these metrics can come in many forms. From a reactive perspective, we're talking about things such as the total number of security incidents over time by type, mean time to detect (MTTD), mean time to resolve (MTTR), intrusion attempts over time, and number of unidentified devices on network.

From there, we lean into what I call "proactive metrics." These are metrics established to gauge how well training and vulnerability management are performing. Examples include phishing test success rate, security awareness completion rate, average number of days to patch, percentage of fully patched devices on network, and number of security incidents reported by staff.

Too often, we get caught in the "shiny object" issue, where we expect everything new to deliver in the exact way we want it — and this goes for technology products, too. Rarely, if ever, can a technology product alone deliver a holistic ROI.

If security leaders are focused on visibility and reporting on what their teams can discover, they can demonstrate to company leadership and boards that their organizations can quickly detect and respond to potential threats with people, process, and technology and rapidly re-establish business normalcy.

How Do I Report My Security Program's ROI?

Acquisition will add Internet-facing attack surface mapping and monitoring to Tenable's internal asset management products.

Tenable today announced it will add external attack surface management to its various cybersecurity offerings with a $44.5 million acquisition of Bit Discovery.

The company said it will fold Bit Discovery's Internet-facing system security capabilities into its existing portfolio of internal asset management products to offer a more comprehensive attack surface view.

“Whatever is visible on the internet is very likely to be the first target and the hardest thing for organizations to continuously see and assess," Tenable's chief technology officer Glen Pendley said in a statement announcing the deal. "We believe attack surface management is vital to modern cybersecurity and an integral part of our vulnerability and Cyber Exposure solutions."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Tenable Acquires External Attack Surface Management Vendor for $44.5M

The move to IaC has its challenges but done right can fundamentally improve an organization's overall security posture.

Infrastructure as code (IaC) has become a core part of many organizations' IT practices, with adoption of technologies like HashiCorp's Terraform and AWS CloudFormation increasing rapidly. The move to IaC sees companies moving away from either manually configuring servers or using imperative scripting languages to automate those changes and toward a model in which declarative code is used to outline a resource's preferred final state.

As with any change in approach to IT, there are security considerations to understand. The move to IaC presents some risks along with opportunities to improve the way companies secure their environments. Given IaC's key role in configuring the security parameters of an organization's systems and the speed at which a flawed template could be rolled out across a large number of systems, ensuring that good security practices are adhered to is vital to making the best use of this technology.

**IaC Security Risks and Opportunities**  
With the move to IaC, there are new security risks to consider. The first is secrets management. When creating and managing resources, credentials will often be needed to authenticate to remote systems; when IaC code is written to automate these tasks, there is a risk that credentials or API keys may be hard-coded into the code. Care should be taken to ensure that proper secrets management processes are followed to avoid this. Secrets should be held in a secure location, such as a cloud key management service (KMS), and retrieved on demand by scripts as they run.

A second risk is that misconfigurations may creep into the IaC templates — for example, if code is copy/pasted in from an external source — and then propagate throughout an environment quickly as the IaC is used. Avoiding this risk requires both automated and manual review, as with any other source code.

The opportunity inherent in moving to IaC-driving environments is that once all of your infrastructure is defined in code, it's possible to apply common automated linters and review tools to it to ensure that good practices are followed. Tooling can draw from common libraries of good practice and be supplemented with custom rules that apply organization-specific practices.

Additionally, with an IaC-based approach, all configurations should be stored in version- controlled source code repositories. This provides improved tracking of changes so that companies can track modifications over time and also ensure appropriate access control and that auditing is in place.

Lastly, IaC-based deployment means that test environments should be able to effectively mirror production, meaning that security testing can be safely conducted with higher confidence that any results will be meaningful in production.

**IaC Technology Stacks**  
There are a variety of options for IaC. Typically, large organizations will use many of these at the same time, as different tools have different strengths and weaknesses.

Terraform from HashiCorp is one of the most widely used IaC toolsets. It has the advantage of being open source and not tied to any one cloud platform or infrastructure provider, meaning that it works across a range of environments.

Unsurprisingly, the major cloud service providers also have IaC toolsets that focus on their clouds. Amazon's CloudFormation, Microsoft's ARM and Bicep, and Google's Cloud Deployment Manager all provide a means for users of that company's cloud to take advantage of the IaC paradigm.

Another popular option for cloud-native IaC is Pulumi, which allows developers to use programming languages they already know (e.g., JavaScript or Golang) to write their IaC templates.

**IaC Review Tools**  
There are a number of open source tools that can help with the process of security reviews of IaC code. These tools take a similar approach in providing a rule set of common security misconfigurations for a given set of IaC languages. In addition to the main IaC format, some of these tools will review other formats, like Kubernetes manifests and Dockerfiles. Some of the commonly used tools in this arena include the following:

*   Trivy is a vulnerability and misconfiguration scanner that includes rules from the tfsec and cfsec projects covering Terraform and CloudFormation, as well as a set of rules for Kubernetes and Docker. It can be easily integrated into a CI/CD pipeline and run by developers as part of the coding environment.
*   Checkov is a tool written in Python that covers a wide range of IAC languages, including Terraform, CloudFormation, Azure Bicep and ARM, and Kubernetes manifests. It also helps with the challenge of ensuring that IaC files don't hard-code secrets by scanning for instances where this can occur.
*   Terrascan is another popular option for IaC scanning. Despite the name, it supports a range of IaC formats in the same way as Trivy and Checkov. Similarly to Trivy, Terrascan is written in Golang and can be integrated into CI/CD pipelines and run as a standalone program.

**Smoothing the Security Path**  
The move to IaC is well underway at a variety of organizations. While it does bring challenges, the process — if well handled — can fundamentally improve organizations' overall security posture by allowing all of their system configurations to be held in version-controlled source code repositories and regularly checked for misconfigurations.

Given the power of IaC, it is vital that its adoption be accompanied by strong security practices, with scanning and validation key to those processes. By using open source review tools like the ones mentioned above, companies can help to smooth their path in adopting this technology.

The Ins and Outs of Secure Infrastructure as Code

Lord previously spearheaded security for the Democratic National Committee and held leadership roles at companies including Yahoo, Rapid7, and Twitter.

The Cybersecurity and Infrastructure Security Agency has named Bob Lord to serve as a senior technical adviser to the Cybersecurity Division. 

Lord's deep cybersecurity experience includes time as chief information security officer (CISO) at Yahoo, a CISO-in-residence role at Rapid7, and as Twitter's first hire for its information security program. Most recently, Lord was the first chief security officer (CSO) for the Democratic National Committee. 

“Bob’s decades of experience and unparalleled expertise will be a great asset as we further strengthen our community partnerships, expand the Joint Cyber Defense Collaborative, and continue our work as the nation’s cyber defense agency to make us more resilient," CISA Director Jen Easterly said in a statement about the appointment this week.  "Bob and I share both a passion for helping Americans stay safe online and a dedication to raising the cybersecurity baseline across the nation. I’m super excited for the creativity he’ll bring to the team." 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Source

DARKReading