Document Comparison
PCI_3DS_SDK_Security_Standard_v1.0.pdf
→
PCI-3DS-SDK-Security-Standard-v1.1.pdf
17% similar
29 → 54
Pages
2364 → 18982
Words
39
Content Changes
Content Changes
39 content changes. 10 administrative changes (dates, page numbers) hidden.
Added
p. 4
December 2018 Document Changes Date Version Description Pages
November 2017 1.0 Initial release
December 2018 1.1 Detailed assessment procedures added
November 2017 1.0 Initial release
December 2018 1.1 Detailed assessment procedures added
Added
p. 5
December 2018 Introduction This document, PCI Security Requirements and Assessment Procedures for EMV® 3-D Secure SDK (hereafter referred to as the PCI 3DS SDK Security Standard), defines security requirements and testing procedures for 3-D Secure (3DS) Software Development Kits (SDK) as defined in the EMV® 3-D Secure SDK Specification.
This PCI 3DS SDK Security Standard defines security controls to facilitate secure 3DS SDK implementations. It does not address how an entity would meet the requirements in the EMV® 3-D Secure SDK Specification. Entities that develop 3DS SDKs (3DS SDK Vendors) may be subject to the requirements in this document. Prior to undergoing an assessment, 3DS SDK Vendors should confirm with the payment brand(s) whether they are required to validate compliance with the security objectives and requirements in this standard.
The requirements in this standard apply specifically to application-based EMV 3-D Secure implementations. Please refer to the EMV® 3-D Secure Protocol and Core …
This PCI 3DS SDK Security Standard defines security controls to facilitate secure 3DS SDK implementations. It does not address how an entity would meet the requirements in the EMV® 3-D Secure SDK Specification. Entities that develop 3DS SDKs (3DS SDK Vendors) may be subject to the requirements in this document. Prior to undergoing an assessment, 3DS SDK Vendors should confirm with the payment brand(s) whether they are required to validate compliance with the security objectives and requirements in this standard.
The requirements in this standard apply specifically to application-based EMV 3-D Secure implementations. Please refer to the EMV® 3-D Secure Protocol and Core …
Added
p. 7
December 2018 Term Definition Sideloading attacks The act of installing an application obtained from an (untrusted) source other than an official application repository for the device (e.g., the App Store for iOS and Google Play for Android).
Tester An individual or agent of the PCI 3DS SDK Lab performing the PCI 3DS SDK Assessment (in whole or in part).
• EMV® 3-D Secure Protocol and Core Functions Specification (www.emvco.com)
• Maintains the PCI 3DS SDK 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 SDK Security Standard.
• Maintains the list of approved 3DS SDK versions and qualified PCI 3DS SDK Labs on the PCI SSC website.
• Maintains a quality assurance program for qualified PCI 3DS SDK Labs.
December 2018 Participating Payment Brands The Participating Payment Brands develop and enforce their respective programs related to compliance with PCI …
Tester An individual or agent of the PCI 3DS SDK Lab performing the PCI 3DS SDK Assessment (in whole or in part).
• EMV® 3-D Secure Protocol and Core Functions Specification (www.emvco.com)
• Maintains the PCI 3DS SDK 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 SDK Security Standard.
• Maintains the list of approved 3DS SDK versions and qualified PCI 3DS SDK Labs on the PCI SSC website.
• Maintains a quality assurance program for qualified PCI 3DS SDK Labs.
December 2018 Participating Payment Brands The Participating Payment Brands develop and enforce their respective programs related to compliance with PCI …
Added
p. 16
Requirement 1: Mechanisms are implemented to prevent unauthorized modification of the 3DS SDK, the functionality it provides, and the sensitive 3DS SDK data elements it handles.
Added
p. 16
• The device is rooted or jailbroken
• An emulator is being used to run the 3DS SDK
• The 3DS SDK has been tampered with
• A debugger is attached T.1.1.1 The tester shall examine vendor materials and other evidence to determine what features are provided by the 3DS SDK to provide security checks of the operating environment, and how any issues are escalated to the 3DS Requestor App. From this review, the tester shall determine what APIs are provided by the 3DS SDK for these purposes, the functions that are performed (and how often), and what error/warning messages are returned by the 3DS SDK. At a minimum, the SDK shall perform the checks upon initialization.
The purpose of device security checks is to collect potential indicators of device compromise and make that information available to the ACS to allow the issuer to make risk-based decisions on how to proceed with the 3DS …
• An emulator is being used to run the 3DS SDK
• The 3DS SDK has been tampered with
• A debugger is attached T.1.1.1 The tester shall examine vendor materials and other evidence to determine what features are provided by the 3DS SDK to provide security checks of the operating environment, and how any issues are escalated to the 3DS Requestor App. From this review, the tester shall determine what APIs are provided by the 3DS SDK for these purposes, the functions that are performed (and how often), and what error/warning messages are returned by the 3DS SDK. At a minimum, the SDK shall perform the checks upon initialization.
The purpose of device security checks is to collect potential indicators of device compromise and make that information available to the ACS to allow the issuer to make risk-based decisions on how to proceed with the 3DS …
Added
p. 18
Run-time integrity checks are intended to ensure that only authorized libraries are used, and rogue functions are not inserted, attached or executed at run-time. One method for performing run-time integrity checks may include using hooking detection techniques specific to the underlying operating system, software development framework or language. However, other methods could be used to achieve the same objective.
T.1.3.2 Where these checks implement the use of a hash function to validate the integrity of the 3DS SDK executable, the tester shall examine vendor materials and other evidence to confirm that the hash function meets PCI requirements of strong cryptography, including applicable cryptography requirements in this standard.
December 2018 Requirements Assessment Procedures Guidance T.1.3.3 The tester shall confirm that these checks include tests to identify attacks that aim to perform interruption of code execution or flow, interception and modification of data elements as they are processed, or modification of responses from the …
T.1.3.2 Where these checks implement the use of a hash function to validate the integrity of the 3DS SDK executable, the tester shall examine vendor materials and other evidence to confirm that the hash function meets PCI requirements of strong cryptography, including applicable cryptography requirements in this standard.
December 2018 Requirements Assessment Procedures Guidance T.1.3.3 The tester shall confirm that these checks include tests to identify attacks that aim to perform interruption of code execution or flow, interception and modification of data elements as they are processed, or modification of responses from the …
Added
p. 20
T.1.4.1 The tester shall examine vendor materials and other evidence to confirm that features are provided by the 3DS SDK to protect the 3DS SDK and any data structures that may be stored in memory, the operating system file system, or other storage locations (such as an OS key store) from reverse engineering.
Note: This requirement is focused on the determination of the data flow and functions of the 3DS SDK, not necessarily the secrecy of the data.
String and code obfuscation tools and techniques might be sufficient to make the reverse engineering of 3DS SDK binaries impractical depending upon the implementation. Properly implemented runtime application self-protection (RASP) and/or anti-debugging techniques could also be used.
T.1.4.2 The tester shall determine where the SDK or data structures are not covered by these protections, and confirm this lack of protection does not affect the security of the SDK or 3DS operation.
T.1.4.3 The tester shall determine …
Note: This requirement is focused on the determination of the data flow and functions of the 3DS SDK, not necessarily the secrecy of the data.
String and code obfuscation tools and techniques might be sufficient to make the reverse engineering of 3DS SDK binaries impractical depending upon the implementation. Properly implemented runtime application self-protection (RASP) and/or anti-debugging techniques could also be used.
T.1.4.2 The tester shall determine where the SDK or data structures are not covered by these protections, and confirm this lack of protection does not affect the security of the SDK or 3DS operation.
T.1.4.3 The tester shall determine …
Added
p. 23
T.1.5.1 The tester shall examine vendor materials and other evidence to identify all 3DS SDK Reference Data used or required by the 3DS SDK, which must be protected against modification (see Table 2, “Sensitive 3DS SDK Data Elements”).
The 3DS SDK Version Number and 3DS SDK Reference Number are values used during 3-D Secure transactions as part of the cardholder authentication process. To properly vet the cardholder and to identify the trustworthiness of the environment in which a transaction has been created, it is important that the values are protected from unauthorized modification.
Examples of methods for securely storing the 3DS SDK Reference Number or 3DS SDK Application ID (sdkAppID) in code might include obfuscation or the use of cryptography.
T.1.5.2 The tester shall examine vendor materials and other evidence to confirm that features are provided by the 3DS SDK to protect each element of the 3DS SDK Reference Data listed above. Where …
The 3DS SDK Version Number and 3DS SDK Reference Number are values used during 3-D Secure transactions as part of the cardholder authentication process. To properly vet the cardholder and to identify the trustworthiness of the environment in which a transaction has been created, it is important that the values are protected from unauthorized modification.
Examples of methods for securely storing the 3DS SDK Reference Number or 3DS SDK Application ID (sdkAppID) in code might include obfuscation or the use of cryptography.
T.1.5.2 The tester shall examine vendor materials and other evidence to confirm that features are provided by the 3DS SDK to protect each element of the 3DS SDK Reference Data listed above. Where …
Added
p. 25
T.2.1.1 The tester shall examine vendor materials and other evidence to determine all sensitive 3DS SDK data elements used or required by the 3DS SDK. Vendor evidence should account for the name of the data element collected, the duration for which the data element is retained, how the data element is stored (e.g., in memory only, in the OS file system, in an OS storage mechanism such as a key store, in a device mechanism such as a Trusted Execution Environment, etc.), and how the data element is securely deleted after storage.
To ensure that the 3DS SDK does not disclose sensitive 3DS SDK data elements to unauthorized parties, the 3DS SDK should only collect the sensitive 3DS SDK data elements absolutely necessary to perform its expected functionality. Collecting sensitive 3DS SDK data elements that do not directly support the functionality of the 3DS SDK presents the opportunity for the information …
To ensure that the 3DS SDK does not disclose sensitive 3DS SDK data elements to unauthorized parties, the 3DS SDK should only collect the sensitive 3DS SDK data elements absolutely necessary to perform its expected functionality. Collecting sensitive 3DS SDK data elements that do not directly support the functionality of the 3DS SDK presents the opportunity for the information …
Added
p. 28
T.2.3.1 The tester shall examine vendor materials and other evidence to confirm that the vendor maintains an inventory of all third-party services and components used by the 3DS SDK.
The use of third-party services or components should be carefully controlled and justified. Control over sensitive information may no longer reside with the 3DS SDK Vendor once sensitive information is shared or made accessible to third- party services or components, and 3DS SDK Vendors should consider the ramifications of third- party misuse or disclosure of such information.
T.2.3.2 Referring to the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to determine all sensitive 3DS SDK data elements that are passed to third-party components or services.
Note: Validation of this requirement must also consider whether the 3DS SDK has any advertising, machine learning, data collection, logging, tracking, or security features which rely on third-party components, features, or …
The use of third-party services or components should be carefully controlled and justified. Control over sensitive information may no longer reside with the 3DS SDK Vendor once sensitive information is shared or made accessible to third- party services or components, and 3DS SDK Vendors should consider the ramifications of third- party misuse or disclosure of such information.
T.2.3.2 Referring to the information produced in T.2.1.1, the tester shall examine vendor materials and other evidence, including source code, to determine all sensitive 3DS SDK data elements that are passed to third-party components or services.
Note: Validation of this requirement must also consider whether the 3DS SDK has any advertising, machine learning, data collection, logging, tracking, or security features which rely on third-party components, features, or …
Added
p. 34
T.2.6.1 Referencing the sensitive 3DS SDK data elements identified in T.2.1.1 and the protection features determined through other testing, the tester shall confirm that protections against extraction or determination are provided for each sensitive 3DS SDK data element.
Code injection, code reuse, local and remote hooks, reverse-engineering attacks and side- channel attacks (for example, cache side-channel or timing attack) are often used to execute code in the context of target process or to extract sensitive information from the target systems and applications. Various defense techniques exist to make attacks significantly harder, including dynamic or artificial software diversity, compression and randomization, etc. Properly implemented runtime application self-protection (RASP) and/or anti-debugging or anti-hooking techniques may be used to satisfy this requirement.
December 2018 Requirements Assessment Procedures Guidance T.2.6.2 The tester shall examine vendor materials and other evidence, including source code, and test the 3DS SDK to determine what sensitive 3DS SDK data elements may …
Code injection, code reuse, local and remote hooks, reverse-engineering attacks and side- channel attacks (for example, cache side-channel or timing attack) are often used to execute code in the context of target process or to extract sensitive information from the target systems and applications. Various defense techniques exist to make attacks significantly harder, including dynamic or artificial software diversity, compression and randomization, etc. Properly implemented runtime application self-protection (RASP) and/or anti-debugging or anti-hooking techniques may be used to satisfy this requirement.
December 2018 Requirements Assessment Procedures Guidance T.2.6.2 The tester shall examine vendor materials and other evidence, including source code, and test the 3DS SDK to determine what sensitive 3DS SDK data elements may …
Added
p. 36
T.2.8.1 The tester shall examine vendor materials and other evidence, including source code, and the findings in T.2.7.1 to confirm that URL requests made by the UI in HTML mode are handled within the 3DS SDK itself and are not passed to the device’s operating system or any other component (internal or external).
When the 3DS SDK makes API calls to the ACS that are rendered in HTML mode, those calls, as well as the responses, should not be available outside the 3DS SDK. HTML content generated by the ACS and displayed in HTML mode by the 3DS SDK should not reference content from other external sites. The intent of this requirement is to reduce the 3DS SDK’s attack profile and to protect against the inadvertent leakage of sensitive 3DS SDK data elements to unauthorized parties.
T.2.8.2 The tester shall examine vendor materials and other evidence, including source code, to determine what …
When the 3DS SDK makes API calls to the ACS that are rendered in HTML mode, those calls, as well as the responses, should not be available outside the 3DS SDK. HTML content generated by the ACS and displayed in HTML mode by the 3DS SDK should not reference content from other external sites. The intent of this requirement is to reduce the 3DS SDK’s attack profile and to protect against the inadvertent leakage of sensitive 3DS SDK data elements to unauthorized parties.
T.2.8.2 The tester shall examine vendor materials and other evidence, including source code, to determine what …
Added
p. 37
T.2.9.1 The tester shall examine vendor materials and other evidence to confirm that protections are provided by 3DS SDK to prevent the injection and execution of JavaScript into the UI (in HTML mode) or any other process outside of the 3DS SDK.
Often an attack will use JavaScript to manipulate the functionality of an application. To prevent such attacks, the injection and execution of JavaScript should be prohibited by properly initializing the HTML UI object.
T.2.9.2 The tester shall examine vendor materials and other evidence, including source code, to confirm that the source code does not contain any JavaScript parsing or execution code, even if disabled, and that the functionality provided in the source code for preventing the injection and execution JavaScript into the UI or other processes outside of the 3DS SDK aligns with the details provided in T.2.9.1.
T.2.9.3 The tester shall test the 3DS SDK by attempting to inject JavaScript …
Often an attack will use JavaScript to manipulate the functionality of an application. To prevent such attacks, the injection and execution of JavaScript should be prohibited by properly initializing the HTML UI object.
T.2.9.2 The tester shall examine vendor materials and other evidence, including source code, to confirm that the source code does not contain any JavaScript parsing or execution code, even if disabled, and that the functionality provided in the source code for preventing the injection and execution JavaScript into the UI or other processes outside of the 3DS SDK aligns with the details provided in T.2.9.1.
T.2.9.3 The tester shall test the 3DS SDK by attempting to inject JavaScript …
Added
p. 38
T.3.1.1 The tester shall examine vendor materials and other evidence, including source code, to determine what cryptographic algorithms and methods are used and all cryptographic keys used in the system that are relied upon for the security of the 3DS SDK.
To protect sensitive information, the 3DS SDK should utilize only recognized cryptographic implementations based on the EMV® 3-D Secure SDK Specification and industry-accepted standards. For a list of approved cryptographic algorithms and methods, please refer to the EMV® 3-D Secure SDK Specification and the EMV® 3-D Secure Protocol and Core Functions Specification.
T.3.1.2 The tester shall examine vendor materials and other evidence, including source code, to identify modes of operation available for each key, including determining how any additional values (such as initial vectors) may be generated for that mode of operation.
T.3.1.3 Where the mode of operation may be open to exploitation⎯e.g., relocation or data analysis attacks on Electronic Code Book …
To protect sensitive information, the 3DS SDK should utilize only recognized cryptographic implementations based on the EMV® 3-D Secure SDK Specification and industry-accepted standards. For a list of approved cryptographic algorithms and methods, please refer to the EMV® 3-D Secure SDK Specification and the EMV® 3-D Secure Protocol and Core Functions Specification.
T.3.1.2 The tester shall examine vendor materials and other evidence, including source code, to identify modes of operation available for each key, including determining how any additional values (such as initial vectors) may be generated for that mode of operation.
T.3.1.3 Where the mode of operation may be open to exploitation⎯e.g., relocation or data analysis attacks on Electronic Code Book …
Added
p. 44
T.4.1.1 The tester shall examine vendor materials and other evidence to confirm that a process is implemented by the 3DS SDK Vendor for identifying, documenting, and analyzing threats, vectors, and attack scenarios applicable to the 3DS SDK.
The design of the 3DS SDK should be evaluated to identify common attack scenarios and/or potential attack vectors applicable to the 3DS SDK, and the results of that analysis documented. Documentation should describe the various aspects of the code that could be attacked (including things that frameworks and libraries do on behalf of the 3DS SDK), the difficulty in mounting a successful attack, how widely the program will be distributed, what mitigation techniques are used (for example, how the security functionality of the operating system is leveraged), and identify or define a methodology for measuring the likelihood and impact of an exploit.
Those individuals making the residual risk determinations should be independent of those individuals …
The design of the 3DS SDK should be evaluated to identify common attack scenarios and/or potential attack vectors applicable to the 3DS SDK, and the results of that analysis documented. Documentation should describe the various aspects of the code that could be attacked (including things that frameworks and libraries do on behalf of the 3DS SDK), the difficulty in mounting a successful attack, how widely the program will be distributed, what mitigation techniques are used (for example, how the security functionality of the operating system is leveraged), and identify or define a methodology for measuring the likelihood and impact of an exploit.
Those individuals making the residual risk determinations should be independent of those individuals …
Added
p. 45
T.4.2.1 The tester shall examine vendor materials and other evidence to confirm that there are clear, documented vendor policy and procedure statements regarding the remediation of identified vulnerabilities in the 3DS SDK. These statements must tie together with the identification and ranking process covered under Requirement 4.1, “Threat and Vulnerability Analysis.” Once threats, attack vectors, and attack scenarios are identified, they should be mitigated. 3DS SDK Vendors should define and implement mechanisms to protect the 3DS SDK from those risks and reduce the likelihood and impact of their exploitation. Any known risks that are not addressed or do not reduce the likelihood and impact of the exploitation of those risks to a reasonable level should be justified. T.4.2.2 The tester shall determine whether the vendor explicitly allows for potential threats to remain un- addressed and, if so, the tester shall confirm that ranking/categorization levels are considered acceptable for this (as …
Added
p. 46
T.4.3.1 The tester shall examine vendor materials and other evidence to confirm that the vendor has written policy and procedures requiring internal security review and testing that accounts for the entire 3DS SDK code base, including detecting vulnerabilities in code developed by the vendor, as well as vulnerabilities in third-party, open source, or shared components or libraries.
Software security testing is a fundamental practice to ensure that software cannot be exploited through known vulnerabilities or common attacker techniques.
Performing security testing throughout the development process and during development of future updates using a variety of testing techniques mitigates the risk that vulnerabilities may be introduced during updates. Testing tools and techniques may include manual code reviews, static code analysis, dynamic code analysis, software composition analysis, fuzz testing, penetration testing, etc., where appropriate. Organizations are responsible for understanding common vulnerabilities associated with the technologies they are using and for implementing testing practices specific …
Software security testing is a fundamental practice to ensure that software cannot be exploited through known vulnerabilities or common attacker techniques.
Performing security testing throughout the development process and during development of future updates using a variety of testing techniques mitigates the risk that vulnerabilities may be introduced during updates. Testing tools and techniques may include manual code reviews, static code analysis, dynamic code analysis, software composition analysis, fuzz testing, penetration testing, etc., where appropriate. Organizations are responsible for understanding common vulnerabilities associated with the technologies they are using and for implementing testing practices specific …
Added
p. 50
T.4.5.1 The tester shall examine vendor materials and other evidence to confirm that the 3DS SDK does not accept updates during 3DS transaction processing.
Updates to 3DS SDK functionality during 3DS transaction processing should not be permitted to ensure the integrity of those transactions. 3DS SDK Vendors should implement functionality within the 3DS SDK to preserve the integrity of the 3DS SDK code during 3DS transaction processing, while still enabling the 3DS Requestor App to push automatic updates to the consumer device when necessary.
T.4.5.2 The tester shall examine vendor materials and other evidence, including source code, to confirm that methods are implemented to prevent the SDK from being updated during 3DS transaction processing.
T.4.5.3 Where the operating systems and platforms targeted by the 3DS SDK do not allow for the applications to prevent or delay updates themselves, the tester shall confirm that other protections have been put in place by the vendor …
Updates to 3DS SDK functionality during 3DS transaction processing should not be permitted to ensure the integrity of those transactions. 3DS SDK Vendors should implement functionality within the 3DS SDK to preserve the integrity of the 3DS SDK code during 3DS transaction processing, while still enabling the 3DS Requestor App to push automatic updates to the consumer device when necessary.
T.4.5.2 The tester shall examine vendor materials and other evidence, including source code, to confirm that methods are implemented to prevent the SDK from being updated during 3DS transaction processing.
T.4.5.3 Where the operating systems and platforms targeted by the 3DS SDK do not allow for the applications to prevent or delay updates themselves, the tester shall confirm that other protections have been put in place by the vendor …
Added
p. 51
T.5.1.1 The tester shall examine vendor materials and other evidence to confirm that the 3DS SDK Vendor maintains detailed security guidance for the secure implementation of the 3DS SDK, as determined in previous testing within this standard, and that such guidance contains all references required for a secure implementation and configuration of the 3DS SDK.
Detailed implementation and security guidance for stakeholders helps to direct stakeholders and integrators during the implementation of the 3DS SDK into a Requestor App. Without detailed vendor security guidance, appropriate configuration and use of the 3DS SDK could be overlooked and unknowingly left out of the 3DS SDK security controls, thus leaving the device vulnerable to compromise. T.5.1.2 The tester shall confirm that vendor security guidance is made available to all software developers who will be integrating the 3DS SDK into their applications. The tester shall also confirm there are no specific legal, distribution, or other …
Detailed implementation and security guidance for stakeholders helps to direct stakeholders and integrators during the implementation of the 3DS SDK into a Requestor App. Without detailed vendor security guidance, appropriate configuration and use of the 3DS SDK could be overlooked and unknowingly left out of the 3DS SDK security controls, thus leaving the device vulnerable to compromise. T.5.1.2 The tester shall confirm that vendor security guidance is made available to all software developers who will be integrating the 3DS SDK into their applications. The tester shall also confirm there are no specific legal, distribution, or other …
Modified
p. 1
Payment Card Industry 3-D Secure (PCI 3DS) Security Requirements and Assessment Procedures for EMV® 3-D Secure SDK Version 1.0
Payment Card Industry 3-D Secure (PCI 3DS) Security Requirements and Assessment Procedures for EMV® 3-D Secure SDK Version 1.1
Removed
p. 7
Maintains the PCI 3DS SDK 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 SDK Security Standard Maintains the list of approved 3DS SDK versions and qualified 3DS SDK 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:
Modified
p. 7
• EMV® 3-D Secure SDK Specification (www.emvco.com) Roles and Responsibilities Several stakeholders are involved in maintaining and managing PCI Standards. The following describes the high-level roles and responsibilities as they relate to the PCI 3DS SDK Security Standard:
Modified
p. 7
PCI SSC maintains various PCI Standards, supporting programs and related documentation. In relation to the PCI 3DS SDK Security Standard, PCI SSC:
PCI SSC maintains various PCI Standards, supporting programs, and related documentation. In relation to the PCI 3DS SDK Security Standard, PCI SSC:
Modified
p. 7 → 8
• Fines or penalties for non-compliance 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.
Removed
p. 9
3DS SDK Security Requirements and Assessment Procedures
• The security requirements and assessment procedures applicable specifically to a 3DS SDK version. The following topics are covered under this section: o SDK Integrity Protection o Sensitive Information Protection o Use of Cryptography 3DS SDK Vendor Requirements and Assessment Procedures
• The security requirements and assessment procedures that apply specifically to a 3DS SDK Vendor. The following topics are covered under this section: o Risk and Vulnerability Management o Stakeholder Guidance Requirements Architecture The Security Requirements and Assessment Procedures defined within this standard are presented in the following format:
Requirements
• Specific security controls or activities that must be implemented by the 3DS SDK or 3DS SDK Vendor (in addition to any other activities specified by the SDK Vendor) to support the overarching security objective Assessment Procedures
• Describe the expected testing activities to be performed by the Assessor to validate whether an …
• The security requirements and assessment procedures applicable specifically to a 3DS SDK version. The following topics are covered under this section: o SDK Integrity Protection o Sensitive Information Protection o Use of Cryptography 3DS SDK Vendor Requirements and Assessment Procedures
• The security requirements and assessment procedures that apply specifically to a 3DS SDK Vendor. The following topics are covered under this section: o Risk and Vulnerability Management o Stakeholder Guidance Requirements Architecture The Security Requirements and Assessment Procedures defined within this standard are presented in the following format:
Requirements
• Specific security controls or activities that must be implemented by the 3DS SDK or 3DS SDK Vendor (in addition to any other activities specified by the SDK Vendor) to support the overarching security objective Assessment Procedures
• Describe the expected testing activities to be performed by the Assessor to validate whether an …
Modified
p. 9 → 10
• Identifies the high-level security objective that the 3DS SDK or 3DS SDK Vendor is required to meet. Security objectives are broadly stated to enable 3DS SDK Vendor flexibility in determining the best methods to achieve the stated security objective. However, it is expected that the 3DS SDK Vendor produces clear and unambiguous evidence to illustrate that the chosen methods are appropriate,
Security Objective
• Identifies the high-level security objective that the 3DS SDK or 3DS SDK Vendor is required to meet. Security objectives are broadly stated to enable 3DS SDK Vendor flexibility in determining the best methods to achieve the stated security objective. However, it is expected that the 3DS SDK Vendor produces clear and unambiguous evidence to illustrate that the chosen methods are appropriate, sufficient, and properly implemented to satisfy the security objective. Below the security objective, additional information has been …
• Identifies the high-level security objective that the 3DS SDK or 3DS SDK Vendor is required to meet. Security objectives are broadly stated to enable 3DS SDK Vendor flexibility in determining the best methods to achieve the stated security objective. However, it is expected that the 3DS SDK Vendor produces clear and unambiguous evidence to illustrate that the chosen methods are appropriate, sufficient, and properly implemented to satisfy the security objective. Below the security objective, additional information has been …
Removed
p. 11
Testing Methods During the 3DS SDK Assessment, the Assessor employs a number of different testing methods to validate conformity with the stated 3DS SDK security objectives and associated requirements. Those testing methods are described below:
Static Analysis
• Static analysis methods include the review of static documents or code. Examples of static analysis methods are documentation reviews, code reviews, default configuration reviews, etc. Static analysis methods may also include automated analysis methods such as the use of automated static code analysis or software composition analysis tools. It shall be up to the Assessor to determine the specific static analysis techniques and tools to use to validate that the 3DS SDK meets a specific 3DS SDK requirement.
Static Analysis
• Static analysis methods include the review of static documents or code. Examples of static analysis methods are documentation reviews, code reviews, default configuration reviews, etc. Static analysis methods may also include automated analysis methods such as the use of automated static code analysis or software composition analysis tools. It shall be up to the Assessor to determine the specific static analysis techniques and tools to use to validate that the 3DS SDK meets a specific 3DS SDK requirement.
Modified
p. 11 → 12
1. The 3DS SDK Vendor submits its SDK to EMVCo for 3DS SDK Functional Testing, completes the testing and receives a Letter of Approval from EMVCo.
1. The 3DS SDK Vendor submits its 3DS SDK to EMVCo for 3DS SDK Functional Testing, completes the testing and receives a Letter of Approval from EMVCo.
Modified
p. 11 → 12
2. The 3DS SDK Vendor contacts the Payment Brands to determine whether the SDK is eligible or required to validate compliance with this standard.
2. The 3DS SDK Vendor contacts the payment brands to determine whether the 3DS SDK is eligible or required to validate compliance with this standard.
Modified
p. 11 → 12
3. The 3DS Vendor contracts with an Assessor to perform the PCI 3DS SDK Security Assessment and provides the Assessor its EMVCo Letter of Approval.
3. The 3DS SDK Vendor contracts with a PCI 3DS SDK Lab to perform the PCI 3DS SDK Security Assessment and provides the PCI 3DS SDK Lab its EMVCo Letter of Approval.
Modified
p. 11 → 12
4. The Assessor performs the PCI 3DS SDK Security Assessment following the Assessment Procedures for each security objective and associated requirements specified within this standard.
4. The PCI 3DS SDK Lab performs the PCI 3DS SDK Security Assessment following the Assessment Procedures for each security objective and associated requirements specified within this standard.
Modified
p. 11 → 12
5. The Assessor completes the 3DS SDK Report on Validation (ROV) and Attestation of Validation (AOV) in accordance with applicable PCI templates, guidance and instructions.
5. The PCI 3DS SDK Lab completes the PCI 3DS SDK Report on Validation (ROV) and Attestation of Validation (AOV) in accordance with applicable PCI templates, guidance, and instructions.
Modified
p. 11 → 12
6. The Assessor submits the ROV and AOV, along with any other requested documentation, to both the PCI SSC and applicable payment brand(s).
6. The PCI 3DS SDK Lab submits the ROV and AOV, along with any other requested documentation, to both the PCI SSC and applicable payment brand(s).
Modified
p. 11 → 12
7. If required, remediation activities are performed by the 3DS SDK Vendor to address security objectives or requirements that are not in place, or security controls that were not sufficiently evidenced. The Assessor will then perform follow-up testing and provide PCI SSC and the applicable payment brand(s) with an updated ROV.
7. If required, remediation activities are performed by the 3DS SDK Vendor to address security objectives or requirements that are not in place, or security controls that were not sufficiently evidenced. The PCI 3DS SDK Lab will then perform follow-up testing and provide PCI SSC and the applicable payment brand(s) with an updated ROV.
Removed
p. 12
Interviews and Observations
• For security objectives and requirements that do not apply to a particular 3DS SDK, but rather the process employed by the 3DS SDK Vendor to develop and maintain the 3DS SDK, it may be necessary to perform interviews and observe operational procedures to validate that the 3DS SDK Vendor is meeting the security objectives and corresponding requirements, rather than performing tests against the 3DS SDK. Assessors shall determine the appropriate individuals to interview and the number of interviews or observations to perform to confirm that a security objective and corresponding requirements are being met by the 3DS SDK Vendor.
Required Vendor Materials To support validation that the 3DS SDK and 3DS SDK Vendor meet the security objectives and requirements defined within this document, the 3DS SDK Vendor must provide sufficient evidence to enable an Assessor to validate the requirements. Such evidence may be in the form of …
• For security objectives and requirements that do not apply to a particular 3DS SDK, but rather the process employed by the 3DS SDK Vendor to develop and maintain the 3DS SDK, it may be necessary to perform interviews and observe operational procedures to validate that the 3DS SDK Vendor is meeting the security objectives and corresponding requirements, rather than performing tests against the 3DS SDK. Assessors shall determine the appropriate individuals to interview and the number of interviews or observations to perform to confirm that a security objective and corresponding requirements are being met by the 3DS SDK Vendor.
Required Vendor Materials To support validation that the 3DS SDK and 3DS SDK Vendor meet the security objectives and requirements defined within this document, the 3DS SDK Vendor must provide sufficient evidence to enable an Assessor to validate the requirements. Such evidence may be in the form of …
Modified
p. 12 → 14
Additionally, the 3DS SDK Vendor must provide full access to (1) all un-obfuscated source code and (2) all obfuscated code for all internally developed functional as well as bespoke or custom functionality developed by third parties. Failure to provide adequate access to source code shall be considered a failure to meet applicable security objectives and requirements.
Additionally, the 3DS SDK Vendor must provide full access to (1) all un-obfuscated source code and (2) all obfuscated code for all internally developed functionality as well as bespoke or custom functionality developed by third parties. Failure to provide adequate access to source code shall be considered a failure to meet applicable security objectives and requirements.
Modified
p. 12 → 14
Exceptions In some cases, it may be impossible for a 3DS SDK or 3DS SDK Vendor to meet a specific requirement as stated. In such cases, the 3DS SDK Vendor must provide clear and unambiguous justification for why the requirement cannot be met. The 3DS SDK Vendor must also provide evidence to clearly illustrate that the corresponding security objective is still being met and that other functionality or methods are employed to provide similar assurance to that provided by the …
Exceptions In some cases, it may be impossible for a 3DS SDK or 3DS SDK Vendor to meet a specific requirement as stated. In such cases, the 3DS SDK Vendor must provide clear and unambiguous justification for why the requirement cannot be met. In order to be considered compliant to the requirements within this standard, the 3DS SDK Vendor must also provide evidence to clearly illustrate that the corresponding security objective is still being met and that other functionality or …
Removed
p. 13
Test Harness To facilitate testing the 3DS SDK in accordance with the Assessment Procedures contained in this standard, the 3DS SDK Vendor may be asked to provide a test harness to verify the 3DS SDK’s compliance to the applicable security objectives and requirements. A test harness is considered to be special test functionality that is either separate or absent from production-level code. A test harness may be developed and provided by a 3DS SDK Vendor for purpose of testing its 3DS SDK application or developed by an Assessor to have a generic 3DS SDK testing platform. The test harness must rely on as much underlying intended production-level functionality as possible. The test harness is only to serve the purpose of providing a test framework that allows for the 3DS SDK functionality to be exercised outside of a production-level deployment environment (such as within a 3DS Requestor App) to verify the …
Modified
p. 13 → 15
Component Integration If the 3DS SDK leverages security services from components defined within the 3DS SDK architecture that reside outside the formal technical boundary of the 3DS SDK (for example, at the application, OS or device level), then those security services will also require validation. 3DS SDK Vendors who utilize these services are responsible for obtaining the necessary evidence and materials to support validation of these components. For example, if the 3DS SDK utilizes a random function provided by the …
Component Integration If the 3DS SDK leverages security services from components defined within the 3DS SDK architecture that reside outside the formal technical boundary of the 3DS SDK (for example, at the application, OS, or device level), those security services will also require validation. 3DS SDK Vendors that utilize these services are responsible for obtaining the necessary evidence and materials to support validation of these components. For example, if the 3DS SDK utilizes a random-number generating function provided by the …