The Hard Reality of Patch Management in OT Networks

Join Klaus Mochalski and Westermo’s CISO Niklas Mörth to explore why OT patch management differs from IT. Discover the challenges of safety, the importance of system baselines, and alternative mitigations like zero trust to keep your critical infrastructure secure.

Duration:

25 min

Guest in this episode:

Niklas Mörth

CISO Westermo

Transcript

Keywords

‍

OT Security, Patch Management, Incident Management, Cybersecurity, Critical Infrastructure, Vulnerability Assessment, Best Practices, Vendor Management, IEC 62443, Zero Trust

Summary

‍

Takeaways

‍

While patch management is a largely solved issue in IT, it remains a significant hurdle in Operational Technology (OT) due to factors like human health, safety, and strict system availability requirements. Unlike IT systems that can easily fail over, OT systems often require power cycling that causes operational downtime.

Deploying a patch in an OT environment can instantly invalidate a system's safety certification. This creates a difficult scenario where operators must choose between maintaining their certification or applying a patch to remain secure.

Instead of blindly following a vulnerability CVS base score or trying to maintain a weekly IT-style patching cadence, OT operators must perform their own functional impact assessments.

To accurately assess vulnerabilities, organizations need a precise baseline and asset inventory. Operators must know exactly what systems are deployed and understand each asset's criticality to the overall process (e.g., recognizing that a controller is vastly more important than a network printer).

Because patching is often unfeasible, OT operators must implement alternative security measures. Air-gapped solutions are defended as still being highly effective at eliminating remote attack vectors. Additional strategies include zero-trust architectures, network isolation, and configuring firewalls for strict whitelisting rather than deep packet inspection.

When upgrading networks, asset owners should look for vendors that build products to capabilities outlined in the IEC 62443 standard and maintain internal security postures like ISO 27000. A transparent, established vulnerability management process and a positive, collaborative response to responsible vulnerability disclosure are key indicators of a reliable vendor.

The groundwork laid for patch management—such as establishing baselines and building a "toolbox" of mitigations—directly supports incident management. If an unknown vulnerability causes an incident, the established countermeasures can be rapidly deployed. Consequently, vulnerability management and incident response teams should ideally collaborate closely or merge.

For organizations that haven't started patching yet, the absolute first step is to gather knowledge and create a baseline of existing assets. Without knowing what is on the network, it is impossible to secure it effectively. Organizations lacking the internal resources to do this should reach out for help.

Sound Bites

Klaus Mochalski: "Patch management is an exercise that we have solved many years ago. Some would argue decades ago, but in OT, for some reason, it still seems to pose a challenge in day-to-day operations."

Niklas Mörth: "[...] Human health and safety is always kind of the primary thing you're working with. I mean if you're in transportation and you're running a train you need to really make sure that the doors are closed and so on and braking works etc. So, your main focus is not just keeping the system up."

Niklas Mörth: "[...] If you introduce a new functionality, all that verification you did from a safety point of view is invalid. So, you kind of need to restart that process, which is extremely cumbersome and costly. So that also prohibits a lot of patching [...]"

Klaus Mochalski: "So certification, basically with many security solutions that are certified you may not have an up-to-date certified update, but you may have an update which actually solves the security issue. So, it's an either-or problem. Do you remain certified, or do you remain secure?"

Niklas Mörth: " [...] It's really really important in an OT setting to actually have a really good baseline on how your system looks and actually grade your assets and then when the vulnerability comes in look at say what is the actual functional impact here [...]"

Klaus Mochalski: "So if you know your systems very well and you're faced with a vulnerability on a certain device you could also isolate it by other means like by configurational means. So, in an extreme case you can pull the plug, [...] and you can only do this if you understand what pulling a certain plug means [...] "

Niklas Mörth: "You could start working with firewalls more say less like an IT kind of deep impaction packet inspection firewall and rather go like you know whitelisting stuff because you know this is what actually is going to flow in this network. Everything is I mean just block it. It shouldn't be there"

Klaus Mochalski: "[...] We discovered a number of unknown vulnerabilities and we immediately disclosed it following like the responsible disclosure procedure with different manufacturers. And it was so interesting how different the responses were. Like some were very happy and they even gave us like a medal afterwards. Others they didn't react at all at first and then they got angry [...]"

Niklas Mörth: "The incident might be caused by an unknown vulner ability you don't you didn't know about it beforehand but you can probably assess it and see that okay it's similar to this one and then you can use treatments that you have decided on for those type of vulnerabilities in that incident management [...]"

Klaus Mochalski: " [...] Understanding what you have is much more I would say a satisfying exercise because it gives you an understanding also in terms of operational processes and then it again helps you increasing the security of your systems."