4. ICT devices like phones, tablets, laptops and other mobile devices
5. Office equipment like printers and meeting systems
#### 4.2.2 Controller design
### 4.2.2 Controller design
The product is a network controller.
The different user roles are defined later in [4.5 Users](#45-users).
@@ -644,7 +644,70 @@ Only in networks that need greater integrity assurance, does the network need to
### 4.3.4 Connectivity aspects
### 4.3.x Trust initialisation
Authorization is the final step that assigns execution and access rights to resources to a user.
The preparation for this step consists of identity verification and authentication.
The user identity management can be integral part of the product, but can also be provided as an external service.
The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.
As the natural user and machine user can sometimes be used interchangeably in the context the term subject in this document refers to both unless specified.
Depending on the design of the product, authorisation to execute a single or a set of commands and general identity management can use the same system or two distinct systems.
The choice to use a single or separate systems often relates to system and network size and in smaller systems identity management and authorisation are often combined.
Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
The interfaces designed for the machine users can be used by other privileged subjects.
As administrator is often a privileged natural user, but the machine user making changes is not necessarily an administrator, this document refers to both as privileged subject whom are often connecting to privileged interfaces.
The product can serve traffic that is not meant to be identified.
For example, an in-home router often trusts that the physical access to its port is enough to identify the subscriber line.
In addition, the managed element can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.
The operative context is described in more detail in the section [4.8 Operational Environment](#48-operational-environment).
#### 4.3.4.1 Identity management
An identity management system assures the identity of each subject which can be privileged or non-privileged within the system deployment context.
The identity management system maintains a list of trusted sources, one or more, that describes what subjects are valid.
An up-to-date source of identity is essential.
If a company internal employee directory is the source of the identity, its functionality is dependent on the accuracy and timeliness of its content.
If an employee exits the company, their identity is expected to vanish or at least reflect the contractual status of the employee.
The identity management is often assessed as part of certification processes, and is outside of this document. [\[i.12\]](#_ref_i.12)
Identity management system design and implementation is outside of the scope of this standard.
Depending on the product design, the identity management referred in **AAC_AUTH-1** can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is desirable or necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated identity management system is part of existing processes, up-to-date and can invalidate subjects credentials when necessary.
The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.
Therefore due diligence is required during integration development to assure that the supported structures meets the target security requirements in the intended or likely implementations of the product.
Role based authentication has been established to be a reasonable method to control a large pool of subjects by grouping them together for example to task based sub-groups that grants access to partial set of functions.
These groups can be for example _billing reader_ or _project admin_ to grant access to related operations in the product.
For example, it is not feasible that a financial accountant needs access as the _project admin group_, but it is reasonable to assume, that _project admin_ would need to understand how much the performed actions costs while assessing if projects is within the budget.
How the grouping is implemented is outside of this document.
#### 4.3.4.2 Attribute-Based Access Control
Role based access control might be too coarse for some applications, like machine user access grants.
Therefore industry has started to adopt more granular controls like Attribute-Based Access Control (ABAC), where subject's authorisation to perform a function is determined by attributes associated with the request.
This ABAC is also know as policy-based access control that compliments Identity and Access Management (IAM).
The attributes that formulate the identity portion of the grant are often matched with a target action.
> **ABAC Example:**
> An identified workflow execution A in a trusted environment B can amend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.
In the above example, the trust relationship between policy holder and the source environment can be established in various ways with different implementations.
Attribute-Based Access Control design and implementation is outside of the scope of this standard.
#### 4.3.4.3 Role based authorisation
When the identity of a subject is established, the system grants the subject access rights based on the subjects' role.
The system can have multiple distinct roles, each is tailored to the subjects' perceived needs.
There are many possible roles, with examples such as: monitoring data reader, interconnectivity administrator, or administrator.
If the product's deployment context calls for an all-powerful superuser, this can be accomplished either with a single role with numerous responsibilities or by aggregating many available roles to that single subject.
Role Based Access Control design and depth is outside of the scope of this standard.
#### 4.3.4.4 Trust initialisation
Secure network communication needs trust establishment among the communicating entities.
The NMS initiates and establishes that trust and can operate multiple methods for this, including but not limited to: identity confirming certificates, unique serial numbers or stored credentials, usually in the form of pre-installed keys.
@@ -663,7 +726,7 @@ Once configured, the same channel and trusted status is used for secured identif
Independent of any of the host system's capabilities, the NMS can also be remotely accessible.
### 4.3.x Risk management
#### 4.3.4.5 Risk management
The risk management is always use case dependent, and thus dependent on the actual conditions and operational environment.
Therefore, it is essential to understand how an NMS can impact a network operation in its key areas.
@@ -1186,69 +1249,6 @@ Distributed application design and delay lines built with buffers might tolerate
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (d).
Authorization is the final step that assigns execution and access rights to resources to a user.
The preparation for this step consists of identity verification and authentication.
The user identity management can be integral part of the product, but can also be provided as an external service.
The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.
As the natural user and machine user can sometimes be used interchangeably in the context the term subject in this document refers to both unless specified.
Depending on the design of the product, authorisation to execute a single or a set of commands and general identity management can use the same system or two distinct systems.
The choice to use a single or separate systems often relates to system and network size and in smaller systems identity management and authorisation are often combined.
Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
The interfaces designed for the machine users can be used by other privileged subjects.
As administrator is often a privileged natural user, but the machine user making changes is not necessarily an administrator, this document refers to both as privileged subject whom are often connecting to privileged interfaces.
The product can serve traffic that is not meant to be identified.
For example, an in-home router often trusts that the physical access to its port is enough to identify the subscriber line.
In addition, the managed element can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.
The operative context is described in more detail in the section [4.8 Operational Environment](#48-operational-environment).
#### Identity management
An identity management system assures the identity of each subject which can be privileged or non-privileged within the system deployment context.
The identity management system maintains a list of trusted sources, one or more, that describes what subjects are valid.
An up-to-date source of identity is essential.
If a company internal employee directory is the source of the identity, its functionality is dependent on the accuracy and timeliness of its content.
If an employee exits the company, their identity is expected to vanish or at least reflect the contractual status of the employee.
The identity management is often assessed as part of certification processes, and is outside of this document. [\[i.12\]](#_ref_i.12)
Identity management system design and implementation is outside of the scope of this standard.
Depending on the product design, the identity management referred in **AAC_AUTH-1** can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is desirable or necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated identity management system is part of existing processes, up-to-date and can invalidate subjects credentials when necessary.
The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.
Therefore due diligence is required during integration development to assure that the supported structures meets the target security requirements in the intended or likely implementations of the product.
Role based authentication has been established to be a reasonable method to control a large pool of subjects by grouping them together for example to task based sub-groups that grants access to partial set of functions.
These groups can be for example _billing reader_ or _project admin_ to grant access to related operations in the product.
For example, it is not feasible that a financial accountant needs access as the _project admin group_, but it is reasonable to assume, that _project admin_ would need to understand how much the performed actions costs while assessing if projects is within the budget.
How the grouping is implemented is outside of this document.
#### Attribute-Based Access Control
Role based access control might be too coarse for some applications, like machine user access grants.
Therefore industry has started to adopt more granular controls like Attribute-Based Access Control (ABAC), where subject's authorisation to perform a function is determined by attributes associated with the request.
This ABAC is also know as policy-based access control that compliments Identity and Access Management (IAM).
The attributes that formulate the identity portion of the grant are often matched with a target action.
> **ABAC Example:**
> An identified workflow execution A in a trusted environment B can amend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.
In the above example, the trust relationship between policy holder and the source environment can be established in various ways with different implementations.
Attribute-Based Access Control design and implementation is outside of the scope of this standard.
#### Role based authorisation
When the identity of a subject is established, the system grants the subject access rights based on the subjects' role.
The system can have multiple distinct roles, each is tailored to the subjects' perceived needs.
There are many possible roles, with examples such as: monitoring data reader, interconnectivity administrator, or administrator.
If the product's deployment context calls for an all-powerful superuser, this can be accomplished either with a single role with numerous responsibilities or by aggregating many available roles to that single subject.
Role Based Access Control design and depth is outside of the scope of this standard.
#### Generic requirements
All subjects require roles or comparable control structures like Attribute-Based Access Control, to limit individual access credentials to the smallest possible set of requested operations.
