Threat Intelligence
1/27/2017
12:00 PM
Galina Antova
Galina Antova
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Rethinking Vulnerability Disclosures In Industrial Control Systems

Why the security industry's traditional obsession and hype around vulnerabilities cannot be transferred to the ICS environment.

The red lines once thought to be unapproachable by cyber adversaries have dimmed significantly in industrial control systems (ICS) over the past year. While not yet commonplace, these disruptive and destructive attacks are no longer the thing of fiction. Even if we abandon the “cyber war” scenario, ICS attacks may become attractive to the new wave of ransom-driven cybercrime actors or shift towards the operational technology (OT) networks and systems that support the world’s most critical physical and virtual infrastructure.

As part of this transition, we will also likely see entrenched vendors repackage solutions with an ICS label, new entrants come to market with purpose-built solutions, and a wave of ICS vulnerability research released into the public domain. After all, making news with vulnerabilities is just what security people do, and the unfortunate fact is that discovering ICS vulnerabilities is an incredibly pedestrian exercise. We’ve seen evidence of this as recently as November with a few “zero-day” disclosures pointing to “trivial exploit” pathways timed for the annual American Petroleum Institute conference. 

But this space is vastly different than the traditional IT domain, and disclosure in this arena – far more than in IT – is an incredibly sharp double-edged sword. Where disclosing vulnerabilities, theoretically should prompt ICS vendors to improve their security design strategies and alert asset owners to the potential vectors of attack, in reality, the same pace of movement towards fixing vulnerabilities (arguably inadequate in IT) cannot be achieved in OT. Here’s why:

Experience & Maturity
ICS vendors have come a long way when it comes to security vulnerability patching. However, they still don’t have the same level of experience and maturity that we find in the IT software world, and typically cannot develop patches for newfound vulnerabilities with the same degree of speed. Why? Traditionally, these companies were creating hardware and software built around reliability, up-time and real-time performance – not with security as a core focus. Because of this, these technologies were and are designed by engineers, not security experts. This is starting to change, as ICS engineers are expected to follow an accepted secure development cycle. This is clearly stated in ISA and IEC 62443-4-1, expected to be published in 2017. This industry transition will take years, though.

Long Lifecycles
The lifecycle of ICS components can be 25- to 35 years. Much of the technology in place today is at its end of life, from a support perspective. As researchers disclose vulnerabilities in “ubiquitously deployed” ICS components, they’re pointing to problems that will never be patched. These have been described as “forever-day” vulnerabilities. For example, facts identified in a recent report from FireEye concluded that 33% of vulnerabilities disclosed had no patch available at the time of disclosure. 

What’s Patching?
Patching ICS vulnerabilities comes down to the degree of adoption by asset owners/operators. This works against security since the majority of these owners/operators: 

  • Cannot afford the downtime to install the patches – they are in the business of production, not in the business of running secure networks (a huge difference from IT). At Level 2 and 3 of ICS networks (where we find Windows-based systems), for example, there is some chance of patching but at Level 1 (the Programmable Logic Controllers or PLCs), firmware upgrades often require the controllers and PLCs to be taken offline. In this industry, downtime = no good for business = no patching!  
  • Have not fully bridged the IT/OT gap, which means that organizational challenges get in the way. OT engineers are in charge of the OT systems and they don’t understand the security concern as deeply as they should. IT security teams own security, but they cannot enforce policy due to potential downtime impacts.
  • Vulnerability disclosures and subsequent patches are relevant to an admin/operator when s/he knows exactly what is in the network. In industrial networks this is patently not the case. So, until stakeholders have a better and deeper visibility and understanding of their assets, the disclose and patch cycle won’t work.

You Can’t Force the ICS Vendor’s Hand
In IT we are used to “forcing the vendor hand” through vulnerability disclosure. But with ICS, there is no hand to force. It is simply a different world than what we are used to. Disclosing vulnerabilities prior to a patch being released by the vendor only helps the bad guys, and these disclosures significantly decrease the skills required for attackers to be successful.   

For researchers that are hell bent on the sensational, there is a real harsh ICS security reality that we also need to understand: Hacking a process in an ICS network doesn’t require some insanely well-crafted exploit of the latest and greatest vulnerability. The security gaps are so wide and so drastically need fixing that for highly-skilled adversaries, there are a gazillion ways to get in. In short, we don’t need to educate the low-skilled adversary on ways to target the ICS space with our disclosures.

Bottom line: The security industry’s traditional obsession and hype around vulnerabilities cannot be transferred to the ICS environment. In ICS, even more than in the IT domain, coordination with all parties is going to be of critical importance. Consequently, as security researchers, we need to help ICS vendors and asset owners focus on solving the systemic problems, not waste our efforts pointing to issues that generate sensational headline but no lasting solution.

Related Content:

Galina 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 development of its portfolio of services that protect industrial customers ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
2/6/2017 | 4:45:29 PM
Re: ICS and IoT
@Dr.T:  Sure.  ICS is really just an enterprise-grade IoT device/system.  Additionally, there is generally more at stake w/ ICS than with other "run-of-the-mill" IoT devices -- even if are speaking strictly in the enterprise context.
MarkT563
50%
50%
MarkT563,
User Rank: Apprentice
2/5/2017 | 5:15:41 PM
ICS System Patching
ICS vendors are becoming better at providing patches for vunerabilities related to operating systems. However, the patches can be delayed as the vendor usually performs regression testing to ensure any patch does not have an adverse affect on the ICS software.

Patching can be further delayed as the client deploying the patch on their ICS will also test the patch on an offline system to ensure there are no adverse effects.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2017 | 1:36:25 PM
ICS and IoT
 

I think these go together when it comes to the security, they work and we do not touch them until we face a big security attack on them. Then the game will be completely different.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2017 | 1:36:05 PM
Re: Vuln Disclosures
"production site disconnected from the public Internet."

Good idea. It may be that some platforms are designed to work with the internet, unless vendors provide this potion it would not be easy to implement.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2017 | 1:34:17 PM
Re: Vuln Disclosures
"need to try to keep them a little more private "

This would be a little bit hard to do, if there is vulnerability then most likely there is many others already knowing it.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2017 | 1:32:25 PM
Re: Vuln Disclosures
"most don't implement the patch in time to prevent an attack."

Good point. We do not take action unless we see we are impacted. Especially with ICS environment it would be worse.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
1/30/2017 | 1:29:09 PM
Mechanical things
 

Mechanical things are hard to hack without close proximity however when we start automating most of the things then we make them vulnerable too.
WolfgangK818
50%
50%
WolfgangK818,
User Rank: Apprentice
1/30/2017 | 3:58:42 AM
Re: Vuln Disclosures
Sometimes bad guys know the vulnerability already before it gets disclosed .e.g. in targeted and state sponsored attacks. This are the biggest threats... I agree we need to keep away vulnerabilities/exploits from "newbie hackers" and script kiddies but we require to find ways to speed up the implementation of compensation controls, either by vendors or manufacturer, or best jointly.
richalt
50%
50%
richalt,
User Rank: Apprentice
1/27/2017 | 5:30:46 PM
Re: Vuln Disclosures
Although patches may not be forthcoming, the ICS vendor can certainly get their production site disconnected from the public Internet.  This is a step which should happen immediately.  In other words, workarounds need to be deployed with an assumption of vulnerability.  Don't wait for the attack to prove you are vulnerable.

 
jcavery
50%
50%
jcavery,
User Rank: Moderator
1/27/2017 | 3:13:46 PM
Vuln Disclosures
"Disclosing vulnerabilities prior to a patch being released by the vendor only helps the bad guys, and these disclosures significantly decrease the skills required for attackers to be successful."

Any disclosure has this impact even if a patch was released, as most don't implement the patch in time to prevent an attack... I agree we don't need to be publicly disclosing ICS vulnerabilities but we still have alot of thinking to do in how we disclose vulns in regular consumer products too, need to try to keep them a little more private, within the industry, instead of pasting them on the front page for any newbie hacker to cherry-pick.
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.