PCI DSS (v3) Linux: Creation and deletion of system-level objects (10.2.7)

PCI DSS (v3) Linux: Creation and deletion of system-level objects (10.2.7)

Some areas are within the PCI 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/<architecture>. 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”.

Screenshot of ausearch with key

Example of events monitored by the Linux audit framework

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!

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


Leave a Reply

Your email address will not be published. Required fields are marked *