UA EN
Support

Audit Log: Immutability and Context of Security Events

By:

· Updated · 9 min

An audit log should do more than record an event: it must preserve enough context to reconstruct the sequence, including who performed the action, when it occurred, and which system sent the request. If a privileged user can alter records without detection, or if the log does not link an event to its user and system, technical trust in the log declines. Protection against undetected alteration, transfer to a separate repository, and completeness checks therefore need to be designed into the logging architecture before an incident, not added only during an investigation.

Technical trust in audit logs depends not only on retaining them, but also on separating access rights, recording standardized context, and using verifiable tamper-detection mechanisms.

In this article, “evidentiary value” means the technical ability to verify recorded provenance, context, sequence, and signs of undetected alteration within a defined trust model. It does not automatically guarantee source authenticity, non-repudiation, or legal admissibility; those depend on the applicable procedural, contractual, and sector-specific requirements.

Different mechanisms provide different guarantees: access control limits actors and allowed operations; WORM or retention lock prevents overwriting for a defined period; and HMACs or digital signatures make tampering detectable or establish origin within a particular scheme. Sending records to a SIEM does not by itself turn it into an immutable repository.

Regulatory guidelines and scope of standard application

A logging policy begins with a list of events and those responsible for their analysis. For each source, the team defines the collection goal, the required context, access to records, and the method for verifying transmission. NIST SP 800-92 views log management as a combination of infrastructure and processes. Therefore, the choice of format or storage should be supplemented with operational rules: who checks for gaps, who reacts to collector failures, and how configuration changes are logged.

Annex A of ISO/IEC 27001:2022 includes reference control A.8.15 for creating, retaining, protecting, and analyzing relevant logs; monitoring systems for anomalous behavior is addressed separately by A.8.16. The organization selects and documents applicable controls through risk treatment and the Statement of Applicability, while ISO/IEC 27002:2022 provides more detailed implementation guidance. ISO/IEC 27001 is not universally mandatory for every organization and does not by itself prescribe one technical architecture for a log repository.

  • Forward Secure Sealing — a mechanism for verifying the integrity of sealed local systemd logs.
  • ISO/IEC 27001 (A.8.15) — the logging control in Annex A; ISO/IEC 27002 provides more detailed implementation guidance.
  • NIST SP 800-92 — guidance on infrastructure and processes for generating, transmitting, storing, analyzing, and disposing of logs.
  • RFC 5424 — a standard that defines the message structure for unifying logs from different systems.

Architectural separation of duties in event collection

NIST SP 800-92 recommends separating duties between administrators of individual systems and personnel who manage the centralized log-management infrastructure, but it does not establish a universal ban on source administrators working with local logs. The specific roles depend on the operating model and selected controls. For stricter scenarios, NIST SP 800-53 control AU-9 addresses protection of audit information, with enhancements for a separate repository and limiting audit privileges to a subset of privileged roles. A central repository for critical logs should be configured so that a source administrator cannot alter or delete accepted records without detection.

To implement this principle, events are sent to a separate centralized repository at a frequency determined by risk and buffered locally during connectivity loss. Role separation, centralization, and access restrictions reduce risk but do not provide an absolute guarantee: an attacker who controls a node or the network can block transmission before an event is accepted. The health of agents and collectors, lag, retries, and sequence gaps therefore need separate monitoring.

In an integration project, the event collection system should be considered separately from application logs. The technical specification can include a list of sources, transmission rules, an access model, and connectivity loss checks. The acceptance of such a solution should be based on agreed-upon criteria and documented checks; the mere existence of a log does not confirm that all security requirements have been met.

  • Role separation — a source administrator does not manage records already accepted by the central repository; retention and maintenance operations follow a separately controlled procedure.
  • Centralized collection — transmission to a separate repository with local buffering, retries, and alerts for agent, collector, or connectivity failures.
  • Access restriction — granting access to logs based on work necessity with separate control of administrative rights.
  • Completeness control — reconciling identifiers, sequences, or checkpoints for each source and detecting gaps between the source and repository.

Structuring metadata with RFC 5424

RFC 5424 defines a transport-independent syslog protocol and message format. The STRUCTURED-DATA field can contain one or more SD-ELEMENT values; each element has an SD-ID and zero or more SD-PARAMs. The standard provides a container but not application semantics: the source must explicitly supply the user identifier, operation, object, outcome, and correlation ID. Structured fields can simplify SIEM parsing when a consistent schema is used, but the format does not itself guarantee a lower processing load.

The optional MSG (Message) text field can provide a detailed event description. RFC 5424 defines a transport-independent syslog protocol and message format, but it does not by itself guarantee that a collector accepted and durably stored every event. For channel confidentiality and integrity, syslog can use the TLS transport standardized by RFC 5425. TLS does not replace application-level acknowledgement, gap detection, or protection of logs after they are written to storage.

Detecting modifications using Forward Secure Sealing technology

When a local node temporarily loses connection to the central repository, logs may accumulate locally. Forward Secure Sealing (FSS) in systemd-journald helps detect tampering with already sealed ranges after a node is compromised. It is an integrity-verification mechanism, not a control that makes files physically undeletable.

FSS periodically evolves the sealing-key state and adds SHA-256 HMAC tags for time intervals. Compromise of the current state should not allow valid HMACs to be calculated for already sealed history; this is forward-secure sealing, not a digital signature. FSS must be configured in advance: the sealing key remains on the host, while systemd recommends storing the verification key externally. The journalctl --verify command without a key checks internal file consistency, whereas authenticity of FSS-sealed intervals is checked with journalctl --verify --verify-key=…. FSS does not establish the truth of the source event, protect the current unsealed interval, prevent logging from being disabled, stop deletion of an entire file or replacement with an older valid copy, or prove delivery completeness. Those risks require a centralized copy or external checkpoints, backups, and monitoring; FSS provides tamper evidence, not a self-sufficient immutable repository.

Practical steps for verifying log integrity

Building a reliable logging system requires the regulation of rotation, archiving, and integrity verification processes. An organization must independently determine log retention periods in accordance with internal risk assessments and regulatory requirements, as there is no single mandatory period for all companies.

Before implementing technical protection measures, it is recommended to conduct an internal audit: check access rights to local and centralized repositories, configure time synchronization on all nodes, and ensure that message formats allow for the unambiguous identification of users performing critical operations in the system.

  • Access-rights audit — checking the effective permissions of source and centralized-logging administrator roles: altering, deleting, or truncating records; managing retention; forwarding; and collector configuration.
  • Time synchronization — a controlled and monitored time infrastructure with independent fallback sources and clock-offset monitoring; when correct time is critical, RFC 8633 recommends at least four independent, diverse sources.
  • FSS testing — separate checks of internal consistency with journalctl --verify and authenticity of sealed intervals using an externally stored verification key.
  • Transmission completeness check — reconciling stable event identifiers, per-source sequence numbers, or checkpoints, and detecting gaps, duplicates, and acknowledgement state. Record counts are only a supporting metric after allowed filtering and transformations are considered.

FAQ

How do you verify administrators’ effective permissions to alter audit logs?

In a test environment or an approved control window, check the effective permissions of every administrative role, including source, collector, repository, and emergency-access administrators. Test overwrite, truncate, delete, retention changes, forwarding disablement, administrative-API bypasses, and alerting. If deletion must be technically impossible during a defined period, use WORM, retention lock, or an equivalent write-once mechanism; there is no need to simulate a real compromise of a production account.

What log retention periods are mandatory for organizations?

There is no universal retention period for all organizations. Periods are determined by internal security policies, requirements of specific industry standards, or regulatory acts applicable to a specific type of enterprise or critical infrastructure facility.

Does Forward Secure Sealing (FSS) guarantee preservation of every event?

No. FSS with an externally stored verification key helps verify the authenticity of already sealed intervals, but it does not guarantee creation, delivery, or retention of every event. It does not prevent deletion of an entire file, disabling future sealing, or recording a false source event. Completeness and retention require separate centralized-collection, checkpointing, backup, and access-control mechanisms.

Sources

Tags: #Cybersecurity #Standards & Certification #Public Sector