Rethinking Vulnerability Disclosures In Industrial Control Systems

More on Security
Live at Interop ITX

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: 

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: