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:

Dead on Arrival? What’s next for IoT security?

IoT security is in the news again and it is pretty grim reading. The DynDNS distributed denial of service (DDoS) attack caused many major websites to go offline. Let’s be clear – there are many security companies who have suddenly dumped all the insecure webcams and routers that have been out there for years into the new world of the Internet of Things. It is semantic perhaps, but I think somewhat opportunistic because much of the kit is older and generally not your new-to-market IoT products. There is however a big issue with insecure IoT products being sold and if not today, tomorrow will bring further, much worse attacks using compromised IoT devices across the world.

We’re at the stage where we’re connecting more physical things and those things are often quite weak from a security point of view. It appears that it has only just occurred to some people that these devices can be harnessed to perform coordinated attacks on services companies and people rely on (or individuals in the case of Brian Krebs).

I fully agree with Bruce Schneier and others who have said that this is one area where government needs to step in and mandate that security needs to be baked in rather than half-baked. The market isn’t going to sort itself out any time soon, but mitigation, both technical and non-technical can be taken in the interim. This does not mean that I am expecting marks or stickers on products (they don’t work).

There are some quite straightforward measures that can be requested before a device is sold and some standards and recommendations and physical technology is available to create secure products. Some of the vulnerabilities are simply unforgivable in 2016 and the competence of these companies to be able to sell internet connected products at all has to be questioned. Those of us who are in industry often see the same companies time and time again and yet nothing ever really happens to them – they still go on selling products with horribly poor levels of security. The Mirai botnet code released in September targets connected devices such as routers and surveillance cameras because they have default passwords that have not been changed by the user / owner of the device. We all know what they are: admin, admin / admin, password and so on. https://www.routerpasswords.com/ has a good list. With Mirai, the devices are telnetted into on port 23 and hey presto, turned around for attack.

I did notice that there is an outstanding bug in the Mirai code to be resolved however, on github: “Bug: Fails to destroy the Internet #8”

Your company has to have a security mindset if you are creating a connected product. Every engineer in your organisation has to have security in mind. It is often easy to spot the companies that don’t if you know what you are looking for.

Is there another way?

At the grandly titled World Telecommunications Standardization Assembly (WTSA) starting next week in Tunisia, many countries are attempting to go further and introduce an alternative form of information management based around objects at the International Telecommunication Union (ITU) (the so-called Digital Object Architecture (DOA) technology). Some want this to be mandated for IoT. It is worth having a look at what is being proposed because we are told that the Digital Object Architecture is both secure and private. Great, surely this is what we need to help us? Yet, when we dive a bit deeper, that doesn’t seem to be the case at all. I won’t give chapter and verse here, but I’ll point to a couple of indicators:

According to information handle.net, the DOA relies on proprietary software for the handle system which resolves digital object identifiers. Version 8.1 released in 2016 has some information at: https://www.handle.net/download_hnr.html where we discover that:

• Version 8 will run on most platforms with Java 6 or higher.

A quick internet search reveals that Java 6 was released in 2006 and reveals plenty of issues. For example “Java 6 users vulnerable to zero day flaw, security experts warn” from 2013. This excerpt from the articles states “While Java 6 users remain vulnerable, the bug has been patched in Java 7. Java 6 has been retired, which means that updates are only available to paying clients.”

Another quick internet search discovers “cordra.org”. Cordra is described “as a core part of CNRI’s Digital Object Architecture”. In the technical manual from January 2016 on that site, we find information on default passwords (login: admin, password: changeit).

“Cordra – a core part of the Digital Object Architecture” – default passwords

If it looks bad, it usually is.

These things are like canaries – once you see them you end up asking more questions about what kinds of architectural security issues and vulnerabilities this software contains. What security evaluation has any of this stuff been through and who are the developers? Who has tested it at all? I’ll come back to the privacy bit at a future date.

The Digital Object Architecture is not secure.

Don’t kid yourself that the DOA is going to be any more resilient than our existing internet – the documentation also shows it is based on the same technologies we rely on for our existing internet: PKI based security, relying on encryption algorithms that have to be deprecated and replaced when it gets broken. I’m not sure how it would hold up against a DDoS attack of any sort. What this object based internet seems to give us though is a license. There are many interesting parts to it, including that it seems that CNRI can now kill the DOA at will just by terminating the license:

“Termination: This License Agreement may be terminated, at CNRI’s sole discretion, upon a material breach of its terms and conditions by Licensee.”

So would I use this for the Internet of Things?
No! I’ve touched the tip of the iceberg here. It seems fragile and flaky at best, probably non-functioning at worst. Let’s be honest – the technology has not been tested at scale, it currently has to deal with a small 100s of thousands of resolutions, rather than the billions the internet has to. I can’t imagine that it would have been able to handle “1.2 terabits per second of data“. Operating at internet scale is a whole different ball game and this is what some people just don’t get – incidentally the IETF members pointed this out to CNRI researchers back in the early 2000s on the IETF mailing lists (I will try to dig out the link at some point to add here).

Summary

Yes, we need to get better, but let’s first work together and get on the case with device security. We also need to get better at sinkholing and dropping traffic which can flood networks through various different means, including future measures such as protocol re-design. Some people have said to just block port 23 as an immediate measure (blocking telnet access). There’ll be many future attacks that really do use the Internet of Things but that doesn’t mean we have to tear up our existing internet to provide an even less secure, untested version with the DOA. The grass is not always greener on the other side.

Some more links to recommendations on IoT security can be found below:

Other bodies are also doing work on security but at an earlier stage including the W3C’s Web of Things working group
Edit: 30/10/16 – typos and added IETF list