How to cover the best security practices by design
The road to security always passes through the gateway of code quality. This is what my colleague Shawn Prestridge has stated previously in this article. Nothing can be more true than that. But what can we as code-writers and developers in practice do to make our products secure?
In this article, I will guide you through the Code of Practice for Consumer IoT Security from the Department for Digital, Culture, Media and Sport (DCMS) in the UK. These 13 best practices have become a reference for many other guidelines being created around the world. I will cover what you can achieve by implementing them in your design throughout the lifecycle by providing the foundation for a set of core security concepts aimed at protection of Intellectual Property and prevention of malware injection.
The Code of Practice for Consumer IoT Security
The ambition of the Code of Practice for Consumer IoT Security is to provide guidelines on how to achieve a secure by design approach during development, production, and maintenance of IoT products during the entire life cycle. The practices bring together what is widely considered best practices in IoT security.
The guidelines and code of practice cover everything from secure device boot, cryptographic device identities, Root of Trust, operating system, credential management and encryption to secure software and software updates policy. The security legislation is not solely intended to be a mandatory compliance checkbox, but it should be used voluntarily in your favor. There are many entities and governments spending time in defining guidelines that once followed will benefit the end-users and the liability of the companies developing IoT products. It’s a win-win for consumers and companies developing the IoT products by having the security legislation at their side delivering high-value benefits from inhibiting malware, secure identity, IP protection, production control and compliance on the standards.
Code of Practice for Consumer IoT Security – 13 Guidelines [1]
What do these 13 guidelines cover?
Let’s dig into these best security practices that can directly be covered in the source code and design of an IoT product:
1. No default passwords
Sounds obvious, but there is way more needed to have it in place. Default passwords should ideally be derived from the device itself or injected into the device. A smart thought is to generate a password using a diversification algorithm based on hashing that is unique to the device, where the serial number will not have enough entropy and using a hash-based algorithm like SHA-256.
2. Implement a vulnerability disclosure policy
In short, this is connected to a corporate disclosure policy, with a responsible executive aside of customer liaison activates and the vulnerability communication.
3. Keep software updated
As the volume of IoT devices used in organizations increases, keeping devices updated will present a challenge. Teams that develop a strategy for IoT software updates early in their deployment will find themselves in a more manageable situation than those who don't. Updates shall be timely and should not impact on the functioning of the device. The update policy needs to enforce an anti-rollback mechanism so that older versions cannot become a possible attack vector.
Software update practices also cover the end-of-life policy so that updates should be provided to and pushed to devices for a specified period.
4. Securely store credentials and security-sensitive data
This practice says any credential should be stored securely within services and on devices. In device software, hardcoded credentials like passwords and bank account information are not acceptable. MCU’s device-specific security features and memory management should always be fully enabled for protecting security-sensitive data.
5. Communicate securely
IoT devices should follow secure communications using Transport Layer Security (TLS) or Lightweight Cryptography (LWC) and always use the latest versions. This means that security-sensitive data should be encrypted in transit and keys should be managed securely.
6. Minimize exposed attack surfaces
The ambition is to minimize exposed attack surfaces, which says all devices and services should operate on the ‘principle of least privilege’. This is one of the most important principles and connected to the code quality since software defects or code vulnerabilities are the doors that hackers use, to exploit IoT devices.
Code quality needs to be enforced by design. There are many standards available but especially the CERT C Coding Standard [2], which is developed and owned by the Software Engineering Institute at Carnegie Mellon University, provides rules for secure coding in the C programming language. The goal of these rules and recommendations is to develop safe, reliable, and secure systems, for example by eliminating undefined behaviors that can lead to undefined program behaviors and exploitable vulnerabilities.
Most of the common security holes are known and developers keep injecting the same errors over and over. The good news is that these bad coding habits are addressed in coding standards like the Common Weakness Enumeration (CWE) [3] from mitre.org and point out additional areas of concern like data injection, null pointer exploits and string parsing errors. MISRA C [4] and MISRA C++ also promote safe and reliable coding practices to prevent security vulnerabilities ending up in your code. High-quality static analysis tools include checks for CWE, MISRA, and CERT C so the code quality can be enforced on the day-by-day.
7. Ensure software integrity
This means software on IoT devices should be verified using secure boot mechanisms. If an unauthorized change is detected the device should alert the consumer and make sure that the software is verified and secured.
A secure boot procedure is critical to ensure the integrity of an IoT device. Secure boot is frequently alluded to as the Root of Trust. A Root of Trust must be a computing engine that performs a lot of action and has a set of unconditionally trusted functions. The Root of Trust is then implemented via a Secure Boot Manager. This way you can ensure the verification of the user application which is a key part of every power-up cycle.
8. Ensure personal data is protected
This article will not cover the ways that personal data should be managed and protected. This might change slightly from region to region depending on the local standards and data protection laws. That said, this guideline is very important and companies need to be transparent allowing consumers to withdraw their information at any time.
9. Make systems resilient to outages
Resilience should be built into IoT devices so that if a device has a vulnerability, somebody hacks it and you don't want to necessarily just shut it down, especially if it's something like a pacemaker. That would be bad! So, the idea is to have some resilience where it could still provide a restricted service or at least tell the user that something's happened and devices should be able to return to a network in a sensible state and in an orderly fashion rather than a massive scale reconnect.
10. Monitor system telemetry data
Telemetry is the collection of measurements or other data at remote points and their automatic transmission to receiving equipment for monitoring. The best security practice says 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
IoT devices may change ownership and will in the long run be reused or discarded. This is something that the product designers must implement in the application and it should be configured so that personal data can be easily removed. So, you can transfer ownership as well. Maybe you want to give it to a friend, but you would like to delete your data before giving it to them.
12. Make installation and maintenance of devices easy
The user interface for IoT devices and supporting services should be intuitive, user friendly, and provide appropriate feedback for user actions that affect such policy and its enforcement.
It is the recommendation that manufacturers test the security of each device with a range of possible configurations, as opposed to simply the default configuration. A device’s interface should prevent—or at least actively discourage—users from configuring the device in a way that makes it less secure.
13. Validate input data
The last best security practice is to validate input data. This principle says do not trust data received and always verify any interconnections. Discover, identify, and authenticate the devices connected to the network before trust can be established, and preserve their integrity for trustable solutions and services. This could include checking the data type, length, format, range, authenticity, origin, and frequency because attackers use automated tools to exploit potential gaps like out of bounds, arithmetical errors, and memory inconsistency errors due to not validating data. These vulnerabilities can be exploited by hackers to run any code they want and take over the control of the IoT device.
Runtime analysis tools, that instrument the code can be very helpful in testing and validating input data during development so that the application is protected against bad manipulation in the field. Automated runtime tools during development and field testing can trigger and point to hidden problems, so the source code can be adjusted and the IoT application protected against missuses.
Security legislation in your favor
Many countries are working in parallel when it comes to security legislation. In the EU, the European Union Agency for Cybersecurity (ENISA) compiled the baseline recommendations from the initial guidelines. In the USA, there is the National Institute of Standards and Technology (NIST) focusing on the evolving cybersecurity act alongside the IoT security law in California. Finally, in Asia we have the Japanese government working with Connected Consumer Device Security Council (CCDS) on best practices and worth to mention Singapore, China and South Korea having ongoing working groups for standards and certifications.
Mostly the principles are fundamentally aligned to that published by the IoT Security Foundation in its IoT Security Best Practice Guides [5].
All these freely available guidelines help IoT products and services developers address the varied security issues that must be addressed to deliver a safe, secure, trusted, and mature product.
Security Contexts enabling security by design
Following all the guidelines and best practices is not a trivial task. Implementing the security foundation by integrating and combining the secure device boot, the cryptographic device identities, a Root of Trust, credential management and encryption to secure software and communication with Transport Layer Security (TLS) and enforcing code quality might be a long journey without having access to the right tools.
One of the recommended solutions is to define a Security Context right at the outset of a project – its inception. This should be a description of the security environment that is required to secure your IoT application and be compliant with the standards and guidelines. Having a defined Security Context early will allow developers to rapidly implement the required security ensuring repeatability and reducing development effort over multiple projects. The Security Context can be customized to suit a broad range of IoT applications.
A Security Context should define:
- Robust Root of Trust, ensuring device authentication, authorization and attestation, the core proofs of identity
- Cryptographic device identities and ownership structures
- Implementation of security hygiene, dependent on device hardware support
- Secure Boot Manager extensions to support core boot functionality
- Software updates, and other lifecycle management criteria.
These Security Contexts provide the foundation for a core set of security features, enabling security by design as demanded by the guidelines. Once integrated into the development tools, the security context will automatically be enforced and effectively applies the guidelines so that the process can become easy and naturally integrated into the development of your new IoT product.
It all starts and comes back to code quality
From conception, product developers need to get access to the right tools to be able to ensure code quality, closing any code vulnerabilities and to deliver secure, encrypted code by enforcing the security and encryption settings extracted from security configuration profiles (Security Contexts). The Secure Boot Manager will take advantage of the device security features and set the Root of Trust together with the secrets (keys) and services to enforce all policies. The overall ambition is to ensure that products are secure by design and to make it easier for people to stay secure in a digital world. As stated in this series of articles already, it all starts and comes back to the code quality being the foundations to trigger the security by design.
Written by Clive Watts, Director of Product Management, Embedded Security Solutions, IAR Systems