UK government

Stepping up action on IoT insecurity – new laws and regulation

David RogersLeave a comment
Minister for Digital and the Creative Industries, Margot James launches the consultation

Time moves quickly in the IoT world. It seems like only five minutes since we launched the Code of Practice on Consumer IoT Security.

The staff in the Secure by Design team at DCMS have been working incredibly hard to move forward on the commitments to explore how to identify to consumers what good looks like when it comes to purchasing a connected product. Alongside this, there have been many discussions on the various different possibilities for regulation.

The Minister for Digital, Margot James has launched a consultation on new laws around the first three items in the Code of Practice – elimination of default passwords, responding to reported vulnerabilities and ensuring that software updates are provided, to a transparent end date for consumers.

The consultation is open until the 5th of June 2019 – views can be emailed to: securebydesign@culture.gov.uk or via post to Department for Digital, Culture, Media and Sport, 4th Floor, 100 Parliament Street, London, SW1A 2BQ.

The consultation states:

“We recognise that security is an important consideration for consumers. A recent survey of 6,482 consumers has shown that when purchasing a new consumer IoT product, ‘security’ is the third most important information category (higher than privacy or design) and among those who didn’t rank ‘security’ as a top-four consideration, 72% said that they expected security to already be built into devices that were already on the market.”

Importantly and one component of what we need to work to solve is this issue:

“It’s clear that there is currently a lack of transparency between what consumers think they are buying and what they are actually buying.”

Identifying products that have been designed with security in mind

As the cartoon below demonstrates – explaining security to consumers is difficult and could confuse and scare people, so a balance needs to be found. What the government is proposing in its consultation is to provide a label that explains some measurable elements about the security design approach of that product.

So how do you go about identifying how secure something is?

The answer is – with great difficulty. Even more so in the modern world, because the security properties of a device and service are not static.

To explain this a bit further – all technology will contain vulnerabilities that are not known about yet. These could be issues that are known types of security vulnerability, but that are buried and haven’t been caught during the design and testing process. When you have thousands, maybe even millions of lines of code, written by multiple people and from different companies, this isn’t unexpected. For every piece of software there will be a certain number of bugs, some of these will be security vulnerabilities and a smaller sub-set of these will be “exploitable” vulnerabilities – i.e. those that an attacker can use to do something useful (from their perspective!) to the system.

So this shows why software updates are critically important – in fact even some of those bugs that are not exploitable could in the future become exploitable, so deploying software updates in a preventative manner is a hygienic practice. It is a form of inoculation, because we all benefit from systems being patched, it reduces the number of systems that will be impacted in the future and therefore reduces the potency of attacks which have a major global impact. This of course is paramount in the internet of things, because everything is connected and the onward impact on peoples’ lives could become safety-impacting in some way. We have moved past the time where systems being disabled or unavailable were an inconvenience.

So what does a label give us? Well at this stage – what we can do is help a consumer make an informed purchasing decision. Answering questions like “how long does this device get security updates for?” is really useful. It also means that those companies that have no interest in providing updates (even though they’re critical to provide) can no longer hide behind anything. It’s there for the buyer to see – if you don’t provide the updates, the consumer is free to choose not to buy your product. Not really good business to ship rubbish anymore is it?

Regulation of the Code of Practice security measures

The intention by the government is to pass the Code of Practice measures into law over time. On the regulatory side of the top three from the Code of Practice, the government has boiled down the consultation to three potential options:

“
● Option A: Mandate retailers to only sell consumer IoT products that have the IoT security label, with manufacturers to self declare and implement a security label on their consumer IoT products.
● Option B: Mandate retailers to only sell consumer IoT products that adhere to the top three guidelines, with the burden on manufacturers to self declare that their consumer IoT products adhere to the top three guidelines of the Code of Practice for IoT Security and the ETSI TS 103 645.
● Option C: Mandate that retailers only sell consumer IoT products with a label that evidences compliance with all 13 guidelines of the Code of Practice, with manufacturers expected to self declare and to ensure that the label is on the appropriate packaging.
“

From a personal perspective, I find it fantastic that we’ve reached the point where we can get rid of a lot of the products that are blighting the market with blatant insecurity. Good riddance I say and let’s celebrate the companies that are really paying attention to consumer security.

The security label will be run on a voluntary basis by retailers until regulation comes into force and legislative options are taken forward. The consultation also includes example designs that could be used. Interestingly when DCMS carried out a survey into what types of icons would be best, a padlock option was selected by less than 1% of participants. To me, what this reflects about the state of browser and web security and how we communicate security to users is somewhat depressing, but it serves as a reminder that trust is hard to earn, but easily lost.

This work is just another step down the road for globally improving IoT security. Again, it’s not the be all and end all, but it is a positive step and yet another example that the UK is leading the world by taking action, not just talking about IoT security.

A Code of Practice for Security in Consumer IoT Products and Services

mobilephonesecurity936843331Leave a comment

 

Today is a good day. The UK government has launched its Secure by Design report and it marks a major step forward for the UK for Internet of Things (IoT) security.

Embedded within the report is a draft “Code of Practice for Security in Consumer IoT Products and Associated Services”, which I authored in collaboration with DCMS and with input and feedback from various parties including the ICO and the NCSC.

I have been a passionate advocate of strong product security since I worked at Panasonic and established the product security function in their mobile phone division, through to the mobile recommendations body OMTP where, as the mobile industry we established the basis of hardware security and trust for future devices. We’re certainly winning in the mobile space – devices are significantly harder to breach, despite being under constant attack. This isn’t because of one single thing; it is multiple aspects of security built on the experiences of previous platforms and products. As technologies have matured, we’ve been able to implement things like software updates more easily and to establish what good looks like. Other aspects such as learning how to interact with security researchers or the best architectures for separating computing processes have also been learned over time.

Carrying over product security fundamentals into IoT

This isn’t the case however for IoT products and services. It feels in some cases like we’re stepping back 20 years. Frustratingly for those of us who’ve been through the painful years, the solutions already exist in the mobile device world for many of the problems seen in modern, hacked IoT devices. They just haven’t been implemented in IoT. This also applies to the surrounding ecosystem of applications and services for IoT. Time and again, we’re seeing developer mistakes such as a lack of certificate validation in mobile applications for IoT, which are entirely avoidable.

There is nothing truly ground-breaking within the Code of Practice. It isn’t difficult to implement many of the measures, but what we’re saying is that enough is enough. It is time to start putting houses in order, because we just can’t tolerate bad practice any more. For too long, vendors have been shipping products which are fundamentally insecure because no attention has been paid to security design. We have a choice. We can either have a lowest common denominator approach to security or we can say “this is the bar and you must at least have these basics in place”. In 2018 it just simply isn’t acceptable to have things like default passwords and open ports. This is how stuff like Mirai happens. The guidance addresses those issues and had it been in place, the huge impact of Mirai would simply not have occurred. Now is the time to act before the situation gets worse and people get physically hurt. The prioritisation of the guidance was something we discussed at length. The top three of elimination of the practice of default passwords, providing security researchers with a way to disclose vulnerabilities and keeping software updated were based on the fact that addressing these elements in particular, as a priority, will have a huge beneficial impact on overall cyber security, creating a much more secure environment for consumers.

We’re not alone in saying this. Multiple governments and organisations around the world are concerned about IoT security and are publishing security recommendations to help. This includes the US’s NIST, Europe’s ENISA and organisations such as the GSMA and the IoT Security Foundation. I maintain a living list of IoT security guidance from around the world on this blog.

So in order to make things more secure and ultimately safer (because a lot of IoT is already potentially life-impacting), it’s time to step things up and get better. Many parts of the IoT supply chain are already doing a huge amount on security and for those organisations, they’re likely already meeting the guidance in the code of practice, but it is evident that a large number of products are failing even on the basics.

Insecurity Canaries

Measuring security is always difficult. This is why we decided to create an outcomes-based approach. What we want is the ability for retailers and other parts of the supply chain to be easily able to identify what bad looks like. For some of the basic things like eliminating default passwords or setting up ways for security researchers to contact in the case of vulnerabilities, these can probably be seen as insecurity canaries – if the basics aren’t in place, what about the more complex elements that are more difficult to see or to inspect?

Another reason to focus on outcomes was that we were very keen to avoid stifling creativity when it came to security solutions, so we’ve avoided being prescriptive other than to describe best practice approaches or where bad practices need to be eliminated.

The Future

I am looking forward to developing the work further based on the feedback from the informal consultation on the Code of Practice. I support the various standards and recommendations mapping exercises going on which will fundamentally make compliance a lot easier for companies around the world. I am proud to have worked with such a forward-thinking team on this project and look forward to contributing further in the future.

Additional Resources

I’ve also written about how the Code of Practice would have prevented major attacks on IoT:

Need to know where to go to find out about IoT security recommendations and standards?

Here’s a couple more things I’ve written on the subject of IoT security: