How to operationalize SBOMs for incident response

todo-sbom-operationalize-incident-response

As the cybersecurity industry has endeavored to reduce the risk of software supply chain security flaws, software bills of materials (SBOMs) have received a ton of attention of late, as security pundits have promoted them as a key building block in software supply chain security programs.

But like a tree falling in the forest, does the creation of an SBOM make any noise if there's no one around using it? To benefit from the component and dependency information gathered in SBOMs, security teams must make plans to actually operationalize them.

Some of the more obvious areas for this are in application build governance and ongoing vulnerability management, but security teams can leverage SBOMs in cybersecurity incident response (IR). Here's why — and how to put SBOMs to work. 

[ Learn why you need an SBOM, more | Get a free SBOM and software risk analysis ]

The value of SBOMs in incident response

An SBOM can be a really valuable tool for both IR and security operations center (SOC) teams who should ideally know not just what devices or processes are running on a network, but also the ins and outs of the software their organization is using to run everything, says Christine Gadsby, vice president of product security for BlackBerry.

"This allows SOC teams to understand contents and monitor a product's ingredients for potential vulnerabilities rather than being dependent on the product vendor to tell them and provide a fix, which is often too late. This is total software transparency and incredibly valuable, but you must build the capability to monitor it."
Christine Gadsby

Assuming that analyst and response teams can find the right SBOMs quickly, SBOM information can help IR teams speed up their response time for software-related attacks and breaches, says Jeff Williams, co-founder and CTO of Contrast Security. The most useful scenarios are when a known vulnerability is targeted in an attack and the team has figured out which library is being affected.

"Then, using an SBOM, the IR team can immediately see whether a vulnerable version of the library is in use in a system. They can accelerate the response by asking the development team for a specific fix in a specific piece of software."
Jeff Williams

Williams explains that SBOMs can be useful in responding to attacks on unknown flaws in an application or API.

"A complete SBOM can help IR teams understand how the application/API works, enabling them to put an attack in context. The SBOM may also help them track down the repos and individuals involved in a project, shortening the response time."
—Jeff Williams

SBOMs containing information about services such as backend connections to databases, queues, APIs, and directories can be helpful in calculating the blast radius of a breach when responders are called to communicate details in the thick of an incident, Williams adds.

The incident response lifecycle: Where SBOMs should be used

Experts say SBOMs can be utilized during multiple stages of the IR lifecycle. Here's a breakdown of the role SBOM can play across each of the four phases.

1. Preparation

"In preparation, if you are a vendor and have SBOMs for what you produce as a product, and what you consume from other vendors internally, you can create a catalog all of those ‘lists of ingredients’ to create a holistic understanding of your entire attack surface – a total supply chain view," Gadsby says.

Walter Haydock, founder and CEO of StackAware, says that SBOMs using the CycloneDX format are particularly well suited for threat modeling. Mature IR teams that do threat modeling exercises to plan their response activities should find SBOMs extremely useful.

"Since CycloneDX allows for description of data flows, dependencies and other information useful to the practice, security architects can use SBOMs to create machine-readable representations of their networks. This can help them predict attacker movements as well as the business impacts of losing access to certain key dependencies like cloud service providers."
Walter Haydock

2. Detection and analysis

Detection and analysis is the phase in the IR lifecycle that's seen most universally as a good fit for SBOM support, says Williams.

"SBOM information is mostly useful during the detection and analysis phase. The visibility into what is in the software provides context and details that inform the analysis. Obtaining this information from binaries or going back to development teams is extremely time consuming. If SBOMs include vulnerability exploitability (VEX) information, this information can be very helpful in the analysis as well."
—Jeff Williams

3. Containment and recovery

IR teams seeking to ensure they've eradicated similar or related software attack activity across an organization can utilize SBOMs to seek out affected components in areas that they may not have initially begun their investigations, Gadbsy says.

"SBOM information is vital to help containment and recovery in the incident response. This telemetry lets you query your vendors and third parties to determine their impact rather than waiting for them to tell you. Shifting this far left in containment and recovery helps identify patching needed before exploits happen."
—Christine Gadsby

4. Post-incident response

As responders tie off on recovery efforts, SBOM can also help with post-incident activities, Gadsby says, explaining that SBOM data can help organizations do post-mortem work that informs how they prioritize fixes in the future:

"You can review attack surface telemetry to understand a better enterprise level and in-depth risk picture. This will also assist in lesson learned activities to mitigate future organizational risks of the software consumed or produced." 

Tuning the SBOM for IR and SOC consumption

Many organizations today are still stuck in a rut with regard to operationalizing the SBOM because creating an SBOM is the easy part. Figuring out how to use it is trickier because this is where the tooling and processes to support that work are still developing.

"Because SBOMs are incredibly detailed and lengthy documents, having the right tools in place to allow for querying them is vital to operationalizing the concept. Allowing analysts to quickly match components against known vulnerabilities in them, and then determine the resulting level of cyber risk is absolutely critical."
—Walter Haydock

Williams says SBOMs are not really fit for human consumption. Instead, IR teams should be notified of their content through things like automatic notifications, alerts, and tickets that are based on a policy engine that's tuned to SBOM information and which monitors their open source tracking system.

"SBOMs should really be thought of as a machine-readable format used to communicate between systems like a build pipeline and an open source tracking system."
—Jeff Williams

Ideally, the IR team should be able to just type in a system name and get a database view of all libraries in use or do a global search for systems affected by a CVE, Willams says.

Unfortunately, as robust as the tooling is for SBOM generation and quality checking, Williams and Haydock agree that off-the-shelf options aren’t quite there yet when it comes to IR tooling integration, but they both expect to see the market picking up steam soon and likely there are IR teams building what they need in the interim.

"There are a few systems that will consume SBOMs, but very little tooling that would give IR teams/SOC analysts the information they need quickly. There are surely teams building ChatGPT style interfaces that would allow analysts to quickly get their questions answered."
—Jeff Williams

[ Learn why you need an SBOM, more | Get a free SBOM and software risk analysis ]

Article Link: How to operationalize SBOMs for incident response