Audit policy
As part of a security concept for the integration of a device into a network, it should be specified which level of security audit is suitable for detecting potential attacks. Security audit means that an industrial PC creates audit logs of events as soon as an interaction with the device takes place. For example, file and folder accesses can be logged each time a user accesses the selected files or folders.
These logs are intended for review to detect deviations from normal use that could indicate an attack, or for forensic purposes to reconstruct details about an attack. The check can be carried out immediately or at regular intervals by automated mechanisms or manually. It depends on the environment and the application as to which deviations are relevant. Therefore, rules that describe which actions are logged are usually configured using audit policies.
However, configuring too many rules can lead to a kind of blindness. The logs can become overloaded with irrelevant entries, with the relevant entries easily overlooked by humans or not processed quickly enough by automatic monitoring mechanisms. Sometimes it is good practice to forward logs to a central location for automatic review and/or archiving, among other things to avoid exhausting limited log capacity.
File and folder access, as well as security-relevant user inputs, can be logged in Beckhoff RT Linux®. Each time a user performs a specific action, the event is logged. These event logs are especially important for monitoring the system, detecting unauthorized access, and for subsequent analysis after a security incident.
Install and activate the audit daemon:
sudo apt updatesudo apt install auditd audispd-pluginssudo systemctl enable auditdStarting the audit daemon:
sudo systemctl start auditdChecking the status:
sudo systemctl status auditdIf you also want to audit the early system startup, you can set the kernel parameter audit=1 .
In /etc/audit you will find the configuration files of the audit daemon, which can be used to fine-tune the audit. Two areas in particular are important here:
/etc/audit/auditd.conf which is used for general, system-wide audit settings, and /etc/audit/rules.d/*.rules , where the actual audit rules are defined.
For a Beckhoff RT Linux® system, it is recommended to start with a conservative set of rules that logs changes to security-relevant configuration files, identity data, mount operations, kernel modules, and permissions without placing an unnecessarily heavy load on high-frequency runtime paths.
An obvious example configuration is:
# /etc/audit/rules.d/30-rt-security.rules
-b 8192
-f 1# Monitor the audit configuration itself
-w /etc/audit/ -p wa -k audit-config# User, group, and authentication configuration
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d/ -p wa -k privilege
-w /etc/pam.d/ -p wa -k pam-config# Time changes
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
-w /etc/localtime -p wa -k time-change# Host and network configuration
-w /etc/hostname -p wa -k network-config
-w /etc/hosts -p wa -k network-config
-w /etc/resolv.conf -p wa -k network-config
-w /etc/network/ -p wa -k network-config# Persistence mechanisms
-w /etc/crontab -p wa -k cronOn 64-bit systems that also allow 32-bit applications, the corresponding arch=b32 rules should be supplemented accordingly.
Run sudo augenrules –load to load the rules and sudo auditctl -l, to view the loaded rules. You can then view the audit logs using commands such as sudo aureport -k -i or sudo ausearch -k identity -i.
As a general rule, you should avoid rules that extensively monitor high-traffic directories or heavily used system calls–for example, global rules on /tmp, /run, /var/tmp or complete monitoring of all execve-,open or read accesses. Such rules can quickly lead to large amounts of log data and compromise real-time performance. Instead, it is recommended to focus on:
- Changes to user, group, and authentication data
- Changes to network and host configuration
- Changes to startup mechanisms and services
- Mount and kernel module activities
- Changes to permissions, ownership, and attributes
- optional, targeted monitoring of critical application directories