Fixed section numbering and added placeholders

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

| Requirement         | Objective                                                                                                             |

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

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

| **[REQ-EXPLOIT-4]** | PwDE 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-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.                                |

### 5.1.2 Secure design, development and production

<mark>TODO</mark>

### 5.1.3 Product lifecycle management

<mark>TODO</mark>

### 5.1.4 Product vulneravility management process

<mark>TODO</mark>

## 5.2 Technical security requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

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

### 5.3.5 Logging

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

| [REQ-LOG-3]           | Not required  | Required    |

| [REQ-LOG-4]           | Not required  | Required    |

### 5.3.x Monitoring

### 5.3.6 Monitoring

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

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

### 5.3.x High Availability

### 5.3.7 Data minimization

-   **[REQ-MON-2]** Metrics name, purpose, and value interpretation are described for the user.

-   **[REQ-MON-3]** Metrics cadence, accuracy and storage time are described for the user.

-   **[REQ-MON-4]** System does not collect metrics that are not directly used in operative purposes.

### 5.3.8 High Availability

High availability starts from the running process.

In a modern cluster runtime environment used in large system deployments, the process rarely can control the loss of underlying resources.

Administrative actions can shutdown the node without preseeding announcement unexpectedly.

It is up to the software design to tolerate these interruptions.

Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targetted service availability if implemented correctly.

Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targetted service availability if implemented correctly and self healing system can launch a replacement within the given time window.

The high availability d

The high availability requirements are:

-   **[REQ-HA-0]** Expected availability is defined for each relevant system component.

-   **[REQ-HA-1]** System tolerates loss of resources.

1. References to to documentation sections.

#### 6.1.1.7 REQ-EXPLOIT-7

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

1. References to to documentation sections.

## 6.2 Technical security requirement tests and assesments

### 6.2.5 REQ-TECH-5

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

| CRA requirement                                 | Technical security requirements(s)                                                      |

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

| No known exploitable vulnerabilities            | [5.1.1](#511-no-known-exploitable-vulnerabilities)                |

| Secure design, development, production          |                                                                   |

| Secure by default configuration                 | [5.2.4]                                                           |

| Secure updates                                  | [5.3.4 Secure updates](#534-secure-updates)                       |

| Authentication and access control mechanisms    | [5.3.1]                                                           |

| 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                         | [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                            |                                                                   |

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

| No known exploitable vulnerabilities            | [5.1.1 No known exploitable vulnerabilities]                                            |

| Secure design, development, production          | [5.1.2 Secure design, development and production], [5.1.3 Product lifecycle management] |

| Secure by default configuration                 | [5.2.4 Appropriate cryptographic libraries]                                             |

| Secure updates                                  | [5.3.4 Secure updates]                                                                  |

| Authentication and access control mechanisms    | [5.3.1 Mitigations for user identity integrity]                                         |

| Confidentiality protection                      | [5.3.2 Mitigations for ingested data integrity and confidentiality]                     |

| Integrity protection for data and configuration | [5.3.2], [5.3.3], [5.3.6 Monitoring]                                                    |

| Data minimization                               | [5.3.7 Data minimization]                                                               |

| Availability protection                         | [5.3.8 High Availability]                                                               |

| Minimize impact on other devices or services    | [5.3.8 High Availability]                                                               |

| Limit attack surface                            | [5.1.4 Product vulneravility management process]                                        |

| Exploit mitigation by limiting incident impact  |                                                                                         |

| Logging and monitoring mechanisms               | [5.3.x Logging](#53x-logging) [5.3.x Monitoring](#53x-monitoring) |

| Logging and monitoring mechanisms               | [5.3.5 Logging], [5.3.6 Monitoring]                                                     |

| Secure deletion and data transfer               |                                                                                         |

[5.2.4]: #524-appropriate-cryptographic-libraries

[5.1.1 No known exploitable vulnerabilities]: #511-no-known-exploitable-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

[5.2.1 Secure channel definition]: #521-secure-channel-definition

[5.2.2 Cryptographic key intialization and rotation]: #522-cryptographic-key-intialization-and-rotation

[5.2.3 Network segmentation]: #523-network-segmentation

[5.2.4 Appropriate cryptographic libraries]: #524-appropriate-cryptographic-libraries

[5.2.5 Software Bill of Materials]: #525-software-bill-of-materials

[5.2.6 Remote Data Processing Systems]:#526-remote-data-processing-system

[5.3.1 Mitigations for user identity integrity]: #531-mitigations-for-user-identity-integrity

[5.3.1]: #531-mitigations-for-user-identity-integrity

[5.3.2 Mitigations for ingested data integrity and confidentiality]: #532-mitigations-for-ingested-data-integrity-and-confidentiality

[5.3.2]: #532-mitigations-for-ingested-data-integrity-and-confidentiality

[5.3.3 Mitigations for managed device configuration integrity and confidentiality]: #533-mitigations-for-managed-device-configuration-integrity-and-confidentiality

[5.3.3]: #533-mitigations-for-managed-device-configuration-integrity-and-confidentiality

[5.3.4 Secure updates]: #534-secure-updates

[5.3.5 Logging]: #535-logging

[5.3.6 Monitoring]: #536-monitoring

[5.3.7 Data minimization]: #537-data-minimization

[5.3.8 High Availability]: #538-high-availability

# Annex B (informative): Relationship between the present document and any related ETSI standards (if any)