> 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.
> Example technical security requirements can be found in related standards, such as:
>
> - Protection profiles for similar categories of product
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]
> Copy-n-paste mitigation format
*******
### 5.2.X **TR-XXXX**:
Example requirement via NI
#### 5.2.X.x **MI-XXXX**:
#### Threat: Out-of-bounds memory access caused by unvalidated input in incoming packets
_Description of mitigation in "shall" format_
Mitigations: Select from the following depending on use case/risk factor (TBD)
* Test:
* Result:
* Output:
* False positive test:
* Requirements:
* Documentation:
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
*****
**[TR-RES-1]** VPN client must restore security-relevant configuration after VPN connection ends
Threat: VPN client does not restore network or other security configuration
### 5.2.X **[TR-ROUT]** VPN traffic routed only through VPN connection during VPN connection
FIXME something about the VPN client not making the system less secure?
FIXME don't want this to be *any* configuration, want this to be network configuration? not sure
FIXME what if the VPN client is totally killed? Must allow for cleanup to run somehow
From the moment the user activates the VPN connection until the user knowingly deactivates the VPN connection, no network traffic intended for the VPN connection shall exit the node via anything other than the VPN connection, whether not it is functioning.
**[MI-RES-1]** VPN client restores any configuration it changes to its previous state after the VPN connection ends
#### 5.2.X.x **[MI-ROUT-1]** VPN routing stays in effect until VPN connection deactivated
Test 1: For each kind of configuration change the VPN does, record the state of it prior to the VPN connection starting and compare it to the state after the VPN connection ends
The product shall only report that the VPN connection is established after it has configured the system in such a way that all traffic intended to exit only through the VPN connection will only exit through the VPN connection until the user knowingly deactivates the VPN connection.
Result: The configuration is functionally the same
* Test: start the VPN connection, after it reports that it is connected, kill the VPN software in a way that does not allow it to execute any clean up routines, then attempt to transfer data that should only go through the VPN connection
* Result: no data should exit the system
* Output: log of starting VPN, connection succeeding, client being killed, transfer failing, packet capture showing no data left after the VPN client was killed
Documentation: All system configuration that the VPN changes when it starts the connection, source, documentation, description of tests
### 5.2.X **[TR-CONF]** System configuration restored after VPN connection ends
Test 2: Same as test 1, but for when the VPN tunnel drops due to an error
After the user knowingly deactivates the VPN connection, the product shall restore any system configuration it has changes to a state that is functionally equivalent to the state it was in before the VPN connection began.
Areas for Technical requirements to be written:
#### 5.2.X.x **[MI-CONF]** VPN client restores any configuration it changes to its previous state after the VPN connection ends
**TODO: specific known attack vectors to apply to appropriate requirements**
* Test: collect the state of all system configuration the product may alter, start the VPN connection, after it reports that it is connected, stop the VPN connection, collect the system configuration again, and compare with previous version, repeat with different system and product configurations until all the possible system configuration changes have been tested
* Result: no functional differences in system configuration
* Output: before and after system configuration, any differences, explanation of why any differences do not affect the function of the system
* Documentation: a list of all the system configuration the product may change, a list of all the different system and VPN configurations that would result in different parts of the system configuration changing
