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

 

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 OMTPwhere, 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:

IoT Security Resources

This is a list of useful documentation and links for anyone interested in IoT security, either for building products or as general reference material. The list is alphabetical and doesn’t denote any priority. I’ll maintain this and update it as new documentation gets published. Please feel free to add links in the comments and I will add them to the list.


Privacy-specific:


Additional papers and analysis of interest:

With special thanks to Mike Horton, Mohit Sethi, Ryan Ng and those others who have contributed or have been collecting these links on other sites, including Bruce Schneier and Marin Ivezic.


Updates:
28th August 2018: Added [GDPR] Article 29 Data Protection Working Party, multiple AIOTI links, Atlantic Council, CableLabs, CSA, Dutch Cyber Security Council, ENISA links, European Commission and AIOTI  report, IEEE, IERC, Intel, IEC, multiple IETF links, IRTF, ISOC, IoTSF, ISO/IEC JTC 1 report, Microsoft links, MIT, NTIA, CSCC, OECD links, Ofcom, OWASP, SIAA, SAFECode links, TIA, U.S. Department of Homeland Security and US Senate
3rd July 2018: Updated broken OneM2M report, GSMA IoT security assessment, AIOTI policy doc and IETF guidance links.
6th March 2018: Added NIST draft report on cybersecurity standardisation in IoT.
14th February 2018: Added IoTSI, NIST and IRTF additional links.
1st February 2018: Updated with the following organisations: ENISA, IoT Alliance Australia, ISAC, New York City, NTIA, Online Trust Alliance, OneM2M, OWASP, Smart Card Alliance, US Food & Drug Administration. Added additional papers section.
24th April 2017: Added additional IoTSF links.
5th December 2016: Added GSMA, Nominet and OLSWANG IoT privacy links as well as AIOTI security link.

24th November 2016: Added GSMA self-assessment checklist, Cloud Security Alliance research paper, Symantec paper and AT&T CEO’s guide.