The test scope should be selected based on a risk-based approach. This includes considering the product's intended use and prioritizing functions and interfaces that process untrusted inputs, provide access to security-relevant assets, or execute critical operations, since memory access errors in such areas may have a greater cybersecurity impact.
### 6.2.4 REQ-SSD-04 (MI-BTIN) Boundary testing of inputs that may cause memory errors
### 6.2.4 REQ-SSD-04 (MI-BTIN) Resilience against potentially untrusted inputs
Identify input fields in the product that may produce memory errors.
Identify all sources of untrusted input to the product. For each source of untrusted input, review for fields in the format, values, or input sequences that could affect:
* availability of product resources (buffer length, number of packet descriptors, fragmented packets, CPU-intensive operations, etc.)
* incrementing or decrementing of internal counters (packet counters, event counters, etc.)
* consistency or validity of internal data structures
For each input, construct a series of inputs that tests, if technically possible:
* maximum and minimum valid input values and the next above and below
* maximum and minimum possible input values and next possible above and below
* a representative selection of other valid and invalid values
* potential overflow or underflow of internal counters
* values that are inconsistent with other values in the input
* indexes that are inconsistent or invalid with the data indexed
* values that, if used, would harm product availability
Identify the acceptable behaviour(s) of the product in response to the input that would protect its cybersecurity. Identify a method of sending these inputs to the product and recording the responses. Set up this testing environment.
#### 6.2.4.3 Activities
Run a tool that tests the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors.
For every input, send the input to the product and record its response.
#### 6.2.4.4 Verdict
PASS if **all** of the following are fulfilled:
* All boundary values tested, and
* all detected memory errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.
For every identified input:
* All values tested, and
* all detected errors have corresponding documentation demonstrating that each does not constitute an unacceptable cybersecurity risk.
Otherwise FAIL
#### 6.2.4.5 Evidence
* Logs of boundary testing tool
* Memory error report
* Documentation of any memory errors
* List of sources of untrusted input
* Analysis of sources of untrusted input for specified inputs
* Sufficienct analysis of untrusted inputs
* List of test inputs
* Logs of testing inputs and recording behavior
* Sufficiency analysis of testing logs
#### 6.2.4.6 Guidance
Assessment can often be done with minimal effort using commonly available fuzzer or security testing tools. It can also be done manually.
Acceptable behaviours might include:
* Crashing and restarting
* Terminating a thread
* Rejection of input and returning an error
* Silent discard of input
* Correction of input
* Dropping a packet and incrementing an error counter
* Emitting a notification when a counter rolls over
