@@ -168,6 +168,7 @@ Products not in scope include:
- Industrial NMS’ as covered by EN 304 621b (alternatively prEN 50XXX-2 project number 81650)
- Telecom functions as covered by
- Routers, modems and switches as covered by EN 304 627
- OS used to manage the NMS
This standard does not cover products in use in contexts other than those identified in Annex <L>.
@@ -523,28 +524,19 @@ The metrics can be for example the last time when the managed element has been s
> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.
> Example technical security requirements can be found in related standards, such as:
>
> - Protection profiles for similar categories of product
-**[RQ-1]** An network management system shall implement appropriate cryptographic libraries to allow the protection of the provisioned configuration according to the requirements of the forseeable use.
-**[RQ-2]** The product is shipped without undocumented interfaces.
-**[RQ-3]** The administrative actions shall be traced in case of accidental or intentional misconfiguration.
-**[RQ-4]** A secure channel is used in transport (e.g., TLS)
-**[RQ-5]** Compromised keys can be changed
-**[RQ-4]** A secure channel is used in transport (e.g., TLS).
-**[RQ-5]** Cryptographic keys can be changed.
-**[RQ-6]**
-**[RQ-7]**
-**[RQ-8]**
- Authenticate the source of updates (digital signatures).
- Verify integrity before installation (hash checks).
- Authenticate the source of the update package (digital signatures).
- Verify integrity of the upddate before installation (hash checks).
- Use secure channels for delivery (e.g., TLS).
- Prevent rollback to vulnerable versions.
- Ensure fail-safe install with rollback if needed.
@@ -555,11 +547,22 @@ General requirements:
A **secure channel** referred in [RQ-4] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the forseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].
When TLS is not used to encrypt the traffic in the secure channel, manufacturer shall provide detailed description how the channel is secured in the technical documentation.
The chosen method shall follow the CRA by protecting the data transfer, and protect the confidentiality and integrity of the data according to the requirements of the forseeable use.
### 5.2.2 Network segmentation
Network segmentation is encouraged to be used where applicapble. The best practise is to use dedicated network segment for network management traffic.
Management traffic can be configuration updates, encryption keys, software updates, and other alike.
Regardless of what connectivity design manufacturer implements in the NMS design from [ACC-L-0] to [ACC-L-3], manufacturer shall implement mitigations described in the following section [Risk Mitigations](#53-risk-mitigations).
## 5.3 Risk Mitigations
> **TODO**: Connect the technical security requirements in Section 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in section 6.
### 5.2.1 Mitigations for user identity integrity
### 5.3.1 Mitigations for user identity integrity
> This section shall have:
>
@@ -568,11 +571,11 @@ A **secure channel** referred in [RQ-4] and used in transportation is a cryptogr
-**[ID-1]** An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.
### 5.2.2 Mitigations for ingested data integrity and confidentiality
### 5.3.2 Mitigations for ingested data integrity and confidentiality
> This section shall have:
>
> - How the SIEM shall verify the authensity and integrity of the incoming data
> - How the NMS shall verify the authensity and integrity of the incoming data
> - What is expected to happen, if discrepencies are found
-**[CONF-1]** The manufacturer shall protect the system against data poisoning or other adversial attacks.
