Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Documentação do SUSE Linux Enterprise Server / Security and Hardening Guide / Achieving PCI DSS Compliance
Applies to SUSE Linux Enterprise Server 12 SP5

A Achieving PCI DSS Compliance

To protect customers and the business itself, companies that handle credit card payments must keep data as safe and secure as possible. Following the Payment Card Industry Data Security Standard helps to secure all areas that are connected to payment processes and to implement security-relevant actions to keep the data and the computing environment safe.

This document aims to provide a basic understanding of how SUSE Linux Enterprise Server can be configured to comply with the Payment Card Industry Data Security Standard.

It is important to understand that protecting systems includes more than configuration. The entire environment and people involved must be taken into account.

An essential part of implementing PCI DSS is the combination of actions:

  1. Create a secure configuration.

  2. Track and review all changes made to the configuration: who changed what at which point in time.

A.1 What is the PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements to guide a merchant to protect cardholder data. The standard covers 6 main categories with currently 12 requirement topics on how to implement, protect, maintain and monitor systems that are involved with credit cardholder data processing.

PCI DSS was created and is maintained by the PCI Security Standards Council (SSC), which was founded by the five major credit card brands Visa, Mastercard, American Express, Discover, and JCB. In December 2004, PCI DSS 1.0 was released to address the growing threat of online credit card fraud. The current version, PCI DSS version 3.2, is available since April 2016.

Build and Maintain a Secure Network and Systems
  1. Install and maintain a firewall configuration to protect cardholder data

  2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data
  1. Protect stored cardholder data

  2. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program
  1. Protect all systems against malware and regularly update anti-virus software or programs

  2. Develop and maintain secure systems and applications

Implement Strong Access Control Measures
  1. Restrict access to cardholder data by business need to know

  2. Identify and authenticate access to system components

  3. Restrict physical access to cardholder data

Regularly Monitor and Test Networks
  1. Track and monitor all access to network resources and cardholder data

  2. Regularly test security systems and processes

Maintain an Information Security Policy
  1. Maintain a policy that addresses information security for all personnel

Most requirements of PCI DSS are organizational guidelines that help ensure the security of all areas involved with cardholder data. There is usually no specific wording of the technical aspects.

This means that it is up to auditors to decide which security settings are valid for a requirement and which are not. Therefore, the recommendations in this document can only provide a starting point for implementing the PCI DSS and are necessarily subject to discussion.

A.2 Focus of This Document: Areas Relevant to the Operating System

The PCI DSS covers a wide range of aspects related to cardholder data. Not all of these aspects concern the operating system and this document will not focus on these. Instead, this document focuses on aspects that affect OS configuration, including:

  • System security

  • Access control

  • System maintenance to protect against known vulnerabilities

Topics beyond the scope of this document include data processing applications, database design, and formal processes outside of the OS scope. In particular, requirement 9 (restrict physical access) and requirement 12 (maintain a policy) are not discussed extensively in this document.

A.3 Requirements in Detail

The following section goes through relevant parts of the PCI DSS in detail, following the ordering of the standard itself.

A.3.1 Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data

The listed terms in this section are mostly design, documentation and formal process requirements. All changes to the firewalls and routers need to be approved, documented and verified, and all stakeholders need to be involved. The network design includes a DMZ environment, access to the Internet, a protected network for database servers, traffic filtering rules between network segments, etc.

In addition to a dedicated firewall and router, SUSE Linux Enterprise Server comes with a host firewall based on iptables. The system can be easily configured to allow only connections on certain inbound ports. With the YaST firewall module it is also possible to define more complex rules. For example, to disable connections not coming from certain network addresses. This allows integrating the local system firewall into an overall firewall design that maximizes network security.

In generalized terms, the technical points in requirement 1 are the following:

  • Identify insecure services and protocols.

  • Limit traffic to and from the system so that unneeded and unwanted traffic is directly avoided.

1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service.

This task is embedded in the requirement to identify, document and justify all services and protocols running on a system. Of special interest are services and protocols that could lead to a security risk. If an insecure service or protocol is used, it must be evaluated to understand its potential security impact. Services or protocols that are not necessary for the business to function should be disabled or removed.

1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Inbound traffic filtering rules can be defined from the YaST firewall module. Systems with multiple interfaces can be configured to make the SSH daemon only reachable on the administration interface and not on the general network card. Furthermore, it is possible to define the source addresses that a service allows traffic from.

Usually all outbound system traffic is allowed by the SuSEfirewall2 script. Therefore outbound rules need to be defined manually inside the SuSEfirewall2 custom script. Activate the custom script inside the general SuSEfirewall2 configuration file /etc/sysconfig/SuSEfirewall2 by uncommenting the FW_CUSTOMRULES line.

To add an outbound rule, add an appropriate iptables command line inside the fw_custom_after_chain_creation() function. This function hook is executed during the firewall setup and allows any customized iptables rule.

For example, to allow only outbound DNS requests over the interface eth0 to server 10.0.0.4, use:

tux > sudo iptables -A OUTPUT -d 10.0.0.4/32 -o eth0 -p udp -m udp --dport 53 -j ACCEPT

Also see the deny all OUTPUT rule described in 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit deny all or an implicit deny after allow statement. .

1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit deny all or an implicit deny after allow statement.

The deny all rules of other inbound and outbound traffic can easily be achieved with iptables. The INPUT and FORWARD table policies are directly set by the SuSEfirewall2 script, so all unwanted traffic is dropped. Forwarding is usually completely disabled by a kernel parameter and should not be enabled for endpoint servers.

The OUTPUT policy needs to be defined manually inside the custom SuSEfirewall2 script because in general, all outgoing traffic is allowed. The following two rules need to be added to the fw_custom_after_chain_creation() function so that only outbound traffic that is related to an established inbound connection is allowed.

tux > sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
tux > sudo iptables -P OUTPUT DROP

In addition, inbound traffic can also be configured for certain services via the TCP wrapper configuration file /etc/hosts.deny.

Most of the following tasks are about examining and verifying that the defined inbound and outbound rules are really limiting the traffic between and within all network segments, like the DMZ and the Internet, to a necessary minimum for full system operation.

1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.

There are two ways to implement anti-spoofing measurements in SUSE Linux Enterprise Server:

  • iptables rules that only allow input from certain addresses on specified interfaces.  The used address space for communications can be clearly defined in the system setup. Any use of addresses that violates these definitions can be logged and trigger an alarm.

  • Linux Kernel Reverse Path Filtering.  This feature discards packet replies that do not go through the same interface as the initial packet. This feature is enabled by default in SUSE Linux Enterprise Server and can be checked with the following command:

    tux > cat /proc/sys/net/ipv4/conf/all/rp_filter

    When enabled, this returns 1.

1.3.5 Permit only established connections into the network.

The SuSEfirewall2 enables connection tracking via iptables. Connections to an interface that has been marked as external are dropped by default. Only connections that are associated with an established connection are allowed.

It is possible to define certain services that are allowed to connect to the external interface. However, this must be in compliance with the general security policy.

Keep in mind that the first line of defense against malicious connections from the Internet should be a dedicated firewall system that handles all traffic and acts as a gatekeeper. Unwanted connections should never reach the DMZ network. However, simple firewall rules on SUSE Linux Enterprise Server systems can help avoid misconfigurations and act as another line of defense.

1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.

A SUSE Linux Enterprise Server system can also act as a router to forward traffic from one interface to another network on a second interface. It is possible to use Network Address Translation (NAT) on the external interface so that no internal IP address is actually exposed to the outside. This is done to mitigate the information an external attacker can gather by simply analyzing the network traffic. NAT can also be used on virtualization hosts or container-based environments that connect to the outside via a specific interface.

A.3.2 Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

During the installation of SUSE Linux Enterprise Server, general system passwords are already set by the administrator. The setup also uses a password checker (cracklib) that identifies weak entries against a dictionary. This means that the standard configuration already includes customer-defined security options for most services.

For more information about OS security, see Security and Hardening Guide and Hardening Guide.

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

The configuration of any system service must be evaluated to meet the required security standards. This goes from limiting the protocols used to only allow currently secure versions and to disable legacy implementations, to the definition of access controls and authentication. The default settings of SUSE Linux Enterprise Server already provide good overall security, but they can be tweaked further.

For example, the following security settings might be relevant:

  • By default, the SNMP daemon only allows incoming requests to localhost. However, the default community string is named public and should be changed before accepting general inbound connections.

  • By default, certain insecure upstream settings of the sshd daemon are listed and commented out inside the sshd configuration file /etc/ssh/sshd_config. For example, the insecure protocol version 1 and empty passwords (PermitEmptyPasswords no) are already disabled.

    To further increase SSH security, if applicable, deny direct root access by setting PermitRootLogin to no.

Default settings can be customized by automating system installation with an AutoYaST profile. This allows rolling out new instances of SUSE Linux Enterprise Server and automatically enabling an evaluated configuration. This setup procedure can also be automated with the SUSE Manager. For more information, see the SUSE Manager documentation at https://documentation.suse.com/suma/.

By default, SUSE Linux Enterprise Server does not create additional accounts apart from the root administrative user. There are system accounts defined in /etc/passwd, but they are not activated and therefore not directly reachable. This can be validated by checking the lines inside the /etc/shadow file.

In that file, the second column represents the defined password:

  • An asterisk (*) means that a password was never defined and the account is therefore locked.

  • An exclamation mark (!) stands for a locked account and can appear all by itself or in front of a password hash.

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

As mentioned in the PCI DSS document, possible sources for industry-accepted hardening standards are:

  1. Center for Internet Security (CIS)

  2. International Organization for Standardization (ISO)

  3. SysAdmin Audit Network Security (SANS) Institute

  4. National Institute of Standards Technology (NIST)

As the PCI DSS requirements are not specified precisely, there is no direct relationship between hardening standards and specific requirements. However, other hardening resources can also help in complying with these specifications, including Security and Hardening Guide and Hardening Guide.

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

To help separate services, use the variety of virtualization and containerization methods included with SUSE Linux Enterprise Server: KVM, Xen, LXC, and Docker.

You can also run SUSE Linux Enterprise Server on third-party virtualization servers like VMware ESX or Microsoft Hyper-V to achieve service separation.

When using the options built in to SUSE Linux Enterprise Server, see:

2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

This is directly related to an item of requirement 1: To allow only services that are really needed and are using secure protocols and settings ( 1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service. ). All parties involved must be aware of the dangers of using insecure communication. Research, clearly document and communicate the risk of using insecure protocols and services.

Enable and disable system services using the following systemctl commands:

  • tux > systemctl status SERVICE
  • tux > sudo systemctl enable SERVICE
  • tux > sudo systemctl disable SERVICE

To list all available services that are installed on the system and see their status, use the following command:

tux > systemctl list-unit-files --type=service
2.2.3.a Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols.

To add an additional layer of security to insecure services, use VPN tunnels (for example, IPsec). With a VPN tunnel, network traffic of such services can be isolated and all data is protected against eavesdropping, both internally and externally. However, note that the communication is still insecure at the endpoints of the VPN tunnel and that this is only a workaround.

For additional security within SUSE Linux Enterprise Server, use SELinux or AppArmor. However, the setup of these frameworks is beyond the scope of this document:

2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

The Linux kernel is the main system component. It consists of a core image that is extended by kernel modules which are loaded depending on the hardware and system design. For example: Network card drivers are automatically loaded depending on the system’s network card. File system modules can be enabled to extend the Linux kernel’s file system support.

The list of loaded kernel modules is usually quite long and includes modules that are only used occasionally. The kernel module framework allows blacklisting modules and limiting which functionalities are loaded.

To block modules from being loaded, configure them via the directory /etc/modprobe.d. For example, the kernel module floppy is only necessary for systems that have a floppy drive. On systems that do not have a floppy drive, prevent the module from loading: Create a configuration file /etc/modprobe.d/00-disable-modules.conf with the following content:

install floppy /bin/true

The floppy module is usually loaded during the execution of the initial RAM disk. Therefore, propagate this configuration change to the initrd file using the mkinitrd script.

tux > sudo mkinitrd

It is harder to remove or restrict application functionality, as functionality is in most cases compiled into the application or library itself. Even cases where deleting a file cleanly removes a functionality are problematic: If the file was installed from an RPM package, it will be reinstalled when the package is updated.

2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access.

Encrypt all administrative network access: SSH with appropriate configuration settings that fit into the security concept should be the tool of choice.

Administrative access can also be granted via a Web site. In this case, the complete connection chain between the browser and the server system must be encrypted. This is done via TLS and X.509 certificates.

A.3.3 Requirement 3: Protect Stored Cardholder Data

This section explains how to handle cardholder and authentication data securely. The following definitions apply:

  • Cardholder data includes information such as the cardholder name and the Primary Account Number (PAN).

  • Authentication data includes the Personal Identification Number (PIN) and the Card Validation Code (CVC2).

The main difference between cardholder data and authentication data is that storing authentication is never allowed. In contrast, data such as the PAN can be stored, but must be encrypted and unreadable in case an attacker gains access to the stored data.

The database design for storing cardholder data is beyond the scope of this document. However, data can be encrypted in different ways:

  • The DBMS can use column-level encryption inside the database scheme.

  • Alternatively, the database files can be encrypted.

  • SUSE Linux Enterprise Server supports full-disk encryption, so that the whole database storage is always encrypted. However, access to an encrypted disk works the same way as to a non-encrypted disk. This is discussed in more detail in requirement 3.4.1.

3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).

The guidance description of the PCI DSS document says the following about this requirement: Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.

From an administrator’s point of view, a block device encryption with the Linux Unified Key Setup (LUKS)/dm-crypt offers an abstraction layer that allows the usage of encrypted disks in the same way as unencrypted disks.

Therefore, access control can only be limited with the general ACL permissions that the file system offers. To comply with this requirement, the decryption key used must not be associated with any general login credentials or authentication methods.

When using LUKS, this is usually fulfilled: The password needs to be entered separately when booting, inserting portable devices or manually mounting disks.

LUKS is fully integrated into SUSE Linux Enterprise Server and can be used via YaST to create new partitions.

3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored.

As described in 3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials). , LUKS/dm-crypt provides full-disk encryption that fulfills this requirement. Access to the stored data is only possible via a decryption password that must be entered when the disk is mounted.

A.3.4 Requirement 4: Encrypt Transmission of Cardholder Data Across Open, Public Networks

Cardholder data must be encrypted during transmissions over insecure networks. Ideally, encrypt all traffic, externally and internally. This makes it hard for attackers to gain inside information and privileged access to the cardholder data environment.

4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following: (1) Only trusted keys and certificates are accepted, (2) The protocol in use only supports secure versions or configurations, (3) The encryption strength is appropriate for the encryption methodology in use.

Any connection that transmits sensitive information must be protected against eavesdropping and tampering.

For incoming client requests, use the HTTPS protocol with a secure TLS connection. The authentication is done with a public X.509 certificate that proves to a certain level that the server is the right endpoint the customer is looking for.

SUSE Linux Enterprise Server comes with a set of services and tools that allow protected HTTPS connections. For example, this can be directly done with the Apache HTTP Server or via stunnel, which functions as a proxy to offer TLS encryption functionality.

IPsec or other VPN technologies can be used for securing the connection between network segments that are connected via a public network. Such connections can also be secured with a public X.509 certificate. For internal usage, it is possible to use a private Certificate Authority (CA) to sign X.509 certificates and to keep track of trusted keys.

In SUSE Linux Enterprise Server, this can be directly established with strongSwan, which is an IPsec-based VPN solution, or with OpenVPN, which uses a custom security protocol.

To administrate the OS, use SSH. For information about configuring SSH to provide better security, see Section A.3.1, “Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data” and Section A.3.2, “Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters”.

A.3.5 Requirement 5: Protect All Systems Against Malware and Regularly Update Anti-Virus Software or Programs

For PCI DSS compliance, it is necessary to protect against malicious software. Third-party anti-virus software is available from the major anti-virus software vendors and can be integrated into the Linux environment. SUSE Linux Enterprise Server comes with the open source anti-virus engine ClamAV.

ClamAV has a limited set of scanning capabilities and limited performance compared to third-party products. Hence, expect ClamAV to only provide basic protection.

On the other hand, ClamAV is shipped with SUSE Linux Enterprise Server and it can be included during server installation. This makes it easy to fulfill this requirement, but the drawbacks compared to third-party products need to be clearly understood.

A.3.6 Requirement 6: Develop and Maintain Secure Systems and Applications

The major part of this requirement concerns in-house software development, documentation, and design questions that are beyond the scope of this document. However, SUSE Linux Enterprise Server provides tools that help keep your systems safe:

  • The software package manager Zypper is a powerful instrument of SUSE Linux Enterprise Server. Among other things, it resolves dependencies of packages, products, patterns, and patches, has a locking mechanism to prevent package installation, and provides a complete update stack to keep the system up-to-date and protected against known security issues.

    zypper is part of any SUSE Linux Enterprise Server installation and has direct access to the update repositories after system registration.

    For information about Zypper, see Section 6.1, “Using Zypper”.

  • For system management, SUSE provides SUSE Manager, which provides an efficient way to keep systems up-to-date. It offers seamless management of both SUSE Linux Enterprise Server and Red Hat Enterprise Linux client systems. This is particularly useful in larger system environments, when you need to check the current update status of each system and to react to known security risks.

    For information about SUSE Manager, see https://documentation.suse.com/suma/.

6.2.a Examine policies and procedures related to security patch installation to verify processes are defined for: (1) Installation of applicable critical vendor-supplied security patches within one month of release, (2) Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

To identify patches that need to be installed to secure your system, do the following:

First, refresh all software repositories, so you have up-to-date information:

tux > sudo zypper refresh

Then use the patch-related commands of Zypper:

  • Search for important security fixes that have not yet been installed:

    tux > zypper list-patches --category security --severity important
  • It is also possible to search for CVE or SUSE Bugzilla numbers. By default, only necessary patches are listed by this command. To also show patches that have already been installed, use the parameter --all:

    tux > zypper list-patches --all --cve=CVE-2016-4957
  • To list details of individual patches, use the patch-info subcommand:

    tux > zypper patch-info SUSE-SLE-SERVER-12-SP1-2016-600
  • To install only important security patches, use the patch subcommand:

    tux > sudo zypper patch --category security --severity important

To perform updates automatically, the parameter --non-interactive, which is supported by all Zypper subcommands, is helpful.

For more information about Zypper, see Section 6.1, “Using Zypper”.

A.3.7 Requirement 7: Restrict Access to Cardholder Data by Business Need to Know

OS access control is a complex topic. Again, this PCI DSS requirement is not specified precisely and does not specifically state to what degree the restrictions need to be implemented. SUSE Linux Enterprise Server comes with all general Linux tools to limit and restrict access to certain system areas and components:

  • Access can be controlled via specific users and groups of users by using the traditional Unix permission settings.

    For information about managing permissions, see Chapter 11, Access Control Lists in Linux.

  • A more flexible mechanism for file systems are Access Control Lists (ACLs), which offer a more granular approach. SELinux can be used for maximum system separation and to protect processes from gaining more resources and access than allowed. SELinux or AppArmor are beyond the scope of this document but should be employed to protect critical systems that are likely to be targeted.

7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.

The standard Unix permissions allow setting Read, Write, and Execution flags for user and group IDs. A general group called others or world defines the access for users that do not fit into the first two groups. This provides a straightforward way to grant or deny access to file system resources.

ACLs provide an extra level of restrictions. It is possible to set read-write access for one user ID and only read access to a second one. The same goes for group IDs.

The commands getfacl and setfacl (on SUSE Linux Enterprise Server shipped with the package acl) allow direct modification of file system resources. For example, to check and set ACL restrictions of the file /tmp/test.txt for the user wilber:

tux > getfacl /tmp/test.txt
# file: /tmp/test.txt
# owner: tux
# group: users
user::r--
group::r--
other::r--

tux > setfacl -m "u:wilber:rw" /tmp/test.txt

tux > getfacl /tmp/test.txt
# file: /tmp/test.txt
# owner: tux
# group: users
user::rw-
user:wilber:r--
group::r--
mask::r--
other::r--

Standard Unix permissions include the so-called Sticky Bit. This allows the execution of certain programs with higher privileges than the user who is executing those programs. The best example of this is the passwd tool, which needs to modify the file /etc/shadow to change the user password.

For a more gradual approach to explicitly allowing certain operations or behaviors to binaries, use extended capabilities. As an example of a command that uses extended capabilities by default, consider ping (from the package iputils).

ping sends ICMP IP packets over the network card. To do so, it needs the CAP_NET_RAW capability to be Effective and Permitted (+ep):

root # sudo getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

Login access control to the system can be managed using Pluggable Authentication Modules (PAM). There are several modules available in SUSE Linux Enterprise Server that allow setups such as logging the login time, multiple authentication mechanisms and central databases like NIS, LDAP or Active Directory.

For more information about managing permissions, see Chapter 11, Access Control Lists in Linux.

A.3.8 Requirement 8: Identify and Authenticate Access to System Components

Ideally, use a central database with user information and a unique identifier (UID) to grant or deny access to certain system components. This makes it easy to give administrators special access to group of servers or a database engineer permission to a certain DBMS system.

On a stand-alone server, unique identifiers are managed via the standard Linux user and group IDs. These are listed in /etc/passwd and /etc/group.

8.1.4 Remove/disable inactive user accounts within 90 days.

In this context, there are many advantages to using a centralized infrastructure for user accounts like NIS, LDAP, or Active Directory:

  • It is easy to identify and automatically disable inactive accounts.

  • User accounts only need to be disabled in one place. After their access is revoked, the user cannot use any service that relies on the centralized account infrastructure.

However, if you are using local accounts, these can be checked for inactivity when a user is logging in. This module checks the last login time recorded in /var/log/lastlog and calculates the number of days since. By default, access is denied when the inactivity reaches 90 days.

To list the local accounts' last login time use the command lastlog.

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.

As stated in 8.1.4 Remove/disable inactive user accounts within 90 days. , a centralized account infrastructure will have this capability. On SUSE Linux Enterprise Server systems, access attempts can be checked and limited with the pam_tally2 PAM module. The module is executed during login time and checks the recorded failed attempts since the last successful login. To check and reset the account status, use the tool pam_tally2.

8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

The PAM module pam_tally2 described in 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. can be used to lock an account for a given time after a failed login attempt. The parameter unlock_time=1800 must be specified in the PAM configuration. By default, only the administrator can reactivate a locked account.

8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

To authenticate users for administrative access with multiple factors, use the following methods:

  • Use Pluggable Authentication Modules (PAM): This increases flexibility when adding new methods to the authentication process and when adjusting it.

    For third-party one-time password (OTP) products, there is usually also a Linux PAM module available.

    For information about PAM, see Chapter 2, Authentication with PAM.

  • To add multi-factor authentication for SSH connections, mandate use of public keys in addition to passwords.

    To connect to a system, it is then necessary to prove possession of an appropriate private key. At the second stage, you then enter a password. This means attackers need to acquire a private key before they can even try to brute-force a password prompt.

8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.

For details, see 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. .

A.3.9 Requirement 9: Restrict Physical Access to Cardholder Data

Physical access to systems that are involved in processing cardholder data are not within the scope of general operating system security. Appropriate facility entry controls must be in place to allow on-side personnel and visitors to access systems directly.

A.3.10 Requirement 10: Track and Monitor all Access to Network Resources and Cardholder Data

To track user activities, it is important to have a synchronized time reference. This is done via the NTP protocol, which allows servers to keep their local time in synchronization with a central system. The central NTP server inside the cardholder data environment (CDE) should not rely on external connections to the Internet to update the system time. Alternatively, system time can be updated using DCF77 radio transmissions or a GPS receiver.

A synchronized time reference makes it easier to correlate events inside recorded log files. This reference can include general system log entries collected by a central system log server or kernel audit messages by the daemon audit.

For information about auditing, see Part VI, “The Linux Audit Framework”.

All subsections of this requirement relevant to auditing can be complied with by defining auditing rules in a central storage.

A.3.11 Requirement 11: Regularly Test Security Systems and Processes

Testing the discussed security mechanisms is also a key requirement for PCI DSS. Evaluating the configurations and testing logging mechanisms can protect against known security risks and ensure that essential information is available to identify possible security breaches. Testing capabilities should be considered ahead of time, during the system design.

To keep track of system integrity, SUSE Linux Enterprise Server comes with the Advanced Intrusion Detection Environment (AIDE). AIDE creates a hash value database of all relevant OS files. After initialization, it can be used to verify the integrity of all previously saved files. To employ AIDE, it is best to regularly create database snapshots and save them to a central system on which you can evaluate possible modifications.

For more information about AIDE, see Chapter 14, Intrusion Detection with AIDE.

A.3.12 Requirement 12: Maintain a Policy That Addresses Information Security for All Personnel

Any organization that handles valuable information should have general security policy. All relevant aspects should be included to make it clear for employees and stakeholders what the possible risks are and how to avoid them.

All security policies should also be evaluated regularly and adjusted to keep the protection level as high as possible.