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.
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
6 Reasons Why Employees Violate Security Policies
Ericka Chickowski, Contributing Writer, Dark Reading,  10/16/2018
Getting Up to Speed with "Always-On SSL"
Tim Callan, Senior Fellow, Comodo CA,  10/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Latest Comment: Too funny!
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.