This section contains technical cybersecurity requirements for the product. Each general technical requirement is objectively verifiable on an instance of a product.
Each requirement has at least one concrete example that satisfies the requirements of the CRA.
Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these general requirements to [Section 4.5 Risk Factors](#45-risk-factors). The Risk Mitigations can include additional topic specific requirements.
When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [SRU], [Complexity], [Segment], and [CENT] defines the below risk category low, medium or high to follow. The requirements covering high risks comprise all requirements of the medium and low risk, and, analogously, the requirements from the medium risk comprise also those from the low risk.
<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>
For low risk:
***[REQ-TECH-0]** The product shall be shipped without unknown interfaces.
***[REQ-TECH-0]** The product shall not connect to unknown RDPS services.
***[REQ-TECH-1]** The product shall implement [5.2.4 State-of-the-art cryptographic libraries] in all interfaces, expect the ones that are available only in localhost.
***[REQ-TECH-2]** When privileged information is transferred or accessed, a secure channel shall be used in transport [5.2.1 Secure channel].
For medium risk:
* This document does not have medium level requirements in this category.
For high risk:
***[REQ-TECH-6]** All system time drift corrections shall be recorded as monitoring event.
***[REQ-TECH-7]** The product shall be designed in a way, that all user accessible and controlled cryptographic keys can be replaced.
***[REQ-TECH-8]** The product shall make known the purpose and usage of keys that are not user accessible, where present.
***[REQ-TECH-9]** In the context of key management and accepting new devices to the management context:
1. The product shall support initialization of trust in a greenfield deployment, and in the connected device management;
2. The product shall support accepting managed elements into the network based on that trust;
3. The product shall support key rotation and replacement of all relevant cryptographic keys after trust has been established.
### 5.2.1 Secure channel
### 5.2.2 Cryptographic key intialisation and rotation
@@ -94,9 +68,6 @@ For high risk:
## 5.3 Risk Mitigations
The following sections describe how technical cybersecurity requirement in previous [Section 5.2](#52-technical-cybersecurity-requirements-specifications) are mapped to the risk factors in [Section 4.5 Risk Factors](#45-risk-factors).
This section can include topic specific requirements.
### 5.3.1 Mitigations for user identity integrity
### 5.3.2 Mitigations for ingested data integrity and confidentiality
@@ -121,157 +92,6 @@ This section can include topic specific requirements.
## 6.2 Technical cybersecurity requirement tests and assessments
### 6.2.0.0 REQ-TECH-0
**Objective:** How the product communicates is understood and documented.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
1. Study the listed documented communication endpoints.
1. List all the interfaces the product is listening.
1. Cross-reference the open interfaces to the documentation.
**Verdict:**
1. Pass, if all interfaces used for communication are documented.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.2.0.1 REQ-TECH-1
**Objective:** The implementation and operation follows the Agreed Cryptographic Mechanisms specification and the Annex K.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
2. Identify the patterns from architectural documentation where encryption is required.
3. Study the implementation from the product or from the technical documentation.
**Verdict:**
1. Pass if the documentation describes with enough details how and where the cryptographic features and functions are used,
2. and handling of data is identified and protected with cryptogaphy as defined in Annex K.
3. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.2.0.2 REQ-TECH-2
**Objective:** Protect the integrity of the data.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Identify the structures where data is transferred.
3. Study the deployment guidance.
4. Study the implementation from the product and from the technical documentation.
**Verdict:**
1. Pass, if the data flow and transmission is identifiable from the technical documentation
2. and testing the implementation of interfaces matches the documentation
3. and the interfaces transfering confidential data are protected with encryption.
4. Fail otherwise.
**Supporting Evidence:**
1. Listing of tested interfaces and the protocol replies that show that encryption is used.
2. Listing of interfaces showing authentication is used.
### 6.2.0.3 REQ-TECH-3
**Objective:** Mutual authentication ensures that blind trust is not part of the system design.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Identify the structures where administrative, PII or otherwise privileged information is transferred.
3. Study the implementation from the product and from the technical documentation.
**Verdict:**
1. Pass, if the mechanism for mutual authentication is implemented,
2. and, there is no debug mode or equivalent activated on by default.
3. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.2.0.4 REQ-TECH-4
**Objective:** When employees and administrators roles change, the related keys shall change accordingly.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Cross reference the instuctions how and how often to do rotation of important keys to industry state-of-the art policies.
**Verdict:**
1. Pass, if key rotation can be made on demand,
2. and the instructed rotation policy is fit for the foreseeable use of the product
3. and the keys can be initialised when the product is taken into a use for a firts time or after a reset to factory settings.
4. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.2.0.6 REQ-TECH-6
**Objective:** Where multiple monitoring sources all operate they shall have consistent system time where any drift or lack of synchronization shall be accurately documented and notification provided to administrator.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Set a node or a system to a wrong time that is off by at leat an hour.
2. Set a managed device or connected service to a wrong time that deviates from real time by at least one hour.
**Verdict:**
1. Pass, if system notices the drift,
2. and creates a notification about the event.
3. Fail otherwise.
**Supporting Evidence:**
1. System notification from the logs.
### 6.2.0.7 REQ-TECH-7
**Objective:** Product shall provide users with data management capabilities and ability to verify the integrity of the stored data in the NMS. <br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Cross reference to the architectural description of how the encryption is used in different parts of the system.
**Verdict:**
1. Pass, if customer has a ability to change all cyptographic keys in the system except the ones that are reasonably made immutable.
@@ -1054,17 +1054,32 @@ High requirement level shall implement all requirements in the defined set of re
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (1).
### 5.2.1 Architecture and design
System operation is always an interplay of multiple components.
Modern software design can rarely ignore impact of the changes to other components.
On product architecture and design:
For **low** risk:
***CYB_GENERAL_1** The product shall define whether a service is completely fulfilled by the product itself.
***CYB_GENERAL_2** The product shall describe the external services and systems that are required for the product operation.
***CYB_GENERAL_3** The product shall define how it is dependent on RDPS.
***CYB_GENERAL_4** The product shall describe the dependencies to Operating System essential security capabilities.
On operative environment:
For **medium** risk:
***CYB_GENERAL_5** In the context of key management and accepting new devices to the management context:
1. The product shall support initialization of trust in a greenfield deployment, and in the connected device management;
2. The product shall support accepting managed elements into the network based on that trust;
3. The product shall support key rotation and replacement of all relevant cryptographic keys after trust has been established.
For **high** risk:
***CYB_GENERAL-6** The product shall be designed in a way, that all user accessible and controlled cryptographic keys can be replaced.
***CYB_GENERAL-7** The product shall make known the purpose and usage of keys that are not user accessible, where present.
***CYB_GENERAL-8** All system time drift corrections shall be recorded as monitoring events.
### 5.2.1 Operative environment:
***CYB_OPS_5** The product shall describe the core requirements and expectations for the operational environment (OE).
***CYB_OPS_6** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
@@ -1129,9 +1144,17 @@ Recognising that there may be vulnerabilities discovered between the time that a
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>
For low risk:
***SBD_TECH-1** The product shall be shipped without unknown interfaces.
***SBD_TECH-2** The product shall not connect to unknown RDPS services.
***SBD_TECH-3** The product shall implement **CON_CRYPTO-1** in all interfaces, expect the ones that are available and reachable only in localhost by the local processes.
***SBD_TECH-4** When privileged information is transferred or accessed, a [5.7.2 Secure channel](#572-secure-channel) shall be used in transport.
> NOTE: Cryptographic mechanisms not covered by **CON_CRYPTO-1** are disabled by default.
***SBD_CRYPTO-1** For backward compatibility:
***SBD_CRYPTO-1** For backward compatibility, if supported:
* the product shall inform the user about the security implications when not using the default configuration;
* the product shall inform the user the component requiring the weaker mechanism;
* the product shall inform the user the justification for backward compatibility;
@@ -1387,11 +1410,11 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
### 5.8.2 Cryptographic key intialisation and rotation
***INT_ROTATE-4** The product shall support and implement a on-demand rotation of cryptographic keys.
***INT_ROTATE-5** The product shall support the initialisation of trust.
***INT_ROTATE-6** The product shall support cryptographic mechanisms used to accept managed elements to the network.
***INT_ROTATE-7** The product shall support a method to replace or update the cryptographic keys in the system and in the managed elements the product has control over.
***INT_ROTATE-8** The prodcut shall not trust expired keys.
***INT_ROTATE-1** The product shall support and implement a on-demand rotation of cryptographic keys.
***INT_ROTATE-2** The product shall support the initialisation of trust.
***INT_ROTATE-3** The product shall support cryptographic mechanisms used to accept managed elements to the network.
***INT_ROTATE-4** The product shall support a method to replace or update the cryptographic keys in the system and in the managed elements the product has control over.
***INT_ROTATE-5** The prodcut shall not trust expired keys.
Trust is inherited from a parenting system or from an existing entity.
Rollout automation and zero touch configuration approaches rely on concepts, which are not nessesarily well established, and vendor specific.
@@ -1487,7 +1510,7 @@ Especially when there are forensic demands, comprehensive and detailed logging b
The logging requirements in this subclause define baseline event recording and additional protections for retention, integrity, backup, and external forwarding according to the applicable risk tier.
For low risk:
For **low** risk:
***MON_LOG-0a** The log file of events shall be protected from unauthorised access.
***MON_LOG-0b** The log data of events shall be protected from modification including their deletion.
@@ -1514,7 +1537,7 @@ The following requirements apply where the corresponding function exists:
***MON_LOG-3c** The product shall log events described by [5.3.4 Secure updates].
***MON_LOG-3d** The product shall log installation successes and failures in the managed devices and the product itself if that information can be extracted from the targets.
For medium risk:
For **medium** risk:
***MON_LOG-4:** The log information shall have an active backup scheduled.
***MON_LOG-5:** Administrative log records, traces and events shall be forwarded to or stored in a service that prevents unauthorized modification or deletion of recorded entries.
@@ -1522,7 +1545,7 @@ For medium risk:
> Clarification: write only service can be append only or even idempotent upsert system that does not let the received message to be altered later.
> The aim is to prevent a possible attacker to clear its traces by deleting the actions done in the system by distorting the history.
For high risk:
For **high** risk:
***MON_LOG-6** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
***MON_LOG-7** SIEM transfer format, field attributes and event descriptions shall made available in a machine readable format.
Matching tests for these requirements are listed in [6.3.6 Metrics tests].
## 5.15 Factory reset and data portability
<mark>_Proposed ESR code: DRT_</mark>
@@ -1715,6 +1737,47 @@ NNNNN - Incremental and unique sequence of numbers and letters - could be the sa
1. References to the documentation sections.
2. Listing of discovered targets and an explanation of those targets.
### 6.2.1 Architecture and design tests
#### 6.2.1.7 CYB_GENERAL-8
**Objective:** Product shall provide users with data management capabilities and ability to verify the integrity of the stored data in the NMS. <br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Cross reference to the architectural description of how the encryption is used in different parts of the system.
**Verdict:**
1. Pass, if customer has a ability to change all cyptographic keys in the system except the ones that are reasonably made immutable.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.2.1.8 CYB_GENERAL-8
**Objective:** Where multiple monitoring sources all operate they shall have consistent system time where any drift or lack of synchronization shall be accurately documented and notification provided to administrator.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Set a node or a system to a wrong time that is off by at leat an hour.
2. Set a managed device or connected service to a wrong time that deviates from real time by at least one hour.
**Verdict:**
1. Pass, if system notices the drift,
2. and creates a notification about the event.
3. Fail otherwise.
**Supporting Evidence:**
1. System notification from the logs.
## 6.3 No known exploitable vulnerabilities
@@ -1764,6 +1827,53 @@ Verify that:
## 6.4 Secure by default configuration
### 6.4.1 SBD_TECH-1
**Objective:** How the product communicates is understood and documented.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
1. Study the listed documented communication endpoints.
1. List all the interfaces the product is listening.
1. Cross-reference the open interfaces to the documentation.
**Verdict:**
1. Pass, if all interfaces used for communication are documented.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.4.4 SBD_TECH-4
**Objective:** Protect the integrity of the data.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Identify the structures where data is transferred.
3. Study the deployment guidance.
4. Study the implementation from the product and from the technical documentation.
**Verdict:**
1. Pass, if the data flow and transmission is identifiable from the technical documentation
2. and testing the implementation of interfaces matches the documentation
3. and the interfaces transfering confidential data are protected with encryption.
4. Fail otherwise.
**Supporting Evidence:**
1. Listing of tested interfaces and the protocol replies that show that encryption is used.
2. Listing of interfaces showing authentication is used.
## 6.5 Security updates
### 6.5.1 SU_UPDATE-1
@@ -1842,8 +1952,73 @@ Verify that:
## 6.7 Confidentiality protection
### 6.7.2 Secure channel tests
#### 6.7.2.1 CON_CHANNEL-1
**Objective:** The implementation and operation follows the Agreed Cryptographic Mechanisms specification and the Annex K.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
2. Identify the patterns from architectural documentation where encryption is required.
3. Study the implementation from the product or from the technical documentation.
**Verdict:**
1. Pass if the documentation describes with enough details how and where the cryptographic features and functions are used,
2. and handling of data is identified and protected with cryptogaphy as defined in Annex K.
3. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.7.2.2 CON_CHANNEL-2
**Objective:** Mutual authentication ensures that blind trust is not part of the system design.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Identify the structures where administrative, PII or otherwise privileged information is transferred.
3. Study the implementation from the product and from the technical documentation.
**Verdict:**
1. Pass, if the mechanism for mutual authentication is implemented,
2. and, there is no debug mode or equivalent activated on by default.
3. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
## 6.8 Integrity protection
### 6.8.2.1 INT_ROTATE-1
**Objective:** When employees and administrators roles change, the related keys shall change accordingly.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Cross reference the instuctions how and how often to do rotation of important keys to industry state-of-the art policies.
**Verdict:**
1. Pass, if key rotation can be made on demand,
2. and the instructed rotation policy is fit for the foreseeable use of the product
3. and the keys can be initialised when the product is taken into a use for a firts time or after a reset to factory settings.
