Although accident responders all over the world are struggling to deal with the latest Apache Log4j vulnerability, It has affected countless products, and organizations need to go beyond this disaster vision and turn to sustainable security response.There has been a lot of use by responders Software Bill of Materials (SBOM) Help determine the priority of repairs, and in some cases, may overlook other practical guidelines that may be more straightforward and useful.A lot of effort Aggregate stepwise response The mantra is under development, but this column is about knowing where your process gaps are in real time, so that you can make improvements for the inevitable next time the Internet is hot.
SBOM is a list of components in a given program. Exploitability information and accurate asset inventories are prerequisites for SBOM to be useful in a rapid vulnerability and incident response environment.
There are no studies using a complete organizational SBOM map to respond to these types of events. As organizations improve their incident response, new projects such as SBOM are welcome to join the tool library that supports rapid prioritization, such as asset management. In theory, SBOM will make emergency safety response faster and more scalable. All these rapid incident response methods have limitations and are susceptible to outdated information. For example, when it was discovered that the initial repair was bypassed, the initial guide for repairing Log4j itself was revised in real time. Every tool that provides help without causing interference is a good tool for incident response.
With all of this in mind, SBOM is an objectively good idea. If you are making software, you should definitely integrate SBOM into your development and release practices immediately. Organizations can also use SBOM when comparing software purchase decisions, because it is a useful tool for comparing relative attack surfaces when you have time for security due diligence. However, for incident response, SBOM may not be comprehensive enough for the entire organization to provide much help until the supplier continues to create SBOM.
If your organization is currently using SBOM to help prioritize Log4j responses, consider the following time-sensitive issues:
- Given that we know that it will take a while for SBOM to catch up with suppliers, how do you balance the risk of losing key vulnerable assets early when coaching a limited number of employees?
- What are your plans to find vulnerable applications that lack SBOM or that SBOM is inaccurate?
- If all SBOMs are perfect, after this Log4j response, what improvements can be made to the process you control?
- Regarding your hindsight report, how would you deal with vendors that do not have SBOM and did not proactively communicate their Log4j status to you but were found to be vulnerable during testing?
- Do you have a way to mark every product in your environment that lacks SBOM? What mechanism do you have to ensure parallel testing in future events like this?
Are you benchmarking your responsiveness? Some elements to be measured include:
- Speed: Have all assets of your organization been inspected and repaired, or verified that they are not affected?
- Efficiency: Is the fragile asset with the highest organizational value solved first?
- Information source: Compared with other timely information sources (for example, the information that your supplier tells you on the Internet, or your own tests), what ratio do you use SBOM to prioritize repair work?
I think most organizations, if they have the people and skills to do this, would ideally conduct multiple parallel workflows—provided by traditional asset lists, SBOM, Internet resources, affected vendors, security vendors, and testing information.
In order for SBOM to mature until all of us have high hopes for it, Tools and automation It will have to be accompanied by the thought-provoking reality that even a perfect SBOM cannot save an organization that does not understand its assets. When new methods emerge, I worry that those who are looking for simple solutions in difficult times will not be able to perform the necessary preparations, and this is their true and greatest hope in the next security incident.
When we do not innovate, we will fail, but we have also seen the cyclical nature of pinning our hopes on emerging innovations. These innovations have not been widely adopted and will not be enough for us to survive the next imminent Internet crisis. When the next Log4j appears, I hope we can make progress on a safe basis, combining new innovations and tools (such as SBOM) with experience and diligence.
