Merge branch 'know-vulns' into 'development'

The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with the present document.

-   **[REQ-GEN-0]:** Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.

-   **[REQ-GEN-1]:** Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

-   **[REQ-GEN-0]:** The product shall have technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.

-   **[REQ-GEN-1]:** The product shall have technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

-   **[REQ-GEN-2]:** The product dependencies to Operating System essential security capabilities are documented.

**Table 5.1-1: Generic requirements**

| Requirement     | Assesment                                                                                                     |

| :-------------- | :------------------------------------------------------------------------------------------------------------ |

| **[REQ-GEN-0]** | Technical documentation exists, is available for national MSAs and has product related risk factors declared. |

| **[REQ-GEN-1]** | National MSAs are able to validate the system design comformity without a deployment.                         |

<br />

System operation is always an interplay of multiple components.

Modern software design can rarely ignore impact of the changes to other components.

### 5.1.1 No known exploitable vulnerabilities

### 5.1.1 No known exploited vulnerabilities

If the NMS deliverable contains or requires an operating system it is important to keep the whole system up to date.

Depending on the chosen delivery method the maintenance of the OS can be with the customer of the product.

Note that a container has always an operating system.

**Table 5.1.1-1: Exploitable requirements - 1**

| Requirement         | Objective                                                                                                 |

| :------------------ | :-------------------------------------------------------------------------------------------------------- |

| **[REQ-EXPLOIT-0]** | NMS dependencies to Operating System essential security capabilities are documented.                      |

| **[REQ-EXPLOIT-1]** | Disclosure of new vulnerabilities in the operating system and its dependencies are proactively monitored. |

| **[REQ-EXPLOIT-2]** | Instructions how to handle the Operating System upgrades are provided.                                    |

| **[REQ-EXPLOIT-3]** | OS upgrade intructions makes it possible to obtain the set High Availability targets.                     |

If automatable and freely-usable vulnerability scanners are available the product shall satisfy the following with respect to the most comprehensive of such scanners.

<br />

-   **[REQ-EXPLOIT-0a]** The product shall have no vulnerabilities discovered by scans.

-   **[REQ-EXPLOIT-0b]** The product shall have only discoverable vulnerabilities whose age is consistent with the manufacturer's documentation of how long vulnerabilities may go unfixed after public disclosure.

-   **[REQ-EXPLOIT-0c]** For each detected vulnerability, the product shall have publicly available documentation explaining how the risk has been mitigated.

System operation is always an interplay of multiple components.

Modern software design can rarely ignore impact of the changes to other components.

More about [High Availability](#53x-high-availability) in its dedicated chapter.

Recognizing that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known vulnerabilities both when first made available and when first used by a consumer, the manufacturer shall ensure that the product can be updated at the time of first use to address all known exploited vulnerabilities which were discovered after the product's placement on the market and before that first use.

**Table 5.1.1-2: Exploitable requirements - 2**

-   **[REQ-EXPLOIT-1a]** The product shall be accompanied by documentation describing how the product may be securely updated,

-   **[REQ-EXPLOIT-1b]** including how to update the product prior to, or as part of, first use.

-   **[REQ-EXPLOIT-2]** The product shall have OS and Application upgrade intructions which makes it possible to obtain the set High Availability targets.

| Requirement         | Objective                                                                                                             |

| :------------------ | :-------------------------------------------------------------------------------------------------------------------- |

| **[REQ-EXPLOIT-4]** | Product is free of known vulnerabilities at the time it is placed on the market.                                      |

| **[REQ-EXPLOIT-5]** | Disclosure of new vulnerabilities in the application dependencies are proactively monitored.                          |

| **[REQ-EXPLOIT-6]** | Application design makes it possible to upgrade the OS while keeping the set High Availability targets.               |

| **[REQ-EXPLOIT-7]** | Operating system dependencies and application dependencies are clearly separated in the provided SBOM.                |

| **[REQ-EXPLOIT-8]** | Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM. |

| **[REQ-EXPLOIT-9]** | The SBOM identifier format is consistent with common vulnerability handling standards.                                |

<br />

More about [High Availability](#53x-high-availability) in its dedicated chapter.

### 5.1.2 Secure design, development and production

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

-   **[REQ-SBOM-0]:** Operating system dependencies and application dependencies are clearly separated in the provided SBOM.

-   **[REQ-SBOM-1a]:** Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM.

-   **[REQ-SBOM-1b]:** The SBOM identifier format is consistent with common vulnerability handling standards.

### 5.2.6 Remote Data Processing Systems

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

## 6.1 General requirements assesments

## 6.1.1 Vulnerability handling tests

#### 6.1.1.0 REQ-EXPLOIT-0

### 6.1.0.0 REQ-GENERAL-2

**Objective:** NMS dependencies to Operating System essential cybersecurity capabilities are documented.<br/>

**Preparation:** None<br/>

**Activities:**

-   **[REQ-GEN-0]:** The product shall have technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.

1. Study the technical documentation.

### 6.1.0.1 REQ-GENERAL-2

**Verdict:**

-   **[REQ-GEN-1]:** The product shall have technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

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.1.0.2 REQ-GENERAL-2

#### 6.1.1.1 REQ-EXPLOIT-1

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

**Objective:** The product dependencies to Operating System essential security capabilities are documented.<br/>

**Preparation:** None<br/>

**Activities:**

**Verdict:**

1. Pass if manufacturer process to track new vulnerabilities is documented

1. and how existing vulnerabilities are tracked in the already released products is described.

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.1.1.2 REQ-EXPLOIT-2

**Objective:** Instructions how to handle the Operating System upgrades are provided.<br/>

**Preparation:** None<br/>

**Activities:**

1. Study the technical documentation.

**Verdict:**

### 6.1.1 No known exploited vulnerabilities tests

1. Pass if OS upgrade instructions are provided

1. and the instructions are noting the custom requirements of the application, if any.

1. Fail otherwise.

**Supporting Evidence:**

#### 6.1.1.0 REQ-EXPLOIT-0

1. References to to documentation sections.

**Requirement a:** The product shall have no vulnerabilities discovered by scans.<br/>

**Requirement b:** The product shall have only discoverable vulnerabilities whose age is consistent with the manufacturer's documentation of how long vulnerabilities may go unfixed after public disclosure.<br/>

**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 operating system and its dependencies are proactively monitored.<br/>

**Preparation:**

#### 6.1.1.3 REQ-EXPLOIT-3

1. Select up to three vulnerability scanners meeting the requirements

**Objective:** OS upgrade intructions makes it possible to obtain the set High Availability targets.<br/>

**Preparation:** None<br/>

**Activities:**

1. Study the technical documentation.

1. On a new product, carry out a secure update, run the selected scanners on the product, and examine the documentation for any reported vulnerabilities

**Verdict:**

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

1. Pass if manufacturer process to track new vulnerabilities is documented

1. and how existing vulnerabilities are tracked in the already released products is described.

1. and no vulnerabilities found, or all reported vulnerabilities satisfy either the age or documentation requirement.

1. Fail otherwise.

**Supporting Evidence:**

1. References to to documentation sections.

1. Documented vulnerability handling policy.

1. List of vulnerability scanners selected.

1. Reports from each scanner.

1. Correlation of reports of discovered vulnerabilities with documentation of mitigations.

#### 6.1.1.4 REQ-EXPLOIT-4

#### 6.1.1.1 REQ-EXPLOIT-1

**Objective:** Product is free of known vulnerabilities at the time it is placed on the market.<br/>

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

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

1. Examine public or private vulnerability information sources and select a recently fixed vulnerability (preferably the most recently fixed).

**Activities:**

1. Study the technical documentation.

1. Programmatically examine all of the installed application packages and dependencies.

1. Programmatically examine all of the installed operating system packages and dependencies.

1. Cross-reference the output to the latest data from the known vulnerability databases.

1. On a new product, carry out the initial secure update, scan the product to see if a recently fixed vulnerability has been fixed on the product, and examine the documentation for the required info.

**Verdict:**

1. Pass if 90% of used identfiers and versions are matching

1. and no known vulnerabilities are found when cross referencing.

1. Pass if the secure update completes successfully

1. and the most recently fixed vulnerability is fixed

1. and the documentation includes all the required information

1. and the instructions are noting the custom requirements of the application, if any.

1. Fail otherwise.

**Supporting Evidence:**

1. Description of what tools were used and how the evaluation was executed.

1. List of which vulnerability databases were used and what is the latest data used in the test.

1. Statistics about dependency identifier hit rates.

1. Documentation of vulnerability handling

1. Documentation of how to securely update the product

1. The report for the selected vulnerability

1. Description of how to scan for the vulnerability

1. Log of vulnerability scan results

#### 6.1.1.5 REQ-EXPLOIT-5

#### 6.1.1.2 REQ-EXPLOIT-2

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

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

**Objective:** <br/>

**Preparation:** None<br/>

**Activities:**

**Verdict:**

1. Pass if manufacturer process to track new application vulnerabilities is documented

1. and how existing vulnerabilities are tracked in the already released products is described.

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

1. Fail otherwise.

**Supporting Evidence:**

1. References to to documentation sections.

#### 6.1.1.6 REQ-EXPLOIT-6

## 6.2 Technical cybersecurity requirement tests and assesments

**Objective:** Application design makes it possible to upgrade the OS while keeping the set High Availability targets.<br/>

**Preparation:** None<br/>

**Activities:**

### 6.2.0.5 REQ-TECH-5

1. Study the technical documentation.

**Verdict:**

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

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

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

1. Fail otherwise.

#### 6.2.0.6 REQ-TECH-6

**Supporting Evidence:**

**Objective:** All system clocks, including the managed elements, are being tracked.<br/>

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

1. References to to documentation sections.

**Objective:** System clock deviation is available as a metric.<br/>

**Preparation:**

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

#### 6.1.1.7 REQ-EXPLOIT-7

#### 6.2.5.0 REQ-SBOM-0

**Objective:** Operating system dependencies and application dependencies are clearly separated in the provided SBOM.<br/>

**Preparation:** None<br/>

1. References to to documentation sections.

#### 6.1.1.8 REQ-EXPLOIT-8 and REQ-EXPLOIT-9

#### 6.2.5.1 REQ-SBOM-1a and REQ-SBOM-1b

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

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

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

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

**Preparation:** None<br/>

**Activities:**

1. References to to documentation sections.

## 6.2 Technical cybersecurity requirement tests and assesments

### 6.2.5 REQ-TECH-5

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

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

### 6.2.6 REQ-TECH-6

**Objective:** All system clocks, including the managed elements, are being tracked.<br/>

**Preparation:** <br/>

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

**Objective:** System clock deviation is available as a metric.<br/>

**Preparation:**

**Activities:** <br/>

**Verdict:** <br/>

**Supporting Evidence:** <br/>

## 6.3 Risk mitigations tests

### 6.3.5 Logging tests

<br />

[5.1 General]: #51-general

[5.1.1 No known exploitable vulnerabilities]: #511-no-known-exploitable-vulnerabilities

[5.1.1 No known exploited vulnerabilities]: #511-no-known-exploited-vulnerabilities

[5.1.2 Secure design, development and production]: #512-secure-design-development-and-production

[5.1.3 Product lifecycle management]: #513-product-lifecycle-management

[5.1.4 Product vulneravility management process]: #514-product-vulneravility-management-process

| Section                                                                            |  Content status                   |  Tests status                   |

| :--------------------------------------------------------------------------------- | :-------------------------------- | :------------------------------ |

| [5.1 General]                                                                      | will be ammended with new content | todo                            |

| [5.1.1 No known exploitable vulnerabilities]                                       | ready for review                  | todo                            |

| [5.1.1 No known exploited vulnerabilities]                                         | ready for review                  | ready for review                |

| [5.1.2 Secure design, development and production]                                  | todo                              | todo                            |

| [5.1.3 Product lifecycle management]                                               | todo                              | todo                            |

| [5.1.4 Product vulneravility management process]                                   | todo                              | todo                            |