Easy, Moderate and Hard SBOM Wins
Dale Peterson
ICS Security Catalyst, Founder of S4 Events, Consultant, Speaker, Podcaster, Get my newsletter friday.dale-peterson.com/signup
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.
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.
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:
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.
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.
R&D Group Manager | ICS Security Expert at JFrog
3 年Excellent article Dale, as already mentioned here I strongly agree that one of the critical goals should be to improve the 'Vulnerability Exploitability eXchange (VEX)'?process. The ability to provide the relevant vulnerabilities at high risk that we will need to address. This capability is important because indeed most vulnerabilities will not be applicable with certainty in the context of the device itself, and therefore should be given low priority in the risk management process Several vendors are already examining this process, and even performing the analysis on the binary itself. This analysis can provide great flexibility for the vendor itself (the manufacturer) and also for the asset owners who can scan the binaries themselves and combine the result into a vulnerabilities management tool.
Good article and good followup points by Richard (Dick) Brooks, Tom Alrich, Eric, etc. I would add that a quantitative risk analysis could/should be added per Hubbard/Seiersen or FAIR Institue. Adding the automated translation of SBOM to vulnerabilities to risk/dollar curves is technically easy. The hard part is the valuation into the quantitative risk analysis but I’d argue that should happen independently anyway. And there are 3rd party services already helping with this.
Leader of OWASP SBOM Forum and Vulnerability Database Working Group projects; consultant on NERC CIP compliance in the cloud and vulnerability management
3 年Great post, Dale! I've thought a lot about what services are necessary for SBOMs to be both widely produced and widely distributed, and you've hit the nail on the head - I'd say each of these is needed. But you need to keep in mind that using spreadsheets is out of the question when you're managing SBOM data. The average software product has 135 components, and plenty of products have thousands (or tens of thousands) of components. There's no way this can be done, except in a machine-readable format. Of course, the three major SBOM formats - SPDX, CycloneDX and SWID - are all machine readable (and there are tools to conver them back and forth). Regarding your third service, producing SBOMs in one of the 3 formats is already easy for many suppliers, since it's almost a checkbox item in modern development tools. However, I agree that a lot of suppliers won't consider SBOMs to be part of their core mission, and they'll be glad to engage a third party to help them make decisions on production and distribution. There are other important considerations, like the VEX documents that Eric and Tony refer to. Suppliers will need to produce these as well - and they'll feel compelled to, for reasons that I'd be glad to discuss with you.
Very interesting article. SBOM + C-SCRM = an effective, proactive, solution to prevent bad software from being installed from the start. Also, Dependency Track from OWASP CycloneDX SBOM Standard provides customers with an "open source" solution to track software component vulnerabilities, and it's already SBOM aware. I do think Dale Peterson may be making some assumptions with regard to the difficulty of using SBOM's proactively in his hard slog analysis; Consider this a formal offer to show you just how easy it is to implement a proactive SBOM + C-SCRM solution today.
Technology Expert & Board Member
3 年Great blog Dale, continuous product assessment based on a Digital-Twin mindset that extracts full SBOM information into vulnerability management system is a key capability that every company should have!