Fixed general tests

### 5.1.2 Secure design, development and production

This document will make informative reference prEN 40000-1-2 "Principles for cyber resilience" <a href="#_ref_i.15">[i.15]</a> normative, when available.

This document will make normative reference to prEN 40000-1-2 "Principles for cyber resilience" <a href="#_ref_i.15">[i.15]</a>, when available.

### 5.1.3 Product vulnerability management process

This document normatively references EN 40000-1-3 "Vulnerability Handling"<a href="#_ref_2">[2]</a> and doesn't add to the specified definitions.

This document normatively references EN 40000-1-3 "Vulnerability Handling"<a href="#_ref_2">[2]</a> and doesn't currently add to the specified definitions.

## 5.2 Technical cybersecurity requirements specifications

**Verdict:**

1. Pass if cross referencing OS and Application upgrade instructions makes it possible to maintain given High Availability requirements.

1. Fail otherwise.

1. Pass if cross referencing OS and Application upgrade instructions makes it possible to maintain High Availability requirements defined in the technical documentation.

2. Fail otherwise.

**Supporting Evidence:**

## 6.2 Technical cybersecurity requirement tests and assessments

### 6.2.0.1 REQ-TECH-0

### 6.2.0.0 REQ-TECH-0

**Requirement:** The product shall be shipped without undocumented interfaces.<br/>

**Objective:** How the product communicates is understood and documented.<br/>

**Preparation:**

1. List all the interfaces the product is listening.

1. Cross-reference the open interfaces to the documentation.

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**Verdict:**

1. Pass, if all interfaces used for communication are documented.

2. Fail otherwise.

**Supporting Evidence:**

### 6.2.0.0 REQ-TECH-1

1. References to to documentation sections.

### 6.2.0.1 REQ-TECH-1

**Requirement:** An network management system shall implement [5.2.4 State-of-the-art cryptographic libraries] to allow the protection of the requirements of the forseeable use.<br/>

**Objective:** The product follows changes in the Agreed Cryptographic Mechanisms specification and shows how the product does that.<br/>

**Requirement:** A network management system shall implement [5.2.4 State-of-the-art cryptographic libraries] to allow the protection of the requirements of the forseeable use.<br/>

**Objective:** Agreed Cryptographic Mechanisms specification is followed and the product shows it does that.<br/>

**Preparation:**

1.  Have the product initialised and available with the default configuration and required credentials.

**Requirement:** When privileged information is transferred or accessed, a secure channel shall be used in transport [5.2.1 Secure channel definition].<br/>

**Objective:** <br/>

**Preparation:**

1.  Have the product initialised and available with the default configuration and required credentials.

**Preparation:** None<br/>

**Activities:**

1. Study the technical documentation.

### 6.2.0.3 REQ-TECH-3

**Requirement:** All endpoints in a secure channel shall cryptographically verify others.<br/>

**Objective:** <br/>

**Preparation:**

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**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 described system makes it possible to execute mutual authentication,

2. and, there is no debug mode or equivalent turened on by default.

3. Fail otherwise.

**Supporting Evidence:**

1. References to to documentation sections.

### 6.2.0.4 REQ-TECH-4

**Requirement:** The product shall be designed in a way that [5.2.2 Cryptographic key intialisation and rotation] is made possilbe.<br/>

**Objective:** <br/>

**Preparation:**

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**Objective:** When employees and administrators roles change, the keys need to be changed also.<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. Fail otherwise.

**Supporting Evidence:**

1. References to to documentation sections.

### 6.2.0.5 REQ-TECH-5

**Requirement:** All system components shall be synchronized to the same time.<br/>

**Objective:** All system components are synchronized to the same time.<br/>

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**Objective:** When monitoring information, logs, metrics and traces, is collected, the timing of different events is relying on clock accuracy.<br/>

**Preparation:**

1.  Have the product initialised and available with the default configuration and required credentials.

**Activities:**

1. Dump all clock from all participating systems and nodes.

2. Ensure that the clock deviation is within limits specified in the techinal documentation.

3. If unsure, verify that the clock synchronisation mechanism is in use and functioning in the default installation.

**Verdict:**

1. Pass, if the clock deviation is under the specified limit in the technical documentation.

2. Fail otherwise.

**Supporting Evidence:**

1. Log output from the test.

#### 6.2.0.6 REQ-TECH-6

**Requirement:** All system clock drifts shall be monitored.<br/>

**Objective:** Accuracy in multiple different monitoring sources require consistent clocks.<br/>

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <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.

**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

**Requirement:** The product shall be designed in a way, that all cryptographic keys can be replaced with user controlled keys.<br/>

**Objective:** <br/>

**Preparation:**

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**Objective:** Customer need to have full control of the integrity of the data stored in the system.<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.

2. Fail otherwise.

**Supporting Evidence:**

1. References to to documentation sections.

#### 6.2.5.0 REQ-SBOM-0