There are multiple concerns sourced from different perspectives that should be taken into consideration when architecting a secured end-to-end IoT management platform.

As the nature of such system is the fluent interaction between (potentially) millions of independent hardware components and a mission-capable management system orchestrating them, it is essential to handle each component's security within two levels – individually and as a whole. The IoT administration system is a centric and crucial component in the connected devices ecosystem, acting as the glue for all devices.

While the device itself is a standalone component, having the capability to act independently over time, it is just a tiny participant in the larger IoT network hosting it. But even the single device, compromised for a malicious or deceptive operation, can lead to a devastating situation where the entire management backbone collapses, effectively destroying the IoT network.

Without a functioning, accessible and responsive orchestration system, every registered device is abandoned to continue its work in an uncontrolled existence. It is still alive but only in a zombie-like mode, detached from its management entity. Depending on the nature of the device's activity, it shall continue to operate for a decent amount of time before it becomes a useless brick.

For instance, it is likely that a pedestrian gate controlled by a photoelectric sensor will function for life, as long as it receives the correct voltage. However, a parking barrier gate that opens and closes according to the license plate reading requires a fundamental connectivity with the management system, based on continuous or semi-continuous communication in order to function over time.

When the management system is not healthy and the connection with the IoT devices is not stable, it immediately impacts the registered devices' security by opening new potential vulnerabilities.

During the "zombie life" of a device, many unknown and potentially troublesome activities might occur in the device. Obviously, it can naturally get into a situation where it is no longer able to "talk" with the central system because of protocol modifications performed during the disconnection period.

This situation can sometimes be mitigated by keeping the protocol backward compatible to some extent. However, manipulating the device's firmware and critical parameters for a wicked purpose is a totally different story. And here folks, lies the really big problem.

The Manchurian Candidate

Think about a scenario in which a device that for a long time was considered abandoned pings to the management system to signal its existence. From the outside it looks the same, but is it really?

Recovering from this insecure condition is the responsibility of the management system solely, where it needs to hard reset the device remotely if that feature is applicable by the device property, or perform a soft cleaning procedure in case it is enough (by policy), in order to re-establish the device management system root of trust connectivity.

Architecting a secured device management system environment must involve attack vector mapping in the coverage required by the Cyber Threat Analysis phase. Security requirements must define at least the following: first, the management system should protect itself from external threats, such as data stealing, data jamming, trojan attacks and DDoS campaigns.

Second, it must have a system-wide, Data-to-API authorization coverage against intra-organization threats. Third, it must maintain a trusted relationship with the devices it manages to avoid malicious device attacks.

Divide and Conquer

Another way to ensure the system is safe and secured is by creating a segmented IoT management environment, in order to achieve compartmentalization among the devices as well as avoiding single point of failure (SPOF).

That is, not only the system should be redundant, it should also break into multiple sub-systems (or services), where each sub-system is responsible only to a pre-configured set of devices. That way, a potential multi-million device attack could only harm a specific sub-system, which can be quickly shut down and recovered without affecting the rest of the IoT environment.

Talking about segmentation, it is also applicable and much more effective in the area of connected devices. In order to avoid a malicious device performing systemic damage to both the management system and other devices in the network, we can use the segmentation principal between the devices themselves, such that all devices are incapable of infecting other devices. By doing so, a worming procedure refrains.

The creation of an isolated inter-device environment with even a higher degree of security requires a security-oriented hardware architecture that emphasizes physical separation rather than logical separation.

Spectre and Meltdown are classic cases in which the physical medium has been breached in the first place, and a logical disruption of the processor's operating principle is what caused the security mechanism to collapse. As the pure hardware does not have an antivirus protection and the firmware can be breached with the skilled brain, creative hardware solutions should be used to prevent such incidents from recurring in the future.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access