In today’s ever-evolving threat landscape, safeguarding your systems against unauthorized access and malicious activity is paramount. Mandatory Audit and Logging Baselines (MLBs) serve as a critical line of defense, providing a standardized approach to securing your system through systematic monitoring and record-keeping. This article delves into the importance of MLBs, explores the authorities behind them, and outlines the key controls to ensure their successful implementation.

What are Mandatory Audit and Logging Baselines Security (MBSS)?

MBSS is a collection of essential security controls that dictate how system activity is monitored and logged. These controls establish a baseline for auditing system calls, file system modifications, user logins, and other critical events. By meticulously recording these activities, MBSS empowers system administrators to detect potential security breaches, investigate suspicious behavior, and reconstruct incidents for forensic analysis.

Why is MBSS Mandatory?

The enforcement of MLBs often stems from regulatory compliance requirements or internal security policies. However, their significance transcends mandated implementation. MBSS offers a multitude of benefits, including:

• Enhanced Intrusion Detection: By capturing system events, MLBs provide a clear picture of system activity, enabling administrators to identify and respond to anomalies that might indicate intrusion attempts.
• Improved Forensics: Detailed audit logs serve as a valuable source of evidence in the event of a security breach. They facilitate the reconstruction of the incident timeline and the identification of the culprits.
• Stronger Accountability: User activity logs provide a record of individual actions within the system. This fosters accountability and deters unauthorized access attempts.
• Streamlined Security Audits: MLBs establish a consistent framework for security audits, simplifying the process of evaluating system security posture and identifying areas for improvement.

Who Declared these Baselines?

While there’s no single governing body that dictates universal MLBs, several prominent authorities recommend and enforce similar security baselines. These include:

• The Center for Internet Security (CIS): The CIS publishes security benchmarks for various operating systems, including Red Hat Enterprise Linux (RHEL) – the focus of the MLBs we’ve outlined.
• The National Institute of Standards and Technology (NIST): NIST Cybersecurity Framework (CSF) provides a comprehensive structure for improving critical infrastructure security. While not explicitly mandating logging baselines, the CSF emphasizes the importance of audit logging for security purposes.
• Regulatory Compliance Requirements: Depending on your industry or location, specific regulations might mandate the implementation of security baselines that include audit and logging controls.

Linux Distributions Based on Red Hat Enterprise Linux (RHEL)

Here’s a list of applicable Mandatory Audit and Logging Baselines Security Linux distributions that are based on RHEL:

RHEL-Based Distributions

• Red Hat Enterprise Linux (RHEL): The commercial flagship distribution from Red Hat.  
• CentOS Stream: A development-oriented distribution that feeds into RHEL.  
• Rocky Linux: A community-driven enterprise Linux distribution.  
• AlmaLinux: Another community-driven enterprise Linux distribution.  
• Oracle Linux: A free and open-source enterprise Linux distribution backed by Oracle.  

Key Differences

While these distributions share a common base, there are some key differences:

• Support and Updates: RHEL offers commercial support, while the others are community-driven and offer free support. Update schedules and frequencies may also vary.
• Package Repositories: While they share many packages, there might be differences in package versions and availability due to the different distribution channels.
• Community Focus: Some distributions have a stronger focus on specific communities or use cases, which might influence package selection and configuration.

Important Note

It’s essential to understand that while these distributions are highly compatible, there might be subtle differences in package management tools, configuration files, and default settings. It’s always recommended to test applications thoroughly when migrating between these distributions.

Key Mandatory Audit and Logging Controls

The 27 control points outlined earlier encompass a wide range of security measures. Here’s a breakdown of some of the most crucial controls:

• Audit Log Configuration: Ensure adequate storage size for audit logs, prevent deletion upon reaching capacity, and enable automatic log rotation.
• Auditd Service: Activate the auditd service to record system events.
• Audit Log Rotation: Configure log rotation to manage log size and facilitate archiving.
• Log File Permissions: Maintain proper access controls on log files to prevent tampering.
• System Call Monitoring: Audit critical system calls for unauthorized activities.
• User/Group Modification Monitoring: Track changes to user and group accounts.
• Network Environment Monitoring: Monitor modifications to network configuration files.
• Mandatory Access Control (MAC) Monitoring: Track modifications to SELinux policies.
• Login/Logout Monitoring: Record login and logout attempts for user accountability.
• Session Initiation Monitoring: Monitor changes to session-related files.
• File Permission/Attribute Changes: Audit modifications to file permissions and ownership.
• Unsuccessful File Access Attempts: Track failed attempts to access files.
• Privileged Command Usage: Monitor the execution of privileged commands by non-administrative users.
• Remote Logging: Configure secure remote log forwarding to a centralized log server.

Details List of all Mandatory Audit and Logging Baseline Security for Red Hat Enterprise Linux (RHEL)

1. Audit log storage size should be configured: It is important that an appropriate size is determined for log files so that they do not impact the system and audit data is not lost.
2. Ensure system is disabled when audit logs are full: The auditd daemon can be configured to halt the system when the audit logs are full. In high security contexts, the risk of detecting unauthorized access or nonrepudiation exceeds the benefit of the system’s availability.
3. Audit log should not be automatically deleted upon reaching max audit log storage size: The max_log_file_action setting determines how to handle the audit log file reaching the max file size. A value of keep_logs will rotate the logs but never delete old logs. In high security contexts, the benefits of maintaining a long audit history exceed the cost of storing the audit history.
4. Ensure auditd service is enabled: Turn on the auditd daemon to record system events. The capturing of system events provides system administrators with information to allow them to determine if unauthorized access to their system is occurring.
5. Ensure auditing for processes that start prior to auditd is enabled: Configure grub so that processes that are capable of being audited can be audited even if they start up prior to auditd startup. Audit events need to be captured on processes that start up prior to auditd, so that potential malicious activity cannot go undetected.
6. Events that modify date and time information should be collected: Capture events where the system date and/or time has been modified. The parameters in this section are set to determine if the adjtimex (tune kernel clock), settimeofday (Set time, using timeval and timezone structures) stime (using seconds since 1/1/1970) or clock_settime (allows for the setting of several internal clocks and timers) system calls have been executed and always write an audit record to the /var/log/audit.log file upon exit, tagging the records with the identifier “time-change”.
7. Ensure events that modify user/group information are collected: Record events affecting the group, passwd (user IDs), shadow and gshadow (passwords) or /etc/security/opasswd (old passwords, based on remember parameter in the PAM configuration) files. The parameters in this section will watch the files to see if they have been opened for write or have had attribute changes (e.g. permissions) and tag them with the identifier “identity” in the audit log file.
8. Ensure events that modify the system’s network environment are collected: Record changes to network environment files or system calls. The below parameters monitor the sethostname (set the systems host name) or setdomainname (set the systems domainname) system calls, and write an audit event on system call exit. The other parameters monitor the /etc/issue and /etc/issue.net files (messages displayed pre-login), /etc/hosts (file containing host names and associated IP addresses), /etc/sysconfig/network file and /etc/sysconfig/network-scripts/ directory (containing network interface scripts and configurations).
9. Ensure events that modify the system’s Mandatory Access Controls are collected: Monitor SELinux mandatory access controls. The parameters below monitor any write access (potential additional, deletion or modification of files in the directory) or attribute changes to the /etc/selinux directory.
10. Ensure login and logout events are collected: Monitor login and logout events. The parameters below track changes to files associated with login/logout events. The file /var/log/lastlog maintain records of the last time a user successfully logged in. The /var/run/failock directory maintains records of login failures via the pam_faillock module. Monitoring login/logout events could provide a system administrator with information associated with brute force attacks against user logins.
11. Ensure session initiation information is collected: Monitor session initiation events. The parameters in this section track changes to the files associated with session events. The file /var/run/utmp file tracks all currently logged in users. All audit records will be tagged with the identifier “session.” The /var/log/wtmp file tracks logins, logouts, shutdown, and reboot events. The file /var/log/btmp keeps track of failed login attempts and can be read by entering the command /usr/bin/last -f /var/log/btmp. All audit records will be tagged with the identifier “logins.” Monitoring these files for changes could alert a system administrator to logins occurring at unusual hours, which could indicate intruder activity (i.e. a user logging in at a time when they do not normally log in).
12. Ensure discretionary access control permission modification events are collected: Monitor changes to file permissions, attributes, ownership and group. The parameters in this section track changes for system calls that affect file permissions and attributes. The chmod, fchmod and fchmodat system calls affect the permissions associated with a file. The chown, fchown, fchownat and lchown system calls affect owner and group attributes on a file. The setxattr, lsetxattr, fsetxattr (set extended file attributes) and removexattr, lremovexattr, fremovexattr (remove extended file attributes) control extended file attributes. In all cases, an audit record will only be written for non-system user ids (auid >= 1000) and will ignore Daemon events (auid = 4294967295). All audit records will be tagged with the identifier “perm_mod.” Monitoring for changes in file attributes could alert a system administrator to activity that could indicate intruder activity or policy violation.
13. Ensure unsuccessful unauthorized file access attempts are collected: Monitor for unsuccessful attempts to access files. The parameters below are associated with system calls that control creation (creat), opening (open, openat) and truncation (truncate, ftruncate) of files. An audit log record will only be written if the user is a non-privileged user (auid >= 1000), is not a Daemon event (auid=4294967295) and if the system call returned EACCES (permission denied to the file) or EPERM (some other permanent error associated with the specific system call). All audit records will be tagged with the identifier “access.”
14. Ensure use of privileged commands is collected: Monitor privileged programs (those that have the setuid and/or setgid bit set on execution) to determine if unprivileged users are running these commands. Execution of privileged commands by non-privileged users could be an indication of someone trying to gain unauthorized access to the system.
15. Ensure successful file system mounts are collected: Monitor the use of the mount system call. The mount (and umount) system call controls the mounting and unmounting of file systems. The parameters below configure the system to create an audit record when the mount system call is used by a non-privileged user.
16. Ensure file deletion events by users are collected: Monitor the use of system calls associated with the deletion or renaming of files and file attributes. This configuration statement sets up monitoring for the unlink (remove a file), unlinkat (remove a file attribute), rename (rename a file) and renameat (rename a file attribute) system calls and tags them with the identifier “delete”.
17. Ensure changes to system administration scope (sudoers) is collected: Monitor scope changes for system administrations. If the system has been properly configured to force system administrators to log in as themselves first and then use the sudo command to execute privileged commands, it is possible to monitor changes in scope. The file /etc/sudoers will be written to when the file or its attributes have changed. The audit records will be tagged with the identifier “scope.”
18. Ensure system administrator actions (sudolog) are collected: Monitor the sudo log file. If the system has been properly configured to disable the use of the su command and force all administrators to have to log in first and then use sudo to execute privileged commands, then all administrator commands will be logged to /var/log/sudo.log. Any time a command is executed, an audit event will be triggered as the /var/log/sudo.log file will be opened for write and the executed administration command will be written to the log.
19. Ensure kernel module loading and unloading is collected: Monitor the loading and unloading of kernel modules. The programs insmod (install a kernel module), rmmod (remove a kernel module), and modprobe (a more sophisticated program to load and unload modules, as well as some other features) control loading and unloading of modules. The init_module (load a module) and delete_module (delete a module) system calls control loading and unloading of modules. Any execution of the loading and unloading module programs and system calls will trigger an audit record with an identifier of “modules”.
20. Ensure the audit configuration is immutable: Set system audit so that audit rules cannot be modified with auditctl. Setting the flag -e 2 forces audit to be put in immutable mode. Audit changes can only be made on system reboot. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. Users would most likely notice a system reboot and that could alert administrators of an attempt to make unauthorized audit changes.
21. The rsyslog/syslog-ng service should be activated: Ensure that rsyslog service is turned on. If the rsyslog service is not activated, the system will not have a syslog service running.
22. Logging rules for rsyslog/syslog-ng should be configured: The /etc/rsyslog.conf and /etc/rsyslog.d/* OR /etc/syslog-ng/syslog-ng.conf and files specifies rules for logging and which files are to be used to log certain classes of messages.
23. rsyslog/syslog-ng should be configured to send logs to a remote log host: The rsyslog/syslog-ng utility supports the ability to send logs it gathers to a remote log host or to receive messages from remote hosts, reducing administrative overhead. Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
24. Remote rsyslog/syslog-ng messages are only accepted on designated log hosts: By default, rsyslog does not listen for log messages coming in from remote systems. The ModLoad tells rsyslog to load the imtcp.so module so it can listen over a network via TCP. The InputTCPServerRun option instructs rsyslogd to listen on the specified TCP port. syslog-ng does not listen for log messages coming in from remote systems. The guidance in the section ensures that remote log hosts are configured to only accept syslog-ng data from hosts within the specified domain and that those systems that are not designed to be log hosts do not accept any remote syslog-ng messages. This provides protection from spoofed log data and ensures that system administrators are reviewing reasonably complete syslog data in a central location.
25. The rsyslog or syslog-ng package should be installed: The rsyslog package is a third-party package that provides many enhancements to syslog, such as multi-threading, TCP communication, message filtering and database support.
26. Ensure logrotate is configured: The system includes the capability of rotating log files regularly to avoid filling up the system with logs or making the logs unmanageable large. The file /etc/logrotate.d/syslog is the configuration file used to rotate log files created by syslog or rsyslog. By keeping the log files smaller and more manageable, a system administrator can easily archive these files to another system and spend less time looking through inordinately large log files.
27. System file permissions should be audited: The RPM package manager has a number of useful options. One of these, the --verify (or -V) option, can be used to verify that system packages are correctly installed. The -verify option can be used to verify a particular package or to verify all system packages. If no output is returned, the package is installed correctly.

Conclusion

In an era where cyber threats loom large, implementing Mandatory Audit and Logging Baselines is no longer a choice but a strategic imperative. By meticulously monitoring and recording system activities, organizations can bolster their security posture, detect threats early, and streamline incident response. The comprehensive guidelines outlined in this article serve as a blueprint for establishing a robust audit and logging infrastructure. Don’t wait for a breach to strike; empower your security team with the tools they need to protect your organization’s valuable assets.

By taking proactive steps to implement these mandatory controls, you’re not just complying with regulations; you’re investing in the long-term security and resilience of your organization. This includes ensuring that audit logs are adequately sized and stored, the auditd service is enabled, and critical system events are captured. Additionally, monitoring user activity, file modifications, and network changes is vital for identifying suspicious behavior. By establishing a comprehensive audit and logging infrastructure, you’ll be better equipped to detect, investigate, and respond to security incidents, ultimately safeguarding your organization’s sensitive information and maintaining business continuity.

roosho Senior Engineer (Technical Services)

I am Rakib Raihan RooSho, Jack of all IT Trades. You got it right. Good for nothing. I try a lot of things and fail more than that. That's how I learn. Whenever I succeed, I note that in my cookbook. Eventually, that became my blog. 

See Full Bio

IT Support Specialist Server and Storage Specialist Dell MidRange Storage Solutions Specialist