ICS-Patch: What To Patch When?

I've been doing my best to push back on the idea that applying all or even most security patches on a monthly or quarterly basis to an ICS makes sense as part of some 'cyber hygiene'. In most cases it is providing minimal risk reduction for a large and ongoing effort. Back as far as February 2016 I wrote an article on a three-tiered patching approach based solely on exposure of the cyber asset (see slide 19).

Then at S4x19 Art Manion and the team at CERT/CC proposed a Never - Next - Now patching approach that used a decision tree rather than artificially precise numerical calculations. They refined it, and presented it again at S4x20, and now have a white paper describing what they call the SSVC in detail. While the decision tree approach and some of the decision factors are spot on, it needs modification for ICS. So here I want to unveil for your consideration version 0.5 of what I'm tentatively calling ICS-Patch to answer the what to patch when in your ICS question.

There are three criteria for success in a methodology to answer this question.

1. The methodology must greatly reduce the security patching burden.
2. The decision on what to patch when should be based on the risk reduction achieved in applying the patch.
3. The methodology must be automated so the asset owner does not need to take time to evaluate each patch. The answer to "do I apply a patch to this cyber asset" pops out of ICS-Patch as ASAP, Scheduled or Defer.

The last criterion limits what decision points can be included in the decision tree. For example, the SSVC had a decision point of Exploitation, the degree in which Exploitation is occurring in the wild. There currently is no generally available feed that has this information, so it could not be automatically included in the ICS-Patch decision.

In fact, all but one of the decision points would come from the ICS Asset Inventory and be factors that rarely change for each cyber asset (Exposure, Safety Impact, Security Posture Impact and Process Impact). The only non asset inventory stored field is Technical Impact, and this can be pulled from one of many CVSS feeds.

The decision trees below show that just like the February 2016 simpler approach, Exposure is the most important factor in what to patch when. The next most important factor in ICS-Patch is Security Posture Change. This is related to the insecure by design concept that I've been harping on since 2012. Think of the PLC that allows unauthenticated firmware or logic upload. Applying almost any patch on this PLC will have trivial risk reduction.

Version 0.5 of the ICS-Patch paper defines the decision points, where the information would come from, and what the output of ASAP, Scheduled and Defer mean for an asset owner. It also identifies the differences between ICS-Patch and the SSVC and the reason for the differences. The version number of 0.5 should indicate that this is not viewed as perfection and comments are appreciated as long as they are geared to support the three criteria above.

The decision trees diagrams, shown below, are split into three, for readability, based on the three Exposure levels that are the first branch of the tree.

Small: The cyber asset is in a highly isolated and controlled zone. There are no connections from this cyber asset’s zone to or from a zone with lower trust.

Indirect: The cyber asset has no direct access to a zone with lower trust, but other cyber assets in this cyber asset’s zone are accessible to or from a zone with lower trust. (Note: most ICS cyber assets will fall into this Exposure level)

Direct: The cyber asset is directly accessible to or from a zone with lower trust.

Implementation Realities

The ICS Asset Inventory and Detection product segments are focused on enhancing their products in three main areas due to customer demand: compliance tracking, risk metrics, and vulnerability management. ICS-Patch addresses the last two. Vulnerability management in a straightforward way and risk metrics because the early demos I'm seeing highly weight, overly in my judgment, security patch status in coming up with a numerical risk score for the cyber asset and zone.

Implementation is a straightforward set of small steps.

Preparation: The asset inventory tool needs to have a field for Exposure, Security Posture Change, Safety Impact and Process Impact for each asset, and this information needs to be entered. Again this is likely to be a one time / rarely changes entry.

Step 1: Is to use the vulnerability management capability of the asset inventory tool to identify missing patches on ICS cyber assets. Note that these asset inventories are likely to vary in detail from top level product / version only to full SBOM.

Step 2: For each cyber asset / vulnerability pair, collect the decision point values for the cyber asset from the asset inventory as well as the CVSS score for the vulnerability.

Step 3: Run it though the decision tree and get the what to patch when answer of ASAP, Scheduled or Defer.

The decision tree could be programmed into the asset inventory tool, a separate tool or any other product. It is a small bit of code. If it is outside the asset inventory you will need to use the REST API or some other integration to pull the four decision point values from the asset inventory.

Customization

Each asset owner will decide what ASAP, scheduled and defer mean in terms of timeframe for their system. For many, scheduled will be during the next scheduled outage and defer will be next time the system is upgraded. For those with a more mature OT security program and further along their patching journey, scheduled could be bi-monthly and defer could be next outage.

The decision tree itself, even if it reaches a version 1.0, could be changed by the asset owner. I made a number of changes in the decision tree trying to game out scenarios for different OT security program decisions and maturity. While I believe this decision tree is quite good, I could also make arguments on why aspects should be changed. The approach and criteria are the best part of ICS-Patch.

This contrasts with the early risk metrics that I see from asset owner and detection vendors. Questioning the detail has led to a lot of fuzzy explanations and hand waving. Perhaps we will see detailed description on how the metric is calculated as they are released and mature. Even with a detailed explanation, the scores imply a level of precision that does not exist, and in the IT/OT SIEM examples don't have comparable numbers.

ICS-Patch is one of the S4 Projects spawned from S4 Events.