- De-anonymize using stuff in the unencrypted header that is unique to user
- Document the purpose of each field and whether or not it could be used to identify the user, by itself or in combination with other fields
- Reduce the number of fields to the point where they cannot uniquely identify more than 1% of the total users? (or zero fields)
Threat: [specific technical failure event]
Mitigation(s): [there may be one or several, some or all may be required]
[action to take to mitigate]:
Test: [a step or list of steps to take]
Result: [expected output of above test]
Documentation: [description of how test was executed]
False negative prevention: [a step or list of steps to take in order to trigger the opposite result]
[a different action to take to mitigate]:
Test: [a step or list of steps to take]
Result: [expected output of above test]
Documentation: [description of how test was executed]
False negative prevention: [a step or list of steps to take in order to trigger the opposite result]
*******
Example requirement via NI
Threat: Out-of-bounds memory access caused by unvalidated input in incoming packets
Mitigations: Select from the following depending on use case/risk factor (TBD)
Fuzz packet input with memory use checker
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
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
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
*****
**TODO: specific known attack vectors to apply to appropriate requirements**
