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.
Julian Assange Arrested in London
Dark Reading Staff 4/11/2019
Tips for the Aftermath of a Cyberattack
Kelly Sheridan, Staff Editor, Dark Reading,  4/17/2019
The Single Cybersecurity Question Every CISO Should Ask
Arif Kareem, CEO, ExtraHop,  4/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-11320
PUBLISHED: 2019-04-18
In Motorola CX2 1.01 and M2 1.01, users can access the router's /priv_mgt.html web page to launch telnetd, as demonstrated by the 192.168.51.1 address.
CVE-2019-11321
PUBLISHED: 2019-04-18
An issue was discovered in Motorola CX2 1.01 and M2 1.01. The router opens TCP port 8010. Users can send hnap requests to this port without authentication to obtain information such as the MAC addresses of connected client devices.
CVE-2019-11322
PUBLISHED: 2019-04-18
An issue was discovered in Motorola CX2 1.01 and M2 1.01. There is a command injection in the function startRmtAssist in hnap, which leads to remote code execution via shell metacharacters in a JSON value.
CVE-2019-8999
PUBLISHED: 2019-04-18
An XML External Entity vulnerability in the UEM Core of BlackBerry UEM version(s) earlier than 12.10.1a could allow an attacker to potentially gain read access to files on any system reachable by the UEM service account.
CVE-2018-17168
PUBLISHED: 2019-04-18
PrinterOn Enterprise 4.1.4 contains multiple Cross Site Request Forgery (CSRF) vulnerabilities in the Administration page. For example, an administrator, by following a link, can be tricked into making unwanted changes to a printer (Disable, Approve, etc).