Cyber Resilience Act Requirements Standards Mapping - Joint Research Centre & ENISA Joint Analysis

Joint Research Centre & ENISA Joint Analysis

Abstract

The increasing number of cyberattacks affecting digital products, coupled with widespread vulnerabilities and insufficient timely security updates, creates heavy financial burdens on society. In response, the European Commission has drafted the Cyber Resilience Act (CRA), a new proposal for regulation to define the legislative framework of essential cybersecurity requirements that manufacturers must meet when placing any product with digital elements on the internal market. To facilitate adoption of the CRA provisions, these requirements need to be translated into the form of harmonised standards, with which manufacturers can comply. In support of the standardisation effort, this study attempt to identify the most relevant existing cybersecurity standards for each CRA requirement, analyses the coverage already offered on the intended scope of the requirement and highlights possible gaps to be addressed.

1

1 Introduction

On 15 September 2022, the European Commission published the proposal for the Cyber Resilience Act (CRA) [1], a proposal for a first ever EU-wide legislation of its kind, aimed at introducing mandatory cybersecurity requirements for products with digital elements throughout their lifecycle. The CRA proposal covers all products with digital elements put on the market which can be connected to a device or a network, including their building blocks (i.e., hardware and software) and encompassing also solutions provided in a Software as a Service (SaaS) fashion if they qualify as remote data processing solutions, as defined by Article 3(2) of the CRA proposal. The CRA proposal provides two sets of essential requirements: — Product cybersecurity requirements in Annex I, Section 1 of the CRA proposal — Vulnerability handling process requirements in Annex I, Section 2 of the CRA proposal These requirements should be the subject of a standardisation process by the European Standardisation Organizations (ESOs) to express them in the form of specifications in harmonised standards. The general principle is that for the products on the market, a self-assessment of compliance with the requirements specified in Annex I will be sufficient. For certain categories of more critical products, the application of harmonised standards will be required. For even more critical products, a third-party assessment will be mandatory. This report details the available standardisation outputs on the cybersecurity of products (hardware and software products, including hardware and software components of more complex products) carried out mainly by ESOs and international Standards Development Organizations (SDOs). Specifically, the study aim at presenting a mapping of the existing cybersecurity standards against the essential requirements listed in Annex I of the CRA proposal, along with a gap analysis between the mapped standards and the requirements. In view of the development of harmonised standards, this analysis offers a possible overview about the current coverage of the requirements by existing specifications, highlighting possible lacks that may be compensated by further standardisation work. Upon request of DG CNECT, this study has been developed jointly by the Joint Research Centre (JRC) and the European Union Agency for Cybersecurity (ENISA). This was also in line with the expectations of the proposal of regulation, in which it is stated that synergies on standardisation aspects should be considered between the Commission and ENISA. In Section 2, the methodology adopted to carry out this study is summarised. Section 3 is devoted to the presentation of the mapping between requirements and standards, giving an analysis of the coverage offered by the standards and possible gaps. In Section 4, a summary of all identified standards and their respective mapping is offered along with some overall remarks, while Section 5 is for conclusions.

2

2 Methodology

The development of the present study has been articulated in several stages summarised here below.

Identification of the standardisation organisations

The first step consisted in the identification of the entities that are considered relevant for standards in the specific area and that are recognised by the industry and scientific communities, giving precedence to European and international standardisation organisations. Specifically, the following ones have been taken into account: — CEN — CENELEC — ETSI — ISO — IEC — ITU

Identification of the committees and related standardisation activities

For each of the organisations listed above, the respective committees working on cybersecurity standards have been identified. For each one of the identified committees the list of standardisation activities, including ongoing activities, with potential relevance for the mapping have been identified, drafting a list of respective standards.

High level analysis of the standardisation activities

The standards identified above have been analysed based on freely available information to confirm their relevance to the specific topic. For those considered relevant a tentative mapping to the cybersecurity requirements expressed in Annex I of the CRA Regulation has been proposed, while the others have been discarded. Some statistics pertaining to this activity are summarised in Annex I of the present document, so as to give an order of magnitude of its extent. This high-level overview represented a preparatory ground for the insightful analysis of the next stage.

Mapping and analysis of requirements against standards

Once we listed all standards that might be relevant in a first quantitative analysis, the analysis took a bottom-up approach. For each CRA requirement the most relevant standards were selected based on an expert analysis, allowing to identify both the currently offered coverage and the potential gaps to be addressed at later standardisation stages. The requirements mapping and analysis process is presented in Figure 1, and the overall output of this stage is presented in Section 3.

3

The CRA cybersecurity essential requirements are presented in a list, and each of them is expressed in the form of generic text. To enhance the identification and evaluation of the standards possibly covering aspects captured by the CRA requirements it has been deemed useful to analyse them and highlight some core concepts. Specifically, for each essential requirement a set of sample sub-requirements and keywords have been identified. Such elements have served mainly as guide to identify the CRA-relevant standards, but there are not intended to represent a comprehensive list of sub-requirements, as a specific break-down of a requirement may depend on specificities of products and applications. To be noted that when an identified standard was available both in the form of international standard and European standard, we have referenced it according to the latter. In addition to the requirements-standards mapping, since the security requirements may apply to different stages of the products life-cycle, the study have been enriched with an information pointing out the possible relevance of a requirement with specific product life-cycle stages. This may be helpful under a manufacturer point of view to better navigate through the requirements and standards depending on at what stage a product is. The following high-level generic life-cycle that applies to all diversity of products has been taken as reference.

4

3 Requirements-Standards mapping and analysis

Here below each CRA requirement is mapped against relevant standards. For each standard is discussed the level of coverage offered for the requirement and possible gaps to be considered. For each requirement all the analysis are summarized in an overall consideration. The two subsections below reflect the two groups of requirements expressed in the CRA Annex I.

3.1 Security requirements relating to the properties of products with digital elements 3.1.1 (1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks;

Sample Sub-requirements:

— A cybersecurity risk analysis should be conducted and monitored during the complete lifecycle of the product — Cybersecurity should be taken into account in every step of the product creation (e.g. secure coding, security by design principles, etc.)

Keywords: risk, risk analysis, remediation strategy, secure coding

Standard Standard title Rationale Gap Life-Cycle ID

EN Information ISO 27002 includes While there are Implementation ISO/IEC security, controls related to indications for Validation 27002: cybersecurity secure coding and software 2022 and privacy information security development like Commissioning protection — in supplier the secure coding Surveillance Information agreements part, analogous security (demanding that the indications for a Maintenance controls suppliers ensure its secure hardware products/component design are missing s have the required in this standard, level of security, and although a more communicate all generic “Secure information system architecture regarding external and engineering software and principles” could in components used) principle make up for it in all those cases where hardware is acquired and incorporated but not designed.

5

EN Information Although not specific This standard is Design ISO/IEC security, to product security, generic and not 27005: cybersecurity this standard specific to product 2022 and privacy specifies how development protection — information security Guidance on risks should be managing managed. A proper information risk analysis is indeed security risks of paramount importance to understand which is the “appropriate level of cybersecurity based on the risks”

EN IEC Security for Although specific only This standard Design 62443-3- industrial to Industrial applies only to Implementation 2:2020 automation Automation and Industrial and control Control Systems Automation and Validation systems – (IACS), this standard Control System and covers in detail a does not cover Part 3-2: Security Risk cybersecurity Security risk Assessment process principles like assessment for focused on a system security by design system design design, including the re-evaluation phase after proper countermeasures have been implemented, determining the presence of residual and tolerable risks

EN IEC Security for Although specific only This standard Design 62443-4- industrial to Industrial applies only to Implementation 1:2018 automation Automation and Industrial and control Control Systems Automation and Validation systems – (IACS), this standard Control System and prescribes security does not cover the Part 4-1: principles (i.e. concept of risk Secure product security by design) to assessment development be included during lifecycle the various phases of requirements a product development.

ETSI EN CYBER; Cyber Promotes secure Detailed guidelines Design 303 645 Security for development and on risk analysis and Maintenance Consumer maintenance secure practices are

6

V2.1.1 Internet of practices, implies the not provided, but (2020-06) Things: need for risk analysis sometimes Baseline by setting a references to Requirements framework for secure relevant documents design, emphasizes are provided. secure development practices and data protection

Overall The various components of this requirement are covered within major coverage cybersecurity standards. Within these three selected standards, the gaps may be and summarised as follow:

possible

— The hardware design part is less covered when compared to the software

gaps

counterpart — A risk analysis process specifically targeted to system design is presented only for IACS, while the more general ISO 27005 standard is not specific to system or product design

Sample Sub-requirements:

— A vulnerability assessment should be performed against the digital elements of a product — Known exploitable vulnerabilities shall be fixed before the release of the product

Keywords: exploitable vulnerability, vulnerability assessment

Standard Standard Rationale Gap Life-Cycle ID

ISO/IEC Information Describes the minimum Covers only Validation 18045: security, actions to be performed for vulnerability 2022 cybersecurity a generic IT security discovery and and privacy evaluation. It includes a not fixing protection — dedicated section on vulnerabilities. Evaluation vulnerability assessment. Cites only one criteria for IT This section describes the discovery security — main elements that should technique Methodology be present in a vulnerability (penetration for IT security assessment with specific testing). evaluation steps and activities to be followed (such as penetration testing). (note: this is the standard used for the (note: it is intended to be Common used in conjunction with the Evaluation

7

Methodology Common Criteria - ISO/IEC (CEM)) 15408 series)

ITU-T Security Covers vulnerability Covers Validation X.1214 assessment detection of ICT network (software-based) Surveillance (03/2018) techniques in elements; both known and ICT network telecommunic unknown (zero-day) elements. Maintenance ation/informa vulnerabilities; covers Vulnerability tion and different techniques: detection only, communicatio scanning, fuzzing, code not fixing. There n technology review, binary analysis, is no detailed networks penetration testing, plus step-by-step some other supplementary procedure but techniques an example model that could be followed; the standard contains mainly a list of techniques that could be used, providing general descriptions of these techniques

EN IEC Security for Although specific only to This standard Validation 62443-4- industial Industrial Automation and applies only to Surveillance 1:2018 automation Control Systems (IACS), this Industrial and control standard contains several Automation and Maintenance systems – provisions related to Control System security testing, like Part 4-1: vulnerability testing and Secure penetration testing. product Moreover, it describes what development this tests should cover, who lifecycle should perform them, and requirements how to manage identified cybersecurity issues

ETSI EN CYBER; Cyber Provision 5.2-3 of the The standard Validation 303 645 Security for standard refers to secure lacks explicit V2.1.1 Consumer development lifecycle provisions (2020-06) Internet of including vulnerability regarding Things: management. conducting a Baseline Manufacturers should vulnerability Requirements continually monitor for assessment. identifying and rectifying There is no security vulnerabilities explicit

8

within products and services requirement to they sell, produce, have fix each known produced and services they exploitable operate during the defined vulnerability support period. before the release of the product

Overall The first two standards (ISO/IEC 18045:2022 and ITU-T X.1214) contain a step-bycoverage step methodology for vulnerability assessment; collectively they cover the preand and post-delivery phases of the product life cycle. They cover both known and possible unknown (zero-day) vulnerabilities with a number of different, complementary gaps techniques. The IEC 62443-4-1 standard prescribes several security tests on the product, although referring only IACS, and the ETSI EN 303 645 standard poses a requirement for IoT manufacturers not referring explicitly to the initial delivery and without further implementation detail. With the exception of the IEC 62443-4-1 standard, but which refers only to IACS, the main identified gap is that the mentioned standards cover only vulnerability detection and not the patching of the discovered vulnerabilities, so in general not covering the whole requirement: ISO/IEC 18045 (which is the standard used for the Common Evaluation Methodology (CEM) that is used in conjunction with the Common Criteria - ISO/IEC 15408 series) describes a vulnerability assessment methodology in validation phase and with only one technique, ITU-T X.1214 covers more techniques in validation and maintenance phases but without a specific methodology and focusing on ICT network elements, and ETSI EN 303 645 describes only the necessity to deliver products without vulnerabilities.

(a) be delivered with a secure by default configuration, including the possibility to reset the product to its original state;

Sample Sub-requirements:

— In case default configurations foresee an initial/default credential, the same should use a complex and randomly chosen password, different for each product — In case default configurations cover cybersecurity items, they should adopt a reasonable level of security for each item — The default configuration should be placed in a non-erasable memory — A function to reset the product configuration to the default one should be implemented

Keywords: default configuration, randomised password, unique password, non-erasable memory,

ROM, reset, security by default

9

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard It mainly Implementation ISO/IEC security, provides a set of provides general Validation 27002: cybersecurity and generic controls for guidelines 2022 privacy protection information security covering several — Information risk treatment. It different aspects, security controls includes so it does not implementation specifically target guidance for the this requirement. controls based on recognised best practices. Among the technological controls there is configuration management, which addresses security configuration of hardware, software, services and networks.

ETSI EN CYBER; Cyber This standard defines The provisions Design 303 645 Security for cybersecurity are expressed at Implementation V2.1.1 Consumer Internet provisions for high-level (2020-06) of Things: Baseline consumer IoT without details Requirements devices. Among for a reasonable those there are security level in recommendations on the default the use of default configuration passwords on the and target devices, secure specifically storage of sensitive consumer IoT parameters and the devices. management of the credentials (e.g., password generation, user authentication and change of default values)

ISO/IEC Information This standard defines The standard is Design 18031: technology — the conceptual dedicated to the Implementation 2011 Security techniques model of non- definition of — Random bit deterministic and models for generation deterministic random bit random bit generation, thus generators for not specifically

10

cryptographic targeting purposes. It specifies configuration their security management requirements and aspects. covers application of random bit strings for random PIN and password generation. It can be employed to address aspects of randomised passwords and keys for secure product configuration.

Overall Aspects related to random password and key generation in general are well coverage covered by ISO/IEC 18031:2011 for what concerns specific conceptual models. and Those related to product configuration/credentials management (ISO/IEC possible 27002:2022 and ETSI EN 303 645) are addressed at a high level, with references to gaps NIST publications for details. More detailed implementation aspects relying for example on the specific use of non-erasable memories for configuration management seem not to be covered.

3.1.4 (3b) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems;

Sample Sub-requirements:

— In accordance with the nature of the product and to the relevant risks identified in the risk analysis, an appropriate system to provide authentication and authorisation should be implemented. — The access to personal/protected data and to administration/configuration functions should be granted only to authenticated and authorised users — In accordance with the nature of the product and to the relevant risks identified in the risk analysis, physical unauthorized access should be forbidden

Keywords: authentication, authorisation, identity & access management, IAM, physical access

control, logical access control, anti-tampering

11

Standard Standard Rationale Gap Life-Cycle ID

ISO/IEC Information technology The General part Covers only Design 9798 — Security techniques of the ISO/IEC authentication. Implementation — Entity authentication 9798 standard

Parts 1 to

— specifies a model

6

for entity Part 1:2010 General authentication, Part 2:2019 together with Mechanisms using general authenticated requirements encryption and constraints

for the relevant Part 3:2019 mechanisms. It Mechanisms using covers a variety digital signature of authentication techniques protocols, Part 4:1999 including one-to- Mechanisms using a one and through cryptographic check a third-party function authentication. Part 5:2009 Details for Mechanisms using specific zero-knowledge mechanisms are provided in the techniques other Parts of Part 6:2010 this standard. Mechanisms using manual data transfer

ISO/IEC IT Security and Privacy This series of Covers only Design 24760 — A framework for standards identity Implementation identity management specifies a management

Parts 1 to

framework for systems; does Validation 3 Part 1:2019 issuing, not cover Terminology and administering, access concepts and managing management. Part 2:2015 Reference identity data and architecture and applies to any requirements information

system. Part 3:2016 Practice

Part 1 defines terms and core concepts of identity and identity management.

Part 2 provides guidelines and

12

requirements for the implementation of an identity management framework. Part 3 provides guidance for ensuring that an identity management system conforms to Parts 1 and 2.

ISO/IEC Information technology This standard Covers access Design 29146: — Security techniques defines a management 2016 — A framework for framework for only; does not access management access cover identity management, management building on top which is a preof an identity requisite for management this framework. system (not covered in this standard). It describes the process to access ICT resources in a secure and accountable way.

ITU-T Security guidelines for This standard It is of generic Design X.1253 identity management provides nature and (09/2011) systems guidelines for the does not apply secure and to specific privacy- identity preserving management deployment and systems; as operation of such, high-level identity descriptions of management the techniques systems. are provided.

ITU-T Information technology Provides a It is generic and Design X.812 – Open Systems general overview does not (11/1995) Interconnection – of access control, describe Security frameworks policies and specific access for open systems: mechanisms. It control Access control can be used by mechanisms or framework standards steps to be describing performed to

13

specific access provide access control control mechanisms and services. services.

ETSI EN CYBER; Cyber Security Provisions 5.1, The standard Design 303 645 for Consumer Internet 5.5: require emphasizes Implementation V2.1.1 of Things: Baseline authentication, authentication (2020-06) Requirements unique and passwords, and cryptography, cryptographic but lacks measures. specifics on access management systems.

EN IEC Security for industial This standard, This standard Design 62443-4- automation and control related to IACS applies only to Implementation 2:2019 systems – components, Industrial includes Automation Part 4-2: Technical requirements and Control security requirements that cover the System for IACS components various aspects of user authentication (all provisions included in Foundational Requirement 1 – Identification and authentication control) and authorisation (Component requirement 2-1: Authorisation enforcement)

Overall The standards above cover the following areas: authentication, identity & access coverage management, and access control. The aspects related with these areas are well and covered by the above standards. It should be noted that the above standards are possible mainly of generic nature and in most cases do not cover specific mechanisms and gaps services.

14

3.1.5 (3c) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms;

Sample Sub-requirements:

— Data stored in a product’s internal memory should be encrypted at rest using current nondeprecated technology — Transmission protocols used to send/receive data should support encrypted communications and enable them by default — The product should implement symmetric or asymmetric encryption schemes (including PKIs) to ensure that confidentiality of exchanged data is protected

Keywords: symmetric/asymmetric encryption, encryption at rest and in motion/transit, PKI,

certificates, sensitive assets confidentiality, data confidentiality

Standard Standard Rationale Gap Life-Cycle

ID

ITU-T Security This standard Does not cover Design X.805 architecture for describes a protection of (10/2003) systems providing generic data at rest; very end-to-end architecture for generic, covers communications end-to-end the basic communication principles that security that is should be independent of followed by the network security technology or mechanisms protocol stack without layer. describing specific mechanisms.

ISO/IEC Information This series of These standards Design 18033 security — standards do not describe Implementation Encryption describes key

Parts 1 to

algorithms — encryption management;

7

algorithms for only an overview Part 1:2021 General data is given in Part 1 Part 2:2006 confidentiality with relevant Asymmetric ciphers both for stored references. Some and transmitted algorithms are Part 3:2010 Block data. It covers deprecated ciphers symmetric and Part 4:2011 Stream asymmetric ciphers ciphers but also Part 5:2015 Identity- non-conventional based ciphers algorithms such as homomorphic and

15

Part 6:2019 identity-based Homomorphic ciphers. encryption Part 7:2022 Tweakable block ciphers

ITU-T Information This standard It is very generic, Design X.814 technology – Open defines the basic covers the basic (11/1995) Systems concepts related principles of Interconnection – to confidentiality, confidentiality Security discussing also without frameworks for types of describing open systems: confidentiality specific protocol Confidentiality services, exchanges framework mechanisms, threats and attacks.

ETSI EN CYBER; Cyber Provisions 5.5.1, The standard Design 303 645 Security for 5.5.6, 5.5.7 focus lacks specific Implementation V2.1.1 Consumer Internet on secure coverage for (2020-06) of Things: Baseline communication protecting all Requirements and confidentiality data types, in using particular at rest, cryptography. and does not Provisions 5.8.1, fully address 5.8.2 ensure particular cryptographic encryption protection of schemes. personal data. Provisions 5.4.1, 5.4.4 require secure storage and uniqueness of security parameters.

EN IEC Security for This standard, This standard Design 62443-4- industial related to IACS applies only to Implementation 2:2019 automation and components, Industrial control systems – includes a Automation and confidentiality Control System. Part 4-2: Technical requirement for Moreover, the security both data at rest confidentiality requirements for and in transit requirement is IACS components (Component quite generic and Requirement 4.1: does not provide Information technical details Confidentiality)

16

Overall The above standards cover the basic concepts and principles behind data coverage confidentiality, both at-rest and in-transit. They also cover symmetric and and asymmetric encryption algorithms, as well as homomorphic and identity-based possible ciphers. The aspects related with these areas are well covered by the above gaps standards. It should be noted here that the above standards are a mix of generic standards independent from network technology or network stack layer and more specific standards describing encryption algorithms.

3.1.6 (3d) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, as well as report on corruptions;

Sample Sub-requirements:

— Integrity of data, programs and configurations stored in the product’s internal memory should be ensured using current non-deprecated technology, e.g. hashing — Transmission protocols used to send/receive data should support ways to ensure it is possible to spot data alteration during the transmission (e.g. MACs) — The product should implement symmetric or asymmetric encryption schemes (including PKIs) to ensure that the integrity of exchanged data is protected — A product should perform self-test to verify integrity of relevant code/information (e.g. firmware)

Keywords: integrity, hashing, checksum, data corruption, PKI, certificates, self-test

Standard ID Standard Rationale Gap Life-Cycle

ISO/IEC 9796 Information Covers digital Does not cover Design technology — signatures where digital Parts 2 and Implementation Security techniques part or the entire signatures with

3

— Digital signature message can be appendix; also, schemes giving recovered from does not cover message recovery the signature. It techniques for describes key Part 2:2010 Integer deterministic and management factorization based randomized and random mechanisms mechanisms, number Part 3:2006 specifying also the generation. Discrete logarithm key production based mechanisms method.

ISO/IEC 9797 Information These standards Does not cover Design technology — cover several MAC key Parts 1 to 3 Implementation Security techniques algorithms based management of — Message on block ciphers, block cipher dedicated or mechanisms. universal hash

17

Authentication functions. Part 1 Codes (MACs) covers 6 MAC algorithms based Part 1:2011 on block ciphers, Mechanisms using generic enough to a block cipher be applied to any Part 2:2021 security Mechanisms using architecture, a dedicated hash- process or function application. Part 3:2011 Mechanisms using a universal hashfunction

ISO/IEC Information Covers digital Does not cover Design 14888 technology — signatures where digital Implementation Security techniques the entire signatures with

Parts 1 to 3

— Digital message is stored message signatures with and/or recovery; also, appendix transmitted does not cover together with the techniques for Part 1:2008 signature. It key and General describes several certificate Part 2:2008 Integer mechanisms, management, factorization based including identity- and random mechanisms based, and number certificate-based generation. Part 3:2018 schemes. Discrete logarithm based mechanisms

ITU-T X.815 Information This standard It is of generic Design (11/1995) technology – Open defines the basic nature; covers Systems concepts related the basic Interconnection – to integrity, also principles of Security discussing types of integrity frameworks for integrity services, without open systems: policies, describing Integrity framework mechanisms, specific threats and mechanisms attacks.

ETSI EN 303 CYBER; Cyber The standard While the Design 645 V2.1.1 Security for emphasizes standard Implementation (2020-06) Consumer Internet secure storage covers many of Things: Baseline (5.4), and software aspects of data Requirements integrity (5.7). integrity, it

18

These directly does not align with the explicitly detail requirement's information focus on ensuring integrity. integrity using non-deprecated technology like hashing and cryptographic schemes

EN IEC Security for This standard, This standard Design 62443-4- industrial related to IACS applies only to Implementation 2:2019 automation and components, Industrial control systems – includes specific Automation integrity and Control Part 4-2: Technical requirements that System. security cover software, Moreover, the requirements for updates, integrity IACS components configuration, requirements communications, although quite audit logs, etc. specific, do not seem to have a general applicability in all situation (e.g. there is not an integrity requirement prescribing all memory to have integrity protection feature, but this might be due to the specific nature of IACS)

Overall The above standards cover basic concepts and principles for providing integrity coverage services. They also describe specific mechanisms for integrity based on digital and possible signatures and MACs. The aspects related with these areas are well covered by gaps the above standards. It should be noted here that the above standards are a mix of generic (related to integrity concepts) and more specific standards (related to integrity mechanisms).

19

3.1.7 (3e) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended use of the product (‘minimisation of data’);

Sample Sub-requirements:

— In general, refer to GDPR best practices, such as: o it should not be asked to the user the provision of data that is not strictly necessary to the execution of the task or service requested o data no longer needed should be deleted without delay

Keywords: privacy, GDPR, data minimisation, personal data, data retention

Standard Standard title Rationale Gap Life-Cycle ID

ISO/IEC Security This standard is an This standard, Design 27701: techniques — extension to ISO being an extension Implementation 2019 Extension to 27001 and 27002 of the ISO/IEC ISO/IEC 27001 and regarding privacy 27001 and 27002 Validation ISO/IEC 27002 for information standards, refers Commissioning privacy management. It to organisations Surveillance information includes rather than management — requirements and products. Maintenance Requirements and controls for this Nevertheless, it End of Life guidelines specific topic and could be argued mapping with that an relevant standards organisation and legislation, like implementing the the GDPR. controls included in this standard will do the same for its products

ISO/IEC Information This standard No specific Design 29100: technology — provides a high- requirements or Implementation 2011 Security level framework for controls are techniques — the protection of PII present in this Validation Privacy framework within ICT systems. document Commissioning Although it is quite Surveillance high-level and does not include Maintenance concrete End of Life requirements and controls, it contains explanatory sections on key privacy concepts, including data minimisation

20

ETSI TS CYBER; This Technical The documents Design 103 485 Mechanisms for Specification does not list Implementation V1.1.1 privacy assurance document specific (2020-08) and verification describes requirements or Validation mechanism to controls Commissioning enable assurance Surveillance of privacy, using references to Maintenance Common Criteria End of Life documents and to the GDPR

ETSI EN CYBER; Cyber The standard While the standard Design 303 645 Security for addresses data outlines broad Implementation V2.1.1 Consumer protection and measures for data (2020-06) Internet of Things: minimization, with security and Baseline provisions ensuring processing, it lacks Requirements secure data specific guidance handling, for data transparent minimization processing, and practices such as adhering to the the deletion of principles of only unnecessary data processing and prevention of necessary data forced (e.g., Sections 5.8 registrations. It and 6). The would also benefit standard from better emphasizes secure reference to some and responsible explicit GDPRdata management, specific best aligning with GDPR practices to be principles, thereby more effective. addressing the requirement to a considerable extent.

Overall This privacy requirements is very well covered especially in the ISO/IEC 27701 coverage standard, that proposes a mapping between various standards and legislation, and including the GDPR. The concept of data minimisation is well covered.

possible gaps

21

3.1.8 (3f) protect the availability of essential functions, including the resilience against and mitigation of denial of service attacks;

Sample Sub-requirements:

— The product should be hardened against attacks, like for instance distributed denial of service attacks, by implementing, among other things, the following measures if appropriate: o reverse proxies network segmentation o load balancing o rate limiting o redundancy and high availability solutions o backup sites o disaster recovery plans o minimize offered services

Keywords: availability, resiliency, secure outages, backup, denial of service, DoS, DDoS, protocol-

based attacks, connection limit

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard provides a The guidance Implementation ISO/IEC security, set of generic controls for developing Validation 27002: cybersecurity and for information security availability of 2022 privacy protection risk treatment. It essential — Information includes implementation functions is security controls guidance for the provided at a controls based on high level recognised best (e.g., for DoS practices. Among the protection). organisational controls there is information transfer, which mentions denial of service protection for electronic messaging and availability of services and information

ISO/IEC Information This standard describes The focus is Design 22237- technology — the principles for specifically for Implementation 1:2021 Data centre availability, reliability data centre facilities and and resilience of data facilities and infrastructures — centres, seen as key infrastructure Part 1: General element for housing and s. Although concepts supporting IT data this would processing, storage and cover services transport. Availability is and also considered as a applications provisioned

22

dimension for data from a data centres classification. centre, it does not refer to the design of generic user products.

ITU-T Security This standard defines a Specific for Design X.805 architecture for network security end-to-end Implementation (10/2003) systems providing architecture for network end-to-end providing end-to-end security, it communications network security. The does not architecture is cover general applicable to different aspects of types of networks and systems or considers several products security dimensions design. (including availability) and security planes (management, control, end-user). The availability dimension explicitly mentions protection against active attacks such as Denial of Service (DoS).

ETSI EN CYBER; Cyber This standard gathers The provisions Design 303 645 Security for cybersecurity provisions are expressed Implementation V2.1.1 Consumer for consumer IoT at high-level (2020-06) Internet of devices. It contains and target Things: Baseline provisions on systems specifically Requirements resilience to outages, consumer IoT including mitigations devices. against Distributed Denial of Service (DDoS) attacks. More specifically about some provisions: 5.5 Communicate securely: Emphasizes best practice cryptography and secure authentication. 5.6 Minimize exposed attack surfaces: Focuses on disabling unused interfaces and secure development. 5.9 Make systems resilient to outages:

23

Addresses resilience in case of data networks and power outages.

EN IEC Security for This standard, related to This standard Design 62443-4- industial IACS components, applies only to Implementation 2:2019 automation and includes specific Industrial control systems – requirements focused Automation on maintaining a and Control Part 4-2: baseline of operational System. Technical security functionalities also in requirements for cases of denial of service IACS components attacks (see Component Requirement 7.1: Denial of service protection). Moreover, it presents a requirement that prescribes a resource usage limitation capability to prevent resource exhaustion (Component Requirement 7.2: Resource management).

Overall General availability aspects are covered by ISO/IEC 22237-1:2021 for what concerns coverage the design of data centre facilities and infrastructures, that could be applicable to and some digital products and services but do not cover all the landscape. Broader possible scope is provided by ISO/IEC 27002:2022 and ETSI EN 303 645 even if at a high level gaps and, for the latter, focusing on IoT consumer devices. ITU-T X.805 (10/2003) covers the requirement for end-to-end network security. EN IEC 62443-4-2 covers the requirement for IACS. A possible gap could be the more detailed guidance on implementation of availability principles for generic user products.

3.1.9 (3g) minimise their own negative impact on the availability of services provided by other devices or networks;

Sample Sub-requirements:

— The product should limit outgoing network connections to what is strictly needed — The product should implement measures such as timeouts and exception handling to avoid generating multiple requests to a busy/not responsive service

Keywords: network saturation, minimization, connection limits, timeouts, exception handling

24

Standard Standard title Rationale Gap Life-Cycle ID

ETSI EN CYBER; Cyber The standard includes While the standard Design 303 645 Security for requirements on encompasses Implementation V2.1.1 Consumer system resilience, security, data (2020-06) Internet of limiting unnecessary protection, and Things: exposure, and orderly resilience, it Baseline network connections, doesn't specifically Requirements which align with focus on minimizing negative minimizing impacts on other interference with services. other services as in the given Relevant Provisions: requirement. 5.6 Minimize exposed Provisions related attack surfaces to network saturation, 5.9 Make systems connection limits, resilient to outages and exception 5.13 Validate input handling are not data fully addressed in the standard, indicating potential gaps in coverage. Moreover, the provisions are expressed at highlevel and target specifically consumer IoT devices.

ITU-T Requirements In section 9.5 “Specific Although specific, Design Y.4810 for data requirements for data these Implementation (11/2021) security of transfer to and from requirements, heterogeneous heterogeneous IoT related only to IoT Internet of devices” the following devices, limit their things devices two requirements coverage to data could be seen as transfer and radio partially covering this interference. In topic: the document there are not it is required to limit other elements the function of data that could be transfer to and from an mapped to this IoT device – the element process of a specific type of data transfer is required to be initiated

25

only with explicit permission of end users it is required to have the anti-interference ability between the IoT device and network equipment.

Overall Requirement 3(g) of the CRA proposal is covered only in documents related to IoT coverage devices, although they can be considered quite generic. However, even in these and documents the coverage is limited to a minimal number of high-level provisions.

possible gaps

3.1.10 (3h) be designed, developed and produced to limit attack surfaces, including external interfaces;

Sample Sub-requirements:

— The product’s hardware design should limit all the connections and interfaces that are not strictly required for performing the various tasks the product is expected to do — If required by a risk assessment, a physical product should include tamper-resistant features — The product/service should have all not essential network ports closed as a default configuration — Software present in digital product should be designed to avoid having unnecessary entry points (e.g. API) open and available for external unauthorised callers

Keywords: hardware hardening, tamper-resistance, system hardening, software hardening,

interfaces, security by design

Standard ID Standard title Rationale Gap Life-Cycle

ISO/IEC TS Information This technical This document Design 19249:2017 technology — specification document is rather Security describes some descriptive and techniques — security design does not Catalogue of principles that would include a architectural help developing a concrete and design secure product. In the “requirements” principles for list it is included the list secure attack surface products, minimisation principle, systems and at the core of this applications requirement. The description is followed by a concrete example

26

of the application of the principle.

ISO/IEC Information This standard lists a This document Design 15408- security, series of security does not list Implementation 2:2022 cybersecurity functional concrete and privacy components, that, in “requirements” Validation protection — the Common Criteria Evaluation jargon are defined as criteria for IT the basis for security security — Part functional 2: Security requirements. functional In particular, the components “Limited capabilities and availability” section defines requirements to limit the capabilities (i.e. a function should provide only the capabilities necessary for its genuine purpose) and availability (i.e. the use of a specific function should be restricted when not needed/required) of functions. This is useful to enforce design principles such as least privilege and attack surface minimization

EN IEC Security for Although this standard In this standard Design 62443-4- industrial is specific for Industrial it is not present Implementation 2:2019 automation Automation Control a requirement and control Systems, it lists several dedicated to an Validation systems - Part requirements related attack surface 4-2: Technical to physical hardening, minimisation security like “Physical tamper principle. requirements resistance and Moreover, this for IACS detection” and “use of document components physical diagnostic and targets test interfaces” exclusively Industrial Automation Control Systems

27

ETSI EN 303 CYBER; Cyber The requirement This standard is Design 645 V2.1.1 Security for closely aligns with specific to IoT Implementation (2020-06) Consumer Section 5.6 of this consumer Internet of standard, which devices and Things: emphasizes minimizing does not Baseline exposed attack automatically Requirements surfaces through apply to other disabling unused categories of interfaces, not products, for unnecessarily exposing which other physical interfaces, and and maybe following secure more specific development provisions may processes. be needed.

Overall This requirement is well covered from a theoretical point of view in the analysed coverage documents, that well describe what are the security design principles that would and allow to minimise the attack surface of a product with digital elements. possible Nevertheless, we found a lack of concrete requirements and practical controls gaps that, implemented, would indeed ensure an attack surface minimisation. Standard EN IEC 62443-4-2:2019 is a partial exception to this as it included concrete requirements although limited to industrial automation and control systems.

3.1.11 (3i) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;

Sample Sub-requirements:

— The product should be designed in a way that gaining unauthorised access to a function or data does not automatically lead to a complete access to all product’s functions and data (defence in depth principles) — Sensitive data stored in a product’s internal memory should be encrypted at rest — The product should not store data that is not relevant or necessary to perform its tasks (data minimisation)

Keywords: defence in depth, encryption-at-rest, data minimisation, security by design, hardening,

risk assessment, secure architecture, sandboxing, secure environment

Standard Standard title Rationale Gap Life-Cycle ID

ISO/IEC Information Provides a It does not cover Design 27001: security, systematic specific technical 2022 cybersecurity approach for measures for and privacy managing defence in depth, protection — information encryption at rest, Information security risks. or sandboxing.

28

security management systems — Requirements

ISO/IEC Information Offers best High-level Design 27002: security, practices for guidelines, might Implementation 2022 cybersecurity selecting and lack specific details and privacy implementing on secure software protection — security controls. design and Information hardening. security controls

ISO/IEC Information Focuses on secure The standard Design 27034- technology — development promotes security Implementation 1:2011 Security practices for in all software techniques — software development Application applications. phases, implicitly security — Part supporting defence- 1: Overview and in-depth, but concepts doesn't detail hardening and sandboxing. While not specifying controls like encryption at rest, it encourages risk assessments and appropriate control implementation. Data minimisation isn't explicitly addressed, but could be implemented if identified as a risk.

EN Information Provides security This standard Design ISO/IEC security, evaluation criteria primarily focused Implementation 15408- cybersecurity for IT products and on evaluation 3:2022 and privacy systems. criteria, not specific protection — mitigation Evaluation mechanisms or criteria for IT techniques which security — Part could be enforced 3: Security through security assurance functional components requirements defined in ISO/IEC 15408-2:2022.

29

However, it could be used to provide assurance in the product thus reducing the impact of an incident using appropriate (= assessed by the lab) exploitation mitigation mechanisms and techniques.

EN Information Specifies the This standard Validation ISO/IEC security, methodology for focuses on 18045: cybersecurity evaluating the methodology for IT 2022 and privacy security properties security evaluation, protection — of IT products and not specific Evaluation systems. mitigation criteria for IT mechanisms. But it security — supports the Methodology ISO/IEC 15408for IT security 3:2022 coverage evaluation statement above while providing evaluation methods considering for instance attack potential calculation to assess the mitigation mechanisms and techniques for robustness.

ETSI EN CYBER; Cyber The requirement Data Minimization: Design 303 645 Security for aligns with the Lacking explicit Implementation V2.1.1 Consumer standard principles coverage in (2020-06) Internet of emphasizing secure provisions, Things: Baseline design, encryption, constituting a gap. Requirements minimizing data, Secure architecture, and resilience. sandboxing, secure More specifically: environment: not Defence in Depth explicitly defined, Principles: leading to potential provisions 5.6, 5.9, gaps. and 5.6-9 cover this principle but may need more specific layering details.

30

Encryption-at-Rest: provisions 5.4-1, 5.4-2, 5.3-7, and 5.5-1 partly address this requirement. Other Relevant Provisions: Ensuring software integrity (5.7) Encrypted communication (5.5) Hardening by disabling unused interfaces and minimizing code (5.6-1, 5.6-6) Secure management processes and best practice cryptography (5.5-8, 5.3-7)

IEC 62443- Security for Provides guidelines Relevant to Design 3-2:2020 industrial for security risk Industrial products. automation and assessment and While it doesn't control systems secure system explicitly mention - Part 3-2: design, addressing encryption at rest or Security risk defence in depth data minimisation, it assessment for through network covers security by system design segmentation design, risk strategies. It implies assessment, and hardening through secure architecture. identification of However, specific vulnerabilities and sandboxing or countermeasures. secure environment requirements aren't detailed.

Overall The standards provide a solid foundation in secure system design, secure product coverage development, risk assessment, security evaluation, and security controls. and However, some aspects of defence in depth, sandboxing, and certain mitigation possible techniques might not be explicitly covered by the selected standards.

gaps

31

3.1.12 (3j) provide security related information by recording and/or monitoring relevant internal activity, including the access to or modification of data, services or functions;

Sample Sub-requirements:

— A product should contain a log of cybersecurity related events — Access or modification of data, services or functions should be logged — Such log should be accessible to the privileged user — Logs should be protected from unauthorised modification or corruption

Keywords: logging, event monitoring, non-repudiation, intrusion detection, tamper-detection

Standard Standard title Rationale Gap Life-Cycle

ID

EN ISO/IEC Information This standard provides a Guidance in Implementation 27002: security, set of generic controls this standard is Validation 2022 cybersecurity for information security generally and privacy risk treatment. It provided at a protection — includes implementation high level, even Information guidance for the controls though for this security based on recognised requirement controls best practices. Among few examples those there is logging facilitate the and monitoring identification of activities, which use cases and embraces logging of main actions to events and protection of put in place. log information. It includes example of events to log and of unauthorised changes.

ISO/IEC Information Standard specific for More general Design 13888- security — non-repudiation aspects not Implementation 1:2020 Non- mechanisms using related to nonrepudiation — cryptographic repudiation are Validation Part 1: General techniques, it targets not in the generation of evidence scope of this concerning relevant standard. events. It can be applied to recording and monitoring of activities as specified in the requirement with particular focus on nonrepudiation.

32

ETSI EN CYBER; Cyber Relevant Provisions: The Design 303 645 Security for requirement 5.9-2, 5.9-3 (Resilience): Implementation V2.1.1 Consumer related to focus on resilience and (2020-06) Internet of recording Validation restoration after Things: and/or outages. They imply the Surveillance Baseline monitoring need to monitor system Maintenance Requirements relevant behaviour, possibly internal activity, including unauthorized including the access attempts or access to or modifications, although modification of this is not explicit. data, services, 5.10-1 (Examine system or functions, is telemetry data): calls for not explicitly examining telemetry addressed. data, including the While there are monitoring of system some aspects usage and behaviour. It related to aligns with the focus on telemetry data recording and and input monitoring internal validation, activities, such as specific unauthorized access or guidelines or modifications. mandates for

logging 5.11-1 to 5.11-4 (Easy cybersecuritydeletion of user data): related events, allow users to control and ensuring and erase their data. that logs are They indirectly imply accessible to tracking of data access privileged users and modification while being 5.13-1 (Validate input protected from data): requires data unauthorized input validation to modification or ensure its integrity and corruption, are authenticity. It implies a not expressly monitoring mechanism detailed in the and may indirectly relate standard. to logging and event monitoring

IEC 62443- Security for This standard is related Relevant only Design 4-2:2019 industrial to IACS. Within the listed to IACS. Implementation automation requirements there are and control also provisions about systems - Part event auditing 4-2: Technical (Component security Requirement 2.8: requirements Auditable events), timestamping of audit

33

for IACS records (Component components Requirement 2.11: Timestamps) and nonrepudiation (Component Requirement 2.12: Nonrepudiation)

Overall Monitoring aspects with specific focus on non-repudiation are covered in ISO/IEC coverage 13888-1:2020. ISO/IEC 27002:2022 gives a more general overview and high-level and provisions. ETSI EN 303 645 V2.1.1 touches upon telemetry data, data validation possible and integrity. EN 62443-4-2 covers the requirement for IACS.

gaps

3.1.13 (3k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users.

Sample Sub-requirements:

— The company distributing a product or service should provide timely security updates for the software components of the product/service for a reasonable amount of time. — A function to automatically check the presence of updates and install them, or notify the user of their presence, should be implemented, and where applicable this should be the default initial configuration. — A product should provide a secure mechanism to install/implement updates — The company distributing a product should notify the user on the availability of updates

Keywords: Indicator of Compromise, patching, software updates, automatic updates, user

notification, secure update functionality

Standard Standard title Rationale Gap Life-Cycle ID

EN Information security, Covers general Lacks specific Design ISO/IEC cybersecurity and principles for guidance on Validation 27002: privacy protection — information automatic 2022 Information security security updates and user controls management, notifications including patch management

ISO/IEC Information technology Focuses on Lacks guidance Design 30111: — Security techniques vulnerability on secure 2019 — Vulnerability handling handling processes mechanisms for processes but not specifically installing/implem on the mechanisms enting updates for delivering and installing updates

34

ETSI EN CYBER; Cyber Security Addresses security Lacks detailed Design 303 645 for Consumer Internet updates, automatic guidance on V2.1.1 of Things: Baseline updates, and user secure (2020-06) Requirements notifications for mechanisms for consumer IoT installing/implem devices enting updates

IEC 62443- Industrial Addresses patch Limited to Design 2-1:2010 communication management and industrial networks - Network and updates in the automation and system security - Part 2- context of control system 1: Establishing an industrial environments. It industrial automation automation and does not cover and control system control systems automatic security program updates and user notifications in detail

IEC 62443- Security for industrial Provides guidance Limited to Design 4-2:2019 automation and control on patch industrial systems - Part 4-2: management and automation and Technical security security updates control system requirements for IACS for IACS components – It components components does not cover user notifications

Overall The identified standards focus on different aspects of vulnerability management, coverage patching, and updates. However, some standards mention the need for secure and updates, but they do not provide detailed guidance on the secure mechanisms for possible installing/implementing updates. Also, they do not explicitly cover the requirement of gaps notifying users about the availability of updates.

35

3.2 Vulnerability handling requirements 3.2.1 Manufacturers of the products with digital elements shall: (1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product;

Sample Sub-requirements:

— A monitoring of the cybersecurity status of the overall supply chain for the acquisition of the necessary components incorporated in the product should be put in place. — All libraries and external components used in the software part of a product, including their version number should be listed in a Software Bill of Material (SBOM) available to the user — Such Software bill of materials (SBOM) should be compliant to the relevant standards (e.g., ISO/IEC 5921:2021 also known as SPDX [2] or CycloneDX [4] standard)

Keywords: software bill of materials, SPDX, CycloneDX, supply chain security, machine-readable,

versioning, software dependencies, composability

Standard Standard title Rationale Gap Life-Cycle ID

ISO/IEC Cybersecurity This standard covers While it is Design 27036 — Supplier information security for relevant to the Surveillance relationships — supplier relationships. It overall supply

Parts 1 to

Part 1:2021 provides guidance on chain, it doesn't Maintenance

3

Overview and managing information specifically concepts security risks associated address the with suppliers and third- creation, Cybersecurity party developers. This can management, or — Supplier be relevant to SBOM in the exchange of relationships — context of the software Software Bill of Part 2:2022 supply chain. Materials Requirements (SBOM). Cybersecurity — Supplier relationships — Part 3: Guidelines for hardware, software, and services supply chain security

Overall To address the gaps in ISO/IEC 27036 related to Software Bill of Materials (SBOM), coverage it's recommended to consider the following standards and initiatives:

and

— SPDX: A Linux Foundation standard for sharing software components, licenses,

possible

copyrights, and security data, providing a consistent SBOM format [2].

gaps

36

— NTIA's Software Component Transparency Initiative: A U.S. initiative working on standardizing SBOM formats and best practices for software component transparency [3]. — CycloneDX: An SBOM specification designed for application security and supply chain component analysis, offering a lightweight format for describing software components and metadata [4]. — ECSO Supply Chain management and Product Certification Composition [5] — IIoTSBOM is an initiative from LSEC, Flanders Make and KU Leuven COSIC from Belgium to improve cybersecurity for devices. Inspired and with the support of the US CISA (Cyber Security and Infrastructure Security Agency) [6] Combining these standards and initiatives with ISO/IEC 27036 can help create a comprehensive approach to managing SBOMs, addressing information security risks in supplier relationships, and improving software supply chain transparency.

3.2.2 (2) in relation to the risks posed to the products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates;

Sample Sub-requirements:

— In case vulnerabilities are found they should be classified in accordance with standard severity metrics (e.g. CVSS) — vulnerabilities that can be directly fixed by the company should be fixed without delay, in accordance to their severity and the posed risks — In case a vulnerability is found in a software component of a product (including libraries and third party components), an update should be prepared and distributed as soon as possible — The company developing a product or service should be subscribed to updates coming from CERTs and cybersecurity organisations and analyse them in order to spot vulnerabilities in their products — The company developing a product or service should remain updated on the release of new versions of the libraries or third party software components included in their products/services and update the relative software whenever such new version includes a security update

Keywords: security updates, CVSS, updates release, vulnerability management, secure policy

Standard Standard title Rationale Gap Life-Cycle ID

ISO/IEC Information This international This standard Surveillance 27001: security, standard provides a provides a high-level Maintenance 2022 cybersecurity and framework for framework for privacy protection establishing, information security — Information implementing, management. It security maintaining, and doesn't explicitly management continually improving cover vulnerability an information classification, patch

37

systems — security management, or Requirements management system handling security (ISMS). It outlines the updates for libraries requirements for and third-party managing risks components. related to information security, including addressing and remediating vulnerabilities in digital products.

ISO/IEC Information This standard While it offers Surveillance 27002: security, provides best guidelines for Maintenance 2022 cybersecurity and practices and information security privacy protection guidelines for controls, it is not — Information implementing sufficient in providing security controls information security detailed guidance on controls in vulnerability organizations. It classification, specific covers various patch management aspects of procedures, or vulnerability addressing management, vulnerabilities in including risk third-party assessment, components. vulnerability classification, and remediation.

EN Information This standard This standard focuses Surveillance ISO/IEC technology — specifies the process on the process for Maintenance 30111: Security for vulnerability vulnerability handling 2020 techniques — handling in software in software products Vulnerability products. It provides but does not handling guidance on how specifically address processes organizations can subscribing to identify, analyse, and updates from CERTs remediate and cybersecurity vulnerabilities in their organizations or software products, maintaining updates including distributing for third-party security updates. components and libraries.

EN Information This standard defines This standard focuses Surveillance ISO/IEC technology — the process for on vulnerability Maintenance 29147: Security vulnerability disclosure and does 2020 techniques — disclosure, focusing not cover aspects like on how organizations vulnerability can receive and classification,

38

Vulnerability process vulnerability remediation, and disclosure reports from external patch management in sources, such as a comprehensive CERTs and manner. cybersecurity organizations.

EN IEC Security for This standard is This standard is for Surveillance 62443-4-1 industrial related to IACS. It IACS only. Moreover, Maintenance 2018 automation and contains although it requires control systems – requirements security patches, it covering security does not cover Part 4-1: Secure updates and in aspects like product particular timely vulnerability development delivery of security classification, lifecycle patches (SUM-1 remediation and requirements “Security update patch management in qualification” and a comprehensive SUM-5 “Timely manner. delivery of security patches”)

Overall While each standard provides valuable information and guidance, there is no single coverage standard that comprehensively addresses all aspects of vulnerability management, and including classification, remediation, patch management, handling updates from possible CERTs and cybersecurity organizations, and maintaining updates for third-party gaps components and libraries. To cover this gap, these standards could be combined to address the specific security needs aligned with sectoral requirements, and the regulatory landscape. By leveraging the strengths of each standard, a more comprehensive vulnerability management process addressing and remediating vulnerabilities in products with digital elements could be needed to fully cover this requirement.

Sample Sub-requirements:

— Periodic vulnerability assessment should be executed, especially towards those components that present the highest risk — When developing or maintaining software components, automatic tests should be executed whenever a new commit/build/version is prepared, if possible using Continuous Integration/Continuous Deployment (CI/CD) techniques — A risk assessment should be re-evaluated whenever there is a significant change in one of the dimensions analysed (new threats, new vulnerabilities, etc.) or a new product release.

Keywords: vulnerability assessment, continuous integration/continuous deployment, risk

assessment, security testing procedures, testing

39

Standard Standard title Rationale Gap Life-Cycle ID

ISO/IEC Information This international This standard Surveillance 27001: security, standard provides a provides a high- Maintenance 2022 cybersecurity and framework for level framework privacy protection establishing, for information — Information implementing, security security maintaining, and management. It management continually improving does not explicitly systems — an information security cover detailed Requirements management system security testing (ISMS). It outlines the procedures, requirements for continuous managing risks related integration/contin to information security, uous deployment including performing (CI/CD), or specific regular security tests testing and reviews. methodologies.

ISO/IEC Information This standard provides While it offers Surveillance 27002: security, best practices and guidelines for Maintenance 2022 cybersecurity and guidelines for information privacy protection implementing security controls, it — Information information security is not sufficient in security controls controls in providing detailed organizations. It covers guidance on various aspects of specific security security testing and testing vulnerability procedures, CI/CD management, including techniques, or the risk assessment and frequency and periodic reviews. scope of testing.

ISO/IEC TS Information This standard focuses This standard Surveillance 27034-5- technology — on application security focuses on Maintenance 1:2018 Application and provides application security — Part 5- guidelines for security but might 1: Protocols and embedding security not cover all application into the software aspects of security security controls development lifecycle, testing, especially data structure, including regular for non-software XML schemas security testing and products, reviews of applications. hardware components, or infrastructure elements.

40

ISO/IEC Information This standard provides This standard Surveillance 27005: security, guidelines for provides Maintenance 2022 cybersecurity and information security guidelines for privacy protection risk management, information — Guidance on which includes risk security risk managing assessment, risk management, but information treatment, and regular it does not cover security risks monitoring and review specific security of risks associated with testing digital products. methodologies or CI/CD techniques.

Overall While each standard provides valuable information and guidance, there is no single coverage standard that comprehensively addresses all aspects of security “effective” testing and and reviews for products with digital elements, including specific testing possible methodologies, CI/CD techniques, and the frequency and scope of testing.

gaps

To cover this gap, it could be considered the implementation of a combination of these standards and guidelines, tailoring the approach to the specific needs, industry, and regulatory landscape. By leveraging the strengths of each standard, it may be developed a more comprehensive security testing process during the development phase (e.g. DevSecOps) that addresses the requirement of applying effective and regular tests and reviews of the security of products with digital elements.

3.2.4 (4) once a security update has been made available, publically disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and information helping users to remediate the vulnerabilities;

Sample Sub-requirements:

— New CVE indicators should be publicly released and disseminated as soon as the relative security update has been released or implemented

Keywords: Common Vulnerabilities and Exposures (CVE), vulnerability disclosure, vulnerability

analysis

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard provides This standard Surveillance ISO/IEC technology — guidelines for provides Maintenance 29147: Security vulnerability disclosure, guidelines for 2020 techniques — including vulnerability Vulnerability recommendations on disclosure but disclosure how to disclose does not offer

41

vulnerability specific guidance information, such as the on the timeline nature of the for public vulnerabilities, affected disclosure or the products, impacts, exact format for severity, and sharing remediation vulnerability information. information.

EN Information This standard focuses While it focuses Surveillance ISO/IEC technology — on the process of on the process of Maintenance 30111: Security vulnerability handling in vulnerability 2020 techniques — software products, handling in Vulnerability including the steps software handling processes necessary to investigate, products, it does resolve, and publicly not provide disclose vulnerability detailed guidance information. on the public disclosure of vulnerability information for non-software products or hardware components.

ETSI EN CYBER; Cyber This European standard Even if the Surveillance 303 645 Security for is dedicated to standard remains Maintenance V2.1.1 Consumer Internet consumer internet of quite generic it is (2020-06) of Things: Baseline things. Chapter 5.2 is dedicated to Requirements dedicated to a means to internet of things manage reports of (IoT). It provides vulnerabilities. It refers overview of to EN ISO/IEC 29147 vulnerability document. disclosure policy content, timeline is a general one and not more precise than EN ISO/IEC 29147.

EN IEC Security for This standard is related This standard is Surveillance 62443-4-1 industrial to IACS. Requirement for IACS only. Maintenance 2018 automation and DM-5 “Disclosing control systems – security-related issues” prescribes the Part 4-1: Secure disclosure of product information related to development the fixed vulnerability in lifecycle a timely matter. requirements

42

Overall While these standards and initiatives contribute to the process of vulnerability coverage disclosure, they do not comprehensively address all aspects of public disclosure, and such as specific disclosure timelines or the exact format for sharing vulnerability possible information across different industries or product types.

gaps

To cover this gap, it could be considered the implementation of a combination of these standards and initiatives, tailoring the approach to the specific needs, industry, and regulatory landscape. Additionally, it may be possible to rely on vulnerability disclosure policies and procedures that align with industry best practices (including for instance: CVE [7], NIST National Vulnerability Database (NVD) [8], FIRST Vulnerability Reporting and Data eXchange (VRDX) SIG [9]). As part of a holistic approach, engaging with and incorporating feedback from various stakeholders, such as customers, researchers, and security experts, should be an ongoing, integral part of the vulnerability management process. By leveraging the strengths of each standard and initiative, it may be possible to create a comprehensive and effective vulnerability disclosure process that meets the requirement and its sub-requirements.

Sample Sub-requirements:

— The company should adopt and enforce the CVD policy

Keywords: CVD policy

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard provides This standard Design ISO/IEC technology — guidelines for offers guidelines Surveillance 29147: Security vulnerability disclosure, for vulnerability 2020 techniques — which includes disclosure but Maintenance Vulnerability recommendations for does not provide disclosure organizations to develop detailed guidance and implement a CVD on the policy. It offers guidance implementation of on the disclosure a CVD policy, such process, roles and as specific responsibilities, and how processes or to communicate requirements for vulnerability different information. industries.

EN Information This standard focuses on This standard is Design ISO/IEC technology — the process of dedicated to Surveillance 30111: Security vulnerability handling in vulnerability 2020 techniques — software products. It handling Maintenance Vulnerability complements ISO/IEC processes, 29147 by providing including

43

handling guidance on coordinated processes investigating, resolving, vulnerability and disclosing disclosure (CVD). vulnerabilities in a However, it coordinated manner. doesn't specify the enforcement of a particular national or EU CVD policy.

ETSI EN CYBER; Cyber This European standard Even if the Surveillance 303 645 Security for is dedicated to standard remains Maintenance V2.1.1 Consumer consumer internet of quite generic it is (2020-06) Internet of Things: things. Chapter 5.2 is dedicated to Baseline dedicated to a means to internet of things Requirements manage reports of (IoT). It provides vulnerabilities. It refers some details to EN ISO/IEC 29147 related to document vulnerability disclosure, and highlights the successful use of CVD in some software industries but without details on how to apply it in the IoT domain. There is also a reference to the Common Vulnerability Reporting Framework (CVRF) but without details.

Overall While the mentioned standards and initiatives contribute to the development and coverage implementation of a CVD policy, they do not comprehensively address all aspects of and enforcing such a policy or provide specific guidance tailored to different industries possible and product types.

gaps

To cover this gap, it could be considered the implementation of a combination of these standards, initiatives, and national / EU CVD policies. Additionally, it may be possible to rely on CVD policies and procedures that align with industry best practices (e.g. NIST SP 800-61 Revision 2 [10], FIRST VRDX SIG [9]). By leveraging the strengths of each standard and initiative, it may be possible to create a comprehensive and effective CVD policy that meets the requirement.

44

3.2.6 (6) take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements;

Sample Sub-requirements:

— The company distributing a product/service should have a contact point specifically advertised to collect information related to vulnerabilities found in their products/services. If the company has one, this contact point should be the company’s PSIRT — The company distributing a product/service should inform any relevant authority (e.g. national CERT/CSIRT) about how they can be reached in a timely manner for reasons related to the handling of vulnerabilities

Keywords: PSIRT, discovered vulnerabilities

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard provides This standard Design ISO/IEC technology — guidelines for provides guidelines 29147: Security vulnerability disclosure, for vulnerability 2020 techniques — including disclosure but does Vulnerability recommendations on not specifically disclosure how organizations can address the sharing establish and maintain of information communication channels about potential for reporting vulnerabilities in vulnerabilities. It covers third-party the roles and components. responsibilities of organizations and the process for communicating vulnerability information.

EN Information This standard focuses on Focused on Design ISO/IEC technology — the process of vulnerability 30111: Security vulnerability handling in handling in software 2020 techniques — software products, which products, it does not Vulnerability can be extended to comprehensively handling cover digital elements cover the aspects of processes and third-party sharing information components. It about potential complements ISO/IEC vulnerabilities in 29147 by providing third-party guidance on components and investigating, resolving, other digital elements.

45

and disclosing vulnerabilities.

Overall The mentioned standards and initiatives contribute to various aspects of the coverage requirement but do not comprehensively address sharing information about and potential vulnerabilities in third-party components and other digital elements.

possible

To cover this gap, it could be considered the implementation of a combination of

gaps

these standards, initiatives, and collaborate with national CERTs/CSIRTs and ENISA. It may be possible to also follow the CSIRTs Network forum and [11] latest ENISA activities on that topic under the EU Cybersecurity Act umbrella. The CSIRTs Network is composed of CSIRTs appointed by EU Member States and CERT- EU ('CSIRTs Network members'). It is worth noting that ENISA actively supports cooperation between CSIRTs, provides the secretariat and supports incident coordination upon request. Additionally, it may be possible to rely on policies and procedures that align with industry best practices (e.g., NIST SP 800-61 Revision 2 [10], FIRST PSIRT Services Framework [12]). By leveraging the strengths of each standard and initiative, it may be possible to create a comprehensive and effective process for sharing information about potential vulnerabilities and handling discovered vulnerabilities in their products with digital elements and third-party component.

3.2.7 (7) provide for mechanisms to securely distribute updates for products with digital elements to ensure that exploitable vulnerabilities are fixed or mitigated in a timely manner;

Sample Sub-requirements:

— Security updates should be digitally signed using a Code Signing Certificate to ensure the identity of the issuer — Hashes of the updates should be made publicly available with instructions on how to verify them

Keywords: code signing certificate, hashing, secure software update distribution, digital

signatures, official distribution channel, hash publication

Standard Standard title Rationale Gap Life- ID Cycle

ISO/IEC Information This standard provides Although it provides Design 27002: security, guidelines for guidelines for secure 2022 cybersecurity and information security software distribution, it privacy protection controls, including does not explicitly — Information secure software address the security controls distribution and update requirement of management. It covers publishing hashes of aspects such as updates and providing securing development environments,

46

cryptographic controls, instructions for and securing verification. distribution channels.

IEC 62443- Security for This standard focuses While IEC 62443-4-1 Design 4-1:2018 industrial on defining process addresses security automation and requirements for the aspects throughout the control systems - secure development of product development Part 4-1: Secure products used in lifecycle, including product industrial automation aspects related to development and control systems. It secure software lifecycle covers security updates and patch requirements requirements management, there are throughout the product potential gaps when it development lifecycle, comes to covering the including design, analysed requirement implementation, of securely distributing testing, and updates for products maintenance. While the with digital elements. standard is primarily Industry specificity: IEC targeted at the 62443-4-1 is tailored to development of secure Industrial Automation products, it also and Control Systems addresses aspects (IACS). Although the related to secure standard's principles software updates and can be applied to other patch management, industries, it does not which are important for fully cover the unique securely distributing needs and challenges of updates. other sectors. Explicit mention of hashes and verification: The standard does not explicitly address the publication of update hashes and the provision of instructions for verifying them. Organizations may need to develop additional guidelines or policies to ensure that hashes are published and that users receive clear instructions for verifying the authenticity and

47

integrity of software updates. Code signing certificate: While the standard covers secure software development practices, it does not explicitly mention the requirement of using code signing certificates to sign security updates, which ensures the identity of the issuer and the integrity of the update.

Overall The mentioned standards contribute to various aspects of the requirement but coverage does not comprehensively address the publication of update hashes and the and provision of instructions for their verification.

possible

To cover this gap, it could be considered the implementation of a combination of

gaps

these standards, tailored to the specific needs and industry best practices (e.g., NIST SP 800-53 [13], NIST SP 800-63B [14], OWASP SSDLC [15]). It may be possible to take a closer look into the Patch Management mechanism suggest in the EUCC [16]. The latter provides a framework for securely distributing updates for products with digital elements, ensuring that exploitable vulnerabilities are fixed or mitigated in a timely manner. By leveraging the strengths of each standard and considering input from various sources, it may be possible to create a comprehensive and effective process for securely distributing updates and mitigating exploitable vulnerabilities in a timely manner.

3.2.8 (8) ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

Sample Sub-requirements:

— Users should be made aware of the existence of security updates either via automatic distribution, popup, newsletter, etc. — This notice should contain information about the fixed issues and instructions on how to apply the update — Security updates should be released free of charge

Keywords: Security update notice

48

Standard Standard title Rationale Gap Life-Cycle ID

EN Information This standard provides While the standard Surveillance ISO/IEC technology — guidelines for the covers Maintenance 30111: Security design and vulnerability 2020 techniques — implementation of handling Vulnerability vulnerability handling processes, it does handling processes processes, including not explicitly the discovery, address the reporting, and requirement of remediation of providing security vulnerabilities. It can updates free of help organizations charge or specific develop processes to methods for ensure timely notifying users. dissemination of security patches, updates, and advisories

ISO/IEC Information This standard provides This standard Surveillance 27002: security, best practice provides best Maintenance 2022 cybersecurity and recommendations on practice privacy protection information security recommendations — Information management for but does not security controls organizations. Section provide explicit 12.6, "Technical guidance on Vulnerability providing updates Management," covers free of charge or aspects related to specific vulnerability notification management, methods for users. including the timely application of security patches and updates.

EN IEC Security for This standard is related This standard is Surveillance 62443-4-1 industrial to IACS. Requirements for IACS only. Maintenance 2018 automation and DM-5: “Disclosing Moreover, it does control systems – security-related issues” not make explicit and SUM-5 “Timely that the security Part 4-1: Secure delivery of security update should be product patches” cover the free of charge development requirement with the lifecycle notable exception of requirements the gratuitousness if the security update

49

Overall The existing standards and guidelines generally provide guidance on vulnerability coverage management, patch management, and the dissemination of security updates. and However, they do not explicitly address certain aspects of the requirement, such possible as providing updates free of charge or specifying methods for user notification.

gaps

To cover the overall gap, it could be possible to define policies that mandate providing updates free of charge and establishing specific methods for notifying users about available security updates.

50

4 Summary of the identified standards and overall remarks

Here the overall list of identified standards is summarised with the respective mapping, grouping them according to the two groups of CRA essential requirements.

Security requirements relating to the properties of products with digital elements

Standard 1 2 3 3 3 3 3 3 3 3 3 3 3 a b c d e f g h i j k

EN ISO/IEC 27002:2022 x x x x x x EN ISO/IEC 27005:2022 x EN IEC 62443-3-2:2020 x x EN IEC 62443-4-1:2018 x x ISO/IEC 18045:2022 x x ITU-T X.1214 (03/2018) x ETSI EN 303 645 V2.1.1 (2020-06) x x x x x x x x x x x x x ISO/IEC 18031:2011 x ISO/IEC 9798, Parts 1 to 6 x ISO/IEC 24760, Parts 1 to 3 x ISO/IEC 29146:2016 x ITU-T X.1253 (09/2011) x ITU-T X.812 (11/1995) x EN IEC 62443-4-2:2019 x x x x x x x ITU-T X.805 (10/2003) x x ISO/IEC 18033, Parts 1 to 7 x ITU-T X.814 (11/1995) x ISO/IEC 9796, Parts 2 and 3 x ISO/IEC 9797, Parts 1 to 3 x ISO/IEC 14888, Parts 1 to 3 x

51

ITU-T X.815 (11/1995) x ISO/IEC 27701:2019 x ISO/IEC 29100:2011 x ETSI TS 103 485 V1.1.1 (2020-08) x ISO/IEC 22237-1:2021 x ITU-T Y.4810 (11/2021) x ISO/IEC TS 19249:2017 x ISO/IEC 15408-2:2022 x ISO/IEC 27001:2022 x ISO/IEC 27034-1:2011 x EN ISO/IEC 15408-3:2022 x ISO/IEC 13888-1:2020 x ISO/IEC 30111:2019 x IEC 62443-2-1:2010 x Table 22: Overall list of the identified standards with their respective mapping towards the security requirements

Vulnerability handling requirements

Standard 1 2 3 4 5 6 7 8

ISO/IEC 27036, Parts 1 to 3 x ISO/IEC 27001:2022 x x ISO/IEC 27002:2022 x x x x EN ISO/IEC 30111:2020 x x x x x EN ISO/IEC 29147:2020 x x x x IEC 62443-4-1:2018 x x x x ISO/IEC TS 27034-5-1:2018 x

52

ISO/IEC 27005:2022 x

ETSI EN 303 645 V2.1.1 (2020-06) x x

Some overall remarks stem from the detailed analysis of the previous section and from the two above summary tables, and are summarized here below: — Overall, the existing standards cover at least partially all CRA requirements. This provides a strong basis to build on taking into consideration the identified gaps. Nevertheless, we did not find a single standard that can, alone, satisfy all requirements listed in the two lists present in Annex I of the CRA; — In general, “horizontal” standards - i.e., not targeting a specific use case or a market sector emerged as the most relevant to cover the purposes of the different requirements. The only exception to this is represented by some standards of the EN IEC 62443 family (related to industrial control systems) and the Internet of Things (IoT), although in our opinion standards targeting the IoT domain can be seen mostly as horizontal standards, since nowadays most digital devices can be associated to the IoT scenario; — Although some of the selected standards are not directly related to product design/development (e.g., EN ISO/IEC 27002 related to recommended controls for initiating, implementing or maintaining information security management systems), they might nevertheless be relevant for the CRA, as their implementation by an organisation will be reflected also in the products produced by that organisation; — Regarding the product-related security requirements of the first list of CRA Annex I, the standard ETSI EN 303 645 has been indicated to us as one of the most relevant, and for this reason we have made a specific attempt to map it on all the requirements, which result somehow all covered by the standard even if with some gaps. To be also noted that the standard is specifically devoted to IoT systems, so, even if many digital products nowadays present different features analogous to those of the IoT environment, an automatic applicability of this standard to all categories of products cannot to be taken for granted (see also the comment below about the requirement 3g). Another relevant standard in terms of coverage of the requirements is EN ISO/IEC 27002 (information security controls), covering 6 out of 13 requirements. Also the EN IEC 62443 family offers a quite good coverage, but it is specifically devoted to industrial control systems. — For the vulnerability handling requirements, the second list of the annex, EN ISO/IEC 30111 (vulnerability handling process) is the most relevant one, covering 5 out of 8 requirements, with also EN ISO/IEC 29147 (vulnerability disclosure) covering 4 of the same requirements. All these standards are “horizontal” in terms of their application; — In some cases, such as requirement 3(b) (ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems), the selected standards are quite generic whereas there exist several other standards covering specific use cases in more detail. The selection of more generic standards allows more flexibility and wider coverage of current and future use cases. On the other hand, specific and sectoral standards might be able to satisfy more closely the peculiar constraints and requirements of specific niches;

53

— In other cases, e.g., 3(f) (protect the availability of essential functions, including the resilience against and mitigation of denial of service attacks), the focus of the identified documents is more on infrastructural elements rather than user products or services. Even though these infrastructures are the core for provisioning of services and for some device functionalities, more specific standard provisions would be needed. Those are present for IoT devices, but still at a high level; — While requirement 3(g), which focuses on minimizing negative impacts on the availability of services provided by other devices or networks, is specifically addressed by standards related to the IoT domain, it raises questions about the broader applicability of these standards. In the context of the highly interconnected nature of devices in the IoT domain, these standards have clear relevance. However, for other domains, the specific applicability of IoT-focused cybersecurity standards may need further evaluation. While interconnectedness is also a characteristic of several domains nowadays, the specific requirements, regulations, and risks might vary, necessitating a tailored approach or additional measures to ensure that cybersecurity needs are adequately addressed.

54

5 Conclusion

Products with digital elements are evermore present in our lives. The increasing number of cyberattacks affecting them triggers negative impacts on many different aspects of our society. As a response the European Commission has proposed the Cyber Resilience Act, a new legislative framework prescribing a set of cybersecurity requirements that manufacturers have to implement in their products with digital elements. The defined requirements should be translated into harmonised European standards which would become the reference cybersecurity specifications to be followed by manufacturers. In view of this standardisation activity, this report identifies the most relevant already existing cybersecurity standards mapping them to the different requirements, describing both the level of offered coverage and the gaps to be possibly considered in further standardisation efforts. According to our analysis for each of the defined requirements there is already at least one document that can be considered as an initial reference offering some coverage. However, to the best of our knowledge, there is not a single standard capable of covering all the requirements expressed in the proposed legislative act, even if some of the standards do partially cover all of the requirements. The analysis offers re-assurance that a good international cybersecurity standardisation base is already in place for serving the scope of the Cyber Resilience Act requirements, but harmonisation is needed to ensure a homogeneous horizontal coverage, and some gaps, as highlighted in this report, need still to be addressed.

55

References

[1] Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020, COM/2022/454. https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A52022PC0454 [2] SPDX: A Linux Foundation standard for sharing software components, licenses, copyrights, and security data, providing a consistent SBOM format - SPDX Specification 2.2. https://spdx.github.io/spdx-spec/ [3] NTIA's Software Component Transparency Initiative - a U.S. initiative working on standardizing SBOM formats and best practices for software component transparency. https://www.ntia.gov/SBOM [4] CycloneDX: An SBOM specification designed for application security and supply chain component analysis, offering a lightweight format for describing software components and metadata - CycloneDX Specification. https://cyclonedx.org/capabilities [5] ECSO Supply Chain management and Product Certification Composition. https://ecsorg.eu/activities/standardisation-certification-and-supply-chain-management/ [6] IIoTSBOM is an initiative from LSEC, Flanders Make and KU Leuven COSIC from Belgium to improve cybersecurity for devices. Inspired and with the support of the US CISA (CyberSecurity and Infrastructure Security Agency). https://www.iiotsbom.com/ [7] The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities and exposures. https://cve.mitre.org/ [8] The National Vulnerability Database (NVD) is the U.S. government repository of standardsbased vulnerability management data, enabling automation of vulnerability management, security measurement, and compliance. https://www.nist.gov/itl/products-andservices/national-vulnerability-database-nvd [9] The Vulnerability Reporting and Data eXchange Special Interest Group (VRDX SIG) of the Forum of Incident Response and Security Teams (FIRST) focuses on improving vulnerability management processes and standards. https://www.first.org/global/sigs/vrdx [10]NIST SP 800-61 Revision 2 - Computer Security Incident Handling Guide. https://www.researchgate.net/publication/320851514_NIST_Special_Publication_800- 61_Revision_2_Computer_Security_Incident_Handling_Guide [11]The CSIRT (Computer Security Incident Response Team) Network is a collaborative platform where members can cooperate, exchange information, and build trust. The network's members, composed of CSIRTs appointed by EU Member States and CERT-EU ('CSIRTs Network members'), work together to improve the handling of cross-border incidents and discuss how to respond in a coordinated manner to specific incidents. https://www.enisa.europa.eu/topics/incident-response/csirts-in-europe/csirts-network [12]The PSIRT (Product Security Incident Response Team) Services Framework is a document developed by the FIRST (Forum of Incident Response and Security Teams) community, detailing potential services that CSIRTs (Computer Security Incident Response Teams) and PSIRTs may provide. https://www.first.org/resources/guides/first-psirt-services-frameworkv1.0.pdf [13]NIST SP 800-53: This standard provides a catalog of security and privacy controls for all U.S. federal information systems except those related to national security. It aims to protect individuals' privacy and organizational operations from a diverse set of threats. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf [14]NIST SP 800-63B: This is a guideline for digital identity services. It offers technical requirements for each of three levels of assurance in the areas of identity proofing,

56

authentication, and federation. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf [15]OWASP SSDLC: The Open Web Application Security Project (OWASP) Secure Software Development Life Cycle Project is a guide to security in the software development life cycle. It provides a core framework for integrating security concepts and best practices into a software development process. https://owasp.org/www-project-secure-software-developmentlifecycle/ [16]The patch management approach outlined in the EU Common Criteria is for certified ICT products and aims to ensure the security of the products through proper vulnerability handling and patch deployment. The process allows for different patch levels based on the severity and urgency of vulnerabilities, and it involves the collaboration of various stakeholders in the certification process. Annex 15: https://www.enisa.europa.eu/publications/cybersecurity-certification-eucc-candidatescheme-v1-1.1

57

List of abbreviations and definitions

API Application Programming Interface CERT Computer Emergency Response Team CD Continuous Deployment – A Software engineering approach that involves regularly delivering software features using automated deployment processes. CI Continuous Integration – A Software engineering approach that consists in automatically integrating code changes from various contributors into a unified software repository, where automated tests and builds are performed. CISA Cybersecurity and Infrastructure Security Agency - A U.S. government agency responsible for cybersecurity and critical infrastructure protection CRA Cyber Resilience Act CSIRT Computer Security Incident Response Team CVD Coordinated Vulnerability Disclosure - A process of reporting and addressing vulnerabilities in a collaborative manner DoS Denial of Service DDoS Distributed Denial of Service ECSO European Cyber Security Organisation - An organization that aims to develop a cybersecurity ecosystem in Europe ENISA European Union Agency for Cybersecurity ESO European Standardisation Organization FIRST Forum of Incident Response and Security Teams - A global organization focused on incident response and security coordination GDPR General Data Protection Regulation IACS Industrial Automation and Control Systems IIoTSBOM Industrial Internet of Things Software Bill of Materials - An initiative to improve cybersecurity for devices IoT Internet of Things ISMS Information Security Management System JRC Joint Research Centre

58

LSEC Leaders in Security - A European information security cluster NIST National Institute of Standards and Technology - A U.S. government agency that develops standards and guidelines NTIA National Telecommunications and Information Administration - A U.S. government agency PII Personal Identifiable Information PKI Public Key Infrastructure PSIRT Product Security Incident Response Team - A team responsible for handling security incidents and vulnerabilities in products ROM Read Only Memory SaaS Software as a Service SBOM Software Bill of Materials - A document that lists the components used in a software product SDO Standards Developing Organisation SP Special Publication - A series of publications by NIST covering various technology and security topics SPDX Software Package Data Exchange - A Linux Foundation standard for sharing software component information VRDX SIG Vulnerability Reporting and Data eXchange Special Interest Group - A group within FIRST focused on vulnerability reporting and data exchange XML eXtensible Markup Language

59

List of figures

60

Annexes

Annex 1. High level pre-screening of standardisation activities with potential relevance for the CRA requirements

As preparatory activity of the present study, with the aim to offer a robust mapping of the CRA requirements against the relevant cybersecurity standardisation activities offered by European and international standardisation body, several outputs produced by their committees have been surveyed. This pre-analysis has represented the ground on which to build the detailed mapping of standards against the CRA requirements. In the screening activity already published standards have been obviously considered, but ongoing standardisation efforts, technical specifications, technical reports and guidelines have been also taken into consideration. The analysis of each of them has been based solely on freely available information, like overviews, summaries, abstracts, tables of content and where possible the full text. For each identified document a tentative coarse mapping against the CRA requirements has been sketched, so as to measure the potential relevance of each of them in the actual mapping. In the table below we summarise the number of committees and documents we went through for the pre-screening of the present study, so as to give an insight about the amplitude of the analysis.

Committees/Working Surveyed groups Standards/Documents

International SDOs (ISO, IEC, ITU) 37 ~ 950

European SDOs (CEN, CENELEC, 25 ~ 270

ETSI)

62