@@ -1222,12 +1222,6 @@ If an employee exits the company, their identity is expected to vanish or at lea
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.
@@ -1267,35 +1261,61 @@ Role Based Access Control design and depth is outside of the scope of this stand
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.
These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.
The requirement [REQ-AUTH-5] is intentionally vague.
***AAC_AUTH-1:** The product shall support identity management through at least one of the following approaches:
* integration of the product into an external state-of-the-art Identity Management System
* integration of an external Identity Management System into the product, or
* a dedicated Identity Management module built into the product.
***AAC_AUTH-2:** The product shall not implement a design where default credentials or keys are used to identify subjects.
***AAC_AUTH-3:** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.
***AAC_AUTH-4:** 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.
***AAC_AUTH-5:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.
***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.7.1 State-of-the-art cryptographic libraries](#571-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 verify successfully an explicit authorisation decision immediately before execution of any privileged action that can modify, including but not limited to:
* managed-element configuration
* control-plane behaviour routing or forwarding state
* security policy
* identity or authorisation configuration
* cryptographic trust material
* software state
* availability
* network reachability.
***AAC_AUTH-10:** The authorisation decision shall be bound to, and made available in auditable event data, including but not limited to:
* source of the identity
* 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-11:** 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 **AAC_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.
The authoritative decision making requirement listed as **AAC_AUTH-11:** directs the product not to cache the credentials.
While the requirement calls for active checking, in combination with **AAC_AUTH-4:** the wording leaves room to implement a fluent GUI experience when viewing the content and performing privileged actions are separated.
#### Machine users
### 5.6.1 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.
Credential rotation addressed by **INT_ROTATE-1** in [5.8.2 Cryptographic key intialisation and rotation](#582-cryptographic-key-intialisation-and-rotation), 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.
***AAC_MACHINE-1:** The product shall provide passwordless authentication for machine users such as certificates or tokens.
***AAC_MACHINE-2:** The privileged interfaces like APIs shall support minimal access grants for the machine user.
## 5.7 Confidentiality protection
@@ -2327,6 +2347,335 @@ Verify that:
## 6.6 Authentication and access control
### 6.6.1 AAC_AUTH-1
**Objective:** Support reasonable identity management.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Study the documented deployment guidance.
**Verdict:**
1. Pass if one of the listed methods is supported.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.2 AAC_AUTH-2
**Objective:** Prevent accidental breaches due to lack of oversight.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Study the documented deployment guidance.
**Verdict:**
1. Pass if no predefined secrets or keys are used to identify the first subject.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.3 AAC_AUTH-3
**Objective:** Verify the important users through other means than one.<br/>
**Preparation:**
1. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the multifactor authentication implementation.
**Verdict:**
1. Pass if MFA is used and is required from the authenticating human user.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.4 AAC_AUTH-4
**Objective:** Have an ability to adopt the system users entity context practices.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the product and the documentation.
**Verdict:**
1. Pass if default is set to the required limit and user has an ability to reconfigure it.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.5 AAC_AUTH-5
**Objective:** Limit the user access to a reasonable set of rights.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the product and the documentation
**Verdict:**
1. Pass if the roles defined or suggested structures are fit for the product target audience.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.6 AAC_AUTH-6
**Objective:** Protect the control functions and the data.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the product and the documentation
2. Identify all interfaces that are used to interface with users, other systems or components.
**Verdict:**
1. Pass if authenticaton and authorisation is performed on discovered interfaces.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.7 AAC_AUTH-7
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the product and the documentation
2. Identify all interfaces that are used to interface with users, other systems or components.
**Verdict:**
1. Pass if the discovered interface implement cryptography based on Annex K in the default settings.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.8 AAC_AUTH-8
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Tricker listed activities.
**Verdict:**
1. Pass if an auditable event is emited.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.10 AAC_AUTH-9
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Tricker listed activities.
**Verdict:**
1. Pass if auditable event is emitted for each different category.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.11 AAC_AUTH-10
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the system.
2. Tricker a security policy change.
**Verdict:**
1. Pass if auditable event is emitted with the listed information.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.12 AAC_AUTH-11
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the system;
2. Tricker listed activites.
**Verdict:**
1. Pass if excution of privileged action fails in the described conditions.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.1.1 AAC_MACHINE-1
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the system.
**Verdict:**
1. Pass if an altertanive to preshared keys or passwords is provided.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.6.1.2 AAC_MACHINE-2
**Objective:**<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Study the technical documentation how to interact with the system;
**Activities:**
1. Investigate the system.
**Verdict:**
1. Pass if the machine access credentials do not inherit wider access rights than the purpose of the interraction requires within reasonable limits.
2. Fail otherwise.
**Supporting Evidence:**
* Metrics output showing detected system or managed element crash or restart with the reported cause;
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
