Legal briefing | 24 Jun 2019 |

Sshh: Alexa can hear you

We live in a connected world. And the problem with a connected world, is that every connection is potentially vulnerable to cyber attack. This is part of the reason why the Government has recently published proposals to legislate for more stringent security measures to be implemented by those who manufacture, and provide related services in respect of, consumer Internet of Things (IoT) products.

This article takes a look at the current regulatory landscape which device manufacturers, service providers and app developers must adhere to when it comes to addressing the security risks associated with both the use and proliferation of consumer IoT devices, and how this might change as a result of the Government's proposals.

What are consumer IoT products?

First, let's be clear what exactly we mean by consumer IoT products.

They include smart watches, wearable health trackers which connect to GPS and tell you how far you've walked, security alarm controls which enable you to switch your burglar alarm on with your mobile phone when you are half way down the M25, thermostats which you can activate remotely so as to get your house cosy for when you arrive home, and connected appliances such as washing machines, and fridge freezers which can alert you when the time comes to re-stock your favourite ice cream.

Another prime example is Cayla. Marketed as the "World's First Interactive Doll" and the "Smartest Friend You Will Ever Have", concerns over its use led German authorities to warn consumers back in 2017, that hackers could exploit an insecure Bluetooth device embedded in the toy to allow strangers to speak directly to children via the unfortunate doll.

The factor which all these products have in common, is that they are all connected to the internet. Which in turn poses two issues. Firstly, the potential invasion of privacy that these products expose individuals and their homes to, and the proliferation of personal data which manufacturers and service providers can now collect about users of IoT devices. The way in which Amazon's Alexa can play new music she thinks you might want to listen to, based on your preferences, is not only handy for you, but also useful for advertisers and music retailers.

Secondly, that individuals and their homes might be exposed to cyber attacks in a way which would never have been possible in an "offline" world.

Privacy by design

When it comes to personal data, you have to consider the General Data Protection Regulation (GDPR) and related data protection legislation. IoT products are complex beasts, in the sense that there are usually many different stakeholders involved in bringing them to market and ensuring their ongoing operation. Who collects and processes personal data will differ depending on what the product is, how it works, and who it is offered by. However, one thing is for sure, at least in relation to products which are put on the EU market for sale: anyone who processes personal data as a data controller in relation to that product must comply with the requirements of the GDPR (see box for details).

For data controllers, this means that:

1. Privacy by design must be incorporated into the systems they use to collect the data, the way they use the data, and who they share it with.

2. They must be transparent in terms of making it clear to those whose data they collect, what data they are collecting about them, what they are using that data for, who they are sharing it with, and where they are keeping it.

3. They must also make sure they put technical and organisational measures in place to ensure a level of security appropriate to risks imposed on individuals' privacy as a result of the data processing concerned.

4. They have obligations to respond to requests from those whose data they collect, to have access to that data, to have it deleted and ported.

5. They are obliged to report certain security breaches which have resulted in the loss of personal data.

Anyone who processes personal data on behalf of a controller (ie a data processor), will also have to comply with obligations, essentially to keep the data safe and to help the controller comply with its own obligations, in so far as the processor's activities impact on this.

So, let's take a smart fridge as an example. Really smart fridges are no longer called fridges, but have names like the "Family Hub". According to their manufacturers, they enable you to shop for food, organise your family's schedules, entertain, and even see who is at the door. They do this for example by using your smart phone to see what's inside the fridge and work out your shopping list, which you can then record on a personal organiser provided by the app, along with all your other activities for the week. Think of it as the digital equivalent to the old fashioned and decidedly offline family calendar which used to hang from the fridge door of every family home. In this scenario, it is probably the app provider (who may or may not also be the fridge manufacturer or an affiliate of the fridge manufacturer) who collects and processes any personal data which is left on your app and who must comply with the GDPR requirements outlined above.

For many IoT devices (including the smart fridge), it is most likely to be deficiencies or noncompliance in the collection, processing and storing of personal data which cause the security issue. The question that therefore follows, is, if those industry stakeholders who do process personal data are already regulated by GDPR, precisely what other concerns is the Government seeking to cover off?

Security by design

IoT products can provide would-be criminals with a point of access into your home that they would previously not have had. More likely, an ability to sabotage a device means that personal data could easily fall into the hands of cyber criminals before it even reaches the service or app provider's systems – at which point, compliance with GDPR is rather a moot point. There are also concerns that poor security could lead to devices being used for co-ordinated attacks such as Distributed Denial of Service attacks, which could in turn affect essential systems such as electricity supply.

This is part of the reason why the Government has seen fit to consult on introducing security requirements for consumer IoT products – in its view, existing legislation such as data protection or consumer protection laws, aren't sufficient to address the issue head on. Rather than leaving consumers with responsibility for securing their own devices, it prefers an approach which requires device manufacturers, IoT service providers, mobile app developers, and retailers to ensure that strong cyber security is built into IoT products by design, using three indicators to create a minimum baseline security platform for interested parties to follow:

1. All IoT device passwords to be unique and unresettable to any universal factory default value.
2. Manufacturers to provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues.
3. Manufacturers to explicitly state the minimum length of time for which the product will receive security updates.

These security indicators were first set out in the Government's Secure by Design 13 point code of practice which was launched last year on a self regulated basis, but which has not seen the level of voluntary uptake which the Government would ideally like.

A compulsory labelling scheme which confirms the minimum baseline is met, is the Government's preferred option for implementation, with retailers mandated to only sell IoT products which have a "secure" or "not secure" label attached (the actual labelling and assurance/testing obligation would rest with the manufacturer). Another option would require retailers to only sell IoT products which adhere to the above guidelines (with manufacturers again being responsible for testing and assurance).

The security baseline and labelling scheme is a good start, and a reasonable attempt to impose a meaningful level of security without overburdening manufacturers; but whether these proposals actually go far enough in bolstering the security of IoT products is an open question. For example, the baseline about security updates only requires manufacturers to state the minimum length of time for which a product will receive updates, whereas last year's code of practice went further in actively advising that software updates should be provided after the sale of a device, and pushed out to them, which in our opinion, is a more effective way to address this and helps to ensure the ongoing security of devices as far as possible, not just at the point of sale. Another point of contention is sure to be the focus on retailers as guardians of security for the devices which they offer for sale.

Time will tell whether the Government's proposals are sufficient. Perhaps our concerns lie, in part, in the stated objective of these measures, which is to restore transparency within the market and ensure that manufacturers are clear and transparent with consumers so that they can make informed purchasing decisions about the security of IoT devices. This effectively leaves it to the market to deal with security shortcomings (the Government's rationale being that in time consumers will only want to buy secure devices) – which assumes that consumers will make choices based on security rather than, say price, branding or functionality. We wonder whether this is the right focus for regulation, or whether the objective should be aimed more at achieving similar security standards to those set in GDPR – namely, for manufacturers to actually take measures to ensure as far as they can, a level of security in consumer IoT products which is appropriate to the risks they pose, supported by meaningful sanctions for breach.

In their current form, the requirements put forward in the consultation would not, in our view, significantly add to the burden faced by those service and app providers who already have to comply with the high bar set by GDPR; the main difference is that whereas currently, those with GDPR obligations will seek to pass back any relevant obligations to the manufacturer via their contract with them, the Government's proposals would, for the first time, widen the net by imposing some sort of security responsibility directly on all manufacturers. The consultation closed earlier this month; as yet no date has been set for next steps, however it will be interesting to see industry and the Government's response in due course.