ENISA Baseline Security Recommendations for IoT
Good Practices | Description | ||
4.1.1 | Security by Design | GP-PS-01: Consider the security of the whole IoT system from a consistent and holistic approach during its whole lifecycle across all levels of device/application design and development, integrating security throughout the development, manufacture, and deployment. GP-PS-02: Ensure the ability to integrate different security policies and techniques. GP-PS-03: Security must consider the risk posed to human safety. GP-PS-04: Designing for power conservation should not compromise security. GP-PS-05: Design architecture by compartments to encapsulate elements in case of attacks. GP-PS-06: For IoT hardware manufacturers and IoT software developers it is necessary to implement test plans to verify whether the product performs as it is expected. Penetration tests help to identify malformed input handling, authentication bypass attempts and overall security posture. GP-PS-07: For IoT software developers it is important to conduct code review during implementation as it helps to reduce bugs in a final version of a product. | N/A |
4.1.2 | Privacy by Design | GP-PS-08: Make privacy an integral part of the system. GP-PS-09: Perform privacy impact assessments before any new applications are launched. | I6 Insufficient Privacy Protection |
4.1.3 | Asset Management | GP-PS-10: Establish and maintain asset management procedures and configuration controls for key network and information systems. | I8 Lack of Device Management |
4.1.4 | Risk and Threat Identification and Assessment | GP-PS-11: Identify significant risks using a defence-in-depth approach. GP-PS-12: Identify the intended use and environment of a given IoT device. | N/A |
4.2.1 | End-of-life Support | GP-OP-01: Develop an end-of-life strategy for IoT products. GP-OP-02: Disclose the duration and end-of-life security and patch support (beyond product warranty). GP-OP-03: Monitor the performance and patch known vulnerabilities up until the “end-of-support" period of a product’s lifecycle. | I8 Lack of Device Management |
4.2.2 | Proven Solutions | GP-OP-04: Use proven solutions, i.e. well known communications protocols and cryptographic algorithms, recognized by the scientific community, etc. Certain proprietary solutions, such as custom cryptographic algorithms, should be avoided. | I5 Use of Insecure or Outdated Components |
4.2.3 | Management of Security Vulnerabilities and/or Incidents | GP-OP-05: Establish procedures for analysing and handling security incidents. GP-OP-06: Coordinated disclosure of vulnerabilities. GP-OP-07: Participate in information-sharing platforms to report vulnerabilities and receive timely and critical information about current cyber threats and vulnerabilities from public and private partners. GP-OP-08: Create a publicly disclosed mechanism for vulnerability reports, e.g. Bug Bounty programs. | N/A |
4.2.4 | Human Resources Security Training and Awareness | GP-OP-09: Ensure the personnel practices promote privacy and security – train employees in good privacy and security practices. GP-OP-10: Document and monitor the privacy and security training activities. GP-OP-11: Ensure that cybersecurity roles and responsibilities for all workforce are established and introduce personnel assignments in accordance with the specifics of the projects and security engineering needs. | N/A |
4.2.5 | Third-Party Relationships | GP-OP-12: Data processed by a third-party must be protected by a data processing agreement. GP-OP-13: Only share consumers’ personal data with third parties with express consent of the consumers, unless otherwise required and limited for the use of product features or service operations. GP-OP-14: For IoT hardware manufacturers and IoT software developers it is necessary to adopt cyber supply chain risk management policies and to communicate cyber security requirements to its suppliers and partners. | N/A |
4.3.1 | Hardware Security | GP-TM-01: Employ a hardware-based immutable root of trust. GP-TM-02: Use hardware that incorporates security features to strengthen the protection and integrity of the device – for example, specialised security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical attacks can be covered via functional security. | I10 Lack of Physical Hardening |
4.3.2 | Trust and Integrity Management | GP-TM-03: Trust must be established in the boot environment before any trust in any other software or executable program can be claimed. GP-TM-04: Sign code cryptographically to ensure it has not been tampered with after signing it as safe for the device, and implement run-time protection and secure execution monitoring to make sure malicious attacks do not overwrite code after it is loaded. GP-TM-05: Control the installation of software in operating systems, to prevent unauthenticated software and files from being loaded onto it. GP-TM-06: Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful. GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships. | I4 Lack of Secure Update Mechanism I8 Lack of Device Management I9 Insecure Default Settings |
4.3.3 | Strong Default Security and Privacy | GP-TM-08: Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default. GP-TM-09: Establish hard to crack, device-individual default passwords. | I1 Weak, Guessable, or Hardcoded Passwords I9 Insecure Default Settings |
4.3.4 | Data Protection and Compliance | GP-TM-10: Personal data must be collected and processed fairly and lawfully, it should never be collected and processed without the data subject’s consent. GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any further processing of personal data is compatible and that the data subjects are well informed. GP-TM-12: Minimise the data collected and retained. GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR). GP-TM-14: Users of IoT products and services must be able to exercise their rights to information, access, erasure, rectification, data portability, restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated processing. | I6 Insufficient Privacy Protection |
4.3.5 | System Safety and Reliability | GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing an unacceptable risk of injury or physical damage. GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state. GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and chronicle negative impacts from compromised devices or cloud-based systems. | I8 Lack of Device Management |
4.3.6 | Secure Software/ Firmware Updates | GP-TM-18: Ensure that the device software/firmware, its configuration and its applications have the ability to update Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it does not contain sensitive data (e.g. hardcoded credentials), that it is signed by an authorised trust entity and encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate and signing certificate chain, verified by the device before the update process begins. GP-TM-19: Offer an automatic firmware update mechanism. GP-TM-20: Backward compatibility of firmware updates. Automatic firmware updates should not modify user-configured preferences, security, and/or privacy settings without user notification. | I1 Weak, Guessable, or Hardcoded Passwords I4 Lack of Secure Update Mechanism I8 Lack of Device Management |
4.3.7 | Authentication | GP-TM-21: Design the authentication and authorisation schemes (unique per device) based on the system-level threat models. GP-TM-22: Ensure that default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed. GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., on top of certificates. GP-TM-24: Authentication credentials shall be salted, hashed and/or encrypted. GP-TM-25: Protect against ‘brute force’ and/or other abusive login attempts. This protection should also consider keys stored in devices. GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with information indicating a valid account. The same applies to key update and recovery mechanisms. | I1 Weak, Guessable, or Hardcoded Passwords I3 Insecure Ecosystem Interfaces |
4.3.8 | Authorisation | GP-TM-27: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible. GP-TM-28: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware that do not need access to them. Device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code. | I1 Weak, Guessable, or Hardcoded Passwords I9 Insecure Default Settings |
4.3.9 | Access Control - Physical and Environmental Security | GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy. GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance. GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity. GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed. GP-TM-33: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to function and that the test/debug modes are secure, so they cannot be used to maliciously access the devices. In general, lock down physical ports to only trusted connections. | I1 Weak, Guessable, or Hardcoded Passwords I3 Insecure Ecosystem Interfaces I6 Insufficient Privacy Protection I10 Lack of Physical Hardening |
4.3.10 | Cryptography | GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation. GP-TM-35: Cryptographic keys must be securely managed. GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques. GP-TM-37: Support scalable key management schemes. | I7 Insecure Data Transfer and Storage |
4.3.11 | Secure and Trusted Communications | GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud. GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption. GP-TM-40: Ensure credentials are not exposed in internal or external network traffic. GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should always be signed whenever and wherever it is captured and stored. GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, and preserve their integrity for reliable solutions and services. GP-TM-43: IoT devices should be restrictive rather than permissive in communicating. GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is connected to, at all levels of the protocols. GP-TM-45: Disable specific ports and/or network connections for selective connectivity. GP-TM-46: Rate limiting. Controlling the traffic sent or received by a network to reduce the risk of automated attacks. | I2 Insecure Network Services I3 Insecure Ecosystem Interfaces I7 Insecure Data Transfer and Storage |
4.3.12 | Secure Interfaces and Network Services | GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk. GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set. GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would be enough to expose the rest of the product family. GP-TM-50: Ensure only necessary ports are exposed and available. GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure. GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services, and that they are not susceptible to XSS, CSRF, SQL injection, etc. GP-TM-53: Avoid security issues when designing error messages. | I2 Insecure Network Services I3 Insecure Ecosystem Interfaces |
4.3.13 | Secure Input and Output Handling | GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering. | I3 Insecure Ecosystem Interfaces |
4.3.14 | Logging | GP-TM-55: Implement a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system. Logs must be preserved on durable storage and retrievable via authenticated connections. | I8 Lack of Device Management |
4.3.15 | Monitoring and Auditing | GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors. GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually. | I8 Lack of Device Management |
Last updated