PCI DSS Compliance

Networking components are an important part in the chain of moving data between systems. Therefore a clear standard should exist for firewall and routers.

Control details:
1.1 Establish and implement firewall/router standards

Control details:
1.1.5 Roles for network management

Computer systems have a primary goal to assist the business of the company. Some systems are focused on delivering functionality to core business processes, others support the IT department. Collecting running services on Linux is fairly easily, assigning them a clear business justification is usually harder.

Control details:
1.1.6 Documentation and business justification for services

Deploying anti-virus software is required by the PCI DSS standard, to counter the threat of malicious software (malware). This section describes reviewing the anti-virus solution, policy and procedures.

Control details:
5.1 Anti-virus software deployment

To ensure a proper functioning anti-virus solution, the effectiveness should be tested. This PCI DSS section defines regular scans and automated updates of the malware signatures.

Control details:
5.2 Testing effectiveness of anti-virus solution

Anti-virus software should be actively running on the system to catch malware before it is being executed.

Control details:
5.3 Anti-virus is running

By using repeated login attempts, also known as "brute force" attacks, the right password might be guessed. To prevent this from happening, PCI DSS describes that accounts should have a lock mechanism in place.

Control details:
8.1.6 Lockout accounts after a number of access attempts

A lockout duration should be configured when authentication attempts several times failed. A related time should be configured to re-enable the account again, or by manual reset of an administrator.

Control details:
8.1.7 Account lockout duration

Access to open machines should be limited, to reduce the risk of non-authorized people accessing a system. A session time out value or tool should be used to control this risk.

Control details:
8.1.8 Session idle time out

Activities should be traceable and accounted for. This control deals with the way systems are configured, and in particular of authentication methods in related to generic accounts.

Control details:
8.5 Groups, shared and functional accounts

Brute force and logon attempts might be a first indication of a possible break-in. This is the reason such attempts should be properly logged and reviewed on a regular basis. On Linux this PCI DSS control might be configured by using the Linux audit system.

Control details:
10.2.4 Invalid logical access attempts

Within the field of intrusion detection, it is important to know what accounts where used for proper investigation purposes. This section of PCI DSS wants to know how the root user is used on Linux systems, including the creation, modification and deletion of users.

Control details:
10.2.5 Usage and changes to identification and authentication mechanisms

To achieve full accountability, audit trails should be properly logged by the system. When it comes to auditing system components, at least the following fields needs to be available: user identification, type, date/time, success/failure status, originator and an identifier.

Control details:
10.3 Audit trail fields

Log files, audit trails, and even some protocols depend on the time. A high level of accuracy is needed to ensure the quality of the logs, which might be needed for forensics or troubleshooting. Protocols like kerberos can stop working if the time is not properly synced. On Linux systems, it is therefore common to find an NTP daemon or a service responsible for time-synchronization.

Control details:
10.4 Time-synchronization technology

Audit trails form the basis for forensics, troubleshooting, and accountability. This section of PCI DSS defines what to do to secure these audit trails against tampering.

Control details:
10.5 Secure audit trails so they cannot be altered