Time Is Not On Your Side for IoT Security

IoT Vulnerabilities

A Microsoft IoT study shows 97% of IoT adopters have concerns over security. Well, aren’t we all concerned about security? I believe so, but I don’t believe we are equally concerned. Companies are concerned because they hear that other companies (or the whole industry) are concerned about it. But do they really know what to be concerned about? What are the risks and vulnerabilities for IoT specifically? Should a sensor, camera, pacemaker, traffic light, and car all have the same level of security concerns? Does it actually matter?

IoT Vulnerabilities

The same Microsoft research says that despite these concerns, security is not a barrier to implementing more IoT technology. What the research does not say is if companies are forging ahead because decision makers are simply discounting security, or because they believe they are sufficiently on top of it and the solution they’ve chosen is secure enough. Let’s hope it’s the latter.

In both cases, IoT vulnerabilities present risks too serious to be overlooked. New vulnerabilities are discovered constantly and we should do more than just keep an eye on them.

Threats to IoT can be grouped into three main categories:

Threats to IoT can be grouped into three main categories

IoT vulnerability and threat categories This list is not exhaustive and still it may be discouraging. From the 97% with concerns, a percentage will still not be compelled to not just overlook the threats, much less dig into the specific vulnerabilities corresponding to their IoT application. This is compounded if they believe their project is not critical. A company implementing an ordinary (dumb) sensor solution with certain non-sensitive information would definitely not look at data leakage or interception the same way a company implementing remote monitoring of a critical service would. Both would most certainly assess the risk of attack on a two dimensional risk matrix differently.

IoT risk matrix
Figure 1 Current IoT Risk Matrix

While both are concerned by security, most likely the dumb sensor project would be analyzed as low-consequence and therefore less probability of happening. Put another way, if nobody has much to gain from attacking such a device, there is little chance anyone will bother.

IoT Startups

Also, when starting an IoT project, there is pressure to do a PoC–and quickly. The mindset is more about trying quickly rather than trying securely. This is against one of the pillars of security: “security by design,” vs “security after, whenever we have customers.” The risk inherent in this attitude is that it might be too late afterward–too late to change a provider in the chain, device, connectivity, application, etc.

IoT Security Solutions

In Figure 1, the network and IoT/Application server area can be protected with well-established and reliable security mechanisms: VPN, dedicated connection, and signaling firewall, which can be easily managed and maintained over time. Big data is increasingly incorporated into these systems as a way to more efficiently detect, identify, and categorize threats which can be dealt with more quickly thanks to AI-powered defense solutions.

However, for endpoint devices, it is different. First there are many different device types, and they all offer different levels of integrity. Secondly, they will be in the field for five to ten years, which implies they are vulnerable to physical attacks, and updating software can be a challenge. Thirdly, they are more subject to human interaction and error throughout their whole life cycle management. Devices themselves need to be considered the weakest link.

There are some solutions to secure the device and its access: avoid default password, use the SIM as root of trust (GSMA SAFE initiative), proper code signing of the device’s software, and other basic guidelines to follow. Even still, we should assume they will be hacked–eventually.

Consequences

When IoT devices are hacked, they open a security hole in an IT infrastructure and can be used to access sensitive data, either from the device itself or from the IT infrastructure. In a well-known incident, the connected fish tank of a casino in Las Vegas leaked several gigabytes of sensitive data. Hacked devices not only present direct consequences for the IoT application or user data, but also the indirect benefits for the hackers who may recruit the device into a botnet. A hacked device, given it is powerful enough, can be used as a proxy for other attacks like cryptomining or DDoS. It becomes an additional tool, soldier, or weapon for hackers. Even if the consequences do not directly impact the IoT service or enterprise, the consequences of a hacked device are far greater for the rest of the internet community.

Time is a factor

In both cases, the evolution of vulnerabilities on existing deployed solutions, especially devices is in itself a threat. IoT deployment typically has a 5 to 10 year life span, which in the IT/telecom world is an eternity (remember that Whatsapp barely existed 10 years ago). Just as technology evolves for everyone, it evolves for hackers, and they eventually find new ways to access devices and information. Any project’s risk will increase in both probability and consequence over time.

Figure 2 Future IoT Risk Matrix
Figure 2 Future IoT Risk Matrix

Future-proof Security

While different IoT solutions may be concerned about security, they have different levels of interpretation of these concerns. IoT will have to live with vulnerable devices, just as the internet lives with DDoS noise and viruses. This is not to say there is nothing that can be done: the best security measures shall be set up to react to emerging threats, complete with big data and AI to detect these threats and mitigate them both in IP and signaling network protocols. Even so, one thing is certain: the device and time itself will lead to more vulnerabilities, therefore security must be rigorously maintained for the life cycle of all devices.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>