Added AMS work plan as markers

### 5.2.4 Appropriate cryptographic libraries

<mark>AMS: Markku, Ivan and Claire are focusing on this. Skip for now.</mark>

Cryptographic libraries, primitivies and constructions shall follow ENISA's Agreed Cryptographic Mechanisms<a href="_ref_1">[1]</a>.

Manufacturer shall enable by default only the recommended designs that are fit for use-case. Any designs that are not fit for use-case may only be enabled after the user has been sufficiently informed of the security consequences in a manner that takes the use-case into account.

-   Transition plan towards recommended cryptographical impelmentation

-   Transition timeline

### 5.2.5 Software Bill of Materials

<mark>AMS: Stefane is working on this. Skip for now.</mark>

### 5.2.6 Remote Data Processing Systems

<mark>AMS: August and Daniel are working on this. Skip for now.</mark>

## 5.3 Risk Mitigations

The following sections describe how technical security requirement in previous [Section 5.2](#52-technical-security-requirements-specifications) are mapped to the risk factors in [Section 4.5 Risk Factors](#45-risk-factors).

> -   How the system users identities should be maintained

> -   How the least amount of privileges principles are enforced to user groups

<mark>AMS: Killian and Mohammad are focusing on this. Skip for now.</mark>

-   **[REQ-ID-0]** An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.

### 5.3.2 Mitigations for ingested data integrity and confidentiality

### 5.3.4 Secure updates

<mark>AMS: Srinath and Mohamad are focusing on this. Skip for now.</mark>

-   **[REQ-UPDATES-0]** Authenticate the source of the update package with.

-   **[REQ-UPDATES-1]** Verify integrity of the upddate before installation (hash checks).

-   **[REQ-UPDATES-2]** Use secure channels for update delivery (e.g., TLS).

### 5.3.x Logging

<mark>AMS: Luka and Bruno are working on this. Skip for now.</mark>

-   **[REQ-LOG-0]** All system components are synchronized to a same time.

-   **[REQ-LOG-1]** From the system perspective, logs and traces are stored into a write only service or endpoint.

-   **[REQ-LOG-2]** The write only log or tracing storage is deployed outside of the system deployment context.

Reasoning for monitoring requirements is often justified by data integrity protection. Faults can not be detected, if an attacker can hide it's existense.

General:

General requirements:

-   **[REQ-MON-0]** Collected and stored metrics data can not be altered.

-   **[REQ-MON-1]** Historical metrics data import overwriting an existing data point is noticed.

> NOTE: [REQ-MON-2], [REQ-MON-3] and [REQ-MON-4] requirements apply to all collected metrics.

Availability and uptime:

Availability and uptime requirements:

-   **[REQ-MON-5]** Relevant system and connected element metrics like CPU, memory, disk utilisation are tracked and reported.

-   **[REQ-MON-6a]** System process and service crashes and restarts are tracked and reported.

-   **[REQ-MON-8b]** Relevant managed element database and storage health metrics like queries per second, latency and throughput are tracked and reported.

-   **[REQ-MON-9]** Relevant networking metrics like throughput and protocol errros are tracked and reported.

Application monitoring:

Application monitoring requirements:

-   **[REQ-MON-10]** GUI and API latencies are tracked and reported.

-   **[REQ-MON-11]** GUI and API error rates are tracked and reported.

[REQ-MON-10]: (#63x10-req-mon-10)

[REQ-MON-11]: (#63x11-req-mon-11)

Matching tests for these requirements are listed in [6.3.x Monitoring tests](#63x-monitoring-tests).

# 6 Conformity assesments and tests

> This section should not add requirements that are not already specified in 5. Requirements Specifications.

### 6.3.x Logging tests

| Requirement  | Assesment                                                                                |

| Requirement  | Objective                                                                                |

| ------------ | ---------------------------------------------------------------------------------------- |

| [REQ-LOG-0]  | All system clocks are synchronized to a NTP server or similar.                           |

| [REQ-LOG-1]  | From the running process, it is impossible to overwrite the stored log output.           |

#### 6.3.x.8 REQ-MON-8

**Reference**: **[REQ-MON-8a]** and **[REQ-MON-8b]** <br/>

**Objective**: Relevant system database and storage health metrics like queries per second, latency and throughput are tracked and reported.<br/>

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

**Objective a**: Relevant system database and storage health metrics like queries per second, latency and throughput are tracked and reported.<br/>

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

**Preparation**:

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

| Confidentiality protection                      | [5.3.2]                                                           |

| Integrity protection for data and configuration | [5.3.2], [5.3.3], [5.3.x Monitoring](#53x-monitoring)             |

| Data minimization                               |                                                                   |

| Availability protection                         |                                                                   |

| Availability protection                         | [5.3.x High Availability](#53x-high-availability)                 |

| Minimize impact on other devices or services    | [5.3.x High Availability](#53x-high-availability)                 |

| Limit attack surface                            |                                                                   |

| Exploit mitigation by limiting incident impact  |                                                                   |

> Describe how to decide if residual risks are tolerable.

<mark>AMS: Pol and Santeri? focusing on vulnerability handling</mark>

## C.2 Risk Assessment

> For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security profiles.

-   Proper operating system

    -   **Rationale:** A network management system requires a trustworthy operating system to perform its functions.

    -   [A-POS-L-1]: The operating system is assumed to be trustworthy.

    -   [A-POS-L-2]: The operating system provides and enforces process isolation

    -   [A-OS-L-1]: The operating system is assumed to be trustworthy.

    -   [A-OS-L-2]: The operating system provides and enforces process isolation

-   Proper administrator

    -   **Rationale:** A network management system requires effective administration to perform its functions.

    -   [A-PA-L-1]: The administrator is assumed to be trustworthy.

    -   [A-PA-L-2]: The administrator is limited to protect against accidental misconfiguration.

    -   [A-PA-L-3]: The administrator is severely limited to protect against intentional misconfiguration.

    -   [A-ADMIN-L-1]: The administrator is assumed to be trustworthy.

    -   [A-ADMIN-L-2]: The administrator is limited to protect against accidental misconfiguration.

    -   [A-ADMIN-L-3]: The administrator is severely limited to protect against intentional misconfiguration.

-   Not being attacked by a state actor

-   Not using sophisticated or expensive hardware snooping techniques