Minor changes to AAC_AUTH assessments

### 6.6.1 AAC_AUTH-1

**Objective:** Support reasonable identity management.

**Objective:** Identity management as basis for authentication is supported.

**Preparation:**

### 6.6.2 AAC_AUTH-2

**Objective:** Prevent accidental breaches due to lack of oversight.

**Objective:** Any subject receives an individual key, either on board generated or imported.

**Preparation:**

### 6.6.3 AAC_AUTH-3

**Objective:** Verify the important users through other means than one.

**Objective:** System users are identified with multi-factor authentication.

**Preparation:**

**Activities:**

1. Investigate the multifactor authentication implementation.

1. Investigate the multifactor authentication implementation;

2. Try to access with a wrongly applied authentication method.

**Verdict:**

1. Pass if MFA is used and is required from the authenticating human user.

2. Fail otherwise.

1. Pass, if MFA is used and is required from the authenticating human user

2. and if the authentication with the wrongly applied method was rejcted.

3. Fail otherwise.

**Supporting Evidence:**

* Screenshots, captures, or console outputs confirming the correct authentication with MFA;

* Logs from the authentication and rejection events;

* Metrics output relevant for the activities, if available;

* 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

**Activities:**

1. Investigate the product and the documentation.

2. Check and set the duration of a session to a duration suitable for the assessment.

3. Launch the session and keep it passive while measuring the time elapsing.

**Verdict:**

1. Pass if default is set to the required limit and the user has an ability to reconfigure it.

2. Fail otherwise.

1. Pass, if default is set to the required limit and the user has an ability to reconfigure it

2. and the session gets terminated after reaching the set time and that meets the applied setting

3. Fail otherwise.

**Supporting Evidence:**

### 6.6.5 AAC_AUTH-5

**Objective:** Limit the user access to a reasonable set of rights.

**Objective:** Authorised users have assigned execution and resource access rights.

**Preparation:**

**Activities:**

1. Investigate the product and the documentation

1. Investigate the product and the documentation;

2. Try to execute commands not assigned to the present user role.

**Verdict:**

1. Pass if the roles defined or suggested structures are fit for the product target audience.

2. Fail otherwise.

1. Pass, if the user roles defined or other structures match with the assigned rights

2. and the command execution beyond the present user role gets rejected.

3. Fail otherwise.

**Supporting Evidence:**

* Screenshots, captures, or console outputs proving the users execute commands and access only those records that are permitted to their role.

* Evidence from the command rejection.

* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

* Metrics output relevant for the activities, if available;

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

**Objective:** All interfaces, controls and sensitive operations are protected by authorisation.

**Preparation:**

**Supporting Evidence:**

* List of the tested product user interfaces and assigned evidence of the authentication and authorisation operation and their results.

* Metrics output relevant for the activities, if available;

* Relevant vendor or design documentation describing the applied measures;

* Test reports showing the steps performed and results obtained;

### 6.6.7 AAC_AUTH-7

**Objective:** Ensure confidentiality of the IAM.

**Objective:** The authentication and communication on all product user interfaces is cryptographically appropriately protected.

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;

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.

1. Investigate the product and the documentation;

2. Identify all interfaces that are used to interface with users, other systems or components;

3. Check whether each interface deploys a protocol with appropriate cryptography from CON_CRYPTO-1.

**Verdict:**

**Supporting Evidence:**

* List of interfaces and their operated protocols with assigned cryptographic methods;

* Screenshots, captures, or console outputs confirming the matched protocol execution;

* Metrics output relevant for the activities, if available;

* 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:** Ensure auditability of the system.

**Objective:** Any event in relation with user authorisation gets a logging record.

**Preparation:**

**Activities:**

1. Tricker listed activities.

1. To tricker listed activities:

   1. Login to a user role that does not have access to the listed activities;

   2. Try to escalate the authorisation by calling a command not allowed for the present role.

**Verdict:**

1. Pass if an auditable event is emitted.

2. Fail otherwise.

1. Pass, if the activity is rejected

2. and an auditable event is emitted.

3. Fail otherwise.

**Supporting Evidence:**

* Log record from the command rejection

* Metrics output relevant for the activities, if available;

* 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

### 6.6.9 AAC_AUTH-9

**Objective:** Ensure privileged action correctens a the time of the execution.

**Objective:** All privileged actions receive an authorisation before their execution.

**Preparation:**

**Activities:**

1. Tricker listed activities.

1. Login to a user role;

2. Try to escalate the authorisation by calling a command not allowed for the present role;

3. Execute at least listed activities.

**Verdict:**

1. Pass if an auditable event is emitted for each different category.

2. Fail otherwise.

1. Pass, if the execution is rejected

2. and an auditable event is emitted for each different activitity.

3. Fail otherwise.

**Supporting Evidence:**

* Evidence like screenshots and logs about login procedure, escalating command call and the product reaction;

* Metrics output relevant for the activities, if available;

* 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

### 6.6.10 AAC_AUTH-10

**Objective:** Ensure auditability of the system.

**Objective:** The authorisation for a privileged action is recorded in the log files.

**Preparation:**

**Activities:**

1. Investigate the system.

2. Tricker a security policy change.

2. Login and trigger a security policy change as privileged action.

**Verdict:**

**Supporting Evidence:**

* Printout of logging records documenting the authorisation permission for the security policy change;

* Metrics output relevant for the activities, if available;

* 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

### 6.6.11 AAC_AUTH-11

**Objective:** Ensure auditability of the system.