@@ -1406,7 +1406,7 @@ The assessment criteria for each security requirements are described in a struct
## 6.3 Secure by default configuration
## 6.3.1 SBDC - Access control
- REFERENCE: ACC_PKI_SBDC_01
- REFERENCE: ACC-PKI-SBDC-01
- OBJECTIVE:
- Verify that all system assets are identified as protected assets and that the default access control policy is configured to deny access unless an explicit permission is granted.
- PREPARATION:
@@ -1605,7 +1605,7 @@ The assessment criteria for each security requirements are described in a struct
## 6.5 Authentication and access control
### 6.5.1 AC - General
- REFERENCE: ACC_PKI_AAC_01
- REFERENCE: ACC-PKI-AAC-01
- OBJECTIVE:
Verify the product allows to create different user profiles (users with different access rights to functions, configuration, and stored data) for the roles defined by PKI policies, each with distinct credentials.
- PREPARATION:
@@ -1628,7 +1628,7 @@ The assessment criteria for each security requirements are described in a struct
- List of validated functionalities and data access rights for each user profile.
- Screenshots or logs of access attempts and rights verification.
- REFERENCE: ACC_PKI_AAC_02
- REFERENCE: ACC-PKI-AAC-02
- OBJECTIVE:
- Verify that the product only allows identified and authenticated authorized users to perform access-controlled actions.
- PREPARATION:
@@ -1646,7 +1646,7 @@ The assessment criteria for each security requirements are described in a struct
- Screenshots or logs of access attempts, rights verification, or rejected actions.
### 6.5.2 AC - Monitoring
- REFERENCE: ACC_PKI_AAC_03
- REFERENCE: ACC-PKI-AAC-03
- OBJECTIVE: Verify the product's ability to detect unauthorised modifications to the stored audit records during the audit.
@@ -2851,52 +2851,6 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- the size of the audit when full, or nearly so;
- the way the additional event was attempted to be triggered, and the corresponding response from the product.
- REFERENCE: ACC-PKI-MON-07
- OBJECTIVE:
- Verify the use of an audit log signing event by the product.
- PREPARATION: Ability to trigger auditable events, and ability to audit events.
- Determine the configured frequency of the audit log signing event and date of the audit log signing event. The frequency of the audit log signing event may be reduced; the event shall not be triggered manually.
- The list of auditable events may be reduced.
- Ability to verify the digital signatures, keyed hashes, or authentication codes used for the audit log signing event.
- Ability to modify audit records before verifying or re-verifying their digital signatures, keyed hashes, or authentication codes.
- ACTIVITIES: Trigger an auditable event.
- Wait until the next audit log signing event happens.
- Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is present in the audit log.
- Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is correct.
- Modify the audit record of the triggered event, and verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.
- Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.
- Restore the audit record of the triggered event, if necessary.
- Modify the second-to-last signature, keyed hash or authentication code.
- Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.
- Restore the second-to-last signature, keyed hash or authentication code, if necessary.
- Wait until the next audit log signing event happens, ensuring no auditable event happens in the meantime.
- Verify a new signature, keyed hash or authentication code, including at least the previous signature, keyed hash or authentication code, is present in the audit log.
- VERDICT:
- SUCCESS: Audit logs are periodically signed or authenticated, and any modification to logs or signatures is detected and causes verification to fail.
- FAIL: Audit log signatures are missing, incorrect, or can be modified without detection.
- EVIDENCE:
- The way the auditable event was triggered;
- the last entries of the audit log, including all the entries impacting the third-to-last audit log signing event and its signature, keyed hash or authentication code;
- the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the product;
- the way the audit record of the triggered event was modified;
- the way the second-to-last signature, keyed hash or authentication code was modified.
- REFERENCE: ACC-PKI-MON-08
- OBJECTIVE:
- Verify the frequency of the audit log signing event by the product to be configurable.
- PREPARATION:
- Ability to trigger auditable events, and ability to audit events. Ability to configure the frequency of the audit log signing event.
- ACTIVITIES:
- Modify the frequency of the audit log signing event.
- Wait sufficiently such that 2 audit log signing events occur.
- Access audit records, and verify the time between the last 2 audit log signing events corresponds to the newly configured frequency.
- VERDICT:
- SUCCESS: The audit log signing frequency is configurable and verified to be correctly applied in observed signing intervals.
- FAIL: The signing frequency cannot be configured or does not reflect the configured interval in actual audit log behavior.
- EVIDENCE:
- The new frequency which was configured;
- the 2 last audit log signing events as they appear in the audit log, and their corresponding date and time.
