Just as the internet changed everything, a new revolution known as the Internet of Things (IoT) promises to produce even greater disruption.
Primarily because IoT sensors will be utilized everywhere—in hospitals to monitor medical devices, in factories to supervise operations, in buildings for controlling temperature and lighting, etc.
Data from these sensors will be used for operations management, predictive maintenance and much more. Meanwhile, all of these applications are typically integrated with an enterprise’s IT infrastructure. As such, they are introducing a variety of new security challenges.
+ Also on Network World: DDoS attacks using IoT devices follow The Manchurian Candidate model +
Just like in current IT environments, there is no security silver bullet that can protect IoT devices from every possible cyber threat.
Since IoT will generate data at different locations for various end users, including the enterprise, its customers and partners, network segmentation and segment-based topologies are needed to protect against large-scale attacks.
For example, a compromised segment inside a partner network should not be able to compromise an enterprise’s network.
In one recent incident, OVH, a France-based hosting provider, was victimized by a massive DDoS attack carried out with IoT devices. According to OVH, the attack reached nearly 1 Tbps at its peak. The compromised IoT devices were primarily CCTV surveillance cameras and DVRs.
Changing architectures to prevent IoT device hijacking
To mitigate the threat of large-scale attacks that hijack IoT devices, important changes are needed in branch and site location architectures.
Data that is intended for partner consumption should be offloaded at the first hop from the enterprise network. Today, most partner network connectivity is routed through the DMZ. This backhauling puts unnecessary pressure on the network infrastructure (routers and switches). Instead, this data could be offloaded via a VPN locally by creating a third-party secure partner DMZ in the cloud or carrier colocation facility. Here multiple parties’ VPNs can peer with each other, while restricting these DMZs to a few locations.
One major advantage of this model is that the first hop offloads the partner data at every site instead of backhauling large amounts of site data through corporate DMZ before passing it to the partner network. A second benefit is segmentation-based topologies. Not all partners need to peer at every location. For example, a partner could be provided with the flexibility to peer and collect their data at well-defined drop-off points in the cloud. This is similar to implementing a cloud-based VPN.
In manufacturing environments, IoT devices used for industrial automation are not associated users, nor do they have encryption capabilities. Therefore, to maintain data integrity and confidentiality, the network must provide security services such as encryption for IoT devices.
As stated earlier, in most current deployments, sensor data is backhauled through the corporate DMZ and network. This forces IT departments to create complex policies for the data to traverse the network.
In figure 1, Partition P0 on a whitebox x86 machine has its own VPN, which manages connections to all the PLCs. The connection data for each PLC can be programmed from the control layer in the network. In this scenario, the data transmitted between the PLC and control elements contains operational intelligence that is relevant to the manufacturing company, but also to the industrial equipment provider.
One source of data (PLC controllers) has to be split at the source and delivered to two independent organizations. The data from the same P0 PLC source can be placed in two different VPNs by the edge router, with each having a separate topology. Data for consumption by the manufacturing company can be processed locally and then backhauled on the plant floor or back to the corporate data center. Data relevant to the PLC supplier can be processed at the local site by an analytic engine then sent to the partner for their use.
This architecture is best deployed with a VPN that connects from the plant to a cloud location and then to the partner. It can be achieved in an enterprise- or carrier-managed fashion.
Using this approach, the enterprise builds an iDMZ VPN and selects cloud locations where the data is dropped for the partner to process. The enterprise assumes responsibility for protecting the cloud points and internal plant network. This entails setting up a full security stack to ensure adequate protection measures are in place.
Here a carrier can provide the cloud VPN as a service to the enterprise plant network. The carrier can announce VPN drop locations that, based on their footprint, can be distributed across the globe. The enterprise can designate which partner collects the data from which VPN in which location. The carrier can offer all network functions as a completely managed service, including security. Using the internet as a secure transport, only the VPN peering locations will be visible to the partners.
Figure 2 below illustrates this connectivity model, which eliminates the need to build a dynamic, arbitrary VPN and protects the enterprise’s network from the burden of transporting extraneous partner traffic.
To realize the benefits of IoT, enterprises must unlock intelligence from the sensors and devices in their facilities. Yet they need the help of partners to analyze large amounts of data securely, without taxing the corporate IT network. Creating arbitrary VPN segmented topologies that use optimized data steering and strong encryption is one way for enterprises to build an IoT ecosystem with partners that protects data integrity without exposing their network to security threats.
This article is published as part of the IDG Contributor Network. Want to Join?