The proliferation of poorly secured network-connected devices has prompted the UK government to publish new best practice guidelines. Do these go far enough?

Wireless functionality has improved workplace efficiency and organisations are no longer restricted by cabling access. Unfortunately, many of these devices are poorly secured and rarely have their firmware updated.

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

“The proliferation of IoT devices with poor security posture has increased the attack surface for threat actors dramatically,” says John Sheehy, vice-president of ioActive. “Compromised devices can be used by threat actors for anything from listening in on conversations and harvesting sensitive data, to cryptomining and jumping to traditional IT systems.”

Incidents where hackers have been able to exploit poor device security to obtain sensitive data have resulted in significant reputational damage, as happened to vTech in 2016. Such incidents could now – under the Data Protection Act 2018 – see companies fined.

These guidelines are currently voluntary and are broken down into thirteen steps, as follows:

No default passwords – all IoT device passwords should be unique and not resettable to any universal factory default value.

Implement a vulnerability disclosure policy – all companies that provide internet-connected devices should 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.

Keep software updated – software components should be securely updateable. Updates should be timely and not impact on the functioning of the device. An end-of-life policy shall be published for end-point devices, which explicitly states the minimum length of time that a device will receive software updates.

Securely store credentials and security-sensitive data – any credentials shall be stored securely in services and on devices. Hard-coded credentials in device software are not acceptable.

Communicate securely – security-sensitive data, including any remote management and control, should be encrypted in transit, appropriate to the properties of the technology and usage. All keys should be managed securely.

Minimise exposed attack surfaces – all devices and services should operate on the ‘principle of least privilege’; unused ports should 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.

Ensure software integrity – software on IoT devices should 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.

Ensure that personal data is protected – where devices and/or services process personal data, they shall do so in accordance with applicable data protection law. Device manufacturers and IoT service providers shall provide consumers with clear and transparent information about how their data is being used, by whom, and for what purposes. This also applies to any third parties that may be involved. Where personal data is processed on the basis of consumers’ consent, this shall be validly and lawfully obtained, with those consumers being given the opportunity to withdraw it at any time.

Make systems resilient to outages – resilience should be built into IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power. As far as reasonably possible, IoT services should remain operating and locally functional in the case of a loss of network, and should recover cleanly in the case of restoration of a loss of power. Devices should be able to return to a network in a sensible state, rather than in a massive reconnect.

Monitor system telemetry data – if telemetry data is collected from IoT devices and services, such as usage and measurement data, it should be monitored for security anomalies.

Make it easy for consumers to delete personal data – devices and services should be configured such that personal data can easily be removed from them 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.

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. Consumers should also be provided with guidance on how to securely set up their device.

The definition of a “timely manner” is incident-specific. However, 90 days is the standard for completion.

Industry reactions have been broadly positive, with HP and Centrica agreeing to abide by these recommendations. However, some recommendations are easier to implement than others.

“At the high level, the specific requirements outlined in the code of practice are exactly what needs to happen,” says Sheehy. “The challenge I see is that the devil is in the detail.”

No default passwords and a vulnerability disclosure policy are fairly easy for organisations to implement, but ensuring software integrity and monitoring system telemetry data are more challenging. “One of the huge challenges of doing software integrity is building the right cryptographic system to be able to ensure that integrity,” says Sheehy.

Keeping software updated is also not as easy as it sounds. Most IoT devices can be updated over the internet. However, there are devices that are unsuitable for updating in this way. For example, the software in cars would probably need to be updated at a garage, which would come with a significant cost, and not all car owners would go to the effort of asking for the software to be updated.

To fully implement these guidelines, companies need to follow “secure by design” principles in the manufacturing process. This technique embeds security considerations within device development phase, rather than as an afterthought.

Guideline benefits

For all of the challenges that come with this, organisations can nonetheless benefit from following such guidelines. In a survey by Bain and Co, it was discovered that executives would be prepared to spend 22% more on IoT devices that were proven to be secure.

“If a product has followed these guidelines, and has been independently checked, then people would pay more,” says Colin Tankard, managing director of Digital Pathways.

This increase in income could be used by manufacturers to offset the costs associated with following these best practice guidelines. Furthermore, reputation of the company would be protected by having secured their devices appropriately.

“Most businesses buy quality hardware, such as Cisco,” says Tankard. “They could go cheaper, but they go for brand reputation.”

However, the challenge is how manufacturers can show potential customers that guidelines have been followed, and how customers can be confident that these claims are accurate. Independent certification could be one answer, but there have been no indications that any certification method has been proposed.

Currently, the closest form to a standard for cyber security is ISO/IEC 27001, but this only specifies the requirements for information security management systems within organisations, rather than device security.

“How do the companies wanting to buy all of this stuff know it has been done, when there is no kite mark or ISO standards that say it is compliant?” asks Tankard. “We are a long way away from having something we can trust.”

The UK government is currently debating whether these guidelines should become a legislative requirement. A spokesperson for the DCMS said: “Our ambition is for appropriate aspects of the Code of Practice to be legally enforceable, and we have already commenced work to consider which aspects of regulatory change are necessary with further details to be shared in due course.”

The challenge of adapting these best practice guidelines into legislation is ensuring that they remain valid. Technology is evolving at such a rate that government regulation is often lagging behind by several years.

“One of my concerns with legislation of this kind is that it needs to evolve very quickly and it needs to not be overly prescriptive,” says Sheehy. “If there is too much detail in the legislation it can quickly become outdated.”

Device security needs to improve to meet the increasing use of such devices. The sooner that organisations begin adopting the recommendations, the better they will be prepared for when these potentially become law.

Organisations should view these guidelines as an opportunity, by demonstrating their commitment to customer security, while engaging with the government to ensure the recommendations are both effective and technically feasible.

“This is a very technical document and it is meant for consumption by technical people,” says Sheehy. “I think that the right place for the government to make this legislation is at the governance level.”

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.