This was the topic of my talk at the SANS ICS Security Summit in Orlando. Take a look at the presentation below, and I’ll write a few posts to give context to the key points.
Most asset owner ICS Security Programs are still, to put in kindly, in a less than mature stage for a variety of reasons. There is a long list of technical and security controls that are clearly good security practice, and an organization can only absorb so much security in a year even if resources are unlimited. So determining what you do next is extremely important.
We recommend a very basic efficient risk reduction approach. Ask yourself, where will we get the most risk reduction for the next dollar or hour spent on improving ICS security? Create a prioritized list of actions based on the answers. Determine how much you can do well in the next 12-18 months and measure your progress. FYI … take a look at some Shell presentations over the last year to see a practical example.
With this in mind, does security patching make the cut?
Remember the key here is “risk reduction” not “risk”. An example from the presentation is security patch for a hard coded credential in a PLC. Obviously hard coded credentials are a significant vulnerability with the consequence that once these credentials are known an attacker can compromise every PLC from the manufacturer. However in this case an attacker can upload logic/programs and do whatever else he wants to the PLC without authentication, and this is still the case after the security patch is applied. Therefore the risk reduction is tiny, and in almost all cases not worth the time.
The 1st general rule is if a device is insecure by design, and the attacker can do anything he wants without exploiting a vulnerability, then security patching is not worthwhile from a risk reduction standpoint.
Next: Security Patching In An Insecure By Design Zone