Easy Win – Procurement
A simple request to inspect Security Development Lifecycle (SDL) artifacts, such as the threat model and fuzz testing plan and results, will tell you if the SDL is more than a dream put down on paper. (In the early 2010’s it was more aspirational than reality)
A Software Bill of Materials (SBOM) will provide another helpful and easy way to evaluate the security of the solutions under consideration and the likelihood of future support in at least three ways.
- Does A SBOM Exist? Similar to the SDL artifacts, if it is not easily produced it is a red flag that the vendor doesn’t understand and manage their software supply chain.
- Evaluate The Software In The SBOM. Are the software components on a currently supported and fully patched versions? Are there software components that have proven to be rife with security problems or other issues of concern? This is admittedly harder than Step 1.
- Look at the SBOM from 1 year ago, and if possible 2 years ago. Ask for maintenance releases over that same time period. Is the product being updated to contain supported and fully patched versions? Is the information on the software component updates included in the maintenance release documentation.
Much like the SDL, it will be simple to qualitatively evaluate this aspect of the ICS vendor’s process and attention to the software security supply chain issue.
A Moderate Workload Win – Am I Vulnerable To This High Profile Threat?
The SolarWinds hack has demonstrated to many ICS asset owners that they don’t know what software is in their systems. Eric Byres of aDolus recently told me he is still encountering asset owners who have just learned they had SolarWinds running behind the scenes as part of an integrated solution.
When a high profile, or even more importantly a high risk, threat becomes known a SBOM can ease the process of finding out if you have the associated vulnerable software or firmware in your system.
This will require getting a current SBOM from multiple vendors or asking the vendors to search their SBOM. In a perfect world the vendor would proactively notify customers if their solution had the vulnerable software. Most asset owners have a number of vendor systems in their OT environment, and this will entail either repetitively getting the SBOM for each high risk threat. Alternately they can try to maintain a current SBOM for all software in the OT environment. The preferred solution will be based on how many high risk or high profile threats you envision occurring in a year.
Note … high profile is a real world issue. There are many times when a high profile vulnerability cannot be exploited outside the OT zone, and if the adversary is inside the OT zone the remediation of the vulnerability would achieve minor risk reduction. Even with this reality, executive management often will not accept an answer that we don’t know and it doesn’t matter from a risk perspective. They will want to be able to answer they have evaluated their environment and applied the remediation to a high profile threat.
The Hard Slog and Hard Win … Proactively Using SBOMs
SBOM proponents are correct that this is needed information to keep a cyber asset and system of cyber asset in a hardened state with known vulnerabilities addressed. And even though many hours and days have been spent getting SBOMs to a near reality and moving towards a requirement, this is a small fraction of the effort required to proactively use a set of SBOMs that comprise the software and firmware in an OT environment.
ICS vulnerability management in 2021 for the average security conscious ICS asset owner, asset owners that are doing something, is periodically patching Microsoft vulnerabilities and maybe applying an update from their primary ICS vendor. There are literally 1000’s of asset/missing patch pairs in the system.
The idea that SBOMs from more than five vendors and over 25 products, representing a “simple” ICS, will be maintained with a spreadsheet or other manual process is unrealistic. The idea that even the most security conscious asset owners will apply almost all of the missing patches even annually in the next three years is unrealistic. Two things will be needed to make proactive use of a SBOM feasible.
- SBOM Services, Or Products, To Manage Multiple SBOMs And Current Inventory
A large company with 100’s of ICS, like BP or Deere, could in theory build a system to do this on their own. For all the rest, and probably the BPs and Deeres, they will need a product or service, or multiple products and services, to deal with this information and related tasks. This market is now in the A and B round of funding and is one of the most interesting to track for product/service innovation and the business models that will sustain it.
Here are three of many possible product / service mixes:
- An existing vulnerability management solution, such as Tenable’s, Rapid7’s or one of the OT specific, could import SBOMs and provide missing patch information. This is the simplest model only, although this may not be a small thing, requiring someone to make sure SBOMs are imported into the vulnerability management solution as the SBOMs or assets are updated. This business model assumes the SBOM exists, and is unclear who pays for maintaining the current SBOM feed into the vulnerability management system.
- A third party collects and verifies, or creates, SBOMs and offers multi-vendor SBOM service on demand for asset owners. The asset owner’s asset management or vulnerability management system, depending on product architecture and process, would query the third party with their asset list and get any updated SBOMs. The asset owner would pay for this service.
- ICS vendors work with a third party to provide their SBOMs to asset owners. The vendor could provide their SBOM and have it verified by the third party for every version and maintenance release or service pack. Who would pay for this? Is this something a vendor like Emerson or Honeywell pays for and allows their customers to access? Or does the third party get their money solely from the asset owners?
In the second and third models the third party would need to cover all or almost all of the OT asset inventory to be worthwhile. This should make some of the early support and scaling interesting as it was for protocol and ICS support early in the detection space. There are many more business models that are likely to be tried.
- Risk Based Guidance On Prioritized Patching
Actionable information is key. Providing a list of 1000’s, 10K, 100K or more of asset/missing patch pairs, that is growing every month, is not helpful. Patch everything and often is not helpful. Asset owners need to understand what security patches should be prioritized. What security patches will result in the most risk reduction?
We are seeing risk metrics being added to the visibility and detection products, and they need to be in this addition or separate offering from the start. It would be a failure if the main benefit of this product or service is to quantify the number of missing patches in an ICS. I know of no one in the space that contends this number is not large.