Moved the risk factors to Annex B

## 4.3 Product overview and architecture

## 4.5 Risk Factors

To obtain conformity with this standard, each NMS placed on the market, the manufacturer should perform an assessment following the methods detailed in Annex C and applying the criteria of Clause 6.

This assessment can provide a risk profile of the intended purpose and foreseeable uses of the NMS product.

When following this standard such an assessment should consider the interplay between:

-   The complexity of foreseeable uses

-   The likelihood of incidents, given the foreseeable uses

-   The impact of incidents, given the foreseeable uses

-   The complexity of foreseeable use

-   The likelihood of an incident, given the foreseeable use

-   The impact of an incident, given the foreseeable use

The technical requirements in clause 5 reflect the risks and provide mitigations for the use cases provided in clause 4.6 and intended deployment of NMS products.

Individual risks are judged using the risk factors described here, and determine the degree and type of security needed for specific related security requirements.

Clause 5.X maps each use case to a set of mitigations that reflect these risk factors and the overall risk of the product as a combination of the likelihood and potential impact of incidents.

Risk factor analysis of all appropriate risk factors can be combined to determine an overall risk of the product and label its risk as low, medium, or high. With this approach, each risk factor provides a description of high or low risk related to a particular aspect of the product and when combined a way to judge its overall security needs.

The risk is combination of likelihood and impact.

Each risk factor is evaluated using defined criteria for likelihood and impact. The resulting risk level is determined as low, medium, or high according to Table 4.5-1.

The set of resulting risk levels is then used to determine the applicable requirements in clause 5.

The end result is a three tier low-medium-high evaluation of that given risk factor.

A set of risk factors is used to determine what requirements apply to the product in the later section [5 Requirements specifications](#5-requirements-specifications).

**Table 4.5-1: Determining risk level**

| Likelihood / impact | Low impact | High impact |

| ------------------- | ---------- | ----------- |

| Low likelihood      | Low        | Medium      |

| High likelihood     | Medium     | High        |

### 4.5.1 List of Risk Factors

The risk factors identified by the risk assessment in Annex C are grouped into risk categories and assigned unique identifiers as defined below.

#### 4.5.1.1 Service requesting users

The number of affected Service Requesting Users [<a href="#_term_.SRU">SRU</a>]

**Key:** [SRU]<br/>

**Rationale:** The affected user base impacts the risk definition.

[SRU]<br/> risk **likelihood** is **low**, where:

- The NMS's managed network has well-defined traffic patterns.

- The NMS's managed network has only a small variety of traffic classes, for example: IoT network data collection and software updates.

- The NMS's managed network's SRUs are other devices with well-known communication needs.

[SRU]<br/> risk **likelihood** is **high**, if:

- The NMS's managed network networtk has arbitrary and traffic.

- The NMS's managed network serves human users with possible various devices like laptops and mobile phones.

[SRU]<br/> risk **impact** is **low**, if:

- The NMS's managed network serves single household or a small business, small ammount of SRUs.

[SRU]<br/> risk **impact** is **high**, if:

- The NMS's managed network is a larger enterprise network with multiple sites connected to the same internal network structure.

- The NMS's managed network is a public telecommunication network provider, Internet service provider, or other network with a large amount of SRUs.

[SRU]: #4511-service-requesting-users

#### 4.5.1.2 Complexity of managed network element implementation

**Key:** [Complexity]<br/>

**Rationale:** The complexity and number of devices, functions, and sites managed or performed by the NMS are a factor when determining risk.

[Complexity]<br/> risk **likelihood** is **low**, if:

- The NMS has minimal features

- The NMS receives data only from simple devices, like a network of IoT devices the that send basic availability metrics to the NMS

- The NMS also enables some simple features for basic networking functionalities like firewall, DHCP

[Complexity]<br/> risk **likelihood** is **high**, if:

- NMS managed network is has exposed connectivity services like VPN and SDN.

- NMS provides a high number of network services.

- NMS managed network includes multiple interconnected sites

[Complexity]<br/> risk **impact** is **low**, if:

- NMS managed devices have limited capabilities

- NMS uses idempotent design

[Complexity]<br/> **impact** is **high**, if:

- NMS managed network performs dynamic routing table modifications

- NMS managed network is complex with sophisticated functions and supporting services

- NMS managed network includes multiple interconnected sites

[Complexity]: #4512-complexity-of-managed-network-element-implementation

#### 4.5.1.3 Critical entity

The expectations on security are a sum of deployment, its environment, likelihood and impact. Therefore this risk factor is evaluated directly as perceived by the market the product is made available.

**Key:** [CENT] </br>

**Rationale:** Critical entity's operations are governance is defined by laws and guidances like the NIS2 [i.16] in addition to nation specific regulation.

Entities that require higher level of protection also expects more accuracy and scrunity from the product.

The deployment context may include additional mechanisms to detect and respond to security compromise.

[CENT] </br> risk level is **low** if:

- The product is intended for or foreseaably used to manage networks whose product user entity status is undefined.

- Product's intended deployment target is a household or a small business with under a thousand users.

[CENT] </br> risk level is **medium** if:

- The product is intended for or foreseaably used to manage networks whose entity status is undefined.

- The product serves for a medium-sized enterprise.

- or the number of managed elements is a thousand or over.

[CENT] </br> risk level is **high** if:

- The product is targeted important or essential entities.

#### 4.5.1.4 Deployment context network segmentation

**Key:** [Segment] </br>

**Rationale:** The level of segementation and isolation of the NMS managed network are a factor when determining risk.

[Segment] </br> **likelihood** is **low**, if:

- NMS managed network is physically isolated from public networks with strong physical access control procedures.

[Segment] </br> **likelihood** is **high**, if:

- NMS managed network is connected with multiple entry points to public networks filtered by firewalls.

- NMS managed network uses no segmentation.

[Segment] </br> **impact** is **low**, if:

- NMS managed network is segmented in a way that does not mix management traffic with payload data.

- NMS managed network uses single segment, but the number of connect devices in the network is low.

[Segment] </br> **impact** is **high**, if:

- NMS managed network is segmented, and the segmentation is trusted to provide additional security.

- Traffic classes including control, management and payload shares the same segment on the NMS managed network.

[Segment]: #4514-deployment-context-network-segmentation

### 4.5.2 Mapping of use cases to risk factors

The table below is an example, how the example use cases could be mapped to different risk factors.

**Table 4.5.2-1: Example mapping of use cases**

| Use case                                              | [SRU] | [Complexity] | [CENT] | [Segment] |

| :---------------------------------------------------- | :---- | :----------- | :----- | :-------- |

| [4.4.1.1 IoT network with monitoring data collection] | low   | low          | TBD    | high      |

| [4.4.1.2 Home network deployment]                     | low   | low          | low    | medium    |

| [4.4.2.1 Office network]                              | TBD   | high         | TBD    | TBD       |

| [4.4.2.2 Telecom network]                             | high  | high         | high   | TBD       |

The To Be Defined (TBD) represent manufacturer design choices and what market the product is intended to be used in.

The product can be targeted to an audience, where the given risk factor evaluation is different.

For example the [4.4.2.1 Office network] evaluation table could be expanded to all existing combinations of low, medium, and high, in the risk factors that has TBD in place.

When the same product is provided to multiple different markets, highest risk factor selection appears as an appropriate selection.

[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

[4.4.2.1 Office network]: #4421-office-network

[4.4.2.2 Telecom network]: #4423-telecom-network

## 4.6 Security Profile

In the present context a security profile is the identification and mapping of assets, threats, resulting risks, and mitigating objectives that are furthermore covered by security requirements. The mapping thereby ensures that all identified threats are repelled or mitigated.

All products with digital elements have a common set of requirements which is essential to be addressed regardless of the system design or of the intended market.

 These essential security requirements are defined in the CRA [\[i.1\]](#_ref_i.1). The present document tries also to identify risk factors that are not obvious in all scenarios.

## 4.7 Essential functions

## 4.8 Product functions

This Annex applies state of the art methodology to identify assets, threats, identify and evaluate risk factors, and define security profiles applicable to the different use cases identified in the product context.

<mark> Editor's Note: The standard may implement an existing methodology, referencing the standards where it is defined. However, this methodology shall not compete with the legal obligation to draft an overall risk assessemnt. Alternatively, the following structure has been proposed as part of the EC comments received, that may be adapted as relevant for each vertical:

<br>

B.1 Assets

<br>

B.2 Risk factors

<br>

B.3 Assumptions

<br>

B.4 Threats (including connection to risk factors)

<br>

B.5 Mapping of risk factors to use cases

<br>

B.6 Mapping of risk factors to security profiles

<mark> Editor's Note: The standard may implement an existing methodology, referencing the standards where it is defined. However, this methodology shall not compete with the legal obligation to draft an overall risk assessemnt.

</mark>

<mark>Use technical language and focus what is relevant from a product perspective</mark>

## B.1 Asets

## B.2 Risk Factors

This assessment provides a risk factors for the intended purpose and foreseeable uses of the product.

When following this standard such an assessment should consider the interplay between:

-   The complexity of foreseeable uses

-   The likelihood of incidents, given the foreseeable uses

-   The impact of incidents, given the foreseeable uses

-   The complexity of foreseeable use

-   The likelihood of an incident, given the foreseeable use

-   The impact of an incident, given the foreseeable use

The technical requirements in clause 5 reflect the risks and provide mitigations for the use cases provided in intended deployment of the product.

Individual risks are judged using the risk factors described here, and determine the degree and type of security needed for specific related security requirements.

Clause 5.X maps each use case to a set of requirements that reflect these risk factors and the overall risk of the product as a combination of the likelihood and potential impact of incidents.

Risk factor analysis of all appropriate risk factors can be combined to determine an overall risk of the product and label its risk as low, medium, or high.

With this approach, each risk factor provides a description of high or low risk related to a particular aspect of the product and when combined a way to judge its overall security needs.

The risk is combination of likelihood and impact.

Each risk factor is evaluated using defined criteria for likelihood and impact.

The resulting risk level is determined as low, medium, or high according to Table B.1.0-1.

The set of resulting risk levels is then used to determine the applicable requirements in clause 5.

| Likelihood / impact | Low impact | High impact |

| ------------------- | ---------- | ----------- |

| Low likelihood      | Low        | Medium      |

| High likelihood     | Medium     | High        |

**Table B.1.0-1: Determining risk level**

### B.2.1 Service requesting users

The number of affected Service Requesting Users.

**Key:** [SRU](#b11-service-requesting-users)<br/>

**Rationale:** The affected user base impacts the risk definition.

risk **likelihood** is **low**, where:

- Managed network has well-defined traffic patterns.

- Managed network has only a small variety of traffic classes, for example: IoT network data collection and software updates.

- Managed network's SRUs are other devices with well-known communication needs.

risk **likelihood** is **high**, if:

- Managed network networtk has arbitrary and traffic.

- Managed network serves human users with possible various devices like laptops and mobile phones.

risk **impact** is **low**, if:

- Managed network serves single household or a small business, small ammount of SRUs.

risk **impact** is **high**, if:

- Managed network is a larger enterprise network with multiple sites connected to the same internal network structure.

- Managed network is a public telecommunication network provider, Internet service provider, or other network with a large amount of SRUs.

### B.2.2 Complexity of managed network element implementation

**Key:** [Complexity](#b12-complexity-of-managed-network-element-implementation)<br/>

**Rationale:** The complexity and number of devices, functions, and sites managed or performed by the NMS are a factor when determining risk.

risk **likelihood** is **low**, if:

- The product has minimal features

- The product receives data only from simple devices, like a network of IoT devices the that send basic availability metrics to the NMS

- The product also enables some simple features for basic networking functionalities like firewall, DHCP

risk **likelihood** is **high**, if:

- Managed network is has exposed connectivity services like VPN and SDN.

- The product provides a high number of network services.

- Managed network includes multiple interconnected sites

risk **impact** is **low**, if:

- Managed devices have limited capabilities

- The product uses idempotent design

**impact** is **high**, if:

- Managed network performs dynamic routing table modifications

- Managed network is complex with sophisticated functions and supporting services

- Managed network includes multiple interconnected sites

### B.2.3 Critical entity

The expectations on security are a sum of deployment, its environment, likelihood and impact. Therefore this risk factor is evaluated directly as perceived by the market the product is made available.

**Key:** [CENT](#b13-critical-entity) </br>

**Rationale:** Critical entity's operations are governance is defined by laws and guidances like the NIS2 [i.16] in addition to nation specific regulation.

Entities that require higher level of protection also expects more accuracy and scrunity from the product.

The deployment context may include additional mechanisms to detect and respond to security compromise.

risk level is **low** if:

- The product is intended for or foreseaably used to manage networks whose product user entity status is undefined.

- Product's intended deployment target is a household or a small business with under a thousand users.

risk level is **medium** if:

- The product is intended for or foreseaably used to manage networks whose entity status is undefined.

- The product serves for a medium-sized enterprise.

- or the number of managed elements is a thousand or over.

risk level is **high** if:

- The product is targeted important or essential entities.

### B.2.4 Deployment context network segmentation

**Key:** [Segment](#b14-deployment-context-network-segmentation) </br>

**Rationale:** The level of segementation and isolation of the managed network are a factor when determining risk.

**likelihood** is **low**, if:

- Managed network is physically isolated from public networks with strong physical access control procedures.

**likelihood** is **high**, if:

- Managed network is connected with multiple entry points to public networks filtered by firewalls.

- Managed network uses no segmentation.

**impact** is **low**, if:

- Managed network is segmented in a way that does not mix management traffic with payload data.

- Managed network uses single segment, but the number of connect devices in the network is low.

**impact** is **high**, if:

- Managed network is segmented, and the segmentation is trusted to provide additional security.

- Traffic classes including control, management and payload shares the same segment on the NMS managed network.

## B.3 Assumptions

## B.4 Threats and connection to risk factors

## B.5 Mapping of risk factors to use cases

# Annex C (informative): Relationship between the present document and any related ETSI standards (if any, e.g. EN 303 645)

## C.1 First clause of the annex