@@ -209,111 +209,6 @@ As the product is delivered without known exploitable vulnerabilities, those leg
### 5.2.6 Identity and access management
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 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 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 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.
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 shall implement the identity and authorisation model that is considered to be secure.
-**[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 successfully 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.
-**[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.
@@ -1110,6 +1110,111 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
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 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 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.
***AAC_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.
***AAC_AUTH-1:** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.
***AAC_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 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.
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].
***AAC_AUTH-3:** When a subject has been authenticated, the product shall apply authorisation controls based on assigned roles or equivalent access-control attributes.
***AAC_AUTH-4:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.
***AAC_AUTH-5:** The product shall implement the identity and authorisation model that is considered to be secure.
***AAC_AUTH-6:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.
***AAC_AUTH-7:** Privileged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
***AAC_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.
***AAC_AUTH-9:** The product shall record the source of the identity in authoritative event monitoring data.
***AAC_AUTH-10:** The product shall verify successfully 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.
***AAC_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.
***AAC_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.
***AAC_MACHINE-13:** The product shall not implement a design where default machine user credentials are used.
***AAC_MACHINE-14:** The product shall support machine credential rotation or comparable structure.
***AAC_MACHINE-15:** The product shall provide passwordless authentication for machine users such as certificates or tokens.
***AAC_MACHINE-16:** The privileged interfaces like APIs shall support minimal access grants for the machine user.
