Awareness and activity increased in 2022 on OT vulnerability management, and it will likely increase even more in 2023. OT detection products’ key selling proposition is asset inventory, vuln management and increasingly mapping this information to risk scores. Same for the Tenable “scanning” solution. Same for OT asset management solutions. 

The amount of software and vulnerabilities in a typical OT environment is large and requires automation to be handled effectively. If we add in the software components that make up the software / firmware the numbers explode. The software bill of material (SBOM) proponents have recognized this and are working on a variety of machine readable formats to automate the input of this information. Good work. Important work. Work that OT asset owners will not be ready to use for at least 3 – 5 years.

OT Vulnerability Management in 2023

The process of vulnerability management in OT is little changed over the last decade. More asset owners are attempting to patch every year, but the process remains the same for the computers and PLCs/controllers that monitor and control the physical system.

1.     The ICS vendor monitors a small amount of software/firmware for security patches. This is typically the Microsoft software and the ICS application software. Sometimes it will include a few applications, for example Adobe Acrobat. 

2.     After a Microsoft patch Tuesday the ICS vendor will look at the issued security patches and determine if they are applicable, and if applicable, if they can be applied without affecting the integrity and availability of the ICS. Is the patch compatible with the ICS?

3.     The vendor updates their patch compatibility document and makes it available to customers, typically customers with a support contract. Sometimes it is emailed out as a bulletin, sometimes it is sent as media via snail mail, and in most cases it is available for download from the support site as a spreadsheet or document.

4.     The asset owner takes this patch compatibility bulletin and plans to patch their system per their patching interval and process. Many asset owners pay the vendor or an integrator to do this patching for them periodically.

Importantly, steps 3 and 4 lack helpful automation.

Simple, Best, First Need (Early Win From SBOM Efforts That Don’t Require SBOMs)

The answer: ICS vendor compatibility feeds delivered in a machine readable format for automated import into vulnerability management.

I intentionally decided to stay out of the SBOM protocol wars. There are a number of Vulnerability Disclosure Report (VDR) formats, such as NIST and CycloneDX, and NIST will have a meeting in late January to attempt to standardize on a single VDR format. (ht: Dick Brooks) CSAF also has a capability to provide this information.

A great starting point would be for large ICS vendors, i.e. Emerson, Honeywell, Rockwell Automation, Schneider Electric …, to agree they will provide their ICS patching applicability and compatibility information in one of these VDR formats. This could be done under the auspices of ISA Global Cybersecurity Alliance, another industry group, or one or more vendors stepping up and taking the lead.

Again, this has nothing to do with SBOMs. It is taking vendor information that exists and is being provided to and used by asset owners for years now, and putting it into a ‘standard’ machine readable format. It does help pave the way for use of SBOMs if/when they become available.

The OT products that include vulnerability management, i.e. Armis, Claroty, Dragos, Langner, Nozomi, …, then would need to import these machine readable VDR, and use them to provide asset owner customers with what to patch when guidance.

Automate what exists and is being used today for the immediate win and a pathway to more robust capabilities.

Another Thought

One thing I’ve always been baffled by is the lack of integration between vulnerability management solutions and patching solutions. They don’t have to be a single product, but I’d like my vulnerability management solution to provide a machine readable format of the patching decisions made to the system that will do the patching. (Note this doesn’t mean the patching system applies the patches mindlessly. It still follows the change management procedures.)

Perhaps this is a solved issue in IT, but everyone I ask in OT doesn’t do this. It is at best a report or an export of a proprietary file format.