WIXLIB

S C O P I N G AN D S E G M E N T A T I O NPCI DSS recommends that an assessed entity confirm the accuracy of their PCI DSS scope at leastannually or prior to the annual assessment. To help identify scope, the payment entity should evaluate theirsystems to identify all locations and flows of CHD and identify all systems that are connected to or, ifcompromised, could impact the CDE. Systems that store, process, or transmit CHD/SAD are categorizedas CDE systems. Likewise, system components that reside on the same network segment (for example,same subnet or VLAN) as systems that store, process, or transmit CHD/SAD are considered “CDESystems”. A second category in scope for assessment is “Connected-to or Security-impacting Systems”. Athird category of systems as defined by PCI DSS is called “Out-of-Scope Systems”. Out-of-scope systems,by definition, are typically not considered in scope for assessment; however, it is important to understandthat any system that is part of a payment entity’s infrastructure can potentially, through vulnerability or lackof adequate security control, provide a foothold to a zone of the payment entity’s internal network, whichmay be used to, over time, pivot and acquire increasing access until CHD is eventually compromised (PCISecurity Standards Council, 2016).PCI DSS recommends the use of network segmentation to isolate the CDE from the remainder of an entity’snetwork as a method to reduce the scope of PCI DSS assessment, the cost of a PCI DSS assessment, thecost and difficulty of implementing and maintaining PCI DSS controls, and the risk to an organization byconsolidating CHD into fewer, more controlled locations. The intent of segmentation is to preventtraditionally out-of-scope systems from being able to communicate with systems in the CDE and/or impactthe security of the CDE (PCI Security Standards Council, 2016).A P R O G R AM O F C O N T I N U O U S C O M P L I AN C EPCI DSS specifies a best practice for implementing PCI DSS into Business-as-Usual (BAU) processes.These best practices are designed to ensure that prescribed security controls continue to be implementedproperly, to monitor the effectiveness of security controls on an ongoing basis, and to maintain an entity’sPCI DSS compliant environment in between PCI DSS assessments. The recommended best practices forimplementing BAU processes include monitoring of security controls, ensuring that failures in securitycontrols are detected and responded to in a timely manner, and reviewing changes to the environment thatmay impact PCI DSS scope, changes to organizational structure, and the performance of periodic reviews(PCI Security Standards Council, 2016).SUGGESTIONS FOR USE OF THIS REPORTThis white paper is intended to be used by a variety of payment card entities and other interested partiesthat may be involved in the sale, construction, operation, or assessment of infrastructure using Red HatEnterprise Linux, Red Hat Satellite, Red Hat Insights, Red Hat Ansible Engine, and/or Red Hat AnsibleTower. It guides Red Hat customers with understanding how these solutions can be used to support aprogram of compliance. It provides examples of how this assessment may be utilized by the identifiedentities engaged in a PCI DSS lifecycle including merchants and financial institutions; payment solutionservice providers; Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) service providers;designated entities and others who share responsibility with a payment entity; and PCI DSS QSAs.INTRODUCING RED H AT SOLUTIONSRed Hat is the world’s leading provider of open source solutions, using a community-powered approach toprovide reliable and high-performing cloud, virtualization, storage, Linux, and middleware technologies. Thetransparency of Red Hat’s open source community-powered approach enables a greater scope of designdiversity than alternative closed development approaches. Due to this transparency, open source solutionshave the propensity to be more inherently secure. A larger community of developers and users are able toRed Hat Product Applicability Guide for PCI DSS 3.2 White Paper5

identify and correct discovered flaws on a more timely basis. Beyond this collaborative approach todelivering an enterprise operating platform and tools, Red Hat offers support, training, and consultation tohelp their customers successfully utilize the solutions that Red Hat provides.E N T E R P R I S E P L A T F O R M F O R T H E M O D E R N D AT A C E N T E RA platform for a modern data center should be able to keep up with the diverse demands of entities thatplan to use it. It should be adaptable, flexible, and sustainable to support ongoing hardware innovations. Itshould be able to support a diverse set of applications and business solutions with a wide array of deliveryoptions efficiently, effectively, reliably, and securely across private, public, and hybrid clouds. As anenterprise solution, it should be a consistent and stable platform. It should also be backed by support, tools,and solutions to optimize IT using the entity’s existing resources. Ideally, the platform should be designedwith security at the inception.The security built into the platform should be adaptable to address the ever-changing and constantlyevolving threat landscape. Simply protecting the entity’s boundary between “trusted” internal networks and“untrusted” or “unmanaged” external networks is no longer sufficient. Attackers are increasingly findingways to gain access to the internal network, often through insider access, and once inside can often pivotundetected across the “trusted” network. Placement of security controls closer to the sensitive or criticaldata is a way to reduce this risk. A zero-trust architecture, through well planned and executed accesscontrols (least access), network controls, eliminating unnecessary services (least function), use ofcryptography, and other security techniques, is useful to minimize the surface area of attack for internalassets and make it more difficult for attackers to find and gain access to protected data. The concept of azero-trust architecture assumes that a breach has already occurred and uses controls to minimize theimpact of that breach. Red Hat Enterprise Linux Server includes hardening guidance, as well as severalsecurity control features that are useful to support a zero-trust architecture.Red Hat Ent erprise Linux ServerThe foundation of Red Hat’s offering is Red Hat Enterprise Linux Server. There is broad applicability forRed Hat Enterprise Linux Server as a platform to serve various business applications and componentsincluding, but not limited to, traditional bare metal servers, hypervisors, virtual machines, and containerplatforms. The discussion of Red Hat Enterprise Linux Server for this paper is broad, but the securityfeatures, functionality, and capabilities are applicable across many of the use cases. For the purpose ofthis paper, Coalfire considers the use of Red Hat Enterprise Linux Server as a possible component of apayment entity’s CDE, which may have a role in storing, processing, or transmitting CHD/SAD, and/or asupporting system.Red Hat Enterprise Linux Server is a platform capable of supporting a multitude of application architectures.It provides fundamental core operating system functions including hardware resource managementcapabilities to orchestrate an infrastructure’s basic computing requirements including CPU, memory,network, and storage. Beyond the traditional operating system basics, Red Hat has incorporated a numberof security features and functions that are useful for entities looking to improve security or support variouscompliance initiatives.Red Hat provides guidance for securing Red Hat Enterprise Linux Server, which can be useful for securityand operations personnel planning for secure deployments of the operating platform. These hardeningguides are broken out by topics that align with general security best practices and common requirementsfound within various compliance frameworks. The guidance provided by Red Hat for Red Hat EnterpriseLinux Server is applicable and useful in general to varying degrees for aligning with PCI DSS requirements1, 2, 3, 6, 7, 8, 10, and 11. Detailed alignment can be found later in this document.Red Hat Product Applicability Guide for PCI DSS 3.2 White Paper6

In addition to hardening best practices, Red Hat has incorporated a number of available security featuresand functions into Red Hat Enterprise Linux Server. These features, when implemented, can help toimprove the management and functional security of the server platform across various deployment modes.Some of the integrated security features and functions that may be useful in a PCI DSS regulatedenvironment include disk and file level encryption, encryption for data in transit, Advanced IntrusionDetection Environment (AIDE), Domain Name System Security Extension (DNSSEC), USBGuard, MediaAccess Control Security (MACsec), Security Enhanced Linux (SELinux), identity management (IdM),compliance and vulnerability scanning with Open Security Content Automation Protocol (OpenSCAP),system auditing, firewalld, and iptables.Data-At-Rest Disk EncryptionRed Hat Enterprise Linux Server provides a number of data encryption options either for data at rest ordata in transit. Many of the requirements in PCI DSS v3.2 are applicable to how the payment applicationand/or payment hardware handle encryption and how the payment entity generates and secures encryptionkeys for the protection of CHD and SAD. While the encryption provided by Red Hat Enterprise Linux Serverdoes not specifically address all of the requirements and methodologies as it pertains to secure paymentapplication design, it can be useful for providing additional layers of security for specific use cases. RedHat Enterprise Linux Server complies with the Federal Information Processing Standard (FIPS) Publication140-2 and can be made compliant with the standard by enabling FIPS mode on the server.For data at rest, Red Hat Enterprise Linux Server includes Linux Unified Key Setup-on-disk-format (LUKS)disk encryption for full disk or partition encryption. This is useful for securing the contained data on diskwhen the server is powered off, when the disk is removed, or for removable media. Multiple ciphers, ciphermodes, and initial vectors are supported for enabling at-rest encryption on the server. Red Hat EnterpriseLinux Server also offers Policy Based Decryption (PBD) one of the implementations of which is calledNetwork Bound Disk Encryption (NBDE). NBDE allows for entire disks to be encrypted, including the bootdisk. For NBDE encryption, the target server enrolls with a remote server where the keys for encryption anddecryption are stored. The server involved with managing the keys and encryption for servers are thenetwork is needed in order for the disks to be decrypted. The entity can set up NBDE such that disks areunaccessible or unbootable and incapable of being decrypted if removed from the facility or from the systemon the network segment where NBDE is being used. The following steps outline the process for encryptionor decryption of disks using NBDE:1. Phase 1: Enrollmenta. During this phase the encryption key for the LUKS volume is encrypted with the public key ofthe remote decryption server.This operation can occur without direct access of the server.2. Phase 2: Decryptiona. The client generates a random key and wraps already encrypted volume key with a specialcryptographic operation. Then it sends the results to the serverb. The server decrypts the payload by removing the PKI encryption but the content is stillencrypted with the wrapping key so the server does not see the actual data.c.The client receives the response from the server and decrypts the payload to get direct accessto the key.d. The client then uses the key to unlock and mount the volume.Red Hat Product Applicability Guide for PCI DSS 3.2 White Paper7

On the client side is the Clevis framework. On the server side, on the network, is the system that will dothe remote unlocking that utilizes a TANG service. Figure 1 illustrates the components of NBDE for networkbased encryption and decryption of disks.Figure 1: NBDE Encryption ComponentsData-in-Transit EncryptionFor transmitted data, Red Hat Enterprise Linux Server provides options for securing communication eitherusing secure virtual private networks (VPNS), secure shell (SSH) with OpenSSH, OpenSSL, and stunnel.In Red Hat Enterprise Linux Server, VPNS can be configured using the IPsec tunneling protocol for hostto-host and/or site-to-site. SSH with OpenSSH provides a secure connectivity tool for remote login with theSSH protocol. OpenSSH encrypts traffic to protect against eavesdropping, connection hijacking, and otherattacks. OpenSSL is a library that provides cryptographic protocols to applications. The stunnel program isan encryption wrapper between a client and a server. It listens on the port specified in its configuration file,encrypts the communication with the client, and forwards the data to the original daemon listing on its usualport. This way, any service can be secured where the service itself does not support any type of encryption.Likewise, it can be used to improve the security of a service that uses a type of encryption that is not strongenough for the specific application, for instance SSL version 3 affected by the POODLE SSL vulnerability(SSL 2.0 is intentionally not supported on RHEL 7.4 and later).Red Hat Enterprise Linux Server provides support for the latest version of TLS. Included for support of theTLS protocol is OpenSSL, GnuTLS, and NSS toolkits. Additional guidance is provided by Red Hat forconfiguration of specific applications for TLS support such as Apache HTTP Server. Various cipher suitesare also available for TLS-secured communications.For additional secure authentication mechanisms and multi-factor authentication support, Red HatEnterprise Linux Server also provides Smart Card and Hardware Security Module (HSM) integration.MACsecMACsec encrypts and authenticates all traffic in LANs with the GCM-AES-128 algorithm. MACsec canprotect not only IP, but also Address Resolution Protocols (ARP), Neighbor Discovery (ND), or DHCP.While IPsec operates on the network (layer 3) and SSL and TLS on the transport layer (layer 4), MACsecRed Hat Product Applicability Guide for PCI DSS 3.2 White Paper8

operates in the data link layer (layer 2). Because it operates on layer 2 protocol, it can secure traffic fromhigher layer protocols as well. MACsec is an extension to 802.1x and provides secure key exchange andmutual authentication for MACsec nodes.AIDEAIDE is a utility on Red Hat Enterprise Linux Server that creates a database of files on the system and thenuses that database to ensure file integrity and detect system intrusions. AIDE can be scheduled to runduring regular intervals such as weekly at a minimum or daily at most.DNSSECDNSSEC enables a DNS client to authenticate and check the integrity of responses from a DNSnameserver in order to verify their origin and to identify if they have been tampered with in transit.Traditionally, DNS lookups are done insecurely and susceptible to man-in-the-middle attacks due to lack ofauthentication. Using insecure DNS lookups means that the client cannot have confidence that the repliesthat appear to have come from a given DNS name server are authentic and have not been tampered with.In the same way, a recursive name server cannot be sure that records that it obtains from othernameservers are genuine. An attacker can intercept traditional DNS requests and reply with falseinformation. In this way, an attacker can redirect a client to a website or service that he or she controls.USBGuardThe USBGuard software framework provides systems protection against intrusive USB devices byimplementing whitelisting and blacklisting capabilities based on device attributes. To enforce a host-basedpolicy, USBGuard uses a Linux kernel USB device authorization feature. This feature is typically moreimportant on end user devices such as workstation and laptops. Servers in the data center should bephysically protected to prevent unauthorized users from attaching USB devices. However, as an addedmeasure to protect against insider threats, USBGuard can be implemented on servers.SELinuxRed Hat Enterprise Linux Server comes with the SELinux Linux Kernel security module enabled by default.SELinux is an implementation of mandatory access control (MAC) mechanisms in the Linux kernel andprovides an additional layer of access control. After discretionary access controls (DAC) are checked,SELinux checks to determine if the requested operation is allowed. Flaws in programs or services that runwith coarse-grained privileges can potentially be exploited to escalate further systems access. SELinuxprovides finer-grained control over the activities that programs and services can take, even when executedby privileged users. Above identity and ownership access decisions, SELinux verifies the role of the user,the function and trustworthiness of the program, and the sensitivity and integrity of the data to determine ifthe action can be authorized.IdMRed Hat Enterprise Linux Server provides a centralized way to manage identities and define access-controlpolicies for users, machines, and services within large Linux and UNIX enterprise environments. Red HatEnterprise Linux IdM is a way to create identity stores, centralized authentication, domain control forKerberos and DNS services, and authorization policies, all on Linux systems using native Linux tools. Itprovides a unifying skin for standards-defined, common network services, including PAM, LDAP, Kerberos,DNS, NTP, and certificate services, allowing Red Hat Enterprise Linux Server to serve as domaincontrollers. IdM domain controllers can deliver enterprise-level single-sign-on, certificate management,DNS integration, and command-line and web user interfaces (UI) for managing enterprise identities,certificates, and keys.Red Hat Product Applicability Guide for PCI DSS 3.2 White Paper9

IdM is a management tool for Linux domains. It centralizes identity management and identity policies;whereas without IdM, each Linux server must be individually managed with unique identities and policiesper server. IdM is built on existing native Linux applications and protocols. The underlying technologies ofIdM would be more familiar for Linux administrators. The goal of IdM is to simplify administrative overheadby allowing users, machines, services, and policies for Linux systems to all be configured in one centralplace, using the same tools. Figure 2 graphically depicts the elements of IdM that can be administered forLinux and Unix systems in the IdM domain.Figure 2: IdM High-Level ArchitectureRed Hat Enterprise Linux IdM provides more advanced capabilities than LDAP, with support for advancedsecurity policies like sudo, host-based access control rules, automount, netgroups, SELinux user mappings,and other similar capabilities. In many environments, it is not uncommon for user accounts for both Linuxand Windows to be stored in Windows Active Directory. Red Hat Enterprise Linux IdM can coexist withActive Directory to provide additional identity management services for Linux systems. IdM simplifiesmaintenance of multiple domains by supporting interoperability with Microsoft Active Directory. Forinteroperability, Red Hat Enterprise Linux IdM provides two options: direct integration where Red HatEnterprise Linux systems are joined directly into an Active Directory domain and indirect access throughcross-realm Kerberos trusts between IdM in Red Hat Enterprise Linux Server and an Active Directory forest.Red Hat recommends an indirect integration approach, preferably using a trust-based solution leveragingIdM in Red

The Payment Card Industry Security Standards Council (PCI SSC) was founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa Inc. to serve those who work with and are . issuers, acquirers, and service providers. The PCI DSS security requirements apply to all system . PCI DSS compliant environment in between PCI .