Charit Misra

Software Bill of Materials (SBOM) Importance for ICS/OT Environments: Key Reasons and Manual Analysis

Supply Chain risk management is important. It helps assess inherent vulnerabilities that might be intentionally or mistakenly added to softwares/ binaries/ firmwares. For IACS it is even more critical. The safety and operations of the environment heavily depend on them. For instance, we need engineering applications to manage controllers. We need controllers to manage our physical processes. We need firmware to run those controllers. These vulnerabilities cannot be easily detected. We as an asset owner, system integrators, or product suppliers, must devise the process of SBOM which fits our purpose.

The Software Bill of Materials (SBOM) is crucial in Industrial Control Systems (ICS) and Operational Technology (OT) environments, aiding in vulnerability monitoring and compliance. Manual creation of an SBOM becomes important when automated tools are not available, ensuring security, compliance, and resilience against cyber threats.

In Industrial Control Systems (ICS) and Operational Technology (OT), minimizing the safety, operational and cyber security risks is paramount. One of the key components in ensuring this is supply chain risk management. One core element is Software Bill of Materials (SBOM) analysis. To put it simply SBOM is a detailed inventory of the components from your own IACS environments. It is much like an a detailed list for softwares/libraries. These components are both could be both open-source and proprietary which makes up a software system. This transparency would allows organizations to capture, assess, monitor and remediate vulnerabilities that could jeopardize the IACS.

What happens when an SBOM is not available for OT equipment? What happens if the asset owners or system integrator do not prepare one? This is where manual generation comes in and can assist to perform due diligence. Let’s explore why SBOM is vital in IACS environments. We will also learn how to manually create one when automated tools are not available.

Why SBOM is Important for ICS/OT

ICS/OT environments are increasingly becoming targets of the cyber attacks. These environments are not just made up of IT systems. They also include operational components like valves, sensors, and controllers and each of these have software or firmware. When attackers target these systems, they are often trying to exploit vulnerabilities in the software supply chain. An SBOM is essential, it helps in identifying software components, enabling faster patching of vulnerabilities and strengthening overall cybersecurity maturity.

Here are the key reasons why SBOM analysis is critical for these environments:

  • Visibility and Transparency: An SBOM provides detailed insight into all the software components running within an OT environment. Knowing what software versions are deployed is the first step in identifying security vulnerabilities.
  • Compliance: Regulatory bodies worldwide are increasingly mandating the use of SBOMs. For example, some government entities requires SBOMs as part of federal procurement processes for critical infrastructure software. Look at the reference table at the end for
  • Risk Mitigation: By having a continuously updated SBOM, security teams can take proactive steps and be pro-active. They can mitigate vulnerabilities before adversaries exploits them. This is particularly important in critical facilities such where the consequences of a cyber attack be catastrophic.

How to Perform SBOM Analysis Manually for OT Equipment

When you don’t have an automated SBOM generation tool, manual creation is still possible. Here’s a step-by-step guide to generating an SBOM for an OT device:

1. Identify the SuC

Start by identifying the specific OT equipment you need an SBOM for. Let’s assume you are dealing with a Programmable Logic Controller (PLC) commonly found in every industrial settings.

2. List All Software Components

The next step is to identify and list all software components associated with the PLC. This includes:

  • Firmware: Check the firmware version of the PLC. Access the manufacturer’s website or documentation to get details about what’s included in this firmware.
  • Installed Software: If the PLC runs any additional software applications, note their versions and configurations.
  • Third-Party Libraries: Many OT devices include third-party libraries, often open-source, which need to be accounted for. Examine system files to locate the presence of these libraries.

3. Identify Dependencies

An essential part of any SBOM is identifying the dependencies between software components. You’ll need to determine:

  • Direct Dependencies: These are software packages directly called or used by the device’s main application.
  • Transitive Dependencies: These are the libraries that are indirectly used by the software.

For example, the firmware might use a specific cryptography library, which in turn depends on lower-level encryption standards. All of these need to be documented in the SBOM.

4. Collect Version and Licensing Information

After identifying the software components, gather version numbers and licensing information. For proprietary software, check with the vendor for the exact version. For open-source libraries, use tools like package.json or requirements.txt if the device is Linux-based.

Additionally, capture licensing details as different components may have varying restrictions that need to be managed.

5. MapPing Data to Known Vulnerabilities

Once you have all the software components and versions, the next step is to map them to known vulnerabilities. This can be done using databases such as:

  • National Vulnerability Database (NVD)
  • Common Vulnerabilities and Exposures (CVE) Lists

This will allow you to determine if any component has known vulnerabilities that require attention.

6. Create the SBOM Document

Now, compile all the collected data into a structured format. The common formats used for SBOMs include:

  • SPDX: An ISO standard that supports the sharing of metadata about software components.
  • CycloneDX: Popular in application security and supply chain component analysis.
  • SWID: Another ISO standard backed by NIST, used for tagging software products.

Your SBOM document at minimum should include:

  • Component name and supplier
  • Version number
  • License type
  • Vulnerability status
  • Date of SBOM creation

7. Maintain and Update the SBOM

An SBOM is not a one-time task, ICS/OT environments change regularly with software updates, patches, and new installations and updated periodically.

Standards and Frameworks

  • NIS2-009 — Manage Supply Chain Security Risks
  • NIST CSF (Protect) — ID.BE-1
  • NIST 800-53 Rev5 — 3.20 SUPPLY CHAIN RISK MANAGEMENT
  • NIST 800-82 Rev3 — 4.2.1 Supply Chain Risk Management
  • NERC CIP — CIP-013-2 Cyber Security – Supply Chain Risk Management
  • ISO 27001:2022 Annex A Control 5.19

Conclusion

The need for cybersecurity in ICS/OT environments is growing as attacks become more sophisticated and frequent. Having an actionable SBOM is essential. It is one of the best ways to mitigate the risk of vulnerabilities in the software supply chain. When automated tools are not available, you can manually generate an SBOM. This method can be highly effective if done methodically. Following these steps will help ensure that your OT equipment remains secure, compliant, and resilient to cyber threats.

By taking control of your SBOM management, you’re not just complying with regulations. You are proactively securing your critical infrastructure from potentially devastating attacks.

References

Discover more from Hard Hat Security

Subscribe to get the latest posts sent to your email.

Leave a comment