0% found this document useful (0 votes)

653 views65 pages

PCI 3DS Core Security Standard v1

Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server

Uploaded by

Al QUin

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

653 views65 pages

PCI 3DS Core Security Standard v1

Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server

Uploaded by

Al QUin

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 65

Payment Card Industry

3-D Secure (PCI 3DS)

Security Requirements and Assessment Procedures for

EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server
Version 1.0
October 2017
Document Changes
Date Version Description

October 2017 1.0 Initial version

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 2
Table of Contents
Document Changes ..................................................................................................................................................................................................... 2
Introduction .................................................................................................................................................................................................................. 5
Terminology ................................................................................................................................................................................................................ 7
Roles and Responsibilities ......................................................................................................................................................................................... 8
Scope of PCI 3DS Core Security Standard .............................................................................................................................................................. 10
3DS Data .................................................................................................................................................................................................................. 10
Relationship between PCI 3DS Core Security Standard and PCI DSS ................................................................................................................... 10
Use of Third-Party Service Providers / Outsourcing .............................................................................................................................................. 11
3DS Security Requirements and Assessment Procedures ................................................................................................................................... 12
Risk-Management Approach to Requirements ........................................................................................................................................................ 12
Validating Requirements .......................................................................................................................................................................................... 12
Compensating Controls ............................................................................................................................................................................................ 13
3DS Assessment Process ........................................................................................................................................................................................ 13
Part 1: 3DS Baseline Security Requirements .......................................................................................................................................................... 14
Requirement P1-1. Maintain security policies for all personnel ............................................................................................................................... 14
Requirement P1-2. Secure network connectivity ..................................................................................................................................................... 17
Requirement P1-3. Develop and maintain secure systems ..................................................................................................................................... 19
Requirement P1-4. Vulnerability management......................................................................................................................................................... 23
Requirement P1-5. Manage access ......................................................................................................................................................................... 26
Requirement P1-6. Physical Security ....................................................................................................................................................................... 28
Requirement P1-7. Incident response preparedness ............................................................................................................................................... 30
Part 2: 3DS Security Requirements .......................................................................................................................................................................... 33
Requirement P2-1. Validate scope ........................................................................................................................................................................... 33
Requirement P2-2. Security governance ................................................................................................................................................................. 34

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 4
Introduction
This document, the PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS
Server (hereafter referred to as the “PCI 3DS Core Security Standard”), defines physical and logical security requirements and assessment
procedures for entities that perform or provide the following functions, as defined in the EMV® 3-D Secure Protocol and Core Functions
Specification:
 3DS Server (3DSS)

 3DS Directory Server (DS)

 3DS Access Control Server (ACS)

The requirements in this PCI 3DS Core Security Standard are organized in two parts:

 Part 1: Baseline Security Requirements – A baseline of technical and operational security requirements designed to protect the 3DS
data environment (3DE)

 Part 2: 3DS Security Requirements – Security requirements to protect 3DS data and processes

This standard does not address how an entity would meet the requirements in the EMV® 3-D Secure Note: Whether an entity is
Protocol and Core Functions Specification. Rather, this document defines the security controls needed to required to validate to the PCI
protect environments where specific 3DS functions occur. Entities performing these functions may be 3DS Core Security Standard is
subject to the requirements in this document. To determine whether an entity is required to meet these determined by payment brand
requirements, confirm with the payment brand for which the functions are performed. compliance programs.

The requirements in this standard cover EMV® 3-D Secure implementations. Table 1 provides a high-level overview of the PCI 3DS Core Security
Standard requirements.

PCI 3DS Part 1: Baseline Security Requirements PCI 3DS Part 2: 3DS Security Requirements
1. Maintain security 1.1 Maintain security policies 1. Validate scope 1.1 Scoping
policies for all 1.2 Evaluate risk
personnel 1.3 Educate personnel
1.4 Screen personnel
2. Secure network 2.1 Protect 3DS systems from 2. Security governance 2.1 Security governance
connectivity untrusted systems and networks 2.2 Manage risk
2.2 Protect 3DS systems from network 2.3 Business as usual (BAU)
threats 2.4 Manage third-party relationships
3. Develop and 3.1 Secure application development 3. Protect 3DS systems 3.1 Protect boundaries
maintain secure 3.2 Configuration standards and applications 3.2 Protect baseline configurations
systems 3.3 Change management 3.3 Protect applications and application
interfaces
3.4 Secure web configurations
3.5 Maintain availability of 3DS operations
4. Vulnerability 4.1 Protect against malicious software 4. Secure logical access 4.1 Secure connections for issuer and
management 4.2 Address vulnerabilities and security to 3DS systems merchant customers
weaknesses 4.2 Secure internal network connections
4.3 Secure remote access
4.4 Restrict wireless exposure
4.5 Secure VPNs
5. Manage access 5.1 Access management 5. Protect 3DS data 5.1 Data lifecycle
5.2 Account management 5.2 Data transmission
5.3 Authentication 5.3 TLS configuration
5.4 Data storage
5.5 Monitoring 3DS transactions
6. Physical security 6.1 Restrict physical access 6. Cryptography and key 6.1 Key management
6.2 Secure media management 6.2 Secure logical access to HSMs
6.3 Secure physical access to HSMs
7. Incident response 7.1 Incident response plan 7. Physically secure 3DS 7.1 Data center security
preparedness 7.2 Audit logs systems 7.2 CCTV

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 6
Terminology
Definitions for PCI terminology used throughout this document are provided in the general PCI Glossary on the PCI SSC website:
https://www.pcisecuritystandards.org/pci_security/glossary.
Additionally, the following terms are used in this PCI 3DS Core Security Standard:
 Authentication Value (AV) – As defined in the EMV® 3-D Secure Protocol and Core Functions Specification: A cryptographic value
generated by the ACS to provide a way, during authorization processing, for the authorization system to validate the integrity of the
authentication result. The AV algorithm is defined by each Payment System.

 3-D Secure (3DS) – As defined in the EMV® 3-D Secure Protocol and Core Functions Specification: An authentication protocol that
enables the secure processing of payment and non-payment card transactions.

 3DE – Acronym for 3DS data environment. The 3DE is a secure area within which ACS, DS, and/or 3DSS functions are performed, as
described in the EMV® 3-D Secure Protocol and Core Functions Specification.

 3DS data – Covers a number of discrete data elements as defined in the EMV® 3-D Secure Protocol and Core Functions Specification,
and generally includes any data transmitted within 3DS messages.

 3DS entity – Term used to describe entities that perform 3DSS, ACS, and/or DS functions as defined in the EMV® 3-D Secure Protocol
and Core Functions Specification.

 3DS messages – A set of messages—for example, PReq, PRes, CReq, CRes, etc.—that are used to convey information between 3DS
components, as described in the EMV® 3-D Secure Protocol and Core Functions Specification.

 3DS sensitive data – Specific data elements requiring additional protection as defined in the PCI 3DS Data Matrix. Data in this category
includes 3DS authentication data, public-key data, authentication challenge data (CReq/CRes), and cardholder challenge data.

 3DS system – General description for any system component—for example, network device, server, computing device, or application—
that performs or supports a 3DS function or comprises the 3DE infrastructure.

 Consumer Device Information (CDI) – Data provided by the Consumer Device that is used in the authentication process. The Consumer
Device—for example, a smartphone, laptop, or tablet—is used by a cardholder to conduct payment activities, including authentication and
purchase.

 Cardholder Verification Method (CVM) – A process used to confirm that the person presenting a payment card (or payment token) is the
legitimate cardholder. Examples of static CVM data include online PIN, offline PIN, challenge-response, shared secret/static password,
and biometric. Examples of dynamic CVM data include a one-time passcode (OTP).

Definitions and terminology related to the 3-D Secure Protocol can be found in the EMV® 3-D Secure Protocol and Core Functions Specification
(www.emvco.com).
PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 7
Roles and Responsibilities
There are several stakeholders involved in maintaining and managing PCI standards. The following describes the high-level roles and
responsibilities as they relate to the PCI 3DS Core Security Standard.

PCI SSC
PCI SSC maintains various PCI standards, supporting programs, and related documentation. In relation to the PCI 3DS Core Security
Standard, PCI SSC:
 Maintains the PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and
3DS Server (this document, hereafter referred to as the PCI 3DS Core Security Standard).
 Maintains supporting documentation including reporting templates, attestation forms, frequently asked questions (FAQs), and guidance
to assist entities implementing and assessing to the PCI 3DS Core Security Standard.
 Provides training for assessors evaluating 3DS entities in accordance with the requirements and assessment procedures in the PCI 3DS
Core Security Standard.
 Maintains the list of qualified assessors on the PCI SSC Website.
 Maintains a quality assurance program for qualified assessors.

Participating Payment Brands

The Participating Payment Brands develop and enforce their respective programs related to compliance with PCI standards including, but not
limited to:
 Requirements, mandates, and deadlines for compliance to PCI standards.
 Which organizations are required to comply with a PCI standard.
 Validation methods and frequency.

 Fines or penalties for non-compliance.

EMVCo
EMVCo is the global technical body owned by American Express, Discover, JCB, MasterCard, UnionPay, and Visa that facilitates the
worldwide interoperability and acceptance of secure payment transactions by managing and evolving the EMV Specifications and related
testing processes. Adoption of EMV Specifications and associated approval and certification processes promotes a unified international
payments framework, which supports an advancing range of payment methods, technologies, and acceptance environments.

3DS Access Control Server (ACS)

The ACS contains the authentication rules and is controlled by the Issuer. The ACS verifies whether authentication is available for a card
number and device type, and authenticates specific transactions. Specific ACS functions include:
 Verifying whether a card number is eligible for 3DS authentication.
 Verifying whether a Consumer Device type is eligible for 3DS authentication.
 Authenticating the Cardholder for a specific transaction.

3DS Directory Server (DS)

The DS maintains lists of card ranges for which authentication may be available and coordinates communication between the 3DSS and
ACS to determine whether authentication is available for a particular card number and device type. DS functions include:
 Authenticating the 3DS Server and the ACS.
 Routing messages between the 3DS Server and the ACS.
 Validating the 3DS Server, the 3DS SDK, and the 3DS Requestor.
 Defining specific program rules (for example, logos, time-out values, etc.).
 Onboarding 3DS Servers and ACSs.
 Maintaining ACS versions and 3DS Method URLs.

3DS Server (3DSS)

The 3DSS provides the functional interface between the 3DS Requestor Environment flows and the Directory Server (DS). Functions
performed by the 3DS Server include:
 Collecting necessary data elements for 3DS messages.
 Authenticating the DS.
 Validating the DS, the 3DS SDK, and the 3DS Requestor.
 Ensuring that message contents are protected.
The 3DS Server may also link to the Acquirer and initiate authorization requests.

1 For further information about 3DS roles and functions, refer to the EMV® 3-D Secure Protocol and Core Functions Specification.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 9
Scope of PCI 3DS Core Security Standard
The PCI 3DS Core Security Standard applies to environments where ACS, DS, and/or 3DSS functions are performed. Typically, this will consist of
the 3DS Environment (3DE), which contains system components involved in performing or facilitating 3DS transactions, as well as system
components supporting the 3DE. The term “system components” includes network devices, servers, computing devices, and applications.
Examples of system components include but are not limited to:
 Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or
may impact the security of (for example, name resolution or web redirection servers) the 3DE.
 Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and
hypervisors.
 Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other
security appliances.
 Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and
Domain Name System (DNS).
 Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.
 Any other component or device located within or connected to the 3DE.

3DS Data
3DS transaction processes involve a number of discrete data elements that may be also used for purposes other than performing 3DS
transactions. Requirements in this standard that address “3DS data” apply where such data is part of a 3DS transaction process or is otherwise
present where ACS, DS, and/or 3DSS functions occur—that is, within a 3DE. Data that exist outside of a 3DE and used only for purposes
unrelated to 3DS transactions are not in scope for this standard.

Relationship between PCI 3DS Core Security Standard and PCI DSS
There is an independent relationship between the PCI 3DS Core Security Standard and PCI DSS. A 3DE could be part of a cardholder data
environment (CDE) or be completely separate from any CDE. If a 3DE contains account data, it may be subject to PCI DSS and/or the PCI 3DS
Core Security Standard in accordance with payment brand compliance programs.
Where a 3DS entity has already applied PCI DSS to protect its 3DE as part of its CDE, the 3DS entity may be able to leverage the results of its
PCI DSS assessment to meet the PCI 3DS Part 1: Baseline Security Requirements. Refer to Appendix B, “Alignment between PCI 3DS and PCI
DSS Requirements,” for details.
Whether a 3DS entity is required to validate to PCI DSS, to the PCI 3DS Core Security Standard, or to both is defined by individual payment brand
compliance programs.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 10
Use of Third-Party Service Providers / Outsourcing
3DS entities will often outsource or rely on a third-party service provider for certain functionality of the 3DE. Common examples include hosting of
applications, management of network devices or databases, and maintenance of physical security. Additionally, a 3DS entity may outsource
aspects of the 3DS transaction process—for example, performing risk-based analysis of 3DS transactions—to an external third party. Where a
third-party service can impact 3DS functionality or the security of the 3DE, the applicable PCI 3DS requirements will need to be identified and
implemented for that service.

Critical steps in the process include understanding which 3DS functions and system components can be impacted by the service provider and
identifying which PCI 3DS requirements are the responsibility of the service provider(s) and which are the responsibility of the 3DS entity.

It is expected that a 3DS entity will have processes in place to manage risks associated with third-party providers, including:
 Performing due diligence prior to engagement.
 Clear definition of security responsibilities.
 Periodic verification that agreed-upon responsibilities are being met.
 A written agreement to ensure both parties understand and acknowledge their security responsibilities.

While the ultimate responsibility for the security of the 3DE and 3DS Data lies with the 3DS entity, service providers may be required to
demonstrate compliance with the applicable PCI 3DS requirements based on the provided service. The service provider may do so by either:
(a) Undergoing a PCI 3DS assessment and providing evidence to its 3DS entity customers to demonstrate its compliance to applicable PCI
3DS requirements; or
(b) For each of its 3DS entity clients’ assessments, providing the required evidence to demonstrate compliance with the applicable PCI 3DS
requirements.

The evidence provided by service providers should be sufficient to verify that the scope of the service provider’s 3DS assessment covered the
services applicable to the 3DS entity, and that the relevant PCI 3DS requirements were examined and determined to be in place. The specific type
of evidence provided will depend on the how the assessments are managed. For example, if the service provider undergoes its own PCI 3DS
assessment, the service provider’s 3DS Attestation of Compliance (AOC) and/or relevant sections of the service provider’s 3DS Report on
Compliance (redacted to protect any confidential information) could provide some or all of the information. If the service provider does not have a
3DS AOC or Report on Compliance, the evidence provided should encompass the specific requirements being assessed, and be consistent with
the validation methods described for each requirement.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 11
3DS Security Requirements and Assessment Procedures
The security requirements and assessment procedures in this PCI 3DS Core Security Standard are presented in the following format:
 Requirements – The specific security control or objective that a 3DS entity is required to meet.
 Validation Methods – The assessment activities to be performed to determine whether a requirement has been met.
 Implementation Guidance* – Additional information to help entities and assessors understand how a requirement could be met. The
guidance may include examples of controls or methods that— when properly implemented—could meet the intent of a requirement, as
well as best practices that should be considered. This guidance is not intended to preclude other methods that an entity may use to meet
a requirement, nor does it replace or extend the requirement to which it refers.
* The examples and practices in the Implementation Guidance column are not requirements.

Risk-Management Approach to Requirements

To ensure security controls continue to be properly implemented and are appropriate to address applicable security risks, the PCI 3DS Core
Security Standard requires periodic identification and evaluation of evolving risks to 3DS environments. The rigor of certain security requirements
(for example, the timing and frequency of system patching) will depend on the 3DS entity’s risk-management strategy. While this approach
provides the 3DS entity with flexibility to implement security controls based on its assessed risk, it also requires implementation of a robust risk-
management practice as an integral part of the entity’s “business as usual” operational processes.

Where a PCI 3DS requirement does not define a minimum frequency for periodic or recurring activities (for example, audit log reviews), the 3DS
entity may define the frequency as appropriate for its business. The frequency defined by the 3DS entity must be supported by the 3DS entity’s
security policy and risk-management strategy. The 3DS entity should also be able to demonstrate that the frequency it has defined is appropriate
for the activity to be effective and meets the intent of the requirement.

Validating Requirements
The validation methods identified for each requirement describe the expected activities to be performed by the assessor to validate whether the
entity has met the requirement. The intent behind each validation method is described as follows:
 Examine: The assessor critically evaluates data evidence. Common examples include documents (electronic or physical), screenshots,
configuration files, audit logs, and data files.
 Observe: The assessor watches an action or views something in the environment. Examples of observation subjects include personnel
performing a task or process, system components performing a function or responding to input, system configurations/settings,
environmental conditions, and physical controls.
 Interview: The assessor converses with individual personnel. Interview objectives may include confirmation of whether an activity is
performed, descriptions of how an activity is performed, and whether personnel have particular knowledge or understanding.
PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 12
The validation methods are intended to allow the 3DS entity to demonstrate how they have met a requirement. They also provide the 3DS entity
and the assessor with a common understanding of the assessment activities to be performed. The specific items to be examined or observed and
personnel to be interviewed should be appropriate for both the requirement being assessed and each entity’s particular implementation.
When documenting the assessment results, the assessor identifies the validation activities performed and the result of each activity. While it is
expected that an assessor will perform all the validation methods identified for each requirement, it is also possible for an implementation to be
validated using different or additional methods. In such cases, the assessor should document why they used validation methods that differed from
those identified in this document.
The PCI 3DS Reporting Template and Attestation documents (available on the PCI SSC Website) should always be used to document the results
of a PCI 3DS security assessment.

Compensating Controls
Compensating controls may be considered when, due to legitimate technical or documented business constraints, an entity cannot meet a PCI
3DS requirement as stated but has sufficiently mitigated the risk associated with the requirement through implementation of alternative, or
compensating, controls. Refer to Appendix A for details and requirements on the use of compensating controls.

3DS Assessment Process

The PCI 3DS assessment process typically includes the following steps:

1. The 3DS entity completes EMVCo functional testing for ACS, DS, and/or 3DSS and receives a Letter of Approval from EMVCo.
2. Confirm the scope of the PCI 3DS assessment.
3. Perform the PCI 3DS assessment, following the requirements and assessment procedures in this PCI 3DS Core Security Standard.
4. Complete the 3DS assessment report and attestation in accordance with applicable templates, guidance, and instructions.
5. Submit the assessment report and attestation, along with any other requested documentation, to the applicable payment brand(s).
6. If required, perform remediation to address requirements that are not in place, and provides an updated report.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 13
Part 1: 3DS Baseline Security Requirements
Requirement P1-1. Maintain security policies for all personnel
Overview Requirements

P1-1 Security policies define rules and requirements for all personnel to 1.1 Maintain security policies
protect the security and integrity of the entity’s resources and protect 1.2 Evaluate risk
against identified risks.
1.3 Educate personnel
1.4 Screen personnel

Requirements Validation Methods Implementation Guidance

P1-1.1 Maintain Security Policies
P1 1.1.1 An organizational security policy(s)  Examine documented policies A strong security policy, or policies, should set the security tone for the
is established and disseminated to and procedures. entity as a whole and inform personnel what is expected of them. All
all relevant personnel.  Interview personnel. personnel should be aware of the sensitivity of data and their
responsibilities for protecting it. The security policy should be updated as
P1 1.1.2 Security policies are reviewed and
needed in response to changes in the environment, results of risk
updated as needed to reflect
assessments, implementation of new technologies, and changes in
changes to business objectives or
business objectives.
the risk environment.
Personnel should be aware of all policies and policy updates, including
P1 1.1.3 Policy updates are communicated their applicable responsibilities. Methods of communicating policies should
to applicable personnel. include a mechanism for personnel to acknowledge they have received and
P1 1.1.4 The security policy is approved by read the policy or policy update. Personnel acknowledgment may be in
management writing or electronic.

P1 1.1.5 Personnel acknowledge that they  Examine evidence of All security policies and policy updates should be approved by
have read and understood the acknowledgments. management to ensure they are aligned with the entity’s security strategy
security policy, including updates and business objectives. Any exception to the policies should require
 Interview personnel.
to the policy. management sign-off to ensure the appropriate due diligence is done and
approval obtained.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 14
Requirements Validation Methods Implementation Guidance
P1-1.2 Evaluate Risk
P1 1.2.1 A risk-assessment process is  Examine documented policies Risks to 3DS environments should be assessed at least annually and upon
documented. and procedures. significant changes. The risk assessment should identify assets, threats,
 Interview personnel. likelihood, and potential impacts. Risk considerations should include
P1 1.2.2 The documented risk-assessment
responsible for risk- internal and external attacks—e.g., for cybercrime, fraud, or theft—internal
process is performed at least
assessment process. control failures, and malware. Risks should be prioritized and resources
annually and upon significant
allocated to implement controls that reduce the likelihood and/or the
changes.
potential impact of the threat being realized. Considerations should include
regulatory obligations and changes in technology—e.g., deprecation of
encryption algorithms.
Examples of risk-assessment methodologies include but are not limited to
OCTAVE, ISO 27005 and NIST SP 800-30.

P1-1.3 Educate personnel

P1 1.3.1 A security awareness program is  Examine documented policies The security awareness program should result in personnel understanding
implemented that provides and procedures. the security policy and procedures, and their responsibilities for following
awareness to all applicable  Examine security awareness secure processes. All personnel—including full-time, part-time and
personnel about security policy materials. temporary employees, contractors, and consultants—with access to or the
and procedures. ability to impact the security of the 3DE should be required to complete
training. Training should be required upon hire and include periodic
P1 1.3.2 Personnel receive security  Examine records of refresher sessions at appropriate intervals. The frequency of training
awareness training at defined attendance. should be aligned with the entity’s policies for education and security
intervals, as appropriate for their  Interview personnel. awareness, and commensurate with personnel job function.
job function.

P1 1.3.3 Personnel are aware of the  Interview personnel.

security policy and responsibilities
as applicable to their job function.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 15
Requirements Validation Methods Implementation Guidance
P1-1.4 Screen personnel
P1 1.4.1 Personnel are screened  Examine documented policies The intent of screening personnel is to reduce the risk of fraud and
(background checks) prior to being and procedures. unscrupulous behavior from an internal resource. Role descriptions should
granted access to the 3DE.  Interview personnel. describe the level of security or access required for the role, and the level
of screening should be appropriate for the particular position. Positions
P1 1.4.2 The screening process includes  Examine results of screening requiring greater responsibility or that have administrative access to critical
established criteria and a decision process. data or systems may warrant more detailed background checks than
process for background check
positions with less responsibility and access. The policy should also cover
results.
internal transfers where personnel in lower-risk positions, and who have not
already undergone a detailed background check, are promoted or
transferred to positions of greater responsibility or access. The specific
roles to be screened will depend on the entity’s personnel and security
policies. For example, an entity may have a policy that requires detailed
screening for all personnel or defines different levels of screening for
different job functions.
Examples of criteria that may be appropriate include employment history,
criminal records, credit history, and reference checks.

Overview Requirements

P1-2 Network connectivity controls provide secure pathways to 2.1 Protect 3DS systems from untrusted systems and
the entity’s systems while protecting those systems from networks
unauthorized access and network-based threats. 2.2 Protect 3DS systems from network threats

Requirements Validation Methods Implementation Guidance

P1-2.1 Protect 3DS systems from untrusted systems and networks
P1 2.1.1 A security policy(s) and  Examine documented policies Policies for the protection of 3DS environment boundaries should define
procedures for protection of 3DS and procedures. the purpose, scope, roles, and responsibilities of defined boundaries to
environment boundaries are  Interview personnel. protect system components from untrusted networks. The policy should be
maintained and implemented. kept up to date, approved by management, and communicated to
applicable personnel.

P1 2.1.2 Up-to-date network and data flow  Examine network and data Network and data flow information—for example, diagrams or network
information is maintained for all flow information. mapping tools—accurately document how the entity’s 3DS networks are
3DS communication paths.  Observe methods used to configured, the identity and location of all 3DS systems, how 3DS systems
maintain up-to-date network are connected to each other and to other systems, and all communication
and data flow information. paths with trusted and untrusted networks.

P1 2.1.3 Access between trusted and  Examine documentation Documentation illustrating authorized communications, both internal and
untrusted networks, systems, and describing controls. external—including source and destination systems, interface connections,
applications is limited via physical  Observe physical and/or security controls for those connections, and the type of data being sent—
and/or logical controls. logical controls. will assist in meeting these requirements.
Protection mechanisms may include technologies such as network
P1 2.1.4 Traffic to/from 3DS systems is  Examine documentation
gateways, routers, firewalls, encryption, API controls, and virtualization
restricted to only that which is identifying necessary traffic.
techniques. Controls may be a combination of software and hardware—for
necessary, with all other traffic  Observe configurations of example, use of packet-filtering capability based on header information,
specifically denied. ingress and egress controls. advanced filtering/inspection tools, and implementation of dedicated
physical network devices or channels to separate network segments.
Many security devices and software provide rule sets and settings that can
validate the existence and methodologies used to secure network
connectivity.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 17
Requirements Validation Methods Implementation Guidance
P1 2.1.5 Network connectivity controls are  Examine documented Reviewing device configurations allows the entity to identify and remove
monitored and/or periodically methods for monitoring and/or any unneeded, outdated, or incorrect rules and confirm that only authorized
reviewed to confirm periodically reviewing network connections, ports, protocols, services, and APIs are allowed as defined in
configurations are effective. connectivity controls. the documented business justifications. All other services, protocols, and
 Observe implemented ports should remain disabled or be removed through periodic reviews.
methods and processes. Review processes may include real-time monitoring and analysis, periodic
maintenance cycles to ensure the controls are accurate and working as
intended, and periodic reviews of network traffic connectivity across ports,
protocols, and services. For guidance on services, protocols, or ports
considered to be insecure, refer to industry standards and guidance—e.g.,
NIST, ENISA, OWASP, etc.

P1-2.2 Protect 3DS systems from network threats

P1 2.2.1 Controls are implemented to detect  Examine documented Controls should be implemented at the perimeter and critical systems
and/or block known and unknown controls/configuration points, and include consideration of both network-based and application-
network attacks. standards. based attack vectors. Methods of detection may include signature-based,
 Observe implemented behavioral, and other mechanisms that analyze traffic flows. Examples of
controls. tools include IDS/IPS, host firewalls, and real-time traffic analysis tools. All
mechanisms—such as detection engines, baselines, and signatures—
should be configured, maintained, and updated per vendor instructions to
ensure optimal protection.

P1 2.2.2 Suspicious traffic is blocked or  Examine documented If suspicious traffic is not automatically blocked, an alert should be
generates an alert that is procedures. generated that is actively monitored and immediately investigated.
investigated and responded to.  Observe implemented Where suspicious traffic is automatically blocked, a record of the traffic
controls and processes. should also be generated and investigated to determine whether action is
needed to prevent further attack.

Overview Requirements

P1-3 Security risks and events can occur at any time during the 3.1 Secure application development
lifetime of a system or application. Integrating secure 3.2 Configuration standards
processes throughout the lifecycle provides assurance that
system integrity is maintained at all times. 3.3 Change management

Requirements Validation Methods Implementation Guidance

P1-3.1 Secure application development
P1 3.1.1 A security policy(s) and  Examine documented policies Where software is developed by the 3DS entity or bespoke or custom
procedures for secure and procedures. software is developed by a third party for the 3DS entity, the software
management of the Software  Interview personnel. development process should employ secure coding practices to address
Development Life Cycle (SDLC) is common vulnerabilities applicable to the particular technology. The entity
maintained and implemented. should remain up to date with vulnerability trends and update its secure
coding practices and developer training as needed to address new threats.
P1 3.1.2 Personnel involved in software  Examine evidence of training. Examples of current best practices include OWASP, SANS CWE Top 25,
development are trained in secure  Interview developer and CERT Secure Coding.
software development practices. personnel.
Application developers should be properly trained to identify and resolve
P1 3.1.3 Software development procedures  Examine documented issues related to common coding vulnerabilities. Having staff
include processes to address procedures. knowledgeable of secure software development practices minimizes the
common coding vulnerabilities.  Interview developer number of security vulnerabilities accidentally introduced through poor
personnel. coding practices. Training for developers may be provided in-house or by
third parties and should be appropriate for the technology used.
P1 3.1.4 Software security testing is  Examine documented
Common methods for software security testing include threat modeling,
conducted during the software software security testing
development lifecycle using code reviews, fuzz testing, and penetration testing. Software security
procedures.
testing should be performed by someone other than the developer of the
methodologies documented in the  Examine results of software code to allow for an independent, objective review. Automated tools or
SDLC processes. security testing. processes may also be used in lieu of manual reviews, but keep in mind
 Interview personnel. that it may be difficult or even impossible for an automated tool to identify
some coding errors or other security issues.
(Continued on following page)

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 19
Requirements Validation Methods Implementation Guidance
P1 3.1.5 The software security testing  Examine documented Correcting identified software defects before the software is deployed
process identifies defects and software security testing prevents it from exposing the environments to potential exploit. Requiring a
security vulnerabilities. procedures. formal review and sign-off by management should verify that the software
 Examine results of software is approved and has been developed in accordance with policies and
P1 3.1.6 Identified software defects and
security testing. procedures.
security vulnerabilities are
addressed prior to release.  Interview personnel.
P1 3.1.7 Results of software security testing
are signed off by management
prior to software release.

P1-3.2 Configuration standards

P1 3.2.1 A security policy(s) and  Examine documented policies The policy document should be able to explain the purpose, scope, roles
procedures for system build and and procedures. and responsibilities, methods of access for different account types,
configuration management are  Interview personnel. configuration management, monitoring methodology, and controls to
maintained and implemented. address known risks.

P1 3.2.2 An up-to-date inventory of all 3DS  Examine system inventory. Maintaining a current inventory of all system components enables an
system components is maintained.  Interview personnel. organization to accurately and efficiently apply security controls to protect
the assets. The inventory should be periodically confirmed by either
manual or automated process—for example by correlation with the results
of vulnerability scans or penetration testing—to confirm it is up to date.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 20
Requirements Validation Methods Implementation Guidance
P1 3.2.3 Configuration standards are  Examine system configuration System configuration standards must be kept up to date to ensure that
defined and implemented for all standards and build newly identified weaknesses are corrected prior to a system being
3DS system types. procedures for all system deployed in the environment.
component types.
P1 3.2.4 Configuration standards address System configuration standards and related processes should specifically
all known security vulnerabilities  Examine system address security settings and parameters that have known security
and are based on industry- configurations. implications for each type of system in use. Examples of industry-accepted
accepted system hardening  Interview personnel. configuration standards include, but are not limited to: Center for Internet
standards. Security (CIS), International Organization for Standardization (ISO),
SysAdmin Audit Network Security (SANS) Institute, and National Institute
P1 3.2.5 Configuration standards and build  Examine system configuration of Standards Technology (NIST).
procedures include: standards and build
procedures for all system The implemented controls should provide assurance that all 3DS systems
 Changing all vendor-supplied
component types. have known secure configurations.
default accounts and system
settings.  Examine system
 Removing or disabling all configurations.
unnecessary system or  Interview personnel.
application functionality.
 Preventing functions that
require different security levels
from co-existing on the same
system component.

P1-3.3 Change management

P1 3.3.1 Change-control procedures are  Examine documented Defined change-control procedures should be followed for any change that
defined and implemented for all change-control procedures. impacts a 3DS system or the 3DE. The impact of the change should be
changes to system components,  Examine records of changes documented so that all affected parties can plan appropriately for any
including “emergency changes.” and compare to system processing changes. Changes should be authorized by appropriate parties,
configurations. as defined by the change-management policy, to verify the change is
P1 3.3.2 All changes are authorized and the
legitimate.
security impact understood prior to  Interview personnel.
implementing the change. Thorough testing should be performed to verify that the security of the
environment is not reduced by implementing a change; and there should
P1 3.3.3 All changes are tested in a non- be documented back-out procedures in case the change fails or adversely
production environment. affects the security of any system component.
P1 3.3.4 Rollback procedures are prepared
for all changes.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 21
Requirements Validation Methods Implementation Guidance
P1 3.3.5 Unauthorized changes to system  Examine documentation of The implemented process should be able to either prevent or detect and
or application configurations are controls and/or processes. address the unauthorized addition, removal, or modification of system
prevented and/or detected and  Observe implemented critical files such as configuration file contents, operating system programs,
addressed. controls. and application executables. If the implemented solution relies on
detection, processes should be in place to ensure that unauthorized
 Interview personnel. changes are detected and addressed as soon as possible. Where
unauthorized change attempts are automatically blocked, a record of the
attempted change should also be generated and investigated to determine
whether action is needed to prevent further attempts.
The controls could include change-detection solutions, such as file-integrity
monitoring, or a frequent re-load of a trusted build to restore the system
component to a known secure state.

Overview Requirements

P1-4 New vulnerabilities are continually being discovered and can enter 4.1 Protect against malicious software
the network from both internal and external sources. An ongoing 4.2 Address vulnerabilities and security weaknesses
cycle of testing and remediation helps ensure that security controls
continue to be effective in a changing environment.

Requirements Validation Methods Implementation Guidance

P1-4.1 Protect against malicious software
P1 4.1.1 A security policy(s) and  Examine documented policies Controls should prevent the introduction and execution of malicious
procedures for protecting systems and procedures. software (malware) on 3DS systems. A combination of methods, tools, and
against malware are maintained  Interview personnel. programs may be used—for example, anti-malware software, application
and implemented. whitelisting, host-based and network-based intrusion-prevention tools, and
system instrumentation. A combination of real-time protection and periodic
P1 4.1.2 Controls to prevent and/or detect  Examine documented scans should be considered.
and remove malicious software are controls/configurations.
implemented, active, and The implemented controls should be kept current—e.g., updated
 Observe implemented
maintained. signatures, baselines, etc.—as applicable for the technology. Anti-malware
controls and processes.
controls should not be disabled unless specifically authorized by
 Examine evidence of malware management on a case-by-case basis for a limited time period.
prevention and/or detection
and removal.
 Interview personnel.

P1-4.2 Address vulnerabilities and security weaknesses

P1 4.2.1 A security policy(s) and  Examine documented policies Policies and procedures define the methods employed to identify and
procedures for identifying, ranking, and procedures. remediate vulnerabilities that could affect 3DS systems, and include;
and protecting against  Interview personnel. monitoring vulnerability lists, performing vulnerability scans and penetration
vulnerabilities are maintained and tests, and establishing bug bounty programs. Reputable outside sources
implemented. should be used for security and vulnerability information.

P1 4.2.2 Vulnerability scans, both internal  Examine vulnerability Vulnerability scans and all required remediation should be completed as
and external, are performed at scanning reports frequently as needed to ensure vulnerabilities are addressed in a timely
least quarterly to identify and  Interview personnel. manner. Rescans should be performed to verify vulnerabilities have been
address vulnerabilities. addressed. In addition to a regular scanning process, vulnerability scans
should also be performed after any significant change to the environment.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 23
Requirements Validation Methods Implementation Guidance
P1 4.2.3 Vulnerability scans are performed  Examine vulnerability Internal vulnerability scans can be performed by qualified, internal staff or
by qualified personnel: scanning reports. outsourced to a qualified third party. For scans managed by the entity, the
 External scans are performed  Interview personnel. entity should ensure that scanning engines and vulnerability fingerprints are
by a PCI SSC Approved up to date and the scanning engine configured in accordance with vendor
Scanning Vendor (ASV). guidance documentation.

 Internal scans are performed Internal personnel should have sufficient knowledge to review and
by qualified personnel. understand the scan results, and determine appropriate remediation.
Internal personnel who interact with the ASV should also be knowledgeable
in the network architecture and implemented security controls in order to
provide the ASV with information needed to complete the scan.

P1 4.2.4 Identified vulnerabilities are ranked  Examine documented Vulnerabilities should be ranked and prioritized in accordance with an
to determine the criticality of the procedures for ranking industry-accepted methodology or organizational risk-management
vulnerability. vulnerabilities. strategy.
 Interview personnel.

P1 4.2.5 Penetration tests are performed at  Examine penetration test Penetration tests should be performed at regular intervals and after
least annually. reports. significant changes to the environment. The penetration-testing
 Interview personnel. methodology should be based on industry-accepted approaches and
incorporate both application-layer and network-layer testing. The scope of
testing should cover the 3DE perimeter and critical systems, and include
testing from both inside and outside the network. Testing should also be
performed to verify all segmentation controls are operational and effective,
and that out-of-scope systems and networks do not have access to the
3DE. The specific methodology, depth, and frequency of the testing should
be based on the entity’s risk-assessment strategy, and be updated as
needed to consider new threats and vulnerabilities.

P1 4.2.6 Penetration tests are performed by  Examine penetration test Tests should only be performed by qualified personnel who can
qualified personnel. reports. demonstrate knowledge and experience, and are organizationally
 Interview personnel. independent of the environment being tested.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 24
Requirements Validation Methods Implementation Guidance
P1 4.2.7 Vulnerabilities and penetration  Examine results of penetration Security patches and fixes should be implemented based on risk ranking.
testing findings considered as high tests and vulnerability Where high-risk vulnerabilities cannot be addressed within one month, a
risk are addressed within one scanning reports. formal exception process should be followed, including approval by
month. All other vulnerabilities and  Examine evidence of personnel with appropriate responsibility and accountability. (See
identified security issues are remediation to address Requirements P2-2.1.2 and P2-2.1.3.)
addressed in a timely manner. vulnerabilities and security Once remediation activities have been performed—for example,
issues. implementing a patch or updating a configuration file to address a
vulnerability or security flaw—rescans and penetration tests should be
 Interview personnel.
performed as necessary to verify the remediation is effective and the
identified vulnerability or security issue has been mitigated.
A record of remediation activities should be maintained—for example, via
change-control records, configuration file updates, and audit logs. All
updates and patches should be managed in accordance with change-
control processes. Where applicable, changes to system configurations
should be reflected in the configuration build standards.

Overview Requirements

P1-5 Strong access controls protect systems and data from 5.1 Access management
unauthorized access and can limit the likelihood of a 5.2 Account management
compromised system being used to gain access to other systems
and networks. 5.3 Authentication

Requirements Validation Methods Implementation Guidance

P1-5.1 Access management
P1 5.1.1 A security policy(s) and  Examine documented policies Policies and procedures should include details of processes for role
procedures for assigning access and procedures. assignments, oversight processes, business justifications, and user and
are maintained and implemented.  Interview personnel. group privilege controls.

P1 5.1.2 Roles and responsibilities are  Examine defined roles and Determining who has access to what, for how long, and what level of
defined for groups and accounts responsibilities. access they have should be based on established roles and
with access to 3DS systems.  Interview personnel. responsibilities. This includes the processes used to maintain, monitor, and
approve administrative and user access to 3DS systems and data.

P1 5.1.3 Least privileges are assigned  Observe assigned access Access to 3DS systems and data should be restricted based on business
based on individual job function privileges. need, while also accounting for the sensitivity of the data being transmitted
and periodically reviewed.  Examine evidence that access between the 3DS systems. Access privileges should be reviewed by
privileges are periodically responsible personnel as defined by the 3DS entity. The frequency of
reviewed. reviews should be defined in accordance with the entity’s defined policies
and be appropriate for the level of privilege assigned.
 Interview personnel.

P1-5.2 Account management

P1 5.2.1 A security policy(s) and  Examine documented policies Established processes and oversight includes approval process for
procedures for managing accounts and procedures. provisioning, monitoring, changing, and revocation of accounts with the
are maintained and implemented.  Interview personnel. ability to access a 3DS system.

P1 5.2.2 Individuals are assigned a unique  Examine documented Assigned unique IDs should allow the organization to maintain individual
account ID. procedures. responsibility for actions and an effective audit trail per employee.
 Observe account settings.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 26
Requirements Validation Methods Implementation Guidance
P1 5.2.3 Controls are implemented to  Examine documented Implemented controls should protect the confidentiality and integrity of
protect the confidentiality and procedures. accounts for both local and remote users. The controls should include
integrity of accounts and  Observe implemented ensuring that account and credential information is securely transmitted
credentials. controls. and stored—for example, using strong cryptography—at all times.

P1 5.2.4 Controls are implemented to  Examine documented Processes for prevent misuse of accounts should include, at a minimum,
prevent misuse of accounts. procedures. the use of account lockouts, lockout durations, session timeouts, and
 Observe implemented reactivation processes. Inactive user accounts should be removed or
controls. disabled within a timely manner. All processes should align with the entity’s
security policies and procedures.

P1 5.2.5 Access for third parties is  Examine documented Configuration and connection requirements should be defined and
identified, controlled, and procedures. implemented for all access by third-party personnel—for example, ensuring
monitored.  Observe implemented accounts are enabled only during the time needed and disabled when not
controls. in use, and monitoring account activity when in use.

P1-5.3 Authentication
P1 5.3.1 All access to 3DS systems  Examine documented Authentication may be consist of one or more of:
requires strong authentication procedures.  Something you know, such as a password or passphrase
prior to access being granted.  Observe implemented  Something you have, such as a token device or smart card
controls.
 Something you are, such as a biometric
Where passwords are used, documented requirements should include
considerations for entropy (strength/complexity), password history and
reuse, reset processes, and other best practices for secure password use.
Passwords should meet a minimum level of strength, as defined by the
entity’s security policy, that provides reasonable assurance they are not
guessable and would withstand a brute-force attack.

Overview Requirements

P1-6 Individuals with physical access to systems or media could potentially bypass 6.1 Restrict physical access
logical access controls and gain access to sensitive data. Strong physical 6.2 Secure media
access controls also protect against the unauthorized addition, modification,
removal, or damage of systems and data.

Requirements Validation Methods Implementation Guidance

P1-6.1 Restrict physical access
P1 6.1.1 A security policy(s) and procedures  Examine documented policies The entity should define the physical access controls required to prevent
for securing physical access to and procedures. 3DS systems being physically accessed by unauthorized persons. The
3DS systems is maintained and  Interview personnel. controls should cover all physical access points and include procedures for
implemented. managing onsite employees and third parties. Specific procedures should
be defined for managing visitors, including a visible means for identification
P1 6.1.2 Facility entry controls are in place  Observe physical access and escorts by authorized personnel.
to limit and monitor physical controls.
access to systems in the 3DE. Physical access and monitoring controls should include use of video
cameras and/or access-control mechanisms. Data from video cameras
P1 6.1.3 Physical access for personnel to  Examine assigned access and/or access-control mechanisms should be logged to provide an audit
3DE is authorized and based on permissions. trail of all physical access to the 3DE. Access logs should be retained in
individual job function.  Interview personnel. accordance with the entity’s audit log policy. (Refer to Requirement P1–
 Observe personnel access 7.2.) Monitoring and periodic reviews of physical access controls and audit
procedures. logs should be performed to allow early identification of incorrect controls
and for timely response to suspicious activities. Personnel should be
P1 6.1.4 Personnel access is revoked  Examine documented trained to follow procedures at all times.
immediately upon termination, and procedures.
all physical access mechanisms, All suspicious activity should be managed per incident security procedures.
 Examine evidence of access (Refer to Requirement P1-7.1.)
such as keys, access cards, etc., revocation and return of
are returned or disabled. physical access mechanisms.
 Interview personnel.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 28
Requirements Validation Methods Implementation Guidance
P1-6.2 Secure media
P1 6.2.1 Strict control is maintained over the  Observe implemented Controls and processes should cover secure storage, transport, and
storage and accessibility of media. controls. disposal of all storage media used in the 3DE. Procedures and technical
 Interview personnel. controls should provide assurance that media cannot be removed, stolen,
or copied by unauthorized persons. The specific controls and level of rigor
required to protect media should be appropriate for the sensitivity of the
data stored on the media.

P1-6 An effective incident response plan allows an entity to respond to 7.1 Incident response plan
potential security issues quickly and effectively, and minimize the 7.2 Audit logs
potential impact of a security incident or breach.

Requirements Validation Methods Implementation Guidance

P1-7.1 Incident response plan
P1 7.1.1 A security policy(s) and  Examine documented policies The policy should define plans, procedures, and technologies to detect,
procedures for managing and and procedures. analyze, and promptly respond to security incidents. Defined procedures
responding to security incidents is  Interview personnel. should include response activities, escalation, and notification, and cover
maintained and implemented. all assets and processes that could impact 3DS operations or data.
Procedures should be updated in alignment with operational/business
changes and the organization's risk strategy.

P1 7.1.2 An incident response plan is in  Examine documented incident The incident response plan should be comprehensive and include
place that includes: response plans and coverage of all 3DS systems.
 Roles and responsibilities procedures.
Communication and contact strategies should include notification of the
 Communication and contact  Interview personnel. payment brands, at a minimum.
strategies
Incident response personnel/teams should be trained and knowledgeable
 Specific incident response in incident response procedures, and be available to respond immediately
procedures to an incident.
 Business recovery and
continuity procedures
 Data back-up processes
 Analysis of legal requirements
for reporting compromises
 Coverage and responses of all
critical system components
 Consideration of payment
brands’ response requirements

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 30
Requirements Validation Methods Implementation Guidance
P1 7.1.3 The plan is reviewed and tested at  Examine documented The incident response plan should be periodically reviewed, tested, and
least annually. procedures. updated to incorporate lessons learned. Relevant staff should be included
 Examine evidence of reviews in the testing and be briefed on the post-test review. Testing should include
and testing. validation that system, audit, and monitoring logs are available and contain
all needed data.
 Interview personnel.

P1-7.2 Audit logs

P1 7.2.1 A security policy(s) and  Examine documented policies The policy should cover requirements for the generation, collection,
procedures for generating and and procedures. management and retention of audit logs for all system components in the
managing audit logs is maintained  Interview personnel. 3DS environment.
and implemented.

P1 7.2.2 Audit logs are implemented to:  Examine system Recording all personnel access, both physical and logical, to 3DS systems
 Link all access to 3DS systems configurations. should help the entity identify any misuse of accounts, and ensure that
to an individual user.  Observe access attempts. each individual is accountable for their actions.

 Record security events.  Examine audit log files. The determination of “security event” will vary for each organization and
may include consideration for the type of technology, location, and function
of the system. Logging of security events should include notifications or
alerts related to suspicious or anomalous activities—for example, as
defined in Requirements P1-2.2.2 and P1-3.3.5. The level of detail logged
should be sufficient to identify who, what, where, when, and how an event
occurred in the 3DS environment. This requirement does not encompass
3DS transaction logs.

P1 7.2.3 Time synchronization is  Examine system Designated central time server(s) should be defined to receive time signals
implemented on 3DS systems to configurations. from trusted external sources, based on International Atomic Time or UTC.
ensure system clocks are Central time server(s) should peer with one another to keep accurate time.
synchronized and have the correct Systems receive time only from designated central time server(s).
and consistent time.
Time-synchronization technology should be kept current and time data
protected from unauthorized modification.

P1 7.2.4 Logs and security events are  Examine evidence of reviews Real-time monitoring and/or periodic reviews should be in place for all
monitored and/or periodically of logs and security events. security events, critical system logs, and security system logs—for
reviewed for all 3DS systems to  Interview personnel. example, firewalls, IDS/IPS, authentication servers, e-commerce
identify anomalies or suspicious redirection servers, etc. The frequency of reviews should be aligned with
activity. the associated risk.
The use of log harvesting, parsing, and alerting tools can help facilitate the
process by identifying log events that need to be reviewed.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 31
Requirements Validation Methods Implementation Guidance
P1 7.2.5 Audit logs are secured so they  Examine Only individuals who have a job-related need should be able to view audit
cannot be altered. controls/configurations. log files. Audit logs should be promptly backed up to a centralized log
 Observe attempts to modify server or media that is difficult to alter. Physical and logical access controls
audit logs should be in place to prevent unauthorized modifications to audit logs. File-
integrity monitoring or change-detection software can be implemented to
ensure that any changes to saved log data generates an alert.

P1 7.2.6 Audit and monitoring logs are  Examine audit log files. Log-retention policies should include storage and retrieval procedures. If
retained for least one year, with a  Interview personnel. stored in off-line locations, procedures should include assurance that log
minimum of three months data can be retrieved in a timely manner. The logs to be retained include at
immediately available for analysis. least those defined in Requirement P1-7.2.2.

Overview Requirements

P2-1 Scoping involves the identification of the facilities, people, processes, 1.1 Scoping
and technologies that interact with or could impact the security of 3DS
data or systems. Once scope is properly identified, the appropriate
security controls can be applied.

Requirements Validation Methods Implementation Guidance

P2-1.1 Scoping
P2 1.1.1 All networks and system  Examine documented results A scope verification exercise includes identifying all locations and flows of
components in-scope for these of scope reviews. 3DS data, as well as the systems performing 3DS functions (ACS, DS,
PCI 3DS security requirements are  Interview personnel. and/or 3DSS) and any systems that are connected to or could impact the
identified. 3DE. Network mapping tools, data flow diagrams, and process
documentation can often assist with this process. The scoping process
P2 1.1.2 All out-of-scope networks are  Examine documented results should also include consideration of backup/recovery sites and fail-over
identified with justification for being of scope reviews. systems.
out of scope and descriptions of  Examine data flow and
segmentation controls The scoping exercise should also include identifying personnel with access
network diagrams.
implemented. to 3DS data, as well as the physical locations where 3DS systems are
 Observe segmentation housed.
controls.
Validation of scope should be performed as frequently as needed to ensure
P2 1.1.3 All connected entities with access  Examine documentation. the scope is known and scope documentation remains accurate and up to
to the 3DS environments are  Interview personnel. date. The results of scoping exercises should help to confirm that security
identified. controls are applied to all applicable systems, and that all connections to
third-parties—for example, service providers and business partners—are
identified and properly secured.

Overview Requirements

P2-2 A security governance program provides oversight and assurance that 2.1 Security governance
an entity’s information security strategies are aligned with its business 2.2 Manage risk
objectives and adequately address risks to the entity’s data and
systems. 2.3 Business as usual (BAU)
2.4 Manage third-party relationships

Requirements Validation Methods Implementation Guidance

P2-2.1 Security governance
P2 2.1.1 Security objectives are aligned  Examine documentation. The security objectives should be defined as part of an overarching
with business objectives.  Interview personnel. security strategy that supports and facilitates business objectives. The
security strategy should provide the foundation for the entity’s security
policies and procedures and provide a benchmark against which the health
of security controls is monitored and measured.

P2 2.1.2 Responsibilities and accountability  Examine documentation. The assignment of specific roles and responsibilities should include
for meeting security objectives are  Interview personnel. monitoring and measurement of performance to ensure security objectives
formally assigned, including are met. Roles and responsibilities may be assigned to a single owner or
responsibilities for the security of multiple owners for different aspects.
3DS processes. Ownership should be assigned to individuals with the authority to make
P2 2.1.3 Responsibility for identifying and  Examine documentation. risk-based decisions and upon whom accountability rests for the specific
addressing evolving risks is function. Duties should be formally defined, and owners should be able to
 Interview personnel. demonstrate an understanding of their responsibilities and accountability.
assigned.

P2-2.2 Manage risk

P2 2.2.1 A formal risk-management  Examine documentation. The risk-management strategy defines a structured approach for
strategy is defined.  Interview personnel. identifying, evaluating, managing, and monitoring risk. The strategy should
include requirements for regularly reviewing and updating the entity’s risk-
assessment processes as well as methods to monitor the effectiveness of
risk-mitigation controls.

P2 2.2.2 The risk-management strategy is  Examine documentation. The risk-management strategy should be approved by personnel with
approved by authorized personnel  Interview personnel. appropriate responsibly and accountability. (See Requirements P2-2.1.2
and updated as needed to address and P2-2.1.3.)
changing risk environment.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 34
Requirements Validation Methods Implementation Guidance
P2-2.3 Business as usual (BAU)
P2 2.3.1 Review and/or monitoring is  Examine evidence of reviews Periodic reviews and/or ongoing monitoring of personnel and activities
performed periodically to confirm and/or ongoing monitoring. should ensure security is included as part of normal business operations
personnel are following security  Interview personnel. on an ongoing basis. Reviews should be performed by responsible
policies and procedures. personnel as defined by the entity. The frequency of reviews should be
defined in accordance with the entity’s risk assessments and be
appropriate for the particular job function.

P2 2.3.2 Processes to detect and respond  Examine documented The entity should be able to detect any failures in security controls and
to security control failures are processes. respond to them in a timely manner. Processes for responding to security
defined and implemented.  Observe implemented control failures should include:
processes.  Restoring the security control
 Interview personnel.  Identifying the cause of failure
 Identifying and addressing any security issues that arose during the
failure of the security control
 Implementing mitigation (such as process or technical controls) to
prevent the cause of the failure recurring
 Resuming monitoring of the security control

P2-2.4 Manage third-party relationships

P2 2.4.1 Policies and procedures for  Examine documented Policies and procedures for managing third-party relationships should
managing third-party relationships policies/procedures. consider the risk that each relationship represents, as well as how third-
are maintained and implemented.  Interview personnel. party performance and behavior will be monitored. The policy should be
kept up to date, approved by management, and communicated to
applicable personnel.

P2 2.4.2 Due diligence is performed prior to  Examine documented Due-diligence processes should include thorough vetting and a risk
any engagement with a third party. procedures. analysis prior to establishing a formal relationship with the third party.
 Examine results of due Specific due-diligence processes and goals will vary for each entity and
diligence efforts should provide sufficient assurance that the third party can meet the
entity’s security and operational needs.
 Interview personnel.

P2 2.4.3 Security responsibilities are clearly  Examine documentation The specific approach for defining security responsibilities will depend on
defined for each third-party  Interview personnel. the type of service as well as the particular agreement between the entity
engagement. and third party. The entity should have a clear understanding of the
security responsibilities to be met by the third party and those to be met by
the entity.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 35
Requirements Validation Methods Implementation Guidance
P2 2.4.4 The 3DS entity periodically verifies  Examine results of periodic The specific type of evidence provided by the third party will depend on the
that the agreed-upon verification. agreement in place between the two parties. The evidence should provide
responsibilities are being met.  Interview personnel. assurance that the agreed-upon responsibilities are being met on a
continual basis. The frequency of verification should be aligned with the
entity’s risk analysis of the service being provided.

P2 2.4.5 Written agreements are  Examine documentation. Agreements should promote a consistent level of understanding between
maintained.  Interview personnel. parties about their applicable responsibilities, and be acknowledged by
each party. The acknowledgement evidences each party’s commitment to
maintaining proper security in regard to the 3DS services.

Overview Requirements

P2-3 To maintain the security of 3DS environments, controls need 3.1 Protect boundaries
to be designed and implemented to protect the confidentiality, 3.2 Protect baseline configurations
integrity, and availability of 3DS technologies, processes, and
data. 3.3 Protect applications and application interfaces
3.4 Secure web configurations
3.5 Maintain availability of 3DS operations

Requirements Validation Methods Implementation Guidance

P2-3.1 Protect boundaries
P2 3.1.1 Traffic to and from ACS and DS is  Examine log files. The only permitted traffic should be for the purposes of 3DS transactions,
restricted to only that which is  Observe implemented or to support a 3DS function, or support the 3DS system component—for
relevant to the 3DS functions. controls. example, for security or management purposes. Systems within the 3DE
should be limited to those necessary for performing or supporting 3DS
P2 3.1.2 Traffic to and from ACS and DS is
functions.
permitted only via approved
interfaces. All types of interfaces should be identified, including physical, logical, and
virtual.

P2-3.2 Protect baseline configurations

P2 3.2.1 Controls are implemented to  Examine log files. Examples of the types of files requiring protection include baseline
protect the confidentiality and  Observe implemented configuration files, system build data, system images, and build
integrity of system configurations controls. procedures. The controls should protect both integrity and confidentiality of
and documentation that define such data, to prevent an attacker from changing the secure configuration of
security settings. a 3DS system component, installing their own configuration, or using the
information to identify security gaps they can then exploit.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 37
Requirements Validation Methods Implementation Guidance
P2-3.3 Protect applications and application interfaces
P2 3.3.1 Applications and programs are  Examine log files. Ensuring the integrity of applications and programs in production requires
protected from unauthorized  Observe implemented more than an effective change-control process. A combination of strict
changes once in a production controls. access controls, monitoring, and programmatic controls should be
state. considered. Examples of additional mechanisms include software
authentication codes, digitally signed modules, or execution within an SCD.
The use of a protection technique is only effective if the system confirms
the results (for example, is the digital signature valid?) and acts on the
results.

P2 3.3.2 The mechanisms to protect  Observe implemented Protection mechanisms should be kept up to date and monitored to ensure
applications and programs from controls for monitoring and they are working as intended and continue to be effective. Cryptographic
unauthorized changes are maintaining protection techniques used for API code protection may require updating as
monitored and maintained to mechanisms computation capabilities and cryptanalysis improvements evolve.
confirm effectiveness.  Interview personnel.

P2 3.3.3 All APIs that interface with the  Examine network and data- All exposed APIs need to be periodically reviewed and tested to ensure
3DS environment are identified, flow diagrams that they are functioning as intended. Use of industry best practices and
defined, and tested to verify they  Observe implemented guidance is recommended—for example, the OWASP REST
perform as expected. controls. (REpresentational State Transfer) Security Cheat Sheet provides best
practices for REST-based services.
P2 3.3.4 Controls are implemented to  Examine results of testing
protect APIs exposed to untrusted
 Interview personnel.
networks.

P2-3.4 Secure web configurations

P2 3.4.1 Only those HTTP request methods  Examine log files. All functionality not explicitly required for system operation should be
required for system operation are  Observe implemented disabled or blocked; and configurations should be designed to prevent
accepted. All unused methods are controls. common application attack scenarios such as XSS, Clickjacking, and
explicitly blocked. injection attacks. Applications should be configured to restrict content and
 Interview personnel. functionality from external sources to only that which is necessary for
P2 3.4.2 The use of HTTPS is enforced  Examine log files. business purposes. If functionality or content from trusted external
across all application sources—for example, third-party websites—is necessary for business
 Observe implemented purposes, then those sources and the methods in which they are permitted
pages/resources and all controls.
communications are prevented to provide such content (e.g., as iframes, direct posts, etc.) should be
from being sent over insecure  Interview personnel. explicitly authorized, and all other sources and methods blocked.
channels (e.g., HTTP).

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 38
Requirements Validation Methods Implementation Guidance
P2 3.4.3 Applications (or the underlying  Examine documented (See previous page)
systems) are configured to reject controls.
content provided by external  Observe implemented
sources by default. Exceptions are controls.
explicitly authorized.
 Interview personnel.

P2 3.4.4 Applications are configured to  Examine documented Similarly, content provided by the 3DS provider should be prevented (to the
prevent content from being controls. extent possible) from being embedded in the sites of untrusted third
embedded into untrusted third-  Observe implemented parties. Otherwise, those parties might use the content of the 3DS entity to
party sites/applications. controls. impersonate the 3DS entity in an attempt to hijack 3DS transactions and/or
Exceptions are explicitly commit fraud.
authorized.  Interview personnel.

P2 3.4.5 Security features native to the  Examine documented Native security functions are available in most modern development
development framework and/or controls. platforms and frameworks, and are effective at protecting against common
application platform are enabled,  Observe implemented client-side attacks without requiring additional security functionality to be
where feasible, to protect against controls. written into the application code. Methods to restrict such content and
common client-side attacks (such functionality include the use of Content Security Policy (CSP) directives
as XSS, Injection, etc.).  Interview personnel. and HTTP Strict Transport Security (HSTS). Other security features native
to the development framework that should be considered include
automated compile-time security checks that are performed as part of the
application build process.
Where native security controls such as those described above are not
used, 3DS entities should document the controls that have been
implemented to protect applications and systems from common client-side
attacks (such as XSS, XSRF, Injection attacks, etc.) and provide
justification for why native features were not used.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 39
Requirements Validation Methods Implementation Guidance
P2-3.5 Maintain availability of 3DS operations
P2 3.5.1 Availability mechanisms are  Examine documented 3DS components should be architected with high availability as a key
implemented to protect against controls. factor in the software, system, and infrastructure design to maintain the
loss of processing capability within  Observe implemented integrity of the 3DS ecosystem. Security policies should reflect availability
the 3DS infrastructure. controls. requirements of 3DS components and security resources in support of 3DS
platform and clusters—for example, review of catastrophic testing results,
failover results, and change-control processes. The controls should ensure
security resources are working correctly and according to policy within the
respective testing processes.
The plan for availability should allow the entity to withstand denial-of-
service (DoS) attacks that could force fallback to less secure verification
methods or provide cover for other attacks against a system or the
infrastructure. The implemented controls should demonstrably reduce this
risk through, for example, a combination of fault-tolerance and rapid
response/recovery capabilities as well as the use of application isolation,
data and system restraints, and load balancing. Documentation and
domain architectures should be reviewed for denial-of-service utilities and
network load-balancing capabilities. Testing of back-up process and data
should be performed.

P2 3.5.2 The availability mechanisms  Observe implemented The mechanisms intended to maintain availability of the 3DS infrastructure
implemented are monitored and controls for monitoring and should be maintained and monitored to ensure they are working as
maintained to confirm maintaining the availability intended and continue to be effective. Continuous monitoring of processing
effectiveness. mechanisms. availability and rapid reporting of outages aid in timely response to
 Interview personnel. potential failures.
Availability mechanisms and technologies evolve and may require periodic
refresh. Additionally, the sophistication of attacks that may adversely
impact availability or that may exploit a degraded system continues to
evolve.

Overview Requirements

P2-4 In addition to ensuring strong access controls and account 4.1 Secure connections for issuer and merchant customers
management for the 3DS environment, certain types of 4.2 Secure internal network connections
access present a higher risk and require more stringent
controls to prevent them from being misused or compromised. 4.3 Secure remote access
4.4 Restrict wireless exposure
4.5 Secure VPNs

Requirements Validation Methods Implementation Guidance

P2-4.1 Secure connections for issuer and merchant customers
P2 4.1.1 Access by issuer and merchant  Examine documented This requirement is intended for scenarios where the 3DS entity provides
users to their assigned issuer and procedures. issuer and merchant users with access to 3DS services and data through
merchant interfaces—for example,  Observe implemented defined issuer and merchant interfaces, such as an API or web portal. In
via API or web portal—for controls. this scenario, the issuer and merchant personnel require a unique user ID
purposes of managing only their with a strong password and another form of strong authentication. Strong
own account, is restricted to authentication techniques should align with industry-accepted practices and
authorized personnel and requires may include:
a unique user ID with strong  One-time passcodes/passwords (OTP)
password and another form of
strong authentication.  Certificate-based authentication (CBA/SAML) where a public and private
key is unique to the authentication device and the person who
possesses it
 Context-based authentication where additional information is required to
verify whether a user’s identity is authentic
 Restriction of connections to only predefined and authorized system
components–e.g., via IP filtering or site-to-site VPN
These merchant/issuer users have access only to their own
merchant/issuer account and are not able to access any other account or
impact the configuration of any application, system component, or network.
While multi-factor authentication is not required for this type of access, it is
recommended.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 41
Requirements Validation Methods Implementation Guidance
P2-4.2 Secure internal network connections
P2 4.2.1 Multi-factor authentication is  Examine documented Multi-factor authentication (MFA) requires the completion of at least two
required for all personnel with non- procedures. different authentication methods—that is, something you know, something
console access to ACS, DS, and  Observe implemented you have, and something you are—prior to access being granted. The
3DSS. controls. authentication mechanisms used should be implemented to ensure their
independence such that access to one factor does not grant access to any
other factor, and the compromise of any one factor does not affect the
integrity or confidentiality of any other factor. Additionally, no prior
knowledge of the success or failure of any factor should be provided to the
individual until all factors have been presented. Refer to industry standards
and best practices for further guidance on MFA principles.
MFA can be applied at the network level, system level, or application level.
For example, MFA could be applied when connecting to the 3DE secure
network or network segment, or when connecting to an individual 3DS
system component.
MFA is required for all personnel connections to the ACS, DS, and 3DSS
that occur over a network interface. Examples of access include for
purposes of maintenance, configuration, updating, administration, or
general management of the 3DS component. MFA is not required for
application or system accounts performing automated functions.

P2-4.3 Secure remote access

P2 4.3.1 Multi-factor authentication is  Examine documented Multi-factor authentication (MFA) is required for all personnel—both user
required for all remote access procedures. and administrator, and including third-party access for support or
originating from outside the entity's  Observe implemented maintenance—accessing the 3DE from outside the entity’s network.
network that provides access into controls. Where MFA is implemented to grant access to the 3DE, additional MFA is
the 3DE.
not required for access to individual systems or applications within the 3DE.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 42
Requirements Validation Methods Implementation Guidance
P2 4.3.2 Remote access to the 3DE is  Examine policies and Remote access processes should be fully documented to ensure access is
controlled and documented, procedures. only granted to users or systems that have been previously approved for
including:  Observe remote access such access. Disconnection of remote access sessions after a period of
 System components for which controls. inactivity should be considered. Policies and operational procedures should
remote access is permitted be kept up to date so personnel understand the proper processes and to
 Interview personnel. prevent unauthorized access to the network.
 The location(s) from which
remote access is permitted
 The conditions under which
remote access is acceptable
 Individuals with remote access
permission
 The access privileges
applicable to each authorized
use

P2 4.3.3 Where remote access using  Examine policies and Remote access using a personally owned device should only be permitted
personally owned devices is procedures. under a strictly defined process that includes management approval and
permitted, strict requirements for  Observe remote access verification that the device could not impact the security of 3DS systems.
their use are defined and controls. Devices should be verified as meeting at least the same rigor of security as
implemented to include:
 Interview personnel. defined in the entity’s security policies. Devices should be maintained and
 Device security controls are monitored via a centralized, secure device-management solution. Approval
implemented and maintained for the use of a personal device should be explicitly provided on a case-by-
as equivalent to corporate- case basis, by an appropriate person who has assigned responsibilities for
owned devices. security. (See Requirement P2-2.1.2.)
 Each device is explicitly
approved by management.

P2 4.3.4 Remote access privileges are  Examine documented Remote access privileges should be regularly reviewed, at least quarterly,
monitored and/or reviewed at least processes. by an authorized individual. Documentation of reviews should be retained.
quarterly by an authorized  Examine evidence of Results of these reviews should include identification and removal of any
individual to confirm access is still monitoring and/or reviews. unneeded or incorrect access, and should ensure that only individuals with
required. a current business need are granted remote access.
 Interview personnel.
Automated processes may be used to assist in reviewing access
privileges—for example, to generate notifications when an account has not
been used for a period of time. Organizational processes to actively review
and change access when an individual changes job function can also
assist.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 43
Requirements Validation Methods Implementation Guidance
P2-4.4 Restrict Wireless Exposure
P2 4.4.1 3DS components (ACS, DS,  Examine network diagrams. To prevent 3DS components from being exposed to wireless networks,
3DSS) do not use or connect to  Observe implemented wireless-enabled devices should not be present within the 3DE.
any wireless network. controls. Additionally, ACS, DS, and 3DSS system components should not use or be
connected to any wireless-enabled components.
 Interview personnel.
Any wireless networks and devices used or supported by the 3DS entity—
for example, for remote users—should be properly secured and configured
in accordance with industry standards.

P2-4.5 Secure VPNs

P2 4.5.1 All VPNs that provide access to  Examine configuration VPN configurations should be reviewed against industry-recommended
3DE are properly configured to standards. implementations to verify security features are enabled. Use of a trusted
provide strong security  Observe VPN controls. CA, a third party that utilizes a chain-of-trust model to provide assurance
communications and protect for a particular certificate, is recommended. If an internal CA is used the
against eavesdropping, replay  Interview personnel. internal CA also needs to be verified as meeting industry requirements
attacks, and man-in-the-middle such as TS101456.
attacks.

Overview Requirements

P2-5 Minimizing the distribution and amount of data to only that which is 5.1 Data lifecycle
necessary helps to reduce the risk of data exposure. The use of data- 5.2 Data transmission
specific controls provides a critical layer of protection when data is
exposed to public or untrusted environments, and can also protect data 5.3 TLS configuration
in trusted environments in the event other security controls are 5.4 Data storage
circumvented. 5.5 Monitoring 3DS transactions

Requirements Validation Methods Implementation Guidance

P2-5.1 Data lifecycle
P2 5.1.1 Policies and procedures for  Examine documented policies. Policies should address protection of 3DS data throughout its lifecycle and
usage, flow, retention, and  Examine evidence of data be based on data sensitivity and legal and business requirements.
disposal of 3DS data are usage, flow, retention and Protection for data in transit, persistent storage, temporary storage, and
maintained and implemented. disposal. memory should be defined. Documentation should explain the purpose,
scope, retention goals, disposal requirements, and applicable legal and
 Interview personnel. business requirements. Local or applicable laws supersede any defined
practices regarding data storage—for example, PII Laws and breach
notification laws should be included in data-classification and retention
policies. Data should be classified according to its security need.

P2 5.1.2 3DS data is retained only as  Examine data retention Data-retention schedules should be defined to identify what data needs to
necessary and securely deleted schedule and data disposal be retained, for how long, where that data resides, and procedures for its
when no longer needed. process secure destruction as soon as it is no longer needed.
 Interview personnel.
 Observe data storage.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 45
Requirements Validation Methods Implementation Guidance
P2-5.2 Data transmission
P2 5.2.1 Strong cryptography and security  Examine documentation Controls should be applied at all interfaces and locations where 3DS
protocols are used to safeguard describing methods for sensitive data (as defined in the PCI 3DS Data Matrix) is transmitted or
3DS sensitive data during encrypting data. received. This includes all transmissions over open or public networks,
transmission.  Examine configuration internal networks, and transmissions within and between 3DS system
standards. domains. 3DS sensitive data should be protected to a level that is at least
P2 5.2.2 Fallback to insecure cryptographic
equivalent to that identified in Annex D of the current version of EMV® 3DS
protocols and configurations is not  Observe implemented Protocol and Core Functions Specification.
permitted. controls.
Secure transmission of 3DS data requires use of trusted keys/certificates,
a secure protocol for transport, and strong cryptography to encrypt the 3DS
data. Connection requests from systems that do not support the required
encryption strength, and that would result in an insecure connection,
should not be accepted.

P2-5.3 TLS configuration

P2 5.3.1 All TLS communications between  Examine configuration Refer to Annex D, “Approved Transport Layer Security Versions,” in the
ACS, DS, and 3DSS for the standards and TLS current version of the EMV® 3DS Protocol and Core Functions
purpose of 3DS transmissions use configurations. Specification, to identify those cipher suites that shall be supported and
only approved cipher suites with at  Observe TLS communications. those that must not be offered or supported. The Implementation Notes in
least the minimum key sizes, as Annex D may also contain additional considerations for TLS
defined in the EMV® 3DS Protocol implementations.
and Core Functions Specification. The use of 3DES and SHA-1 should be phased out, as they may be
P2 5.3.2 3DS components (ACS, DS, and  Examine configuration deprecated in future versions of the EMV® 3DS Protocol and Core
3DSS) do not offer, support, or standards and TLS Functions Specification.
use any cipher suite identified as configurations.
“not supported” in the EMV® 3DS  Observe TLS communications.
Protocol and Core Functions
Specification.

P2 5.3.3 TLS configurations do not support  Examine configuration TLS configurations may not support rollback to unapproved algorithms, key
rollback to unapproved algorithms, standards and TLS sizes, or implementations.
key sizes, or implementations. configurations.
 Observe TLS communications.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 46
Requirements Validation Methods Implementation Guidance
P2 5.3.4 Controls are in place to monitor  Observe implemented controls A combination of tools and processes should be considered to ensure an
TLS configurations to identify for monitoring and maintaining appropriate level of monitoring is implemented. Examples of controls
configuration changes and to TLS configurations. include real-time monitoring, change-detection software, and analysis of
ensure secure TLS configuration  Interview personnel. audit logs. Continuous monitoring is recommended to prevent, detect, and
is maintained. allow timely response to unauthorized modifications or use of non-
permitted configurations. The implemented controls should provide
continued assurance that TLS is properly configured and using only
approved cipher suites.

P2-5.4 Data storage

P2 5.4.1 Storage of 3DS sensitive data is  Examine data flows and 3DS The PCI 3DS Data Matrix identifies storage restrictions for 3DS sensitive
limited to only permitted data transaction processes. data elements. Where storage of a particular data element is not permitted,
elements.  Observe data storage. the 3DS entity should be able to confirm that the data element is not stored
to any persistent media—including to any hard drive, portable media or
other data storage device—for any period of time or for any reason. The
presence of these data elements in volatile memory is permitted as needed
for 3DS transaction purposes; however, controls should be implemented to
prevent data in memory being inadvertently copied to persistent media.

P2 5.4.2 Strong cryptography is used to  Examine documentation 3DS sensitive data—as identified in the PCI 3DS Data Matrix—should be
protect any permitted storage of describing methods for protected wherever it is stored, using industry-recognized methods for
3DS sensitive data. protecting stored data. strong cryptography. The cryptographic control may be applied either to the
 Observe implemented controls individual data elements or to the entire data packet or file that contains the
and configurations. data element. For example, where an element of 3DS sensitive data is
contained in a transaction log with other data, encryption may be applied to
the entire log or to only the sensitive data elements within the log.
Strong cryptographic controls include one-way hash functions that use an
appropriate algorithm and a strong input variable, such as a “salt.” Hash
functions are appropriate when there is no need to retrieve the original
data, as one-way hashes are irreversible. Alternatively the data can be
protected using cryptography based on an industry-tested and accepted
algorithm (not a proprietary or "home-grown" algorithm) with strong
cryptographic keys. Associated key-management processes and
procedures are defined in Requirement P2-6. Refer to industry standards
and best practices for information on strong cryptography and secure
protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.).

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 47
Requirements Validation Methods Implementation Guidance
P2-5.5 Monitoring 3DS transactions
P2 5.5.1 3DS transactions are monitored to  Examine documented Maintaining a baseline of normal 3DS traffic and transaction patterns will
identify, log, and alert upon procedures and configuration assist in identifying anomalous behaviors and developing use cases. All
anomalous activity. standards. identified deviations should be ranked by risk level and responded to
 Examine log files. accordingly. In addition to real-time monitoring and analysis, frequent
P2 5.5.2 Anomalous or suspicious
reviews of network traffic and correlation of audit logs may identify
transaction activity is investigated  Observe implemented potentially suspicious activity.
and addressed in a timely manner. controls.
Response processes should include specific investigative activities,
 Interview personnel.
escalation, and notification, in accordance with the entity’s incident
response plan.

Overview Requirements

P2-6 Proper management and use of cryptographic keys is critical to the 6.1 Key management
continued security of any encryption implementation. Strong key- 6.2 Secure Logical access to HSMs (For ACS
management practices prevent unauthorized or unnecessary access to
and DS only)
the keys, which in turn could result in exposure of keys and
compromise of data the keys are intended to protect. 6.3 Secure Physical access to HSMs (For ACS
and DS only)

Requirements Validation Methods Implementation Guidance

P2-6.1 Key management
P2 6.1.1 Policies and procedures for  Examine documented policies Policies should cover all cryptographic keys and processes used to protect
managing cryptographic and procedures. the confidentiality and integrity of 3DS data and messages during
processes and keys are  Interview personnel. transmission and storage, as well as all respective key-encrypting keys.
maintained and implemented. Cryptographic key-management processes should be monitored and
maintained to ensure adherence to the defined policies.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 49
Requirements Validation Methods Implementation Guidance
P2 6.1.2 For ACS and DS only: All key  Examine documented key- The requirement to use an HSM applies to ACS and DS entities. The PCI
management activity for specified management procedures. 3DS Data Matrix identifies 3DS cryptographic key types required to be
cryptographic keys (as defined in  Interview personnel. managed in an HSM. Key-management activities include key-encryption
the PCI 3DS Data Matrix) is and decryption operations, as well as key lifecycle functions such as key
performed using an HSM that is generation and storage.
either:
The HSM approval documentation verifies the HSM is either:
 FIPS 140-2 Level 3 (overall)
 Listed on the NIST Cryptographic Module Validation Program (CMVP)
or higher certified, or
list, with a valid listing number, and approved to FIPS 140-2 Level 3
 PCI PTS HSM approved. (overall) or higher. Refer to http://csrc.nist.gov.
 Listed on the PCI SSC website, with a valid PCI SSC listing number, as
an Approved PCI PTS Device under the approval class “HSM.”
While an HSM is required only for the keys specified in the PCI 3DS Data
Matrix, use of an HSM for other 3DS keys is strongly recommended. All
3DS keys should be evaluated in accordance with the 3DS entity’s risk-
management policy to determine whether they should be managed in an
HSM.
It is not required that 3DSS entities use an HSM to manage 3DS keys;
however it is strongly recommended. 3DSS entities are subject to all other
key management requirements in this standard.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 50
Requirements Validation Methods Implementation Guidance
P2 6.1.3 For ACS and DS only: The HSM  Examine HSM approval An integral component of a PCI PTS or FIPS certification is the HSM
is deployed securely, in documentation / security security policy, which defines how to configure and operate the HSM in
accordance with its approved policy (as applicable). accordance with the certification.
security policy, as follows:  Observe HSM configurations. The security policy enforced by the HSM should not allow unauthorized or
 If FIPS-approved HSMs are unnecessary functions. HSM API functionality and commands that are not
used, the HSM uses the FIPS- required to support specified functionality should be disabled before the
approved cryptographic HSM is commissioned. When HSMs are connected to online systems,
primitives, data-protection controls should be in place to prevent the HSM being used to perform
mechanisms, and key- privileged or sensitive functions that are not available during routine HSM
management processes for operations. Examples of sensitive functions include but are not limited to:
account data decryption and loading of key components, outputting clear-text key components, and
related processes. altering HSM configuration.
 If PCI PTS-approved HSMs
are used, the HSM is
configured to operate in
accordance with the security
policy that was included in the
PTS HSM approval, for all
operations (including
algorithms, data protection,
key management, etc.).

P2 6.1.4 A documented description of the  Examine documented Cryptographic keys must be stored and functions handled securely to
cryptographic architecture exists description of the prevent unauthorized or unnecessary access that could result in the
that includes: cryptographic architecture. exposure of keys and compromise cardholder data.
 Description of the usage for all  Interview personnel.
keys  Examine HSM approval
 Details of all keys used by documentation.
each HSM (if applicable)

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 51
Requirements Validation Methods Implementation Guidance
P2 6.1.5 Cryptographic keys are securely  Examine documented key- A good key-management process, whether manual or automated, is based
managed throughout the management procedures. on industry standards and addresses all elements of the key lifecycle.
cryptographic lifecycle including:  Observe key-management Applicable standards include NIST Special Publication 800-57 (all parts),
 Generation activities. Special Publication 800-130, ISO 11568, and ISO/IEC 11770—including
associated normative references cited within as applicable. For example,
 Distribution/conveyance  Interview personnel. the generation and use of deterministic random numbers should conform to
 Storage NIST Special Publication 800-90A, ISO/IEC 18031, or equivalent.
 Established crypto periods Keys should only be distributed in a secure manner, never in the clear, and
 Replacement/rotation when only to designated custodians or recipients. Procedures for distribution
the crypto period is reached apply both within the entity and across 3DS domains. Secret and private
 Escrow/backup keys should be encrypted with a strong key-encrypting key that is stored
separately, or be stored within a secure cryptographic device (such as a
 Key compromise and recovery HSM), or be stored as at least two full-length key components or key
 Emergency procedures to shares, in accordance with an industry-accepted method. The existence of
destroy and replace keys clear-text keys during data-encryption/decryption operations should be
 Accountability and audit limited to the minimum time needed for its purpose—for example, where
clear-text keys may temporarily exist in memory, they should be securely
P2 6.1.6 Cryptographic key-management  Examine documented key- purged from memory upon completion of the encryption/decryption
processes conform to recognized management procedures. operation.
national or international key-  Observe key-management
management standards. A crypto period should be identified for each key based on a risk
activities. assessment, and keys changed when this period is reached. Additionally,
 Interview personnel. keys should be destroyed and replaced immediately upon suspicion of a
compromise.
Secure key-management practices include minimizing access to keys to
the fewest number of custodians necessary, enforcing split knowledge and
dual control for activities involving clear-text keys or key components, and
defining roles and responsibilities for key custodians and key managers.
6.1.7 Cryptographic keys are used only  Examine documented key- Cryptographic keys should only be used for the purpose they were
for their intended purpose, and management procedures. intended—for example, a key-encryption key should never be used to
keys used for 3DS functions are  Interview personnel. encrypt 3DS sensitive data. Similarly, public and private keys should only
not used for non-3DS purposes. be used for a single defined purpose—private keys should be used either
for decryption or for creating digital signatures, and public keys used only
for encryption or for verifying digital signatures.
Keys used to protect 3DS transactions or data should not be used for any
business function other than their 3DS purpose.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 52
Requirements Validation Methods Implementation Guidance
P2 6.1.8 A trusted Certificate Authority is  Examine documented Entities need to ensure that the Certificate Authority (CA) that they use has
used to issue all digital evidence of Certificate robust security controls to ensure the security of 3DS protocols and to
certificates used for 3DS Authority validation (e.g., verify a chain of trust. Refer to Section 6.1, “Links,” in the current version of
operations between 3DSS, ACS, security assessments, the EMV® 3DS Protocol and Core Functions Specification to identify
and DS components. certifications). connections between 3DSS, ACS, and DS components that require digital
 Observe implemented digital certificates. The CA could be approved by a payment brand or could
certificates. undergo a security assessment, conducted by the entity or other third
party, against an industry-standard framework such as ISO 27001. The
assessment should confirm the CA has robust controls around security,
processing integrity, confidentiality, online privacy, and availability. Entities
can also leverage WebTrust, an assurance service jointly developed by the
American Institute of Certified Public Accountants (AICPA) and the
Canadian Institute of Chartered Accountants (CICA).

P2 6.1.9 Audit logs are maintained for all  Examine documented key- Recording the function or key-management activity being performed (for
key-management activities and management procedures. example, key loading), and the purpose of the affected key (for example,
all activities involving clear-text  Examine audit logs. 3DS data encryption) provides the entity with a complete and concise
key components. The audit log record of key-management activities. Identifying whether the activity
includes:  Interview personnel. resulted in success or failure confirms the status upon conclusion of the
 Unique identification of the activity. By recording these details for the auditable events, a potential
individual that performed each compromise can be quickly identified with sufficient detail to know who,
function what, where, when, and how.

 Date and time

 Function being performed
 Purpose
 Success or failure of activity
P2 6.1.10 Incident response procedures  Examine documented incident The appropriate personnel should be notified immediately of any breach
include activities for reporting and response procedures. impacting the keys. Documented procedures should explain how this issue
responding to suspicious or  Interview personnel. would be escalated for further investigation and resolution, including
confirmed key-related issues. initiation of the entity’s incident response procedures.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 53
Requirements Validation Methods Implementation Guidance
P2-6.2 Secure logical access to HSMs (For ACS and DS only)
P2 6.2.1 Personnel with logical access to  Examine system HSMs have high security needs, and additional controls are necessary to
HSMs must be either at the HSM configurations restrict and protect logical access to these systems. If personnel have
console or using an HSM non- If non-console access is used: network (non-console) access to HSMs, the security of the HSM non-
console access solution that has console access solution is critical to the overall security of the HSM itself.
been evaluated by an  Examine documented Examples of personnel access include for purposes of maintenance,
independent laboratory to comply evidence (e.g., lab certification configuration, updating, administration, and general management of the
with the following sections of the letters, solution technical HSM. Use of non-console access solution is not required for application or
current version of ISO 13491: documentation, or vendor system accounts performing automated functions.
attestation) that the solution
 Annex A – Section A.2.2: Logical has been validated to An HSM non-console access solution is typically comprised of both
security characteristics. applicable ISO requirements hardware components (for example, network appliances and smart cards)
 Annex D – Section D.2: Logical  Observe implemented solution
and software components (for example, client-side applications) that define
security characteristics. and manage how non-console access is handled. For additional assurance
(Note: The use of single DEA that only authorized persons can access the HSM, the use of multi-factor
message authentication codes is not authentication for all personnel access should also be considered.
permitted.)
An independent laboratory is one that is organizationally independent of
 Annex E – Section E.2.1: Physical the non-console management solution vendor and is not otherwise subject
security characteristics, and Section to any commercial, financial, or other commitment that might influence its
E.2.2: Logical security evaluation of the vendor’s product.
characteristics.
(Note: Only random number
generators meeting the requirements
of SP 800-90A are allowed.)
 Annex F – Section F.2.1: Physical
security characteristics, and Section
F.2.2: Logical security
characteristics.
 If digital signature functionality is
provided: Annex G – Section G.2.1:
General considerations, and Section
G.2.2: Device management for digital
signature verification.

P2 6.2.2 All non-console access to HSMs  Examine network and system To ensure that non-console access to HSMs originates from a secure
originates from a 3DE network(s). configuration settings location, such access may only be provided to systems located within a
3DS environment (3DE) that is protected in accordance with the
requirements in this standard.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 54
Requirements Validation Methods Implementation Guidance
P2 6.2.3 Devices used to provide  Observe locations of devices The term “devices” refers to the endpoint device (for example, a PC,
personnel with non-console used for non-console access laptop, terminal, or secure cryptographic device) that an individual is using
access to HSMs are secured as to HSMs. to access the HSM via a non-console connection. The implemented
follows:  Observe device physical and logical security controls should provide assurance that
 Located in a designated configurations. devices are being used only as intended, and only by authorized
secure area or room that is personnel. The specific security configurations for each device will depend
 Observe HSM authentication on its particular technology and function. In order to prevent malicious
monitored at all times. mechanisms. individuals from “piggy-backing” on an authorized connection, devices
 Locked in room/rack/cabinet/ should only be connected to the network used to access the HSM. For
drawer/safe when not in use. example, connectivity on multi-homed devices should be disabled for all
 Physical access is restricted but the interface accessing the HSM, and any VPN/SSH tunnels to other
to authorized personnel and networks should be closed before opening a tunnel to the HSM.
managed under dual control.
Methods to verify that only authorized devices are permitted to connect to
 Authentication mechanisms the HSM can include digital signatures and other cryptographic techniques.
(e.g., smart cards, dongles,
etc.) for devices with non- All non-console access to HSMs should occur only over a secure
console access are physically communication channel, such as a VPN that meets Requirement 4.4.
secured when not in use.
 Operation of the device
requires dual control and
multi-factor authentication.
 Devices have only
applications and software
installed that are necessary.
 Devices are verified as having
up-to-date security
configurations.
 Devices cannot be connected
to other networks while
connected to the HSM.
 Devices are cryptographically
authenticated prior to the
connection being granted
access to HSM functions.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 55
Requirements Validation Methods Implementation Guidance
P2 6.2.4 The loading and exporting of  Examine device Non-console access to HSMs should only be used for the purpose of HSM
clear-text cryptographic keys, key configurations. maintenance/administration. Because the loading and export of clear-text
components, and/or key shares keys, key components, and key shares requires a higher assurance of
to/from the HSM is not permitted physical security, all such activities are required to be performed at the
over a non-console connection. HSM.

P2 6.2.5 Activities performed via non-  Examine policies and If personnel are not physically at the HSM console, additional controls may
console access adhere to all procedures. be necessary to ensure that the 3DS entity’s policies and procedures
other HSM and key-management  Interview personnel. around key management and HSM usage are adhered to. For example, if
requirements. the ability to access an HSM function or key-management activity requires
 Examine HSM configurations dual control, and the activity or function can be accessed by personnel
and observe connection physically at the HSM console or over a non-console (network) connection,
processes. the requirements for dual control need to be enforced over both methods of
access.
P2-6.3 Secure physical access to HSMs (For ACS and DS only)

P2 6.3.1 HSMs are stored in a dedicated  Examine 3DS device Physical access to HSMs requires passing an additional physical control—
area(s). inventory. e.g., via locked cabinets or cages, or a separate secure room. HSMs could
 Observe physical locations of be in multiple racks within the same dedicated physical space, or in one or
HSMs. more dedicated rooms, and so on.
Where HSMs are in a data center managed by the 3DS entity, the HSMs
P2 6.3.2 Physical access to the HSMs is  Examine documented
should be in a space dedicated to HSMs and HSM-management devices.
restricted to authorized personnel procedures.
Where a 3DS entity’s HSMs are in a shared data center, such as a co-
and managed under dual control.  Observe access controls. location facility, the 3DS entity’s HSMs should be in a space that is
dedicated to the entity’s systems and is physically separate from all other
customers of the co-location facility.
Dual control requires two or more people to perform a function, and no
single person can access or use the authentication materials of another.

Overview Requirements

P2-7 As ACS and DS systems are critical components of the 3DS 7.1 Data center security
infrastructure, they require a secure facility with elevated physical 7.2 CCTV
security controls to restrict, manage, and monitor all physical access.

Requirements Validation Methods Implementation Guidance

P2-7.1 Data center security
P2 7.1.1 ACS and DS systems are hosted  Observe ACS and DS Data centers should apply controls across a number of levels—for
in data center environments. locations. example, door-entry controls may be applied at room level within the data
center, at an outer level that must be passed through to access the data
center, or a combination of both. Some controls may also be applied at
rack level—for example, where the 3DS component is in a secured rack.
However the controls are implemented, they must ensure that access to
the 3DS component is controlled and monitored as defined in these
requirements.

P2 7.1.2 Data centers supporting ACS and  Observe data center entry A positively controlled mantrap is typically a small room with an entry door
DS are equipped with a positively points. on one wall and an exit door on the opposite wall. One door of a mantrap
controlled single-entry portal (e.g., cannot be unlocked and opened until the opposite door has been closed
mantrap), that: and locked.
 Requires positive Access controls can be a combination of automated (for example,
authentication prior to granting electronic access cards and physical barriers) and manual (for example, a
entry; and human security guard performing visual verification and confirmation of
 Grants entry to a single person identity). These controls ensure that the second door is not opened until
for each positive authentication is complete, and that only one individual is provided access
authentication. per authentication.

P2 7.1.3 Doors to areas within the data  Observe all entrances to the Electronic access-control systems, such as a keypad with individually
center that contain 3DS systems 3DE. assigned PIN codes or individually assigned access cards, provide
are fitted with an electronic  Examine audit logs and/or assurance that the individual gaining access is who they claim to be. To
access-control system (e.g., card other access records. provide additional protection against the unauthorized use of an
reader, biometric scanner) that individual’s credential, multi-factor authentication should be considered.
controls and records all entry and
exit activities.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 57
Requirements Validation Methods Implementation Guidance
P2 7.1.4 Multi-factor authentication is  Examine access controls. A telecommunications room is a room or space where communications are
required for entry to  Observe access events. consolidated and distributed. Telecommunications rooms typically house
telecommunications rooms that communications equipment (such as switches and routers), cable
are not located within a secure termination points, and cross-connects serving a specific area and/or floor.
data center. Examples of multi-factor authentication for physical access include use of
an access card with PIN/passcode and use of an access card with a
biometric reader. Visual verification of government-issued photo ID by an
authorized guard at the entry point may also be acceptable as one of the
two factors.
Multi-factor authentication is not required for physical access to
telecommunications rooms housed within a data center environment that
meets the requirements in this standard.

P2 7.1.5 Entry controls prevent piggy-  Observe personnel entering Each individual is identified and authenticated before being granted access
backing by granting access to a the data center. to the 3DS data centers. These controls provide assurance that the identity
single person at a time, with each of every individual in the data center is known at any given time.
person being identified and
authenticated before access is
granted.

P2 7.1.6 A physical intrusion-detection  Interview personnel. To be effective, an intrusion-detection system should be activated
system that is connected to the  Observe intrusion-detection whenever the 3DS environment is intended to be unoccupied. The
alarm system is in place. controls. intrusion-detection system may be activated automatically or via manual
process.

P2 7.1.7 Physical connection points leading  Observe physical connection Securing networking and communications hardware prevents malicious
into the 3DE are controlled at all points. users from intercepting network traffic or physically connecting their own
times. devices to wired network resources.

P2-7.2 CCTV
P2 7.2.1 CCTV cameras are located at all  Observe all entrances and The cameras need to be able to identify individuals physically entering and
entrances and emergency exit emergency exit points. exiting the area, even during dark periods, as this provides valuable
points and capture identifiable  Examine CCTV footage. information in the event of an investigation.
images, at all times of the day and
night.

P2 7.2.2 CCTV recordings are time  Examine CCTV records. Clocks need to be properly synchronized to ensure the captured images
stamped. can be correlated to create an accurate record of the sequence of events.
Synchronization may use automated or manual mechanisms.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 58
Appendix A-1: Compensating Controls
Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use
of compensating controls to meet a PCI 3DS requirement.

Compensating controls must satisfy the following criteria:

1. Meet the intent and rigor of the original PCI 3DS requirement.

2. Provide a similar level of defense as the original PCI 3DS requirement, such that the compensating control sufficiently offsets the risk that
the original PCI 3DS requirement was designed to defend against.

3. Be “above and beyond” other PCI 3DS requirements. (Simply being in compliance with other PCI 3DS requirements is not a compensating
control.)

When evaluating “above and beyond” for compensating controls, consider the following:
(a) Existing PCI 3DS requirements CANNOT be considered as compensating controls if they are already required for the item under
review.
(b) Existing PCI 3DS requirements MAY be considered as compensating controls if they are required for another area, but are not
required for the item under review.
(c) Existing PCI 3DS requirements may be combined with new controls to become a compensating control.

Note: The items at a) through c) above are intended as examples only. All compensating controls must be reviewed and validated for
sufficiency by the assessor who conducts the PCI 3DS review. The effectiveness of a compensating control is dependent on the specifics
of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Entities
should be aware that a particular compensating control will not be effective in all environments.

4. Be commensurate with the additional risk imposed by not adhering to the PCI 3DS requirement.

The assessor is required to thoroughly evaluate all compensating controls during the PCI 3DS assessment and validate that each compensating
control adequately addresses the risk the original PCI 3DS requirement was designed to address. Processes and controls must be in place to
ensure compensating controls remain effective after the assessment is complete.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 59
Appendix A-2: Compensating Controls Worksheet
Use this worksheet to document any compensating controls used to meet a PCI 3DS requirement. Compensating controls should also be
documented with the corresponding PCI 3DS requirement in the 3DS Report on Compliance.

3DS Requirement Number and Description:

Information Required Description Explanation

1. Constraints List constraints precluding compliance with the

original requirement.

2. Objective Define the objective of the original

requirement; identify the objective met by the
compensating control.

3. Identified Risk Identify any additional risk posed by the lack

of the original control.

4. Definition of Compensating Define the compensating controls and explain

Controls how they address the objectives of the original
control and the increased risk, if any.

5. Validation of Compensating Define how the compensating controls were

Controls validated and tested.

6. Maintenance Define processes and controls in place to

monitor and maintain the effectiveness of the
compensating controls.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 60
Appendix B: Alignment between PCI 3DS and PCI DSS Requirements
The PCI 3DS Part 1 Baseline Security Requirements cover many of the security objectives required by PCI DSS. Where PCI DSS has been
applied to the 3DS environment as described below, the implementation of additional controls may not be needed to meet the PCI 3DS Part 1
Requirements:
1. The 3DE is contained within a CDE, and all 3DS system components—including supporting infrastructure and systems—are included in
scope for the applicable PCI DSS requirements. See Table 2 “Mapping of PCI 3DS Part 1: Baseline Security Requirements to PCI DSS
Requirements” later in this section for details of applicable PCI DSS requirements; and
2. The applicable PCI DSS requirements are confirmed to be “In Place” through a PCI DSS assessment performed no more than 12 months
prior to the 3DS assessment.
A 3DE that is not within the security boundary of a PCI DSS-compliant (as defined by applicable payment brand Note: The individual
compliance programs) CDE, or does not store, process, or transmit any cardholder data (CHD) or sensitive authentication payment brand
data (SAD), may be subject to PCI 3DS Part 1 Requirements, based on payment brand compliance programs. compliance programs
define whether an entity is
The applicability of PCI 3DS Part 2: 3DS Security Requirements is not impacted by a PCI DSS implementation. The PCI
required to validate to PCI
3DS Part 2 Requirements apply whether or not PCI DSS is also implemented.
3DS, PCI DSS, or both.
The following diagram provides an illustration of how PCI DSS may impact applicability of 3DS Requirements.
Diagram 1: Relationship between PCI 3DS Requirements and PCI DSS

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 61
A 3DS entity that has applied PCI DSS in accordance with Table 2 “Mapping of PCI 3DS Part 1: Baseline Security Requirements to PCI DSS
Requirements” may either confirm that its PCI DSS validation covers the systems and environments in scope for PCI 3DS, or complete validation
to the 3DS Part 1 Requirements. A 3DS entity that does not store, process, or transmit any account data (CHD and/or SAD), and therefore has not
applied PCI DSS, should complete both 3DS Part 1 and 3DS Part 2 Requirements.
The following diagrams conceptually illustrate how a 3DE could be separate to or within a CDE, and the corresponding applicability of requirements.

Diagram 2: Scenario with Standalone 3DE

In Diagram 2 above, the 3DS entity does not store, process, or transmit any account data (CHD or SAD) as part of the 3DS transaction process.
This entity’s 3DE is therefore not part of any CDE and is not protected by PCI DSS. In this scenario, the 3DS systems in the 3DE are subject to
3DS Part 1 and Part 2 Requirements.
Systems that are outside of the 3DE and that connect to or otherwise support 3DS system components in the 3DE would also be subject to 3DS
Part 1 and Part 2 Requirements.

In Diagram 3 above, the entity’s 3DE is contained within or is the same as its CDE, and all 3DE system components (including ACS, DS, and/or
3DSS) are already protected by PCI DSS. In this scenario, the 3DS systems in the 3DE may be validated to either PCI DSS or 3DS Part 1
Requirements. The 3DS Part 2 Requirements also apply to these system components.
System components that are outside the combined 3DE/CDE and that connect to or otherwise support 3DS system components in the 3DE also
need to be protected. If all connected-to and supporting systems are protected by the appropriate PCI DSS controls, these system components
could also be validated to either PCI DSS or 3DS Part 1 Requirements. In all cases, these system components would be subject to 3DS Part 2
Requirements.

PCI 3DS Security Requirements and Assessment Procedures for EMV® 3-D Secure Core Components: ACS, DS, and 3DS Server, v1.0 October 2017
© 2017 PCI Security Standards Council, LLC. All Rights Reserved. Page 63
Leveraging PCI DSS for PCI 3DS Part 1: Baseline Security Requirements
A mapping of PCI 3DS Part 1 Requirements to the applicable PCI DSS requirements is provided in Table 2 on the following page. The intent of
this mapping is to assist 3DS entities that have implemented PCI DSS to protect their 3DS environment in confirming that the PCI DSS controls
they have implemented are appropriate to meet the objectives of the 3DS Part 1 Requirements.

 All identified PCI DSS requirements in place – 3DS entities that have all the identified PCI DSS requirements in place for their 3DS
environment could either:
(a) Confirm PCI DSS coverage for the scope of their 3DS environment, or
(b) Validate to 3DS Part 1 Requirements

 Some but not all identified PCI DSS requirements in place – 3DS entities that have some but not all the identified PCI DSS
requirements in place for their 3DS environment could either:
(a) Implement and validate the applicable PCI DSS requirements in order to confirm PCI DSS coverage, or
(b) Validate to 3DS Part 1 Requirements.

 One or more PCI DSS requirements identified as N/A – If any PCI DSS requirements were identified as being “Not Applicable” during
the PCI DSS assessment, the 3DS entity could either:
(a) Provide verification that all “N/A” PCI DSS requirement(s) are also not applicable to the 3DS environment, or
(b) Implement and validate the applicable PCI DSS requirements in order to confirm PCI DSS coverage, or
(c) Complete the 3DS Part 1 Requirements.

 PCI DSS has not been implemented – Entities that have not implemented PCI DSS should complete the 3DS Part 1 Requirements in
their entirety.

3DS Part 1: Baseline Security Requirements PCI DSS Requirements

1. Maintain security policies for all  Requirement 12: Maintain a policy that addresses information security for all personnel
personnel

2. Secure network connectivity  Requirement 1: Install and maintain a firewall configuration to protect cardholder data
 Requirement 10: Track and monitor all access to network resources and cardholder data
 Requirement 11: Regularly test security systems and processes

3. Develop and maintain secure systems  Requirement 2: Do not use vendor-supplied defaults for system passwords and other
security parameters
 Requirement 6: Develop and maintain secure systems and applications

4. Vulnerability management  Requirement 5: Protect all systems against malware and regularly update anti-virus
software or programs
 Requirement 6: Develop and maintain secure systems and applications
 Requirement 11: Regularly test security systems and processes

5. Manage access  Requirement 7: Restrict access to cardholder data by business need to know
 Requirement 8: Identify and authenticate access to system components

6. Physical security  Requirement 9: Restrict physical access to cardholder data

7. Incident response preparedness  Requirement 10: Track and monitor all access to network resources and cardholder data
 Requirement 12: Maintain a policy that addresses information security for all personnel

Note: The applicability of 3DS Part 2: 3DS Security Requirements is not impacted by a PCI DSS implementation.

Smart Reader: Operating Manual
No ratings yet
Smart Reader: Operating Manual
39 pages
01-05 Class-Based QoS Configuration
No ratings yet
01-05 Class-Based QoS Configuration
135 pages
1270A542-004 Payshield 9000 Host Programmer's Manual
100% (1)
1270A542-004 Payshield 9000 Host Programmer's Manual
105 pages
3manager Technical White Paper
No ratings yet
3manager Technical White Paper
14 pages
BlackHatUSA2018 DEFCON26 PHV Wpa-Sec AlexStanev
No ratings yet
BlackHatUSA2018 DEFCON26 PHV Wpa-Sec AlexStanev
17 pages
EMVCo 3DS Spec v220 122018
No ratings yet
EMVCo 3DS Spec v220 122018
286 pages
Dasd
No ratings yet
Dasd
3 pages
Iot SIMP Tie - 2024
No ratings yet
Iot SIMP Tie - 2024
3 pages
CentOS7 FreeIPA AD Integration
No ratings yet
CentOS7 FreeIPA AD Integration
18 pages
Introduction To Cloud Computing
No ratings yet
Introduction To Cloud Computing
49 pages
Zerotier Openwrt
No ratings yet
Zerotier Openwrt
6 pages
TSYS EMV Implementation Guide
No ratings yet
TSYS EMV Implementation Guide
230 pages
Skills Develpment MCQs
No ratings yet
Skills Develpment MCQs
8 pages
Analysis of LoRa Link Quality For Underwater Wireless Sensor Networks A Semi-Empirical Study
No ratings yet
Analysis of LoRa Link Quality For Underwater Wireless Sensor Networks A Semi-Empirical Study
3 pages
Mtctce 2
100% (1)
Mtctce 2
5 pages
X9.24 3 2017 Test Vectors 20180129 1
No ratings yet
X9.24 3 2017 Test Vectors 20180129 1
66 pages
2012 - Fail-Over Clustering
No ratings yet
2012 - Fail-Over Clustering
34 pages
Privacy and Security
No ratings yet
Privacy and Security
11 pages
Payment Card Industry 3-D Secure (PCI 3DS)
No ratings yet
Payment Card Industry 3-D Secure (PCI 3DS)
7 pages
Output
No ratings yet
Output
6 pages
MC Onbehalf Key MGMT Interface Spec
100% (1)
MC Onbehalf Key MGMT Interface Spec
100 pages
Ubiquiti Home Network
100% (3)
Ubiquiti Home Network
132 pages
Five Ways To Transform Access and Secure The Digital Enterprise
No ratings yet
Five Ways To Transform Access and Secure The Digital Enterprise
11 pages
TR-31 Key Block Implementation-Whitepaper-Excrypt
No ratings yet
TR-31 Key Block Implementation-Whitepaper-Excrypt
16 pages
Xcode Private Training Linux Networking
No ratings yet
Xcode Private Training Linux Networking
4 pages
EMVCo Payment Tokenisation Specification Technical Framework v2.3
No ratings yet
EMVCo Payment Tokenisation Specification Technical Framework v2.3
106 pages
350-401 60423b177d74
No ratings yet
350-401 60423b177d74
41 pages
WSIPTCiscoCUCM10 5CUBE9 5
No ratings yet
WSIPTCiscoCUCM10 5CUBE9 5
13 pages
Fall in Love With I2C LCD Displays PDF
100% (2)
Fall in Love With I2C LCD Displays PDF
7 pages
Chapter XXV: Fault Control Procedures
No ratings yet
Chapter XXV: Fault Control Procedures
5 pages
Network Programming: What Is in This Chapter ?
No ratings yet
Network Programming: What Is in This Chapter ?
21 pages
PCI DSS v3-2-1
No ratings yet
PCI DSS v3-2-1
139 pages
Pg056-Cpri v87
No ratings yet
Pg056-Cpri v87
180 pages
Command 2G 3G 4G 18052022
No ratings yet
Command 2G 3G 4G 18052022
66 pages
Rsa Securid Suite: Accelerate Business While Mitigating Identity Risk
No ratings yet
Rsa Securid Suite: Accelerate Business While Mitigating Identity Risk
7 pages
PGD v5 Documentation
No ratings yet
PGD v5 Documentation
443 pages
DocOverview PDF
No ratings yet
DocOverview PDF
1 page
VHD-V500N 3.0 User Manual3.1.8V
No ratings yet
VHD-V500N 3.0 User Manual3.1.8V
69 pages
Right-Sized It Solution: Small Office Solution: Proliant Microserver Gen8 and Ps1810 Switch Series
No ratings yet
Right-Sized It Solution: Small Office Solution: Proliant Microserver Gen8 and Ps1810 Switch Series
4 pages
CAIQ v3.1 Final
100% (1)
CAIQ v3.1 Final
586 pages
Installation Guide - : IIS Server Hosting Guideline (EPM)
No ratings yet
Installation Guide - : IIS Server Hosting Guideline (EPM)
20 pages
ISO 20022 Development
No ratings yet
ISO 20022 Development
62 pages
Visa TADG
100% (1)
Visa TADG
212 pages
Intersect PIPESIMCoupling
100% (1)
Intersect PIPESIMCoupling
18 pages
Visa Approved Dual Chip Cards - January 2022
No ratings yet
Visa Approved Dual Chip Cards - January 2022
23 pages
PCI Requirements On Implementing Key Blocks - Migration Phases and Key Management Solutions
No ratings yet
PCI Requirements On Implementing Key Blocks - Migration Phases and Key Management Solutions
5 pages
Users Guide
No ratings yet
Users Guide
51 pages
5G - XN Application Protocol: Nex-G Innovations - NESPL & Infoserve Qatar
No ratings yet
5G - XN Application Protocol: Nex-G Innovations - NESPL & Infoserve Qatar
23 pages
Payshield 9000 Payshield 9000 and DUKPT Application Note PWPR April 2013
No ratings yet
Payshield 9000 Payshield 9000 and DUKPT Application Note PWPR April 2013
25 pages
Copia de SCA-3 User Guide Version 2.0 C8Z33-9003C PDF
No ratings yet
Copia de SCA-3 User Guide Version 2.0 C8Z33-9003C PDF
316 pages
PCI PTS POI - SRED v4.x
No ratings yet
PCI PTS POI - SRED v4.x
51 pages
BAR Test Cases Manual
No ratings yet
BAR Test Cases Manual
20 pages
EMVCo Software Based Mobile Payment Security Requirements - V1.0 - 20161213 - 20161213093622436
No ratings yet
EMVCo Software Based Mobile Payment Security Requirements - V1.0 - 20161213 - 20161213093622436
42 pages
PIN Security RQMT 18-3 Key Blocks 2022 v1.1
No ratings yet
PIN Security RQMT 18-3 Key Blocks 2022 v1.1
15 pages
Normative Annex B - Key-Injection Facilities
No ratings yet
Normative Annex B - Key-Injection Facilities
81 pages
ACI Guide
No ratings yet
ACI Guide
254 pages
FAQs For PCI 3DS Core Security Standard v1 - 1
No ratings yet
FAQs For PCI 3DS Core Security Standard v1 - 1
6 pages
PCI DSS v3-2-1 PDF
No ratings yet
PCI DSS v3-2-1 PDF
139 pages
PCI DSS v3 2 1 r1
No ratings yet
PCI DSS v3 2 1 r1
139 pages
UIC680TG Programmer S Manual REV 2.7
No ratings yet
UIC680TG Programmer S Manual REV 2.7
103 pages
Cryptography
No ratings yet
Cryptography
43 pages
csfb400 Icsf Apg hcr77d1 PDF
No ratings yet
csfb400 Icsf Apg hcr77d1 PDF
1,720 pages
Sunmi KLD KeyManagement V2.101
No ratings yet
Sunmi KLD KeyManagement V2.101
7 pages
Seminar MWC Visa Token Service
No ratings yet
Seminar MWC Visa Token Service
11 pages
Tms Messageusageguide 7.0 Key Downloading
No ratings yet
Tms Messageusageguide 7.0 Key Downloading
198 pages
PCI Slides Merged
No ratings yet
PCI Slides Merged
161 pages
What Is 3DS
No ratings yet
What Is 3DS
16 pages
3-D Secure (PCI 3DS) : Payment Card Industry (PCI)
No ratings yet
3-D Secure (PCI 3DS) : Payment Card Industry (PCI)
16 pages
PPRN0523-079 Payshield 9000 Base Software v3.5b Release Notes
No ratings yet
PPRN0523-079 Payshield 9000 Base Software v3.5b Release Notes
103 pages
Data Security Standard: Payment Card Industry (PCI)
No ratings yet
Data Security Standard: Payment Card Industry (PCI)
115 pages
Apache HTTPServer LunaHSM IntegrationGuide RevJ
No ratings yet
Apache HTTPServer LunaHSM IntegrationGuide RevJ
24 pages
PCI PIN Security Requirements v2
No ratings yet
PCI PIN Security Requirements v2
101 pages
Ultra AEP - Cryptosec Banking Data Sheet
No ratings yet
Ultra AEP - Cryptosec Banking Data Sheet
2 pages
EMV - Understanding
No ratings yet
EMV - Understanding
3 pages
book2-EMV v4.2 Book 2 Security and Key Management CR05 - 20090122094212
100% (1)
book2-EMV v4.2 Book 2 Security and Key Management CR05 - 20090122094212
176 pages
PCI PIN Security Requirements
No ratings yet
PCI PIN Security Requirements
86 pages
Electronic Payments Security & Payment Card Industry (PCI) Security Standards
No ratings yet
Electronic Payments Security & Payment Card Industry (PCI) Security Standards
26 pages
Traninghsm 141124071350 Conversion Gate01
100% (1)
Traninghsm 141124071350 Conversion Gate01
61 pages
Paymenthsmpayshield9000 13324102949915 Phpapp01 120322045859 Phpapp01
No ratings yet
Paymenthsmpayshield9000 13324102949915 Phpapp01 120322045859 Phpapp01
29 pages
NEW PCI DSS 3.0 Requirements (PCI Compliance)
No ratings yet
NEW PCI DSS 3.0 Requirements (PCI Compliance)
112 pages
Safe Net HSM
No ratings yet
Safe Net HSM
46 pages
Cryptography and Key Mangement001
No ratings yet
Cryptography and Key Mangement001
95 pages
Key Management Guidance v1 3
No ratings yet
Key Management Guidance v1 3
71 pages
Quick Chip Emv Specification
No ratings yet
Quick Chip Emv Specification
11 pages
EMV Overview
100% (1)
EMV Overview
51 pages
O Dukpt
No ratings yet
O Dukpt
18 pages
EMV General Functional Desc
100% (2)
EMV General Functional Desc
18 pages
Data Encryption Best Practices For PCI
No ratings yet
Data Encryption Best Practices For PCI
5 pages
EPC342-08 Guidelines On Algorithms and Key Management
No ratings yet
EPC342-08 Guidelines On Algorithms and Key Management
57 pages
PCI DSS Compliance Statement
100% (2)
PCI DSS Compliance Statement
12 pages
Eracom HSM
No ratings yet
Eracom HSM
43 pages
Best Practices For Point of Sale Security - Published Version 1
No ratings yet
Best Practices For Point of Sale Security - Published Version 1
78 pages
Visa Integrated Circuit Card Terminal Specification
No ratings yet
Visa Integrated Circuit Card Terminal Specification
258 pages
Personalization Data Specifications: For Debit and Credit On Chip
100% (1)
Personalization Data Specifications: For Debit and Credit On Chip
71 pages

PCI 3DS Core Security Standard v1

Uploaded by

PCI 3DS Core Security Standard v1

Uploaded by

Payment Card Industry

3-D Secure (PCI 3DS)

Security Requirements and Assessment Procedures for

October 2017 1.0 Initial version

 3DS Directory Server (DS)

 3DS Access Control Server (ACS)

Participating Payment Brands

 Fines or penalties for non-compliance.

3DS Access Control Server (ACS)

3DS Directory Server (DS)

3DS Server (3DSS)

Risk-Management Approach to Requirements

3DS Assessment Process

Requirements Validation Methods Implementation Guidance

P1-1.3 Educate personnel

P1 1.3.3 Personnel are aware of the  Interview personnel.

Requirements Validation Methods Implementation Guidance

P1-2.2 Protect 3DS systems from network threats

Requirements Validation Methods Implementation Guidance

P1-3.2 Configuration standards

P1-3.3 Change management

Requirements Validation Methods Implementation Guidance

P1-4.2 Address vulnerabilities and security weaknesses

Requirements Validation Methods Implementation Guidance

P1-5.2 Account management

Requirements Validation Methods Implementation Guidance

Requirements Validation Methods Implementation Guidance

P1-7.2 Audit logs

Requirements Validation Methods Implementation Guidance

Requirements Validation Methods Implementation Guidance

P2-2.2 Manage risk

P2-2.4 Manage third-party relationships

Requirements Validation Methods Implementation Guidance

P2-3.2 Protect baseline configurations

P2-3.4 Secure web configurations

Requirements Validation Methods Implementation Guidance

P2-4.3 Secure remote access

P2-4.5 Secure VPNs

Requirements Validation Methods Implementation Guidance

P2-5.3 TLS configuration

P2-5.4 Data storage

Requirements Validation Methods Implementation Guidance

 Date and time

Requirements Validation Methods Implementation Guidance

Compensating controls must satisfy the following criteria:

3DS Requirement Number and Description:

Information Required Description Explanation

1. Constraints List constraints precluding compliance with the

2. Objective Define the objective of the original

3. Identified Risk Identify any additional risk posed by the lack

4. Definition of Compensating Define the compensating controls and explain

5. Validation of Compensating Define how the compensating controls were

6. Maintenance Define processes and controls in place to

Diagram 2: Scenario with Standalone 3DE

3DS Part 1: Baseline Security Requirements PCI DSS Requirements

6. Physical security  Requirement 9: Restrict physical access to cardholder data

You might also like