ASD ISM 1977 Central logging of Linux system events
What it says
Security-relevant events for Linux operating systems are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishImportant Linux system events should be logged in a central location for security purposes.
This control is about making sure all important events happening on your Linux computers are recorded in one central place. It matters because if something goes wrong, like a security breach, you want to know exactly what happened and when. Without this logging, it would be challenging to spot issues or figure out how to fix them.
Free. Save your status, tasks and notes.
Why it matters
Without central logging of Linux security events, attacks may go undetected and incident investigation is slowed due to missing or scattered audit trails.
How to implement
The IT team should decide which events need to be logged.
They can do this by identifying key activities on Linux systems that involve access, changes, or errors. This can be achieved by reviewing the Linux system's capabilities and determining which logs will help in monitoring unusual actions.
System administrators should set up a central logging system.
They can install specific software that collects logs from all Linux systems to one location. Tools like syslog or rsyslog can be configured to automatically send logs from each computer to the central server.
IT managers need to check that all systems are correctly logging.
This involves periodically reviewing logs to make sure they are being sent from all Linux machines. They can do walk-throughs or run scripts that verify log files are up to date.
The security team should review these logs regularly.
Set a schedule for team members to go through logs to spot any unusual behaviour or access attempts. They can use tools that analyse the data and flag potential security incidents for further review.
Business continuity planners should ensure backup processes are in place.
This involves setting policies for backing up logs regularly so that even in the event of an attack, there's a history available to analyse. Digital storage must be checked to ensure data over time is preserved securely.
Keep it running
Ensure Linux hosts forward security-relevant events (e.g. auth, sudo, kernel) to a central log server; monitor ingest health and review alerts for anomalies.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The logging policy document: Request the policy that details which Linux system events are logged centrally.
Look at
The list of events covered.
Good evidence
Document includes a comprehensive list that covers security and operational events necessary for your environment.
- Check 2 of 5What an auditor asks for
Ask for
Evidence of software installation on the central server that collects logs. Check the installation logs and configuration files.
Good evidence
Setup would show consistent file updates, signifying active logging processes.
- Check 3 of 5What an auditor asks for
Ask for
A sample log report from the central repository: Request a sample of logs collected for a specific timeframe.
Look at
The sample for different types of events captured, such as access logs and error logs.
Good evidence
Report will show a variety of logged events and details like timestamps and the origin of each event.
- Check 4 of 5What an auditor asks for
Ask for
A planned schedule or checklist for regular log reviews.
Look at
Evidence of completed reviews, such as dated notes or digital records of findings.
Good evidence
Schedule shows regular reviews with action points outlined to address any issues found.
- Check 5 of 5What an auditor asks for
Ask for
About log backup procedures: Request documents that describe how logging data is backed up. Examine whether the procedures include regular frequency, storage location, and data protection measures.
Good evidence
Backup plan will exhibit clear protocols, secure storage solutions, and a regular backup routine.
Mappings
Closest match in ASD Essential Eight: E8-AC-ML2.5, Allowed and blocked application control events are centrally logged, which partially overlaps with this control.
ASD Essential Eight: 5 mappings
This control partially overlaps E8-AC-ML2.5.
ISM-1977 requires security-relevant events for Linux operating systems to be centrally logged. E8-AC-ML2.5 specifically requires central logging of allowed and blocked application control events, which are a subset of security-relevant events that could occur on Linux hosts where application control is implemented. E8-AC-ML2.5 is event-type specific (application control) and not Linux-specific, while ISM-1977 is Linux-specific and broader across multiple Linux event categories.
This control partially overlaps E8-MF-ML2.6.
ISM-1977 requires security-relevant events for Linux operating systems to be centrally logged. E8-MF-ML2.6 requires central logging of MFA success and failure events, which may be generated by Linux-based authentication components (e.g. PAM modules) or upstream identity providers feeding Linux access decisions. E8-MF-ML2.6 is limited to MFA outcomes and is not Linux-specific, while ISM-1977 covers Linux system events more broadly and may include many non-MFA security logs.
This control partially overlaps E8-RA-ML2.6.
E8-RA-ML2.6 requires privileged access events to be centrally logged to detect and investigate misuse of elevated access. ISM-1977 requires central logging of security-relevant events for Linux operating systems, which may include privileged authentication and administrative actions. They overlap on centralising logs that may capture privileged activity, but ISM-1977 is OS-scoped and broader in event types, while E8-RA-ML2.6 is specifically about privileged access events across platforms.
- E8-RA-ML2.7Centrally log privileged user account and security group management eventsPartially overlaps
This control partially overlaps E8-RA-ML2.7.
ISM-1977 requires security-relevant events for Linux operating systems to be centrally logged. E8-RA-ML2.7 requires central logging of privileged account and group management events, which on Linux include user/group changes and sudoers-related administration that are security-relevant. E8-RA-ML2.7 is focused on identity and group lifecycle events, whereas ISM-1977 is broader across Linux system event sources beyond account and group management.
This control depends on E8-AH-ML2.12.
E8-AH-ML2.12 requires command line process creation events to be centrally logged. ISM-1977 requires central logging of security-relevant events for Linux operating systems, which can include process execution/audit events that capture command execution. ISM-1977 supports implementation of E8-AH-ML2.12 on Linux hosts, but does not uniquely target command line process creation events.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.