@@ -1075,7 +1075,7 @@ These requirements are about the collection and handling of "auditable events",
- REFERENCE: REQ-5.1-06
- REQUIREMENT: The product shall prevent auditable events, except those taken by the auditor, if the audit log is full.
- RATIONALE: If the PKI system is properly deployed—with appropriate policies, effective system management, and regular log reviews—an overload of logs should be seen as a symptom of a potentially significant security issue. In such cases, corrective actions should be taken before operations return to normal. Meanwhile, a full audit log should never result in the loss of old audit records or prevent future auditable events from being recorded. The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Disclosure
- APPLICABILITY: Not applicable when product operates using log rotation/pruning or any other mechanisms ensuring that audit logs cannot be full.
- APPLICABILITY: Not applicable where the product implements or supports automatic log management mechanisms (e.g. log rotation with archival, log pruning, log forwarding to an external system) ensuring continuity of audit recording without data loss.
- REFERENCE: REQ-5.1-07
- REQUIREMENT: The product shall periodically create an audit log signing event in which it computes a digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature, keyed hash, or authentication code shall be computed over, at least:
@@ -1091,9 +1091,8 @@ NOTE: An audit log signing event is performed even if no entry was added to the
It covers misuse of users and administrators function : T_SYS02,T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Disclosure.
- APPLICABILITY: UC1, UC2
- NOTE: Not all integrity protection mechanisms can be foreseen so for use cases with lower regulation of standardization constraints (UC1, UC2) other appoaches can be valid and so not identified here.
- NOTE: Not all integrity protection mechanisms can be foreseen so for use cases with lower regulation of standardization constraints (UC1, UC2) other approaches can be valid and so not identified here.
Acceptable mechanisms include: append-only log storage, file-system integrity monitoring, hash-chained log entries, or forwarding to a trusted external log management system. The choice should be proportionate to the risk profile.