diff --git a/pcidss/xml/art_security_pcidss.xml b/pcidss/xml/art_security_pcidss.xml index 532a290e..194daf1b 100644 --- a/pcidss/xml/art_security_pcidss.xml +++ b/pcidss/xml/art_security_pcidss.xml @@ -9,1148 +9,1011 @@ &productname;&sls;"> &productnumber;code stream 15"> ]> -
- - &sle_pcidss_guide; - &sle_pcidss_guide; - - &productnamex; - &productnumberx; - &productnameshort; - - - - https://bugzilla.suse.com/enter_bug.cgi - Security - Documentation - taroth@suse.com - - https://github.com/SUSE/doc-unversioned/tree/main/pcidss/xml/ - yes - - - - - To protect customers and the business itself, companies that handle - credit card payments must keep data as safe and secure as possible. - Following the &pcidss; 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 - &productnamex; can be configured to comply with the &pcidss;. - - - 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 &pcidssa; is the combination of actions: - - - - - Create a secure configuration. - - - - - Track and review all changes made to the configuration: who changed what - at which point in time. - - - - - - &pcidssa; Disclaimer + &sle_pcidss_guide; + &sle_pcidss_guide; + &productnamex; + &productnumberx;&productnameshort; + + + + https://bugzilla.suse.com/enter_bug.cgi + Security + Documentation + taroth@suse.com + + https://github.com/SUSE/doc-unversioned/tree/main/pcidss/xml/ + yes + + + + To protect customers and the business itself, companies that handle credit card payments + must keep data as safe and secure as possible. Following the &pcidss; 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. + + + - SUSE seeks to provide our customers with quick and easy guides that can - assist them in maintaining security compliance. Implementation of the - settings contained within this guide without its prior testing in a non-operational - environment is highly discouraged. The developers of these - profiles and documentation have made reasonable efforts to ensure overall - compliance. They assume no responsibility for its use by other parties, and - make no guarantee, expressed or implied, about its quality, reliability, or - any other characteristic. + This document aims to provide a basic understanding of how &productnamex; can be configured to + follow the &pcidss;. - - - - What is the &pcidssa;? - The &pcidss; (&pcidssa;) is a set of - requirements to guide a merchant to protect cardholder data. The - standard covers six main categories with currently 12 requirement topics - on how to implement, protect, maintain and monitor systems that are involved - in credit cardholder data processing. + It is important to understand that protecting systems includes more than configuration. The + entire environment and people involved must be taken into account. - &pcidssa; 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, &pcidssa; - 1.0 was released to address the growing threat of online credit card - fraud. The current version, &pcidssa; version 4.0, has been available since - March 2022. + An essential part of implementing &pcidssa; is the combination of actions: - - Build and maintain a secure network and systems - - - - - - - - - - - - - Protect cardholder data - - - - - - - - - - - - - Maintain a vulnerability management program - - - - - - - - - - - - - Implement strong access control measures - - - - - - - - - - - - - - - - - - Regularly monitor and test networks - - - - - - - - - - - - - Maintain an information security policy - - - - - + + + Create a secure configuration. + + + + + Track and review all changes made to the configuration: who changed what at which moment. + + - - Most requirements of &pcidssa; 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 - &pcidssa; and are necessarily subject to discussion. - - - - Focus of this document: areas relevant to the operating system - - The &pcidssa; 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 - - - + + &pcidssa; Disclaimer - System maintenance to protect against known vulnerabilities + SUSE seeks to provide our customers with quick and easy guides that can assist them in + maintaining security compliance. Implementation of the settings contained within this guide + without its prior testing in a non-operational environment is highly discouraged. The + developers of these profiles and documentation have made reasonable efforts to ensure overall + compliance. They assume no responsibility for its use by other parties, and make no + guarantee, expressed or implied, about its quality, reliability or any other characteristic. - - - - 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. - - - - Requirements in detail - - The following section provides an overview of the relevant parts of the - &pcidssa;, following the ordering of the standard itself. - + + + What is the &pcidssa;? - - 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, and other relevant - considerations. - - - In addition to a dedicated firewall and router, &productnamex; - comes with a host firewall based on iptables. The system can be - configured to allow only connections on certain inbound ports. With the - &yast; firewall module it is also possible to define more complex - rules, such as refusing connections from specific - addresses. This allows integrating the local system firewall into an - overall firewall design that maximizes network security. + The &pcidss; (&pcidssa;) is a set of requirements to guide a merchant to protect cardholder + data. The standard covers six main categories with currently 12 requirement topics on how to + implement, protect, maintain and monitor systems that are involved in credit cardholder data + processing. + - In generalized terms, the technical points in requirement 1 are the - following: + &pcidssa; 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, &pcidssa; 1.0 was released to address the growing threat + of online credit card fraud. The current version, &pcidssa; version 4.0, has been available + since March 2022. - - - - Identify insecure services and protocols. - - - - - Limit traffic to and from the system so that unwanted - traffic is not allowed. - - - - - - 1.1.6.b Identify insecure services, protocols, and ports allowed; - and verify that security features are documented for each service + + Build and maintain a secure network and systems - - 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 Verify that inbound and outbound traffic is limited to - that which is necessary for the cardholder data environment. - - - - Outbound traffic should only be allowed in specifically defined - cases. Create rules for allowed outbound traffic. - - - Make the SSH daemon only reachable on a separate administration - interface, and not on the general network interface if possible. - Define the source addresses that a service allows traffic from. - - - For example, to allow only outbound DNS requests over the - interface eth0 to server - 10.0.0.1, use: - -&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 23 \ - -d 10.0.0.1/32 -o eth0 -p udp -m udp --dport 53 -j ACCEPT -&prompt.sudo;firewall-cmd --reload - - To block all other outbound traffic, see . - + + + - - - - 1.2.1.c Verify that all other inbound and outbound traffic is - specifically denied. - - - Deny all outbound and inbound traffic for which no exceptions - are defined as stated in the previous section. Forwarding is - usually completely disabled by a kernel parameter, and should - not be enabled for endpoint servers. - - - &firewalld; in &productname; by default blocks all inbound - traffic. - - - To block all outbound traffic, manually add the following rules: - -&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 99 -j DROP -&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 99 -j DROP -&prompt.sudo;firewall-cmd --reload - - In addition, inbound traffic can also be configured for specific - 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. - + + + + Protect cardholder data - - There are two ways to implement anti-spoofing measurements in - &productnamex;: - - - - - <systemitem>iptables</systemitem> 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 &productnamex; and can be checked with - the following command: - - - &prompt.user;cat /proc/sys/net/ipv4/conf/all/rp_filter - - When enabled, this returns - 1. - - - + + + - - - - 1.3.5 Permit only established connections into the - network. - - - &firewalld; 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 an 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 &productnamex; 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. - + + + + Maintain a vulnerability management program - - A &productnamex; 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. - + + + - - - - - Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters - - During the installation of &productnamex;, 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 the - . - &productnamex; Security 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 needed security standards. This goes from limiting the used - protocols to only allow currently secure versions and to disable - legacy implementations, to the definition of access controls and - authentication. The default settings of &productnamex; 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 &ay; profile. This allows rolling out new instances of - &productnamex; and automatically enabling an evaluated configuration. - This setup procedure can also be automated with the &susemgr;. For - more information, see the &susemgr; documentation at - . - - - By default, &productnamex; 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 /etc/shadow, 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 either alone or in front of a password hash. - - - + + + - - - - 2.2 Develop configuration standards for all system components. Ensure - that these standards address all known security vulnerabilities and - are consistent with industry-accepted system hardening standards. - + + + + Implement strong access control measures - - As mentioned in the &pcidssa; document, possible sources for - industry-accepted hardening standards are: - - - - Center for Internet Security (CIS) - - - International Organization for Standardization (ISO) - - - SysAdmin Audit Network Security (SANS) Institute - - - National Institute of Standards Technology (NIST) - - - - As the &pcidssa; 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 the - - &productnamex; Security 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 &productnamex;: - &kvm;, &xen;, &lxc;, and &docker;. - - - You can also run &productnamex; on third-party virtualization servers - like &esx; or &hyperv; to achieve service separation. - - - When using the options built in to &productnamex;, see: - - - - - For information about virtualization, see - - &productnamex; Virtualization - Guide. - - - - - For information about containerization, see - - &productnamex; &deng; - Guide. - - - + + + - - - - 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 (). 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: - - - - &prompt.user;systemctl status SERVICE - - - &prompt.sudo;systemctl enable SERVICE - - - &prompt.sudo;systemctl disable SERVICE - - - - To list all available services that are installed on the system and - see their status, use the following command: - - &prompt.user;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. - + + + + Regularly monitor and test networks - - 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 &productnamex;, use &selnx; or &aa;. - However, the setup of these frameworks is beyond the scope of this - document: - - - - - For information about &selnx;, see - . - &productnamex; Security Guide, - Chapter Configuring &selnx;. - - - - - For information about &aa;, see - . - &productnamex; Security Guide, - Part Confining Privileges with &aa;. - - - + + + - - - - 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 dracut (replace NAME - with the name of the current initrd and - KERNELVERSION with the currently running - kernel). - - &prompt.sudo;/usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/$initrd-NAME $KERNELVERSION - - 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. - + + + + Maintain an information security policy - - 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. - + + + - - - - - Requirement 3: Protect stored cardholder data + + - This section explains how to handle cardholder and - authentication data securely. The following definitions apply: + Most requirements of &pcidssa; 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. - - - - 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. + 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 &pcidssa; and are necessarily subject to + discussion. + + + Focus of this document: areas relevant to the operating system + - The database design for storing cardholder data is beyond the scope of - this document. However, data can be encrypted in different ways: + The &pcidssa; covers a wide range of aspects related to cardholder data. Not all of these + aspects concern the operating system and this document does not focus on these. Instead, this + document focuses on aspects that affect OS configuration, including: + - - - The DBMS can use column-level encryption inside the database - scheme. - - - - - Alternatively, the database files can be encrypted. - - - - - &productnamex; 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 &pcidssa; 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 &productnamex; and can be used via - &yast; to create new partitions. - + + System security + - - - - 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 , - 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. - + + Access control + - - - - - 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. - - - &productnamex; comes with a set of services and tools that allow - protected HTTPS connections. For example, this can be done directly - 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 &productnamex;, this can be established directly with - strongSwan, which is a 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 - and - . - + + System maintenance to protect against known vulnerabilities + - - - - - Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs - - For &pcidssa; 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. &productnamex; 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 &productnamex; 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. + 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. - - - Requirement 6: Develop and maintain secure systems and applications + + + Requirements in detail + - The major part of this requirement concerns in-house software development, - documentation, and design questions that are beyond the scope of this - document. However, &productnamex; provides tools that help keep your - systems safe: + The following section provides an overview of the relevant parts of the &pcidssa;, following + the ordering of the standard itself. - - + + + Requirement 1: Install and maintain a firewall configuration to protect cardholder data - The software package manager Zypper is a powerful instrument of - &productnamex;. 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. + The listed terms in this section are 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, and other relevant considerations. - zypper is part of any &productnamex; installation and - has direct access to the update repositories after system registration. + In addition to a dedicated firewall and router, &productnamex; comes with a host firewall + based on iptables. The system can be configured to allow only connections on certain + inbound ports. With the &yast; firewall module it is also possible to define more complex + rules, such as refusing connections from specific addresses. This allows integrating the + local system firewall into an overall firewall design that maximizes network security. - For information about Zypper, see - . - &productnamex; Administration Guide, - Chapter Managing Software with Command Line Tools, Section Using - Zypper. + 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 unwanted traffic is not allowed. + + + + + + 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 Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment. + + + Outbound traffic should only be allowed in specifically defined cases. Create rules + for allowed outbound traffic. + + + Make the SSH daemon only reachable on a separate administration interface, and not on + the general network interface if possible. Define the source addresses that a service + allows traffic from. + + + For example, to allow only outbound DNS requests over the interface + eth0 to server + 10.0.0.1, use: + +&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 23 \ + -d 10.0.0.1/32 -o eth0 -p udp -m udp --dport 53 -j ACCEPT +&prompt.sudo;firewall-cmd --reload + + To block all other outbound traffic, see . + + + + + 1.2.1.c Verify that all other inbound and outbound traffic is specifically denied. + + + Deny all outbound and inbound traffic for which no exceptions are defined as stated + in the previous section. Forwarding is usually disabled by a kernel parameter, and + should not be enabled for endpoint servers. + + + &firewalld; in &productname; by default blocks all inbound traffic. + + + To block all outbound traffic, manually add the following rules: + +&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 99 -j DROP +&prompt.sudo;firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 99 -j DROP +&prompt.sudo;firewall-cmd --reload + + Also, inbound traffic can also be configured for specific 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 &productnamex;: + + + + + <systemitem>iptables</systemitem> rules that only allow input from certain addresses on specified interfaces + + The used address space for communications can be 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 &productnamex; and + can be checked with the following command: + + +&prompt.user;cat /proc/sys/net/ipv4/conf/all/rp_filter + + When enabled, this returns 1. + + + + + + + 1.3.5 Permit only established connections into the network. + + + &firewalld; 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 an 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 &productnamex; 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 &productnamex; 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 + 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. + + + + + + + + Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters - For system management, &suse; provides &susemgr;, which provides an - efficient way to keep systems up-to-date. It offers seamless - management of both &productnamex; and &rhel; 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. + During the installation of &productnamex;, 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 information about &susemgr;, see the - &susemgr; - documentation page. + For more information about OS security, see the + . + &productnamex; Security Guide. - - - - - - 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: - - &prompt.sudo;zypper refresh - - Then use the patch-related commands of Zypper: - - + + + 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 needed security + standards. This goes from limiting the used protocols to only allow currently secure + versions and to disable legacy implementations, to the definition of access controls + and authentication. The default settings of &productnamex; 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 &ay; + profile. This allows rolling out new instances of &productnamex; and automatically + enabling an evaluated configuration. This setup procedure can also be automated with + the &susemgr;. For more information, see the &susemgr; documentation at + . + + + By default, &productnamex; 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 /etc/shadow, 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 either alone or in front of a password hash. + + + + + + + 2.2 Develop configuration standards for all system components. Ensure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. + + + As mentioned in the &pcidssa; document, possible sources for industry-accepted + hardening standards are: + + + + + Center for Internet Security (CIS) + + + + + International Organization for Standardization (ISO) + + + + + SysAdmin Audit Network Security (SANS) Institute + + + + + National Institute of Standards Technology (NIST) + + + + + As the &pcidssa; 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 + the + &productnamex; Security 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 &productnamex;: &kvm;, &xen;, &lxc;, and &docker;. + + + You can also run &productnamex; on third-party virtualization servers like &esx; or + &hyperv; to achieve service separation. + + + When using the options built in to &productnamex;, see: + + + + + For information about virtualization, see + + &productnamex; Virtualization + Guide. + + + + + For information about containerization, see + + &productnamex; &deng; Guide. + + + + + + + 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 + (). All parties involved must be aware + of the dangers of using insecure communication. Research, document and communicate + the risk of using insecure protocols and services. + + + Enable and disable system services using the following systemctl + commands: + + + +&prompt.user;systemctl status SERVICE + + +&prompt.sudo;systemctl enable SERVICE + + +&prompt.sudo;systemctl disable SERVICE + + + + To list all available services that are installed on the system and see their status, + use the following command: + +&prompt.user;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 &productnamex;, use &selnx; or &aa;. However, the + setup of these frameworks is beyond the scope of this document: + + + + + For information about &selnx;, see + . + &productnamex; Security Guide, Chapter + Configuring &selnx;. + + + + + For information about &aa;, see + . + &productnamex; Security Guide, Part Confining + Privileges with &aa;. + + + + + + + 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 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 dracut (replace + NAME with the name of the current initrd and + KERNELVERSION with the currently running kernel). + +&prompt.sudo;/usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/$initrd-NAME $KERNELVERSION + + 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 is 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. + + + + + + + + Requirement 3: Protect stored cardholder data + + This section explains how to handle cardholder and authentication data securely. The + following definitions apply: + + - - Search for important security fixes that have not yet been - installed: - - &prompt.user;zypper list-patches --category security --severity important + + Cardholder data includes information such as the cardholder name + and the Primary Account Number (PAN). + - - 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 : - - &prompt.user;zypper list-patches --all --cve=CVE-2016-4957 + + 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: + + - - To list details of individual patches, use the - patch-info subcommand: - - &prompt.user;zypper patch-info SUSE-SLE-Product-SLES-15-SP3-2021-2126 + + The DBMS can use column-level encryption inside the database scheme. + - - To install only important security patches, use the - patch subcommand: - - &prompt.sudo;zypper patch --category security --severity important + + Alternatively, the database files can be encrypted. + + + + + &productnamex; supports full-disk encryption, so that the whole database storage is + always encrypted. However, access to an encrypted disk works the same way as a + non-encrypted disk. This is discussed in more detail in requirement 3.4.1. + - - - To perform updates automatically, the parameter - , which is supported by all - Zypper subcommands, is helpful. - + + + + 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 host operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials). + + + The guidance description of the &pcidssa; 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 follow 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 &productnamex; 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 , 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. + + + + + + + + Requirement 4: Encrypt transmission of cardholder data across open, public networks - For more information about Zypper, see - . - &productnamex; Administration Guide, - Chapter Managing Software with Command Line Tools, Section Using - Zypper. + 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. + + + &productnamex; comes with a set of services and tools that allow protected HTTPS + connections. For example, this can be done directly 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 &productnamex;, this can be established directly with + strongSwan, which is a 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 and + . + + + + + + + + Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs + + For &pcidssa; 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. &productnamex; comes with the open source + anti-virus engine &clamav;. - - - - - - Requirement 7: Restrict access to cardholder data by business need to know - - OS access control is a complex topic. Again, this &pcidssa; requirement - is not specified precisely and does not specifically state to what - degree the restrictions need to be implemented. - &productnamex; 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. + &clamav; has a limited set of scanning capabilities and limited performance compared to + third-party products. Hence, expect &clamav; to only provide basic protection. - For information about managing permissions, see - . - &productnamex; Security Guide, - Chapter Access Control Lists in Linux. + On the other hand, &clamav; is shipped with &productnamex; 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 understood. - - + + + + Requirement 6: Develop and maintain secure systems and applications - A more flexible mechanism for file systems are Access Control Lists - (ACLs), which offer a more granular approach. &selnx; can be used for - maximum system separation and to prevent processes from gaining more - resources and access than allowed. - &selnx; and &aa; are beyond the scope of this document but should be - employed to protect critical systems that are likely to be targeted. + The major part of this requirement concerns in-house software development, documentation + and design questions that are beyond the scope of this document. However, &productnamex; + provides tools that help keep your systems safe: - - - For information about &selnx;, see - . - &productnamex; Security Guide, - Chapter Configuring &selnx;. - - - - - For information about &aa;, see - . - &productnamex; Security Guide, - Part Confining Privileges with &aa;. - - + + + The software package manager Zypper is a powerful instrument of &productnamex;. 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 &productnamex; installation and has direct + access to the update repositories after system registration. + + + For information about Zypper, see + . + &productnamex; Administration Guide, Chapter Managing + Software with Command Line Tools, Section Using Zypper. + + + + + For system management, &suse; provides &susemgr;, which provides an efficient way to + keep systems up-to-date. It offers seamless management of both &productnamex; and + &rhel; 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 &susemgr;, see the + &susemgr; documentation + page. + + - - - - - - 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 for a second - one. The same goes for group IDs. - - - The commands getfacl and - setfacl (on &productnamex; 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 &exampleuserII;: - + + + 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: + +&prompt.sudo;zypper refresh + + Then use the patch-related commands of Zypper: + + + + + Search for important security fixes that have not yet been installed: + +&prompt.user;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 : + +&prompt.user;zypper list-patches --all --cve=CVE-2016-4957 + + + + To list details of individual patches, use the patch-info + subcommand: + +&prompt.user;zypper patch-info SUSE-SLE-Product-SLES-15-SP3-2021-2126 + + + + To install only important security patches, use the patch + subcommand: + +&prompt.sudo;zypper patch --category security --severity important + + + + To perform updates automatically, the parameter , + which is supported by all Zypper subcommands, is helpful. + + + For more information about Zypper, see + . + &productnamex; Administration Guide, Chapter Managing + Software with Command Line Tools, Section Using Zypper. + + + + + + + + Requirement 7: Restrict access to cardholder data by business need to know + + OS access control is a complex topic. Again, this &pcidssa; requirement is not specified + precisely and does not specifically state to what degree the restrictions need to be + implemented. &productnamex; 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 + . + &productnamex; Security Guide, Chapter Access Control + Lists in Linux. + + + + + A more flexible mechanism for file systems are Access Control Lists (ACLs), which offer + a more granular approach. &selnx; can be used for maximum system separation and to + prevent processes from gaining more resources and access than allowed. &selnx; and &aa; + are beyond the scope of this document but should be employed to protect critical + systems that are possible targets. + + + + + For information about &selnx;, see + . + &productnamex; Security Guide, Chapter Configuring + &selnx;. + + + + + For information about &aa;, see + . + &productnamex; Security Guide, Part Confining + Privileges with &aa;. + + + + + + + + 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 for a second one. The same goes for group IDs. + + + The commands getfacl and setfacl (on + &productnamex; 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 &exampleuserII;: + &prompt.user;getfacl /tmp/test.txt # file: /tmp/test.txt @@ -1172,264 +1035,240 @@ 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 - /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): - + + 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 /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): + &prompt.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 &productnamex; that allow setups such as - logging the login time, multiple authentication mechanisms, and - central databases like NIS, LDAP, or &ad;. - + + Login access control to the system can be managed using Pluggable Authentication + Modules (PAM). There are several modules available in &productnamex; that allow + setups such as logging the login time, multiple authentication mechanisms, and + central databases like NIS, LDAP or &ad;. + + + For more information about managing permissions, see + . + &productnamex; Security Guide, Chapter Access Control + Lists in Linux. + + + + + + + + Requirement 8: Identify and authenticate access to system components - For more information about managing permissions, see - . - &productnamex; Security Guide, - Chapter Access Control Lists in Linux. + 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 a group of servers or a database engineer permission for a + certain DBMS system. - - - - - - 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 a group of - servers or a database engineer permission for 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 &ad;: + 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. - - - - 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. - - - + + + 8.1.4 Remove or 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 &ad;: + + + + + 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 account's 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 , a centralized account + infrastructure has capability. On &productnamex; 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 + 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 + . + &productnamex; Security Guide, Chapter + 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 . + + + + + + + + Requirement 9: Restrict physical access to cardholder data - 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. + Physical access to systems that are involved in processing cardholder data is not within + the scope of general operating system security. Appropriate facility entry controls must be + in place to allow on-site personnel and visitors to access systems directly. + + + + Requirement 10: Track and monitor all access to network resources and cardholder data - To list the local account's last login time use the command - lastlog. + 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. - - - - - 8.1.6 Limit repeated access attempts by locking out the user ID after - not more than six attempts. - - - - As stated in , a centralized - account infrastructure will have this capability. On &productnamex; - 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 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 - . - &productnamex; Security Guide, - Chapter 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 . - - - - - - - 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-site personnel and visitors to access systems directly. - - - - 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 - . - &productnamex;, Security Guide, - Part &auditguide;. - - - All auditing requirements from this section can be fulfilled by defining - centrally stored auditing rules. - - - - Requirement 11: Regularly test security systems and processes - - Testing the discussed security mechanisms is also a key requirement for - &pcidssa;. 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 during system - design, before installation and deployment. - - - To keep track of system integrity, &productnamex; 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 - . - &productnamex; Security Guide, - Chapter Intrusion Detection with &aide;. - - - - Requirement 12: Maintain a policy that addresses information security for all personnel - - Any organization that handles valuable information should - have a 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. - - - - - + + 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 + . + &productnamex;, Security Guide, Part + &auditguide;. + + + All auditing requirements from this section can be fulfilled by defining centrally stored + auditing rules. + + + + + Requirement 11: Regularly test security systems and processes + + Testing the discussed security mechanisms is also a key requirement for &pcidssa;. + 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 during system design, before + installation and deployment. + + + To keep track of system integrity, &productnamex; 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 + . + &productnamex; Security Guide, Chapter Intrusion Detection + with &aide;. + + + + + Requirement 12: Maintain a policy that addresses information security for all personnel + + Any organization that handles valuable information should have a 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. + + + + +