Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats //

Advanced Threats

10:00 AM
Connect Directly
E-Mail vvv

The Folly of Vulnerability & Patch Management for ICS Networks

Yes, such efforts matter. But depending on them can give a false sense of security.

IT security has depended on vulnerability and patch management for decades, and conventional wisdom says these programs should be replicated to make industrial networks more secure. We only partially agree.

Vulnerability and patch management programs have only modestly improved overall security for traditional IT networks. We're not throwing the baby out with the bathwater here. There is no doubt that well-planned vulnerability/patch programs — ones that prioritize what to patch based on a clear understanding of risks and that conduct proper testing — can demonstrably reduce risk. While improvements in automation across the vulnerability/patch life cycle have reduced costs and the resources required, opportunity costs remain.

Within the industrial control system (ICS) networks that underpin everything from oil/gas and water systems to manufacturing and the electric grid, many issues combine to make traditional vulnerability and patch management approaches very difficult.

The first thing IT security teams run headlong into is that patch windows for ICS networks are not, and in fact cannot, be done as frequently or regularly as IT networks. On Wednesday, you're not testing and deploying any of the patches Microsoft (or any other vendor) released on Patch Tuesday.

Check out the all-star panels at the 'Understanding Cyber Attackers & Cyber Threats' event June 21 and get an in-depth look at your cyber adversaries. Click here to register. 

Plants need to keep running, and plant executives prioritize uptime over patching something that "may cause an issue at some point." Patch windows may come about quarterly, but in some cases it can be a year or more before the plant engineering team is willing or able to patch systems — and in some instances, other priorities eclipse even these infrequent windows. We have an oil exploration customer with vessels that only come to port every three to five years for maintenance; this is when all but the most critical patching happens.

Notably, in some cases, SCADA (supervisory control and data acquisition, a control system architecture associated most commonly with critical infrastructure environments such as energy grids) and distributed control system components are shipped by vendors with outdated or end-of-life operating systems.

Another reality is that many ICS environments are outdated because of the long asset life cycles on which these plants operate — often 20 or more years between major overhauls. This is compounded by the long design/release life cycles for the ICS software that runs these plants. In many cases, these systems can't be fixed from a vulnerability perspective. We have customers that still run ICS software on Windows XP or NT — even a perfectly patched XP system is highly vulnerable since Microsoft ended support years ago. And don't forget "zero days," which are frequent for many industrial assets.

But this issue goes deeper. Most older (and even some newer) ICS environments have little or no inherent security. Security wasn't a design criterion when many of these plants were built 20 or 30 years ago. Many ICS systems have no user authentication and require no validation for code or commands downloaded to controllers that monitor and direct the operation of the physical systems — valves, actuators, pumps, robots, etc. These systems use insecure, unencrypted protocols and often operate over flat networks.

ICS vendors are making real progress, baking security into new systems, and engineering firms are beginning to prioritize cybersecurity in the design of new plants. But most plants today have what we call "M&M security" — soft on the inside and (sometimes) harder on the outside. The result? Attackers must still gain a foothold on the ICS network to inflict damage, but once they are there, they will often have nearly unfettered access to the systems that run the plant — whether patched or not.

With this in mind, a "magic wand" thought exercise is helpful. If we handed you a magic wand and you could wave it at your plant and have a perfect list of all the assets in your ICS network, and a complete list of all the known vulnerabilities, what would you do next? What steps would you take that would have the most definitive risk reduction impact on the environment?

There is definitely a need for vulnerability and patch management. Vulnerabilities, especially those as high-risk as the one that enabled the WannaCry ransomware to propagate so rapidly last month, clearly demonstrate that if patching is at all possible, then it's needed. But rather than attempting to patch everything that can be patched, we advocate a risk-adjusted approach in which you patch the most important pathways into the ICS network. Critical vulnerabilities on anything inside the enterprise network perimeter with connections back to IT networks are a high priority (for example, the VPN that provides contractors and employees remote access to the plant for maintenance purposes). Next, work on other less critical but still important vulnerabilities on the same pathways.

Instead of looping until done, we highly recommend spending time finding and fixing configuration vulnerabilities on your ICS network. In a perfect world, ICS owners/operators would implement all the recommendations of the IEC-62443 standard and cover the basics of cybersecurity hygiene. Unfortunately, the reality is that they cannot afford the downtime and all too often lack resources to do these basic steps. A practical approach is to look at overall risk posture improvements that any element can provide, and prioritize which measures and in what proportion can drive the biggest bang for the buck — considering both cost and resource constraints.

We simply don't have a decade to markedly improve the security for ICS networks. When implementing a cybersecurity program for ICS networks, you must consider opportunity costs across competing program elements. Overfocusing on an element such as vulnerability and patch management can prove to be costly in the short and longer run.

Related Content:

Galina Antova, Co-founder & Chief Business Development Officer, ClarotyGalina Antova is the co-founder and chief business development officer at Claroty. Prior to co-founding the company, she was the global head of industrial security services at Siemens, overseeing the ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
6/23/2017 | 7:21:58 AM
Why we not patch ICS
I read many articles often negatively mention that fact that ICS are not being patched. I want to say bravely: There are justifiable reasonsd for that, as correctly mentioned by Galina.

While IT people worry about CIA, ICS experts shall worry about SRP (Safety - Reliability-Productivity). None want to be blamed for a painful outage or damage just because they patched the OS.

ICS cyber experts know very well that every change to ICS hardware or software is a severe risk to SRP. So... what is the solution? where we want to be in 5 or 10 years? You shall plan building a brand new and modern control room, build it with modern hardware and software and fit the original application to the new system.

But ! be ready that it will not work. Plan for spending 4-6 months and test it before you can commision the new control room. 

The result is funny: The new control room will be as good as the old one and not better ! But it will have strong cyber defense solutions build in and will be ready for periodic cyber security upgrades.

Yes, it worth the investment, and also there is no alternative!
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Mobile App Fraud Jumped in Q1 as Attackers Pivot from Browsers
Jai Vijayan, Contributing Writer,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...