Vulnerability management in ICS environments is making progress due to the availability of automated software and firmware inventories. Now once you have a good picture of the known vulnerabilities that affect your installed base, wouldn’t it be a good idea to automatically roll out security updates? An argument that was recently re-iterated by Dale Peterson in his talk at the Distributech conference.
The simply answer is no, it’s a bad idea. And here is why.
One issue that makes the “patching” of computer systems in OT difficult is patch incompatibility with the various critical applications that might be running on a given computer. Having Microsoft issue a security patch is one thing, having your HMI/DCS/Historian etc. running as expected after the patch was applied is another. This is a well-known problem, which several vendors try to address by issuing patch compatibility lists.
Unfortunately, not every vendor is following that practice. And those who do don’t use a unified, machine-readable format such as the VPC format defined in IEC 62443-2-3. In other words, an automated check if the various applications that are running on a given computer might perform reliably after a patch is applied is not possible at this time, and the industry seems to have other priorities than fixing this issue in short time.
Then, computers aren’t your only problem. Think about your network gear, PLCs, RTUs, IEDs, and so on. All these devices have vulnerabilities, too. But those aren’t “fixed” with patches. They usually require a firmware update. When was the last time you updated your industrial switches’ firmware, for example, because of a security risk? Or your PLCs? Probably never. This may be due to the result of your personal risk assessment, complacency, or just to the practicalities involved in finding a good time slot to make it happen.
Now imagine a new, cool security solution could help you to automate patch and firmware rollout a great deal. What does that actually mean?
In essence it means that the risk involved in every single patch application or firmware update is multiplied. You scale that risk from something that can be managed locally by an individual team of engineers to something that can shut down the global operations of a large company just like that.
Who is owning that risk? Who wants to own it?
And let’s not forget, we’re not just talking about patch incompatibilities or firmware version conflicts here. Were’re talking about the even bigger risk that your security rollout platform might get compromised, and rather than benign security updates you are pushing out malware and rogue firmware. A trusted central software distribution mechanism is a single point of global compromise.
That’s the reason why we don’t support active configuration changes in our OT-BASE Asset Management Platform.
Also read: What does “insecure by design” actually mean for OT/ICS security?