Understanding IoT Security – Part 1 of 3: IoT Security Architecture on the Device and Communication Layers
- The device must initiate the connection to the cloud.
- “Communications to the IoT device (regardless of whether they are to or from the device) should be treated with care.
- A connection to the cloud can also facilitate a bi-directional channel, thereby allowing the IoT device to be remotely controlled.
- “Having smart devices is about giving your device the power to evolve, making it more powerful/useful/helpful over time.
- Thoughtful execution of the processing power at the device layer helps strengthen the overall network.”
IoT Security is complex. This post is the first in a series of 3 articles aiming to break down the different levels of the overall IoT Security architecture
@evankirstel: Understanding #IoT #Security @AerisM2M @bitdefender
The massive scale of recent DDoS attacks (October 2016) on DYN’s servers that brought down many popular online services in the US, gives us just a glimpse of what is possible when attackers are able to leverage up to 150,000 unsecure IoT devices as malicious endpoints.
To address the growing fear and uncertainty out there surrounding the IoT security architecture, our IoT security research practice teamed up with the IoT Security company Ardexa to help companies implementing IoT double-check that their solutions are built secure.
Part 1 of this 3-part security-focused blog series presents an introduction into the overall IoT security architecture and highlights six key principles as explained by George Cora, CEO of Ardexa.
Developing secure end-to-end IoT solutions involves multiple levels that fuse together important IoT security architecture features across four different layers: Device, Communications, Cloud, and Lifecycle Management.
The device layer refers to the hardware level of the IoT solution i.e., the physical “thing” or product. ODMs and OEMs (who design and produce devices) are increasingly integrating more security features in both their hardware and software (that is running on the device) to enhance the level of security on the device layer.
Important IoT security architecture features:
While these “hard identities” or “physical protection barriers” may be valuable in specific situations, it is the proposed data movements and ability of the device to handle complex security tasks that will determine the level of risk. Edge processing and complex security functions within a device are important principles to get right from the start.
“Many devices, appliances, tools, toys or gadgets available today have the ability to ‘talk’ to a service, cloud or server via Ethernet or wi-fi. But many of these ‘devices’ are powered by nothing more than a microprocessor. These devices are ill-equipped to handle the complexities of Internet connectivity, and should not be used for the front-line duty in IoT applications.
Effective and secure connectivity must be powered by a “smart” device able to handle security, encryption, authentication, timestamps, caching, proxies, firewalls, connection loss, etc. Devices must be robust and able to operate in the field with limited support.”
“Having smart devices is about giving your device the power to evolve, making it more powerful/useful/helpful over time. For example, machine learning algorithms can now enable these small devices to process video streams in ways which were not foreseeable (or computationally possible) a few years ago. Edge processing means that these smart devices can process data locally before it is sent to the cloud, eliminating the need to forward huge volumes of video to the cloud.
Can this be used for enhanced security? Absolutely. It means that sensitive information (usually in bulk) need not be sent to the cloud. Furthermore, it means processed data, packaged into discrete messages, sent securely to various entities is now possible. Thoughtful execution of the processing power at the device layer helps strengthen the overall network.”
The communication layer refers to the connectivity networks of the IoT solution i.e., mediums over which the data is securely transmitted/received. Whether sensitive data is in transit over the physical layer (e.g., WiFi, 802.15.4 or Ethernet), networking layer (e.g, IPv6, Modbus or OPC-UA), or application layer (e.g., MQTT, CoAP or web-sockets) unsecure communication channels can be susceptible to intrusions such as man-in-the-middle attacks.
Important IoT security architecture features:
“The moment a firewall port is opened to a network, you literally and metaphorically open your network up to significant security risks. Opening a firewall port is only really required to allow someone or something to connect to a service. Yet, field devices are not likely to be supported to the same degree as hosted applications such as web/email or voice/video servers. They will not have an administrator patching, reconfiguring, testing and monitoring software that normally applies to a cloud service.
For this reason, it is usually a bad idea to allow a connection from the Internet to the device. The device must initiate the connection to the cloud. It must not allow incoming connections. A connection to the cloud can also facilitate a bi-directional channel, thereby allowing the IoT device to be remotely controlled. In most cases, this is required.
Closely related to this principle is the use of Virtual Private Networks (VPNs), to access an IoT device. However, VPNs can be just as dangerous as allowing incoming services, since they allow an individual, or a network, access to resources inside one’s own network. The scale of the security task has now grown significantly, and often beyond reasonable control. Again, VPNs have a role to play but in very specific circumstances.”
“Communications to the IoT device (regardless of whether they are to or from the device) should be treated with care. Lightweight message-based protocols have a number of distinct advantages that make them a good choice for IoT devices including options for double encryption, queuing, filtering and even sharing with third parties.
With correct labeling, each message can be handled according to the appropriate security policy. For example, one may restrict access to messages that allow ‘remote control’ functions, or allow ‘file transfers’ in only one direction or (say) double encrypt all messages carrying client data to protect it when it traverses a message switch. It becomes possible, with such an infrastructure, to control message flow to the desired destination(s). Messaging, and its related access control and security benefits is a very, very powerful tool on the communication layer of the IoT.”
To combat the inherent challenges of securing the IoT, sticking to these key principles at both the Device and Communications layer will help reduce future headaches, particularly in trying to compensate for poor underlying design fundamentals and inadequate IoT security architectures.
Stay tuned for Part 2 of our IoT security blog series in December where we take a closer look at Secure Cloud and Secure Lifecycle Management.
Find out more details about the 4 levels of IoT security architecture and how the overall IoT security market is shaping up in our upcoming IoT Security Market Report (to be released in the coming months) – contact us now to gain exclusive access.