@@ -424,40 +424,109 @@ Considering these and similar scenartios, it is next to impossible to verify how
### 4.8.x Managed Network Architecture
#### Distributed element design
#### 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
>Pocket deployments with high independency
>
>Editor's Note: What is a pocket deployment? That needs a clarification. Does that mean deployment in a from public networks isolated closed network?
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 management system is deployed on shared resources, the resource hierarchy, dependencies and control boundaries becomes a points of interest.
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
> An old block from !25:
The site design is often guided by the national legistlation and it varies between the EU countries.
The manufacturer shall describe the core requirements for the operational environment (OE). The actual protection required is linked to the criticality of the use case, and with that the OE requirements can be mapped to [SUR-L-x].
The OE for [SRU-L-0] shall ensure:
to be defined......
The OE for [SRU-L-1] shall ensure:
to be defined......
The OE for [SRU-L-2] shall ensure:
• Always available basic services the NMS 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 NMS 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
• Authorized staff shall be trained and qualified on the NMS, trusted, operate without malicious intent and act according the NMS user guidelines
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.
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
@@ -508,8 +577,9 @@ The following non-technical requirements shall be implemented by all products wi
-**[REQ-GEN-0]:** The product shall have technical documentation with what [Risk factors](#45-risk-factors) the product shall be evaluated.
-**[REQ-GEN-1]:** The product shall have technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.
-**[REQ-GEN-2]:** The product dependencies to Operating System essential security capabilities are documented.
-**[REQ-GEN-3]:** The manufacturers technical documentation shall describe the external services and systems that are required for the product operation like mentioned in [4.10.1 External security functions, not in scope of the present document].
-**[REQ-GEN-3]:** The products technical documentation shall describe the external services and systems that are required for the product operation like mentioned in [4.10.1 External security functions, not in scope of the present document].
-**[REQ-GEN-4]:** Traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122 in the technical documentation.
-**[REQ-GEN-5]:** The product shall describe the core requirements and expectations for the operational environment (OE).
System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.
