“If you’re looking to deploy IoT, you need to do it right from the start and you need to think about what happens with that product throughout its lifetime, until you sunset it,” David Rogers MBE – founder of Copper Horse and author of the UK’s Code of Practice for Consumer IoT Security – told listeners at yesterday’s launch webinar (available to watch on-demand). “That means working with suppliers and partners who you can trust will take the right approach to security and platforms.”
Arm commissioned Copper Horse to offer an impartial guide to IoT security by design, and the 19 page white paper guides readers on how to appropriately and securely manage solutions at scale.
“If you’re deploying IoT in any kind of environment – for example, consumer, automotive, agricultural, industrial or medical, you need to consider security from the beginning,” David reiterates. “Regulation is coming so it can’t be ignored.”
Topics covered in the briefing include: the threat landscape; future regulation; software updates and device management; public key infrastructure (PKI); end-of-life and decommissioning; and a reminder on identifying and eliminating bad practices.
In late 2018, to coincide with the launch of the UK’s Code of Practice for Consumer IoT Security we launched a website: iotsecuritymapping.uk which mapped IoT recommendations and standards from around the world. Our previous blog explains more of the detail. Earlier this year, we updated the site to include the European Telecommunications Standards Institute (ETSI) Technical Specification, TS 103 645 (pdf) which originated from the Code of Practice.
Today we have launched an updated version of the mapping site which stretches the landscape further with a number of new recommendations from around the world. These have either been sent to us as a result of people hearing about the original mapping work or work that we’ve seen launched since then.
The following additional recommendations are added, from all over the globe including Japan, South Korea and the USA:
Some recommendations we looked at had been updated, but these were either minor editorial changes or had changes not relevant to mapping against the Code of Practice, in these cases, the mapping was not updated.
Updating the External References
One useful thing we created last time was a mapping of external references from the recommendations – it is quite useful to understand where things are happening, which bodies are at least judged to be the most relevant. We’ve further updated this and it is no surprise that organisations like the IETF with massive contribution from industry are the most referenced and essentially used while other organisations like the ITU who try and lay claim to IoT are hardly referenced. We believe this work is the first time that any organisation has attempted to lay out these relationships, to break open the marketing hyperbole with real, factual data.
What are we observing and what does it mean?
There is a broad consensus on what needs to be done in IoT security, which is quite nice to see. Pretty much everyone who is looking at the problem is saying the same thing in different ways. The consumer space seems to be a common starting point because that is where the problem is most visible, but clearly the majority of this work provides a common foundation which is applicable across all IoT ‘verticals’ from industrial IoT, to connected cars.
There are differences in the level of abstraction in recommendations – some are very detailed, others at a high level. This is not a massive problem, it is just that more detailed and specific recommendations can be a real barrier to adoption. It can also affect innovation because detailed specifications tend to deal with the status quo of what exists now. They fail to consider or accommodate the possibility that someone could create something securely without doing exactly what has been put into a bit-level recommendation or standard. It can also affect organisations implementing security in the first place because detailed specifications look daunting. A high level recommendation is easier to access and implement (within the spirit of what is being asked), however it suffers from the fact that people could pay lip service to it or that more detail may be necessary to stop people doing something insecure. We need to find a happy medium between the two approaches for real security success in such a varied market as IoT.
The gaps between the specifications are going to get interesting – where is there divergence and why is that? This looks to be a key piece of work for the future and we may explore that in the coming year.
Keeping the site updated
We’ll keep updating the mapping site until there is a natural end. There is work ongoing which will rationalise these efforts at an international standards level. Once that has happened and there is consensus, we’ll have hopefully achieved what we set out to do – unification and defragmentation of IoT security; at least for the fundamental foundations. We hope you find the latest update useful and do please keep sending your feedback to us.