Posts

Emergency at Colonial Pipeline

/by

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

/by

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.

NIS 2 Raises the Bar for Network Security

/by

Key directive: One or more DMZs are needed for the most secure, manageable, and scalable segregation of control and corporate networks.

The recent adoption of a new NIS 2 Directive by the European Commission is a sign of the times.  Beset by a world-wide pandemic, many companies across the EU have turned to digital technologies to allow their workforce to stay productive, and to facilitate access to valuable production data.  This has led to unprecedented levels of industrial data being passed between company networks and across the Internet, increasing the risk of exposure to malicious intruders.

To combat the threat, the European Commission has accepted revisions to the Directive on Security of Network and Information Systems (NIS), now calling it NIS 2. Among other things, this document mandates a number of basic security elements, including standards for networking data between the production and corporate levels of a company.

The Commission has tasked ENISA, the European Union Agency for Network and Information Security, with implementing the standards.  In pursuit of this mandate, ENISA relies on the expertise of three well-known bodies, NIST, ISO, and ISA to provide detailed descriptions of how network security should be implemented, as published in its Mapping of OES Security Requirements to Specific Sectors document.

Using DMZs

For example, the recommended way to bring process data into the corporate office is summed up in NIST document SP-800-82.  It says: “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.”

These three zones are the control zone (OT), the corporate zone (IT), and the DMZ itself.  The document describes the value and use of firewalls to separate these zones, and to ensure that only the correct data passes from one to the other. Using a DMZ ensures that there is no direct link between corporate networks and control networks, and that only known and authenticated actors can enter the system at all.

Skkynet recommends using a DMZ for OT/IT networking, and provides the software needed to seamlessly pass industrial data across a DMZ-enabled connection.  Most industrial protocols require opening a firewall to access the data, but Skkynet’s patented DataHub architecture keeps all inbound firewall ports closed on both the control and corporate sides, while still allowing real-time, two-way data communication through the DMZ.

Unlike MQTT, which cannot reliably daisy-chain connections across the three zones as ENISA recommends, the DataHub maintains a complete copy of the data and connection status from the source to final destination.  Thus, it provides accurate indicators of data reliability at each zone in the system, along with making the data itself available.

We applaud the European Commission for its no-nonsense stance on cybersecurity with NIS 2, and encourage all EU members, indeed any company expanding its use of corporate networking, Industrie 4.0, or Industrial IoT technologies to adhere closely to the guidance of ENISA, and to implement three-zone security using one or more DMZs.

Case Study: TANAP Pipeline, Turkey

/by

Skkynet’s DataHub middleware was used by ABB for secure, real-time data networking on the Trans-Anatolian Natural Gas Pipeline (TANAP) project in Turkey.

Read more

Is MQTT the Answer for IIoT?

/by
Part 8 of Data Communication for Industrial IoT

MQTT, or Message Queue Telemetry Transport, is a publish/subscribe messaging protocol that was originally created for resource-constrained devices over low-bandwidth networks. It is being actively promoted as an IoT protocol because it has a small footprint, is reasonably simple to use, and features “push” architecture.

MQTT works by allowing data sources like hardware devices to connect to a server called a “broker”, and publish their data to it. Any device or program that wants to receive the data can subscribe to that channel. Programs can act as both publishers and subscribers simultaneously. The broker does not examine the data payload itself, but simply passes it as a message from each publisher to all subscribers.

The publish/subscribe approach has advantages for general IoT applications. “Push” architecture is inherently more secure, because it avoids the client-server architecture problem, allowing devices to make outbound connections without opening any firewall ports. And, by using a central broker, it is possible to establish many-to-many connections, allowing multiple devices to connect to multiple clients. MQTT seems to solve the communication and security problems I have identified in previous posts.

Despite these architectural advantages, though, MQTT has three important drawbacks that raise questions about its suitability for many IIoT systems and scenarios.

MQTT is a messaging protocol, not a data protocol

MQTT is a messaging protocol, not a data communications protocol. It acts as a data transport layer, similar to TCP, but it does not specify a particular format for the data payload. The data format is determined by each client that connects, which means there is no interoperability between applications. For example, if data publisher A and subscriber B have not agreed on their data format in advance, it’s not likely that they’ll be able to communicate. They might send and receive messages via MQTT, but they’ll have no clue to what they mean.

Imagine an industrial device that talks MQTT, say a chip on a thermometer. Now, suppose you have an HMI client that supports MQTT, and you want to display the data from the thermometer. You should be able to connect them, right? In reality, you probably can’t. This is not OPC or some other industrial protocol that has invested heavily into interoperability. MQTT is explicitly not interoperable. It specifies that each client is free to use whatever data payload format it wants.

How can you make it work? You must either translate data protocols for each new connected device and client, or you need to source all devices, programs, HMIs, etc. from a single vendor, which quickly leads to vendor lock-in.

The broker cannot perform intelligent routing

MQTT brokers are designed to be agnostic to message content. This design choice can cause problems for industrial applications communicating over the IoT. Here are a few reasons why:

1) The broker cannot be intelligent about routing, based on message content. It simply passes along any message it gets. Even if a value has not changed, the message gets sent. There is no damping mechanism, so values can “ring” back and forth between clients, leading to wasted system resources and high bandwidth use.

2) The broker cannot distinguish between messages that contain new or previously transmitted values, to maintain consistency. The only alternative is to send all information to every client, consuming extra bandwidth in the process.

3) There is no supported discovery function because the broker is unaware of the data it is holding. A client cannot simply browse the data set on the broker when it connects. Rather, it needs to have a list of the topics from the broker or the data publisher before making the connection. This leads to duplication of configuration in every client. In small systems this may not be a problem, but it scales very poorly.

4) Clients cannot be told when data items become invalid. In a production system a client needs to know that the source of data has been disconnected, whether due to a network failure or an equipment failure. MQTT brokers do not have sufficient knowledge to do that. The broker would need to infer that when a client disconnects it needs to synthesize messages as if they had originated from that client indicating that the data in certain topics are no longer trustworthy. MQTT brokers do not know how to synthesize those messages, and since they don’t know the message format, they would not know what to put in them. For this reason alone MQTT is a questionable choice in a production environment.

5) There is no opportunity to run scripts or otherwise manipulate the data in real time to perform consolidation, interpretation, unit conversion, etc. Quite simply, if you don’t know the data format you cannot process it intelligently.

No acceptable quality of service

MQTT defines 3 levels of quality of service (QoS), none of which is right for the IIoT. This is an important topic and one that I have gone into depth about in a previous post (see Which Quality of Service is Right for IIoT?). MQTT might work for small-scale prototyping, but its QoS failure modes make it impractical at industrial scale.

In summary, although the MQTT messaging protocol is attracting interest for IoT applications, it is not the best solution for Industrial IoT.

Continue reading, or go back to Table of Contents

Is UDP the Answer for IIoT?

/by
Part 7 of Data Communication for Industrial IoT

UDP is an alternative to TCP.  So, the question comes down to this: Which is more suitable for Industrial IoT applications: UDP or TCP?  To answer that, we’ll take a quick look at the differences between UDP and TCP.

UDP services provide best-effort sending and receiving of data between two hosts in a connectionless manner.  It is a lightweight protocol with no end-to-end connection, no congestion control, and whose data packets might arrive out of time-sequential order, or duplicated, or maybe not at all.  Nevertheless, UDP is often used for VOIP connections and consumer applications like streaming media and multi-player video games, where a packet loss here or there is not particularly noticeable to the human eye or ear.

TCP, in contrast, provides connection management between two host entities by establishing a reliable data path between them.  It tracks all data packets and has buffering provisions to ensure that all data arrives, and in the correct sequence.  This added functionality makes TCP a little slower than UDP, but with plenty of speed for most industrial applications.  Witness the popularity of Modbus TCP, for example.

Industrial control: higher priorities than speed

In real-time systems, including most industrial control networks, sequence, accuracy, and completion of messages takes a higher priority than speed.  If an alarm sounds, of course you want to receive the information as quickly as possible, but more important is to receive the correct alarm for the correct problem, and to always receive the alarm.  Missing that one alarm out of 100 could mean the difference between shutting off a valve or shutting down the plant.

Industrial IoT is not the same as a low-level control system, but the principle still applies.  Speed is important, but getting the correct information in the correct time sequence is vital.  TCP can provide that quality of service, and is fast enough for virtually all IIoT applications.

Continue reading, or go back to Table of Contents