# 3 Definition of terms, symbols and abbreviations
@@ -405,6 +408,7 @@ The risk factors identified by the risk assessment in Annex C are grouped into r
- **[COM-L-3]** Complex network element with sophisticated functions and supporting services
- Security expectations of intented network segment operation
- **Rationale**: NIS2 identifies entities that require higher level of protection
- **[EXP-L-0]** Undefined
- **[EXP-L-1]** NIS2 important entity
@@ -424,13 +428,13 @@ If there is no clear use case to be referred, the manufacturer shall take the pr
The different risk factors have a set of minimun requirements defined that are lowering the posibility and mitigating the impact of an security incident.
In case of overlap in the requirements, a stronger and more secure option shall be selected.
[4.4.1.1 IoT network with monitoring data collection]:#4411-iot-network-with-monitoring-data-collection
[4.4.1.2 Home network deployment]:#4412-home-network-deployment
@@ -438,27 +442,15 @@ In case of overlap in the requirements, a stronger and more secure option shall
[4.4.2.2 Waste management]:#4422-waste-management
[4.4.2.3 Telecom network]:#4423-telecom-network
## 4.6 Security Profiles
### 4.6.1 General
Security profiles are an informative resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.
## 4.6 Security Profile
### 4.6.2 Mapping of security profile to risk factors
Security profiles are a resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors.
Risk factors will be mapped to specific mitigations for each security requirements necessary to treat the risk.
Security profiles are associated with sets of risk factor levels.
All products with digital elements has a common set of requirements that shall be addressed regardless of the system design or intented market. These are defined in the CRA <ahref="_ref_i.1">[i.1]</a>.
The risk factors listed in this document meant to help the manufacturer to address specific scenarios which implementation might not be obvious.
> FIXME add security requirements when they exist
| Security profile | SRU | COM | EXP |
| ---------------- | --- | --- | --- |
| SEC-1 | | | |
| SEC-2 | | | |
| SEC-3 | | | |
| SEC-4 | | | |
| SEC-5 | | | |
## 4.7 Essential Functions
## 4.7 Essential functions
These essential functions lists, as an example, what the product does during it's intentent use, how it's functions are covered and how it keeps it self secure and functioning.
@@ -491,16 +483,13 @@ The target group relies on the outcomes of an functional system, but do not part
A NMS is often a compilation of different subsystems performing the task of the network management. The security functions may be implemented inside of the product as an integral part of the system or with help the of an established structures like OS package manager or logging subsystems.
### 4.10.1 General
For each security requirement, a product may:
1. Provide all necessary security functions itself
2. Require security functions be provided by some other part of its context
3. Provide security functions for the use of other components
### 4.10.2 Security functions provided outside the product
### 4.10.1 Security functions provided outside the product
The following security functionalities may be handled by other components in the system:
@@ -516,15 +505,20 @@ The following security functionalities may be handled by other components in the
Manufacturer shall document in the techical documentation what relevant systems are used outside of the NMS and how the trust is established and maintained between the components.
The documentation may contain, but is not limited to, components listed above.
### 4.10.3 Security functions provided to other components
### 4.10.2 Security functions provided to other products
The NMS shall provide the assurance of the operative network by keeping the control of the managed elements and by providing selected metrics describing the system's operative functionality.
The metrics can be for example the last time when the managed element has been seen or the throughput of an important interface if it seen to be a relevant metric to follow.
# 5 Requirements specifications
**Technical documentation responsibility** used in the following tables and requirements is a requirement for the manufacturer to specify what actions and designs are supporting the intention to provide similiar, or higher level of security in the context.
## 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.
> 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.
@@ -538,16 +532,16 @@ The metrics can be for example the last time when the managed element has been s
> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)
-**[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]**An network management system which supports medium or larger enterprise networks shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.
-**[RQ-3]** The product is shipped without undocumented interfaces.
-**[RQ-4]**The administrative actions shall be traced in case of accidental or intentional misconfiguration.
-**[RQ-5]**The manufacturer shall protect the system against data poisoning or other adversial attacks.
-**[RQ-6]** The collected network element monitoring and metrics data shall be verifiable
-**[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-6]**
-**[RQ-7]**
-**[RQ-8]**
-**[RQ-9]**
-**[RQ-10]**
- Authenticate the source of updates (digital signatures).
- Verify integrity before installation (hash checks).
@@ -557,10 +551,56 @@ The metrics can be for example the last time when the managed element has been s
- Require admin authorization for updates.
- Log update events and protect logs.
### 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].
## 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
> This section shall have:
>
> - How the system users identities should be maintained
> - How the least amount of privileges principles are enforced to user groups
-**[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
> This section shall have:
>
> - How the SIEM 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.
-**[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.
Confidentiality can be achieved different ways in different scenarios.
Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this document, the following requirements shall be implemented.
| [RQ-4] | Not required | TLS in the endpoint | TLS in exposed endpoints | Technical documentation responsibility |
| [RQ-5] | | | | |
| [RQ-6] | | | | |
| [RQ-7] | | | | |
| [RQ-8] | | | | |
| [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.
# 6 Security Profiles
## 6.1 General
@@ -570,14 +610,14 @@ The metrics can be for example the last time when the managed element has been s
> 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.
