Posts

Emergency at Colonial Pipeline

Another ransomware attack hit the headlines last week.  This time it’s Colonial Pipeline, the largest in the USA by some estimates, 8,850 km long, with carrying capacity of over 3 million barrels of petroleum products.  The attack has prompted the US Department of Transportation to issue an emergency declaration, easing restrictions on overland transport of supply by truck, a necessary but high-cost alternative for the company.

Colonial is wisely reluctant to release details, so we might never know exactly who did this or how it happened.  But that’s not the point.  One way or another, a malicious actor may have compromised a node on the IT network, which could have been used as a staging ground to launch an attack on the OT (Operations Technology) network.

What we do know is how to prevent that kind of attack from spreading.  There should be no need for emergency declarations.  As we have discussed previously, most people in the know―from government regulators and standards agencies to top management and on-site engineering staff―understand that you must isolate your networks.  In this age of cloud, IoT, and digital transformation, when it is becoming possible to connect everything together, we also need to implement ways to keep things separate.

A Well-Known Solution

Isolating a control network from an IT network is not difficult.  The technology has been around for decades.  It involves inserting a defensive layer, a DMZ (Demilitarized Zone) between the two networks, and using firewalls to protect them.

The challenge lies in moving production data securely across the DMZ in real time.  This is where Skkynet’s DataHub technology shines.  The DataHub can connect to equipment and SCADA systems on the industrial side, and pass that data through the DMZ to the IT side, without opening any firewall ports on either side.

We hope Colonial Pipeline recovers quickly from this emergency, and that oil and gas will soon begin to flow again up the East Coast of the USA.  Meanwhile, we encourage others to heed this wake-up call.  The attack surface of an entire company is huge.  Persistent hackers are bound to find their way in, eventually.  The best way to prevent damage to the production systems is to isolate the corporate network from the control network and insert a DMZ.  They may get that far, but no farther.

OPC Attack Surface Exposed

Industrial systems, once of little interest to hackers, are now targeted on a regular basis, making security an ever-growing concern.  At the same time, as more companies update and add to their control systems, the OPC industrial protocol continues to grow in popularity. So it would make sense to ask the question, how vulnerable to attack is an industrial system that uses OPC?

A recent white paper by Claroty, Exploring the OPC Attack Surface, discusses a number of security vulnerabilities in the products of three well-known suppliers of OPC software.  These issues, reported to the Industrial Control System Cyber Emergency Response Team (ICS-CERT), could “expose organizations to remote code execution, denial-of-service conditions on ICS devices, and information leaks,” according to the report.

The companies involved have isolated the bugs, fixed them, and issued upgrades to their software, but the underlying problem remains.  All software has bugs, and OPC software is no exception.  Every connection to the Internet risks exposing an attack surface that could be exploited.

Unforeseen requirements

Like most industrial protocols, OPC was conceived and developed before the advent of Industrie 4.0 and the Industrial IoT.  Back then, nobody seriously considered connecting their process control systems to the Internet.  All production equipment and networks were entirely disconnected (“air-gapped”) from the outside world, or at least secured behind closed firewalls.

Connecting a factory or industrial process to an IT department or cloud service introduces risk.  The design of OPC requires an open firewall port to make a connection.  Most companies are currently using workarounds to overcome this Achilles heel, but none of them are adequate.  Using a VPN simply expands the security perimeter of a control network to the outside world of phishing emails and ransomware attacks. Using an IoT gateway to connect an OPC server to a cloud service still requires connecting the plant network to the Internet in some way.

The most secure approach

Instead, the most secure way to get data from OPC servers running on a plant network is by using one or more DMZs.  According to a recent NIST report, “The most secure, manageable, and scalable control network and corporate network segregation architectures are typically based on a system with at least three zones, incorporating one or more DMZs.”

Using a DMZ makes it possible to isolate the plant from the Internet. Although OPC alone cannot connect through multiple hops across a DMZ, adding Skkynet’s DataHub technology makes it possible.  A DataHub tunnel for OPC can establish secure, real-time data flow across the connection, without opening any inbound firewall ports.  This effectively cuts the attack surface to zero.  Even if there is an undiscovered bug lurking somewhere in an OPC server, there is much less risk.  After all, hackers cannot attack what they can’t see.