Maksim Kabakou - stock.adobe.com

The future of network-connected device security

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.

The vulnerabilities in internet of things (IoT) devices have led to smart devices being part of botnets and incidents such as cardiac devices being vulnerable to hackers. 

“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.

As such attacks have become more frequent, the UK government has decided to step in. Earlier this year, the Department for Digital, Culture, Media and Sport (DCMS) published the Secure by Design report and later the Code of Practice for Consumer IoT Security – a guidance document advising on the best practices for securing IoT devices.

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

  1. No default passwords – all IoT device passwords should be unique and not resettable to any universal factory default value.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  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. Consumers should also be provided with guidance on how to securely set up their device.
  13. Validate input data – data input via user interfaces and transferred via application programming interfaces (APIs) or between networks in services and devices shall be validated.

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.”

Read more about IoT security

Read more on Internet of Things (IoT)