@@ -558,11 +558,16 @@ For example, subscriber line traffic is forwarded to the network without modifyi
Likewise, when a managed device is a router, it can often be configured to send and receive traffic from a Virtual Private Network.
Addressing the VPN security is outside of this document.
Encryption may also be beyond the control of the manufacturer. In the Radio Access Networking (RAN), the protocol family in use, like IEEE 802, defines what protocols are available and what cipher suites can be used to protect the traffic.
Encryption may also be beyond the control of the manufacturer.
In the Radio Access Networking (RAN), the protocol family in use, like IEEE 802, defines what protocols are available and what cipher suites can be used to protect the traffic.
Throughout the multiple possible links in the RAN backhaul, it is possible that the traffic traverses unencrypted.
For example, routing a remote site traffic through satellites can end up in a situation, where trunk traffic is broadcasted to the ground station and near areas of it.
Considering these and similar scenarios, the configuration verification of the underlying network traffic exiting the product's control region is not practical. This is noted later in [REQ-GEN-4] under [General requirements](#51-general)
Considering these and similar scenarios, assuming that the lower level network traffic would be integrity and confidentiality protected by the fact, that the product user who controls the operative environment owns the fiber, is not feasible.
An important system like the product in this document needs multiple layers of defence.
When management traffic is classified to be Application level traffic, there is no reason to not use encryption with the served interfaces.
This is noted later in **CYB_OPS_6** under [5.2.1 Operative environment](#521-operative-environment).
### 4.2.4 Inventory, device and subjects management
@@ -1046,7 +1051,7 @@ High requirement level shall implement all requirements in the defined set of re
<mark>Editor's Note: If there is a matrix mapping the use cases to the technical requirements of the standard, it should be inserted in this clause. Alternatively, there can be such a matrix/mapping in each subclause below.</mark>
@@ -1059,9 +1064,9 @@ High requirement level shall implement all requirements in the defined set of re
| all | INT_CONF | all |
| all | INT_ROTATE | all |
| all | DM_RETENTION | all |
| | IM_SEGMENT | low |
| | IM_SEGMENT | medium |
| | IM_SEGMENT | high |
| UC_HOME | IM_SEGMENT | low |
| UC_ENTERRPISE | IM_SEGMENT | medium |
| UC_TELCO | IM_SEGMENT | high |
| all | MAS_TECH | all |
| all | MON_LOG | low |
| all | MON_LOG | medium |
@@ -1297,7 +1302,6 @@ How the retake of the authority is implemented is between the product and the de
***AAC_MACHINE-15:** The product shall provide passwordless authentication for machine users such as certificates or tokens.
***AAC_MACHINE-16:** The privileged interfaces like APIs shall support minimal access grants for the machine user.
## 5.7 Confidentiality protection
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (e).
@@ -1471,38 +1475,43 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
The best practise is to use dedicated network segment for network management and control traffic.
Management traffic can be configuration updates, encryption keys, software updates, and others alike.
It is not uncommon, that the product is used manage the network the product is deployed into.
With segmentation, protection of management traffic is dependent on:
* capabilities the product
* deployment assumptions
*design assumptions that translates to capabilities of the product
* deployment assumptions and instructions
* the operational environment capabilities
This is often implemented with:
* supporting more than one interface for the workload
*dedicated RFC1918 subnets for the traffic
* supporting more than one interface for the serving workload
*responding only to request that are coming from configured dedicated subnets
* protecting the subnet from rogue actors
* deployment guidance
* product architecture
Many of the items above are operational environment requirements, and often product user's responsibility to implement correctly.
Using segmentation makes it easier to detect undesried traffic in the management network.
It limits the attack surface from other connected networks, but it does not remove integrity, confidentiality and authentication requirements.
Segmentation limits the attack surface from other connected networks, but it does not remove integrity, confidentiality and authentication requirements as all control traffic
Management traffic in this context refers to command and control instructions, that changes the system operation or the managed network element operation.
**Low**:
***IM_SEGMENT-1**Network segmentation shall be used where applicable.
***IM_SEGMENT-1**The product shall support network segmentation for management traffic where applicable.
**Medium**:
***IM_SEGMENT-2** Available interfaces shall accept traffic only from reasonably limited known sources.
***IM_SEGMENT-2** Available management API's shall accept traffic only from reasonably limited known sources like RFC1918 subnet.
**High**:
***IM_SEGMENT-3** Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.
> NOTE: In default configuraton [5.6 Authentication and access control](#56-authentication-and-access-control) applies to all interfaces regardless of the connectivity.
> NOTE: The requirement **CYB_OPS_6** classifies management traffic to be Application level traffic making the low level OT designs incompatible with the this document.
## 5.12 Attack surface minimisation
@@ -2117,6 +2126,84 @@ Verify that:
## 6.11 Non-interference
### 6.11.1 Network segmentation
#### 6.11.1.1 IM_SEGMENT-1
**Objective:** Protect the interface on unclassified traffic.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to deploy the system.
**Activities:**
1. Study the implementation of the product and determine if the management traffic would be possible to segragate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of network served with the product.
**Verdict:**
1. Pass the product **instructs** the product user how to deploy and use the provided product features to limit traffic to the management interfaces.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
#### 6.11.1.2 IM_SEGMENT-2
**Objective:** Protect the interface on unclassified traffic.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to deploy the system.
**Activities:**
1. Study the implementation of the product and determine if the management traffic would be possible to segragate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of network served with the product.
**Verdict:**
1. Pass if the product **supports** utilising dedicated physical port for the management traffic or the product supports dedicated virtual subnet to be connected to the serving workload that is segregated from SRU traffic
1. and the product instructs the product user how to deploy and use the provided product features.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
#### 6.11.1.3 IM_SEGMENT-3
**Objective:** Protect the interface on unclassified traffic.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to deploy the system.
**Activities:**
1. Study the implementation of the product and determine if the management traffic would be possible to segragate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of network served with the product.
**Verdict:**
1. Pass if the product **requires** utilising dedicated physical port for the management traffic or the product supports dedicated virtual subnet to be connected to the serving workload that is segregated from SRU traffic
1. and the product instructs the product user how to deploy and use the provided product features.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
