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).
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).
How exactly this will be done is yet to be determined, but here is our proposal:
* 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.
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel array bounds checking
* Threat: unbounded kernel array access
* Mitigation: array bounds validated
* Test: declare an array of fixed size and write beyond the max index
* Result: thread is killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel heap linear overflow detection
* Threat: kernel heap memory overflow
* Mitigation: check heap memory allocation bounds
* Test: in separate threads, allocate a fixed size from each class of kernel heap memory, write beyond it
* Result: each thread killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel heap user-after-free write prevention
* Threat: kernel heap use-after-free write
* Mitigation: memory tagging prevents use of un/re-allocated memory
* Test: allocate kernel heap memory, free it, write to the allocation
* Result: thread killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel heap user-after-free read prevention
* Threat: kernel heap use-after-free read
* Mitigation: memory tagging prevents use of un/re-allocated memory
* Test: allocate kernel heap memory, free it, read from the allocation
* Result: thread killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel heap free checking
* Threat: kernel heap free corruption
* Mitigation: validate heap origin on free
* Test: allocate kernel heap, free it twice
* Result: second free is rejected
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel stack memory zeroing
* Threat: uninitialized kernel stack memory controlled by attacker
* Mitigation: zero-initialize all kernel stack memory before use
* Test: sequentially call 2 functions that allocate the same amount of memory, fill the first with known values and return, and during second function call, read the stack contents back
* Result: stack contents are clear on second call
* Output: action logged as an event
* Requirements: way to read log output on product as shipped
* Short name: Kernel heap memory zeroing
* Threat: uninitialized kernel heap memory controlled by attacker
* Mitigation: zero-initialize all kernel heap memory before use
* Test: allocate heap memory, fill with a known value, free it, allocate it again in a deterministic way to get the same heap region, and read back the contents
* Result: heap contents are clear on second allocation
* Output: action logged as an event
* Requirements: way to read log output on product as shipped
* Short name: Kernel linked list protection
* Threat: kernel doubly linked list corruption
* Mitigation: linked list implementation checks prev/next pointers on add/del
* Test: add or delete an item to an uninitialized list
* Result: thread is killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Prevent execution of non-kernel code memory
* Threat: Non-code executable kernel memory
* Mitigation: Only kernel code memory regions are executable
* Test: copy a trivial return-only function into every class of non-code memory in the kernel (e.g. stack, heap, read-only data), one to a thread, and attempt to execute each one
* Result: each thread is killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Prevent writes to kernel code and read-only data memory
* Threat: Writable kernel code or read-only memory
* Mitigation: All kernel code memory and non-writable data is read-only
* Test: from separate threads, write to each portion of kernel code
and non-writable data region
* Result: each thread killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Prevent unintentional kernel access to unprivileged memory
* Threat: Unexpected access to userspace memory from OS kernel
* Test: in separate kernel threads, read, write, and execute memory regions that are mapped to userspace without going through dedicated userspace memory access routines
* Result: each thread killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel reference counter protection
* Threat: Kernel reference counter overflow
* Mitigation: bounds check reference counters
* Test: set resource reference counter to 1 less than maximum representable value, increment it twice
* Result: reference counter does not overflow but resource is pinned
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
* Short name: Kernel forward control flow integrity
* Threat: Kernel function pointer overwrite
* Mitigation: Protect saved function pointers from overwrite
* Test: Save a kernel function pointer to heap, overwrite it with a different function, make indirect call to the saved function pointer
* Result: thread is killed
* Output: action logged as an event or the OS reboots
* Requirements: way to read log output on product as shipped
### NOTES
Could requirements be tested by checking for the configuration options? Or do we want to give some instructions to the manufacturer on how to tell what settings or features will satisfy the requirements?
> **TODO**: Connect the technical security requirements in Section 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in section 6.
