@@ -1083,29 +1083,28 @@ Modern software design can rarely ignore impact of the changes to other componen
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.
***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 describe the dependencies to Operating System security capabilities.
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.
***CYB_GENERAL_4** In the context of key management and accepting new devices to the management context the product shall support:
1. initialisation of trust in a greenfield deployment, and in the connected device management;
2. accepting managed elements into the network based on that trust;
3. 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.
***CYB_GENERAL-5** The product shall be designed in a way, that all user accessible and controlled cryptographic keys can be replaced.
***CYB_GENERAL-6** The product shall make known the purpose and usage of keys that are not user accessible, where present.
***CYB_GENERAL-7** All system time drift corrections shall be recorded as monitoring events.
### 5.2.1 Operative environment:
### 5.2.2 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.
***CYB_OPS_7** Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
***CYB_OPS-1** The product shall describe the core requirements and expectations for the operational environment (OE).
***CYB_OPS-2** 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.
***CYB_OPS-3** Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.
@@ -1663,25 +1662,34 @@ For each cybersecurity requirements defined in clause 5, the following clauses s
## 6.2 Appropriate level of cybersecurity
### 6.2. REQ-GEN-2
### 6.2.1 Architecture and design
#### 6.2.1.1 CYB_GENERAL-1
**Objective:** Product dependencies to external services and systems are documented and understood.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Objective:** Dependencies to OS capabilities are documented and understood.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
2. Cross-reference the documentation to the system operation.
3. Monitor the network traffic and capture all targets the systems is trying to initiate a connection with.
**Verdict:**
1. Pass if important and essential OS services and concepts are named
1. and their usage to run the application workload is clearly expressed as part of the architecture description.
1. Fail otherwise.
1. Pass if product dependencies or external systems are named and their purpose and provisions are described
2. and the services or external systems are clearly expressed as part of the architecture description
3. and the monitored network traffic targets matches the documentation.
4. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
* References to the documentation sections.
* Listing of discovered targets and an explanation of those targets.
### 6.2. REQ-GEN-3
#### 6.2.1.2 CYB_GENERAL-2
**Objective:** Product dependencies to external services and systems are documented and understood.<br/>
**Preparation:**
@@ -1703,14 +1711,56 @@ For each cybersecurity requirements defined in clause 5, the following clauses s
**Supporting Evidence:**
1. References to the documentation sections.
2. Listing of discovered targets and an explanation of those targets.
* References to the documentation sections.
* Listing of discovered targets and an explanation of those targets.
#### 6.2.1.3 CYB_GENERAL-3
**Objective:** Dependencies to OS capabilities are documented and understood.<br/>
**Preparation:** None<br/>
**Activities:**
### 6.2.1 Architecture and design tests
1. Study the technical documentation.
#### 6.2.1.7 CYB_GENERAL-8
**Verdict:**
**Objective:** Product shall provide users with data management capabilities and ability to verify the integrity of the stored data in the NMS. <br/>
1. Pass if important and essential OS services and concepts are named
1. and their usage to run the application workload is clearly expressed as part of the architecture description.
1. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
#### 6.2.1.4 CYB_GENERAL-4
**Objective:** New devices added into the management pool are able to adopt the trust initialised with the system.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have a managed element available for testing.
**Activities:**
1. Investigate how the system initialises trust;
2. Perform nessesary actions defined in the technical documentation;
3. Join the managed element into the system;
4. Rotate the keys used in previous steps;
5. Repeat in all connections where such trust is used.
**Verdict:**
1. Pass, all tests pass without issues
2. and keys are replaced with provided ones in the managed device.
3. Fail otherwise.
**Supporting Evidence:**
* References to to documentation sections.
#### 6.2.1.5 CYB_GENERAL-5
**Objective:** To understand and to be ablet to take control over they keys used in confidentiality and integrity protection.<br/>
**Preparation:** None<br/>
**Activities:**
@@ -1719,14 +1769,35 @@ For each cybersecurity requirements defined in clause 5, the following clauses s
**Verdict:**
1. Pass, if customer has a ability to change all cyptographic keys in the system except the ones that are reasonably made immutable.
1. Pass, if customer has a ability to change user controllable cyptographic keys in the system except the ones that are reasonably made immutable.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
* References to to documentation sections.
#### 6.2.1.4 CYB_GENERAL-6
**Objective:** To understand and to be ablet to take control over they keys used in confidentiality and integrity protection.<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 technical documentation matches the product installation.
2. Fail otherwise.
**Supporting Evidence:**
#### 6.2.1.8 CYB_GENERAL-8
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
#### 6.2.1.7 CYB_GENERAL-7
**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:**
@@ -1735,7 +1806,7 @@ For each cybersecurity requirements defined in clause 5, the following clauses s
**Activities:**
1. Set a node or a system to a wrong time that is off by at leat an hour.
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:**
@@ -1746,7 +1817,63 @@ For each cybersecurity requirements defined in clause 5, the following clauses s
**Supporting Evidence:**
1. System notification from the logs.
* System notification from the logs.
### 6.2.2 Operative environment:
#### 6.2.2.1 CYB_OPS-1
**Objective:** The product user is able to meat the expectations of the product with the operational environment.<br/>
**Preparation:**
1. Study the technical documentation.
**Activities:**
1. Cross-reference the provided deployment instructions to described target environment design guidelines.
**Verdict:**
1. Pass, if the deployment, update and upgrade instructions are aligned with the target environment functionalities.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
#### 6.2.2.2 CYB_OPS-2
**Objective:** To understand what kind of connectivity the product is using.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Dump all relevant connectivity information from the product;
2. Cross-reference to the technical documentation;
3. Identify potential low level protocol usage that is not able to operate with adequate confidentiality.
**Verdict:**
1. Pass, if no low level protocol usage is detected
2. and the technical documentation matches the implementation.
3. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
#### 6.2.2.3 CYB_OPS-3
This assement is done based on the definitions in the [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
