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
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:
Attack Surfaces Overview
First, let’s look at these 3 “tiers” within the IoT stack:
By nature, all IoT Solutions expose a variety of attack surfaces both at the Edge, in Transport, and in the Cloud.
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:
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:
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.
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.
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.
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.