@@ -521,21 +521,26 @@ The following are non-technical requirements, that shall be implemented by all p
-**[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.
This section contains technical security requirements for the product. Each general technical 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-3]** An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
-**[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-6]** A secure channel is used in transport.
| **[RQ-3]** | See [5.2.3 Appropriate cryptographic libraries](#523-appropriate-cryptographic-libraries) |
| **[RQ-4]** | Deployment of a production distribution exposes only documented interfaces. |
| **[RQ-5]** | Relevant actions are recorded and can not be modified later. |
| **[RQ-6]** | See [5.2.1 Secure channel definition](#521-secure-channel-definition). |
@@ -550,15 +556,30 @@ General requirements:
### 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].
A **secure channel** referred in [RQ-6] 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 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.
| Evesdropping from the wire | Third party capturing the channel traffic can not decrypt, understand, modify, resend the traffic. |
| Mutual trust | All endpoints in a secure channel can cryptographically verify others. |
Mutual trust is in plural form not exlucing IP Multicast or Anycast usage if implemented.
The figure above is an illustratoin of a simple TLS protected communication between NMS and the managed device.
The device initiates the connection towards reachable endpoint based on a DNS address configured into the managed device.
The device validates the provided public certifacate and logs in with machine credentials.
NMS authorizes the query based on the role and identity of the device.
### 5.2.2 Cryptographic key intialization and rotation
Manufacturer shall design and implementd support for on-demand rotation of cryptographic keys.
The technical documentation shall include:
1. instructions on how to intialize trust
1. how to use the trust to accept managed elements to the network
1. how to the established trust to rotate all keys
@@ -572,6 +593,8 @@ Regardless of what connectivity structure manufacturer implements in the NMS des
ZeroTrust routing is also encouraged where applicable.
### 5.2.4 Appropriate cryptographic libraries
## 5.3 Risk Mitigations
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).
