My last two articles covered the negligible risk reduction of applying security patches to Insecure By Design Devices and the minimal risk reduction of applying security patches to Insecure By Design Zones.
The good news is eliminating this activity gives you and your team more time to focus on security controls that substantially reduce risk, and one of these is applying security patches to anything accessible from an untrusted zone such as the Corporate Network, Internet, or Business Partner Network. Two factors are in your favor with this approach:
1. This should be a small number of computers and devices, such as firewalls that form the security perimeter, emergency remote access jump servers, USB transfer servers, and historians and other servers in the ICS DMZ. If this is a large and onerous list you have an architecture problem. A SWAG is this should be less than 5% of your cyber assets, and even a lower percentage if you have a large ICS.
2. Nothing in this list should be required for Operations. If you have something required for Operations that is accessible from an untrusted zone you have an architecture problem. So in the rare but possible case that a security patch causes a problem, it does not affect Operations.
Security patching in ICS is not a binary choice, yes or no. It is also not something that needs to be done with consistent frequency across all your cyber assets. The small number of cyber assets accessible from an untrusted zone should be patched asap since we know someone getting through the perimeter will have little difficulty affecting the availability and integrity of most ICS.
As a starting point you could patch this small list asap / at least monthly and everything else annually or bi-annually primarily for cyber maintenance, not risk reduction, purposes. As your security program matures you may reach a point were efficient risk reduction dictates the next security control is patching some additional cyber assets quarterly.