At ReliabilityFirst’s monthly Technical Talk with RF on Monday, cybersecurity consultant Tom Alrich said a software bill of materials (SBOM) can be a useful tool for utilities to meet their obligations under NERC’s reliability standards, particularly CIP-013-2 (Cybersecurity — supply chain risk management).
Introducing the topic, Alrich noted that the SBOM idea has been gaining traction after being included in President Biden’s Executive Order 14028 last May. (See Biden Directs Federal Cybersecurity Overhaul.) But while the concept has gained some recognition in the public sphere, Alrich said many outside the cybersecurity industry don’t fully understand what it is, joking that he was “sure your children have all asked you that question at one time or another.”
“You might tell them that if they had a software bill of materials for each of the video games that they run, they might know which games contain Log4j,” Alrich said, referring to the vulnerability in an Apache open-source software library that was discovered last year and is thought to impact millions of devices and applications worldwide. (See DHS Launches Cyber Review Board.) “If a game does contain Log4j, they might not want to use it until the developer provides a patch.”
Hacked Software Can Spread Quickly
SBOMs are intended to address potential vulnerabilities associated with the reality of modern software development: applications increasingly are not individually coded from the ground up, but largely built from bits of code available in public or private repositories like Github. Log4j, for example, is a freely available component that programmers can insert into their code; the resulting app can log errors and normal system processes, a vital feature for software in a wide range of industries.
These components are often copied and pasted with few changes: Alrich estimated that “in some software products, more than 90% of the code is components,” and 90% of those components are open source, with most of a modern programmer’s work being to “tie components together.” This means that if an attacker manages to slip malicious code into the source, it can spread quickly to myriad platforms, similar to the 2020 hack of the SolarWinds Orion network management software (though that incident involved compromising a company’s official update channel rather than public code repositories).
An SBOM helps to mitigate this issue by providing customers a machine-readable list of software components in a particular product. Under Biden’s executive order, all software developers working for federal agencies will be required to produce SBOMs starting in August; Alrich predicted that the lists will “become a quasi-requirement for all software” as more organizations become aware of the risks of open-source components.
Providing an SBOM does not mitigate any vulnerabilities in a software product by itself, but because it is machine-readable, it can greatly speed up the hunt for compromised components. Alrich provided a diagram showing one way to use an SBOM, in which automated software checks each component against the National Vulnerability Database or other lists of potentially dangerous software.
The resulting list is then checked against a vulnerability exploitability exchange (VEX) to determine which flaws are actually exploitable. As Alrich explained, most vulnerabilities cannot actually be exploited in a finished piece of software, so this step can greatly cut down on a cybersecurity team’s time and effort.
Where the SBOM helps with CIP-013 compliance is in allowing utilities to independently “identify, assess and mitigate” supply chain risks as the standard requires. Without an SBOM, utilities must rely on their suppliers to monitor for potential risks and give them timely information; with the list a utility can do this itself.
“SBOMs are a tool; they don’t mitigate risk themselves, but they’re the indispensable tool for doing that,” Alrich said.
More Changes to Align Release Schedule
Also in Monday’s webinar, ReliabilityFirst’s manager for risk analysis and mitigation Anthony Jablonski provided an update on the status of the ERO Enterprise’s Align software platform and Secure Evidence Locker.
The remaining steps in the most recent version of the Align project timeline | ReliabilityFirst
Currently NERC and the regional entities are still rolling out Release 3 of the platform, which began in December with a staggered schedule. SERC and ReliabilityFirst began their implementation in February and March, respectively; all other entities will start their adoption in April.
Release 3 was originally planned to be the last stage in the platform’s introduction, but NERC decided to split the final release in two to reduce the complexity of the task. Jablonski said on Monday that the new Release 4, originally set to roll out in the fourth quarter, has been split again. The first part will now roll out in the second quarter, comprising audit and scheduling functionality; the second, which the organization has dubbed “Release 4.5,” will be introduced in the fourth quarter, covering inherent risk assessments and compliance oversight plans.
