Add abbreviations, definitions, fix references, notes

# Introduction

> A brief summary of the document to help the manufacturer figure out if they need to keep reading or if they should move on to a different document.

The present document is a European harmonised standard that defines cybersecurity requirements for products whose core function is as an virtual or physical network interface. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act <a href="#_ref_i.1">[i.1]</a>.

The present document is a European harmonised standard that defines cybersecurity requirements for products whose core function is as an virtual or physical network interface. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act.

This standard does not apply to products that contain network interfaces or are part of a network interface if the core purpose of the product is not that of a network interface. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with network interfaces.

The present document does not apply to products that contain network interfaces or are part of a network interface if the core purpose of the product is not that of a network interface. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with network interfaces.

# 1 Scope

* <a name="_ref_i.4">[i.4]</a>    EN 18031-3 (2024): “Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value".

* <a name="_ref_i.x" >[i.x]</a>    EN 18031-3 (2024): “Common security requirements for radio equipment - Part 3: Internet connected radio equipment processing virtual money or monetary value".

<mark> FIXME add or delete informative references as work progresses </mark>

# 3 Definition of terms, symbols and abbreviations

This section provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 and terms and definitions provided by CEN/CLC EN 18031 series.

For the purposes of the present document, the [following] terms [given in ... and the following] apply:

For the purposes of the present document, the following terms apply:

**Device driver** A device driver is software running on the host that facilitates the transmission of network data

**Network device driver interface* An interface defined by host operating system or other software that abstracts the interface of the underlying network interface

**Firmware** Software stored within a device's non-volatile memory, such as ROM or flash memory, used to allow different types of hardware to communicate with the operating system

**Host** Any equipment which has complete user functionality when not connected to the network interface part and to which the network interface part provides additional functionality and to which connection is necessary for the network interface part to offer functionality

**Network interface** A physical device or software component that provides a host with a connection to a network

FIXME add terms

**Physical transmission media** The physical instantion of a network

**Physical transmission media adapter** A physical adapter on a network interface that transmits data on the medium

**Physical interface** A network interface that is a physical device

**System bus** A data transmission bus connecting physical network interfaces to a host processor

**Virtual interface** A network interface that is a software component only

## 3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply:

| Abbreviation | Description                              |

|--------------|----------------|

| ABC          | Alphabets      |

| DEF          | More Alphabets |

|--------------|------------------------------------------|

|**API**       | Application Programming Interface        |

|**ISP**       | Internet Service Provider                |

|**IT**        | Information Technology                   |

|**OS**        | Operating System                         |

<mark> FIXME add more abbreviations as necessary </mark>

# 4 Product context

The types of product with digital elements listed in the section do not fall within the scope of the the Regulation (EU) 2024/2847 (Cyber Resilience Act), and are not covered by this standard:

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a name="_ref_i.1">[i.1]</a>;

2. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a name="_ref_i.1">[i.1]</a>;

3. Products developed for or used exclusively for internal use by public administration as defined in CRA recital 16; article 5, 2 <a name="_ref_i.1">[i.1]</a>;

4. Non-commercial free and open source software as defined in CRA recitals 17-21; article 13, 5 <a name="_ref_i.1">[i.1]</a>;

5. Medical Devices and Software as defined in CRA recital 25; article 2, 2 [a-b] <a name="_ref_i.1">[i.1]</a>;

6. Vehicles, including aviation and marine equipment as defined in CRA recital 27; article 2, 2.c "vehicles"; recital 27; article 2, 3 "aviation"; article 2, 4 "marine equipment" <a name="_ref_i.1">[i.1]</a>;

7. Spare and used parts as defined in CRA recital 29; article 2, 6 <a name="_ref_i.1">[i.1]</a>;

8. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a name="_ref_i.1">[i.1]</a>;

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a href="#_ref_i.1">[i.1]</a>;

2. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a href="#_ref_i.1">[i.1]</a>;

3. Products developed for or used exclusively for internal use by public administration as defined in CRA recital 16; article 5, 2 <a href="#_ref_i.1">[i.1]</a>;

4. Non-commercial free and open source software as defined in CRA recitals 17-21; article 13, 5 <a href="#_ref_i.1">[i.1]</a>;

5. Medical Devices and Software as defined in CRA recital 25; article 2, 2 [a-b] <a href="#_ref_i.1">[i.1]</a>;

6. Vehicles, including aviation and marine equipment as defined in CRA recital 27; article 2, 2.c "vehicles"; recital 27; article 2, 3 "aviation"; article 2, 4 "marine equipment" <a href="#_ref_i.1">[i.1]</a>;

7. Spare and used parts as defined in CRA recital 29; article 2, 6 <a href="#_ref_i.1">[i.1]</a>;

8. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a href="#_ref_i.1">[i.1]</a>;

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a name="_ref_i.1">[i.1]</a> and can only be partially covered by this standard.

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a> and can only be partially covered by this standard.

9. High Risk AI as defined in CRA recital 51; article 12 <a name="_ref_i.1">[i.1]</a>;

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a name="_ref_i.1">[i.1]</a>;

11. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a name="_ref_i.1">[i.1]</a>.

9. High Risk AI as defined in CRA recital 51; article 12 <a href="#_ref_i.1">[i.1]</a>;

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a href="#_ref_i.1">[i.1]</a>;

11. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a href="#_ref_i.1">[i.1]</a>.

## 4.3 Product overview and architecture

The device driver often needs elevated privileges to read and write memory. Device drivers for physical network interfaces often must also have access to address space mapped to the network interface's control registers, and sometimes to enable or disable interrupts or other host hardware functions. This usually requires that the device driver have a high degree of privilege on the host system.

## 4.4 Use cases

This list of use cases is an informative resource to the manufacturer to simplify choosing a set of security requirements. Each use case is mapped to a security level, which is a collection of risks and the security requirements necessary to mitigate them.

Each security level will consist of the security requirements necessary to mitigate the threats related to the associated levels of risk factors.

<mark> FIXME: will need updating when the security requirements exist. </mark>

<mark> FIXME add security requirements when they exist </mark>

| Security level | USR     | ACC     | COM     | ADM     |

|----------------|---------|---------|---------|---------|

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

Where is the manufacturer the best place to mitigate the risks? Those should be the ones the manufac

turer treats, otherwise they are documented for the integrator.

<mark> FIXME actually add security requirements </mark>

<mark> FIXME random unsorted notes, to be updated </mark>

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!!!

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

<mark> FIXME add requirements when they exist </mark>

| CRA requirement                                 | Technical security requirements(s) |

|-------------------------------------------------|------------------------------------|

| No known exploitable vulnerabilities            |                                    |

> What data is stored on the product?

* Firmware

* Access to host memory

* Access to all network packets going in and out

* Configuration of functions

* Transmitter (thing that turns packets into signals)

FIXME device driver and virtual

* All network packets going in and out

* Device configuration

FIXME more assets

<mark> FIXME add assets for device driver and virtual interface </mark>

### C.1.2 Product functions

> See the functions in Section 4.4.

> See the functions in Section 4.7 Essential Functions.

## C.2 Threats

> Example threats can be found in the same documents suggested in the section on security requirements.

<mark> FIXME partial notes, need more threats, need to associate with risk factors </mark>

Virtual interfaces: all the same issues as device drivers: bad pointer, buffer overflow, memory management errors, bad logic, etc.

Physical interfaces:

* Bluetooth is exposed to the world and very common

  * development/debug commands on wireless things

FIXME more threats

FIXME lookup CVEs - anything from host-generated packets?

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01335.html

> List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases.

<mark> FIXME more assumptions, associate with risk factors and security requirements </mark>

- Not being attacked by a state actor

- Not using sophisticated or expensive hardware snooping techniques

- No secret hardware backdoors

Assume no physical tampering

For wireless - operating environment of standard applies

FIXME more assumptions

## C.4 Risk assessments of threats

> For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security levels.

> NOTE 3 A quantitative estimation of the cybersecurity risks can be performed using scoring systems that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to certain values.

<mark> FIXME pick methodology </mark>

# Annex D (informative): Risk evaluation guidance

<mark> FIXME random notes below, should be rewritten or deleted when no longer necessary </mark>

> **EXAMPLE for a table:**

**Table A.1: Relationship between the present document and<br />the requirements of EU Regulation 2024/2847**<a name="table_A.1"></a>

**Table A.1: Relationship between the present document and<br />the requirements of EU Regulation 2024/2847**<a href="#table_A.1"></a>

Harmonised Standard ETSI EN 304 6xx