@@ -517,7 +517,7 @@ This section contains technical security requirements for the product. Each gene
Each requirement has at least one concrete example that satisfies the requirements of the CRA.
Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these general requirements to [Section 4.5 Risk Factors](#45-risk-factors). The Risk Mitigations can include additional topic specific requirements.
General requirements:
Technical requirements:
-**[REQ-TECH-0]** An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
-**[REQ-TECH-1]** The product is shipped without undocumented interfaces.
-**[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 High Availability
Unwanted traffic in the interfaces can cause a denial of service from the managed elements.
### 5.3.x Logging
<mark>AMS: Luka and Bruno are working on this. Skip for now.</mark>
@@ -690,7 +686,6 @@ Manfacturer shall implement logging system features listed in the table below.
| [REQ-LOG-3] | Not required | Required |
| [REQ-LOG-4] | Not required | Required |
### 5.3.x 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.
@@ -725,38 +720,80 @@ Manfacturer shall implement monitoring system features as listed in the table be
Matching tests for these requirements are listed in [6.3.x Monitoring tests](#63x-monitoring-tests).
### 5.3.x 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.
The high availability d
-**[REQ-HA-0]** Expected availability is defined for each relevant system component.
-**[REQ-HA-1]** System tolerates loss of resources.
-**[REQ-HA-2]** Disaster recovery plan is available.
-**[REQ-HA-3]** System updates and changes are included in the availability definition.
-<mark>How to include protections against DDoS or similar?</mark>
- Unwanted traffic in the interfaces can cause a denial of service from the managed elements.
> This section should not add requirements that are not already specified in 5. Requirements Specifications.
@@ -771,21 +808,42 @@ Matching tests for these requirements are listed in [6.3.x Monitoring tests](#63
> 1. **Assignment of Verdict**: Defines the pass/fail criteria. The assessment is considered successful if the requirement’s protection goals are demonstrably met; it fails if unauthorized access, modification, or bypass is possible, or if required security capabilities are unsupported. (treshold)
> 1. **Supporting Evidence**: Lists the artefacts to be collected and documented, such as logs, configuration files, screenshots, vendor documentation, and test results. Evidence ensures traceability and allows independent review. (test or assesment output)
## 6.1 General requirements assesments
## 6.2 Technical security 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/>