The 'unknown unknowns' of IoT security

Security design for IoT devices
According to current projections, by the year 2020 there may be more than 40bn connected things – outnumbering the projected human population of 7.7bn by five to one. These complex networks of connected things will increasingly become vital elements of our critical infrastructure and will control and monitor essential life safety systems such as medical devices, traffic control, and power grids.

As the Internet of Things (IoT) evolves, our dependency on it will grow exponentially. With complexity comes hidden vulnerabilities; the 'unknown unknowns'. We cannot fully predict where security weakness lies because no single group has full access to all the code and hardware. Nobody can understand every nuance of such complex systems and that is why the developer and the system administrator cannot make assumptions about security. Code is mostly written on top of layers that the developer doesn’t have access to or doesn’t have time to fully understand and our nodes (routers) are connected to other nodes that we don’t have access to. Unfortunately, history shows us that security lags behind innovation and that security development tends to be reactionary and not intrinsic to the architecture. The first step for a secure IoT network is to design it. Security must be designed from the beginning and it must be at least considered and thought about in every element of a system. The design must address the three pillars of security: data integrity, privacy preservation, and availability.

Network resilience is important for ensuring data integrity, safeguarding privacy, and providing high availability. It affects all three pillars of security. If you think of an IoT device as a biological entity, attack resilience and defense is like the immune system and the attackers are malicious viruses and bacteria. This model is apt in many ways. Terms such as immunisation and infection outbreak are often used to describe the spread of malware and dissemination of anti-malware software to networked devices. Epidemiological mathematical models that predict the spread of epidemics among people have been successfully shown to apply to the rate of malware spread and infection, the rate of infection recovery, and the length of time for malware incubation.

To accomplish resilience, like the immune system, the defense system must first detect the threat. It must perform the difficult task of knowing what is a normal operation and what is suspicious. A sudden increase in network activity, for example, may raise a red flag as a possible attack but may be legitimate in non-normal situations such as extreme weather conditions or large gatherings. A system that is too slow or too lenient in detecting an attack or a breach will be vulnerable to high bandwidth or distributed attacks. Often the attacker will rely on speed and will prepare for a single massive attack by gathering intelligence and quietly deploying dormant 'bots' on vulnerable devices over the period of months and sometimes years. When it comes time to attack, these sleeper agents are called to action and it’s often the scale that makes it successful because the victim system doesn’t have time to react. The system administrator is not aware of it until after the attackers have accomplished their goals. This is especially true for IoT nodes because the system administrator cannot monitor the health of so many devices in real-time. The IoT network should be designed so nodes are able to monitor adjacent nodes like a true neural network. If a node becomes compromised, adjacent nodes can react quickly and either gather intelligence or execute routing decisions to mitigate the attack. Intelligence gathering is critical for performing post mortems and development of immunisations, which will lead to quicker threat detection and therefore greater resilience.

On the other end of the scale, an overactive threat detection is also a problem as it may disable normally functioning nodes and unwittingly cause instability and/or availability issues. To extend the biological analogy, this can be compared to autoimmune diseases in people such as rheumatoid arthritis where the body attacks itself, incorrectly believing there is a threat. Overactive threat detection is also a tax on resources such as power, memory, CPU, and bandwidth. These resources tend to be limited in IoT devices and even as the technological advances in efficiency give a greater cost-to-feature ratio, the rate of replacement will be slow. IoT devices will be low powered and unlikely to be inspected by humans for long periods of time. Adding unnecessary processing to threat detection would increase costs and reduce the Return On Investment (ROI) for an IoT deployment. The goal is to find the optimal balance where an acceptable ROI threshold and integrity are achieved.

One might question why it’s necessary to invest in effort designing security for minor edge devices, such as a sensor that detects whether a plant needs watering. If a hacker could disable this device would it destabilise the network? Not likely. This is why such devices would not be targets for hackers who want to destabilise a network. To achieve this, a hacker would likely attack IoT router nodes. Every neural network has a tipping point where it fails when enough nodes are taken down and since some nodes are more important to stability, the attacker will look for these 'super nodes'. This is called a centrality attack. Network design is a key factor in network resilience, specifically routing and wiring. If possible, edge devices should be dynamically routable. The ability to dynamically change the topology of the network will help defend against centrality attacks. This is called a Topological Defense Scheme. There are other defense schemes for networks that cannot be virtually or physically re-wired due to constraints such as geolocation restrictions or protocol limitations. I will expand on centrality attack defense schemes in future articles.

While an attacker would not target edge devices to disrupt availability, they might be interested in looking at the data it’s collecting. This is a passive attack and it’s an attack on privacy. When designing for data privacy, it has to be assumed that a node will be compromised and data will be leaked. In many cases, devices will be deployed in remote locations where they cannot be physically secured. These devices can be physically stolen and encryption keys retrieved. Content and context data can be stolen. How can privacy be defended in this case? To answer this, we must look more closely at the definition of data privacy. A simple definition might be: 'guarantee that data is observable by only those who are supposed to access it.' In reality, it’s not so black and white. Data privacy should be measured in tolerance levels. If a patient is wearing a heart monitor, for example, we want to protect this data from being leaked. It may, however, be tolerable that the data is leaked if it doesn’t identify the patient. The tolerance boundary, in this case, is how close we want to get to the identity of the patient. This may include the granularity of the geographic location of the patient such as city, neighborhood, block, etc. When designing data privacy this metric must be expressed in initial stages of design and not as an afterthought. Architecture design decisions should be driven by these metrics.

Each IoT domain has its own set of security challenges. Because of the ad-hoc nature of automobile networks, for example, unauthorised vehicle tracking and impersonation (Sybil attacks) are threats. I plan to cover other IoT domains and their security challenges and defense schemes in future articles.

As the number of IoT devices explodes it’s clear why security is important. Like all biological systems, IoT networks are in a perpetual war with attackers. The attacker and defender evolve together. The initial architectural design of an IoT system must be flexible enough to allow evolution. Quantifiable security requirements should drive the design. As features are designed, security questions should be asked such as:

• What are the privacy tolerance levels?
• What level of availability is required?
• What are the impacts of loss of availability in terms of overall stability?

These questions will affect the topology of the network, communication protocols stacks, and firmware / software design. In my next article, I plan to expand on these security design questions and explore how security design can be driven by requirement metrics.