Home
 » ISP News, Key Developments » 
Sponsored

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

Wednesday, May 1st, 2019 (11:05 am) - Score 1,683
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.

Add to Diigo
Tags: ,
Mark Jackson
By Mark Jackson
Mark is a professional technology writer, IT consultant and computer engineer from Dorset (England), he also founded ISPreview in 1999 and enjoys analysing the latest telecoms and broadband developments. Find me on Twitter, , Facebook and Linkedin.
Leave a Comment
13 Responses
  1. Avatar Joe

    All sounds good except for the top 3 and voluntary bit…

  2. Avatar Mike

    No doubt after a few years they’ll add a 14th point…

    “A back door so the government can ‘confirm’ how secure it is”

    • Or “encryption that the Government can bypass” 🙂 .

    • Avatar Joe

      The trouble with that as mark well knows is that its nearly impossible to create a backdoor for the gov that can’t be exploited by a hacker.

    • Avatar Timeless

      exactly, its like leaving a spare hidden key under a stone by the back door… yeah only you might know where it is but if someone is savvy enough and really wants access then they will get in.

      and lets face it, over the years the government has been known to leave keys for private data all over the places.

  3. Avatar Randolf

    Hahaha This is brilliant, I hope they go for a traffic light system, just like cornflakes, I do have my doubts that most ISP routers would even get an amber. Guess I’ll buy from Aliexpress.

  4. Avatar Meadmodj

    “we have defined consumer IoT products as products that are connected to the internet and/or home network and associated services”

    If this is a UK specific requirement it may increase costs unnecessarily if devices are only used on a locally secured network or exposed to the cloud via say a home automation hub. Enhanced (user friendly) security by MAC address would suffice in most cases. e.g current controllable lightbulbs are already expensive and place this burden on such devices appears excessive (or we go back to Zeebee etc). I would prefer instead a label that highlighted the level of risk rather than its security as invariably it will be connected and logged in 24/7. Yes admin options may be more secure but many of these devices will have cloud exposed APIs.

    My view is that the risk is the proliferation of IoT and the paths to the cloud. If you buy a fridge, a washing machine, food mixer etc from different manufacturers you will end up with multiple accounts to update and manage each device, you will want to add skills to your Alexa “have I any milk” or eventually Tesco will wish to replenish your essentials automatically. This is where the thought needs to be and machine learning application gateways that detect unusual device behaviour.

  5. Avatar idiots

    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.

    …. Except for DNS because that breaks our porn filter

  6. Avatar Spurple

    #7 is risky.

    If I have the skills to, I should be able to run whatever software I want on it without falling foul of a law that mandates secure boot (which usually means centrally signed images).

    • Avatar Joe

      Well the obvious workaround there is bog standard consumer devices lock that down and the tech savvy devices leave it open for the user (and are sold opn that basis with the traffic light bit etc). Much like now really where ISP routers are often locked but I can buy kit that I can fiddle with if I want.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Comments RSS Feed

Javascript must be enabled to post (most browsers do this automatically)

Privacy Notice: Please note that news comments are anonymous, which means that we do NOT require you to enter any real personal details to post a message. By clicking to submit a post you agree to storing your comment content, display name, IP, email and / or website details in our database, for as long as the post remains live.

Only the submitted name and comment will be displayed in public, while the rest will be kept private (we will never share this outside of ISPreview, regardless of whether the data is real or fake). This comment system uses submitted IP, email and website address data to spot abuse and spammers. All data is transferred via an encrypted (https secure) session.

NOTE 1: Sometimes your comment might not appear immediately due to site cache (this is cleared every few hours) or it may be caught by automated moderation / anti-spam.

NOTE 2: Comments that break our rules, spam, troll or post via known fake IP/proxy servers may be blocked or removed.
Cheapest Superfast ISPs
  • Hyperoptic £18.00 (*22.00)
    Avg. Speed 30Mbps, Unlimited
    Gift: Code: SPRING19
  • Vodafone £21.00 (*23.00)
    Avg. Speed 35Mbps, Unlimited
    Gift: None
  • TalkTalk £22.50
    Avg. Speed 36Mbps, Unlimited
    Gift: None
  • Direct Save Telecom £22.95 (*29.95)
    Avg. Speed 35Mbps, Unlimited
    Gift: None
  • SSE £23.00 (*33.00)
    Avg. Speed 35Mbps, Unlimited (FUP)
    Gift: None
Prices inc. Line Rental | View All
The Top 20 Category Tags
  1. BT (2386)
  2. FTTP (1963)
  3. FTTC (1582)
  4. Broadband Delivery UK (1538)
  5. Politics (1321)
  6. Openreach (1318)
  7. Business (1168)
  8. Statistics (1028)
  9. Mobile Broadband (952)
  10. FTTH (948)
  11. Fibre Optic (933)
  12. Ofcom Regulation (865)
  13. Wireless Internet (854)
  14. 4G (836)
  15. Virgin Media (799)
  16. Sky Broadband (572)
  17. TalkTalk (551)
  18. EE (547)
  19. Vodafone (460)
  20. Security (391)
New Forum Topics
Promotion
Helpful ISP Guides and Tips
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
Sponsored

Copyright © 1999 to Present - ISPreview.co.uk - All Rights Reserved - Terms , Privacy and Cookie Policy , Links , Website Rules , Contact