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.

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
Oldest First  |  Newest First  |  Threaded View
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.
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.

 
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.
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.
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: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: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: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.
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.
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.
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Intel Issues Fix for 'Plundervolt' SGX Flaw
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5252
PUBLISHED: 2019-12-14
There is an improper authentication vulnerability in Huawei smartphones (Y9, Honor 8X, Honor 9 Lite, Honor 9i, Y6 Pro). The applock does not perform a sufficient authentication in a rare condition. Successful exploit could allow the attacker to use the application locked by applock in an instant.
CVE-2019-5235
PUBLISHED: 2019-12-14
Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal.
CVE-2019-5264
PUBLISHED: 2019-12-13
There is an information disclosure vulnerability in certain Huawei smartphones (Mate 10;Mate 10 Pro;Honor V10;Changxiang 7S;P-smart;Changxiang 8 Plus;Y9 2018;Honor 9 Lite;Honor 9i;Mate 9). The software does not properly handle certain information of applications locked by applock in a rare condition...
CVE-2019-5277
PUBLISHED: 2019-12-13
Huawei CloudUSM-EUA V600R006C10;V600R019C00 have an information leak vulnerability. Due to improper configuration, the attacker may cause information leak by successful exploitation.
CVE-2019-5254
PUBLISHED: 2019-12-13
Certain Huawei products (AP2000;IPS Module;NGFW Module;NIP6300;NIP6600;NIP6800;S5700;SVN5600;SVN5800;SVN5800-C;SeMG9811;Secospace AntiDDoS8000;Secospace USG6300;Secospace USG6500;Secospace USG6600;USG6000V;eSpace U1981) have an out-of-bounds read vulnerability. An attacker who logs in to the board m...