Payment Card Industry 3-D Secure (PCI 3DS)

Threats, attack scenarios and/or attack vectors applicable to the 3DS SDK are known, analyzed, documented, and described in terms of their exploitability, impact, and residual risk.
Assessment Procedures:
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.

T.4.1.2 The tester shall confirm that the process required is sufficiently detailed for it to be repeatable across different personnel and locations.

T.4.1.3 The tester shall confirm that the process clearly outlines the individuals or teams responsible for determining and investigating new threats. It is acceptable if a group or job title is referenced, but the tester must ensure that there is a clear line of responsibility for this item.

T.4.1.4 The tester shall interview a sample of the personnel identified in T.4.1.3 and confirm that they are aware of the policy and procedure requirements for the analysis of new threats. The tester shall also examine vendor materials and other evidence produced by these interviewees to confirm that defined processes are being followed.

T.4.1.5 The tester shall confirm from the evidence identified in T.4.1.1 that methods are defined and used for categorizing and ranking threats. The tester shall confirm that a documented methodology exists, which can be reasonably assumed to produce the same results each time it is enacted (assuming the same threat and threat environment). It is not a requirement that a public ranking method is used; it is acceptable for the vendor to implement its own method if this provides sufficient assurance and repeatability.

T.4.1.6 The tester shall interview a sample of the personnel identified in T.4.1.3 and confirm that they understand and can apply the categorizing and ranking methodology employed by the vendor.

T.4.1.7 For a sample of threats identified in T.4.1.4, the tester shall obtain the categorizing and ranking results for the sample and confirm that they align with the documented process.
Guidance:
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 responsible for the development of the 3DS SDK. The need for independence is to ensure that only disinterested individuals make assessments and not individuals with objectives that may be in conflict with security concerns.

Software security testing is an integral part of the 3DS SDK’s life cycle and is performed throughout the software life cycle to confirm that risks and attack scenarios are addressed, defensive mechanisms are implemented properly, and the propagation of design flaws or vulnerabilities into production code is prevented.
Assessment Procedures:
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.

T.4.3.2 The tester shall confirm that the process for testing of internal code involves both manual and automated means.

T.4.3.3 The tester shall confirm that the process clearly outlines the individuals or teams responsible for this testing. It is acceptable if a group or job title is referenced, but the tester must ensure that there is a clear line of responsibility for this item.
T.4.3.4 The tester shall confirm that the process includes ensuring that the processes for identification and mitigation of threats are correctly performed prior to the release of any production code.

T.4.3.5 The tester shall confirm that the process includes ensuring that any test, debug, or other code that is intended only for internal use is removed prior to release to production.

The 3DS SDK and its components are monitored for vulnerabilities. In addition to their own processes, 3DS SDK Vendors provide mechanisms to enable third parties to report vulnerabilities. Information on identified vulnerabilities is maintained. Vulnerabilities are addressed and software updates are made available to all stakeholders in a timely manner. All exceptions are documented and justified. The reoccurrence of previously addressed vulnerabilities is tracked and minimized.
Assessment Procedures:
T.4.4.1 The tester shall examine vendor materials and other evidence to confirm that there is a documented release policy for the 3DS SDK, and that this ensures the processes outlined in previous 4.x requirements are followed before the SDK is released to production.

T.4.4.2 The tester shall confirm that the release policy clearly outlines the acceptable period of time after which patches are made available for the different rankings of vulnerabilities as defined in previous 4.x requirements.

T.4.4.3 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that the vendor has an explicit procedure in place for the acceptance and processing of new vulnerabilities through external communications. Although not mandated, this requirement can be met by a properly administered bug bounty program. It does require that reported vulnerabilities are formally registered and processed according to the documented process previously assessed in the 4.x requirements.
T.4.4.4 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that there is a public-facing procedure for the reporting of vulnerabilities in the 3DS SDK. This procedure must implement methods to ensure the confidentiality of the vulnerability as it is reported. For example, a process that requires the reporting of a vulnerability to a shared “info@[company]” e-mail address, without additional encryption, would be non-compliant to this requirement.

T.4.4.5 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that, where any such third-party vulnerability reports have been accepted and processed, the process appears correct⎯e.g., through validation of any special e-mail address or portal that is to be used for public vulnerability reporting.

T.4.4.6 The tester shall examine vendor materials and other evidence to confirm that there is a process to validate that new releases have not re-introduced older vulnerabilities. This may involve the process being updated to specifically check for vulnerabilities as they are discovered, or ensuring that older and un-patched software components and libraries are removed from the development environment as they are updated.
T.4.4.7 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that the process as documented is understood and followed. Where previously sampled vulnerabilities identified the need for an update to internal libraries or components, the tester shall confirm through these interviews and evidence that these have been correctly updated and the older, unpatched versions have been removed.

T.4.4.8 Where not covered under previous requirements, the tester shall examine vendor materials and other evidence, and interview personnel to confirm that any decisions not to address vulnerabilities are reasonably justified and documented.
Guidance:
The identification and management of vulnerabilities in the 3DS SDK and its components is not a one-time exercise. New vulnerabilities can be introduced at any time; therefore, it is imperative that the 3DS SDK is continuously monitored for vulnerabilities and appropriate action is taken when vulnerabilities are identified. 3DS SDK Vendors should have processes in place to identify vulnerabilities in the 3DS SDK and its components, including vulnerabilities identified by third parties, and resolve those vulnerabilities in a timely manner such that the integrity, confidentiality, and the overall confidence in the security of the 3DS SDK are maintained. It is understood that some vulnerabilities may not pose a risk to the application software or environment. However, regardless of the criticality or the impact of the vulnerability, it is important that all vulnerabilities are identified, their risk is known and that there is a process that recognizes, evaluates and (if necessary), assumes the risk. The process should include management review and approval.

The 3DS SDK Vendor does not enable updates or changes to 3DS SDK functionality to be pushed to the 3DS SDK during 3DS transaction processing.
Assessment Procedures:
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.

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 to mitigate interruption of the 3DS transaction process during updates.

T.4.5.4 The tester shall test the 3DS SDK by performing a series of 3DS transactions within a test host/harness that allows for updates to be pushed to the 3DS SDK, to confirm that the 3DS SDK does not accept updates during the transaction processing, and that the outcome of this testing aligns with the vendor materials and evidence provided in T.4.5.1 through T.4.5.3.
Guidance:
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.

The 3DS SDK Vendor creates, maintains, and makes available guidance to all stakeholders on the appropriate and secure implementation, configuration, and use of the 3DS SDK as well as all APIs provided by the 3DS SDK.
Assessment Procedures:
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.
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 requirements that appear to prevent the distribution of the security guidance to developers who require this guidance⎯e.g., a data classification that prevents the document from being distributed to other entities.

Upon any changes and/or updates to the 3DS SDK, the 3DS SDK Vendor provides all stakeholders with a clear and unambiguous indication that updates were made, and makes available detailed information regarding the specific changes made, the functionalities that are affected, and the potential security impacts associated with those changes (for example, release notes). The relationship between the updated software and detailed information about the updates should be clear.
Assessment Procedures:
T.5.2.1 The tester shall examine vendor materials and other evidence to confirm that procedures exist to clearly communicate changes to the 3DS SDK security guidance to relevant stakeholders. This process must require the initiation of contact regarding the change from the 3DS SDK Vendor; it is not considered acceptable to post changes on a website or other location that requires the stakeholder to initiate a process to check whether changes have been made. A process involving e-mails to the stakeholders to inform them of updates is considered an acceptable example of initiation.
T.5.2.2 The tester shall examine vendor materials and other evidence to confirm that the procedures for updating the security guidance requires or includes the production of details indicating exactly what has changed in this new version. This may be in the form of release notes or a marked-up version of the document. A full trace of changes must be possible from the first release of the security guidance through the most current version.

T.5.2.3 The tester shall confirm that the change notice also includes any impacts to the functionality and/or security of the 3DS SDK, as applicable. This should include any new requirements that are conveyed to the application integrating the 3DS SDK⎯e.g., new APIs that must be called, or changes to the way in which entropy must be collected and passed to the 3DS SDK.

T.5.2.4 The tester shall confirm that the process for informing and distributing the security guidance also ensures the distribution of the change details.
Guidance:
It should be made clear to stakeholders when and to what extent changes are made to the 3DS SDK. Indicators of changes may include the advancement of version numbers or some other indicator such that any 3DS SDK stakeholders can easily associate a software release with the changes included in that release. Without change details or release notes, the impact of 3DS SDK changes⎯such as changes/updates and security patches⎯might not be fully realized and could have unintended consequences. The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.

The 3DS SDK Vendor updates security guidance whenever changes warrant updates. The criteria for determining whether updates are necessary are clearly defined by the vendor and are reasonable. At a minimum, security guidance is reviewed at least annually, and updates made whenever new or changes to functionality, security features, APIs, or configurable settings are introduced.
Assessment Procedures:
T.5.3.1 The tester shall examine vendor materials and other evidence to confirm that the vendor has a documented policy and procedure to identify when updates to the security guidance are necessary.

T.5.3.2 The tester shall examine vendor materials and other evidence to confirm that the vendor has a documented policy and procedure requiring regular reviews of the security guidance. At a minimum, there must be a procedure to review the 3DS SDK and confirm any updates required at least annually.
T.5.3.3 Where possible, the tester shall obtain previous versions of the security guidance and confirm that they have been updated and published in accordance with the vendor policy and procedure.

T.5.3.4 The tester shall interview a sample of the personnel responsible for updating the security guidance to confirm that they understand the policy and procedures for this, as well as their responsibility for maintaining and updating this document.

T.5.3.5 The tester shall confirm that the vendor policy and procedures require updates to the security guidance when new or changes to functionality, security features, APIs or configurable settings are introduced.

T.5.3.6 The tester shall interview a sample of the personnel responsible for updating the security guidance to confirm that they understand that the security guidance must be updated when new or changes to functionality, security features, APIs or configurable settings are introduced.
Guidance:
It is imperative that vendor security guidance reflect the current functionality and configuration options available in the 3DS SDK. Otherwise, new features and options might be misconfigured by the implementer. If changes to the 3DS SDK do not warrant updates to security guidance, then the justification for not making updates to implementation guidance should be reasonable. The criteria for making such determinations should also be documented to ensure consistency in application.