Internet of Things (IoT) devices are soon expected to outnumber end-user devices by as much as four to one. These applications can be found everywhere―from manufacturing floors and building management to video surveillance and lighting systems.
However, security threats pose serious obstacles to IoT adoption in enterprises or even home environments for sensitive applications such as remote healthcare monitoring. IoT security can be divided into the following three distinct components:
Application service End device TransportAlthough all three are critical for systemwide security, this post will address only transport security.
There are two primary areas where user-less devices will grow fastest: consumer and industrial applications. In the consumer space, home security systems and appliances will ideally use SSL-based VPNs, since both source and destination points are well defined. For example, alarm systems collect data and send it to the monitoring provider.
+ Also on Network World: A patchwork quilt of IoT security +
In the industrial sector, IoT will be used for connecting machines and automation to improve the output and efficiency of manufacturing operations. Sensors are already being used in many industrial systems. For example, within the same factory floor, low-capacity sensors can be located close to each other to monitor equipment temperature, program PLCs or control lighting systems.
Most sensors don’t have the compute power required to implement the appropriate level of encryption and as such, require the network to provide this function. This can be accomplished across the internal network and, in some cases, even over the internet for partner networks.
In some locations, IoT will result in a dramatic rise in the density of devices within small areas, with each one requiring security to protect critical data.
Since many of these applications are linked to business-critical systems, they are typically integrated with an enterprise’s IT infrastructure. This poses a unique set of security challenges.
SSL vs. IPsecIn my previouspostI discussed the need for greater network segmentation. This time, let’s consider network-based encryption, namely SSL and IPsec, and which is best suited to secure IoT gateways and devices across the network.
IPsec may be a better choice than SSL as a security protocol for IoT gateways, since these gateways are used to convert non-IP data into IP. As a result, they can be the first IP connectivity point in the network. These gateways are used to connect with different types of devices and share sensor data, including video surveillance, lighting, temperature and industrial control systems. Since most low-end sensors will not support encryption (i.e. light bulbs), the first hop router might be the first encryption point in the network.
Due to the segmentation of multiple types of data, IoT infrastructures will require proper site-to-site encryption. IPsec provides benefits for both remote access and site-to-site connections. Since network segmentation is required for IoT, IPsec can be decrypted in the data plane at defined points as shown in Figure 1 below to connect only specific VPN segments in certain parts of the network.
Using IPsec in its traditional implementation, where both the IKE control and IPsec data planes are merged, provides no significant benefit over SSL. However, using software-defined networking (SDN) techniques, IPsec can be extended to provide the data control plane separation using internet key exchange (IKE) as the control/management channel and IPsec as the data channel.
SSL lacks flexibilitySSL cannot provide this flexibility because it is a transport layer protocol that requires connections be terminated at the same device. One of the leading benefits associated with SDN is the ability to transition both the control and data planes from a device by device-vertical scale to a distributed horizontal scale.
This is especially important in IoT environments, since the use of network segmentation increases the importance of resource allocation. For example, low-priority traffic from video surveillance applications should never impact high-priority network resources such as PLC traffic from manufacturing segments.
In addition, the horizontal distribution of the control and data planes enables flexible traffic inspection, which makes it possible to provision services such as IPS IDS as a service chain in order to better manage capacity. The ability to relocate the decryption point based on segments and capacity provides greater service chaining flexibility because it is not tied to any single device and can be moved horizontally along with network function virtualization. While traffic should always be encrypted at the source, ideally we should have the ability to decrypt it at any point in the network based on capacity and security requirements. This also ensures that no single device failure can impact network availability.
Figure 1 below shows multiple segments of IoT devices providing services to a different segment. The first segment is a lighting system; the second is a video surveillance system. Notice there is a control connection between the centralized controllers that could be achieved using IKE or any other IPsec key distribution method. Meanwhile, there are no control connections between routers R1 through R8 except for their connection with the central controllers. These can scale independently. The biggest benefit of this architecture is no single device failure can impact the re-establishment of control connections between the data plane IPsec gateways.
To illustrate this point, consider this capacity planning and failure scenario using IPsec. Video surveillance from one remote branch has IPsec data plane connections with both router R4 and R5, and for policy reasons, all the traffic flows through R4. If R4 fails, all the traffic from R1 will be rerouted through R5 without the need to reestablish any connections. If R4 becomes overwhelmed, a simple group policy modification can reroute sites to R5 and another router can be added for failover.
This dynamic decryption model, which eliminates the control plane at each node, can adapt to on-demand service chaining for security reasons and capacity planning. In addition, it can scale horizontally for high availability better then a vertical SSL gateway that is terminating large numbers of connections, which would require reestablishing a connection to another SSL gateway in the event of a failure.
Viptela
Figure 1
This article is published as part of the IDG Contributor Network.Want to Join?
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.