Gone are the days when organizations could implement basic cybersecurity measures and assume they wouldn’t be necessary. In fact, cybercrime damages are now predicted to reach $10.5 trillion annually by 2025 – an indication of just how far reaching and severe potential cyber incidents have become. The recent Log4j vulnerability dominating headlines has demonstrated the importance of knowing what tools and software your organization has and how they can be affected, preferably before you’re in the midst of remediation. 

Log4j Impact

Log4j is a serious vulnerability; a zero-day exploit that had no known remediation before being exploited by attackers. Even Jen Easterly, the director of the U.S. Cybersecurity and Infrastructure Agency (CISA) said it is the “most serious” security vulnerability she has seen in her extensive career. The logging library is widely used by software deployed on millions of computers, with analysis showing 93 percent of enterprise cloud environments are at risk from the vulnerability. Both the Federal Trade Commission and CISA have issued warnings and guidance to reduce the likelihood of harm and mitigate the risks posed by Log4j. The top action? Understand the extent of the problem by identifying which assets use the Log4j software and then apply an appropriate patch. 

In the past when zero-day exploits occurred, the software product or tool was built as a monolithic code base where the vendor wrote and maintained everything. The vendor of the software would quickly release a patch or workaround for an exploit and notify its users so they can take remediation steps to protect their IT infrastructure. 

In most software built today, software vendors have adopted a model where shared components are leveraged for common and mundane tasks of the software. These components may be built by other software vendors or by open-source project teams. In this case, software vendors must not only maintain their own code for security vulnerabilities but also manage the components they used and ensure they update these components as patches become available. The Log4j exploit is an example of a shared component being affected.

This presents several new problems that IT staff had to deal with. The first is that since it was a shared component, IT staff needed to determine if Log4j was used by any of the software within their company. The second was the scope of Log4j. The component is widely used across the industry, so it’s not just a single software vendor’s product that was affected. Many software products in use by organizations included Log4j as a component. Thankfully, most software vendors that included Log4j quickly had a patch ready within a week of the vulnerability being identified – the challenge was in knowing what to patch and how to prioritize all the affected software.

Mitigating the Effects of Log4j

Mitigating the Log4j vulnerability acts as an exercise in understanding your software supply chain and leveraging a software bill of materials (SBOM) to establish an inventory of potentially affected components. A SBOM allows IT teams to understand what components are in use in their organization, enabling them to determine if the version of software they use is affected by a component vulnerability. This in turn allows IT to determine the scope of the vulnerability within the organization. Once the scope is known, the IT team can prioritize which software needs to be addressed first based on the risk each presents to the organization.

Log4j showed a lot of organizations that they don’t know what they don’t know, and the longer an organization spends figuring out what components are affected, the worse the potential impact. A recent meeting at the White House brought together administration officials and executives from the biggest tech companies to discuss the need for better security in the open-source community. The Log4j vulnerability lit a fire under the industry, demonstrating the importance of a SBOM for efficient and effective mitigation and remediation. 

This incident highlighted the differences between organizations with mature processes and those without. For a mature organization with an inventory of software assets and SBOMs, it could have simply been a matter of looking at what they have, whether it is affected, and prioritizing what to fix first based on criticality. Mature processes are ultimately about prioritization, especially as an organization scales. When a vulnerability like this is found, mature organizations will have already defined processes, along with owners and responsibilities for each activity. These organizations maintain inventory of software assets and their SBOMs are ranked by criticality and the information each component has access to. As CISA recommends, once vulnerable assets are identified, assume compromise and implement processes to determine if the vulnerability has led to a breach. If you’ve done everything right to this point, it should be relatively easy to spot and remediate from there.

Conclusion

The Log4j vulnerability was a wakeup call to organizations that may still be lacking mature cybersecurity processes. As we continue to see the ripple effects, we can take these lessons learned to build more efficient and effective processes and policies in preparation for future exploits.