Apache Log4j Flaw Puts Third-Party Software in the Spotlight
As organizations around the world scramble to address the critical Log4j vulnerability, known as Log4Shell, the number one question on every security leader’s mind is: How do I know if I have this out there?
The sheer ubiquity of Apache Log4j, an open-source logging framework, makes this a particularly challenging question to answer.
Not only do many organizations use Log4j in their own source code, it’s also used in many of the products these organizations acquire from third parties. Organizations that have embraced the “shift left” approach to their secure software development lifecycle (SSDL) can analyze their own source code to find and fix the flaw in their own systems.
An SSDL approach that includes static application security testing (SAST), dynamic application security testing (DAST), third-party dependency checking, container security scanning, vulnerability management and Infrastructure as Code (IaC) is needed. But even with all those practices in place, organizations will still struggle to catch everything on the left-hand side. Vulnerability management and web application scanning are also crucial, particularly when it comes to your third-party software. It’s not enough to discover whether or not the flaw exists, you also need to have an understanding of the level of risk it represents in the context of your organization’s mix of applications, assets and business processes.
Although the recent executive order from the Biden Administration calls for organizations to develop a software bill of materials (SBOM), most vendors don’t supply SBOMs for their software. And, even if they did, most organizations remain light years away from having the processes and capabilities in place to make effective use of them. So, when an incident like log4j occurs, cybersecurity leaders are left with one option: calling their third-party vendors and asking them. This is arduous, redundant and time consuming, leaving organizations in a scramble even as attackers rush in to exploit the flaw.
Even in the most mature organizations, where SSDL practices and SBOMs are ingrained in the processes, gaps remain that make it challenging for security organizations to answer these crucial five questions:
- Do we run these in our environments?
- How about in our infrastructure?
- How about in our build pipelines themselves? ‘
- How about the providers of our infrastructure? (this point is especially pertinent if you are using cloud service provider services)
- Since software composition analysis (SCA) won’t discover all instances of Log4J, have we run other controls, such as Infrastructure as Code (IaC), vulnerability management and web application scanning, against all components of our code?
The bottom line is this: There is no easy fix for Log4j. One obvious option — implementing a web application firewall — has already been shown to be fairly easy to circumvent. A responsible organization needs to do the work of updating its core software and understanding how this flaw affects the overall risk profile. Organizations responding now are making decisions in crisis mode; once the initial crisis is behind us, the temptation will be to declare “mission accomplished” and walk away. In our view, that’s a catastrophic mistake. We are well past time for organizations to do the hard work of fixing their infrastructure and maintaining their systems with a security-first approach baked in.
We at Tenable are committed to SSDL and we are taking the following actions in response to Log4j:
- We have blocking gates and, in this case, we’re blocking the use of any vulnerable instances of software, to include Log4j.
- We actively and constantly perform vulnerability management scans and web application scanning across all of our infrastructure and pre-release product code before it ships to customers.
- Further, we have actioned all indicators of compromise and attack and we have implemented controls at the network and host levels.
We will continue to monitor threat intelligence to track the threat landscape and adjust as required. In the end, responding to any incident is about knowing what’s in your environment, knowing your attack surface — including all third parties — and driving risk down quickly. Time is of the essence. Adversaries are always at the ready to jump on the latest vulnerabilities and re-purpose them for their own use cases. Organizations must do all they can to take a hard look at their practices now, as the ripple effects of this incident will plague enterprise software for years to come.
