When considering securing an IoT deployment, there are two separate conversations that need to be had. First, how do we secure the endpoint devices themselves, and second how do we secure the networks through which those devices communicate information back to a central source (or to each other).
The difficult part about this discussion, is that you can tackle it in many different ways. There are a few key architecture decisions that you’ll have to make to decide how both network security and endpoint security should be approached.
Dedicated Gateway Architecture
In this architecture, you’ll use a dedicated gateway as an aggregation point for all of the data coming from your endpoint devices. Each endpoint speaks to the gateway, the gateway aggregates and preprocesses all information, and then transmits it to a central source.
Technical details:
From endpoint device to edge gateway:
Typically, in this type of setup, you’d have all your devices connect over something like 802.1x, a wireless network authentication protocol.The identity of the device is confirmed based on a certificate provided by a RADIUS server.
This particular protocol offers encryption between the endpoint device and the edge gateway to ensure that communications between the two are secure should someone be eavesdropping.
Securing wireless communications at the physical layer is one of the primary benefits of 802.1x.
Using the Extensible Authentication Protocol (EAP), 802.1x provides a secure method for over-the-air network authentication. As such, it has become the standard for use on both wired and wireless LANs.
It can be configured for EAP-TTLS/PAP and PEAP-MSCHAPv2 credentials as well as digital certificate credentials through EAP-TLS.
From edge gateway to central or cloud data center:
When communicating between the edge gateway and wherever centralized storage or processing of data is happening, a VPN connection is a must.
In this case, you can choose to use either a software or hardware VPN to secure communications back to the central server. In many cases hardware-based VPNs have many benefits in this kind of architecture including:
- No specialized software is required on the gateway device itself.
- No software compatibility concerns: Because no software is required on the gateway device, there is no concern about which versions of applications or operating systems are running.
- In many cases, the gateway device itself can simply be a hardware VPN.
- Firewalling and isolation: A hardware VPN can act as a firewall between the gateway and the outside world. No other devices on the same network as gateway can even see that the endpoint devices communicating with it even exist.
- Greater control over where traffic is sent: A hardware-based VPN can be configured to only allow traffic to flow to a single endpoint. Meaning, when used as a gateway, it can ensure that any and all traffic can only go to the central network.
- Hardware VPNs offer a solution for securing wireless communications at the physical layer.
When to use it:
This architecture option is a good fit for IoT deployments in which devices are physically close to each other and operating with low power requirements. When devices are separated far enough physically that they can’t operate off the same wireless network connection, this type of architecture doesn’t work.
It is also harder to manage and monitor the behavior of each individual endpoint device in this type of architecture. Once information is sent to the centralized server, where anomaly detection security solutions are usually deployed, all of the data has already been aggregated and there is no granularity on what is happening at the individual device level.
It is, however, possible to implement some form of anomaly detection at the gateway itself if desired. Typically IoT devices are relatively simple in their function making it easy to build a behavior profile and execute simple, passive anomaly detection at the gateway entrypoint.
The bottom line: The centralized gateway architecture is a good fit (and typically lower cost option) if you have an IoT deployment with small physical footprint, and it isn’t imperative to know exactly what each individual endpoint is doing once the data reaches the central server.
Individual Device Communication Architecture
In this type of architecture, the endpoint IoT devices communicate directly with the centralized server or cloud data warehouse, rather than using a gateway to gather and aggregate communications.
Technical details:
In this setup, you’ll want to make sure you are encrypting all traffic from the endpoint device back to the centralized network.
Deployments like this often have to communicate across cellular networks or the open internet to communicate back to the centralized server (as they are often physically spread out across a large area).
Because of the networks in use, which are often untrusted, encryption of the data being sent from the endpoint device back to the primary network is very important. You’ll typically want to build it directly into the APIs you are using for the device itself, and often Transport Layer Security (TLS) protocol is used to achieve this.
You’ll also want to follow some best practices for traditional endpoint security including:
- Employing full disk encryption,
- Using a Trusted Platform Module (TPM) for storage
- Making the file-system read-only (to prevent bad actors from changing information on the device should they gain access), and
- Monitoring for file integrity.
When to use it:
This architecture is a fit for larger scale deployments but usually comes with larger costs than the centralized gateway architecture.
The type of backhaul you use will typically be the most expensive part of the equation. Typically these deployments are using Private LTE, 5G, or 4G networks to communicate.
You’ll also have to consider powering your devices, particularly if something like changing batteries is a prohibitive issue. Typically devices are set to send small amounts of data every so often so as not to overtax the available power source.
You do, however, get the benefits of being able to more centrally monitor, control and detect anomalies on each individual device at the central server.
In terms of security, there is a much larger attack surface in this model, as the endpoint devices themselves are more accessible to bad actors, and there are more connections from the point of data collection back to the centralized server to keep secure.
Combining VDI & VPN for Remote Work
If your organization is looking to implement a company-wide, secure solution for remote work that is not overly expensive, difficult to manage or maintain, and simple for end users, a combination of VDI and a hardware VPN may be the right fit.
Combining Virtual Desktop Infrastructure (VDI) with a secure hardware VPN would allow your employees to securely connect to your corporate network from their own devices.
A VDI allows end users to work remotely through a virtualized environment that lives on your central server. End user devices connect via the VDI to virtual machines that you have set up on your server, allowing users to execute work as if they are on your internal network.
With VDI, no data is stored on the end user device. Instead, the user can simply see what is on the screen of the virtual machine and interact with it, but not store data from it. VDI supports a range of end user devices, from laptops and desktops to tablets or mobile devices.
Combining this environment with a secure hardware VPN, like Archon's GoSilent Platform, protects all traffic and information flowing across the connection between the end user device and the central network.
Read the full article on combining VDI and a hardware-based VPN for more information on how it works.
Remote Access for Plant Operators
Using a similar architecture to the example above a VDI and VPN combination can be especially useful for allowing remote access to Human Machine Interfaces (HMIs) inside manufacturing plants.
This allows a technician to remotely track the performance of plant equipment, and alert feet-on-the-ground maintenance staff if physical work is required to that equipment. The use of a VDI interface can allow that technician to remotely tune settings as needed to keep the equipment humming along effectively, without ever actually pulling sensitive data and storing it on a device outside of the plant.
This deployment option also nicely affords the ability to limit the traffic that can get through to the HMI. With the right hardware VPN, you can enforce a rule that only allows VDI traffic through.
All of this keeps the HMI from ever being exposed to the outside world.
Securing and Updating Unmanned Systems
IoT deployments that contain unmanned systems or endpoints are often the most difficult to secure, as denial of service attacks are prominent and very difficult to prevent in these scenarios.
Denial of service attacks are especially effective on IoT devices as they typically have limited computing power, making it easy to overwhelm them with traffic. This limited computing power also means that running tools on the endpoint to catch and stop denial of service attacks isn’t feasible.
For deployments like this, there are a number of options you have for tightly securing and protecting unmanned systems:
Cloud Delivery Networks
Using a good Cloud Delivery Network (CDN) is often the first step in helping to prevent denial of service attacks. Akamai, for instance, is best known for preventing one of the largest denial of service attack attempts in history.
Segregation of IT and OT networks
Another important option you can look into in this case is segregating your IT and OT networks. This means you essentially set up two separate networks, one for IoT devices to transmit data back to a central source for storage and analysis, and a second network specifically for managing and controlling the IoT devices.
Companies like Owl Cyber Defense build products called data diodes specifically for this purpose, that only allow IoT devices to communicate one-way, and prevent traffic from flowing in the wrong direction.
Once you’ve appropriately separated the network functions, you can focus all of your security efforts on the management network, as that is where the threat truly lies. Locking that network down and limiting access to it will prevent attacks that can render unmanned devices useless.
Using an edge gateway
Using a dedicated gateway architecture model (if possible with deployment size constraints) can also help here, by placing a more powerful security device between the outside world and the endpoint devices themselves.
IoT device security measures
There are a few things you can do on the device itself to improve individual IoT device security.
Reserve resources on the CPU or save disk space for your most critical services and functions. Make sure that the processes the device needs to function own a set partition of the CPU, for instance reserving 10% of the CPU for the remote management functionality. This helps make sure that if a denial of service attack is happening, you can still access and fix the device.
Make sure that you have a good mechanism in place to send and execute firmware updates for your device as well. Keeping devices in the field up-to-date goes a long way in keeping doors closed for unauthorized access.
Securing Legacy Industrial IoT Deployments
Another common problem that IoT deployments come up against is the use of outdated or legacy technology. Often the desire to connect equipment or endpoints that were never built to be connected comes up in the predictive maintenance and automation area of IoT.
Compatibility concerns
The biggest issue that tends to arise here is compatibility. Most modern cyber security technologies won’t work with the outdated or legacy technologies in place in most warehouses and factories.
In this case, your methods for securing these solutions become much simpler out of necessity. Purely because most of your options won’t work with the existing technology, you are usually left with using hardware-based VPNs to secure legacy IoT communications.
Often these particular deployments are a great fit for the dedicated gateway architecture as they are limited in geographical scope and need to protect legacy devices from outside networks.
Anomaly detection
It is ideal to use passive anomaly detection on the edge gateway in this example, as your device behavior will be very predictable. Because these devices were never envisioned to be connected and communicating, you can make sure their communications are very simple and repeatable, making it easy to catch anomalies in their activity.
Microsegmentation
You can also employ a strategy called microsegmentation to keep communication between devices limited to only those that need to speak to each other. Rather than allowing every device to talk to every device on the network, you can build and layer separate communication networks between groups of devices.
This can prevent devices from causing problems for each other on the network and reduce the available attack surface should someone gain unauthorized access to one of the smaller segmented networks.
Segregation of IT and OT networks
This is another case, similar to above, where segregation communications between IT and OT networks is also valuable.
Securing Connected Products in Regulated Industries
As a product provider who wants to have products “phone home” to alert for problems or maintenance issues, it is important to keep in mind the places your product will be used. If your product is deployed in highly regulated industries, like a machine that is used in factories to produce military aircraft for instance, the security of those “phone calls” home is very important.
In these instances you’ll most likely run into regulations that require something like a data historian. This is a program that records all production or process data as a time series, making it easy to look back over a timeline of records.
Segregation of IT and OT networks
This is another case, similar to above, where segregation communications between IT and OT networks is also valuable.
In this case you’d want to use something like a data diode to control communications between SCADA systems or industrial devices and end-users outside of the security perimeter of the plant.
Additionally, using tools specifically built to create a firewall between your IT and OT networks, like the Dragos Platform, helps to segregate and control any communications to and from your product in the field.
(source)