Removed duplicate requirements

### 6.1.0.2 REQ-GEN-2

**Requirement:** The product dependencies to Operating System essential security capabilities are documented.

**Objective:** Dependencies to OS capabilities are documented and understood.<br/>

**Preparation:** None<br/>

**Activities:**

#### 6.1.1.0 REQ-EXPLOIT-0

**Requirement c:** For each detected vulnerability, the product shall have publicly available documentation explaining how the risk has been mitigated.<br/>

**Objective:** Disclosure of new vulnerabilities in the product and its dependencies are proactively monitored.<br/>

**Preparation:**

#### 6.1.1.1 REQ-EXPLOIT-1

**Requirement a:** The product shall be accompanied by documentation describing how the product may be securely updated,<br/>

**Requirement b:** including how to update the product prior to, or as part of, first use.<br/>

**Objective:** Prevent exploitation of known exploited vulnerabilities<br/>

**Preparation:**

#### 6.1.1.2 REQ-EXPLOIT-2

**Requirement:** The product shall have OS and Application upgrade instructions which makes it possible to obtain the set High Availability targets.<br/>

**Objective:** Responsibility of OS level updgrades can be elsewhere outside of the system control.<br/>

**Preparation:** None<br/>

**Activities:**

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

### 6.2.0.1 REQ-TECH-1

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

### 6.2.0.2 REQ-TECH-2

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

**Objective:** Protect the integrity of the data.<br/>

**Preparation:** None<br/>

**Activities:**

### 6.2.0.3 REQ-TECH-3

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

**Objective:** Mutual authentication ensures that blind trust is not part of the system design.<br/>

**Preparation:** None<br/>

**Activities:**

### 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:**  Ensure product that allows and encourages users to change keys when necessary for product security reasons, such as when employees and administrators roles change..<br/>

**Preparation:** None<br/>

**Activities:**

### 6.2.0.5 REQ-TECH-5

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

**Objective:** Prevent errors and innaccuracvy in logging, metrics, and traces, due to unsynchronized component clocks.<br/>

**Preparation:**

#### 6.2.0.6 REQ-TECH-6

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

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

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

#### 6.2.5.0 REQ-SBOM-0

**Requirement:** Operating system dependencies and application dependencies shall be clearly separated in the provided SBOM.<br/>

**Objective:** To make clear what part of the system to upgrade, the source of the dependency should be understandable.<br/>

**Preparation:** None<br/>

**Activities:**

#### 6.2.5.1 REQ-SBOM-1

**Requirement a:** Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM.<br/>

**Requirement b:** The SBOM identifier format is consistent with common vulnerability handling standards.<br/>

**Objective:** A linux kernel version can be 6.18, but what it contains? A refereable and exact pointer is needed.<br/>

**Preparation:** None<br/>

**Activities:**

1. Study the technical documentation.

1. Study the SBOM.

2. Study the SBOM.

**Verdict:**

#### 6.2.5.2 REQ-SBOM-2

**Requirement:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.<br/>

**Objective:** The deliverable erodes over time. The SBOM is one of the sources for the motivation to upgrade.<br/>

**Preparation:** None<br/>

**Activities:**

### 6.3.5.8 REQ-LOG-8

**Requirement:**

**Objective:** Reduces vendor lock-in and supports incident response and CRA evidence portability.

**Preparation:** None<br/>

**Activities:**

### 6.3.5.9 REQ-LOG-9

**Requirement:**

**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.

**Preparation:** None<br/>

**Activities:**

#### 6.3.6.0 REQ-METRICS-0

**Requirement:** The product shall be designed in a way that collected and stored metrics data can not be altered.<br/>

**Objective:** An attacker wants to hide its operations. System should prepare for that.<br/>

**Preparation:** None<br/>

**Activities:**

#### 6.3.6.1 REQ-METRICS-1

**Requirement:** Historical metrics data import overwriting an existing data point shall be noticed.<br/>

**Objective:** Prevent compromised managed element to hide its behaviour.<br/>

**Preparation:**

#### 6.3.6.2 REQ-METRICS-2

**Requirement:** Metrics name, purpose, and value interpretation shall be described for the user.<br/>

**Objective:** Understanding what is collected helps user to undrestand what happens, but also is needed for data minimisation validation.<br/>

**Preparation:**

#### 6.3.6.3 REQ-METRICS-3

**Requirement:** Metrics cadence, accuracy and storage time shall be described for the user.<br/>

**Objective:** Metrics storage consumes alot of storage, and also affects persons privacy as rarely the data is deleted on demand.<br/>

**Preparation:**

#### 6.3.6.4 REQ-METRICS-4

**Requirement:** Relevant system and connected element metrics such as CPU, memory, disk utilisation shall be tracked and reported.<br/>

**Objective:** Support users or administrators ability to detect compromised, misconfigured, or harmful connected elements through unusual, excessive, or risky patterns of use.<br/>

**Preparation:**

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

1. Have at lest one managed element as part of the system the product operates

2. Have at lest one managed element as part of the system the product operates

**Activities:**

#### 6.3.6.5 REQ-METRICS-5

**Requirement a:** System incidents, such as process and service crashes and restarts, shall be tracked and reported.<br/>

**Requirement b:** Managed element incidents, such as process and service crashes and restarts shall be tracked and reported.<br/>

**Objective:** Crashes are used to modify the program state. Abnormal crashes can be an indication of upcoming compromise.<br/>

**Preparation:**

#### 6.3.6.6 REQ-METRICS-6

**Requirement a:** Managed elements availabilities and statuses shall be tracked and reported.<br/>

**Requirement b:** System and provided service availabilities and statuses shall be tracked and reported.<br/>

**Objective:** Bad availability can be a indication of compromise.<br/>

**Preparation:**

#### 6.3.6.7 REQ-METRICS-7

**Requirement a:** Relevant databases in the product and storage health metrics like queries per second, latency and throughput shall be tracked and reported.<br/>

**Requirement b:** Relevant managed element database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.<br/>

**Objective:** Bad service quality can be a indication of compromise.<br/>

**Preparation:**

#### 6.3.6.8 REQ-METRICS-8

**Requirement:** Relevant networking metrics like throughput and protocol errors shall be tracked and reported.<br/>

**Objective:** When the errors stop and the throughput returns to nominal levels, the damage has already been done.<br/>

**Preparation:**

#### 6.3.6.9 REQ-METRICS-9

**Requirement:** GUI and API latencies and error rates shall be tracked and reported.<br/>

**Objective:** Wrong calls to the endpoints is an indication of compromise attempt.<br/>

**Preparation:**

#### 6.3.8.0 REQ-HA-0

**Requirement:** Expected availability shall be defined for each relevant system component.<br/>

**Objective:**

**Preparation:**

#### 6.3.8.1 REQ-HA-1

**Requirement:** System updates and changes shall be included in the availability time definition.<br/>

**Objective:** <br/>

**Preparation:**

#### 6.3.8.2 REQ-HA-2

**Requirement:** System shall tolerate loss of resources within the limits of the defined availability.<br/>

**Objective:** The customer understands how the sytem behaves undre different conditions and can make a disaster recovery plan for the operation.<br/>

**Preparation:**

#### 6.3.8.3 REQ-HA-3

**Requirement:** Recovery capabilities shall be made available in the technical documentation and are sufficient to implement the expected availability.<br/>

**Objective:** The customer understands how the sytem behaves undre different conditions and can make a disaster recovery plan for the operation.<br/>

**Preparation:** None <br/>