PCI DSS Compliance

Using ClamAV for Linux PCI DSS requirement 5: Malware

PCI DSS requirement 5 focuses on anti-virus and malware, or malicious software. Linux systems can also be compliant by using the popular ClamAV software.

Summary

An important part in the PCI DSS compliance, is checking for malicious software, or malware. By using anti-virus software like ClamAV, malware threats can be detected, and in most cases prevented. In this article we focus mainly on Linux environments, but of course most of these tips will apply to other platforms like Mac OS.

5.1. Verify presence of software

5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists.

PCI DSS Linux: Creation and deletion of system-level objects

The PCI DSS standard defines Creation and deletion of system-level objects. For Linux systems this might be handled with the Linux audit framework.

Summary

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.

PCI DSS (v3) Linux: Invalid logical access attempts (10.2.4)

PCI DSS compliance control 10.2.4 mandates to monitor invalid logical access attempts. For Linux we can use the Linux audit framework to monitor for this event.

Summary

PCI describes in control 10.2.4 to monitor for “invalid logical access attempts”. Another way of saying to monitor attempts which are not allowed, like accessing a file you are not supposed to. Another indication might be brute force attempts to log in, which result in several failed logins.

To monitor for invalid access attempts, we can use the Linux audit framework. This framework has been created and maintained by Red Hat over the years. It is a great tool for auditing and to help with PCI DSS compliance on Linux based systems.

PCI DSS Linux: Logging of administrative actions with root privileges

PCI DSS requires logging of administrative actions, including commands executed by the root user or using sudo. Learn how to set up accounting and auditing.

Summary

Companies who need to comply with the PCI DSS standard need to log all actions which are executed by the root user or those accounts with similar administrative privileges.

10.2.2 Verify all actions taken by any individual with root or administrative privileges are logged.

The Linux kernel allows the monitoring of executed commands. This monitoring and logging can be done with the Linux audit framework. Using this framework, we can monitor the right system calls and create an audit trail. It is also called Linux accounting. Such accounting is similar to the call history on your mobile phone bill.

PCI DSS Linux: No write access to shared system binaries

PCI compliance demands that no write access is allowed to shared system binaries. Let's use several tools to determine if write access is allowed.

Summary

A.1.2.c Verify that an entity’s users do not have write access to shared system binaries

Shared system binaries should be protected, as they form the basis of your system. PCI compliance (A.1.2.c) demands that users do not have write access to shared systems binaries. The only exception is of course the root user, so software upgrades are still possible.

Paths for system binaries

Depending on the distribution used there are several directories which have shared system binaries. Common paths are:

PCI DSS (v3) for Linux: Auditing application processes (A.1.2.a)

PCI DSS compliance requires you to verify if no application processes are running as root. We audit these application processes and check the status of each.

Summary

A.1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

For Unix and Linux based systems, processes should run as a non-privileged user where possible. However to be able to start, a process is usually started with root permissions (uid 0). This is required to open the required sockets (e.g. bind to port 80).

After the initial start, the process drops its privileges by switching to another user. In some cases there will maintain one master process, which is started with uid 0 as well. This process is responsible for the creation of child processes, not for handling interactions with users or processes. You can consider this as an administrative process. The child processes do handle

PCI DSS (v3) Linux: Restrict log file viewing (A.1.2.d)

Linux users who want to compliant with PCI DSS have to restrict log file viewing to only the owner. Learn how to achieve this.

Summary

A.1.2.d Verify that viewing of log entries is restricted to the owning entity.

To limit exposure to information, PCI DSS requires access of logging to only the entity owning that log file. In other words, we have to search for those entries which can be seen by others.

By default, most log files on Linux based systems will be stored in /var/log. We can do a quick check for any files which are world readable, by using find.