@@ -832,61 +832,41 @@ This section is a list of technical requirements necessary to satisfy the CRA es
Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.
### 5.2.X **TR-TEST**: Enable testing and collection of test output
A few assumptions that we are making:
### 5.2.X.x Requirement
Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.
The product shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable format on the product as placed on the market.
The MSA can and will request source code if desired.
#### 5.2.X.x **MI-TEST**: Document enabling of testing and collection of test output
The manufacturer shall document the steps necessary to enable testing and collection of the test output. The manufacturer shall not add unnecessary barriers to activating and collecting test output by MSAs.
* Test: follow the instructions to set up testing, run one test for a technical requirement that produces test output, and collect the output
* Result: test output matches expected output for that test
* Output: the expected output of the test
* Documentation: how to enable testing and collection of the test output, why any barrier to doing so is necessary
#### 5.2.X.x **MI-TDOC**: Test documentation
For any technical requirement which includes a test, the manufacturer shall document the instructions for setting up and running the test in addition to those described in MI-TEST, as well as what output of the test indicates passing of the test. Documentation shall include source code if available and usage documentation for each test, along with the options or inputs necessary to run the tests.
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
All mitigations for TR-TEST are required for all products.
### 5.2.X.x TR-IMEM Prevent memory safety attacks originating on the attached network
### 5.2.X.x TR-IMEM Prevent memory safety attacks
#### 5.2.X.x Requirement
The network interface shall not process data originating from the attached network in such a way as to cause an internal memory safety error that affects the security-relevant parts of the network interface.
The product shall not process input in such a way as to cause an internal memory safety error affecting the assets of the product.
#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory errors
The manufacturer shall check all security-relevant parts of the network interface firmware and software for memory errors using a source code analysis tool that detects at least the following types of memory errors, subject to whether each error is possible in the source code language:
All software and firmware in the product shall be checked for memory errors using a source code analysis tool that detects at least the following types of memory errors, if possible in the source code language:
* buffer overflow
* use after free
* double free
* uninitialized variables
* dereference invalid pointer
*TBD others?
*FIXME make this more rigorous
All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be accompanied by an explanation of why the code in question will not produce an error under reasonably foreseeable use or misuse.
All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be accompanied by an explanation of why the code in question will not negatively affect the product assets under reasonably foreseeable conditions, including intentional attempts to exploit it.
* Test: run a source code analysis tool on all security-relevant parts of the network interface firmware and software
* Result: no warnings or suppression of warnings that do not have documentation showing why they are memory safe
* Output: the output of the source code analysis checker
* False negative test: for each kind of memory error in the above list, write a test program with the error, run the analysis tool on it, and show that it produces a warning for each error
* Test: run a source code analysis tool on all firmware and software
* Result: no warnings, and any suppressed warnings have documentation showing why they are safe
* Output: the source code, the output of the source code analysis checker, and the documentation for suppressed warnings
#### 5.2.X.x MI-FUZZ Check input handling with an automated fuzzer
The manufacturer shall run a packet fuzzer on the security-relevant parts of the network interface firmware and/or software until it reaches NN% code coverage of the source code (NN based on overall risk) while monitoring for memory access errors.
The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment while measuring code coverage and detecting memory access errors.
* Requirements: a way to run the network interface firmware and software that permits measuring which parts of the source code have been executed and detecting memory safety errors
* Test: run a packet fuzzer until it reaches NN% code coverage (NN based on overall risk)
* Test: run the tool until 95% code coverage is reached
* Result: no memory safety errors are detected
* False negative prevention: create a version of the firmware and/or software that DOES allow an out-of-bounds write and show that it is detected with NN% code coverage
#### 5.2.X.x MI-IMSL Implement in a memory-safe language
@@ -896,7 +876,7 @@ TBD: define memory-safe language
* Test: review source code to determine its language and what exceptions to memory safety exists
* Result: source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a security risk
* Documentation: source code and documentation of unsafe features
* Documentation: source code and documentation of use of unsafe features
#### 5.2.X.x MI-ETIN Exhaustive testing of inputs
@@ -908,16 +888,16 @@ Mitigations satisfy technical requirements only under when they mitigate the rel
| Mitigation | Satisfies TR if risk factors are |
|------------|----------------------------------|
| None | ACC = 0 |
| SSCA | ACC <= 1 or COM = 0 |
| FUZZ | any |
| None | NET = 0 |
| SSCA | NET <= 1 or COM = 0 |
| FZ95 | any |
| IMSL | any |
| Mitigation | Satisfies TR for these security profiles |
