@@ -1059,71 +1059,65 @@ 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 process and drop invalid packets in a manner that protects the availability of the product.
#### 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.2.3 Guidance
### 5.2.13.4 MI-FDRP: Fast packet drop
Efficiently dropping invalid packets may be accomplished by checking the frame length, header fields, and destination address in order from least to most computationally expensive, and dropping the packet as soon as any field is found to be invalid without further processing.
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.10.3 REQ-AP-02 (MI-LMEM) Limit resource usage by incoming network data
- Reference: ER-AVAI
#### 5.10.3.1 Requirement
- Objective: Availability
The product shall manage internal resource usage by data received over the network or from the host system in such a manner that the impact of the exhaustion of any resource on the product's cybersecurity and functions is minimised.
---
#### 5.10.3.2 Applicability
### 5.2.13.5 MI-LMEM: Limit memory usage
TODO
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.
### 5.10.4 REQ-AP-03 (MI-DOST-1) Availability protection provided by operational environment
- Reference: ER-AVAI
#### 5.10.4.1 Requirement
- Objective: Availability
The product shall provide methods by which the operational environment may protect the availability of product assets necessary to the cybersecurity of the product.
---
#### 5.10.4.2 Applicability
### 5.2.13.6 MI-FAIR: Fair resource usage and prioritisation
TODO
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.
### 5.10.5 REQ-AP-04 (MI-NTFY): Watchdog and notification of host
- Reference: ER-AVAI
#### 5.10.5.1 Requirement
- Objective: Availability
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.
---
#### 5.10.5.2 Applicability
### 5.2.13.7 MI-DOST: Document risk transfer to operational environment for denial of service
TODO
### 5.10.6 REQ-AP-05 (MI-WDOG): Watchdog and self-initiated reset
The product shall be accompanied by documentation describing what denial-of-service protections the product provides and what protections the operational environment shall provide.
#### 5.10.6.1 Requirement
- Reference: ER-AVAI
The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.
- Objective: Availability
#### 5.10.6.2 Applicability
TODO
### 5.2.14 ER-LMAS: Minimize exposed interfaces
@@ -2012,133 +2006,198 @@ 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
**[MI-FDRP]** Verify the product performs ordered validity checks on incoming packets and drops invalid packets before further processing.
### 6.10.1 Overview
#### Activities
This clause provides assessment for the requirements in 5.14 relating to CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).
Verify:
### 6.10.2 REQ-AP-01 (MI-FDRP) Fast packet drop
- 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.
#### 6.10.2.1 Objective
#### Verdict
Maintain product availability during denial-of-service attacks.
Pass if:
#### 6.10.2.2 Preparation
- 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.
For each type of packet format processed by the product, order the fields by least to most expensive to process, approximately.
Fail otherwise.
Identify fields in the packet formats processed by the product that would make the packet invalid.
#### Supporting evidence
#### 6.10.2.3 Activities
- 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.
Measure the availability of the product while processing different kinds of invalid packets. Record whether invalid packets were dropped or accepted.
Analyse the availability of the product for indications that the product is doing significantly more processing of an invalid packet than necessary to reject it.
### 6.2.13.5 MI-LMEM assessment
#### 6.10.2.4 Verdict
**[MI-LMEM]** Verify the product enforces documented limits on internal resources consumed by received data and handles limit conditions gracefully.
PASS if **all** of the following are fulfilled:
#### Activities
* All invalid packets were rejected, and
* the availability of the product was reasonably maintained, and
* any significant reduction of availability was necessary to the product's intended purpose.
Verify:
Otherwise FAIL
- 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.
#### 6.10.2.5 Evidence
#### Verdict
* Description of types of invalid packets
* Logs of packet rejection or acceptance
* Logs of measurements of product availability
* Sufficiency analysis of product availability
Pass if:
#### 6.10.2.6
- 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.
One method to probe the efficiency of invalid packet processing is to construct pairs of invalid packet formats that could both be rejected with the same process, but one packet could potentially require significantly more resources to process if the packet processing was done in a less efficient order. Then send a large number of each kind of packet to the device and measure resource usage.
Fail otherwise.
E.g., given a packet with a 4 byte destination address field and a 1000 byte payload with a checksum, create a packet with an invalid address field and a correct checksum and a packet with an invalid address and an invalid checksum. Then measure the packet processing rate for each kind of packet. This may reveal whether the packet rejection code is unnecessarily validating the packet checksum for a packet it will reject anyway.
#### Supporting evidence
### 6.10.3 REQ-AP-02 (MI-LMEM) Limit resource usage by incoming network data
- 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.1 Objective
Maintain product availability during denial-of-service attacks.
#### 6.10.3.2 Preparation
### 6.2.13.6 MI-FAIR assessment
Identify product resources that may be exhausted by data received over the network. For each resource, prepare a sequence of network data that if received by the product (possibly with specific timing) will exhaust that resource. Identify ways to measure the availability of product functions and monitor any impact on product cybersecurity. Identify the performance of the product with maximum sustainable usage of each resource by incoming network data.
**[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.
#### 6.10.3.3 Activities
#### Activities
For each resource, send the network data that will exhaust that resource to the interface while measuring and monitoring availability and cybersecurity. Compare the results to the performance with the maximum sustainable usage of that resource. Analyse the monitoring for any degradation to cybersecurity.
Verify:
#### 6.10.2.4 Verdict
- 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.
PASS if **all** of the following are fulfilled:
For each resource and network data tested,
* the availability of the product was not significantly degraded compared to the maximum sustainable usage, and
* the cybersecurity of the product was not compromised.
Otherwise FAIL
#### 6.10.3.5 Evidence
* Set of inputs
* Logs of measurements and monitoring of resource usage, availability, and cybersecurity
* Explanation of choice of metrics
* Sufficiency analysis of availability
* Sufficiency analysis of cybersecurity
#### Verdict
#### 6.10.3.6 Guidance
Pass if:
Some examples of internal resources that may be exhausted:
- 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).
* packet buffers
* descriptor rings
* processor time
Fail otherwise.
Some ways to exhaust the resources are to send packets:
#### Supporting evidence
* faster than the product can process them
* with the maximum valid length as fast as possible
* that are fragmented and must be reassembled in the network interface
* that are encrypted
* that contain a large number of unusual or optional fields
- 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).
Some ways to measure the cybersecurity of the product:
* data transferred to the host or network are correct
* product does not reset
* product continues to function correctly
* product metrics are correct and consistent with input
### 6.2.13.7 MI-DOST assessment
### 6.10.4 REQ-AP-03 (MI-DOST-1) Availability protection provided by operational environment
**[MI-DOST]** Verify the product is accompanied by documentation describing its denial-of-service protections and the protections the operational environment shall provide.
#### 6.10.4.1 Objective
#### Activities
Maintain product availability during denial-of-service attacks.
Verify:
#### 6.10.4.2 Preparation
- 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.
Identify methods the product provides for availability protection of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require availability protection. For each identified asset, identify the methods to protect its availability and any necessary configuration, inputs, or other preparation for testing availability protection of that product asset. Install the product in the identified operational environment.
#### Verdict
#### 6.10.4.3 Activities
Pass if:
For each method and each type of asset identified, carry out the identified testing preparations and measure its availability.
- 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.4.4 Verdict
Fail otherwise.
PASS if for all tests, the availability of the product asset is deemed sufficient.
Otherwise FAIL
#### 6.10.4.5 Evidence
* Descriptions of types of data requiring integrity protection
* Records of configuration, input, and/or preparation for each test
* Logs of availability measurements
* Sufficiency analysis of analysis of availability of product asset
#### Supporting evidence
#### 6.10.4.6 Guidance
- Denial-of-service protection documentation;
- Assessment of comprehensibility for the intended user.
See the other requirements in the present clause for examples of testing availability of product assets.
### 6.10.5 REQ-AP-04 (MI-NTFY): Watchdog and notification of host
#### 6.10.5.1 Objective
Maintain product availability during denial-of-service attacks.
#### 6.10.5.2 Preparation
Identify the conditions that indicate that the product is not performing its functions sufficiently. Identify representative methods of causing the product to enter that condition.
#### 6.10.5.3 Activities
Use each identified method and monitor notifications to the host.
#### 6.10.5.4 Verdict
PASS if, after causing the product to enter each condition, the host system receives a notification.
Otherwise FAIL
#### 6.10.5.5 Evidence
* Description of identified conditions and methods
* Log of using method
* Log of notifications received on host system
* Log of device activity and/or state
* Packet captures
#### 6.10.5.6 Guidance
Forcing the product into a non-functional state can often be done by enabling and using testing interfaces.
### 6.10.6 REQ-AP-05 (MI-WDOG): Watchdog and self-initiated reset
#### 6.10.6.1 Objective
Maintain product availability during denial-of-service attacks.
#### 6.10.6.2 Preparation
Identify the conditions that indicate that the product is not performing its functions sufficiently. Identify representative methods of causing the product to enter that condition.
#### 6.10.6.3 Activities
Use each identified method and monitor the product functions.
#### 6.10.6.4 Verdict
PASS if, after causing the product to enter each condition, the product regains the ability to perform its functions without outside intervention.
Otherwise FAIL
#### 6.10.6.5 Evidence
* Description of identified conditions and methods
* Log of using method
* Log of device activity and/or state
* Packet captures
# Annex A (informative): Relationship between the present document and the CRA
