PSTI: WILL IT IMPROVE IOT SECURITY?
The new Product Security and Telecommunications Infrastructure (PSTI) Bill currently going through parliament comprises two parts. The first aims to put in place safeguards to regulate the secure design of the Internet of Things (IoT) while the second will ensure broadband and 5G networks are gigabit-grade. It’s the first part that has caused a stir because it will, for the first time, see the introduction of enforceable regulation.
Applicable to consumer products such as smartphones, connected cameras, TVs and speakers, fitness trackers, toys, white goods such as smart washing machines and fridges and home equipment such as smoke detectors and door locks, home automation and alarm systems, the regulations stipulate that manufacturers must:
- Not use default passwords
- Have a vulnerability disclosure policy
- Be open about the length of time the product will be supported with security updates
Yet, while the move to regulate the IoT is regarded as long overdue, the PSTI has been criticised for not going far enough, particularly given the number of well-documented security vulnerabilities exhibited by smart technology.
WHY IS THE IOT SO INSECURE?
The root cause of the majority of issues that have plagued consumer hardware is that manufacturers are cost driven and aim to be quick to markets and in many cases this had led to shortcuts or a complete lack of information security during the design process. This has resulted in common security weaknesses long since addressed in more mature software and hardware products, such as default usernames and passwords or straightforward password bypasses, weak encryption (hashes) for password storage and a lack of encryption for data transfer across open networks for administrative traffic, being widely used in the IoT.
In addition, the sector has suffered from other issues. such as a lack of security around the firmware update processes (such as a lack of signing) and also hardware interface exposures that allow for straightforward access to low level functions of the device or its components (such as memory). And whereas it was hoped the sector would self-regulate, this doesn’t seem to have happened, with a report by the Internet of Things Security Foundation in 2020 finding that only 1 in 5 manufacturers had a disclosure process, meaning the majority could not be alerted to a security vulnerability.
WHERE DOES THE PSTI FALL SHORT?
The bill currently addresses the most significant and easily exploitable weaknesses in IoT devices: the use of default passwords, however many other common security weaknesses have not been covered at this stage. That said, the use of default passwords is by far the most common way that an IoT device will be compromised and it is a significant first step in improving the security of these products.
Focusing on default settings is also easy to establish whether the manufacturer is in breach of the bill, whereas other measures (such as ensuring a stringent code review process to identify access control bypasses or input validation weaknesses) will not be so straightforward to ascertain.
The bill also does not stipulate a minimum support period for security updates for consumers, thus manufacturers can still release products without a commitment to supporting it, leaving this decision in the hands of consumers who may not necessarily understand the risks.
Understandably perhaps, its not being retroactively deployed so won’t apply to the army of devices currently out there, and while manufacturers must have a disclosure channel, there’s no compunction or timeframe for them to notify their users of any reported vulnerability. Nor is there any focus on the patch management: users often find these difficult to implement so some move towards over-the-air or automated patching would have been welcome.
As mentioned above, there are many other vulnerabilities that can be used to exploit IoT devices, including disrupting administrative traffic, identifying and exploiting flaws in web or file transfer services running on the device, causing denial of service, interfering with the update process and deploying rogue firmware or exploiting the devices with physical access.
SO IS THE PSTI TOO LITTLE TOO LATE?
The PSTI is still winding its way through parliament and is unlikely to pass into law until 2023 but when it marks an important first step in the regulation of an industry that has previously been seen as playing fast and loose. It will force IoT product vendors around the world to consider the security associated with their consumer devices and will provide a baseline of protection for devices being sold to the public in the UK. And it will also see offending vendors held to account for the first time if they do not abide by the articles of this law.
It’s important to remember that while the bill doesn’t cover as many of the security issues one might have hoped, it does cover the vulnerability with the highest likelihood and impact of exploitation. Other key requirements such as ensuring a vulnerability disclosure policy and ensuring transparent advice on the time that security updates will be released are also welcome measures and support the improvement of product security over time.
Knowing how long a product will be supported will help consumers make an informed decision and is likely to be used by consumer support organisations such as Which? To differentiate offerings. In many ways, it sets a bar by which vendors can be measured and could lead to the emergence of consumer kitemarks so that security becomes not a sunk cost but a differentiating factor that manufacturers can use to boost sales.
IoT devices do, of course, also impact the corporate environment either because users seek to use these on the network or by acting as potential conduits for an attack, such as ransomware or the large scale DDoS attacks we saw carried out by the Mirai botnet that enslaved thousands of IoT devices. Consequently, the PSTI will affect businesses too and, depending on how the regulation evolves, it could even have a direct impact on security team workloads, particularly if it seeks to address patch management in the future.
