New UK Laws to Make Broadband Routers and IoT Kit More Secure

security of broadband isp routers

The Government has today launched a new consultation on their proposal to introduce new laws that would seek to improve the security of internet connected devices, such as smart TVs, broadband ISP routers, smart speakers and other Internet of Things (IoT) style devices. But “initially” these will only be voluntary.

As most people will hopefully know by now, not all internet connected devices are as secure as they probably should be. Sadly many devices still come with a default admin password that’s the same for every unit sold (until you change it and not everybody bothers to do that) and others fail to adopt decent encryption for their communications, which in both cases leaves the kit exposed to hackers and cyber attacks.

Similarly once the hardware has been shipped then the manufacturers can become very poor at keeping them up-to-date with the latest firmware (software upgrades) in order to protect against new vulnerabilities or to correct bugs. This has been a particular problem when it comes to many third-party broadband ISP routers (one advantage of a router bundled by your ISP is that they often keep it updated automatically).

Admittedly bundled routers from ISPs aren’t perfect either and over the years even they have been targeted by sophisticated malware, such as the Mirai worm that injected the kit being used by lots of major providers. So last year the Government started the process of trying to tackle such issues by setting out their Secure by Design review, which proposed a new industry code of conduct.

The New Security Label

The new consultation essentially proposes the introduction of a mandatory new labelling scheme, which would tell consumers how secure their products are based on several key criteria (not exactly fool proof but it’s a good start). In addition, retailers will only be able to sell items with the security label, although this would initially only be launched as a voluntary scheme “until regulation comes into force.”

The label itself would mandate that a supporting device must adhere to what the Government has identified as the top three security requirements.

Top 3 Requirements for the Label

* Device passwords must be unique and not resettable to any universal factory setting.

* Manufacturers of IoT products must provide a public point of contact as part of a vulnerability disclosure policy.

* Manufacturers explicitly state the minimum length of time for which the device will receive security updates through an end of life policy.

No doubt some people will have wanted even stricter controls, although some hardware will inevitably have a shorter working life and different requirements than others. “We are mindful of the risk of dampening innovation and applying a strong burden on manufacturers of all shapes and sizes. This is why we have worked to define what baseline security looks like,” said the consultation.

Margot James, UK Digital Minister, said:

“Many consumer products that are connected to the internet are often found to be insecure, putting consumers privacy and security at risk. Our Code of Practice was the first step towards making sure that products have security features built in from the design stage and not bolted on as an afterthought.

These new proposals will help to improve the safety of Internet connected devices and is another milestone in our bid to be a global leader in online safety.”

The main thrust of today’s consultation appears to centre on the question of how the Government will mandate retailers to only sell products with the new label attached. For example, manufacturers could be allowed to self declare and implement a security label of their own or one that adheres to just the top 3 requirements. Alternatively they may only be allowed to sell such products if the label “evidences compliance with all 13 guidelines” (we’ve re-published the original 13 points below).

Assuming all goes well then the new security label is expected to be introduced via its initial voluntary run “later this year.

13 Points in the Code of Practice

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: