DCMS Practical Guidelines. Actionable information

The DCMS guidelines for IoT security are an excellent set of recommendations. They help developers secure devices by outlining the basic ways one can prevent common security weaknesses from being present in their devices and infrastructure.

The recommendations are well thought out, and encourage the use of good security standards, but they lack the explicit detail that developers crave. to help with that we’ve provided a list of methods a developer could use to follow each of the thirteen guidelines. While this list is by no means definitive, it should help those who don’t know where to start with securing their devices.

1. No default passwords

All IoT device passwords shall be unique and not resettable to any universal factory default value.

• All passwords which are required for initial setup of a device should be random, and unique to each specific device
• Passwords should not be based on anything recoverable about the device, being truly random
• No static “backdoor” passwords should be implemented by the developers for any purpose, as these could be recovered by an attacker

2. Implement a vulnerability disclosure policy

All companies that provide internet-connected devices and services shall 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.

• A disclosure page should be set up on the company website, providing resources for an individual to disclose weaknesses to the business, and display resolved security weaknesses
• An email address should be made available, using a prefix such as “security@” or “disclosure@”. A PGP Public Key should be made available in order to allow for secure communications with an individual disclosing a vulnerability
• A disclosure tracking system should be implemented, allowing for assessment of the current status of remediation of any issues, failing this email updates should be provided to the discloser. These should include requests for extensions on public disclosure by the individual

3. Keep software updated

Software components in internet-connected devices should be securely updateable. Updates shall be timely and should 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 for which a device will receive software updates and the reasons for the length of the support period.

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.

• Firmware updates should be provided frequently in order to update any security weaknesses that are present in the device. On embedded Linux, this should include patching of third party software which has had security patches published, and kernel versions which fix security weaknesses. Firmware updates should be signed and encrypted, with strong keys and algorithms being used.
• An end-of-life policy should be published allowing users to know when a device will no longer be supported
• If possible, updates should be provided to the device upon end-of-life in order to allow it to still function locally for those users who wish to continue using it without remote server access

4. Securely store credentials and security-sensitive data

Any credentials shall be stored securely within services and on devices. Hard-coded credentials in device software are not acceptable.

• No hard-coded credentials should be used in any element of the device. If a device requires authentication with a remote server, a unique client certificate should be used on a per-device basis
• All credentials should be stored securely on media that is not easily removable by a reverse engineer, ideally on BGA based NAND flash
• Any passwords input by a user for the purpose of further authentication should be stored using a secure, one-way hashing algorithm with a strong salt

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.

• All communication protocols should be secured with appropriate encryption algorithms. For any protocols which support it TLS should be used, with certificate pinning implemented and verification of the identity of the remote server
• No protocols should be used which do not support encryption. Where removal of these protocols is not possible, they should be wrapped in TLS
• All communication on the local network should also be encrypted

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.

• Port scans should be performed on the device in order to identify unnecessary services running. These include any remote access servers such as Telnet or SSH, management interfaces, or logging services
• Services which are required to be active in order for the device to function should never be run as root, and be run under a user account which is restricted only to the privileges required for the service to operate
• External interfaces and debug headers on the board should be removed in order to disallow an attacker from easily connecting to the interface, only those which are required for a consumer to operate the device should be enabled

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.

• Secure boot should be implemented on the device, checking the validity of code via verification of cryptographic signatures for each piece of software that is required to run
• Firmware updates should be signed with a strong cryptographic signature, such as RSA or ED25519, with a Private Key that is only accessible to those authorised to deploy software to the device. In addition, firmware should be encrypted in order to prevent an attacker from identifying weaknesses in it
• Appropriate alerts should be sent to the consumer and manufacturer when the device has been compromised, and revert to a state where the device is non-functional and unable to operate until the matter has been resolved

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, such as the General Data Protection Regulation (GDPR) and the Data Protection Act 2018. 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, 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 shall be validly and lawfully obtained, with those consumers being given the opportunity to withdraw it at any time.

• GDPR regulations should be followed during the development and deployment process of the device, and any changes made to the system after deployment should be assessed in order to identify any areas where GDPR violation could be introduced at a later date
• Customer information should be kept at a minimum for the standard usage of the device, with any information that is not required being discarded and removed from any forms. Information about the data which is being stored should be made available to the user
• Any credentials used for interacting with the device should be stored with a strong one-way hashing algorithm and salt
• Any systems that require payments to be made should strictly follow PCI guidelines in order to protect user data

9. Make systems resilient to outages

Resilience should be built in to 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 and in an orderly fashion, rather than in a massive scale reconnect.

• Devices should be built in such a manner that access via the local network is possible, with special care being taken to secure the communication between the device and the user.
• Devices should note lack of access to remote servers in an appropriate time frame, and periodically attempt to reconnect to them. This should be done every few minutes, and not in such a manner where load on the server would be drastically increased
• Devices should not require power cycling for any reconnection to any networks. Local Wi-Fi access points and remote servers should be automatically reconnected to whenever there is an outage, and the device should not require user interaction in order to do so

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

• Telemetry data should be stored without identifying information for individual users
• Frequent power cycles, communication errors and hardware errors should be logged and flagged when they occur, in order to identify users misusing the device
• Network attacks on hosted services from IP addresses shared with a device should be logged, as these could allow for identification of malicious users

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.

• Information for user accounts which have been disabled should be archived for the purpose of reactivating accounts at a later date
• Users should be provided the option of permanently deleting their data from the host server, with the warning that this data will not be recoverable
• Factory resets of the physical device should delete all user data from it, and all log files which could contain sensitive user information should be erased

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.

• Detailed instructions should be provided to users in order to allow them to set up the device. These instructions should be tested by quality control prior to release of the device in order to ensure that a user who has no experience with such a device can set it up
• Input of credentials and user information should be performed in a secure manner. Input of Wi-Fi credentials should only be performed by a method which is encrypted, either by a Wi-Fi access point on the device utilising WPA2 and a randomised password generated on a per device basis, manual input, or input via authenticated and encrypted Bluetooth
• Information should be provided on how to factory reset the device in order to remove user information from it. In addition, information should be provided on how to download and install firmware updates in order to maintain the integrity of the 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.

• Authentication should be implemented on any API calls made from the device to any remote server. This should include unique authentication credentials for each device, and only allow it access to information that it is authorised to do so. Special care should be taken in order to remove the possibility for an attacker who had gained access to information on the device to gain access to the information of other users
• Security testing should be performed on all remote APIs in order to identify any security weaknesses which could be used by an attacker. In particular, APIs which are provided only to the device should be assessed, as these pose the greatest potential for security weaknesses due to their implementation
• All remote servers should be scanned for unnecessary services which could allow an attacker to compromise the integrity of the system, any unnecessary services should be disabled

Following these methods should help any developer to secure their IoT devices during development, as well as provided a good foundation for future updates which could potentially introduce security weaknesses. It is highly recommended that security is made a priority from the beginning of development of an IoT device, as there are a huge number of weaknesses which can never be fixed once they are introduced.