CEVA PentaG RAN Banner SemiWiki 800x100 220907
WP_Term Object
(
    [term_id] => 3611
    [name] => IoT
    [slug] => iot-internet-of-things
    [term_group] => 0
    [term_taxonomy_id] => 3611
    [taxonomy] => category
    [description] => Internet of Things
    [parent] => 0
    [count] => 543
    [filter] => raw
    [cat_ID] => 3611
    [category_count] => 543
    [category_description] => Internet of Things
    [cat_name] => IoT
    [category_nicename] => iot-internet-of-things
    [category_parent] => 0
)

IoT Security – Part 1 of 3: IoT Security Architecture on the Device and Communication Layers

IoT Security – Part 1 of 3: IoT Security Architecture on the Device and Communication Layers
by Padraig Scully on 12-01-2016 at 4:00 pm

The massive scale of recent DDoS attacks 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 Ardexato help companies implementing IoT double-check that their solutions are built secure.

Part 1 of this 3-part security-focused blog series presents anintroduction 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.

A. Secure Device Layer
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:

  • Some manufacturers are introducing chip security in the form of TPMs (Trusted Platform Modules) that act as a root of trust by protecting sensitive information and credentials (i.e., not releasing encryption keys outside the chip).
  • Secure booting can be used to ensure only verified software will run on the device.
  • Even physical security protection (e.g., full metal shield covering all internal circuitry) can be employed to guard against tampering if an intruder gains physical access to the device.

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.

IoT Security Architecture Principles on the Device Layer:

1. Device “intelligence” is required for complex, security tasks

  • 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.”

2. The security advantage of processing at the edge

  • 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.

Insights from George Cora, CEO at Ardexa

B. Secure Communications Layer
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:

  • Data-centric security solutions ensure data is safely encrypted while in transit (and at rest) so that even if intercepted, it is meaningless except to users (i.e., a person, device, system, or application) who have the right encryption key to unlock the code.
  • Firewalls and intrusion prevention systems, designed to examine specific traffic flows (e.g., non-IT protocols) terminating at the device, are also increasingly being used to detect unwanted intrusions and prevent malicious activities on the communication layer.

IoT Security Architecture Principles on the Communication Layer:

3. Initiate a connection to the cloud, and not in the reverse

  • 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.

4. The inherent security of a message

  • 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.”

Insights from George Cora, CEO at Ardexa
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.

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.