2023 is in the rearview mirror and 2024 is now well underway. I wanted to post my thoughts on some of the software supply chain trends we saw last year and how they will continue to shape the efforts of the cybersecurity community as we embark on 2024.
Unfortunately, software supply chain attacks delivering a malicious malware payload are still on the rise. They are growing at a rate of 1900% over the last 3 years according to Sonatype — and this trend makes total sense. Supply chain attacks have the potential to affect tens of thousands more victims versus a direct 1-on-1 attack. Bad guys know a good ROI when they see one.
Whether their objective is money (in the case of ransomware), espionage (spyware), or carnage (like Triton, Industroyer2, or Pipedream), attackers are now multiplying their success by targeting the supply chain. And all industries — especially organizations involved in providing and operating critical infrastructure — need to be prepared for these kinds of attacks.
Regulators in the US and Europe have taken notice of this emerging threat landscape and launched a barrage of legislation in response. My blog will outline the ways threat actors are exploiting the software supply chain and the evolving regulatory landscape as governments hasten to respond. But before getting into the details, I want to say a few words about terminology.
One challenge facing regulators and operators alike is a lack of consensus on what exactly constitutes a software supply chain attack. I thought the definition was pretty obvious until I discovered a surprising number of different opinions and a fantastic amount of confusion on the topic.
For example, take the attack on the French IT software monitoring company Centreon by the Russian Sandworm group. The French cyber agency ANSSI called it a “supply-chain attack” and compared it to SolarWinds/SunBurst. ENISA, on the other hand, said it is not one because attackers simply exploited existing vulnerabilities, as opposed to the SolarWinds case where attackers injected malware into a supplier system.
To me, that is splitting hairs. In both cases, the customers using the monitoring software trusted they were using secure and reliable software when they were not.
US government agencies have their own ways of characterizing these attacks.
Here is CISA’s software supply chain attack definition:
A software supply chain attack occurs when a cyber threat actor infiltrates a software vendor's network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer's data or system.
Unfortunately, it excludes attacks where the attackers don’t have to actually infiltrate a software vendor’s network. It overlooks instances where a vendor (or open source project), has made mistakes on their own that allow exploitation of their software (think either Centreon or the more famous Log4j vulnerability and Iran’s use of this vulnerability). And it doesn’t include cases where attackers simply contribute malicious code to an open-source project.
NIST, on the other hand, has a broader definition, which doesn’t require the infiltration of a software vendor’s network:
Attacks that allow the adversary to utilize implants or other vulnerabilities inserted prior to installation in order to infiltrate data, or manipulate information technology hardware, software, operating systems, peripherals (information technology products) or services at any point during the life cycle.
However this definition overlooks issues like theft of code signing keys (think Stuxnet).
Here’s the definition I propose to use (and feel free to argue with me in the comments section at the bottom):
Attacks that take advantage of the inherent trust between the participants in the software supply chain to target and exploit an end-user.
I like my definition because it focuses on the strategy of the attack rather than specific tactical infiltration mechanisms.
The use of the software supply chain as an attack vector by APT groups has increased. An ENISA study of attacks shows that at least 50% of those they studied were conducted by an APT group. The other 50% of attacks just couldn’t be attributed. And I’m currently unaware of any foreign threat actors that aren't using the supply chain as a vector — Iran, Russia, North Korea, and China have all made extensive use of this mechanism.
The Biden Administration's National Cybersecurity Strategy earlier this year recognized that the primary cybersecurity threat is from hostile nation states rather than run of the mill cybercriminals.
Supply chain attacks that are sponsored by state actors with advanced capabilities require a united front between government and industry to mount an effective defense. Significant regulatory initiatives are underway in both the US and Europe to address supply chain cybersecurity.
Unquestionably, there has been notable acceleration of regulatory and legislative initiatives in the US as a response to high-profile supply chain attacks and incidents. These feature two recurring highlights: the ability to provide SBOMs and the ability to quickly respond to emerging vulnerabilities.
US Regulatory Initiatives Addressing the Software Supply Chain
In the late 1980s, when Mikhail Gorbachev and Ronald Reagan were negotiating the Intermediate-Range Nuclear Forces Treaty, Reagan adopted the Russian proverb doveryai, no proveryai meaning “trust, but verify” as a core pillar of the negotiations. Reagan used the phrase to emphasize "the extensive verification procedures that would enable both sides to monitor compliance with the treaty.”
Note that there are guidelines for software developers and the open-source community to reduce the likelihood of a supplier’s development system being infiltrated, such as NIST SP 800-218 Secure Software Development Framework (SSDF) and NIST SP 800-161, but this blog is focused on OT owners and operators who must work with the software they are provided. Also, most of these guidelines read like standard security practices for preventing intrusion into any system, and their focus on development systems appears to be secondary.
Since the SBOM is likely your first point of verification in the Trust, but Verify paradigm, let’s dig into it and understand its strengths and weaknesses.
The SBOM is a very simple concept — it is a list of software ingredients contained in a software package. Think of it just like the ingredients list on the side of a can of tomato soup — yes, as a consumer what you want is mostly tomatoes, but what you get is a lot more. You want to know what the “extra stuff” is.
The Minimum Elements For a Software Bill of Materials (SBOM)
A formal record containing the details and supply chain relationships of various components used in building software.
If you look carefully at that soup, you’ll see something called thiamine mononitrate. Is that good for you? Is it bad for you? Frankly I don’t know — and the ingredients label isn’t going to tell me. It will only tell me that an ingredient is present.
Much like the can of soup ingredients list, an SBOM won’t identify the risk associated with the components in the software; it will just tell you what’s in there.
You’ll need to do your own analysis to identify risk.
To learn more about SBOMs, read our earlier post on NTIA Publishes Minimum Components of an SBOM.
There are multiple opportunities in the life cycle of a piece of software to generate its SBOM. NTIA requirements state SBOMs may be generated:
And in addition to deciding when to generate an SBOM, there is also the question of what method to use. SBOMs can be created by performing software composition analysis (SCA*) or they can be generated by binary composition analysis (BCA**), depending on what stage of the software development life cycle you’re at.
These different methods produce different SBOMs and they each have their strengths and weaknesses. Here are the advantages and disadvantages we see between the two methods:
| SBOMs Generated from Software Composition Analysis (SCA) | SBOMs Generated from Binary Composition Analysis (BCA) |
|
Early Vulnerability Detection
Incomplete Dependency Information
Increased False Positives
Limited Scope
|
Accurate Identification
No Source Code? No Problem
Tool Development Requires Expertise
|
* Note that the acronym SCA is also used for “source code analysis or “static code analysis”. Source code analysis refers to analyzing source code for quality, reliability, and security to identify defects and security vulnerabilities. It assesses code quality (e.g. number of lines of code, code complexity, etc.) and verifies compliance with code standards.
** The acronym BCA is also used for binary code analysis. Binary code analysis refers to looking at code largely for flaws (involving disassembly and review for bad behaviors). Binary composition analysis is a subset of binary code analysis that adds a focus on looking for components and dependencies in software.
That’s probably not the right question. Think of differently produced SBOMs like differently produced medical images. Ultrasounds, X-rays, CT scans, and MRIs all produce views of the inside of the body, but each shows different things. It would be a poor doctor who examined only MRIs and ignored the other data sources when determining the patient’s diagnosis.
Rather, like a skilled doctor who uses all the data available, we think it is wise to understand the different SBOM production formats and leverage all the information rather than dismissing one SBOM type in favor of another.
Bottom line: there isn’t — and there won’t be for the foreseeable future — a single, canonical SBOM.
Let’s say you’ve got an SBOM (maybe one supplied by your vendor, maybe one you generated using FACT). You’ve now got your list of ingredients, but as I mentioned earlier, you still need to do some analysis to identify risk.
One of the primary risk factors that industry is most concerned about is:
Does this software package have any vulnerabilities?
Most SBOMs* won’t (and IMHO shouldn’t) tell you that, but if you are using a platform like FACT to continuously scan for vulnerabilities, you can associate newly published vulnerabilities with the components in your SBOM. Ultimately what most end users want is a better understanding of the vulnerabilities in the software they use. Thus, I think two companion documents are likely going to be important and useful to the end user in the next year or two:
Vulnerability Disclosure Reports (VDRs) are an attestation of all vulnerabilities affecting a product, or its dependencies, along with an analysis of the impact. VDRs may come from a software supplier or a third party. (Read more about these in this blog post.)
A Vulnerability Exploitability eXchange (VEX) document is a document that simplifies the vulnerability intelligence found within a product, or many products (i.e., product families), to help end users quickly focus on the vulnerabilities that are most critical. Generally these are the vulnerabilities that are actually exploitable in a product — with particular attention to those vulnerabilities that are being actively exploited in the wild. VEX documents are great for a user who is trying to quickly find out if their product is affected by a high profile vulnerability, such as CVE-2021-44228 (Log4j). VEX documents are generally created by suppliers who have detailed insight into how their applications are actually using specific components.
These SBOM companion documents help make Vulnerability Management (VM) more efficient, more successful, and more easily automated for all links in the software supply chain.
OT Product Supplier
If you are a product supplier, you can determine if the vulnerability in question is actually exploitable in your product. You can then issue machine-readable VEX and VDR documents to efficiently communicate to your customers if any patching or other mitigations are necessary.
OT Asset Owner
If you are an asset owner, you can contact your supplier to see if your product is actually affected and check for recommended updates or mitigations. (And if you are lucky, they can provide a VEX or VDR document to help automate your response.) You can do further risk analysis based on the product's function in your operations.
A good example of VEX documents in action is the Log4j fiasco from 2021. You can read all about how we helped our customers respond to this critical vulnerability here.
* CycloneDX SBOMs can include vulnerabilities, but I am not a fan of this. SBOMs were designed to be static once produced for a piece of software, while vulnerabilities can change daily. VDRs and VEX documents were designed from the start to be a far better document for sharing highly transient information like vulnerabilities.
Vulnerabilities are just one risk factor you need to consider. Malware, counterfeit software, improperly signed certificates, prohibited vendors… there are plenty of risks you should be on guard against to secure your software supply chain in 2024 and beyond. We’ll be publishing more blogs on how SBOMS help address these risks in the coming months.