Replaced manufacturer with the product

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

-   **[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-0b]** The product shall have only discoverable vulnerabilities whose age is consistent with the 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.

Recognising 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.

Recognising 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.

-   **[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 instructions which makes it possible to obtain the set High Availability targets.

-   **[REQ-EXPLOIT-3]** The product 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.

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

### 5.2.1 Secure channel

A **secure channel** referred in [REQ-TECH-2] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the foreseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].

A **secure channel** referred in [REQ-TECH-2] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS.

When TLS is not used to encrypt the traffic in the secure channel, manufacturer shall provide detailed description how the channel is secured in the technical documentation.

The chosen method shall follow the intent in the CRA by protecting the data transfer, and protect the confidentiality and integrity of the data according to the requirements of the foreseeable use.

- **[REQ-CRYPTO-0]** The product shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the foreseeable use.

- **[REQ-CRYPTO-1]** The product shall ensure that the channel can not be impaired by downgrading it [i.10].

- **[REQ-CRYPTO-2]** The product shall provide detailed description how the channel is secured in the technical documentation.

- **[REQ-CRYPTO-3]** The product shall protect the data transfer, the confidentiality and the integrity of the data according to the requirements of the foreseeable use.

Mutual trust is in plural form not exluding IP Multicast or Anycast usage if implemented.

### 5.2.2 Cryptographic key intialisation and rotation

Manufacturer shall design and implement support for on-demand rotation of cryptographic keys.

The technical documentation shall include:

1. instructions on how to intialise trust

1. how to use the trust to accept managed elements to the network

1. how to the established trust to rotate all keys

* **[REQ-CRYPTO-4]** The product shall support and implement a on-demand rotation of cryptographic keys.

* **[REQ-CRYPTO-5]** The product shall support to initialisation of trust.

* **[REQ-CRYPTO-6]** The product shall support cryptographic mechanisms used to accept managed elements to the network.

* **[REQ-CRYPTO-7]** The product shall support a method to replace or update the cryptographic keys in the system and in the managed elements.

### 5.2.3 Network segmentation

### 5.2.4 State-of-the-art cryptographic libraries

Cryptographic libraries, primitivies and constructions shall follow ENISA's Agreed Cryptographic Mechanisms[\[1\]](#_ref_1).

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.

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.

* **[REQ-CRYPTO-8]** The product shall enable by default only the recommended designs that are fit for use-case.

As an example, when using TLS to protect the transport, only TLS v1.3 shall be used with one of the three cipher suites: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256 or TLS_AES_128_CCM_SHA256.

For medium risk:

- **[REQ-INGEST-0]** The manufacturer shall protect the system against data poisoning or other adversial attacks.

- **[REQ-INGEST-0]** The product shall protect the system against data poisoning or other adversial attacks.

- **[REQ-INGEST-1]** The collected network element monitoring data shall be verifiable.

Every time a data is transported through an undefined connection, manufacturer shall take great care, that integrity and confidentiality of the data is not compromised.

Every time a data is transported through an undefined connection, the product needs to be certain, that integrity and confidentiality of the data is not compromised.

Confidentiality can be achieved different ways in different scenarios.

Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this document, the following requirements shall be implemented.

### 6.1.0.0 REQ-GEN-0

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

**Objective:** Manufacturer declares the targeted market what is considered to be foreseeable use of the product.<br/>

**Objective:** The product is fit for the targeted market what is considered to be foreseeable use of the product.<br/>

**Preparation:** None<br/>

**Activities:**

#### 6.1.1.0 REQ-EXPLOIT-0

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

**Preparation:**

**Verdict:**

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

1. Pass if the 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.

1. Pass if there are no unknown metrics displayed or collected.

1. Pass if the metric well-known, like CPU usage, but undocumented.

1. Pass if the metric is recognised and pointer to the documentation is provided (managed element manufacturer's reference documentation e.g.).

1. Fail otherwise.

2. Pass if the metric is recognised and pointer to the documentation is provided (the product's reference documentation).

3. Fail otherwise.

**Supporting Evidence:**

## C.2 Risk assessment methodology

Risk levels for each factors are determined by reading the descriptions for each risk factor and choosing the one that most accurately represents the highest risk for the intended purpose and reasonably foreseeable use and misuse of the product, as specified by the manufacturer.

Risk levels for each factors are determined by reading the descriptions for each risk factor and choosing the one that most accurately represents the highest risk for the intended purpose and reasonably foreseeable use and misuse of the product, as specified by the product.

The risks can be divided to likelihood and impact, but they can also be presented as a whole.

When likelihood and impact is presented, only high and low evaluation is available.