The Log4j security vulnerability was a wake-up call for organizations of all kinds, large and small. An open-source software component used in countless software products and in-house tools can be exploited to give attackers control of an application, executing commands of their choice to install malware, exfiltrate data, or perform other malicious acts.
Log4j was also a warning that the scope of risk management and threat detection is expanding. Going forward, IT organizations need tools and processes for discovering and tracking all the components in the software applications they build, buy or subscribe to. They need tools for scanning and accurately inventorying vast amounts of software — without crashing mission-critical systems with repetitive search algorithms that max out the central processing unit (CPU) and memory of every system being searched.
They also need up-to-date, accurate, verifiable software “bills of materials” (SBOMs) for all their software assets, so that when a new vulnerability is announced, they can immediately determine if the software on any of their endpoints (laptops, servers and other devices) are affected. That way, they can take immediate action to protect the ongoing business operations, data security and compliance of the organization.
Organizations need a systematic way of tracking the contents of all software
Log4j won’t be the last serious vulnerability that IT teams will have to hunt for. In fact, within several weeks of Apache’s announcement about Log4j, a serious vulnerability in a Linux permission tool was announced. Dubbed PwnKit, it has allowed attackers to run commands as privileged users in Linux environments. The vulnerability is found in all major Linux distributions.
These vulnerabilities point to the importance of knowing the contents — the SBOMs — of every piece of software and every operating system configuration running in an organization.
The White House Executive Order on Improving the Nation’s Cybersecurity, issued on May 14, 2021, gives this idea an official push. The order notes:
The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended. … Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.
The order calls for the Director of Commerce to work with the National Institute of Standards and Technologies (NIST) to recommend practices and guidelines for creating SBOMs. Specifically, it calls for:
- Maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.
- Providing a purchaser a SBOM for each product directly or by publishing it on a public website.
Any software application is only as secure as the components it includes. This Executive Order acknowledges that no organization, public or private, can place confidence in its software without knowing the components that go into its software.
Beyond Log4j to continuous threat hunting
The Log4j vulnerability highlights the need for organizations of all kinds to improve their capacity for discovering vulnerabilities, patching them at scale, and remediating threats on an ongoing basis. It also highlights the need for organizations to adopt SBOMs so that any organization using an application can quickly understand its contents.
With the Federal Trade Commission (FTC) committed to penalizing companies that leak data because of any vulnerabilities similar to Log4j, the agency is signaling that longstanding lapses in patch management will no longer be tolerated. Failure could result in fines up to hundreds of millions of dollars.
IT teams need to act now, not just to find and fix Log4j vulnerabilities, but also to implement tools and processes for finding software component vulnerabilities generally. If six months from now another open-source software component is found to contain a security flaw, security teams will need to respond quickly to detect and fix all instances of that component.
Ideally, security teams would have real-time visibility into threats. If a new vulnerability is announced, they could consult SBOMs and quickly understand their exposure. Fast, automated tools would scan endpoints on premises and in the cloud, providing additional coverage. When vulnerabilities are pinpointed, they can be managed and patched. And the automation and efficiency of this process make it repeatable so that even if a vulnerability is reintroduced to a network, it can be detected and remediated quickly.
Conclusion
IT and security leaders should understand both the short- and long-term implications of the Log4j vulnerability. Business as usual has changed. IT organizations require new tools and processes, and departments, as varied as security and purchasing, need to change their expectations.
IT organizations of all kinds have to improve their capacity for finding specific software components at scale. At the same time, organizations need to be ready to produce and receive SBOMs as part of software sales, purchases and deployments.
Learn more about Log4j and how to protect your organization future Zero-Day vulnerabilities.
