Audit Log: Immutability and Context of Security Events
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, its evidentiary value declines. Immutability controls, 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.
The evidentiary value of audit logs is achieved not just by the fact of their accumulation, but by the architectural separation of access rights, the use of standardized formats, and tools for detecting data modification.
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.
The international standard ISO/IEC 27001:2022, in control A.8.15, recommends implementing the maintenance, monitoring, and analysis of event logs. This standard is not universally mandatory for all organizations, but its implementation helps structure incident management processes. Control A.8.15 emphasizes that logs must be protected from unauthorized access, modification, and deletion, which requires engineers to use specialized architectural solutions.
- Forward Secure Sealing — a mechanism for verifying the integrity of sealed local systemd logs.
- ISO/IEC 27001 (A.8.15) — an international recommendation for maintaining, protecting, and regularly analyzing event logs.
- NIST SP 800-92 — a guide for building infrastructure for log collection, transmission, and long-term storage.
- RFC 5424 — a standard that defines the message structure for unifying logs from different systems.
Architectural separation of duties in event collection
According to the NIST SP 800-92 guide, one of the key methods for protecting logs is the Segregation of Duties. System administrators who manage servers and applications should not have the technical ability to modify or delete audit logs. This function should belong exclusively to security administrators or automated log collection systems.
To implement this principle, centralization is used: events are immediately forwarded from local nodes to an isolated repository. However, it must be taken into account that role separation, centralization, and access restrictions are architectural recommendations, not an absolute guarantee of security. If an attacker gains full control over the network infrastructure, they may still attempt to block data transmission.
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 — system administrators should not have rights to modify or delete logs in the repository.
- Centralization of collection — immediate transmission of events to a dedicated server to minimize local manipulation.
- Access restriction — granting access to logs based on work necessity with separate control of administrative rights.
- Completeness control — monitoring for gaps in the sequence of records to detect possible deletions.
Structuring metadata according to RFC 5424 specification
For effective security event analysis, it is critical to have structured data. The RFC 5424 standard defines the Syslog message format, which allows information to be transmitted as structured elements (Structured Data, SD-ID). This simplifies automated log processing by SIEM-class systems if senders consistently populate the required fields. The team must explicitly transmit the user identifier and application operation context: the format does not add them itself. Using structured data simplifies processing without the need for complex parsing of unstructured text and reduces the load on analytical systems when processing large information flows.
At the same time, the standard text field MSG (Message) remains part of the message to preserve a detailed description of the event. It must be noted that the RFC 5424 protocol only defines the data representation format. It does not guarantee message delivery and does not ensure their immutability during transmission. To protect the transmission channel, additional protocols such as TLS must be used.
Detecting modifications using Forward Secure Sealing technology
In cases where a local node temporarily loses connection to the central repository, logs accumulate locally. To protect this data from modification by attackers with superuser (root) privileges, the Forward Secure Sealing (FSS) technology is implemented in the systemd-journald logger.
FSS technology helps detect modification of previously sealed data, but it does not prevent the deletion of log files from the disk and does not guarantee the preservation of all events. The principle of FSS is based on periodic key evolution. The system's operating time is divided into time intervals (epochs). For each epoch, a new signing key is generated based on the previous one using a one-way function, after which the old key is irrevocably deleted from memory. If an attacker gains root privileges, they only possess the current key and cannot forge signatures for records from past epochs, which allows auditors to detect tampering during verification. This creates a reliable mechanism for controlling the integrity of local logs until they are transmitted to a central server.
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 — verifying that system administrators do not have write or delete rights in the central repository.
- Time synchronization — configuring a single NTP time source for all network nodes for accurate event correlation.
- FSS testing — regular execution of the verification utility to confirm the integrity of local logs.
- Transmission completeness check — comparing the number of locally generated events with the number received in the SIEM.
FAQ
How to verify that administrators truly do not have access to change logs?
A practical audit is conducted for this: a compromise of a system administrator account is simulated, attempting to clear or change records in the centralized repository. If the architecture is built correctly, the repository will reject the deletion request due to access restrictions at the log repository level itself.
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) technology guarantee the preservation of all events?
No, FSS does not prevent the deletion of log files from the disk and does not guarantee the delivery of all events. This technology is intended solely for detecting the fact of modification of previously sealed data, as an attacker will not have the old keys to re-sign past epochs after compromising the system.
