Consumer Readable Security Labels for IoT devices

Written by on May 24, 2016 in Features with 0 Comments

The roll out of Health Internet of Things (IoT) is being inhibited by our current inability to communicate the relative security around these IoT systems and devices. Such specific communication of relative security will have to be targeted at the broadest citizenship, and needs to empower individuals to make informed choices about the technologies that impact them.

In an important consumer survey by Accenture released in early 2016, security concerns were identified as a key inhibitor of IoT growth. This survey noted that it is not the technical security challenge per se that is the inhibitor, but rather the lag in addressing consumer experience concerns regarding safety of IoT devices/ services. Most of these concerns can be attributed to the current state of poor communication with the ultimate consumers of the services they are offering.

This paper proposes a mechanism based on widely adopted food and energy efficiency labelling convention to deliver a consumer-friendly security rating for IoT offerings. Typically the convention has five or seven steps, and often includes a traffic light colouring scheme.

What is Internet of Things security, and how does it affect health technology?

The internet of things is the migration of instrumentation and active devices from the single purpose industrial SCADA networks of the past to the much cheaper publicly available internet.  This shift can deliver ROI orders of magnitude faster, and in doing so will create new business models and applications for devices and instrumentation. The downside of this advance is that the internet is a shared space, and additional steps are required to protect the users of IoT, as well as the value created through IoT.

The medical industry is merely one of many verticals that can exploit the shift to IoT, but what makes it particularly cautious in adoption is health systems’ greater need for privacy and patient confidentiality.

I see at least five independent ways software can be guaged for levels of security. They are malware, interoperability, resilience, identity/authentication/authority and privacy.

The Malware Threat

The malware threat is the potential to replace or modify the original software on a device with an unauthorised version. The question is how the user of a system can be sure the software code on the device is the right code, given that the bulk of IoT devices would not have a capable user interface. There are also secondary issues about healing the device if it is found to be suspect, as well as more mundane needs such as automated software upgrades and patches.

Any connected device can be repurposed by hackers. It can be subtle, like the Stuxnet attack, or it can be brutal, similar to current ransomware attacks. It could also be a parasitic deployment, simply using the device’s capability for unauthorised actions such as DDoS attacks on other remote targets.

Current secure proposals advocate VPN utilisation, but the absolute scalability of this is yet to be demonstrated. Solving this at the scale and at the degree of openness required to serve millions of citizens each with many devices is going to take time to solve.

There is no single best level of protection, but there should be a best way of describing the relative security on offer. There are also different levels of ‘good enough’ to be considered here. Pure activity instruments akin to a FitBit may only need to have their software confirmed once a month, but internet connected clinical devices delivering drugs may need near continuous assurance against hijacking. Of course usability may be compromised by additional security, as will cost of ownership, as each additional security measure will require additional effort during fault isolation or other device maintenance.

The challenge here is not so much the actual security capability of the device, but how to communicate this to both the purchaser and the user of the system in a way that accurately reflects the appropriate security levels.

 The Interoperability Threat

The current state of the industry is fragmented, and whilst each device manufacturer believes that they could potentially provide a complete set of solutions there will be little incentive to standardise device interoperability. The problem is compounded by heterogeneous enterprise management systems that any device may be expected to interact with in real world clinical or care organisations. This enterprise diversity is both a function of each enterprise’s past technology choices, as well as the differing regulatory environments that impact the medical IoT space in different countries. This diversity makes it difficult for effective controls to be imposed on IoT devices, making them vulnerable to potential security threats

The interoperability threat surface is further increased by heterogeneous interfaces between devices and the controlling service provider systems. While it is possible to integrate most things, if the starting assumptions between devices are very different, then the interfaces are going to have to be more complex to compensate. If this is the case, then if these interfaces are compromised it may be difficult to recognise the out of normal condition cause by the problem.

One likely scenario for resolving this diversity problem is the growing practise by device manufacturers to abstract the software side of their product from the hardware side. Samsung has its platform Samsung SmartThings, and Canonical has been able to support a range of devices and manufacturers by using Snap Ubuntu Core as a common device operating system. A further such abstracted approach is proposed by Tom Nolle in this blog in which he suggests that IoT devices can be virtualized, and many of the risks can be mitigated by having the vulnerable portions of the device service delivered via the cloud as virtual devices. In these abstracted forms of architecture an enterprise user can deliver custom apps to each physical or virtual device to gain control of the IoT solution in a similar way to how corporate mobile apps can extend enterprise applications to smart phones. In these architectures the diversity of devices is masked by the software interacting with them.

There are currently no widely accepted ways to describe the relative interoperability of any components, but such a commonly agreed to description of the relative strengths is vital as we are going to constrain the growth of IoT without it.

Technical Resilience

The technical resilience of a connected device is a well-known security concern, albeit expensive to verify. Such verification of technical resilience is based on the manufacturer’s ability to control and build the software to the quality intended.

Each step in the software lifecycle can introduce or mitigate risks and threats, and numerous standards and technologies exist to deal with these. In every coding language there are best practises to be met if the device is to remain resilient to faults and attacks. Even the choice of a code compiler can affect the resilience of code.  Common vulnerabilities such as e.g. stack overflows create the same risks in IoT as they do in other applications

In this sense the software associated with IoT devices has the risks as any other.

Such best practices and choices are regulated by numerous existing industry-wide standards and technologies.

Currently, however, there is no overarching meta-rating which makes intelligible the relative strengths of competing standards, rating them from an end-user viewpoint.

 Authority, Authentication and Identity

If a device is connected, we have to concern ourselves with the relative strengths of the authentication to access the device or its data. A particular challenge here is that most of our current exposure to authentication is for human operated devices, and the IoT devices will need equalling good automated authentication at scale.

A follow-on concern is what authorisations are granted to authenticated users. Early evidence indicates that attempts at simplicity have delivered coarse-grained rights, with many implementations receiving overprivilege beyond what the developers intended or needed.

As there are different mechanisms which manage rights and access to devices through identification, we need the ability to rate the strengths and weaknesses of each of these mechanisms relative to each other. This rating must also cover how security certificates are handled, and how closely such certificates are managed.

This authentication and rights issue is further compounded by the failure to distinguish between device management rights and device capability rights on many devices. To further compound the issue, any rating of strengths and weaknesses must apply separately to device management rights and device capability rights.


The privacy of patient data debate has to some degree been overtaken by European regulatory activity to the extent that any player wishing to be active globally will need at least the ability to meet European requirements. Nonetheless, there is room in the wider market for IoT devices with both lesser and greater privacy. The reason for this rage in privacy is balancing ease of use against potential harm from privacy breaches.

The intended level of privacy-security needs to be shared with the intended end user of the device. Nonetheless, the potential for room in the wider market for both tighter and lesser privacy exists and will need to be shared with the intended end user of the device.

The Accenture study referred to earlier in the paper highlights that IoT security threats mostly exist to exploit vulnerabilities to access users’ private data.

Any evaluation of privacy threats must include what data is within the system, and how it becoming available by unauthorised access will will impact the user and their life. In particular, French efforts have focused on rating the relative ease of linking a data set to an individual, and the harm ( be it social, reputational, health or economic) that could arise from the exposure of such information.

 What is our solution, how do we address this?

The security communication challenge that faces developers, manufacturers and user of IoT devices is not unique. Many of the things we buy have characteristics that can pose long term risks. A simple visit to your local grocery store can reintroduce us to an established format for conveying product risk to consumers.

The graphic shown in this image illustrates how on very ordinary food products available in the UK the consumer is provided with data to establish the nutritional risks inherent in the product. The simple graphic shows the food calories present, the sugar included, the fat present (saturated or not), and the salt added to the tin of baked beans. This type of standard usually also includes a suggested colour scheme, and a minimum of supporting information.

Can this format be applied to IoT goods?  The American Federal Communications Commission (FCC) thinks so, and is currently encouraging broadband providers in the US to describe the performance characteristics of their offers in this way.  In this voluntary move, service providers are requested to depict standard service metrics such as bit rate and availability as graphs in this format.

So we can imagine that a suitable rating scale can be found to describe the relative risk in each of the threat surfaces discussed in this paper regarding IoT Security. Each of these rating scales can be sourced from a suitable industry group, or where possible, via a regulatory body.  Some security dimensions are easier to deliver than others, but this can be a staged release, maturing as the concept develops.  This is in line with what we see on commonly bought consumer products. In the graphics displayed on such consumer products we have seen a shift in perceived health concerns over the last decades: initially concerns were saturated fat and calories that were considered harmful, but now with low carbohydrate diets sugars and carbohydrate levels are scrutinised as well. This demonstrates the flexibility of the scale to adapt to new concerns so that if additional security dimensions become prominent in future years, the citizenship at large already is used to the evolution in the format.

We would also have to look at how to govern a labelling convention such as this. There are two distinct areas to manage.

The first is that of how the rating scales are set up and distributed in the first place. This concept would need to pitch itself to a suitable standards body, be they government aligned or not. These regulatory bodies typically would then source any specific expertise via industry aligned bodies.

The second challenge is to ensure the rating scale stays current, and reflects the ever evolving state of technology. This would require the ongoing engagement with thought leaders in each of these disciplines.

What can go wrong?


For the most part, this form of labelling is voluntary for the product manufacturer. Examples where market maturity has reached mandatory imposition are common in the energy field, with mandatory efficiency rating in many housing, car and appliance markets. In most cases the metrics are self-published by the product manufacturer, raising the possibility of false reporting and labelling.

The risks inherent in being less than truthful in this respect are currently being explored in depth by Volkswagen, the motor manufacturer that has recently relinquished its place as the world’s largest automobile manufacturer due to incorrect reporting of measured values. In an IoT market the risk is likely to be borne by service providers, but the service providers are unlikely to tolerate the risk associated with inaccurate device manufacturer security reporting.


The technical world will evolve during the lifecycle of any security standard.  Significant threats will become easily avoided, and new threats will arise. The proposed labelling meme has seen this form of change already.

There are two popular mechanisms to address this.

The simplest was adopted by the appliance industry where ever improving energy efficiencies lead to the addition of A+ ratings on the A to G scale they used. Subsequent improvements now allow the consumer to even buy A++ fridges.

The other mechanism is to flag the scale to a particular release, typically expressed as a year. The widely respected ASEAN/NCAP automobile collision ratings follow this form, using a maximum of five stars to express an ever evolving set of safety concerns.

 Summing Up

This white paper is a call to address a key gap in the IoT solution space with experience drawn from widely adopted consumer practice. The proposal to apply food labelling meme to IoT security has its challenges, but these are no different to the challenges the concept encountered as it was adopted by numerous markets.

We at least know that the consumers know how to interpret this communication.

So, who wants to help, and where can we start?

Tags: , , ,

About the Author

About the Author: Hugo Vaughan is a telco architecture type who has worked in mobile and consulting around the world. He is currently living in the UK, tasting the village life. .


If you enjoyed this article, subscribe now to receive more just like it.

Subscribe via RSS Feed

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.