> List technical cybersecurity 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 cybersecurity 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.
Technical requirements:
When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [SRU], [Segment], [NIS2]
For low risk:
-**[REQ-TECH-0]** An network management system shall implement [5.2.4 State-of-the-art cryptographic libraries] to allow the protection to the requirements of the forseeable use.
-**[REQ-TECH-1]** The product is shipped without undocumented interfaces.
-**[REQ-TECH-2]** Any administrative action shall be recorded for audit purposes.
-**[REQ-TECH-3]** A secure channel is used in transport.
-**[REQ-TECH-4]** Cryptographic keys can be rotated.
-**[REQ-TECH-5]** Cryptographic keys can be replaced with user controlled keys.
-**[REQ-TECH-6]** All system components are synchronized to the same time.
-**[REQ-TECH-7]** All system clocks are monitored.
**Table 5.2-1: Technical cybersecurity assesments and details**
| [REQ-TECH-2] | medium | medium | medium | medium |
| [REQ-TECH-3] | low | low | low | low |
| [REQ-TECH-4] | low | low | low | low |
| [REQ-TECH-5] | high | medium | n/a | high |
| [REQ-TECH-6] | high | high | medium | medium |
| [REQ-TECH-7] | high | high | high | high |
### 5.2.1 Secure channel definition
A **secure channel** referred in [REQ-TECH-3] 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 [REQ-TECH-2] 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.
| State-of-the-art cryptographic libraries are used | See [5.2.4 State-of-the-art cryptographic libraries] |
| 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.
@@ -728,10 +700,10 @@ The technical documentation shall include:
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 others alike.
Regardless of what connectivity structure manufacturer implements in the design, manufacturer shall implement mitigations described in the following section [Risk Mitigations](#53-risk-mitigations).
ZeroTrust routing is also encouraged where applicable.
<mark>TODO: this should need to be coupled with Operative environment chapter</mark>
@@ -748,6 +720,7 @@ For backwards compatibility, use of other combinations of options other what is
### 5.2.5 Software Bill of Materials
These requirements are generally binding, and there is no low-medium-high tiering available.
-**[REQ-SBOM-0]:** Operating system dependencies and application dependencies are clearly separated in the provided SBOM.
-**[REQ-SBOM-1a]:** Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM.
@@ -761,6 +734,8 @@ All performed authoritative actions needs to be identified. If the system fails
An identity management system provides an authentication of an user. It provides the assurance of correctness that the entity's provided information is corret.<ahref="#_ref_i.12">[i.12]</a> To have a functional authentication, the trusted source needs to be well maintained.
If the source authentication is a company internal directory, the content needs to be up to date and reflect the status of persons current access grants.
These requirements are generally binding, and there is no low-medium-high tiering available.
-**[REQ-AUTH-0]:** The product is integrated into a state of the art identity mangement system.
-**[REQ-AUTH-1]:** 2-factor authentication is used to confirm the identity of a natural user.
-**[REQ-AUTH-2]:** Authenticated natural users's authorization validity is no longer than a two days.
@@ -784,8 +759,6 @@ In addition, the managed device can have a configuration port, management API, f
-**[REQ-AUTH-6]:** All access to administrative interfaces, control functions, and sensitive operations shall be subject to strong authentication of users, services, or integrated components.
-**[REQ-AUTH-7]:** Priviledged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
These requirements are generally binding, and there is no low-medium-high tiering available.
<mark>TODO: define usage of machine credentials better, consider the cli over ssh controlled nms scenario</mark>
### 5.2.7 Remote Data Processing Systems
@@ -799,7 +772,7 @@ This section can include topic specific requirements.
### 5.3.1 Mitigations for user identity integrity
See [5.2.6 Role based authorisation]
### 5.3.2 Mitigations for ingested data integrity and confidentiality
