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:
- A prioritized patching process is developed where patches are deployed at a time interval that’s related to risk reduction of applying each patch.
- 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 patching to the risk reduction achieved with the patch.
A risk-based security patching approach as part of vulnerability management is still rare. Many asset owners determine a security patching cadence, monthly, quarterly, semi-annually, etc., and they try to apply all needed security patches in this interval. Again, this is not wrong in the sense that it is a bad practice. It is wrong from a risk management perspective because resources are not being applied to maximize risk reduction. Read more: https://bit.ly/3gLNEcO