Enisa Req
Source: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures November 2017
# | Requirement Nr | Description | Good Practice | Is Fullfilled By | Remarks | |
---|---|---|---|---|---|---|
1 | GP-TM-57 | Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually. | Monitoring and Auditing | View | ||
2 | GP-TM-56 | Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors. | Monitoring and Auditing | View | ||
3 | 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. | Logging | View | ||
4 | GP-TM-54 | Data input validation (ensuring that data is safe prior to use) and output filtering. | Secure input and output handling | View | ||
5 | GP-TM-53 | Avoid security issues when designing error messages. | Secure Interfaces and network services | View | ||
6 | 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. | Secure Interfaces and network services | View | ||
7 | GP-TM-51 | Implement a DDoS-resistant and Load-Balancing infrastructure. | Secure Interfaces and network services | View | ||
8 | GP-TM-50 | Ensure only necessary ports are exposed and available. | Secure Interfaces and network services | View | ||
9 | 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. | Secure and trusted communications | View | ||
10 | GP-TM-48 | Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set. | Secure and trusted communications | View | ||
11 | GP-TM-47 | Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk. | Secure and trusted communications | View | ||
12 | GP-TM-46 | Rate limiting – controlling the traffic sent or received by a network to reduce the risk of automated attacks. | Secure and trusted communications | View | ||
13 | GP-TM-45 | Disable specific ports and/or network connections for selective connectivity. | Secure and trusted communications | View | ||
14 | 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. | Secure and trusted communications | View | ||
15 | GP-TM-43 | IoT devices should be restrictive rather than permissive in communicating. | Secure and trusted communications | View | ||
16 | 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. | Secure and trusted communications | View | ||
17 | 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. | Secure and trusted communications | View | ||
18 | GP-TM-40 | Ensure credentials are not exposed in internal or external network traffic. | Secure and trusted communications | View | ||
19 | GP-TM-39 | Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption. | Secure and trusted communications | View | ||
20 | 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. | Secure and trusted communications | View | ||
21 | GP-TM-37 | Support scalable key management schemes. | Cryptography | View | ||
22 | GP-TM-36 | Build devices to be compatible with lightweight encryption and security techniques. | Cryptography | View | ||
23 | GP-TM-35 | Cryptographic keys must be securely managed. | Cryptography | View | ||
24 | 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. | Cryptography | View | ||
25 | 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. | Access Control - Physical and Environmental security | View | ||
26 | 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. | Access Control - Physical and Environmental security | View | ||
27 | GP-TM-31 | Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity. | Access Control - Physical and Environmental security | View | ||
28 | GP-TM-30 | Ensure a context-based security and privacy that reflects different levels of importance. | Access Control - Physical and Environmental security | View | ||
29 | 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. | Access Control - Physical and Environmental security | View | ||
30 | GP-TM-28 | Device firmware should be designed to isolate privileged code and data from portions of the firmware that do not need access to them, and device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code. | Authorisation | 0 | 0 | View |
31 | GP-TM-27 | Limit the permissions of actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP) | Authorisation | 0 | 0 | View |
32 | 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. | Authentication | View | ||
33 | GP-TM-25 | Protect against ‘brute force’ and/or other abusive login attempts. This protection should also consider keys stored in devices. | Authentication | View | ||
34 | GP-TM-24 | Authentication credentials including but not limited to user passwords shall be salted, hashed and/or encrypted. | Authentication | View | ||
35 | 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., and certificates. | Authentication | View | ||
36 | GP-TM-22 | Ensure default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed. | Authentication | View | ||
37 | GP-TM-21 | Design the authentication and authorization schemes (unique per device) based on the system-level threat models. | Authentication | View | ||
38 | 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. | Secure Software / Firmware updates | View | ||
39 | GP-TM-19 | Offer an automatic firmware update mechanism. | Secure Software / Firmware updates | View | ||
40 | 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), and 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. | Secure Software / Firmware updates | View | ||
41 | 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. | System safety and reliability | View | ||
42 | GP-TM-16 | Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state. | System safety and reliability | View | ||
43 | GP-TM-15 | Design with system and operational disruption in mind, preventing the system from causing unacceptable risk of injury or physical damage. | System safety and reliability | View | ||
44 | GP-TM-14 | Users 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. | Data protection and compliance | View | ||
45 | GP-TM-13 | IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR). | Data protection and compliance | View | ||
46 | GP-TM-12 | Minimize the data collected and retained. | Data protection and compliance | View | ||
47 | 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. | Data protection and compliance | View | ||
48 | GP-TM-10 | Personal data must be collected and processed fairly and lawfully. The fairness principle specifically requires that personal data should never be collected and processed without the user’s consent. | Data protection and compliance | View | ||
49 | GP-TM-09 | Establish hard to crack device individual default passwords. | Strong default security and privacy | View | ||
50 | GP-TM-08 | Enable security by default. Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default. | Strong default security and privacy | View | ||
51 | GP-TM-07 | Use protocols and mechanisms able to represent and manage trust and trust relationships. | Trust and Integrity Management | View | ||
52 | GP-TM-06 | Restore Secure State - Enable a system to return to a state that is known to be secure, after a security breach occurs or if an upgrade is not successful. | Trust and Integrity Management | View | ||
53 | GP-TM-05 | Control the installation of software on operational systems, to prevent unauthenticated software and files being loaded onto it. | Trust and Integrity Management | View | ||
54 | GP-TM-04 | Sign code cryptographically to ensure it has not been tampered after being signed as safe for the device, and implement run-time protection and secure execution monitoring to be sure malicious attacks do not overwrite code after it is loaded. | Trust and Integrity Management | View | ||
55 | GP-TM-03 | The boot process initializes the main hardware components, and starts the operating system. Trust must be established in the boot environment before any trust in any other software or executable program can be claimed. | Trust and Integrity Management | View | ||
56 | GP-TM-02 | Use hardware that incorporates security features to strengthen the protection and integrity of the device - specialized 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. | Hardware security | View | ||
57 | GP-TM-01 | Employ a hardware-based immutable root of trust. | Hardware security | View | ||
58 | GP-PS-12 | Identify the intended use and environment of a given IoT device | Risks and Threats Identification and Assessment | View | ||
59 | GP-PS-11 | Identify significant risks using a defence-in-depth approach | Risks and Threats Identification and Assessment | View | ||
60 | GP-PS-10 | Establish and maintain asset management procedures and configuration controls for key network and information systems. | Asset Management | View | ||
61 | GP-PS-09 | Perform privacy impact assessments before any new applications are launched | Privacy by design | View | ||
62 | GP-PS-08 | Make privacy an integral part of the system | Privacy by design | View | ||
63 | 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. | Security by design | View | ||
64 | 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. | Security by design | View | ||
65 | GP-PS-05 | Design architecture by compartments to encapsulate elements in case of attacks. | Security by design | View | ||
66 | GP-PS-04 | Designing for power conservation should not compromise security | Security by design | View | ||
67 | GP-PS-03 | Security must consider the risk posed to human safety | Security by design | View | ||
68 | GP-PS-02 | Ensure the ability to integrate different security policies and techniques. | Security by design | View | ||
69 | GP-PS-01 | Consider the security of the whole IoT system in 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 | Security by design | View | ||
70 | 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. | Third-Party relationships | View | ||
71 | GP-OP-13 | Only share consumers’ personal data with third parties with consumers’ affirmative consent, unless required and limited for the use of product features or service operation. | Third-Party relationships | View | ||
72 | GP-OP-12 | Data processed by a third-party must be protected by a data processing agreement. | Third-Party relationships | View | ||
73 | 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. | Human Resource Security Training and Awareness | View | ||
74 | GP-OP-10 | Document and monitor the privacy and security training activities. | Human Resource Security Training and Awareness | View | ||
75 | GP-OP-09 | Ensure the personnel practices promote privacy and security – train employees in good privacy and security practices. | Human Resource Security Training and Awareness | View | ||
76 | GP-OP-08 | Create a publicly disclosed mechanism for vulnerability reports, e.g. Bug Bounty programs. | Management of security vulnerabilities and/or incidents | View | ||
77 | 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. | Management of security vulnerabilities and/or incidents | View | ||
78 | GP-OP-06 | Coordinated disclosure of vulnerabilities. | Management of security vulnerabilities and/or incidents | View | ||
79 | GP-OP-05 | Establish procedures for analysing and handling security incidents. | Management of security vulnerabilities and/or incidents | View | ||
80 | GP-OP-04 | Proven solutions | geen opmerkingen | View | ||
81 | GP-OP-03 | Monitor the performance and patch known vulnerabilities for as long as possible during a product�s lifecycle. | End-of-life support | View | ||
82 | GP-OP-02 | Disclose the duration and end-of-life security and patch support (beyond product warranty). | End-of-life support | test | View | |
83 | GP-OP-01 | Develop an end-of-life strategy for IoT products. | End-of-life support | View | ||
Loading...
Saving...
Loading...