Removed writing instructions

## 4.3 Product overview and architecture

> Explain the overall architecture and relationship among the parts of the products. Use diagrams if that is helpful.

Network management system is often deployed in a star pattern, where all command and control functionality is focused on a centralized set of services, that are providing all required functionality.

Depending on the connected element design and degree of autonomy, the element can often operate fully without constant connectivity to a NMS. In larger network deployments, the connectivity can start to erode over time, if there is no adjustments made to the routing or other operation parameters.

## 4.4 Use cases

> Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same for two use cases, then it is basically the same use case for the purposes of the present document. Use cases should include both intended and reasonably foreseeable use/misuse. Use cases don't include industrial operations, automotive, transport, marine, airplane, medical, military, national security, etc.

This list of use cases is an informative resource to the manufacturer to simplify choosing a set of security requirements. Each use case is mapped to a security level, which is a collection of risks and the security requirements necessary to mitigate them.

> When you have many use cases, group them into 3 - 5 levels of risk. These will probably be your security levels.

Manufacturer shall delcare what risk profile it's product is meant to be evaluated at.

Manufacturer shall delcare what risk factors it's product is meant to be evaluated at.

As the technical definition of NMS describes the product being a system [Section 1.2] with connected elements like routers, NMS is an aggregate product.

## 4.5 Risk factors

> List the security profiles and the use cases that correspond to them.

For each network management system placed on the market, the manufacturer shall develop a threat model and risk profile of the forseeable use of the network management system, and shall consider the interplay between:

-   complexity of forseeable use

### 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 below.

These risks are grouped into risk categories and assigned unique identifiers below.

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

### 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

>

> For example, most individual hardware components do not have a built-in method of securely updating any firmware in the product. Usually this requires a full-featured system running an operating system which can check for firmware updates, download and verify them, and carry out the process of updating the firmware.

### 4.10.2 Security functions provided outside the product

> Describe what security functions are delegated to other components.

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

## 5.1 General