Vulnerabilities / Threats //

Advanced Threats

6/21/2017
10:00 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DanielE99701
50%
50%
DanielE99701,
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!
Equifax CIO, CSO Step Down
Dark Reading Staff 9/15/2017
Cloud Security's Shared Responsibility Is Foggy
Ben Johnson, Co-founder and CTO, Obsidian Security,  9/14/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.