Hope, 1 Step Backwards, and Business Models
Hope
The concept and benefits of a software bill of materials (SBOM) is simple to understand. A SBOM is a list of all software in an application or cyber asset.
Vendors need to create and maintain a SBOM to have any chance of credibly supporting their product over time. Many vendors have a SBOM, and some of those vendors actually track and update the software in the SBOM. The updates can be to address security vulnerabilities, but also to fix non-security related bugs and to keep the software components on a supported version.
Asset owners require a SBOM as part of their asset inventory to be able to know if a vulnerability affects their system. The CoDeSys runtime vulnerabilities are one of my favorite examples. This runtime is used in 100’s of different models of PLCs, but when ICS-CERT publishes a vulnerability advisory on CoDeSys it does not include the PLC’s that rely on the CoDeSys runtime as affected products.
A tiny percentage of those PLC vendors update CoDeSys in their build and put out an advisory. Almost all of the PLC vendors don’t update the CoDeSys component, because this requires resources to develop and test, and they don’t notify their customers. The same is true of ICS protocol stacks, as well as common libraries used in OT and IT.
The hope is that the US NTIA led effort to promote a common SBOM format, facilitate SBOM proof of concept projects in various sectors, and generally educate the stakeholders on the need and use of SBOMs is gaining traction. There are whispers that SBOMs will be part of the Biden administration’s efforts to deal with supply chain security issues.
Much like the discussion at the S4x20 panel led by NTIA’s Allen Friedman, the real question is what will asset owners do if SBOMs exist for OT systems?
1 Step Backwards
SBOMs are information. Information that can be used to attack or defend a system. Think of the Shodan tool that scans the Internet and creates a database that can be queried by anyone with an account. Shodan can help an asset owner identify Internet accessible OT devices that need to be removed or protected. Shodan can also help an attacker identify vulnerable OT devices that are Internet accessible. Once Shodan became available, it initially made the attacker’s job easier because they were using the information more and better than the defenders.
The same is likely to be true when SBOMs are introduced for OT applications and devices. An attacker with access to a SBOM will know if a PLC uses a vulnerable CoDeSys runtime or a compromised DNP3 protocol stack. It is fair to generally characterize the OT environment as infrequently and unevenly patched for known software components, while admitting some sectors and some individual asset owners do better.
Once SBOMs for OT are created and distributed, it’s likely that it will be a step backward for OT cyber risk. There will be more risk because attackers will now have information on more ways to attack deployed systems, and the attacks on unpatched vulnerabilities will likely be around for years unless you expect the OT patching trends to change dramatically.
For a normal system, this increased attacker knowledge of vulnerabilities would be of great concern. In OT it is much less so because of the PLC / Level 1 insecure by design issue. Applying all of the SBOM identified missing patches on 90%+ of these systems would not make the attacker’s job much more difficult. The attacker will typically use documented features and functions rather than bother “hacking” once inside the OT security perimeter. Of course this points out again the need to implement the increasingly available secure PLC with signed firmware and support for secure ICS protocols.
The SBOMs for the ~10% or less of the attack surface that either forms the security perimeter or is directly accessible through the security perimeter is extremely important. If the defenders don’t patch or otherwise address this issue faster than the attackers can leverage the information, which is likely, it will be a step backwards.
This does not mean the SBOM effort should not go forward. SBOMs are needed by those asset owners with the maturity and resources to use them. They should not be held hostage by those who choose to invest less in OT cyber security. Still we need to set expectations that SBOMs are unlikely to lower risk in at least the first 1 to 2 years they are available, and are in fact likely to increase risk.
Business Models
The collection, monitoring and use of SBOMs in OT is a large job. Asset owners are lamenting the burden of patching Microsoft vulnerabilities, and more often than not failing to meet their own set requirements of quarterly, semi-annual or even annual security patching. I don’t have hard numbers, but I have to imagine adding all of the software in a SBOM to the security patching program is at least a 5x increase in asset/patch combinations.
My prediction is that vendors will step into this issue and offer a service that will help:
- vendors create and maintain their SBOMs
- provide and update SBOMs for asset owners
- tell both vendors and asset owners when a new vulnerability affects an SBOM
In the OT world companies, such as aDolus and FiniteState, offer products and services to create SBOMs and identify vulnerabilities in the SBOM software components. (Note that the analysis these companies do goes beyond creating and evaluating the SBOM.) Others are sure to join as the supply chain and SBOM get more attention. The question is who pays for what. Three of the many possible business models include:
- Vendor Pays For SBOM Service: The vendor integrates the SBOM Service into its security development lifecycle (SDL). The vendor can buy a license so that approved asset owners can access the SBOM Service. The SBOM Service would provide a SBOM for each build and information on all known vulnerabilities in the SBOM. This model would work best for vendors that deliver a whole system such as Emerson Ovation or Honeywell Experion.
- Asset Owner Pays For SBOM Service: Today most vendors are not providing SBOMs. If an asset owner wants to get a SBOM, they would have to provide the product and pay to have the SBOM created, maintained and monitored for vulnerabilities. The SBOM Service vendor may agree to add it to their library at no cost for future annual recurring revenue. Even if the vendor agreed to provide the asset for the SBOM Service to create the SBOM, the vendor may not be willing to fund the SBOM Service for a large and unknown set of end users. This would be more likely in cases where the vendor does not know who gets their product as it is sold and deployed by integrators.
- Hybrid Model Where Vendor And Asset Owner Pay For The SBOM Service: There are likely many combinations of the two above models.
One of the challenges for this SBOM Service business is asset owners often modify the standard install of the cyber assets. This is often done for legitimate project reasons, and it also occurs due to poor change control. When we go in and audit systems it’s not unusual to see a common cyber asset, such as an HMI / Operator Station, with different software installed in different computers. This can be different versions of the same software or sometimes additional software that got installed on only some of the Operator Stations. The SBOM Service business is not going to be able to help with this.
One last thought, the SBOM Service will need to communicate with the vulnerability management portion of the asset management solution. This integration will be key. Either the SBOM Service will need to feed into the vulnerability management module, or the SBOM Service will need to become the vulnerability management module and communicate with the asset inventory module.