@@ -2652,7 +2652,9 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- ACTIVITIES:
- Verify that authorized users can modify the `issuer`, `issuerAltName`, `nextUpdate`.
- Verify that no CRL may be issued until acceptables values for the issuer, issuerAltName and nextUpdate fields and extensions are set.
- VERDICT: SUCCESS if the verifications passes; else FAIL.
- VERDICT:
- SUCCESS: Authorized users can configure the acceptable values for `issuer`, `issuerAltName`, and `nextUpdate`, and no CRL can be issued until all required values are properly set.
- FAIL: The product does not allow configuration of acceptable values for the required fields, or it issues CRLs before these values are fully defined.
- EVIDENCE: The way CRLs were requested, and the responses from the product.
- REFERENCE: ACC-PKI-EMM-011
@@ -2661,21 +2663,27 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- ACTIVITIES:
- Request an OCSP response;
- verify the OCSP response to match the constraints of the OCSP response profile.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: All issued OCSP responses conform to the defined OCSP response profile, including all required constraints and structure validation.
- FAIL: Any OCSP response is issued that does not conform to the OCSP response profile or violates its defined constraints.
- EVIDENCE: The way the OCSP response was requested, and the response and OCSP response from the product.
- REFERENCE: ACC-PKI-EMM-012
- OBJECTIVE: Verify that the product requires the authorized users to specify the set of acceptable values for the responseType field.
- PREPARATION: Authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.
- ACTIVITIES: Verify that no OCSP response may be issued until acceptable values for the responseType field are set.
- VERDICT: SUCCESS if all the verification pass; else FAIL.
- VERDICT:
- SUCCESS: OCSP responses cannot be issued until acceptable values for the `responseType` field are configured.
- FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responseType`.
- EVIDENCE: The way OCSP responses were requested, and the responses and OCSP responses from the product.
- REFERENCE: ACC-PKI-EMM-013
- OBJECTIVE: Verify that the product requires the authorized users to specify the set of acceptable values for the responderID field.
- PREPARATION: Authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.
- ACTIVITIES: Verify that no OCSP response may be issued until acceptable values for the responderID field are set.
- VERDICT: SUCCESS if all the verification pass; else FAIL.
- VERDICT:
- SUCCESS: OCSP responses cannot be issued until acceptable values for the `responderID` field are configured.
- FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responderID`.
- EVIDENCE: The way OCSP responses were requested, and the responses and OCSP responses from the product.
## 6.13 Logging and monitoring
@@ -2743,7 +2751,9 @@ REFERENCE: ACC_PKI_MON_02
- Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified by the developper.
- For each information verified to be present, verify it matches the expected value given when and how the event was triggered.
- For each of the generated audit record, verify that no private or symmetric key, as well as no other secret parameter is present in plaintext form.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: All audit records include required metadata (timestamp, event type, subject identity where applicable, outcome) and contain no secret or sensitive key material in plaintext.
- FAIL: Audit records are missing required fields, contain incorrect values, or expose secret/sensitive key material in plaintext.
- EVIDENCE: The way the events were triggered and at what time, and the corresponding audit records.
- REFERENCE: ACC_PKI_MON_03
@@ -2756,7 +2766,9 @@ REFERENCE: ACC_PKI_MON_02
- Repeat the above several times from different accesses to the product in parallel and verify the produced time stamps from the product to be monotonic.
- If the product may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.
- If the product may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the product until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: Audit timestamps are reliable, monotonic where applicable, and securely derived from trusted and authenticated time sources or correctly maintained local time mechanisms.
- FAIL: Audit timestamps are unreliable, non-monotonic, unauthenticated, or otherwise inconsistent with trusted time sources.
- EVIDENCE:
- The way the events were triggered and at what time, and the corresponding audit records;
- arguments relating to the authentication of a trusted source (if applicable);
@@ -2771,7 +2783,9 @@ REFERENCE: ACC_PKI_MON_02
- ACTIVITIES: Identify to the product as the given user. Trigger an auditable event as the given user. Access the corresponding audit record.
- Verify the audit record contains the identity of the user that caused the event.
- Verify this identity to match that of the given user.
- VERDICT: SUCCESS if all the verifications pass; else FAIL.
- VERDICT:
- SUCCESS: Audit records cannot be deleted by unauthorized users, and all protected audit logs remain intact after attempted deletion actions.
- FAIL: Unauthorized users can delete or alter audit records, or audit data is not preserved after deletion attempts.
- EVIDENCE:
- The identity of the given user used for the test;
- the way the event was triggered and at what time, and the corresponding audit record.
@@ -2802,7 +2816,9 @@ REFERENCE: ACC_PKI_MON_02
- Verify that a given additional auditable event cannot be performed.
- Identify as an auditor to the product.
- Verify that a given additional auditable event may be triggered as the auditor.
- VERDICT: SUCCESS if the verification passes; else FAIL.
- VERDICT:
- SUCCESS: When the audit log is full, non-auditor actions are blocked while auditor actions remain permitted and correctly recorded.
- FAIL: The system continues to allow non-auditor actions when the log is full, or improperly blocks auditor actions.
- EVIDENCE:
- The configured maximum size of the audit log;
- the size of the audit when full, or nearly so;
@@ -2828,8 +2844,9 @@ REFERENCE: ACC_PKI_MON_02
- 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 if all the verifications pass; else FAIL.
- 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;
@@ -2846,10 +2863,12 @@ REFERENCE: ACC_PKI_MON_02
- 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 if the verification passes; else FAIL.
- 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:
a) The new frequency which was configured;
b) the 2 last audit log signing events as they appear in the audit log, and their corresponding date and time.
- 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.
