@@ -121,7 +121,7 @@ Products in scope include products whose core purpose is to serve as a virtual o
A physical network interface includes a system bus connection to a host, a hardware transmission adaptor that connects to transmission media, and any associated firmware. The device driver is included with the product if it is shipped with the network interface, otherwise it is part of a separate product.
Physical network interfaces include but are not limited to those that enable connection to IP-based networks via physical link layer protocols such Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, and Fieldbus. It also includes modems that are designed to connect directly to a system bus on the host and provide connection from the host to an analog transmission media.
Physical network interfaces include but are not limited to those that enable connection to IP-based networks via physical link layer protocols such Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, 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 an analog transmission media.
A virtual network interface is software that emulates the device driver of a network interface and enables direct or indirect connection to IP-based networks.
@@ -347,20 +347,21 @@ _List the essential functions of the product, including:_
* _How its functions are configured_
* _How it keeps itself secure and functioning_
.
* Bridge host memory and the network
* Receive and transmit data on network
* Read/write data to host memory
* Send commands/data to host hardware (wake on LAN)
* Carry out host commands (power, config, tx/rx)
* Update firmware
* Offload of segmentation
* Offload of segmentation and other features
FIXME more functions
FIXME device driver and virtual
Les: For virtual interfaces I think we'll need to consider the differences between the likes of DPDK and SR-IOV
## 4.6 Operational Environment
_Describe the expected operating environment given the exclusions in Section 4.2. This includes:_
@@ -411,8 +412,9 @@ The following security functionalities are outsourced to the operating system or
* Authorization
* Deletion of data
The network interface does not provide security functionality to other elements of the system, with the possible exception of:
The network interface provides the following security functions to other parts of the system:
* Data confidentiality when providing encryption at the physical link layer (WPA2, MACSEC)
* Impact minimization (can be programmed to assist processing packets more efficiently)
## 4.9 Support period
@@ -436,13 +438,19 @@ _Example technical security requirements can be found in related standards, such
* _Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)_
* _Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)_
* _PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)_
# Annex A (informative): Relationship between the present document and any related ETSI standards (if any)
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.
_List any related ETSI standards and how they interact with the present document._
Don't ship with undocumented interfaces!!!
Problems with protocols working as designed are not in scope.
# Annex B (informative): Mapping between the present document and CRA requirements
Problems with the implementation of the protocols by the interface are in scope.
# 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._
@@ -463,6 +471,10 @@ _Table mapping technical security requirements from Section 5 of the present doc
| Logging and monitoring mechanisms | |
| Secure deletion and data transfer | |
# Annex B (informative): Relationship between the present document and any related ETSI standards (if any)
_List any related ETSI standards and how they interact with the present document._
# Annex C (informative): Risk identification and assessment methodology
## C.1 Assets
@@ -497,40 +509,13 @@ _Example threats can be found in the same documents suggested in the section on
Virtual interfaces: all the same issues as device drivers: bad pointer, buffer overflow, memory management errors, bad logic, etc.
Physical interfaces:
- Copying data beyond end of packet and putting it on the network
- Incoming packets that trigger bad behaviour
- Bugs in chipset allowing unauthorized access to interface
- Malicious firmware updates - do this securely
- IoT things updated over wifi
- Bluetooth is exposed to the world and very common
- development/debug commands on wireless things
Security in depth, integrator has to do something?
Don't ship with undocumented interfaces!!!
Perhaps propose layer 2 security measures
Keep separate the defined protocol at data link layer and other security solutions (upgrade firmware? add chips?)
Must address specific risks with specific protocols if they exist
We cannot redefine e.g. the header of a bluetooth packet but we can address the issue of unsafe features of protocols via another method
lower security for data center
higher security for phones
What about interfaces with flexibility in protocols?
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.
Have different subclasses of standard, at least:
- wired
- MACsec
- wireless
- wireless that supplies security at the data link layer
- WPA2
- is this just a threat mitigation strategy?
- virtual
- common
or applicability matrix or something like that
* Copying data beyond end of packet and putting it on the network
* Incoming packets that trigger bad behaviour
* Bugs in chipset allowing unauthorized access to interface
* Malicious firmware updates - do this securely
* IoT things updated over wifi
* Bluetooth is exposed to the world and very common
* development/debug commands on wireless things
FIXME more threats
@@ -543,14 +528,9 @@ _List assumptions that are relevant to the risk analysis for these threats. Ever
* _No secret hardware backdoors in other components_
Assume no physical tampering
For wireless - operating environment of standard applies
If there is a one way connection - how is this implemented?
remove a card, do bad things, put it back?
wireless - operating environment of standard applies
