The Internet of Dangerous Things

If you have been annoyed by Web browser popups or have screamed at your email provider for letting spam through or have been terrified by the prevalence and occurrence of malware, your frustrations are bound to increase as the Internet of Things (IoT) takes shape. IoT expands the surface area of avenues that can be used to threaten, spy and annoy you and dealing and handling these increased, diverse and potent threats will require an IoT specific security architecture that IoT vendors will need to adopt and implement.

Spectrum of Potential Threats

The spectrum of potential threats part of the Internet of Dangerous Things (IoDT) is three-fold. It ranges from simple annoyances to privacy mishaps to serious harm to the device, user and their physical surroundings. The key difference between information devices like laptops, computers and phones and the connected devices is that the “threat” now permeates into the physical, real world and this takes the threat severity of the IoDT to unprecedented levels.

Things that annoy

This class of IoT enabled devices will annoy users either through its remotely controllable capabilities or on device capabilities. This will be a result of inaccurate messages being displayed and sent to the user that distract and detract the user from more important things. This set will also include certain devices that over alarm and alert the user and cause alarm fatigue or drown out the relevant alarms in a flood of noise. This will also include devices that will intrude into the user’s workflow and break their periodic rhythms.

Things that spy

Another class of IoT enabled devices will spy and pry into the lives of their users. These devices will collect information that is beyond what the user agreed or will collect information for purposes not disclosed or consented for by the user. Things will get even worse when this information is stored insecurely or sold and shared with other parties with potential malicious intent.

Things that destroy

This class of IoT enabled devices, the most dangerous of all, will have the power to be remotely controlled and will carry significant potential for damage that will prove to be dangerous. These devices will directly or indirectly carry the capability to cause physical systems and processes around the user to malfunction, breakdown or trigger an inadvertent chain reaction that cause physical damage to the user or their surroundings.

The ‘Fault Lines and Fuses’ architecture for managing the IoDT

Detecting, preventing, protecting from and remediating the Internet of Dangerous Things (IoDT) will require vendors to invest in a new type of security architecture that I call the “Fault Lines and Fuses” architecture. The basic principle behind this architecture is two fold:

1. “Fault Lines”: Early and centralized deterministic detection of threats and attacks

2. “Fuses”: Self arresting and mitigating capabilities at the device and cloud layers.

The goal for IoT architectures should be to enable early visibility and predictability into threat and attack detection and automatic system hibernation when malicious threats are detected to ensure that the impact on the device, user and their environment is mitigated and prevented.

IoT vendors will need to invest in the following to ensure that their devices do not become part of the IoDT.

Central management of IoT alarms

Vendors should enable central management of their devices and enable users to define acceptable hours and locations (and not acceptable hours and locations) for remote device control and management of triggered notifications and alarms. This would be similar to the “do not disturb” call lists and the concept of traditional “business hours” where/when the user explicitly OKs to be contacted and engaged.

Connected device reputation management

Vendors will need to monitor and track their devices and build reputation models that can detect maliciously acting devices and circumvent their attack trajectories. In addition, vendors will need to submit their data collection, storing and sharing practices to external inspection. This will form the basis of vendor reputation used by users to determine whether or not to select a particular device/vendor.

‘Positive only’ remote actions

Vendors will need to implement Remote Action Plans that ensure that remote actions can only improve the current state and in under no circumstances, change the state to be worse off. These action valves will be required to hard code device protection from malicious remote intent.

Last mile human validation

Remote actions that carry significant risk and potential for abuse will need last mile validation by humans. Vendors will need to ensure that all such actions are always validated before they are carried out. Human validations will be required both at the vendor/service where any actions with mass impact will need to be run through the proper approval chain before rollout. Similarly, validation will be required at the device/user end before an action that can impact the user’s device and environment is carried out. Validation can be remotely delivered through mobile apps but will need to be in place for such actions to be carried out.

Pre and post action notification

Hand in hand with the last mile human validation will be pre and post action notifications delivered both in advance and as close as possible to the action taking place. These notifications will not only will enable the user to prepare or react to the upcoming change but more importantly, will enable the user to revert any actions that they do not agree or approve.

Staggered rollout of user and vendor service actions

With remote actions having the potential to carry out severe damage, any changes or actions that impact a relative large number of devices will need to be staggered with a real time feedback loop that monitors the impact and reaction to the remote action/change. If unexpected reactions are noticed, these changes/actions would need to be undone and previous state to be reinstated while the rollout progress is arrested as soon as possible with impact minimized.

Conclusion

The danger presented by IoT is bigger than what we have seen so far however, the manner in which it will manifest itself is familiar from what we have seen in the online world. Best practices to deal with this new threat are grounded in the world of online safety and abuse detection. Real time visibility, validation chains, notifications and explicit approvals will make up the core of the proposed “Fault Lines and Fuses” architecture that is designed to limit the scope and tone down the severity of IoT attacks and threats.