Log4j, the Cyber Event That Pushes for a Secure Software Development Lifecycle


Posted on by Roderick Chambers, CISSP, CISM

Just like clockwork, where would we be if we did not close out 2021 without a significant information security crisis? Welcome, Log4j, also known as “Log For Java,” the name says it all. The vulnerability impacted millions of Java applications using Log4j, including vendors, open-source projects, frameworks, and notable companies such as Apple, Twitter, Amazon, and Elasticsearch. Even the United States National Security Agency’s (NSA) reverse engineering tool, Ghidra, released as an open-source project to the public, has been found vulnerable to this Log4j security issue.

At this stage of the vulnerability crisis, users know what Log4j is, why it is crucial, and a warning to test all third-party applications to ensure protection from this vulnerability. Many researchers called Log4j a bug; however, it is more of a defect in the Java design. For the record, Java is no worse or better than any other language used regularly to build applications.

What exactly is Log4j?

On December 9, 2021, a remote code execution (RCE) vulnerability (CVE-2021-44228), identified in Log4j, an open-source logging API for Java, was discovered by Chen Zhaojun of Alibaba Cloud Security team through a bug bounty program for the popular game Minecraft. The Log4j vulnerability is not a typical supply chain issue but a significant flaw with software supply chain security.

Log4j, in the simplest terms, is software used to record all activities that go on under the hood of an application in a wide range of computer systems. For example, when a user clicks on a broken weblink and receives a 404 error message, this is a job for Log4j. The web server hosting the domain of the web link tells the user that the webpage does not exist. The server also records that event in a log for the server’s system administrators using Log4j. In the case of the online game Minecraft, the server uses Log4j to log activity such as total memory used and user commands typed into the console.

What exactly is the threat?

The vulnerability in Log4j is everywhere because the library is everywhere, and you likely visit websites every day that use Log4j. Log4j is a destructive problem because it allows hackers to create a “reverse shell” into the “host” computer. Picture this: the daily news reports that a weakness is discovered globally in every model of home lock, and instructions on how to defeat the lock are shared on every media outlet. By the way, before someone points out that this is why old things are better, please note that most home locks do have a weakness that allows someone to unlock them. This is the problem with Log4j, as it allows hackers access to your computer.

Secure Software Development: How do we miss this opportunity for a better SDLC process?

The federal government has its eyes focused on software supply chain security for the foreseeable future. The White House published an executive order on improving the nation’s cybersecurity, which calls for a software bill of materials (SBOM) for applications. It is a good start, but realistically, what are the chances of a developer reading the information and taking precautions? Log4j is virtually everywhere, often bundled as part of other software. This requires system administrators to inventory their software and identify its presence. If some people don’t even know they have a problem, it’s much harder to eradicate the vulnerability.

Log4j’s diverse uses create an issue where there is no one-size-fits-all solution to patching it. The fix will require different approaches depending on how Log4j was incorporated in a given system. Rather, it is recommended that organizations align their practices with a well-established framework, such as NIST’s Secure Software Development Framework (SSDF), which they organize into four phases.

Prepare the Organization (PO): Prepare the organization, people, processes, and technology to perform secure software development at the organization level and, in some cases, for each project.

Protect the Software (PS): Prevent tampering or unauthorized access to all software components.

Produce Well-Secured Software (PW): Publish software with minimal vulnerabilities in its releases.

Respond to Vulnerabilities (RV): Continuously test and identify vulnerabilities in software releases. When vulnerabilities are discovered, patches are issued and further tested to prevent similar vulnerabilities from occurring in the future.

Contributors
Roderick Chambers, CISSP, CISM

Information Security and Intelligence Advisor, New York State Department of Financial Services

Protecting Data & the Supply Chain Ecosystem

software integrity DevSecOps vulnerability assessment patch vulnerability & configuration management supply chain

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community