IoT Security in the Real World – Part 1: Securing the Edge

Overview

There is a significant amount of Fear, Uncertainty, and Doubt (FUD) currently floating around Connected Industry and the IoT universe. Much of that centers around some recent well-known exploits (the BMW Wi-Fi exploit in Europe, NEST sending zip codes in plain text), but as with most FUD, it is largely a lack of understanding that sows the seeds of doubt.

In this posting, rather than give a top ten list of possible remediation steps for securing an IoT solution, I wanted to take a look at a real-world IoT environment, and then review what the possible Attack Surfaces present, and then discuss general strategies for remediating them.

NOTE: This post also happens to be based on a real Security Assessment proposal I put together for a client of Momenta Partners.

Definitions

Before we get started, let’s just settle on a few terms that will be used throughout our discussion:

Attack Surface – The total exposure to attacks within a given environment. A Server with numerous ports open and no firewall rules in place would have a very broad Attack Surface.

Attack Vector – The route by which an exploit attempt is made. The same Server described above could face a brute-force attack using SSH as the Attack Vector.

Our Deployment Environment

For our example, we’re going to pick a Connected Industry environment that is rapidly adopting connectivity and will continue to see substantial connected product growth in the next decade – The Oil Field.

Now, Oil Field equipment ranges from the ultra-high-tech Electrical Submersible Pumps (ESPs) that are used in offshore drilling to the dead-simple Beverly Hillbillies-style “Donkey Pumps” that litter the West Texas landscape.

For our discussion, let’s use the following setup for our new IoT implementation:

• A hardened industrial Gateway deployed at the wellhead (like a Mitsubishi e-F@ctory, or EnBase SCADA), with:
  • Local Wi-Fi connectivity for on-site communication
  • A Cell module that provides the Long Haul transport
• A proprietary piece of “Agent” Software running on the Gateway that sends data and receives commands from the Cloud
• A Mobile App that speaks to the Gateway locally for Configuration / Service
• An Amazon Web Services (AWS) hosted IoT Cloud platform (like Litmus Automation Loop, PLAT.ONE or PTC ThingWorx)
• A set of Programmatic APIs on top of the IoT Platform which the Solution Provider builds the Well Monitoring / Management application

Attack Surfaces Overview

First, let’s look at these 3 “tiers” within the IoT stack:

• Edge: Everything at the “Edge” of the Network, where Data is being Acquired
• Transport: The communication channel used to move data from one place to another
• Cloud: The Server components that receive data and allow remote Users to interact with the Edge devices

By nature, all IoT Solutions expose a variety of attack surfaces both at the Edge, in Transport, and in the Cloud.

Each of these Attack Surfaces provides a possible avenue for exploitation, whether that be for gaining access, Man-in-the-Middle, Denial of Service, or Impostor attacks. These Surfaces will all need to be evaluated, with varying strategies for remediation.

Securing the Edge

The on-site responsibilities for Connected Hardware such as an IoT Gateway can range from simple monitoring of the Key Performance Indicators (KPIs) for the machines themselves, to acting as a Hub (or more like a Reverse Proxy) for Remote Monitoring and Diagnostics.  

Let’s assume that the data coming into the Gateway is coming in via Ethernet or Modbus and that the Sensor to Gateway link is physical and secured.

There are 2 key Attack Vectors that are obvious from the Edge:

• Local Physical Connections (Ethernet, RS-232)
• Local Short-Haul protocol (i.e. Wi-Fi / Bluetooth)

These in-situ interfaces should be secured, but represent the least like a vector of attack. They cannot be ruled out, but if the physical site is compromised there is a limited set of functions that can be protected (anyone in baseball bat distance can bypass most software-based protections!).

In many cases, particularly in sensitive installations, the Networks are “Air Gapped”, meaning that there is a separation of Physical networks in place, such that access to public Internet is on one side of the “Gap”, and sensitive equipment is on the other side.

Once we connect one of the Devices within the “Protected” side of that gap at that site, however, we have now exposed a completely new Attack Vector.

Rather than the focus being on the traditional (low risk) access points, the entire local ecosystem of the Site can potentially be accessed from a remote location.

Let’s look at the components at the Edge to see what our potential exposure looks like:

• Controllers: The physical equipment (Software/Hardware) combination that is responsible for actuating pumps, monitoring fluids, collecting data. Typically, a SCADA device that interfaces with other smaller controllers that are directly attached to Equipment.
• HMIs: Human / Machine Interfaces provide a way to interact with the Controllers within the local operating environment. These have traditionally been accessed via a fixed or hand-held RS-232 or Ethernet attached device, but this is moving toward remote HMIs connected via Cell or Satellite.

Numerous Solution Providers exist in this space with a closed-loop between the SCADA system and the cloud (such as ScadaLink), but increasingly Operators are exploring options that stretch beyond simple equipment monitoring.

Introducing our Gateway

When any additional equipment is added to the environment, you should consider what is the narrowest possible access that is exposed to and through the new piece of equipment.

Here we introduce a new “Gateway” component, and thus a new Attack Vector:

Gateways: This can refer to either the piece of equipment responsible only for the long-haul communication, or a “smart” device that interfaces directly with the Controllers.

Now the local operating environment has a potential access vector that can be used to either gain access to the data, interfere with the local equipment, or intercept payloads meant for the Well Head environment.

Let’s take a look at 3 potential vulnerabilities exposed via the addition of this new piece of equipment: 

1) Network Exposure near Well Head

With the introduction of a new device within the local network at the Well Head, some amount of Network Access must be provided for the Gateway to do its job. Let’s say, for the sake of argument, that the Gateway is attached directly to the Controller via a local Ethernet connection. Any Access to the Gateway via a Remote session (Local Wi-Fi, remote SSH) now exposes some level of access to the Controller-facing side of the infrastructure (Be it via USB, RS232, or Ethernet).

In some cases, it may be possible to download software to the Gateway and run port and process scans to discover possible local vulnerabilities. 

• Similar To: The Stuxnet attack, where a closed network was infiltrated, local devices were discovered and then compromised.  
• Lesson Learned: Assume that the Gateway Device will at some point be compromised, and drastically limit the capabilities and Southbound network access to the bare minimum necessary for the Gateway to function.

The data from the Gateway is going to be configured to have a specific endpoint that serves as the destination for Cloud or “Northbound” data. In most cases this is either a RESTful endpoint, or a Message Queue (over MQTT or AMQP typically). Now, this pre-configured endpoint will be assumed to lie on the other side of the communication path that the Gateway is currently using.

In the case of Wi-Fi being used, it is possible to spoof an existing Wi-Fi network and possibly convince a device to attach itself to the new (and possibly identically named) network. This new network can optionally pass through the traffic to the original destination, making the attack itself very hard to detect. 

In the case of Cell communication, this is generally considered to be infallible. In an ideal environment this is true, but even cell communication can be exploited through Network spoofing, especially in locations where the signal strength causes intermittent renegotiation. 

• Similar To: The BWM Cell Spoofing exploit
• Lesson Learned: Keep all traffic encrypted, do not assume that any transport is secure and instead make sure the payload itself is safe enough for any transport.

3) Impostor Attack

The Gateway itself does not need to be compromised to act as an exploit. Once the Gateway has been established as a trusted Device at the Edge of the Network, the Cloud itself can be used as an Attack Surface. The nature of how Device Identity is managed and asserted from the Gateway becomes critical at this point.

If the Device Identity is nothing more than one or more Strings stored in a plain-text configuration file, without any additional client-side certificate or encryption functionality, then the stream of values being sent from the Gateway can be easily spoofed.

In many cases, cloud-hosted Rules are configured to run based on the values reported from the Gateway, so a spoofed Gateway can trigger significant changes in the system without ever compromising the Gateway itself. This can trigger unnecessary service calls, or even allow the spoofed Gateway to acquire the current values from the Cloud, download Firmware updates, or obtain a session token which can then be fed to other systems for potential exploits.

• Similar To: I won’t publish the details, but I have witnessed this unintentionally occur in production. Bad serial number management (the same Serial issued to multiple devices) caused a situation where it was impossible to tell which instance of a Gateway with a given Serial Number. Since the mechanism for updating firmware relied upon a conversation with one and only one Device throughout the update session, it was impossible to fix it remotely. 
• Lesson Learned: Device Identity should be queried in as deterministic a manner as possible from the hardware, NOT from a configuration file. Client-side certificates for payload encryption also provide another layer that is nearly impossible to spoof without compromising the Gateway first.

Conclusion (Part 1)

“Where there is great power there is great responsibility” – Winston Churchill

While expanding traditional Industrial environments with IoT technology, it is necessary to be cognizant of the new Attack Surfaces that have been added as part of the Solution. Planning for exploits when the Solution is first being implemented will go a long way toward keeping your implementation out of the news.

Stay tuned for the next installment, where we will cover "IoT Security in the Real World – Part 2: The Fog, The Cloud, and the Fallible Human Machine"