Commit 56c99e1b authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Moved network segmentation

parent b768d831
Loading
Loading
Loading
Loading
+0 −37
Original line number Diff line number Diff line
@@ -84,43 +84,6 @@ For high risk:

### 5.2.2 Cryptographic key intialisation and rotation

### 5.2.3 Network segmentation

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.

With segmentation, protection of management traffic is dependent on:

* capabilities the product
* deployment assumptions
* the operational environment capabilities

This is often implemented with:

* supporting more than one interface for the workload
* dedicated RFC1918 subnets for the traffic
* 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.

Management traffic in this context refers to command and control instructions, that changes the system operation or the managed network element operation.

Low:

* **[REQ-NETWORK-1a]** Network segmentation shall be used where applicable.

Medium:

* **[REQ-NETWORK-1b]** Available interfaces shall accept traffic only from reasonably limited known sources.

High:

* **[REQ-NETWORK-1c]** Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.

### 5.2.4 State-of-the-art cryptographic libraries

### 5.2.5 Software Bill of Materials
+43 −4
Original line number Diff line number Diff line
@@ -1054,7 +1054,8 @@ High requirement level shall implement all requirements in the defined set of re

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (1).

System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.
System operation is always an interplay of multiple components.
Modern software design can rarely ignore impact of the changes to other components.

On product architecture and design:

@@ -1065,12 +1066,50 @@ On product architecture and design:

On operative environment:

* **CYB_GENERAL_5** The product shall describe the core requirements and expectations for the operational environment (OE).
* **CYB_GENERAL_6** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
* **CYB_GENERAL_7** Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
* **CYB_OPS_5** The product shall describe the core requirements and expectations for the operational environment (OE).
* **CYB_OPS_6** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
* **CYB_OPS_7** Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).

[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.

### 5.2.1 Network segmentation

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.

With segmentation, protection of management traffic is dependent on:

* capabilities the product
* deployment assumptions
* the operational environment capabilities

This is often implemented with:

* supporting more than one interface for the workload
* dedicated RFC1918 subnets for the traffic
* 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.

Management traffic in this context refers to command and control instructions, that changes the system operation or the managed network element operation.

Low:

* **CYB-NETWORK-1a** Network segmentation shall be used where applicable.

Medium:

* **CYB_NETWORK-1b** Available interfaces shall accept traffic only from reasonably limited known sources.

High:

* **CYB_NETWORK-1c** Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.


## 5.3 No known exploitable vulnerabilities

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).