Internet of Things - Top Ten concerns

Mark O'Neill suggests that his top ten potential vulnerabilities of the Internet of Things (IoT), need to be considered now, before mass deployment.

Internet of Things - Top Ten concerns
Internet of Things - Top Ten concerns

The Internet of Things (IoT) promises to open up new ways of doing business and communicating, from smart meters tracking electricity usage to fitness tracking wristbands, and the “connected car”.  But with IoT it's two way communication as devices transmit and receive data. This data is often private and users may not even be aware that it is being generated and transmitted. So what solutions can you put in place to mitigate the risks?

1.     Protocol Proliferation

The web was built on a relatively simple core of HTTP, HTML and Request/Response protocols which enable security architects to deploy security services across their web applications through one protocol.  But IoT protocols include CoAP, XMPP, AMQP and MQTT. Security architects now often span protocols, rather than relying purely on Web-based solutions.

2.     Initiation

Connected objects are initiating action, so a fitness tracking wristband can connect straight to a cloud service for fitness analysis.  The old Request/Response model cannot be relied upon for all message exchange patterns with other protocols forming part of the mix. Each of these protocols has its own specific message-exchange patterns, such as publish subscribe, request only, and request callback, in addition to the usual request/ response pattern. The security architect must map security protocols onto these communication protocols and their respective message-exchange patterns.

3.     Access Keys

Securing keys is fundamental to IoT security or devices will be left open to attack. Keys on connected devices can be subject to tampering while key storage on the server side introduces distribution and availability challenges. It's impossible to predict all of the different communication protocols IoT implementations will require, but they will definitely need to solve: authentication, integrity and in some cases confidentiality issues.

4.     Naming

Identifying human users is reasonably accurate using Active Directory, LDAP and application user databases, but the equivalent for all objects doesn't exist so we're still not able to consistently identify objects.  But every program must answer the question – who has access to do what? Name directories that enable assigning and managing the object's rights, roles, and groups in a “thingfrastructure” are central to addressing questions around IoT access control.

5.     Constrained Devices

Deployments are often limited by the level of device processing power. Scalability includes being able to scale back, which is just as important as increasing,  and can be just as problematic. IoT system designers cannot architect based on an assumption of the same level of processing power, storage or bandwidth characteristics of an enterprise-class network. So the security protocols of the IoT has to negotiate across a resource-constrained environment. Consider sensors in cars, or small wearable devices; these do not have high processing power but by using a gateway, high performance security layers can be deployed remotely.

6.     Time Services

Many IoT applications can't apply the time-based security protocols they rely upon, yet authentication protocols use time as a primary defence mechanism. Devices cope with threat by limiting retries eg, of password or pin. Lack of time services puts the device at a disadvantage. Logging systems report who did what, and when, but without access to time services they may tag onto alternate ways to identify events, such as incrementing an event ID counter. This approach can also report on sequences.

7.     Usability

In the IoT, subjects are usually things so reverse engineering is a threat. Devices can be disassembled to understand their behaviour and exploit them. An API management gateway can help by acting as an intermediary; clients see the gateway as the service itself, and the gateway can perform security duties that the client is unable to perform.

8.     Patching

There will be vulnerabilities so it's essential that patching is addressed. Without a human to install patches, a new approach is needed, whether through pushing updates or virtual patching. A gateway architecture can help, by initiating the download allowing “virtual patches” to be applied in front of the IoT device.

9.     Stunt Hacking

The IoT will have to deal with hacks carried out for money or for the intellectual challenge, but as applications with economic utility are increasingly deployed (such as smart grid or NFC payments), they will attract interest and need to be prepared for accordingly. Gateway layers can be employed to deliver protective measures against attack.

10.            Ugly Failure Modes

When IoT apps fail, so do real world things, like your power, your supply chain, your fleet tracking capability, and so on – and retry and restart functions may be difficult to impossible to implement.  Hece It's critical that developers clearly understand and anticipate the state of the system at the end of the failure mode – that is, the actual impact on the “thing” and the people who rely on it.

IoT is beginning to emerge as a reality, bringing numerous new security challenges which can and must be mitigated if the IoT is to deliver on its promise of networked objects. The “thingfrastructure” that enables IoT must be deployed using Gateways that enable enterprises to layer-on the necessary security.

Contributed by Mark O'Neil, vice president of innovation, Axway

close

Next Article in Opinion