There are many aspects to architecting an Internet of Things (IoT) solution. Security is probably the most important aspect of any computer system, but it’s especially important with IoT. Every so often there are news reports about IoT solutions being compromised; like Internet connected cameras being compromised to create botnets that perform denial of service attacks, or internet connected automobiles being compromised in dangerous ways. Regardless of what a particular IoT solution is used for, the overall Security of the IoT solution is an extremely important detail to keeping mind from the beginning of design all the way through implementation, as well as deployment to production.

One of the security aspects to keep in mind when designing any Internet of Things (IoT) solution is the trust boundaries between different parts of the system, both physical and software.

IoT Components

When designing an Internet of Things (IoT) architecture, the solution will consist of multiple different components. Each of these components serves a different purpose, and they all provide the building blocks to design and build the IoT solution out of.

These are the main components of an IoT solution:

• Devices
• Field Gateway(s)
• Cloud Gateway(s)
• Services

Devices

Devices are the individual IoT devices that are connected to sensors, and other components. The devices provide the “things” part of the Internet of Things.

Field Gateway(s)

A Field Gateway is a device or software component that serves as a connection point between the cloud and one or more devices and/or other field gateways. These can be used to provide additional security by offering a single connection point between components running on-premises or on the local network and the cloud. Field Gateways can provide multiple different functions from event / message communication aggregation, message or protocol translation, or multiple other functions within the solution.

Devices called Edge Gateways are also a type of Field Gateway. An Edge Gateway, or Edge Device, provides more advanced functionality by adding the ability to run Cloud capabilities locally, closer to other devices, to lower latency in the real-time processing loop. Some of the cloud capabilities that could be pushed down to Edge devices are machine learning, event stream processing, or other cloud capabilities.

Cloud Gateway(s)

Cloud Gateways are very similar to Field Gateways, however, instead of running on-premises or local to other devices, they run in the cloud. Cloud Gateways can provide similar functions to Field Gateways by operating in the cloud rather than local.

Services

The Services component is the bucket of other components of an IoT system backend, like REST APIs, databases, or some other component. These services could run in the cloud, or on-premises in a local or hybrid manner; basically where ever they are needed within the overall IoT solution.

IoT Solution Trust Zones and Boundaries

All IoT solutions are build using a variety of components (as listed above). Within the overall security architecture of an IoT solution, the different components will be isolated into different Trust Zones and Boundaries. These different zones and boundaries provide physical and software based levels of isolation to separate the various components of the solution for protection.

Here’s a partial list of some of the different things Trust Zones and Boundaries are used to protect different components of an IoT solution from:

• Identity spoofing
• Event data tampering
• Information disclosure
• Distributed Denial of Service (DDOS) attacks
• Elevated privilege exploits

To provide the segmented protection of Trust Zones and Boundaries, the different aspects of an Internet of Things (IoT) solution are separated from each other with security protections to isolate each one from the rest in a more secure manner.

The below Internet fo Things (IoT) Trust Zones and Boundaries diagram is a good model to start using to visualize the different Trust Zones and the Boundaries in between them.

Here are the main Trust Zones to keep in mind when designing any IoT Security Architecture:

• Local Zone
• Device Zone
• Field Gateway Zone
• Cloud Gateway Zone
• Gateway and Services Zone
• Remote User Zone

A general rule to follow for Boundaries between Trust Zones is to have a boundary between each zone. This will help protect each zone by creating a level of isolation between it and the other zones. It also helps to add security to each higher zone as you work towards the cloud that validates the security of the communications from the lower zone below it towards the local zone or on-premises components.

As you can see, the diagram lays out boundaries between most of the zones, except the separation of the Device Zone and the Field Gateway Zone. The reason for this is that the Devices in the Device Zone will be communicating directly with the Field Gateway(s) so they can aggregate event data and/or provide other gateway capabilities. This diagram doesn’t put a Trust Boundary here, but you could still add a larger level of separation, such as a Trust Boundary here, if your IoT solution warrants it, or if you just want to increase security to make things a bit more secure than they otherwise would be. In the end, it’s really up to you on how you design your IoT Architecture and the Security Trust Zones and Boundaries of that solution.

Local Zone

The Local Zone is the area where any local users will be. This could be the local or on-premises network where client computers exist, or even the physical space in close proximity to the Devices and Field Gateways. Securing this zone encompasses both the physical and virtual spaces where users can connect to and interact with the system.

From a virtual standpoint, securing the Local Zone would encompass securing the computer systems the end users connect to and use. It also means granting users the specific access privileges in a “least privilege” model where they have the access to perform their jobs / duties, but not more privileges than necessary.

From a physical standpoint, securing the Local Zone would involve various physical security measures necessary. This could mean simply locked doors with keys, or even biometrics in order to access the physical area of the Local Zone.

Device Zone

The Device Zone is the area where the IoT devices are. This includes the physical space around the devices, as well as the local network (or on-premises network) the devices are connected to. The local network provides the digital connectivity for the devices to communicate with the rest of the system, and might include Internet connectivity. Due to the physical and virtual scope of connectivity and access to the devices, the security architecture of the devices warrants both physical and digital protection measures.

From a virtual standpoint, securing the Device Zone would encompass securing the devices on the local network they are connected to; including both wired and wireless connectivity that might be integrated in the devices. This includes using encryption keys for communication, such as using SSL / TLS for secure communications, among other encryption and validation techniques.

From a physical standpoint, securing the Device Zone would encompass securing the devices by locking them in a secure box, or securing access to the rooms or facilities where the devices are located. Keep in mind that each device could be in a different location, so each device may need its own security design that differs from other devices used in the system.

Field Gateway Zone

The Field Gateway Zone is where any Field Gateways used in the system will reside. This could mean being contained within the same Trust Boundary as other Devices, or even placing Field Gateways in a separate dedicated Trust Boundary.

As many different Devices may be located in physically different facilities or locations, there may be multiple Field Gateways in use throughout these different physical facilities or locations. As a result, there may actually be multiple Field Gateway Zones in your overall IoT Security Architecture to accommodate connecting to and facilitating the communications between IoT Devices and the Cloud components of the IoT solution.

From a virtual standpoint, securing the Field Gateway Zone would encompass securing the Field Gateway devices in a similar manner to how you secure the IoT Devices wired or wireless connectivity. This would include SSL / TLS encrypted communications, or some other secure validation of the other devices and components communicating with the Field Gateway devices.

From a physical standpoint, securing the Field Gateway Zone would encompass securing the Field Gateway devices in a similar manner to how you secure IoT Devices within the Device Zone. This could mean locking devices in a secure box, or securing access to the rooms or facilities where the gateways are located. Keep in mind that this may require security of multiple different facilities or locations where different Field Gateways are deployed.

Cloud Gateway Zone

The Cloud Gateway Zone is where the message broker or message queue resides. The message broker for an IoT solution will facilitate communications between the various IoT Devices and the backend, service components of the system. The Cloud Gateway is not a specific database, storage, or processing service. The Cloud Gateway provides the communication to get data to / from the backend services and the devices in the solution.

The Cloud Gateway Zone could be located in the public cloud; such as Microsoft Azure or Amazon AWS. However, the Cloud Gateway Zone could also be located in a separate network and location from any of the other devices in the IoT solution. The term “cloud” in this context is being used to refer to the practice of providing operational measures to prevent targeted physical access to the zone. In todays IoT landscape, this will generally mean the IoT solution will be build with the Cloud components residing in Microsoft Azure, Amazon AWS, or another cloud provider, but it’s important to remember this could mean a local, on-premises environment or some other hybrid environment as well.

Securing the virtual connectivity for the Cloud Gateway Zone is generally the primary security surface area to plan for with this particular zone. Especially if the architecture is relying on a cloud provider, like Microsoft Azure or Amazon AWS, to provide cloud-based IoT message broker services. The appropriate communication encryptions and device identity validation will need to be put into place within this zone. Each particular IoT message broker service will have its own requirements and documentation on how to configure its security.

From a physical standpoint, securing the Cloud Gateway Zone is offloaded to the cloud provider, such as Microsoft Azure or Amazon AWS. However, if the cloud components are hosted in a local on-premises environment, or some other hybrid environment, then the usual physical security measures of securing a physical datacenter or other device will need to be factored into he IoT security architecture.

Gateway and Services Zone

The Gateway and Services Zone is where all the other backend services reside. This will include databases, REST APIs, hybrid connectivity to on-premises systems, and any other backend component of the system. In general there will be multiple Gateway and Service Zones depending on how the overall backend architecture is spread across cloud providers and on-premises networks. Additionally, this will mostly contain Services, but could include additional message brokers / gateways as necessary to build out the system architecture necessary for the given IoT and business scenario.

The security of the Gateway and Services Zone will vary depending on the different services, components, and on-premises systems integrated into the system. Each component may have its own security implemented. As a result there may be a single or even multiple Security Boundaries within the context of what is referred to as the Gateway and Services Zone.

Remote User Zone

The Remote User Zone is sort of a generic bucket to contain pieces of the solution that provide some type of remote or external access to users or even third-party partners. This could also include the integration between the IoT solution and any third-party services integrated to provide additional capabilities as part of the overall IoT architecture.

The security of the Remote User Zone is less pre-defined than other zones. Remote User connections could include using Remote Desktop (RDP) to connect to a Windows VM, using SSL / TLS to access some kind of enduser web application, or some other secure access method to third-parties.

Really, the Remote User Zone provides that backend zone for communication and integration into any other systems that might need to be integrated into the IoT solution. This could include those third-party APIs or services, enduser access web applications, or some other data federation scenarios.

Conclusion

The process of threat modeling and designing security as a feature is important in any software solution. Although, it becomes especially important in an Internet of Things (IoT) solution as there are many more individual components connected; each with their own physical and digital attack surfaces to be secured. As a result, it’s important to incorporate IoT Trust Zones and Boundaries into an IoT solution architecture to ensure the proper isolation and security is incorporated into the overall system design. It’s also extremely important to incorporate the security of Trust Zones and Boundaries into an IoT solution architecture from the very beginning of planning as mistakes with security can have catastrophic consequences to both system design as well as business operation if not accounted for and implemented properly.

Hackers and security exploits pose major risks to any software system, but IoT poses some unique challenges making it difficult to protect. This is why it’s extremely important to keep security in mind throughout the design process. Hopefully this article helps raise awareness as to how organizations can better think about how to design security as a feature in their IoT solutions.

About the Author