@@ -1158,71 +1158,62 @@ The product shall implement methods of detecting and mitigating denial of servic
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.13 ER-AVAI: Availability
## 5.10 Availability protection
#### 5.2.13.1 Cybersecurity requirement
### 5.10.1 Overview
The product shall protect the availability of essential and core functions.
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).
#### 5.2.13.2 MI-WDOG: Watchdog and self-initiated reset
### 5.10.2 REQ-AP-01 (MI-FDRP) Fast packet drop
The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.
#### 5.10.2.1 Requirement
* Reference: ER-AVAI
* Objective: Availability
* Preparation: Document the conditions that indicate the product cannot perform its functions
* Activities: Cause each of the conditions to occur and observe whether the product resets
* Verdict: Every condition triggers an automatic reset => PASS, otherwise FAIL
* Evidence: Documentation, log messages
The product shall check each incoming packet for validity - at minimum frame length, header fields, and destination address - in order from least to most computationally expensive, and shall drop invalid packets before further processing. The check sequence and its rationale shall be documented.
#### 5.2.13.3 MI-NTFY: Watchdog and notification of host
#### 5.10.2.2 Applicability
The product shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions and a way for the host to reset the product.
TODO
* Reference: ER-AVAI
* Objective: Availability
* Preparation: Document the conditions that indicate the product cannot perform its functions
* Activities: Cause each of the conditions to occur and observe whether the product notifies the host system
* Verdict: Every condition triggers a notification to the host => PASS, otherwise FAIL
* Evidence: Documentation, log messages
### 5.10.3 REQ-AP-02 (MI-LMEM) Limit memory usage
### 5.2.13.4 MI-FDRP: Fast packet drop
#### 5.10.3.1 Requirement
The product shall check each incoming packet for validity - at minimum frame length, header fields, and destination address - in order from least to most computationally expensive, and shall drop invalid packets before further processing. The check sequence and its rationale shall be documented.
The product shall enforce documented limits on internal resources consumed by received data (e.g. packet buffers, receive queues, descriptor rings). When a limit is reached, the product shall drop new incoming data without crashing or corrupting existing state.
- Reference: ER-AVAI
#### 5.10.3.2 Applicability
- Objective: Availability
TODO
---
### 5.10.4 REQ-AP-03 (MI-DOST-1) Document risk transfer to operational environment for denial of service
### 5.2.13.5 MI-LMEM: Limit memory usage
#### 5.10.4.1 Requirement
The product shall enforce documented limits on internal resources consumed by received data (e.g. packet buffers, receive queues, descriptor rings). When a limit is reached, the product shall drop new incoming data without crashing or corrupting existing state.
1.**REQ-AP-03 (MI-DOST-1)-1** The product shall be accompanied by documentation informing the user that denial-of-service protection must be provided by the environment, and
2.**REQ-AP-03 (MI-DOST-1)-2** documentation shall be in a form appropriate for a typical user for the intended purpose of the product.
- Reference: ER-AVAI
#### 5.10.4.2 Applicability
- Objective: Availability
TODO
---
### 5.10.5 REQ-AP-04 (MI-WDOG): Watchdog and self-initiated reset
### 5.2.13.6 MI-FAIR: Fair resource usage and prioritisation
#### 5.10.5.1 Requirement
The product shall prevent any single source of input from monopolising processing resources and shall prioritise at least one class of input (e.g. host commands, management traffic) over others under contention. The prioritisation mechanism and its default configuration shall be documented.
The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.
- Reference: ER-AVAI
#### 5.10.5.2 Applicability
- Objective: Availability
TODO
---
### 5.10.6 REQ-AP-05 (MI-NTFY): Watchdog and notification of host
### 5.2.13.7 MI-DOST: Document risk transfer to operational environment for denial of service
#### 5.10.6.1 Requirement
The product shall be accompanied by documentation describing what denial-of-service protections the product provides and what protections the operational environment shall provide.
The product shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions and provide a method for the host to reset the product.
- Reference: ER-AVAI
#### 5.10.6.2 Applicability
- Objective: Availability
TODO
### 5.2.14 ER-LMAS: Minimize exposed interfaces
@@ -2159,133 +2150,153 @@ Outside of the core functionality, the default set size of data that needs to be
> Example DM-01-3: The product is purpose-built for high level application co-operation and participates on the content delivery network function by storing most frequent replies in the network interface volatile memory. The replies are served directly from the memory without relying the request forward. Key information and metrics are collected and relied for the application.
### 6.2.13.4 MI-FDRP assessment
## 6.10 Availability protection
### 6.10.1 Overview
**[MI-FDRP]** Verify the product performs ordered validity checks on incoming packets and drops invalid packets before further processing.
This clause provides assessment for the requirements in 5.14 relating to CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).
#### Activities
### 6.10.2 REQ-AP-01 (MI-FDRP) Fast packet drop
Verify:
#### 6.10.2.1 Objective
- The documentation describes the packet-processing pipeline, including the sequence of validity checks and the rationale for their ordering.
- The documented ordering applies less computationally expensive checks (e.g. frame length, header field validation) before more expensive checks (e.g. deep packet inspection, cryptographic verification).
- Packets with invalid frame lengths (below minimum and above maximum for the link-layer protocol) are dropped before further processing.
- Packets with invalid frame header fields (e.g. malformed protocol version, incorrect type, invalid checksum) are dropped at the header validation stage.
- Packets addressed to a destination other than the product's configured address are dropped (with promiscuous mode disabled).
- Under sustained high-rate invalid traffic, resource consumption remains bounded and valid packet processing is not degraded.
Maintain product availability during denial-of-service attacks.
#### Verdict
#### 6.10.2.2 Preparation
Pass if:
Using packet generation software to bypass operating system level interference, create a selection of invalid packets and enable some type of instrumentation or logging in the packet validity checking code.
- The documentation describes the packet-processing pipeline with an ordered sequence of validity checks and a rationale;
- Invalid frame lengths, invalid header fields, and misaddressed packets are each dropped before further processing;
- Under sustained invalid traffic, resource consumption remains bounded and valid packet processing is not degraded.
#### 6.10.2.3 Activities
Fail otherwise.
For each invalid packet,
#### Supporting evidence
1. send the packet to the product, and
2. record the checks it makes and its use of system resources before it drops the packet
- Packet-processing pipeline documentation, including check ordering and rationale;
- Description of each invalid-packet test case and the specific invalidity injected;
- Packet capture or log showing the point at which each invalid packet was dropped;
- CPU and memory utilisation measurements during sustained invalid-traffic testing;
- Evidence that valid packet processing was not degraded during the test.
#### 6.10.2.4 Verdict
PASS if **all** of the following are fulfilled:
### 6.2.13.5 MI-LMEM assessment
For each invalid packet,
**[MI-LMEM]** Verify the product enforces documented limits on internal resources consumed by received data and handles limit conditions gracefully.
* the packet did not use resources that were not reasonably required to reject the packet, and
* the packet was rejected.
#### Activities
Otherwise FAIL
Verify:
#### 6.10.2.5 Evidence
- The documentation identifies all internal resources consumed by received data (e.g. packet buffers, receive queues, descriptor rings) and specifies a limit for each.
- For each identified resource, external input designed to exhaust the documented limit causes the product to drop new incoming data without crashing or corrupting existing state.
- After the load subsides, the product recovers normal operation without requiring a reboot or manual intervention.
* Invalid packets and descriptions
* Logs of processing
* Annotations explaining why the order of operations is the most efficient reasonable way to process the packet
#### Verdict
### 6.10.3 REQ-AP-02 (MI-LMEM) Limit memory usage
Pass if:
#### 6.10.3.1 Objective
- The documentation identifies all internal resources consumed by received data and specifies a limit for each;
- The product drops new incoming data when each limit is reached without crashing or corrupting existing state;
- The product recovers normal operation after the load subsides.
Maintain product availability during denial-of-service attacks.
Fail otherwise.
#### 6.10.3.2 Preparation
#### Supporting evidence
Identify input fields from untrusted input that are used to calculate the size of memory allocations, and create a set of inputs that, if processed as fast as possible, would significantly degrade the function of the product due to overallocation of memory.
- Documentation identifying each resource, its limit, and the rationale;
- Description of each exhaustion test case and the method used to generate load;
- Logs or observations demonstrating the product's behaviour when each limit was reached;
- Evidence that the product recovered normal operation after each test.
#### 6.10.3.3 Activities
For each set of inputs,
1. send the input to the product,
2. while simultaneously measuring the availability of the product functions.
### 6.2.13.6 MI-FAIR assessment
#### 6.10.3.4 Verdict
**[MI-FAIR]** Verify the product prevents any single input source from monopolising processing resources and prioritises at least one class of input over others under contention.
PASS if for each set of inputs, the product functions remain acceptably available.
#### Activities
Otherwise FAIL
Verify:
#### 6.10.3.5 Evidence
- The documentation describes the fairness and prioritisation mechanisms, including the default configuration and any user-configurable parameters.
- Under sustained concurrent load on at least two input sources, no single source completely starves another of processing resources.
- The prioritised class of input receives preferential treatment under contention, consistent with the documented mechanism.
- If the product supports user-configurable prioritisation, changes to the configuration take effect as documented.
* Set of inputs
* Logs of measurements
* Explanation of availability metrics
#### Verdict
### 6.10.4 REQ-AP-03 (MI-DOST-1) Document risk transfer to operational environment for denial of service
Pass if:
#### 6.10.4.1 Objective
- The documentation describes the fairness and prioritisation mechanisms and their default configuration;
- Under sustained concurrent load, no single input source completely starves another;
- The prioritised class receives preferential treatment consistent with the documented mechanism;
- User-configurable prioritisation changes take effect as documented (where applicable).
Maintain product availability during denial-of-service attacks.
Fail otherwise.
#### 6.10.4.2 Preparation
#### Supporting evidence
None
- Documentation of fairness and prioritisation mechanisms;
- Description of each test scenario, including input sources and traffic rates;
- Throughput and latency measurements for each input source during concurrent-load testing;
- Evidence that user-configurable changes took effect (where applicable).
#### 6.10.4.3 Activities
Examine documentation.
### 6.2.13.7 MI-DOST assessment
#### 6.10.4.4 Verdict
**[MI-DOST]** Verify the product is accompanied by documentation describing its denial-of-service protections and the protections the operational environment shall provide.
PASS if **all** of the following are fulfilled:
#### Activities
* Documentation exists, and
* is appropriate to the typical user.
Verify:
Otherwise FAIL
- The documentation describes what denial-of-service protections the product provides.
- The documentation describes what protections the operational environment shall provide.
- The boundary between product-provided and environment-provided protection is clear.
- The documentation is comprehensible to the intended user of the product.
#### 6.10.4.5 Evidence
#### Verdict
* Documentation
* Sufficiency analysis of documentation
* Documentation of intended purpose
Pass if:
### 6.10.5 REQ-AP-04 (MI-WDOG): Watchdog and self-initiated reset
- The documentation describes the product's denial-of-service protections;
- The documentation describes the protections the operational environment shall provide;
- The boundary between product and environment responsibility is clear;
- The documentation is comprehensible to the intended user.
#### 6.10.5.1 Objective
Fail otherwise.
Maintain availability during attacks that disable product functionality.
#### Supporting evidence
#### 6.10.5.2 Preparation
- Denial-of-service protection documentation;
- Assessment of comprehensibility for the intended user.
Identify the conditions that indicate that the product is not performing its functions.
#### 6.10.5.3 Activities
Using product features or inputs, cause the product to enter each identified condition.
#### 6.10.5.4 Verdict
PASS if, after causing the product to enter each condition, the product regains the ability to perform its functions.
Otherwise FAIL
#### 6.10.5.5 Evidence
* Log messages
* Packet captures
### 6.10.6 REQ-AP-05 (MI-NTFY): Watchdog and notification of host
#### 6.10.6.1 Objective
Maintain availability during attacks that disable product functionality.
#### 6.10.6.2 Preparation
Identify the conditions that indicate that the product is not performing its functions.
#### 6.10.6.3 Activities
Using product features or inputs, cause the product to enter each identified condition.
#### 6.10.6.4 Verdict
PASS if, after causing the product to enter each condition, the host system receives a notification.
Otherwise FAIL
#### 6.10.6.5 Evidence
* Log of device activity and/or state
* Packet captures
# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act
