@@ -404,153 +404,6 @@ Following list of essential functions keep the NMS self-secure and correct funct
<mark>Editor’s Note: Configuration functionality is equally in scope.</mark>
## 4.8 Product Architecture
<mark>Editor’s Note: This clause shall depict reference architectural patterns of products in this category, focusing on the architecture of the product itself and not the product as part of its operational environment or a larger ecosystem. The goal is to clearly indicate components, RDPS and their inter-relationships.</mark>
<mark>Editor’s Note: If the product category consists of multiple distinct product types, the reference architecture for each product type shall be drawn up separately for maximum clarity.</mark>
<mark>Editor’s Note: The diagram(s) shall be clearly labeled and accompanied by a short description of the main flows and components.</mark>
## 4.8 Operational Environment
<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>
<mark>Editor’s Note: Human factors of the operational environment are to be discussed in other clauses.</mark>
The technical requirements of the present document apply to the operational and environmental profiles of a Network Managment System in accordance with its intended use.
### 4.8.x Applying encryption in RFC 1122
A product's Service Requesting Users are often identified from the ability to communicate with the managed device in the link layer.
When considering the need for encryption, it is notable that encryption is often unavailable for fixed access network protocols operating in lower levels of the networking stack.
For example, subscriber line traffic is forwarded to the network without modifying the content or wrapping the traffic with layers of encryption.
Likewise, when a managed device is a router, it can often be configured to send and receive traffic from a Virtual Private Network.
Addressing the VPN security is outside of this document.
Encryption may also be beyond the control of the manufacturer. In the Radio Access Networking (RAN), the protocol family in use, like IEEE 802, defines what protocols are available and what chipher suites can be used to protect the traffic.
Through out the multiple possible links in the RAN backhaul, it is possible that the traffic traverses unencrypted.
For example, routing a remote site traffic through satelites can end up in a situation, where trunk traffic is broadcasted to the ground station and near areas of it.
Considering these and similar scenartios, it is next to impossible to verify how the underlying network is configured when the traffic exits the control region of the product. This is noted later in [REQ-GEN-4] under [General requirements](#51-general).
### 4.8.x System isolation
>Isolated management system design
>
>Editor's Note: What is an isolated design? That needs a clarification. Does that mean a generalized serial NMS product, procured as standalone?
### 4.8.x Managed Network Architecture
#### Distributed element and deployment design
>Distributed element design
>
>Editor's Note: Unclear and to discuss: what is distributed and where? Are elements also outside a defined operational environment? If so then further security requirements apply.
- Distributed element design
- Insignificant amount of interconnectivity within the network elements
- Lesser importance by the type of the controlled managed elements in their functionality and role in the deployment context
The affected Service Requesting Users base is small like in:
1. IoT network elements in a small deployment
1. Single home network deployment
When evaluating the system deployment risks, the product design and functionality needs to be understood.
#### Pocket deployment
A pocket deployment is a structure, where the managed device functionality does not degrade, if the connectivity to the centralised command is lost.
The device is placed in a network, that is independent and self sufficient.
The local network devices using the connectivity are not affected by outages and the product's role is more like a convinience for the user, rather than operational nessecity.
The local network does not expect to be connected to other similar remote sites.
The network user might have VPN services enabled, but expectation is to be connected only to the isolated environment of own home.
When a single device is compromised, the exposure is limited to the devices in that small network.
The network is not fully isolated or air-gapped.
When management system is deployed on shared resources, the resource hierarchy, dependencies and control boundaries becomes points of interest.
#### Physicality of the deployment
The product is can be engineered to work in a cluster which provides required redundancy and maintenance needs.
The deliverable cluster is often composed from multiple nodes and designed to fit to the customer operational environment.
The number of nodes and the composition of the hardware is designed to handle the expected load from the management function the product is performing.
**Table 4.8.x-1: Logical separation of duties adjacent to RFC1122**
| Networking and facilities | Site manager | Is it on? Can I walk in to the premises? |
Above duties in the table can be organised differently depending on the delivery context.
Large deliveries often come with a support contract ensuring the product operatoin and continuity through out changes in the industry, network and in the business the product is serving.
These responsibilities can be implemented with varying degree of third party involvement in respected layers.
Local delivery integration customisations could be also explored as East-West integration plane, but for the purpose of this document, all integration targets, apart from the managed devices, are adressed as RDPS.
> Example: SIEM system operation requires access grants from the product Application-layer to be able to collect iniformation from devices in the Networking and facilities-layer.
**Table 4.8.x-2: Responsibility separation example in a larger scale deployments**
| Layer | In-house | Hyperscaler | On-site as a service |
| Networking and facilities | Site manager | Hyperscaler | Product customer |
While it is possible to stay in higher abstraction level of above layering while defining the product requirements, the provided product needs to ackwnoledge what designs are supported.
There are different benefits in different responsibility separation structures.
Often the selection of delivery style is guided by customer needs, where critical infrastructure requirements have to to be matched in the product.
The physical deployment planning includes, but is not limited to:
- Always available basic services the product requires for operation: power supply, climate control, environmental impact protection against weather, fire, earthquake, other physical impact
- Available network connections to the digital services the product requires or can require for operation: certificate and signature validation, backup server, logging server, timestamp server
- Physical access control to ensure access by authorized staff only
When designing an on-site delivery, the customer might have to understand the following:
- EMP protection of the installation facility
- Facility location in respect to other points of interest
- Distribution and redundancy
The site design is often guided by the national legistlation and it varies between the EU countries.
The physical protection required is linked to the criticality of the use case.
Therfore the operational environement requirements are redused to a single item in [REQ-GEN-5].
### 4.8.x Identifying privileged subjects
> A block from IAM
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming an identification routine as long as that traffic is authorised in another way.
For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User (SRU).
Authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
## 4.9 Users
Human users of the system are natural persons, trained and qualified at NMS administrators, and authorised to manage the NMS and the connected managed elements. Administrators typically access the system through a HTTPS GUI, console, or by VPN connection.
@@ -243,11 +243,13 @@ For the purposes of the present document, the abbreviations given in ... and the
`XDR Extended Detection and Response`
# 4 Product context
The product context for network managment systems is detailed in the following clause. Product context is descriptive, and clause 4 does not contain normative requirements.
Instead it is a tool for the manufacturer of NMS products that describes NMS products in greater detail and provides information reagarding the functions, architecture, operational environment, distrubution of security functions, and common use cases for network managment systems.
The information below is provided as a tool for manufactuerers of NMS products that wish to conform to this standard and offers insight into how a specific product fits within the scope of this standard and which of the technical cybersecurity requirements detailed in clause 5 apply to a specific product.
## 4.0 Introduction
Network management systems consist of a variety of software and hardware products that enable thier user to oversee a network of connected devices.
This generally includes configuration, maintenance, and monitoring of the user's network so that it reamins functional and connected.
Beyond this most basic purpose and description, NMS products and thier implementations vary widely.
@@ -271,18 +273,131 @@ The information below offers an overview of NMS within the scope of this standar
<mark>Editor’s Note: The diagram(s) shall be clearly labeled and accompanied by a short description of the main flows and components.</mark>
### 4.2.x Distributed element and deployment design
>Distributed element design
>
>Editor's Note: Unclear and to discuss: what is distributed and where? Are elements also outside a defined operational environment? If so then further security requirements apply.
- Distributed element design
- Insignificant amount of interconnectivity within the network elements
- Lesser importance by the type of the controlled managed elements in their functionality and role in the deployment context
The affected Service Requesting Users base is small like in:
1. IoT network elements in a small deployment
1. Single home network deployment
When evaluating the system deployment risks, the product design and functionality needs to be understood.
### 4.2.x Pocket deployment
A pocket deployment is a structure, where the managed device functionality does not degrade, if the connectivity to the centralised command is lost.
The device is placed in a network, that is independent and self sufficient.
The local network devices using the connectivity are not affected by outages and the product's role is more like a convinience for the user, rather than operational nessecity.
The local network does not expect to be connected to other similar remote sites.
The network user might have VPN services enabled, but expectation is to be connected only to the isolated environment of own home.
When a single device is compromised, the exposure is limited to the devices in that small network.
The network is not fully isolated or air-gapped.
When management system is deployed on shared resources, the resource hierarchy, dependencies and control boundaries becomes points of interest.
### 4.2.x Applying encryption in RFC 1122
A product's Service Requesting Users are often identified from the ability to communicate with the managed device in the link layer.
When considering the need for encryption, it is notable that encryption is often unavailable for fixed access network protocols operating in lower levels of the networking stack.
For example, subscriber line traffic is forwarded to the network without modifying the content or wrapping the traffic with layers of encryption.
Likewise, when a managed device is a router, it can often be configured to send and receive traffic from a Virtual Private Network.
Addressing the VPN security is outside of this document.
Encryption may also be beyond the control of the manufacturer. In the Radio Access Networking (RAN), the protocol family in use, like IEEE 802, defines what protocols are available and what chipher suites can be used to protect the traffic.
Through out the multiple possible links in the RAN backhaul, it is possible that the traffic traverses unencrypted.
For example, routing a remote site traffic through satelites can end up in a situation, where trunk traffic is broadcasted to the ground station and near areas of it.
Considering these and similar scenartios, it is next to impossible to verify how the underlying network is configured when the traffic exits the control region of the product. This is noted later in [REQ-GEN-4] under [General requirements](#51-general).
## 4.3 Operational Environment
<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>
<mark>Editor’s Note: Human factors of the operational environment are to be discussed in other clauses.</mark>
The technical requirements of the present document apply to the operational and environmental profiles of a Network Managment System in accordance with its intended use.
### 4.3.1 General description
### 4.3.2 Physical/Hardware environment
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
The product is can be engineered to work in a cluster which provides required redundancy and maintenance needs.
The deliverable cluster is often composed from multiple nodes and designed to fit to the customer operational environment.
The number of nodes and the composition of the hardware is designed to handle the expected load from the management function the product is performing.
**Table 4.8.x-1: Logical separation of duties adjacent to RFC1122**
| Networking and facilities | Site manager | Is it on? Can I walk in to the premises? |
Above duties in the table can be organised differently depending on the delivery context.
Large deliveries often come with a support contract ensuring the product operatoin and continuity through out changes in the industry, network and in the business the product is serving.
These responsibilities can be implemented with varying degree of third party involvement in respected layers.
Local delivery integration customisations could be also explored as East-West integration plane, but for the purpose of this document, all integration targets, apart from the managed devices, are adressed as RDPS.
> Example: SIEM system operation requires access grants from the product Application-layer to be able to collect iniformation from devices in the Networking and facilities-layer.
**Table 4.8.x-2: Responsibility separation example in a larger scale deployments**
| Layer | In-house | Hyperscaler | On-site as a service |
| Networking and facilities | Site manager | Hyperscaler | Product customer |
While it is possible to stay in higher abstraction level of above layering while defining the product requirements, the provided product needs to ackwnoledge what designs are supported.
There are different benefits in different responsibility separation structures.
Often the selection of delivery style is guided by customer needs, where critical infrastructure requirements have to to be matched in the product.
The physical deployment planning includes, but is not limited to:
- Always available basic services the product requires for operation: power supply, climate control, environmental impact protection against weather, fire, earthquake, other physical impact
- Available network connections to the digital services the product requires or can require for operation: certificate and signature validation, backup server, logging server, timestamp server
- Physical access control to ensure access by authorized staff only
When designing an on-site delivery, the customer might have to understand the following:
- EMP protection of the installation facility
- Facility location in respect to other points of interest
- Distribution and redundancy
The site design is often guided by the national legistlation and it varies between the EU countries.
The physical protection required is linked to the criticality of the use case.
Therfore the operational environement requirements are redused to a single item in [REQ-GEN-5].
### 4.3.3 Logical/Software environment
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
@@ -291,6 +406,16 @@ The information below offers an overview of NMS within the scope of this standar
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
### 4.3.x Identifying privileged subjects
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming an identification routine as long as that traffic is authorised in another way.
For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User (SRU).
Authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
## 4.4 Distribution of Security Functions
<mark>Editor's Note: The clause should explain how the security functions are distributed among the product and its environment, referencing as appropriate elements of the operational environment defined in prior clauses. This analysis is not limited to which security functions products expect to get but should also explain which functions they themselves provide.</mark>
