A Flurry of Regulatory Action and the Need for SBOMs

Executive Order 14028 on Improving the Nation's Cybersecurity was issued in May of 2021 and provided a roadmap for a series of regulatory initiatives that government agencies (and anyone doing business with them) should prepare for. Recently we’ve seen the rollout of two important mandates:

• OMB Memorandum M-22-18 dated Sept. 14, 2022 establishes requirements for “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.”
• CISA’s Binding Operational Directive 23-01 mandates federal agencies to enhance efforts to detect vulnerabilities and manage cybersecurity across their networks.

Ron Brash and I provided commentary regarding this latest regulatory push to a number of media outlets, and I thought I’d summarize some of our observations here in the blog.

Will the OMB Memorandum be effective — more effective than previous initiatives?

Obviously there is no silver bullet that will stop the relentless attacks from nation-state and criminal actors cold. But this OMB memorandum does provide the tools to respond to these attacks. 

The challenge that OT defenders have been facing for the past 20 years is that they are in the dark as to what software is actually in the products they are using. The bad guys are not under similar limitations: they can reverse engineer any product they want without any enforceable legal consequences. 

These requirements provide transparency between users and suppliers. It is not unlike the laws requiring that additives to food be published. Until these were passed in the early 1900s people were sickened regularly by tainted foods.

What is the bigger threat: ransomware or supply chain attacks?

Ransomware and supply chain attacks are not mutually exclusive. Ransomware is the payload; the supply chain is the attack vector. On a panel hosted by ISSSource last year, I signed off with the statement “my biggest worry: someone will combine professional ransomware with a software supply chain attack to create a truly massive ransomware attack.” Days later, the supply chain attack on Kaseya saw my fears come true.

The most ominous thing about a supply chain attack is its reach. Look at SolarWinds: one company compromised, 18,000 victims affected. Whether the attacker’s objective is a big payout (in the case of ransomware), espionage (spyware), or destruction (really sinister malware), they can multiply their success by targeting the supply chain. So I believe that supply chain attacks are more dangerous because of their potential to spread malicious payloads. Today the most common payload is ransomware, but if you look at Pipedream — malware that allows attackers to infiltrate and move between both IT or OT environments — things get a lot scarier. This destructive malware can disrupt critical devices and functions and cause serious physical damage.

What elements must SBOMs include to ensure agencies know which vulnerabilities exist? 

Depending on who you ask, you’ll get different answers regarding the necessary elements of an SBOM and if they should include vulnerabilities. The current SBOM standard advanced by CISA does not include vulnerability information; it is simply a comprehensive, nested list of ingredients. Vulnerability information — including whether or not a vulnerability is exploitable — is communicated via a separate companion document called VEX (Vulnerability Exploitability eXchange).

There are obvious and compelling reasons for maintaining a “church-and-state” separation between SBOMs and vulnerabilities. The SBOM for a given software package is fixed and doesn’t change. But vulnerabilities tied to the components within are in constant flux as researchers (and adversaries) expose new ones. It’s unlikely software suppliers could issue new SBOMs every time new vulnerabilities are reported. It’s too much effort and would create a versioning nightmare.

How practical are these initiatives on the ground — both for federal agencies and for critical infrastructure operators?

With SBOMs providing definitive lists of ingredients and VEX documents detailing which ingredients contain vulnerabilities (and if they are exploitable), we have the fundamental building blocks to secure the software supply chain. By keeping the model simple and modular, it’s workable.

We’ve already seen these tools prove their effectiveness in real world scenarios such as the Log4j crisis, where one of our clients was able to respond in hours rather than days or weeks thanks to SBOMs and VEX.

Consider also that these requirements don’t just apply to brand new software: they include legacy products if any significant modifications are made. And it isn’t just open source software that is the focus — it is all software. Finally (and perhaps most importantly for the OT market), suppliers can't just put software in an embedded device (like an industrial computer) and dodge the requirements. In fact, all sensors, controllers, and network devices need to follow these guidelines.

Is it difficult for agencies to comply with the NIST Guidance when using 3rd-party software? Are these software providers aware of the vulnerabilities they often push to end users?

Sadly, software providers are frequently clueless about the 3rd, 4th, and 5th-party components embedded in their products. Developers often embed code of shady provenance — some of it open source of unknown authorship. When the products are shipped to customers, the vulnerabilities buried in a deeply nested component set off no alarm bells because nobody knows the component is present.

SBOMs produced from binaries (i.e., executable files rather than source code) can reveal all the components in a software package — even ones the vendors didn’t know about or document. aDolus uses this technique to produce SBOMs and our customers can create an SBOM with a single click. They find it not only feasible, but also easy to assess risk posed by third-party software.

How are federal agencies and industry responding to all the recent legislation?

I’m very encouraged to see the momentum building around SBOMs and supply chain security. Rather than moaning or resisting, industry as a whole seems to be embracing these requirements. There is growing appreciation that well-resourced, nationstate adversaries are focusing on our software supply chain’s soft underbelly. And this awareness is driving a sense of urgency among those working in critical infrastructure.

Is there still more work to do?

I’m afraid so. More work needs to be done in the smaller organizations — local water utilities, municipal or rural electric utilities, small manufacturing, etc. These folks usually don’t have the in-house cybersecurity staff to properly respond to the new mandates. They will need funding support of course, plus tools to automate all the activities they can to reduce the burden on limited resources.

The other area to be worked on is building the infrastructure to securely distribute trusted SBOMs and VEX documents to the organizations that need them. No large critical infrastructure operator wants to have to download SBOMs from 100s or 1000s of suppliers. They also don’t want to have to sift through tens of thousands of SBOMs from a large supplier when they are using only a few products. So there is a lot of interest in services that can securely aggregate SBOMs from multiple suppliers and then tailor the feed to exactly the products that a facility has deployed. 

Interestingly, we can see a requirement to address this need by government agencies spelled out directly in Section III C.2. — “CISA, in consultation with GSA and OMB, will establish a program plan for a government-wide repository for software attestations and artifacts with appropriate mechanisms for information protection and sharing among Federal agencies.

Clearly CISA is being given marching orders to solve this for the government, while industry will look to private enterprise for a solution.