While Log4j has been nothing but a headache for the past five weeks, there may be a Log4j silver lining in the future to make up for it. The key is taking the lessons learned and applying them to future actions.
Reflecting on Log4j
The Log4j vulnerability was publicly disclosed on December 9, 2021. It’s a zero-day, remote code execution vulnerability in the logging framework. If a hacker exploits it, they can make the server running Log4j run any software they want. Some reports estimate that over 840,000 attacks were initiated within 72 hours of vulnerability disclosure. To say it is a widespread issue is a massive understatement.
Log4j is hardly in our collective rearview mirror. There is a long-tail of remediation that will continue to be a part of our lives for a while. But we’ve been in the trenches for long enough to reflect on what it all means going forward.
CISA’s New Approach
The U.S. Cybersecurity and Infrastructure Security Agency recognized the unprecedented nature of the vulnerability from the beginning and actively chose a different approach to address it.
The agency’s director, Jen Easterly, has acknowledged that they’ve learned a lot of lessons about how to deal with something that is this widespread.
First, CISA adopted a crowdsourcing approach. The agency created a GitHub-hosted list of over 2,700 software products. The list tracks which products are affected by the vulnerability and which vendors have issued patches. CISA also acknowledged the importance of engaging with security researchers.
Going forward, CISA’s Executive Assistant Director, Eric Goldstein, says that his agency will work closely with the Department of Homeland Security to use artificial intelligence and machine learning to develop tools to perform packet analysis of open source software. Their hope is to minimize the need for individual code reviewers to reduce the number of weaknesses in software used at large scale. He also expects to see increased federal support for the development and maintenance of open source software in general.
Increased Emphasis on SBOMs
In July 2021, the National Telecommunications and Information Administration published a report on the minimum elements needed for a Software Bill of Materials (SBOM). The Log4j vulnerability has placed an increased emphasis on the need for this kind of guidance.
An SBOM is an inventory of all software components (both proprietary and open source), open source licenses, and dependencies in a given product. The minimum elements as defined in the report are in three broad areas:
- Data Fields: Documenting baseline information about each component that should be tracked.
- Automation Support: Allowing for scaling across the software ecosystem through automatic generation and machine-readability.
- Practices and Processes: Defining the operations of SBOM requests, generation, and use.
The idea is that an SBOM would improve the ability to track known newly emerged vulnerabilities and risks in software products. IT managers and security researchers could use SBOMs as a foundational layer on which to build additional security tools and practices. Basically, if you know what you’ve got, you will know how to manage and protect it!
There is some resistance to overcome around SBOMS. Some developers fear that their intellectual property will be revealed and devalued. We need to continue moving forward with a standard SBOM that not only respects the work of developers but also increases visibility for real-world users.
Monitor and Never Stop Monitoring
As we continue the long process of remediating Log4j, it’s important to remember that the next vulnerability is just around the corner. Businesses and other organizations must remain vigilant and knowledgeable. The first step is knowing what software is running in your environment. A list like the one CISA crowdsourced on GitHub is only useful to you if you know what’s in your tech stack.
Take the time now to create an inventory of your environment. You’ll be ready when the next one (there’s always a next one) hits.
If you need assistance evaluating your software environment, interpreting SBOMs, or remediating log4j issues, reach out to Asylas. Call us at 615-622-4591 or info@asylas.com. Or complete our contact form.
