Sync technical requirement description with OS

Virtual network interfaces are products with digital elements that directly or indirectly connect a device to a network via an API that emulates that of device drivers of physical network interfaces, typically operating at the data link layer.

This category includes but is not limited to wired and wireless network interface cards, controllers and adapters, such as for Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, or Fieldbus, and Infiniband. It also includes modems that are designed to connect directly to a system bus on the host and provide connection from the host to analog transmission media, as for example Power Line Communication devices.

This category includes but is not limited to wired and wireless network interface cards, controllers and adapters, such as for Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, Fieldbus, or Infiniband. It also includes modems that are designed to connect directly to a system bus on the host and provide connection from the host to analog transmission media, as for example Power Line Communication devices.

FIXME: choose something consistent for:

 * system bus

  * **[ADM-L-0]** Professional administration, fully resourced

  * **[ADM-L-1]** Non-professional administration, professional but under-resourced, or mixed

FIXME use case of integrated NIC, what effects does this have on available mitigations and impact, require firmware updatable

FIXME risk factor of DMA or VFIO where userspace can poke at NIC memory and some registers

### 4.5.1 Mapping of use cases to risk factors and security profiles

#### 4.5.2.1 Wired network interface use cases

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).

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). Note that the MSAs generally prefer evaluating via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.

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.

How exactly this will be done is yet to be determined, but here is our proposal:

Each mitigation is described with the following fields where necessary:

* 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.)

* Test: how to test that the mitigation is implemented

* Result: what result would indicate that the product passed the test

* Output: what output would should be saved

* The standard can include requirements for the tools used in the test itself (features or sensitivity or maybe even source code available?)

Optional:

* Any tests should demonstrate both the failure and success version of the test to rule out false positives or negatives

* False negative/positive prevention: if necessary, a way to prove that the test distinguishes between conformant and non-conformant products

* Requirements: features of the product as placed on the market necessary to run the test that aren't already required by some other technical requirement

* Documentation: any documentation the manufacturer must save for provision to the MSA in addition to the documentation required for every test

## 5.2 Technical security requirements specifications

### 5.2.1 General

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.

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following section.

## 5.2 Technical security requirements specifications

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.

**FIRST DRAFT**

### TR prevent or mitigate memory attacks

### Threat: Out-of-bounds memory access caused by unvalidated input in incoming packets

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)

  * 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

### Threat: Attacker causes network interface to stop functioning

### TR restart card when not functioning

Threat: Attacker causes network interface to stop functioning

Mitigations:

  * 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

### TR 

Threat: Packet processing errors (not memory) allow code execution or data modification on NIC or host

### TR General cryptography issues

# Annex A (informative): Mapping between the present document and CRA requirements

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

* Arbitrary packets from outside the system

* OS-validated packets from unprivileged users inside the system

* Any unprivileged user-accessible device driver API

Out of scope attack vectors:

* Any unprivileged user-accessible device driver API - MAY INCLUDE registers and directory memory access

* Anything the OS is responsible for

  * Firmware updates

  * Direct bit twiddling of registers

FIXME lots of firmware responsibility in the NIC, especially wireless

Refer to normative standards: