@@ -517,50 +517,48 @@ The metrics can be for example the last time when the managed element has been s
## 5.1 General
**[REQ-1]**: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
**[REQ-2]**: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test theproduct design.
The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with this standard.
-**[RQ-1]**: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
-**[RQ-2]**: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.
-**[RQ-3]** 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.
> 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.
This section contains technical security requirements for the product. Each general requirement is objectively verifiable on an instance of a product.
Each requirement has at least one concrete example that satisfies the requirements of the CRA.
Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these general requirements to [Section 4.5 Risk Factors](#45-risk-factors). The Risk Mitigations can include additional topic specific requirements.
General requirements:
-**[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]** Cryptographic keys can be changed.
-**[RQ-6]**
-**[RQ-7]**
-**[RQ-4]** The product is shipped without undocumented interfaces.
-**[RQ-5]** The administrative actions shall be traced in case of accidental or intentional misconfiguration.
-**[RQ-6]** A secure channel is used in transport (e.g., TLS).
-**[RQ-7]** Cryptographic keys can be changed.
-**[RQ-8]**
- 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.
- Require admin authorization for updates.
- Log update events and protect logs.
-**[RQ-9]**
-**[RQ-10]**
### 5.2.1 Secure channel definition
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.
The chosen method shall follow the intent in 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).
Management traffic can be configuration updates, encryption keys, software updates, and others alike.
Regardless of what connectivity structure 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.
The following sections describe how technical security requirement in previous [Section 5.2](#52-technical-security-requirements-specifications) are mapped to the risk factors in [Section 4.5 Risk Factors](#45-risk-factors).
This section can include topic specific requirements.
### 5.3.1 Mitigations for user identity integrity
@@ -579,7 +577,7 @@ Regardless of what connectivity design manufacturer implements in the NMS design
> - What is expected to happen, if discrepencies are found
-**[CONF-1]** The manufacturer shall protect the system against data poisoning or other adversial attacks.
-**[CONF-2]** The collected network element monitoring and metrics data shall be verifiable
-**[CONF-2]** The collected network element monitoring and metrics data shall be verifiable.
Every time a data is transported through an undefined connection, manufacturer shall take great care, that integrity and confidentiality of the data is not compromised.
@@ -589,19 +587,38 @@ Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this
| [CONF-1] | Data signing | Data signing | Data signing | Data signing |
| [CONF-2] | Data signing | Data signing | Data signing | Data signing |
Note that in a closed system, where the confindentiality doesn't require transport encryption, the data integrity does require at least signing of the data set with cryptographically good enough keying.
### 5.3.3 Mitigations for managed device configuration integrity and confidentiality
Push style configuration updates:
-**[CONF-0]** NMS signs the configuration in a way that managed device can verify the integrity of the content.
-**[CONF-1]** NMS sends the configuration only through [secure channel](#521-secure-channel-definition).
Pull style configuration updates:
-**[CONF-2]** Connectible configuration update API enables managed device to verify the NMS authencity.
-**[CONF-3]** Managed device credentials are valid.
-**[CONF-4]** Device role, place in the topology and function matches the requested configuration.
### 5.3.4 Secure updates
-**[UPDT-0]** Authenticate the source of the update package with.
-**[UPDT-1]** Verify integrity of the upddate before installation (hash checks).
-**[UPDT-2]** Use secure channels for update delivery (e.g., TLS).
# 6 Security Profiles
## 6.1 General
@@ -611,14 +628,14 @@ Note that in a closed system, where the confindentiality doesn't require transpo
> 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.
