+Article 3 Definitions
|
Article 3 Definitions
Article 3
For the purposes of this Regulation, the following definitions apply:
|
(1)
|
‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;
|
|
(2)
|
‘remote data processing’ means data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions;
|
|
(3)
|
‘cybersecurity’ means cybersecurity as defined in Article 2, point (1), of Regulation (EU) 2019/881;
|
|
(4)
|
‘software’ means the part of an electronic information system which consists of computer code;
|
|
(5)
|
‘hardware’ means a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data;
|
|
(6)
|
‘component’ means software or hardware intended for integration into an electronic information system;
|
|
(7)
|
‘electronic information system’ means a system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data;
|
|
(8)
|
‘logical connection’ means a virtual representation of a data connection implemented through a software interface;
|
|
(9)
|
‘physical connection’ means a connection between electronic information systems or components implemented using physical means, including through electrical, optical or mechanical interfaces, wires or radio waves;
|
|
(10)
|
‘indirect connection’ means a connection to a device or network, which does not take place directly but rather as part of a larger system that is directly connectable to such device or network;
|
|
(11)
|
‘end-point’ means any device that is connected to a network and serves as an entry point to that network;
|
|
(12)
|
‘economic operator’ means the manufacturer, the authorised representative, the importer, the distributor, or other natural or legal person who is subject to obligations in relation to the manufacture of products with digital elements or to the making available of products with digital elements on the market in accordance with this Regulation;
|
|
(13)
|
‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge;
|
|
(14)
|
‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;
|
|
(15)
|
‘authorised representative’ means a natural or legal person established within the Union who has received a written mandate from a manufacturer to act on its behalf in relation to specified tasks;
|
|
(16)
|
‘importer’ means a natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union;
|
|
(17)
|
‘distributor’ means a natural or legal person in the supply chain, other than the manufacturer or the importer, that makes a product with digital elements available on the Union market without affecting its properties;
|
|
(18)
|
‘consumer’ means a natural person who acts for purposes which are outside that person’s trade, business, craft or profession;
|
|
(19)
|
‘microenterprises’, ‘small enterprises’ and ‘medium-sized enterprises’ mean, respectively, microenterprises, small enterprises and medium-sized enterprises as defined in the Annex to Recommendation 2003/361/EC;
|
|
(20)
|
‘support period’ means the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I;
|
|
(21)
|
‘placing on the market’ means the first making available of a product with digital elements on the Union market;
|
|
(22)
|
‘making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;
|
|
(23)
|
‘intended purpose’ means the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation;
|
|
(24)
|
‘reasonably foreseeable use’ means use that is not necessarily the intended purpose supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation, but which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions;
|
|
(25)
|
‘reasonably foreseeable misuse’ means the use of a product with digital elements in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems;
|
|
(26)
|
‘notifying authority’ means the national authority responsible for setting up and carrying out the necessary procedures for the assessment, designation and notification of conformity assessment bodies and for their monitoring;
|
|
(27)
|
‘conformity assessment’ means the process of verifying whether the essential cybersecurity requirements set out in Annex I have been fulfilled;
|
|
(28)
|
‘conformity assessment body’ means a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008;
|
|
(29)
|
‘notified body’ means a conformity assessment body designated in accordance with Article 43 and other relevant Union harmonisation legislation;
|
|
(30)
|
‘substantial modification’ means a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed;
|
|
(31)
|
‘CE marking’ means a marking by which a manufacturer indicates that a product with digital elements and the processes put in place by the manufacturer are in conformity with the essential cybersecurity requirements set out in Annex I and other applicable Union harmonisation legislation providing for its affixing;
|
|
(32)
|
‘Union harmonisation legislation’ means Union legislation listed in Annex I to Regulation (EU) 2019/1020 and any other Union legislation harmonising the conditions for the marketing of products to which that Regulation applies;
|
|
(33)
|
‘market surveillance authority’ means a market surveillance authority as defined in Article 3, point (4), of Regulation (EU) 2019/1020;
|
|
(34)
|
‘international standard’ means an international standard as defined in Article 2, point (1)(a), of Regulation (EU) No 1025/2012;
|
|
(35)
|
‘European standard’ means a European standard as defined in Article 2, point (1)(b), of Regulation (EU) No 1025/2012;
|
|
(36)
|
‘harmonised standard’ means a harmonised standard as defined in Article 2, point (1)(c), of Regulation (EU) No 1025/2012;
|
|
(37)
|
‘cybersecurity risk’ means the potential for loss or disruption caused by an incident and is to be expressed as a combination of the magnitude of such loss or disruption and the likelihood of occurrence of the incident;
|
|
(38)
|
‘significant cybersecurity risk’ means a cybersecurity risk which, based on its technical characteristics, can be assumed to have a high likelihood of an incident that could lead to a severe negative impact, including by causing considerable material or non-material loss or disruption;
|
|
(39)
|
‘software bill of materials’ means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements;
|
|
(40)
|
‘vulnerability’ means a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat;
|
|
(41)
|
‘exploitable vulnerability’ means a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions;
|
|
(42)
|
‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner;
|
|
(43)
|
‘incident’ means an incident as defined in Article 6, point (6), of Directive (EU) 2022/2555;
|
|
(44)
|
‘incident having an impact on the security of the product with digital elements’ means an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions;
|
|
(45)
|
‘near miss’ means a near miss as defined in Article 6, point (5), of Directive (EU) 2022/2555;
|
|
(46)
|
‘cyber threat’ means a cyber threat as defined in Article 2, point (8), of Regulation (EU) 2019/881;
|
|
(47)
|
‘personal data’ means personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679;
|
|
(48)
|
‘free and open-source software’ means software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable;
|
|
(49)
|
‘recall’ means recall as defined in Article 3, point (22), of Regulation (EU) 2019/1020;
|
|
(50)
|
‘withdrawal’ means withdrawal as defined in Article 3, point (23), of Regulation (EU) 2019/1020;
|
|
(51)
|
‘CSIRT designated as coordinator’ means a CSIRT designated as coordinator pursuant to Article 12(1) of Directive (EU) 2022/2555.
|
1. Übersicht
1.1 Referenzen
1.2 Identifizierte Anforderungen
1.3 Related Standards
2. Identifizierte Anforderungen
Anforderungen
| Source |
Anforderung |
3. Related Standards
Standards
| Source |
Anforderung |
|
SCF
|
Standardized Terminology
Description
Mechanisms exist to standardize technology and process terminology to reduce confusion amongst groups and departments.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Follow secure coding basics when developing software
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Secure coding guidelines for developers
∙ Basic security review before release
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Formal security engineering principles
∙ Secure design patterns
∙ Threat modeling
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise security engineering program
∙ Formal threat modeling
∙ Security architecture standards
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise security architecture framework (SABSA)
∙ Formal threat modeling program
∙ Security design patterns library
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.
Level 2 Planned Tracked
Secure Engineering & Architecture (SEA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).
Level 3 Well Defined
Secure Engineering & Architecture (SEA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners.
▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution, etc.).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).
▪ An implemented and operational capability exists to standardize technology and process terminology to reduce confusion amongst groups and departments.
Level 4 Quantitatively Controlled
Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
|
|