Industrial Defender version 7.4 was announced last week. One feature caught my attention:

Per Endpoint Risk Calculations:

Allows customization of risk profiles on a per asset basis using threat vectors such as unpatched vulnerabilities, security events and health status.

The title Per Endpoint Risk Calculations is an important feature in a resource constrained world, while the short definition of the feature could lead to misleading risk analysis and mitigation actions. To be fair, I haven’t seen the demo yet and beginning to put this granularity into a product is a step forward.

The “per endpoint” approach is much needed to avoid security patching and other activity on endpoints where this accomplishes near zero risk reduction. And then take those freed up resources to focus on effective and efficient risk reduction activities.

All too often the approach to security patching in ICS is:

  1. Is security patching a good practice / part of cyber hygiene? Almost every standard and guideline says emphatically yes.
  2. What is my normal security patching period or cadence for the ICS?
  3. Patch everything in the ICS that frequently. Or sometimes jump on an emergency patch if there are a lot of media reports and official advisories.

This per endpoint feature could be used, especially if it can be customized, to support variable security patching periods with the risk reported appropriately. For example, the same missing patch on two different endpoints could be represented by very different risks and corresponding actions.

The reporting in these types of product GUIs and in metrics reported up to management is too often today misrepresenting risk and recommending the wrong action from a risk perspective. This is an even bigger problem in tools that are rolling up OT and IT information into a single platform and GUI. If the metric is missing security patches, then OT is almost always going to be viewed as much higher risk than IT. This is despite decades of evidence that IT cyber incidents are orders of magnitude more frequent and higher consequence.

When viewing product demos, I frequently ask about customization. For example, is it possible for me to mark a model of PLC that is known to be insecure by design to not have missing patches affect the endpoint or zone risk score? Or is it possible to have a cyber asset accessible from IT or the ICS DMZ contribute more to risk due to missing security patches as compared to an asset only accessible inside the ICS security perimeter. It’s good to see Industrial Defender and other product vendors begin to provide this endpoint granularity.

I’m a bit more concerned though that the security posture of the endpoint is what is touted in the press release as the main determinants of the risk calculation. Much more important in my view are the other factors in the ICS-Patch Decision Tree (what to patch when in ICS). These include exposure to other zones, process impact, safety impact and approved security posture. The good news is these factors don’t change often and could be entered into a supporting asset inventory or vulnerability management module, and be considered in the endpoint and zone risk calculations.

If endpoint risk calculation features are mainly automated ways to rate and report the cyber hygiene of ICS cyber assets, then I fear it will continue to incentivize and measure the wrong behavior from a cyber risk standpoint. As you look at these solutions, look at how your system would score if you achieved and maintained the security posture you determined was appropriate from a risk standpoint.