Additional Requirements

In this post, we will understand additional PCI DSS requirements for different types of entities.

Additional Requirements

A1: Multi-Tenant Service Providers

Multi-tenant service providers are a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web-based hosting services, payment applications, various cloud applications and services, and connections to payment gateways and processors.

A1.1 Multi-Tenant Service Providers Protect And Separate All Customer Environments And Data

A1.1.1 Logical separation is implemented as follows: • The provider cannot access its customers’ environments without authorization • Customers cannot access the provider’s environment without authorization

Providers should ensure strong separation between the environments that are designed for customer access, for example, configuration and billing portals, and the provider’s private environment that should only be accessed by authorized provider personnel.

A1.1.2 Controls are implemented such that each customer only has permission to access its own cardholder data and CDE

It is important that a multi-tenant service provider define controls so that each customer can only access their own environment and CDE to prevent unauthorized access from one customer’s environment to another.

A1.1.3 Controls are implemented such that each customer can only access resources allocated to them

To prevent any inadvertent or intentional impact to other customers’ environments or account data, it is important that each customer can access only resources allocated to that customer.

A1.1.4 The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing

Effectiveness of separation techniques can be confirmed by using service-provider-created temporary (mock-up) environments that represent customer environments and attempting to 1) access one temporary environment from another environment, and 2) access a temporary environment from the Internet.

A1.2 Multi-Tenant Service Providers Facilitate Logging And Incident Response For All Customers

A1.2.1 Audit log capability is enabled for each customer’s environment that is consistent including: • Logs are enabled for common third-party applications • Logs are active by default • Logs are available for review only by the owning customer • Log locations are clearly communicated to the owning customer • Log data and availability is consistent

Log information is useful for detecting and troubleshooting security incidents and is invaluable for forensic investigations. Customers therefore need to have access to these logs.

However, log information can also be used by an attacker for reconnaissance, and so a customer’s log information must only be accessible by the customer that the log relates to.

A1.2.2 Processes or mechanisms are implemented to support and/or facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer

In the event of a suspected or confirmed breach of confidentiality of cardholder data, a customer’s forensic investigator aims to find the cause of the breach, exclude the attacker from the environment, and ensure all unauthorized access is removed.

Prompt and efficient responses to forensic investigators’ requests can significantly reduce the time taken for the investigator to secure the customer’s environment.

A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including: • Customers can securely report security incidents and vulnerabilities to the provider • The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities

Security vulnerabilities in the provided services can impact the security of all the service provider’s customers and therefore must be managed in accordance with the service provider’s established processes, with priority given to resolving vulnerabilities that have the highest probability of compromise.

Customers are likely to notice vulnerabilities and security misconfigurations while using the service.

Implementing secure methods for customers to report security incidents and vulnerabilities encourages customers to report potential issues and enable the provider to quickly learn about and address potential issues within their environment.

A2: Entities Using SSL/Early TLS For Card-Present POS POI Terminal Connections

Entities using SSL and early TLS for POS POI terminal connections must work toward upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where those protocols don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment terminals. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up to date with vulnerability trends and determine whether it is susceptible to any known exploits.

A2.1 POI Terminals Using SSL And/Or Early TLS Are Confirmed As Not Susceptible To Known SSL/TLS Exploits

A2.1.1 Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols

However, SSL is outdated technology and could be susceptible to additional security vulnerabilities in the future; it is therefore strongly recommended that POS POI terminals be upgraded to a secure protocol as soon as possible. If SSL/early TLS is not needed in the environment, use of, and fallback to these versions should be disabled.

A2.1.2 Additional requirement for service providers only: All service providers with existing connection points to POS POI terminals that use SSL and/or early TLS have a formal Risk Mitigation and Migration Plan in place that includes: • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, and type of environment • Risk-assessment results and risk-reduction controls in place • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments • Overview of migration project plan to replace SSL/early TLS at a future date

Service providers should communicate to all customers using SSL/early TLS about the risks associated with its use and the need to migrate to a secure protocol.

A2.1.3 Additional requirement for service providers only: All service providers provide a secure service offering

Customers must be able to choose to upgrade their POIs to eliminate the vulnerability in using SSL and early TLS. In many cases, customers will need to take a phased or gradual approach to migrate their POS POI estate from the insecure protocol to a secure protocol and so will require the service provider to support a secure offering.

A3: Designated Entities Supplemental Validation (DESV)

This applies only to entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements. An entity is required to undergo an assessment according to this ONLY if instructed to do so by an acquirer or a payment brand.

A3.1 A PCI DSS Compliance Program Is Implemented

A3.1.1 Responsibility is established by executive management for the protection of account data and a PCI DSS compliance program that includes: • Overall accountability for maintaining PCI DSS compliance • Defining a charter for a PCI DSS compliance program • Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least once every 12 months

Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure.

Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.

A3.1.2 A formal PCI DSS compliance program is in place that includes: • Definition of activities for maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities • Annual PCI DSS assessment processes • Processes for the continuous validation of PCI DSS requirements (for example, daily, weekly, every three months, as applicable per the requirement) • A process for performing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions

The PCI DSS compliance program can be a dedicated program or part of overarching compliance and/or governance program, and should include a well-defined methodology that demonstrates consistent and effective evaluation.

Strategic business decisions that should be analyzed for potential PCI DSS impacts may include mergers and acquisitions, new technology purchases, or new payment-acceptance channels.

A3.1.3 PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel, including: • Managing PCI DSS business-as-usual activities • Managing annual PCI DSS assessments • Managing continuous validation of PCI DSS requirements (for example, daily, weekly, every three months, as applicable per the requirement) • Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions

Ownership should be assigned to individuals with the authority to make risk-based decisions, and upon whom accountability rests for the specific function. Duties should be formally defined, and owners should be able to demonstrate an understanding of their responsibilities and accountability.

Compliance roles may be assigned to a single owner or multiple owners for different requirement elements.

A3.1.4 Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance responsibilities

Individuals with PCI DSS compliance responsibilities should receive specialized training that, in addition to a general awareness of information security, focuses on specific security topics, skills, processes, or methodologies that must be followed for those individuals to perform their compliance responsibilities effectively.

Training may be offered by third parties such as the PCI SSC (for example, PCI Awareness, PCIP, and ISA), payment brands, and acquirers, or training may be internal. Training content should be applicable for the individual’s job function, be current, and include the latest security threats and/or version of PCI DSS.

A3.2 PCI DSS Scope Is Documented And Validated

A3.2.1 PCI DSS scope is documented and confirmed for accuracy at least once every three months and upon significant changes to the in-scope environment. At a minimum, the scoping validation includes: • Identifying all data flows for the various payment stages (for example, authorization, capture, settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce) • Updating all data-flow diagrams • Identifying all locations where account data is stored, processed, and transmitted, including but not limited to 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups • For any account data found outside of the currently defined CDE, either 1) securely delete it, 2) migrate it into the currently defined CDE, or 3) expand the currently defined CDE to include it • Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE • Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope • Identifying all connections to third-party entities with access to the CDE • Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope

Accurate scoping involves critically evaluating the CDE and all connected system components to determine the necessary coverage for PCI DSS requirements. Scoping activities, including careful analysis and ongoing monitoring, help to ensure that in-scope systems are appropriately secured. When documenting account data locations, the entity can consider creating a table or spreadsheet that includes the following information:

Data stores (databases, files, cloud, etc.), including purpose of data storage and the retention period,

Which CHD elements are stored (PAN, expiry date, cardholder name, and/or any elements of SAD prior to completion of authorization),

How data is secured (type of encryption and strength, hashing algorithm and strength, truncation, tokenization),

How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.).

In addition to internal systems and networks, all connections from third-party entities for example, business partners, entities providing remote support services, and other service providers need to be identified to determine inclusion for PCI DSS scope. Once the in-scope connections have been identified, the applicable PCI DSS controls can be implemented to reduce the risk of a third-party connection being used to compromise an entity’s CDE.

A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.

A3.2.2 PCI DSS scope impact for all changes to systems or networks is determined, including additions of new systems and new network connections. Processes include: • Performing a formal PCI DSS impact assessment • Identifying applicable PCI DSS requirements to the system or network • Updating PCI DSS scope as appropriate • Documented sign-off of the results of the impact assessment by responsible personnel

Processes to determine the potential impact that changes to systems and networks may have on an entity’s PCI DSS scope may be performed as part of a dedicated PCI DSS compliance program or may fall under an entity’s overarching compliance and/or governance program.

A3.2.2.1 Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks, and documentation is updated as applicable

A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through an iterative process.

A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls

An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to an organization’s structure and management to ensure controls are in place and active.

A3.2.4 If segmentation is used, PCI DSS scope is confirmed as follows: • Per the entity’s methodology. • Penetration testing is performed on segmentation controls at least once every six months and after any changes to segmentation controls/methods • The penetration testing covers all segmentation controls/methods in use • The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems

Although the requirement specifies that this scope validation is carried out at least once every six months and after a significant change, this exercise should be performed as frequently as possible to ensure it remains effective at isolating the CDE from other networks.

A3.2.5 A data-discovery methodology is implemented that: • Confirms PCI DSS scope • Locates all sources and locations of cleartext PAN at least once every three months and upon significant changes to the CDE or processes • Addresses the potential for cleartext PAN to reside on systems and networks outside the currently defined CDE

PCI DSS requires that, as part of the scoping exercise, assessed entities must identify and document the existence of all cleartext PAN in their environments. Implementing a data-discovery methodology that identifies all sources and locations of cleartext PAN and looks for cleartext PAN on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE for example, in an error log or memory dump file helps to ensure that previously unknown locations of cleartext PAN are detected and properly secured.

A3.2.5.1 Data discovery methods are confirmed as follows: • Effectiveness of methods is tested • Methods are able to discover cleartext PAN on all types of system components and file formats in use • The effectiveness of data-discovery methods is confirmed at least once every 12 months

For completeness, system components in the in-scope networks, and systems in out-of-scope networks, should be included in the data-discovery process.

The data-discovery process should be effective on all operating systems and platforms in use. Accuracy can be tested by placing test PANs on system components and file formats in use and confirming that the data-discovery method detected the test PANs.

A3.2.5.2 Response procedures are implemented to be initiated upon the detection of cleartext PAN outside the CDE to include: • Determining what to do if cleartext PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable • Determining how the data ended up outside the CDE • Remediating data leaks or process gaps that resulted in the data being outside the CDE • Identifying the source of the data • Identifying whether any track data is stored with the PANs

If PAN was found outside the CDE, an analysis should be performed to 1) determine whether it was saved independently of other data or with sensitive authentication data, 2) to identify the source of the data, and 3) identify the control gaps that resulted in the data being outside the CDE. Entities should consider whether contributory factors, such as business processes, user behavior, improper system configurations, etc., caused the PAN to be stored in an unexpected location. If such contributory factors are present, they should be addressed per this Requirement to prevent a recurrence.

A3.2.6 Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the CDE via an unauthorized channel, method, or process, including mechanisms that are: • Actively running • Configured to detect and prevent cleartext PAN leaving the CDE via an unauthorized channel, method, or process • Generating audit logs and alerts upon detection of cleartext PAN leaving the CDE via an unauthorized channel, method, or process

Coverage of the mechanisms should include, but not be limited to, e-mails, downloads to removable media, and output to printers.

A3.2.6.1 Response procedures are implemented to be initiated upon the detection of attempts to remove cleartext PAN from the CDE via an unauthorized channel, method, or process. Response procedures include: • Procedures for the prompt investigation of alerts by responsible personnel • Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss

Attempts to remove cleartext PAN via an unauthorized channel, method, or process may indicate malicious intent to steal data, or may be the actions of an authorized employee who is unaware of or simply not following the proper methods. Prompt investigation of these occurrences can identify where remediation needs to be applied and provides valuable information to help understand from where the threats are coming.

A3.3 PCI DSS Is Incorporated Into Business-As-Usual (BAU) Activities

A3.3.1 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of: • Network security controls • IDS/IPS • FIM • Anti-malware solutions • Physical access controls • Logical access controls • Audit logging mechanisms • Segmentation controls (if used) • Automated audit log review mechanisms • Automated code review tools (if used)

The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.

A3.3.2 Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the organization’s PCI DSS requirements

Organizations should also consider reviewing firmware versions to ensure they remain current and supported by the vendors.

Organizations also need to be aware of changes made by technology vendors to their products or processes to understand how such changes may impact the organization’s use of the technology.

Regular reviews of technologies that impact or influence PCI DSS controls can assist with purchasing, usage, and deployment strategies and ensure controls that rely on those technologies remain effective. These reviews include, but are not limited to, reviewing technologies that are no longer supported by the vendor and/or no longer meet the security needs of the organization.

A3.3.3 Reviews are performed at least once every three months to verify BAU activities are being followed. Reviews are performed by personnel assigned to the PCI DSS compliance program, and include: • Confirmation that all BAU activities are being performed • Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, ruleset reviews for network security controls, configuration standards for new systems) • Documenting how the reviews were completed, including how all BAU activities were verified as being in place • Collection of documented evidence as required for the annual PCI DSS assessment • Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program • Retention of records and documentation for at least 12 months, covering all BAU activities

These reviews can also be used to verify that appropriate evidence is being maintained for example, audit logs, vulnerability scan reports, reviews of network security control rulesets to assist in the entity’s preparation for its next PCI DSS assessment.

A3.4 Logical Access To The Cardholder Data Environment Is Controlled And Managed

A3.4.1 User accounts and access privileges to in-scope system components are reviewed at least once every six months to ensure user accounts and access privileges remain appropriate based on job function, and that all access is authorized

Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access.

This review provides another opportunity to ensure that accounts for all terminated users have been removed (if any were missed at the time of termination), as well as to ensure that any third parties that no longer need access have had their access terminated.

A3.5 Suspicious Events Are Identified And Responded To

A3.5.1 A methodology is implemented for the prompt identification of attack patterns and undesirable behavior across systems that includes: • Identification of anomalies or suspicious activity as it occurs • Issuance of prompt alerts upon detection of suspicious activity or anomaly to responsible personnel • Response to alerts in accordance with documented response procedures

The ability to identify attack patterns and undesirable behavior across systems for example, using centrally managed or automated log-correlation tools is critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something goes wrong. Determining the cause of a compromise is very difficult, if not impossible, without a process to corroborate information from critical system components and systems that perform security functions, such as network security controls, IDS/IPS, and file integrity monitoring (FIM) systems. Thus, logs for all critical system components and systems that perform security functions need to be collected, correlated, and maintained. This could include using software products and service methodologies to provide real-time analysis, alerting, and reporting, such as security information and event management (SIEM), FIM, or change detection.