Skip to content

SBOM as a Risk Illumination Method for Log4J Software Vulnerability

On December 9th, the cybersecurity community became aware of active exploitation attempts associated with a vulnerability in Apache Log4j 2. The vulnerability resides in the Java Naming and Directory Interface (JNDI) and can be easily exploited by malicious actors. Successful exploitation, achieved from a single string of text, can result in remote code execution (RCE) and could allow a threat actor to completely control a targeted server. It affects default configurations and can be targeted by unauthorized remote attackers to impact applications that use the Log4j library. Millions of applications use Log4j for logging error messages, including organizations such as Amazon, Apple, Cisco, Red Hat, Tesla, Elastic NV, and Cloudflare.

Timely discovery and advanced solutions are key

Fortress proposes to utilize the File Integrity Assurance (FIA) continuous software assurance solution to answer the question facing security teams trying to determine their exposure to Log4j and other vulnerabilities. By utilizing a software analysis approach that results in both a software bill of materials (SBOM) as well as analysis of that SBOM, software suppliers and consumers alike can obtain visibility into likely candidates of software vulnerabilities, such as Log4j.

SBOMs provide the knowledge needed to combat new vulnerabilities

An SBOM is an inventory of components found in a software product, along with metadata and dependency relationships for those components. For decades, software consumers have been using software with zero visibility into what’s inside. This lack of transparency, combined with the advent of a digital transformation that has brought software to the nexus of every important part of our lives, is the core issue that prompted the need for SBOM in the first place.

Most software users have grown accustomed to the idea that they can trust the software supplier to discover and patch vulnerabilities in their products, seemingly in a relatively short amount of time. In theory, the situation should be no different when it comes to vulnerabilities in components. Whenever a new vulnerability is identified in a component in their product, the supplier should develop a patch for it. If for some reason the supplier is unable to develop a patch right away, they should have private discussions with customers regarding alternate mitigation steps the customer can take.

The problem is that vulnerability scanners cannot identify these issues, and so an SBOM is needed to identify potential vulnerabilities. Vulnerability scanners are designed around the concept of writing a specific plugin for a specific vulnerability, and with hundreds of thousands of vulnerabilities in the National Vulnerability Database, the scanner vendors cannot hope to have tests for all of them. Additionally, even when the scanner vendor writes a plugin, they only cover one specific instance of that vulnerability. Using a currently available Log4j scanner as an example, there are four separate plugins looking for very specific implementations of this vulnerability while there are tens of thousands of ways this vulnerability can be implemented. Compounding this, the scan needs to be credentialed and in large enterprises, many assets cannot be scanned with credentials. The only reliable and scalable way is with an SBOM.

The Fortress solution

Monitoring - Software Supply Chain - File Integrity Assurance (FIA) - Annual subscription to a File Integrity & Software Assurance process, validating the authenticity and integrity of all patches and updates for a given product. Authenticity checks include checking the supplier for known breaches, appropriate encryption delivery, and updated security certificate and DNS checks. Integrity checks include reviewing code signage, malware analysis and in some cases sandbox and firmware analysis. Software assurance activities include the creation of a software bill of materials and vulnerability analysis to identify known vulnerabilities.

Optional Vulnerability Exploitability (VEX) service – Fortress provides a one-time analysis of software by a qualified product security engineer to determine if the software identified as potentially vulnerable in the SBOM analysis is actually exploitable. Only one vulnerability is included in a standard VEX analysis and all verification will be performed offline in the Fortress security lab. No online exploitation will be performed as part of this service. Fortress will provide results in both machine readable and human readable formats documenting the results of the analysis and recommended mitigations.

For a detailed Log4j threat analysis report and more information about using SBOM as a method for identifying vulnerable software in your technology ecosystem visit Fortress to get started.

Blog comments