Those who have paid attention to the security news over the past few weeks are well aware that a severe vulnerability in the popular Java logging library Log4j pushed the IT community into full-blown crisis mode. Shortly after the first CVE was disclosed last month, Wired published a story declaring that “The Internet Is on Fire.” Twitter has since been flooded with tales of self-pity by infosec teams and the requisite barrage of dumpster fire memes.
Comparing a software flaw to a fire raging out of control may sound hyperbolic, but for too many organizations it’s not that far off. Like prior high-profile open source vulnerabilities, this trivial-to-exploit zero-day vulnerability in Log4j has impacted millions of systems and devices, ranging from web apps and enterprise software to safety-critical systems in vehicles, medical devices, and industrial equipment.
Whether in fighting a fire or mitigating a zero-day open source vulnerability, response time always becomes a critical factor in minimizing the damage. But as with a fire, it’s not just important that the team responds quickly today. It’s even more important that the group makes itself better prepared the next disaster. Here are the three phases of a zero-day attack that can help security teams better understand how to respond:
- The house is on fire! What happens next?
When the alarm sounds many first move to find and extinguish the fire. For CVE-2021-44228, that means identifying which applications were built with vulnerable versions of Log4j.
Security teams may find this a daunting task if they don’t maintain complete and accurate software bills of materials (SBOMs) documenting the open source software in use. Just about every organization depends on software to keep its business running smoothly. And that software undoubtedly contains thousands of open source components that could expose the organization to risk down the road if they aren’t kept up-to-date.
Fortunately, software composition analysis (SCA) tools make this task a lot more manageable. Using SCA to catalogue all of the company’s open source components lets the team immediately pinpoint which applications are at risk when a new vulnerability gets disclosed. Without SCA, tracking open source dependencies becomes a manual and error-prone process that can put the organization at a severe disadvantage. Hackers have been aggressively targeting this vulnerability since it was disclosed. It’s literally a race for the security team to find and fix the company’s software before they find and exploit the vulnerability.
- The team has found the flames. How do they put them out?
Once the team has identified its at-risk software, it needs to quickly remediate the vulnerable components. In some cases, it’s as simple as upgrading the component to the latest version and rebuilding. Unfortunately, it’s often a more complicated process that requires extensive development and testing resources, or it can trigger a cascade of other problems. This often happens while upgrading a foundational library or components several versions out of date. In these situations, it’s important to explore interim mitigation techniques or workarounds that effectively prevent attackers from exploiting the vulnerability until the team can update the component version.
In the case of CVE-2021-44228, it’s often easy to upgrade the Log4j library to a secure version because much of the world’s software was built with versions that are several years out of date. Furthermore, many of the proposed workarounds have been discredited. If the team doesn’t have an up-to-date software bill of materials (SBOMs) and has just recently scanned to see which applications are at risk, they may wind up fighting flare-ups for some time.
- The fire’s out. How does the team prevent the next one?
Once the smoke clears, it’s time to think about how the team can prevent or at least better prepare for the next fire. That’s all about early detection, accurate location, and rapid response.
First, without knowing what’s in the company’s software, the team can’t possibly rapidly and reliably respond to the next open source zero-day. Well-maintained SBOMs are essential. It’s not enough to scan for known open source vulnerabilities today. Hundreds of new vulnerabilities are disclosed every week. Rather, SBOM creation must become a continuous part of the team’s development processes, to ensure it always have an accurate, up-to-date view.
As mentioned earlier, SCA products are automated tools that allow security teams to do just that. These tools can be integrated into the company’ s software development and delivery pipelines to provide continuous visibility into the open source building blocks of the organization’s software as it builds and deploys it. Some SCA solutions can even perform binary analysis to provide visibility into packaged software applications or components that the organization obtained from third parties.
With accurate SBOMs in hand, it’s also important to have access to timely and accurate open source vulnerability alerts for the components the company uses. When an open source zero-day gets disclosed, the security team wants to know immediately which of its applications are impacted, so it’s important to choose an SCA solution that proactively alerts the team via email, slack, or a ticketing system like Jira.
It’s also important to have accurate and actionable information. CVE records available in the National Vulnerability Database (NVD) remain incomplete days or even weeks after a vulnerability gets disclosed. Teams often have to consult other resources to find the information needed for remediation. Bottom line: NVD records often deliver too little too late. The best SCA solutions augment CVE data with independent research that’s more timely and accurate. Stay one step ahead of hackers by choosing an SCA vendor that maintains a proprietary vulnerability feed.
Open source will always be an essential component of modern software. It’s not going away, so we’ll have to live with open source zero-days for several years. There have been more than 500 vulnerabilities disclosed since CVE-2021-44228, and they could wind up being far worse than Log4j. Don’t wait until the security team smells smoke and someone yells “fire.” Put the systems in place to detect and douse the flames before the organization gets burned.
Patrick Carey, senior director of market solutions, Synopsys Software Integrity Group
