IoT Security
19.Jun.2023
How to comply with the mandatory cybersecurity regulation RED-DA in light of ETSI EN 303 645 standard becoming a global trend?
Given the continuous rise in the popularity of home smart devices, the potential risks posed by unresolved cybersecurity vulnerabilities in these devices can be a significant threat to personal data and consumer privacy. This issue should not be taken lightly. To address this issue, the European Telecommunications Standards Institute (ETSI) Network Security Technical Committee released the "ETSI EN 303 645 Cyber Security for Consumer Internet of Things: Baseline Requirements" in June 2020. This standard, which originally started as TS 103 645 in June 2018, was upgraded to an EN standard and renamed in February 2019. The ETSI EN 303 645 standard focuses on the network security of consumer IoT products and incorporates GDPR (General Data Protection Regulation) data protection provisions. The main purpose of this standard is to provide a unified framework and security baseline to help IoT product manufacturers enhance the network security of their products. It aims to ensure effective management and implementation of security and privacy protection, reducing the risks of device intrusion or misuse. Ensuring the security and privacy of IoT products has become a global trend.
According to Qin-Qiang Pan, the Deputy Director of the Technical Services Division at Onward Security, under the EU's cybersecurity law for communication products, there are three levels of network security: Basic, Substantial, and High. Each level has corresponding standards and compliance criteria. The Basic level, in particular, applies to the EN 303 645 standard. To date, many countries and regions, including the European Union, Singapore, Finland, and Germany, among others, have adopted EN 303 645 as the foundation for their cybersecurity regulations. According to the upcoming EU Radio Equipment Directive: the Delegated Act for cyber security, RED-DA Article 3.3 d/e/f, which will be enforced in 2025, strict requirements are set for market entry of wireless devices, including consumer IoT products. These requirements aim to prevent network abuse, enhance personal data and privacy protection, and establish security provisions against fraud. Products must meet these requirements, undergo testing, and obtain relevant validation before they can be introduced to the market.
Prioritize the implementation of SSDLC (Secure Software Development Life Cycle) to ensure the security of the development process
Qin-Qiang Pan mentioned that in order to provide clear guidance for global manufacturers/developers, the European Commission issued a standardization request in August 2002. This request was aimed at harmonizing standards and was developed by CEN/CENELEC. The Harmonized Standard incorporates elements from ETSI EN 303 645 and IEC 62443 standards. To comply with the cybersecurity regulation, in addition to using ETSI EN 303 645 and IEC 62443 standards as guidelines, manufacturers/developers should prioritize the implementation of a Secure Software Development Lifecycle (SSDLC). This will enable manufacturers/developers to identify and address any security issues in the early stages of the product lifecycle.
The EN 303 645 standard, aimed at ensuring the security and privacy of IoT devices and personal data, puts forward a series of requirements and recommendations. These include prohibiting the use of generic default passwords, allowing individuals to delete their personal data, and requiring manufacturers to establish vulnerability reporting processes and mechanisms. The emerging trend in network security standards means that simply completing product development and undergoing security testing will not meet the requirements of regulations such as RED-DA. The referenced harmonized standard, whether it is IEC 62443-4-1 or ETSI EN 303 645, both include the "Secure by Design” requirement. In other words, manufacturers/developers cannot solely rely on completing the development of product features to achieve EN 303 645 certification. They must also demonstrate the security of the entire development process. By implementing SSDLC, we can ensure that our product follows these security requirements throughout the development process, thus achieving "Secure by Design," further meeting the requirements of regulations such as RED-DA. Indeed, as the harmonized standards for RED-DA are still under development, the specific scope and provisions have not been fully established. Therefore, for compliance purposes, the primary focus will be on the explanations and guidance of the EN 303 645 standard.
The EN 303 645 standard, aimed at ensuring the security and privacy of IoT devices and personal data, puts forward a series of requirements and recommendations. These include prohibiting the use of generic default passwords, allowing individuals to delete their personal data, and requiring manufacturers to establish vulnerability reporting processes and mechanisms. The emerging trend in network security standards means that simply completing product development and undergoing security testing will not meet the requirements of regulations such as RED-DA. The referenced harmonized standard, whether it is IEC 62443-4-1 or ETSI EN 303 645, both include the "Secure by Design” requirement. In other words, manufacturers/developers cannot solely rely on completing the development of product features to achieve EN 303 645 certification. They must also demonstrate the security of the entire development process. By implementing SSDLC, we can ensure that our product follows these security requirements throughout the development process, thus achieving "Secure by Design," further meeting the requirements of regulations such as RED-DA. Indeed, as the harmonized standards for RED-DA are still under development, the specific scope and provisions have not been fully established. Therefore, for compliance purposes, the primary focus will be on the explanations and guidance of the EN 303 645 standard.
ETSI EN 303 645 Testing, Verification, and Development Guidelines
As mentioned above, EN 303 645 sets out the basic requirements for IoT cyber security. In addition, to ensure consistency in testing and verification of this standard, ETSI released "TS 103 701 Cyber Security for Consumer Internet of Things: Conformance Assessment of Baseline Requirements" in 2021 which provides guidelines to testing laboratories on how to perform testing and assessment for the EN 303 645 standard. In 2020, ETSI also released "TR 103 621 Guide to Cyber Security for Consumer Internet of Things," which serves as an implementation guide for manufacturers/developers to understand and comply with the requirements of EN 303 645. This guide provides practical guidance on how to meet the compliance requirements of the standard. Indeed, with the inclusion of the complete set of standards, testing, verification, and development guidelines, EN 303 645 is now comprehensive in its coverage.
EN 303 645 covers a wide range of devices, including IoT gateways, smoke detectors, wearable smart devices, smart home systems, smart cameras, smart TVs, and speakers, among others. It has a broad scope that encompasses various types of IoT devices. Considering the diversity of IoT products and usage scenarios, the EN 303 645 standard takes into account devices with physical constraints such as limited computing, communication, storage, or power supply capabilities, and defines these devices as "constrained devices." Specific provisions are outlined to accommodate their characteristics and align with practical usage scenarios. However, mobile applications or cloud services are not within the scope of EN 303 645.
Qin-Qiang Pan further mentioned that EN 303 645 consists of 13+1 network security and data protection provisions, which include a total of 68 requirements. Among these requirements, 33 are mandatory, while the remaining 35 are recommended. It is worth mentioning that the well-known OWASP IoT Top 10 vulnerabilities in the cybersecurity field are mostly covered within the EN 303 645 standard. These vulnerabilities include weak passwords, hardcoded passwords, and inadequate privacy protection, etc. This implies that SO (supplier organizations; manufacturers/developers) must address these issues and find appropriate solutions.
How can supplier organizations embark on the journey of EN 303 645 compliance? First, the development team should first adopt the "Secure Software Development Lifecycle" (SSDLC) concept. This concept is also present in IEC 62443 and emphasizes the implementation of secure design, known as “Secure by Design.” It involves incorporating security considerations during the product design phase. Next, it is necessary to refer to documents such as EN 303 645 and TR 103 621 to understand the relevant requirements and ensure that the product design and development align with these standards. Once the product development is complete, you can commission a qualified third-party testing laboratory, such as Onward Security, to conduct the testing. Subsequently, the testing laboratory, in accordance with the TS 103 701 specifications, will request the supplier organization (SO) to fill out documents such as the Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT). Based on these documents, the laboratory will develop a testing plan and proceed with the testing operations.
EN 303 645 covers a wide range of devices, including IoT gateways, smoke detectors, wearable smart devices, smart home systems, smart cameras, smart TVs, and speakers, among others. It has a broad scope that encompasses various types of IoT devices. Considering the diversity of IoT products and usage scenarios, the EN 303 645 standard takes into account devices with physical constraints such as limited computing, communication, storage, or power supply capabilities, and defines these devices as "constrained devices." Specific provisions are outlined to accommodate their characteristics and align with practical usage scenarios. However, mobile applications or cloud services are not within the scope of EN 303 645.
Qin-Qiang Pan further mentioned that EN 303 645 consists of 13+1 network security and data protection provisions, which include a total of 68 requirements. Among these requirements, 33 are mandatory, while the remaining 35 are recommended. It is worth mentioning that the well-known OWASP IoT Top 10 vulnerabilities in the cybersecurity field are mostly covered within the EN 303 645 standard. These vulnerabilities include weak passwords, hardcoded passwords, and inadequate privacy protection, etc. This implies that SO (supplier organizations; manufacturers/developers) must address these issues and find appropriate solutions.
How can supplier organizations embark on the journey of EN 303 645 compliance? First, the development team should first adopt the "Secure Software Development Lifecycle" (SSDLC) concept. This concept is also present in IEC 62443 and emphasizes the implementation of secure design, known as “Secure by Design.” It involves incorporating security considerations during the product design phase. Next, it is necessary to refer to documents such as EN 303 645 and TR 103 621 to understand the relevant requirements and ensure that the product design and development align with these standards. Once the product development is complete, you can commission a qualified third-party testing laboratory, such as Onward Security, to conduct the testing. Subsequently, the testing laboratory, in accordance with the TS 103 701 specifications, will request the supplier organization (SO) to fill out documents such as the Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT). Based on these documents, the laboratory will develop a testing plan and proceed with the testing operations.
Verify the reasonableness of the design before validating the design's authenticity
For the testing laboratory, the SO is required to submit an Implementation Conformance Statement (ICS) that declares the relevant implementations made in the Device Under Test (DUT). The ICS should provide detailed information about the functionalities implemented or supported in the DUT and include four different statuses: Mandatory Requirements, Recommended Requirements, Mandatory Requirements with Conditions, and Recommended Requirements with Conditions. The SO must provide detailed information in the ICS accordingly. It is important to note that to achieve overall compliance, all items under the mandatory requirements must be supported and pass testing. For the items under Mandatory Requirements with Conditions and Recommended Requirements with Conditions, if the specified conditions are not met, the standard allows them to be marked as "not applicable," provided that a reasonable explanation or justification is provided. As for items under Recommended Requirements, if the SO chooses to undergo testing (as the standard encourages application for testing), they can still fill them as "YES." However, during the sixth stage of "Overall Conformance Assessment," if it is determined that a certain Recommended Requirement has not passed the test, the "Overall Conformance Assessment" will not be successful. Therefore, the SO and the testing laboratory need to negotiate and decide which Recommended Requirements or Recommended Requirements with Conditions should be excluded to meet the specific conformance assessment of the standard.
In addition to the Implementation Conformance Statement, the SO should provide detailed information about the design and implementation of the tested device by filling out the Implementation eXtra Information for Testing (IXIT) form. This form consists of 29 separate tables and aims to provide test personnel with an understanding of the product's design, implementation methods, and the content that needs to be tested. For example, it may include information such as the device's ability to access via the HTTPS protocol on port 443 and its authentication factor being a pre-installed password. This would entail details about the default password generation method, cryptographic applications related to password security (such as which security suites are used for HTTPS over a TLS channel), and other relevant information. The testing laboratory needs to receive appropriate explanations and documentation to conduct comprehensive security testing on the tested device. This ensures that the laboratory has a clear understanding of the device's design, implementation, and specific requirements for testing.
In other words, the testing laboratory will conduct security testing on each item listed as "YES" in the Implementation Conformance Statement. The standard does not specify the specific testing tools and procedures to be used. Therefore, different laboratories may employ different tools to test the same security item. In addition, considering the test scenarios listed in TS 103 701, for example, 5.1-1, it encompasses two different test cases: Conceptual Verification and Functional Verification. The Conceptual Verification is primarily based on the corresponding design content provided in the IXIT form and aims to validate the reasonableness of the design content documented by the SO. Once the Conceptual Verification is completed and deemed satisfactory, then proceeds the Functional Verification phase, where the actual operation of the product is tested to ensure its alignment with the design content specified in the IXIT form.
After completing the testing, the testing laboratory will provide a test report that includes the verification and test results. If the design is deemed reasonable and the actual verification aligns with the requirements, it will be assessed as a "Pass." However, if any aspect of the testing is assessed as a "Fail," it will not pass the overall conformance verification. However, if the overall assessment does not pass due to the failure of Recommended Requirements or Recommended Requirements with Conditions (which are not mandatory), it is possible to declare non-compliance with those items in the Implementation Conformance Statement. This can be done to achieve an overall pass assessment.
Based on practical experience, Qin-Qiang Pan shares several key points that SO should pay attention to: For example, if a product uses the HTTP protocol to transmit username and password authentication packets, it poses a security risk as HTTP transmits data in plain text. Even if the transmitted content is encoded or weakly encrypted, there is still a chance that hackers are able to crack the encryption. In the mentioned case, despite the protection provided by MD5, the testing personnel were able to reverse undo it, resulting in the failure of the authentication verification. Indeed, factors such as whether the SO has implemented a vulnerability disclosure policy, conducted software updates, or uses secure versions of encryption suites in communication (e.g., TLS 1.2 or higher) are all crucial testing points.
In summary, it is recommended for SOs to consider ETSI TS 103 621 as an important guideline and reference document during implementation. If necessary, seeking guidance or assistance from experts can help shorten the implementation timeline. Please note that it is not only the EN 303 645 standard that has incorporated SSDLC into its regulations, but other standards as well; including the OT/IIoT domain IEC 62443 standards, automotive sector ISO/SAE 21434, etc. This has become the consensus and best practice in today's industry. Therefore, the first step towards achieving compliance with network security standards is to implement the SSDLC. Moreover, it is crucial to closely monitor and comply with relevant regulations and standards in your field to ensure that your IoT devices have appropriate security and privacy measures in place. If needed, always seek the assistance and guidance of experts to ensure a smooth implementation process and to achieve compliance with legal and regulatory requirements.
In addition to the Implementation Conformance Statement, the SO should provide detailed information about the design and implementation of the tested device by filling out the Implementation eXtra Information for Testing (IXIT) form. This form consists of 29 separate tables and aims to provide test personnel with an understanding of the product's design, implementation methods, and the content that needs to be tested. For example, it may include information such as the device's ability to access via the HTTPS protocol on port 443 and its authentication factor being a pre-installed password. This would entail details about the default password generation method, cryptographic applications related to password security (such as which security suites are used for HTTPS over a TLS channel), and other relevant information. The testing laboratory needs to receive appropriate explanations and documentation to conduct comprehensive security testing on the tested device. This ensures that the laboratory has a clear understanding of the device's design, implementation, and specific requirements for testing.
In other words, the testing laboratory will conduct security testing on each item listed as "YES" in the Implementation Conformance Statement. The standard does not specify the specific testing tools and procedures to be used. Therefore, different laboratories may employ different tools to test the same security item. In addition, considering the test scenarios listed in TS 103 701, for example, 5.1-1, it encompasses two different test cases: Conceptual Verification and Functional Verification. The Conceptual Verification is primarily based on the corresponding design content provided in the IXIT form and aims to validate the reasonableness of the design content documented by the SO. Once the Conceptual Verification is completed and deemed satisfactory, then proceeds the Functional Verification phase, where the actual operation of the product is tested to ensure its alignment with the design content specified in the IXIT form.
After completing the testing, the testing laboratory will provide a test report that includes the verification and test results. If the design is deemed reasonable and the actual verification aligns with the requirements, it will be assessed as a "Pass." However, if any aspect of the testing is assessed as a "Fail," it will not pass the overall conformance verification. However, if the overall assessment does not pass due to the failure of Recommended Requirements or Recommended Requirements with Conditions (which are not mandatory), it is possible to declare non-compliance with those items in the Implementation Conformance Statement. This can be done to achieve an overall pass assessment.
Based on practical experience, Qin-Qiang Pan shares several key points that SO should pay attention to: For example, if a product uses the HTTP protocol to transmit username and password authentication packets, it poses a security risk as HTTP transmits data in plain text. Even if the transmitted content is encoded or weakly encrypted, there is still a chance that hackers are able to crack the encryption. In the mentioned case, despite the protection provided by MD5, the testing personnel were able to reverse undo it, resulting in the failure of the authentication verification. Indeed, factors such as whether the SO has implemented a vulnerability disclosure policy, conducted software updates, or uses secure versions of encryption suites in communication (e.g., TLS 1.2 or higher) are all crucial testing points.
In summary, it is recommended for SOs to consider ETSI TS 103 621 as an important guideline and reference document during implementation. If necessary, seeking guidance or assistance from experts can help shorten the implementation timeline. Please note that it is not only the EN 303 645 standard that has incorporated SSDLC into its regulations, but other standards as well; including the OT/IIoT domain IEC 62443 standards, automotive sector ISO/SAE 21434, etc. This has become the consensus and best practice in today's industry. Therefore, the first step towards achieving compliance with network security standards is to implement the SSDLC. Moreover, it is crucial to closely monitor and comply with relevant regulations and standards in your field to ensure that your IoT devices have appropriate security and privacy measures in place. If needed, always seek the assistance and guidance of experts to ensure a smooth implementation process and to achieve compliance with legal and regulatory requirements.
