Changes to 5.2.6 Auth requirements

For the purposes of the present document, the following abbreviations apply:

`ABAC   Attribute-Based Access Control`

`CRA    Cyber Resilience Act`

`OS     Operating System`

`IDP    Identity Provider`

`GUI    Graphical User Interface`

`NE     Network Element`

`MDM    Mobile Device Management`

`IAM    Identity and Access Management`

`OCI    Open Container Initiative`

# 4 Product context

- **[REQ-SBOM-1b]:** The SBOM identifier format shall be consistent with common vulnerability handling standards.

- **[REQ-SBOM-2]:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.

### 5.2.6 Role based authorisation

### 5.2.6 Identity and access management

The identity management is an essential piece in the larger puzzle of cybersecurity. A secure product is required to confirm the identity and authority of all users performing an action. If the system fails to identify such actions and authroity, or fails to track who executed commands, the system can easily fall into a state of chaos.

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.

An identity management system provides for the authentication of each user. It provides the assurance of that an entity has authorization and has provided the correct information to the product to perform a specific action.[\[i.12\]](#_ref_i.12) Only a well maintianed trusted source list can provide functional authenticantion.

If the source authentication is a company internal directory, the content needs to be up to date and reflect the status of persons granted current access.

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.

These requirements apply to all network management systems, regardless of the product's use case and without variation for different tiers or risk.

- **[REQ-AUTH-0]:** The product shall be integrated into a state of the art identity management system.

- **[REQ-AUTH-1]:** 2-factor authentication shall be used to confirm the identity of a natural user.

- **[REQ-AUTH-2]:** Authorisation validity for authenticated natural users shall be no longer than a two days.

When the identity of a user is established, the system grants the user access rights based on the users' role.The system can have multiple distinct roles, each are tailored to the users' 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 responsibiltiies or by aggregating many available roles to that single user.

In many systems identity information includes a group assignment matched to a role inside the system.

Role Based Access Control design and depth is outside of the scope of this standard, but the product must use some form of RBAC.

Both natural users, machine users, or equivalent structures need roles, despite often performing differently. Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)

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 device 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 is 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.

These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.

- **[REQ-AUTH-0]:** The product shall support identity management through at least one of the following approaches: (a) integration of the product into an external state-of-the-art Identity Management System, (b) integration of an external Identity Management System into the product, or (c) a dedicated Identity Management module built into the product.

- **[REQ-AUTH-1]:** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.

- **[REQ-AUTH-2]:** Product shall limit a natural user's authorisation validity of a session via a configurable setting that shall be initially limited by factory default of one day.

Depending on the product design, the identity management referred in [REQ-AUTH-0] 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 more likely to properly update or invalidate subjects credentials when necessary.

If the same system is used to grant the subjects access roles, for example through group membership, due diligence is required to assure that it 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.

It is more rare, that a person who focuses on financials would need access grants related to _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.

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

- **[REQ-AUTH-3]:** RBAC design shall follow the best practices of the deployment context.

- **[REQ-AUTH-4]:** The RBAC design and application in the product shall be documented.

- **[REQ-AUTH-5]:** All privileged interfaces shall implement RBAC.

- **[REQ-AUTH-6]:** All access to administrative interfaces, control functions, and sensitive operations shall be subject to strong authentication of users, services, or integrated components.

> **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, how the trust between the policy holder and the source environment is established can vary and there are different implementations in the market.

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.

This is the reason for the requirement [REQ-AUTH-3], but as the evaluating the fit of the implementation to the intended use, the design validation is only vaguely specified in the requirement [REQ-AUTH-4].

- **[REQ-AUTH-3]:** When a subject has been authenticated, the product shall apply authorisation controls based on assigned roles or equivalent access-control attributes.

- **[REQ-AUTH-4]:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.

- **[REQ-AUTH-5]:** The product technical documentation shall describe the identity and authorisation model implemented by the product.

- **[REQ-AUTH-6]:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.

- **[REQ-AUTH-7]:** Privileged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].

- **[REQ-AUTH-8]:** The product shall report all relevant events related to authorisation including, but not limited to, successful and unsuccessful use of identity, object access, policy change, privileged function use, data access and deletions, data changes and permission changes.

- **[REQ-AUTH-9]:** The product shall record the source of the identity in authoritative event monitoring data.

- **[REQ-AUTH-10]:** The product shall verify an explicit authorisation decision immediately before execution of any privileged action that can, including but not limited to, modify managed-element configuration, control-plane behaviour, routing or forwarding state, security policy, identity or authorisation configuration, cryptographic trust material, software state, availability, or network reachability.

- **[REQ-AUTH-11]:** The authorisation decision shall be bound to the acting identity, whether natural user or machine user, role or permission set, target managed element or elements, requested operation, material request parameters, policy version or rule identifier, and validity interval.

- **[REQ-AUTH-12]:** The product shall prevent execution of such privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event except if the action aims to enable or restore auditability of the product.

The requirement [REQ-AUTH-5] is intentionally vague.

The model can be complex, and there can be multiple different overlapping mechanisms in place that can used to enable the same function.

The authoritative decision making requirement listed as [REQ-AUTH-10] directs the product not to cache the credentials.

While the requirement calls for active checking, in combination with [REQ-AUTH-2] the wording leaves room to implement a fluent GUI experience when viewing the content and performing privileged actions are separated.

#### Machine users

Credential rotation addressed by [REQ-AUTH-11], is one of the key elements, that enable organisation to build resilience in a compromised network.

The rotation can replace keys or tokens to limit exposure from compromised credentials.

It can built on top of existing authority structures, or it can re-run some parts of the device initialisation procedures.

How the retake of the authority is implemented is between the product and the device.

<mark>TODO: define usage of machine credentials better, consider the cli over ssh controlled scenario</mark>

- **[REQ-AUTH-13]:** The product shall not implement a design where default machine user credentials are used.

- **[REQ-AUTH-14]:** The product shall support machine credential rotation or comparable structure.

- **[REQ-AUTH-15]:** The product shall provide passwordless authentication for machine users such as certificates or tokens.

- **[REQ-AUTH-16]:** The privileged interfaces like APIs shall support minimal access grants for the machine user.

<mark>TODO: evaluate if a large enterprise needs to have 3rd. party IdP as an integrateable option</mark>

### 5.2.7 Remote Data Processing Systems

### 5.3.5 Logging

In many product deployments, administrators manage monitoring tasks also with the analysis of product logging records.

In many product deployments, privileged users manage monitoring tasks also with the analysis of product logging records.

Especially when there are forensic demands, comprehensive and detailed logging becomes a larger challenge.

The logging requirements in this subclause define baseline event recording and additional protections for retention, integrity, backup, and external forwarding according to the applicable risk tier.