Industry Perspectives

Sleepless in Security: Sensor-y Overload

Jan 03, 2019 | by Paul Roberts |

On the afternoon of September 13, just after 4 PM, 9-1-1 emergency response lines lit up in three communities north of Boston. Seemingly out of nowhere, residents in the towns of Lawrence, Andover and North Andover flooded 9-1-1 operators to report a strong gas odor, homes on fire and even strong explosions in their homes and neighborhoods.  

In a matter of minutes, chaos erupted as dozens of structures burst into flames over a 2 square mile area, overwhelming the local fire response. In all, 131 structures were damaged by gas leaks and fires. Five homes were destroyed in natural gas explosions and 28 people were hospitalized. One man died, when a chimney from a burning building collapsed on the parked car he was sitting in.

Cyberattack? Thankfully, no. A preliminary analysis by the National Transportation Safety Board, released in October, pointed to human error by a work crew hired by Columbia Gas - the local provider. Specifically: a crew replacing a cast iron natural gas distribution main in South Lawrence disconnected a pressure sensor designed to monitor gas pressure in the distribution main, but forgot to disable the sensor first. The disconnected sensor, monitoring gas pressure in a disconnected section of gas main, prompted system regulators to open, pushing high pressure gas into a low-pressure distribution system that served the affected neighborhoods. The result was a deadly conflagration that has left scores of residents homeless for months.

I bring up the Lawrence gas explosions of 2018 not because they are examples of a cyberphysical attack, but because they easily could have been. Increasingly, critical infrastructure like the Columbia Gas network is monitored and controlled by wireless, digital sensors, regulators, actuators and other devices. These interface with industrial control system (ICS) software using (often) proprietary or ICS-specific protocols and regulate discrete parts of vast networks. Throughout the U.S., wireless sensors today provide real-time data to SCADA and ICS systems on variables like temperature, pressure, flow, vibrations and more.

That’s all well and good. What is worrying is that these wireless sensors, the protocols they use to communicate, and the software that manages them are known to be vulnerable to cyberattack and software-based manipulation. Indeed, security researchers have been warning about the security risks of ICS and SCADA software and of ICS specific wireless protocols like WirelessHART and ISA100.11a for almost 10 years. During that time, researchers have used presentations at technical conferences to lay out possible attack scenarios for wireless ICS networks. In a presentation at the S4 cybersecurity conference in 2016, for example, researchers Jalal Bouhdada and Erwin Paternotte showed how they could take advantage of common deployment errors to join rogue devices to industrial networks that use the WirelessHART protocol. A presentation at the 2018 S4 by Blake Johnson of Mandiant describes so-called “link layer exhaustion” attacks against industrial wireless mesh networks. Such techniques could be used to manipulate or knock out wireless sensors and other devices in industrial settings.

Of course, the existence of proof of concept attacks doesn’t mean that exploitable vulnerabilities exist in actual industrial control system environments -- let alone exploitable vulnerabilities that could lead to cyber physical attacks. ICS environments are engineered with many and overlapping safeguards to prevent accidents and avoid worst-case outcomes. The problem is that nobody knows for sure that exploitable security lapses don’t exist.

Add to that: the information security industry is not well positioned to secure this growing “Internet of sensors” that are managing so much of our critical infrastructure. Connected infrastructure is blooming all around us. But today, most network monitoring, endpoint protection and security management tools are designed for traditional enterprise IT environments. They don’t have visibility into industrial control system and SCADA environments, nor can they parse protocols like HART, Modbus, Profibus and their wireless equivalents.

Incidents like the Columbia Gas explosions north of Boston suggest that the desire of industrial- and critical infrastructure firms to monitor and automate ICS networks hasn’t gone hand in hand with electronic safeguards that could short circuit both human error and a malicious cyberattack. As an example: Columbia Gas’s monitoring center in Ohio was alerted to the rapidly increasing pressure in South Lawrence, but did not have the ability to control the pressure remotely - a tragic lapse.

As remote sensing and automation work their way deeper into our critical infrastructure, infrastructure owners and operators need to be more attuned to cyber risk. Denial of service attacks, malicious software outbreaks and man in the middle attacks that could be used to hijack critical infrastructure with devastating consequences. As security expert Joe Weiss has observed: “our industrial and commercial infrastructures were designed to be reliable and safe, not cyber secure.” Industrial networks too often lack appropriate control system cyber forensics, which makes us blind in the face of both human error and willful cyberattack. Investment in new tools and technologies to monitor such environments are critical.

In the face of such clear and present danger, we don’t need FUD - fear uncertainty and doubt. But we also can’t stick our head in the sand and pretend that the risk is too remote to bother addressing. The images of burning homes and evacuated neighborhoods in Lawrence and Andover are a reminder to us that worst case scenarios can happen and that the threat is real.  Here’s hoping we - as an industry - make real strides towards addressing it in the New Year!

This post was sponsored by RSA, but the opinions are my own and do not necessarily represent RSA’s positions or strategies.

# # #

Paul Roberts is the editor-in-chief of The Security Ledger. Follow him at @paulfroberts or @securityledger