While incident responders worldwide are struggling with the latest Apache Log4j vulnerability, which affects countless products, organizations need to look past this disaster horizon toward a sustainable security response. Much has been said about responders using software bills of materials (SBOMs) to assist in remediation prioritization, in some cases eclipsing other practical guidance that may be more immediately useful. Many efforts to aggregate step-by-step response incantations are being developed, but this column is about learning where your process gaps are in real time, to make improvements for the inevitable next time the Internet is on fire.
An SBOM is an ingredient list of components in a given program. Exploitability information and your accurate asset inventory are prerequisites for SBOMs to be useful in the context of rapid vulnerability and incident response.
There are no studies of using a complete organizational SBOM mapping in response to these types of incidents. As organizations refine their incident response, new projects like SBOM are welcome to the arsenal of tools that enable rapid prioritization, such as asset management. In theory, SBOMs will make emergency security response faster and more scalable. There are limitations to all of these approaches to rapid incident response, and all are vulnerable to outdated information. For example, initial guidance to remediate Log4j itself was revised in real time when a bypass of the initial fix was discovered. Each tool that helps without causing a distraction is a good tool to use in incident response.
With all that in mind, SBOMs are an objectively great idea. If you are making software, you absolutely should integrate SBOMs into your development and release practices immediately. Organizations can also use SBOMs when comparing software for purchasing decisions, since it is a useful tool to compare relative attack surfaces when you have the time to do security due diligence. For incident response, though, SBOMs may not be comprehensive enough across the organization to be of much assistance until vendors start consistently creating them.
If your organization is currently using SBOMs to help prioritize Log4j response, consider the following time-sensitive questions:
- Given that we know SBOMs will take a while to catch on with vendors, how are you balancing risks of missing key vulnerable assets early when directing limited staff?
- What is your plan for finding vulnerable applications that either lack SBOMs or have inaccurate SBOMs?
- If all SBOMs were perfect, what else about your process that’s under your control would you improve after this Log4j response?
- For your after-event lessons-learned debriefs, how will you address your vendors who didn’t have an SBOM and didn’t proactively communicate their Log4j status to you but were found to be vulnerable in testing?
- Do you have a way to flag every product in your environment that lacks an SBOM? What mechanism do you have to ensure parallel testing in future events like this?
Are you benchmarking your response capabilities? Some elements to measure include:
- Speed: Were all your organization’s assets checked and fixed, or verified as unaffected?
- Efficiency: Were the vulnerable assets of highest organizational value addressed first?
- Information sources: What was your rate of using SBOMs to prioritize your remediation efforts versus other sources of timely information — e.g., the Internet or your vendors telling you, or your own testing?
I would think most organizations, if they had the staff and skills to do so, would ideally conduct several parallel work streams — informed by traditional asset inventory, SBOMs, Internet sources, vendors affected, security vendors, and testing.
For SBOM to mature into the high hopes all of us have for it, tooling and automation will have to accompany the sobering reality that even perfect SBOMs can’t save an organization that doesn’t know its assets. When novel approaches emerge, I worry that people looking for simple solutions during tough times will fail to perform the necessary pre-work that is their true, best hope in the next security incident.
We fail when we do not innovate, but we also have seen the cyclical nature of putting our hopes into emerging innovations that aren’t broadly adopted enough to carry us through the next imminent Internet crisis. When the next Log4j hits, hopefully we will have made progress building upon the foundations of security, merging new innovations and tools like SBOM with experience and diligence.
