The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product and the documentation that is required to be produced and saved by the manufacturer (and provided to the MSA on request).
> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.
The alternative option is “check-box” requirements, which only require that the vendor document that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”).
> Example technical security requirements can be found in related standards, such as:
>
> - Protection profiles for similar categories of product
We should prefer testable requirement to check-box requirements, but when a requirement isn’t testable, we can provide a decision tree where the vendor follows specific instructions to document why they have to use a check-box requirement (something that is documentation-only).
> FIXME actually add security requirements
The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs).
> FIXME random unsorted notes, to be updated
How exactly this will be done is yet to be determined, but here is our proposal:
Where is the manufacturer the best place to mitigate the risks? Those should be the ones the manufacturer treats, otherwise they are documented for the integrator.
* The vendor’s documentation must include information about each test it ran, including:
* any physical equipment other than the product’s normal operating environment
* any testing software they used, including versions
* documentation for any testing software or hardware used
* the parameters or arguments they used for the software or hardware
* any setup information for the test (load this module, flip this switch, run this script, etc.)
* The standard can include requirements for the tools used in the test itself (features or sensitivity or maybe even source code available?)
* Any tests should demonstrate both the failure and success version of the test to rule out false positives or negatives
Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.
* Test: run a packet fuzzer on instrumented firmware in simulator with memory access checking until it reaches NN% code coverage (NN based on overall risk)
* Result: simulator shows no out-of-bounds memory access
* Documentation: what simulator and fuzzer was used, with what configuration
* False negative prevention: create a firmware version that DOES allow an out-of-bounds write and show that it is logged by the simulator
Source code analysis
### Attacks/bugs/CVEs
* Test: run a source code analyzer that statically checks for out-of-bounds memory access
* Result: analyzer results shows no out-of-bounds memory access
* Documentation: source code, what source code analyzer was used, what parameters, any explanations of false positives or annotations in the source code that are instructions to the analyzer
* False negative prevention: create a firmware version that DOES allow an out-of-bounds write and show that the analyzer catches it
### Technical requirements
Implement in a memory-safe language
* Test: examine source code and firmware to see if they are in a memory-safe language
* Result: source code is in a memory-safe language, binary appears to be built from the source, any part of the source code that allows unsafe memory access has documentation explaining why it does not affect memory safety
* Documentation: source code, how to copy firmware from device
Check the length in any input fields from incoming packets
### Threat: Attacker causes network interface to stop functioning
Mitigations:
Select one from each of these categories
* Test-based:
* Run a fuzzer until you get >= X% code coverage, document the tool and the parameters, document any harmless bugs it triggers and why they aren't a problem
* Write your own test with >= Y% code coverage, include the source code of the test? same as above?
* The above but measuring the coverage in the object code using a simulator <- hard for MSA? do we care?
* Actually test 100% of the values, document how to run and source code
* Source code analysis:
* Run a source code analyzer and document why the false positives are false
* Use a memory-safe language and document why any use of unsafe features won't affect safety of this
Watchdog resets interface after interface stops responding
What about shipping a whole linux?
Is there a use case where we care about glitching of the network interface itself? think about it
----
* Disable all interfaces that intercept incoming packets above data link layer and do not pass them to the to the host
* Check that outgoing packets only contain the data requested to be copied from host
* Don't auto-connect to an network that is not really the same network
* Test: use debug interface to halt firmware
* Result: after N seconds, the interface restarts
* Documentation: how to enable debug interface, how to halt firmware, how to get log of restart
* False positive prevention: prevent any rx/tx/configuration/etc. activity on the card for N+1 seconds and see that it does not restart
# Annex A (informative): Mapping between the present document and CRA requirements
Where is the manufacturer the best place to mitigate the risks? Those should be the ones the manufacturer treats, otherwise they are documented for the integrator.
Don't ship with undocumented interfaces!!!
Problems with protocols working as designed are not in scope.
Problems with the implementation of the protocols by the interface are in scope.
