@@ -799,16 +799,16 @@ A secure product is able confirm the identity and authority of all users perform
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.
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.
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 sepertate systems often relates to system and network size and in smaller systems identity management and authorization are often combined.
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)
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.
The interfaces designed for the machine users can be used by other privileged subjects.
As adminstrator is often a priviledged natural user, but the machine user making changes is not nessesarily an administrator, this document refers to both as privileged subject whom are often connecting to privileged interfaces.
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.
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.
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.
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 datail in the section [4.8 Operational Environment](#48-operational-environment).
The operative context is described in more detail in the section [4.8 Operational Environment](#48-operational-environment).
#### Identity management
#### Identity management
@@ -818,7 +818,7 @@ The identity management system maintains a list of trusted sources, one or more,
An up-to-date source of identity is essential.
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 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.
If an employee exits the company, their identity is expected to vanish or at least reflect the contractual status of the employee.
The idenity management is often assessed as part of certification processes, and is outside of this document. [\[i.12\]](#_ref_i.12)
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.
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.
These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.
@@ -827,24 +827,24 @@ These requirements apply to the product, regardless of the product's use case an
-**[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-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.
-**[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 deseriable or necessary.
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 indentity management system is more likely to properly update or invalidate subjects credentials when 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.
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.
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.
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 withing the budget.
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
#### Attribute-Based Access Control
Role based access control might be too coarse for some applications, like machine user access grants.
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 assosiated with the request.
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).
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.
The attributes that formulate the identity portion of the grant are often matched with a target action.
> **ABAC Example:**
> **ABAC Example:**
> An identified wokflow execution A in a trusted environment B can ammend 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.
> 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.
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.
@@ -855,31 +855,31 @@ Attribute-Based Access Control design and implementation is outside of the scope
When the identity of a subject is established, the system grants the subject access rights based on the subjects' role.
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.
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.
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 subject.
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.
Role Based Access Control design and depth is outside of the scope of this standard.
#### Generic requirements
#### 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.
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 intented use, the design validation is only vaguely specified in the requirment [REQ-AUTH-4].
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-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-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 authorization model implemented by 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-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-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-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-9]:** The product shall record the source of the identity in authoritative event monitoring data.
-**[REQ-AUTH-10]:** The product shall verify an explicit authorization 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 authorization configuration, cryptographic trust material, software state, availability, or network reachability.
-**[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 authorization 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-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 authorization 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.
-**[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 itentionally vague.
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 model can be complex, and there can be multiple different overlapping mechanisms in place that can used to enable the same function.
The authorative decission making requirement listed as [REQ-AUTH-10] directs the product not to cache the credentials.
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.
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.
