5.2 Refactoring

-   **[REQ-TECH-1]** The product is shipped without undocumented interfaces.

-   **[REQ-TECH-2]** Any administrative action shall be recorded for audit purposes.

-   **[REQ-TECH-3]** A secure channel is used in transport.

-   **[REQ-TECH-4]** Cryptographic keys can be changed.

-   **[REQ-TECH-5]** All system components are synchronized to the same time.

-   **[REQ-TECH-6]** All system clocks are monitored.

-   **[REQ-TECH-4]** Cryptographic keys can be rotated.

-   **[REQ-TECH-5]** Cryptographic keys can be replaced with user controlled keys.

-   **[REQ-TECH-6]** All system components are synchronized to the same time.

-   **[REQ-TECH-7]** All system clocks are monitored.

**Table 5.2-1: Technical cybersecurity requirements**

**Table 5.2-1: Technical cybersecurity assesments and details**

| Requirement      | Assesment                                                                                                    |

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

| **[REQ-TECH-5]** |                                                                                                              |

| **[REQ-TECH-6]** |                                                                                                              |

<br />

The listed requirement shall be implemented, if the risk of the given factor is defined as follows.

When multiple factors define a different level, the lowest level shall be selected.

A product which risk factor is evaluated to be medium, shall implement both low and medium requirements.

A product which risk factor is evaluated to be high, shall implement all mapped requirements.

**Table 5.2-2: Technical cybersecurity requirements**

| Name         | [SRU]  | [Complexity] | [Segment] | [NIS2] |

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

| [REQ-TECH-0] | low    | low          | low       | low    |

| [REQ-TECH-1] | low    | low          | low       | low    |

| [REQ-TECH-2] | medium | medium       | medium    | medium |

| [REQ-TECH-3] | low    | low          | low       | low    |

| [REQ-TECH-4] | low    | low          | low       | low    |

| [REQ-TECH-5] | high   | medium       | n/a       | high   |

| [REQ-TECH-6] | high   | high         | medium    | medium |

| [REQ-TECH-7] | high   | high         | high      | high   |

### 5.2.1 Secure channel definition

| Appropriate cryptographic libraries are used | See [5.2.4 Appropriate cryptographic libraries](#524-appropriate-cryptographic-libraries) |

| Mutual trust                                 | All endpoints in a secure channel can cryptographically verify others.                    |

<br />

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

![Figure 5.2.1-1: Secure channel example with TLS](./media/52_secure_channel_example.drawio.png)

### 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 [\[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.

**Table 5.3.2-1: Mitigation requirements**

| Name           | ACC-L-0         | ACC-L-1               | ACC-L-2                  | ACC-L-3                                |

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

| Network        | Air gapped      | Single public endoint | Multiple endpoints       | Everything else                        |

| [REQ-TECH-0]   | Required        | Required              | Required                 | Required                               |

| [REQ-TECH-1]   | Required        | Required              | Required                 | Required                               |

| [REQ-TECH-2]   | Required        | Required              | Required                 | Required                               |

| [REQ-TECH-3]   | Self-signed TLS | TLS in the endpoint   | TLS in exposed endpoints | Technical documentation responsibility |

| [REQ-TECH-4]   | Required        | Required              | Required                 | Required                               |

| [REQ-INGEST-0] | Data signing    | Data signing          | Data signing             | Data signing                           |

| [REQ-INGEST-1] | Data signing    | Data signing          | Data signing             | Data signing                           |

<br />

| Name           | [SRU]  | [Complexity] | [Segment] | [NIS2] |

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

| [REQ-INGEST-0] | medium | medium       | medium    | medium |

| [REQ-INGEST-1] | high   | medium       | medium    | high   |

Note that in a closed system, where the confindentiality doesn't require transport encryption, the data integrity does require at least signing of the data set with cryptographically good enough keying.