PCI DSS Linux: Creation and deletion of system-level objects
Some areas are within the PCI DSS standard are definitely not directly clear when reading the description. Section 10.2.7 is one of them. It talks about the creation and deletion of system-level objects and specifically the ability to log them.
System-level objects?
The guidance in 10.2.7 speaks about malware and mentions database related items. That does not make auditing very obvious, as malware usually targets binaries. Therefore we have to look first what a system-level object is.
Let’s start with a possible definition:
System-level object:
Anything on a system which is required for its operation, including the kernel, executables/binaries, configuration files, libraries, drivers and software applications.
For Linux and Unix based systems this equals to directories like /bin, /sbin, /etc/, /var/lib etc. In this article we will set-up auditing on the most important system objects of Linux system.
Monitoring system-level objects
To protect important areas of the Linux system, proper file permissions will help to safeguard it against unauthorized change or deletion. Defending is for PCI not enough, as we also need proof that accounting is in place. For that we can use the Linux audit framework.
All rules shared in this article can be easily tested by adding them with auditctl, followed by the rule itself. Rules start with -a, to indicate they should be added to the existing rule base. By defining a -d as first parameter, we can delete the related rule again.
Auditing Linux kernel
First area to audit is the Linux kernel itself. Every alteration, including upgrades, should be properly prepared, installed and finally be logged. With the audit daemon we can monitor any changes to the kernel files itself. As we want to keep an eye on the boot configuration as well, monitoring /boot is a great start.
-a always,exit -S all -F dir=/boot -F perm=aw -k system-objects
Auditing system binaries
Next area is auditing the system binaries. There are divided over several directories. You have to look at your system where binaries are listed. Usually displaying the $PATH variable will give a good indication.
-a always,exit -S all -F dir=/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/bin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/local/sbin -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/sbin -F perm=aw -k system-objects
Note: Check your system if there are any other directories containing binaries and not being a subdirectory of any of these entries above.
Auditing system libraries
Last are the system libraries. They contain system calls and supporting functionality for most of the system binaries.
-a always,exit -S all -F dir=/lib -F perm=aw -k system-objects
-a always,exit -S all -F dir=/lib64 -F perm=aw -k system-objects
-a always,exit -S all -F dir=/usr/lib -F perm=aw -k system-objects
Some distributions mights use /usr/lib/. As we already have a watch on the /usr/lib, these should be included (because of the usage of dir).
Auditing configuration files
Most of the configuration files are stored in /etc. If you have other locations, add them as well.
-a always,exit -S all -F dir=/etc -F perm=aw -k system-objects
Auditing systemd
If your system is using systemd, don’t forget to audit the related directories as well.
-a always,exit -S all -F dir=/usr/lib/systemd/ -F perm=aw -k system-objects
Note: If you are already auditing /usr/lib with the -F dir=, the systemd directory will be included.
Monitoring databases
As the guidance provides hints to databases, we suggest to monitor the related database directories as well. The creation of deletion of a database might be useful to log. However, keep in mind on what is actually being logged and not to have too much accounting data, as database can be change very regularly.
Another useful thing is to consult the documentation of the database software, to ensure stored procedures and changes to tables are logged.
Notes
The defined rules with permission “aw” will be triggered when an item is created, updated or deleted from the specified directories. The “a” permission is responsible for monitoring the creation and deletion, as these involve the change of the attributes of the file. While writing, the attributes (e.g. mtime) will change as well. The writing to the file is monitored with the “w” permission definition.
Search events
After an event is logged, it can be discovered with the ausearch utility. Simply provide the -k parameter, followed by the earlier defined name “system-objects”.
Automatic auditing with Lynis
To ensure your systems are PCI compliant, use supporting tools like Lynis, to check your PCI compliance on a regular basis. This way changes can be discovered quickly, avoiding a failure at the next audit.
Happy auditing!
