Log4J Attacks Confirm Need for DevSecOps, Automation, SBOM

Alarms set off from a barrage of cyberattacks that exploit critical vulnerabilities in Log4J – Apache’s Java-based logging tool. Federal government agencies have only two days left to initiate mitigation measures to comply with emergency directive issued by the US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA). But despite the interest, don’t expect the attacks to end anytime soon. And don’t expect your entire systems to be fixed quickly.

Log4J’s situation once again reveals the intricacies of securing applications that use open source code libraries. It is fueling the push towards a unified code of materials (SBOM) – a “component list” that will be made available by software developers, to reveal all external components and the open source components included in it. It also raises questions for enterprise IT departments trying to locate and patch their vulnerable systems: How can automation help, and is it time for DevSecOps?

Log4J vulnerabilities

Three Log4J bugs have been exposed in recent weeks. The significance cannot be overstated – particularly the “Log4Shell” vulnerability that was revealed on December 9, and has been described as the worst security vulnerability in a decade or ever.

Log4Shell affects hundreds of millions of devices. It is a “remote code execution” vulnerability that enables attackers to gain complete shell-level control over all types of victim devices, from web servers to industrial control systems. When it was first revealed, it was already being exploited (making it a “zero-day attack”). Four days after the disclosure, security firm Check Point reported that 40% of global corporate networks had already been targeted with such attacks or information gathering activity to determine if they were at risk. The bug has been widely exploited by all kinds of threat actors, including nation-state-backed groups. It has been used to steal data, steal passwords, install encryption tools, and more.

Complicating matters further, the Apache security update to patch Log4Shell opened a new vulnerability. This forced Apache to release a second update. However, after the release of the second update, another vulnerability was discovered, which led to the release of a third update. (So ​​the patch is now, with version 2.17.0, released on Saturday, December 18th. See this page kept by the Apache Logging team for further updates. Also consult with CISA for recommended mitigations when a patch is not an immediate option. )

But organizations everywhere are asking: What should we fix? Which of our devices/apps are at risk?

3rd party code problems

Log4J is a Java-based logging utility wrapped into the Apache Logging Services. It’s open source third-party software hidden inside thousands of apps, and many organizations (and developers) don’t even know they’re using it. Google researchers estimate that Log4J is part of more than 35,000 Java packages. Hundreds of millions of devices are affected by vulnerability.

Open source software is now an essential part of enterprise applications, including commercial off-the-shelf software. It can be widely used for all kinds of purposes – encryption, network monitoring, file management, running web servers, etc.

Explaining the challenge of third-party code, open source, and “nested dependencies,” Chris Weisupal, chief technology officer at application security firm Veracode, says: “Open source is built on open source build on open source, and the transition to a fourth source or level five dependency.” Or the sixth is not strange at all.”

So when a vulnerability is discovered in such software, the effect ripples and ripples…but the affected don’t necessarily know it. This fact has been reinforced several times over the past seven years since the disclosure of the critical Heartbleed vulnerability in OpenSSL.

“Log4Shell has been more than a point of reinforcement, showing that code can exist in a myriad of places, whether it’s open source or not,” says Pete Allure, director of product security at Red Hat. “I saw similar issues with a closed source library built into other vendor products in 2004 – 2006, highlighting that we periodically relearn this lesson. All of this shows that we need to know where and what code is in your products or environment and only allow trust as needed.”

In a recent report, Veracode found that 79% of developers never Update third-party code libraries. Wiesopal says this could turn out to be a bigger problem. Because of all the complex dependencies, one small update here might cause a small outage there. It gets worse the longer you wait – so to update Log4J to 2.17 you first need to upgrade Java for the first time in 15 years. “That’s why we recommend not putting in too much security debt around your reliance on third-party packages,” he says, “because the next big remote code execution…may happen and you’re stuck in a huge engineering effort just to update one library in one app.” .

A recent Synopsys report found that 60% of code bases contain known open source, high-risk vulnerabilities. Meanwhile, commercial software vendors are failing to do their part. A 2019 Synopsys research found that more than 40% of commercial software contained known vulnerabilities that are at least 10 years old.

So what are the solutions to this recurring problem?

It’s time to drop SBOM

One idea that is gaining traction is to require software builders to provide a Software Materials List (SBOM), which is a formal record detailing all of the components and supply chain relationships used to build this software.

CISA held a two-day “SBOM-A-RAMA” conference last week. President Biden issued an executive order requiring the Department of Commerce’s National Communications and Information Administration to issue the minimum requirements for the Software Materials Act. NTIA released these requirements in a July report.

And in the wake of the Log4J attacks, analyst firm Forrester wrote on December 15 that SBOMs are now important. They also suggest that data analysis of groups of SBOMs can lead to greater insights. “When taken collectively, searching all public SBOMs in a standardized, readable format gives us an idea of ​​which components are ubiquitous and therefore ‘critical’. … Is systematic metrics-based analysis of the most common software packages seen in products forcing us to confront The reality of open source ‘too broad to fail?’

However, there are others who suggest that SBOMs look nice in theory, but not in practice.

“SBOMs are a start, but they are only part of the puzzle,” says Michael Lieberman, of the Cloud Native Computing Foundation’s security advisory group. “They tell you a certain level of confidence about dependencies that are included in a part of the program. It is important to realize that they do not tell you where The software indicated by SBOM is already installed. “

Wysopal adds that while SBOM can be useful, it prefers to get assurances from software vendors about how they keep their software secure – eg a policy by which they can update any medium-severity bugs in third-party code within a framework specific time. Do you want the ingredient label on your soup can? He says, “Or do you want to make sure that they have a process where there is no poisoning in the soup?”

Red Hat’s Allor explains that one limitation of SBOMs is that they document a particular software version and that there is “consistency in its data. However, something that would describe exploiting vulnerabilities has to be dynamic as the current situation evolves”.

Automation and DevSecOps

At Wysopal’s discretion, manual grafts do not stand a chance against the magnitude and frequency of vulnerabilities. Manually running tests, opening tickets to fix the problem, validating the problem, and possibly sending those tickets out at dinnertime where a human operator can let them wait until morning may slow down the process.

“It was only in the past few years that we really understood that this [third-party code] It really needs to manage risk in a different way.” “And that’s how this whole suite of software configuration analysis tools came out, and the best practice is to integrate it into your pipeline,” says Wysopal. “So you have a current view of what you’re using and also there is an opportunity To update when this new version comes out, and we hope you can automate this as much as possible.”

“Another key thing missing is a better way to distribute vulnerability information,” Lieberman says. “[Common Vulnerability Enumeration Scores] Useful, but outside of software and version, the information is often unstructured. It can be difficult to develop automated tools to determine whether or not we are at risk. Newer specifications like VEX (Exchange of Exploitable Vulnerabilities) will help a lot in the future in providing information about dependency in the context in which it is running.”

Shifting security to the left and being better prepared for the inevitable cyber incident is another piece of the puzzle. “A good incident response coordination team with a plan to interact with DevSecOps groups determines the priority of the work and the severity of the problem, giving the organization the ability to respond more effectively,” says Allor. “It provides a ready team with focus and roles to process configuration and settings faster as well as deploy fixes.”

Lieberman also says that individual organizations cannot solve this problem alone, and that open source projects and vendors and organizations like CNCF and OpenSSF must work in tandem.

“We need better cooperation as an industry and as a society in order to address these issues, because those who might exploit these vulnerabilities for malicious purposes are cooperating with each other,” Lieberman says.

What to read next:

KubeCon + CloudNativeCon Highlights Open Source Security

The cost of a ransomware attack, part 2: response and recovery

How DevSecOps Certification Can Help You Gain a Competitive Advantage


Leave a Comment