The “Proposed Code of Practice for Security in Consumer IoT Products and Associated Services”, which starts on page 18 of the report, lists 13 high-level steps that manufacturers, developers and retailers should implement to improve the security of IoT devices. The steps are at the bottom of this article, for reference.
The report struck a chord with us, as recently we’ve been talking about a minimum standard for security for consumer products for a number of reasons; as a way of framing how we approach a product security evaluation, in our collaborations with Which?, and as regular consumers who see a lot of poorly made devices and applications.
We’ve found security problems in a whole manner of consumer devices, from Furbies to lightbulbs and IP cameras. With botnets like Mirai it’s clear that the security of a device now has the potential to affect the wider world, not just the owners of the product.
A need for certification
Several of our Product Security Evaluation customers have asked us about producing some kind of certification of testing, as quite reasonably they want to advertise the fact that they’ve committed to having their products security tested. Our initial response, as security paranoids, is the immediate concern that we rarely engaged by clients to test something exhaustively, so would be cautious about putting a “Context says this product is 100% secure” badge on anything.
Some of the devices we’ve tested for customers have been consumer devices, but most of the devices we’ve tested are being sold to enterprise and industrial customers, who are more used to asking “is this thing secure?” or “has it been security tested?” before putting it on their networks. But what about consumers? Don’t they have a right to ask the same question?
Two years ago, after delivering a talk about the security of home devices at a cyber-security event for a bank, it was the first question from the audience: why is there no equivalent to the kite mark for cyber security? One of the topics that day was a Motorola security camera we’d looked at, and the reasonable point being made was that if I buy a security product that actually undermines the security of my home network, what protections do I have as a consumer?
The guidelines themselves
One section of the new guidelines that gives a good insight into their purpose: paragraph 4.2 states
“The guidelines contained within the Code of Practice are not a silver bullet - only by shifting to a security mind-set and investing in a secure development lifecycle can an organisation succeed at creating secure IoT products and services. Put simply, companies should design products and services with security in mind, from product development through to the entire product lifecycle. Organisations should also regularly assess cyber security risks pertaining to their products and services and implement appropriate measures to address these”
There were some immediate and varied criticisms, as there always is when someone in InfoSec tries to do something constructive. Why do stories of poor products get more headlines than initiatives to make them more secure? It’s a game we’ve all played, but there is a fine line between writing a blog to demonstrate your skills or a new technique, and just trying to generate headlines by hacking the latest cheap connected device. There’s no downside to criticising something that’s already shown to be broken.
Some of the suggestions, such as using encrypted connections and validating input are decades-old advice that you hope would be ingrained in the minds of even the least security-aware developers. But we’ve all seen, and will likely continue to see, products that don’t implement even the first point, not having default passwords. Avoiding default universal passwords would have made the difference with Mirai, as it would have prevented the mass compromise of lots of devices with trivial login authentication.
The suggestions are more design guidelines than they are a tick-list of expected functionality, which conform to the sensible idea of building security in from the beginning, and are reasonable given they are aimed not just at manufacturers, but also at retailers and app developers. One of our favourite gems is hidden in point 3 (“keep software updated”) which instructs manufacturers to publish an end-of-life policy for their devices – imagine knowing how long your new IoT gadget will receive updates for, before you purchase it. Perhaps the next output could be a minimum expected functionality; something that could be used as a baseline for standardised testing.
There have also been complaints that there’s no point putting out standards without regulation, but you have to prepare developers that there is now an expectation of minimum standard, before you implement regulations. The paper seems like a very reasonable first step – imagine the outrage if the Government had announced they would be immediately enforcing regulation around these guidelines from day one.
So let’s take the suggestions and apply them to what we do in the industry, let’s be constructive and positive. Security is improved, on a wider scale, through lots of small steps.
If you are interested in finding out more about the security of connected devices, then register for our upcoming webinar "Building Secure Connected Devices", which will be presented by Scott Lester.
Appendix: The 13 Steps
1) No default passwords
All IoT device passwords must be unique and not resettable to any universal factory default value.
2) Implement a vulnerability disclosure policy
All companies that provide internet-connected devices and services must 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. Disclosed vulnerabilities should be acted on in a timely manner.
3) Keep software updated
All software components in internet-connected devices should be securely updateable. Updates must be timely and not impact on the functioning of the device. An end-of-life policy must be published for end-point devices which explicitly states the minimum length of time for which a device will receive software updates and the reasons why. The need for each update should be made clear to consumers and an update should be easy to implement. For constrained devices that cannot physically be updated, the product should be isolatable and replaceable.
4) Securely store credentials and security-sensitive data
Any credentials must be stored securely within services and on devices. Hard-coded credentials in device software are not acceptable.
5) Communicate securely
Security-sensitive data, including any remote management and control, should be encrypted when transiting the internet, appropriate to the properties of the technology and usage. All keys should be managed securely.
6) Minimise exposed attack surfaces
All devices and services should operate on the “principle of least privilege”; unused ports must be closed, hardware should not unnecessarily expose access, services should not be available if they are not used and code should be minimised to the functionality necessary for the service to operate. Software should run with appropriate privileges, taking account of both security and functionality.
7) Ensure software integrity
Software on IoT devices must be verified using secure boot mechanisms. If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function.
8) Ensure that personal data is protected
Where devices and/or services process personal data, they should do so in accordance with data protection law. Device manufacturers and IoT service providers must provide consumers with clear and transparent information about how their data is being used, by whom, and for what purposes, for each device and service. This also applies to any third parties that may be involved (including advertisers). Where personal data is processed on the basis of consumers’ consent, this must be validly and lawfully obtained, with those consumers being given the opportunity to withdraw it at any time. Consumers should also be provided with guidance on how to securely set up their device, as well as how they may eventually securely dispose of it.
9) Make systems resilient to outages
Resilience must be built in to IoT services where required by the usage or other relying systems, such that the IoT services remain operating and functional.
10) Monitor system telemetry data
If collected, all telemetry such as usage and measurement data from IoT devices and services should be monitored for security anomalies within it.
11) Make it easy for consumers to delete personal data
Devices and services should be configured such that personal data can easily be removed when there is a transfer of ownership, when the consumer wishes to delete it and/or when the consumer wishes to dispose of the device. Consumers should be given clear instructions on how to delete their personal data.
12) Make installation and maintenance of devices easy
Installation and maintenance of IoT devices should employ minimal steps and should follow security best practice on usability.
13) Validate input data
Data input via user interfaces and transferred via application programming interfaces (APIs) or between networks in services and devices must be validated.