- Verify that the product implements only the interfaces required to support the use case as defined in Annex U.
- Verify that no additional, undocumented, unnecessary, or unauthorized interfaces are present or accessible.
- PREPARATION:
- List of use case interfaces as defined in Annex U.
- Product architecture documentation, interface specifications, and deployment documentation.
- Identify all communication interfaces that may be exposed by the product, including:
- Network services and listening ports.
- Administrative interfaces.
- Web interfaces and APIs.
- Command-line interfaces.
- Database interfaces.
- File transfer interfaces.
- Prepare test tools capable of identifying exposed interfaces (e.g., port scanners, API discovery tools, operating system service enumeration utilities).
- Product in executable state
- ACTIVITIES:
- Review the product documentation and identify all interfaces required by the use case.
- Enumerate all implemented interfaces exposed by the product in its operational configuration.
- For each discovered interface:
- Determine its purpose and associated functionality.
- Verify that it is explicitly required by the use case.
- Attempt to identify undocumented or hidden interfaces by:
- Enumerating network ports and services.
- Inspecting running processes and service configurations.
- Discovering accessible APIs and endpoints.
- Reviewing installation packages and configuration files for additional services.
- Verify that:
- No additional interfaces are active beyond those identified for the use case.
- Disabled or unsupported interfaces cannot be accessed or enabled without authorization.
- Administrative, debugging, maintenance, or test interfaces are either absent or explicitly identified and justified by the use case.
- Document the mapping between each implemented interface and its corresponding Annex U use case.
- VERDICT:
- SUCCESS:
- Every implemented interface can be mapped to one or more interface identified for the use cases in Annex U.
- No undocumented, unnecessary, or unauthorized interfaces are present.
- No hidden, debugging, maintenance, or test interfaces are accessible unless explicitly required by the use case.
- The implemented interfaces are limited to those necessary to provide the use case functionality.
- FAIL:
- One or more implemented interfaces cannot be mapped to an interface required for the use cases.
- Additional, undocumented, or unnecessary interfaces are present or accessible.
- Hidden, debugging, maintenance, or test interfaces are exposed without explicit authorization or justification.
- EVIDENCE:
- Interface inventory showing all implemented interfaces.
- Mapping matrix between implemented interfaces and Annex U use case.
- Results of network port scans and service enumeration.
- API discovery results and endpoint listings, where applicable.
- Screenshots or reports showing active services and interfaces.
- Test records demonstrating that no additional interfaces are present or accessible.
## 6.12 Exploitation mitigation mechanisms
### 6.12.1 Certificate issuance
@@ -2837,195 +2886,176 @@ and REQ-PKI-EMM-04.
## 6.13 Logging and monitoring
REFERENCE: ACC_PKI_LOG_01
- OBJECTIVE: Verify that the product records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.
- REFERENCE: ACC-PKI-MON-01
- OBJECTIVE:
- Verify that the product records audit events for:
- All product functions associated with the use cases defined in Annex U.
- All privileged user login attempts, including both successful and failed attempts.
- All product update activities.
- PREPARATION:
- List of PKI functions associated to the use cases as defined in Annex U.
- List of privileged user roles supported by the product (e.g., PKI Administrator, Registration Authority Operator, Auditor, System Administrator).
- Product in executable state and sufficient testing environment to activate desired functions.
- Ensure the audit log storage is empty or note the current audit log state before testing.
- Prepare test accounts for privileged users.
- ACTIVITIES:
- Enable and verify audit logging functionality.
- Execute each function identified in Annex U for the chosen use case.
- For each executed function:
- Perform at least one successful operation.
- Where applicable, perform an unsuccessful or rejected operation.
- Verify that an audit event is generated.
- Using privileged user accounts:
- Attempt successful logins.
- Attempt failed logins using invalid credentials.
- Attempt logins for disabled or locked accounts, if supported.
- Verify that each login attempt generates an audit event.
- Perform one or more product update operations when they exist, such as:
- Software update installation.
- Configuration package update.
- Security patch application.
- Version upgrade.
- Verify that each update activity generates an audit event.
- VERDICT:
- SUCCESS:
- Audit records are generated for all functions.
- Audit records are generated for all successful and failed privileged user login attempts.
- Audit records are generated for all product update activities.
- No required events are missing from the audit logs.
- FAIL:
- One or more functions do not generate audit records.
- Privileged user login attempts are not consistently recorded.
- Product update activities are not recorded.
- Audit records lack sufficient information for accountability or traceability.
- Audit logging can be bypassed, disabled without authorization, or fails to capture required events.
- EVIDENCE:
- Audit log extracts.
- Screenshots or exported reports of the audit logging interface.
- Test execution records mapping each test activity to its corresponding audit event.
- List of executed test cases and their corresponding timestamps and log entries.
- PREPARATION: Ability to trigger auditable events, and ability to audit events.
REFERENCE: ACC_PKI_MON_02
- OBJECTIVE:
- Verify that the product records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.
- PREPARATION:
- Ability to trigger auditable events, and ability to audit events.
- ACTIVITIES: Trigger an auditable event. Access the corresponding audit record.
- Verify the audit record contains at least:
a) the date and time of the event;
b) the type of the event;
c) the subject identity (if applicable);
d) the outcome of the event.
- 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.
- EVIDENCE: The way the events were triggered and at what time, and the corresponding audit records.
- REFERENCE: ACC_PKI_LOG_02
- OBJECTIVE: Verify that the product employs reliable time stamps.
- PREPARATION: Ability to trigger auditable events, and ability to audit events. Obtain access to a trusted time stamp origin. Determine how the product determines its time stamps.
- REFERENCE: ACC_PKI_MON_03
- OBJECTIVE:
- Verify that the product employs reliable time stamps.
- PREPARATION:
- Ability to trigger auditable events, and ability to audit events.
- Access to a trusted time stamp origin. Determine how the product determines its time stamps.
- ACTIVITIES: Trigger an auditable event. Access the corresponding audit record. Verify the date and time of the event to match the trusted time stamp origin.
- 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.
- EVIDENCE:
a) The way the events were triggered and at what time, and the corresponding audit records;
b) arguments relating to the authentication of a trusted source (if applicable);
c) arguments relating to the monotonicity of local time information (if applicable).
- REFERENCE: ACC_PKI_LOG_03
- OBJECTIVE: Verify that the product records within each audit record resulting from actions of identified users the corresponding user information.
- PREPARATION: Ability to identify to the product as a given user. Ability to trigger auditable events as a user, and ability to audit events.
- REFERENCE: ACC_PKI_MON_04
- OBJECTIVE:
- Verify that the product records within each audit record resulting from actions of identified users the corresponding user information.
- PREPARATION:
- Ability to identify to the product as a given user.
- Ability to trigger auditable events as a user, and ability to audit events.
- 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.
- EVIDENCE:
a) The identity of the given user used for the test;
b) the way the event was triggered and at what time, and the corresponding audit record.
- REFERENCE: ACC_PKI_LOG_04
- OBJECTIVE: Verify product protections from unauthorised deletion to be active and functional.
- PREPARATION: Ability to identify to the product as a given user, unauthorised to perform audit record deletion. Ability to trigger auditable events as a user, and ability to audit events. Determine all actions that may result in deletion of an audit record. Depending on this list of actions, several distinct users with distinct authorizations may be used.
- ACTIVITIES: Identify to the product as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.
- REFERENCE: ACC_PKI_MON_04
- OBJECTIVE:
- Verify product protections from unauthorised deletion to be active and functional.
- PREPARATION:
- Ability to identify to the product as a given user, unauthorised to perform audit record deletion. Ability to trigger auditable events as a user, and ability to audit events.
- Listof all actions that may result in deletion of an audit record. Depending on this list of actions, several distinct users with distinct authorizations may be used.
- ACTIVITIES:
- Login as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.
- Attempt to perform all actions identified as possibly resulting in an audit record deletion; re-identifying to the product as necessary.
- Access audit records and verify they match the copy performed previously.
- VERDICT: SUCCESS if the verification passes; else FAIL.
- EVIDENCE:
a) The identity of the given user(s) used for the test;
b) the list of identified actions that may result in deletion of an audit records;
c) the way the actions were attempted, including the corresponding user identity;
d) the copies of existing audit records, before and after attempts.
- REFERENCE: ACC_PKI_LOG_05
- OBJECTIVE: Verify the product's prevention of auditable events, except those taken by the auditor, if the audit log is full.
- PREPARATION: Ability to trigger auditable events, and ability to audit events. The maximum size of the audit log may be reduced.
- REFERENCE: ACC_PKI_MON_05
- OBJECTIVE:
- Verify the product's prevention of auditable events, except those taken by the auditor, if the audit log is full.
- PREPARATION:
- Ability to trigger auditable events, and ability to audit events. The maximum size of the audit log may be reduced.
- ACTIVITIES: Do not identify as an auditor to the product. Trigger auditable events until the audit log is full, or nearly so.
- 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.
- EVIDENCE:
a) The configured maximum size of the audit log;
b) The size of the audit when full, or nearly so;
c) the way the additional event was attempted to be triggered, and the corresponding response from the product.
- REFERENCE: ACC_PKI_LOG_06
- OBJECTIVE: Verify the use of an audit log signing event by the product.
- REFERENCE: ACC_PKI_MON_06
- 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 if all the verifications pass; else FAIL.
- EVIDENCE:
a) The way the auditable event was triggered;
b) 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;
c) the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the product;
d) the way the audit record of the triggered event was modified;
e) the way the second-to-last signature, keyed hash or authentication code was modified.
- REFERENCE: ACC_PKI_LOG_07
- 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.
- REFERENCE: ACC_PKI_MON_07
- 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 if the verification passes; else FAIL.
- 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.
