The number of missing security patches in an OT system is typically very large—measured in the thousands, at least. It would be difficult and expensive for an asset owner to evaluate each missing security patch / cyber asset pair. This may be one reason we see a patch everything approach, but this is also difficult and expensive. In fact, assessments show this is rarely done even where required by policy.

A vulnerability management system can identify the missing security patches for each cyber asset. Equally or even more importantly, a vulnerability management system can help an asset owner automate the decision of what to patch when. While I’m partial to a decision tree approach, see ICS-Patch: What To Patch When In ICS, there are a number of approaches. The key is for the process to meet two criteria:

AWS Builder Community Hub
  1. A prioritized patching process is developed where patches are deployed at a time interval that’s related to risk reduction of applying each patch.
  2. The decision is automated. Information is fed into a process, which helps to decide whether to patch ASAP, schedule the fix on the regular patching/maintenance interval, or defer it to when the software will be upgraded for other reasons.

In a perfect world, software and firmware would never have vulnerabilities. In a near perfect world, all software and firmware vulnerabilities would be patched as soon as possible. There is no doubt that applying security patches is a good security practice and does reduce risk.

The OT reality, though, is a very small number of security patches result in significant risk reduction, and the majority of security patches that could be applied in OT result in a tiny, near-zero risk reduction. Therefore ,the key to effective OT vulnerability management is to match the speed and frequency of security (Read more...)