Log4J Vulnerability Discovery Calls for Advanced Risk Illumination Methods

PARTNER CONTENT

On December 9th, the cybersecurity community discovered 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—placing millions of unsuspecting users at risk. As with all vulnerability threats, security solution knowledge can be the difference between a compromised system and an empowered user.

Users Race to Discover and Eliminate Log4J Threat

Fortress VP of Government Solutions, John Cofrancesco, has likened the Log4J vulnerability to that of salt, hidden within most kitchen recipes:

“If I asked you, ‘hey show me the salt you have in your house,’ you would probably walk up to the salt you have sitting on the table, maybe some you have hidden in the cabinet,” Cofrancesco said. “What you probably wouldn’t do is show me ‘hey, here’s my Panera sandwich, or here’s the soup I have, or here’s the juice I have, my Powerade.’ All those other things have salt in it, it’s just obscured by the fact that there are a bunch of other ingredients. That is precisely what is going on here.”

At this point, Log4J vulnerability discovery remains the most pressing issue in the race to combat this cybersecurity threat—the pertinent question being:

How can users detect and eliminate this threat faster than it can be exploited by cybercriminals?

Solutions for the Present Crisis and Future Peace of Mind

If the Log4J vulnerability is truly as common in software as salt in our food, how can users begin to piece together their exact risk? A great place to start is for users to obtain the software bill of materials (SBOM) for all components used by their system. SBOMs are essentially like the back of a cereal box, explaining what specific ingredients make up the software, making any known vulnerabilities easier to discover.

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 making SBOMs an increasingly important part of a cybersecurity solution all users would greatly benefit understanding.

For the future security of their systems, users may wish to use File Integrity & Software Assurance (FIA) for software inventory, risk analysis, and management, to integrate new software or patch existing components. Benefits include illuminating any software components that pose a threat through vulnerabilities, questionable origin, obsolescence, along with other issues.

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 learn more.