> 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.
@@ -810,6 +836,180 @@ The high availability d
## 6.1 General requirements assesments
## 6.1.1 Vulnerability handling tests
#### 6.1.1.0 REQ-EXPLOIT-0
**Objective**: NMS dependencies to Operating System essential security capabilities are documented.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**Verdict**:
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.1 REQ-EXPLOIT-1
**Objective**: Disclosure of new vulnerabilities in the operating system and its dependencies are proactively monitored.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**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. 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**:
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**:
1. References to to documentation sections.
#### 6.1.1.3 REQ-EXPLOIT-3
**Objective**: OS upgrade intructions makes it possible to obtain the set High Availability targets.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**Verdict**:
1. Pass if cross referencing OS 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.4 REQ-EXPLOIT-4
**Objective**: PwDE is free of known vulnerabilities at the time it is placed on the market.<br/>
**Preparation**:
1. Have the NMS product initialized and available with the default configuration and required credentials.
**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.
**Verdict**:
1. Pass if 90% of used identfiers and versions are matching
1. and no known vulnerabilities are found when cross referencing.
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.
#### 6.1.1.5 REQ-EXPLOIT-5
**Objective**: Disclosure of new vulnerabilities in the application dependencies are proactively monitored.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**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. Fail otherwise.
**Supporting Evidence**:
1. References to to documentation sections.
#### 6.1.1.6 REQ-EXPLOIT-6
**Objective**: Application design makes it possible to upgrade the OS while keeping the set High Availability targets.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**Verdict**:
1. Pass if cross referencing 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.7 REQ-EXPLOIT-7
**Objective**: Operating system dependencies and application dependencies are clearly separated in the provided SBOM.<br/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
**Verdict**:
1. Pass if system dependencies and application dependencies are clearly separated.
1. Fail otherwise.
**Supporting Evidence**:
1. References to to documentation sections.
#### 6.1.1.8 REQ-EXPLOIT-8 and REQ-EXPLOIT-9
**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/>
**Preparation**: None<br/>
**Activities**:
1. Study the technical documentation.
1. Study the SBOM.
**Verdict**:
1. Pass if provided SBOM identifiers are unique
1. and recognized in the industry
1. and cross referable to known vulnerability databases.
1. Fail otherwise.
**Supporting Evidence**:
1. References to to documentation sections.
## 6.2 Technical security requirement tests and assesments
### 6.2.5 REQ-TECH-5
@@ -1200,17 +1400,16 @@ The high availability d
1. Pointers to the documentation.
# Annex A (informative): Mapping with essential requirements of the CRA
> 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.
