Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

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

Стандарт

Requirement 1

Для проведения оценки соответствия по документу войдите в систему.

Список требований

3DS SDK Security Requirements and Assessment Procedures
Security Objective 1: Protect the Integrity of the 3DS SDK
To protect the sensitive information handled by the 3DS SDK and to facilitate secure and trustworthy 3DS SDK transactions, the 3DS SDK must implement measures to defend itself in what must be assumed to be a hostile environment (such as in a mobile application operating on a consumer mobile device). Some of the key risks associated with mobile applications and components include threats associated with a “rooted” or “jailbroken” device and threats from other applications operating within the same environment (and with access to shared resources). Appropriate detective and protective mechanisms must be implemented to ensure that the integrity of the 3DS SDK and sensitive 3DS SDK data elements is maintained. Refer to Table 2, “Sensitive 3DS SDK Data Elements,” in the “Scope of Security Requirements” section of this document for more information on which specific 3DS SDK data elements require protection from unauthorized modification.
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.
Requirements:
1.1 Security Checks
The 3DS SDK provides functionality to conduct device security checks (at a minimum, during initialization) and makes the results of those checks available to the 3DS Requestor App upon request as warning messages. Device security checks include, at minimum, determining whether:
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
Assessment Procedures:
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.
T.1.1.2 Based on the information provided in T.1.1.1, the tester shall examine vendor evidence, including source code, to determine what methods are used to perform the environment validation, and what they are designed to detect. These checks must include the below, at a minimum:
Checking whether the device is rooted or jailbroken
Determining whether an emulator is being used to run the 3DS SDK
Validation of the integrity of the 3DS SDK, to determine whether it has been tampered with
Determining whether a debugger is attached or the device running the 3DS SDK is in a “developer” or “debug” mode
T.1.1.3 The tester shall also determine the platforms, operating systems, and specific versions of these supported by the 3DS SDK.
T.1.1.4 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK on phones that have been rooted or
jailbroken, and observe the response of the SDK to confirm that the 3DS SDK detects that the phone has been rooted or jailbroken. This test must include use of devices from at least two different manufacturers where the 3DS SDK or operating system supports it.
T.1.1.5 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK within an environment where raised privileges have been attained (i.e., the system has been rooted or jailbroken) with at least two readily available rooting or jailbreaking tools to confirm that the 3DS SDK detects such elevated privileges.
T.1.1.6 The tester shall test the 3DS SDK by attempting to execute the SDK within at least two different emulators and observe the response of the 3DS SDK to confirm that the 3DS SDK detects when an emulator is being used to run the 3DS SDK.
T.1.1.7 The tester shall test the 3DS SDK by attempting to modify the 3DS SDK (for example: by modifying initialization files, runtime files, or cryptographic keys) and then execute this modified version to confirm the 3DS SDK detects when its code or execution has been tampered with. The modification must be specifically designed to attempt to bypass the integrity checking of the 3DS SDK.
T.1.1.8 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK in a system that allows for advanced control or insight into the execution of applications⎯e.g., such as running it in debug or developer mode to confirm the 3DS SDK detects this behavior.
Guidance:
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 transaction. The security checks are performed during the initialization of the 3DS SDK and the results are passed to the ACS via the 3DS Requestor App along with other device - specific information. For more information on the interactions between the 3DS SDK, the Requestor App, and the ACS, refer to the EMV® 3-D Secure SDK Specification. Possible indicators of compromise include the existence of specific executables or other residual files and artifacts created during the
rooting or jailbreaking process. Reflection can be used on Android and iOS to calculate a checksum on the 3DS SDK.
Requirements:
1.2 Installed from Approved Source
The 3DS SDK conducts checks (at minimum, during initialization) to determine whether the embedding Requestor App was installed from a trusted app store (for example: Google Play, iTunes, and Microsoft App store, etc.), and makes that information available to the Access Control Server (ACS).
Assessment Procedures:
T.1.2.1 The tester shall examine vendor materials and other evidence to confirm features are provided by the 3DS SDK to check that the Requestor App was installed by a trusted app store. This shall include confirming that action is taken by the 3DS SDK if the Requestor App fails this test.
T.1.2.2 Based on the information provided in T.1.2.1, the tester shall examine vendor materials and other evidence, including source code, to confirm the 3DS SDK verifies the Requestor App was not sideloaded or otherwise installed outside of the primary application distribution store of the operating system being used.
T.1.2.3 The tester shall test the 3DS SDK by attempting to sideload an application and have it interface to the 3DS SDK as required by the 3DS SDK documentation for a valid Requestor Application. The tester shall observe the response of the SDK to confirm that normal 3DS transaction processing is not permitted/performed by the 3DS SDK.
T.1.2.4 The tester shall examine publicly available information to determine what methods, if any, may exist to bypass the checks performed. Using this information, the tester shall test the 3DS SDK by attempting to perform such bypass using a sideloaded application to confirm that normal 3DS transaction processing is not permitted/performed by the 3DS SDK.
Guidance:
While device and operating system vendors have certain control over the applications installed on the mobile device, the end users always have the option to install (also referred to as “sideloading”) applications from non-vetted sources (for example, via USB or SD Card, received as an e-mail attachment or downloaded from a file- sharing site). Applications sideloaded from untrusted resources are often packed with malware and request (from the end user) elevated privileges, allowing it to access sensitive information stored on the device or hijack end-user interaction with legitimate resources. To ensure that the Requestor App was not sideloaded, the 3DS SDK should perform checks (based on the operating system) to determine whether the application was installed from a trusted app store. Checks may include interrogating the device OS for installed application packages (for example, using “PackageManager” class on Android) or validating the app signature at run time.
Requirements:
1.3 Run-Time Integrity
The 3DS SDK performs run-time integrity checks to detect when its functionality has been modified.
Note: These checks shall go beyond the integrity checks performed during initialization as part of Requirement 1.1, “Security Checks.”
Assessment Procedures:
T.1.3.1 The tester shall examine vendor materials and other evidence to confirm features are provided by the SDK to perform run-time integrity checks during execution, to verify that the security of the SDK cannot be compromised after the initialization phase by tampering with the execution code or parameters.
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.
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 SDK to the calling application.
T.1.3.4 The tester shall determine where data values are stored (even temporarily) outside of the 3DS SDK code itself, or the memory space of the 3DS SDK provided by the device operating system during execution⎯e.g., written to the device file system, stored in system functions such as a “key store,” etc.—and confirm that features or methods are applied to protect these values.
T.1.3.5 The tester shall determine where other code, data, script, or features of the application are not included in the integrity check, and confirm that having these features out of scope does not affect the security of the SDK or 3DS transaction process.
T.1.3.6 Based on the information provided in T.1.3.1 through T.1.3.5, the tester shall examine vendor materials and other evidence, including source code, to confirm that the claimed features are correctly implemented.
T.1.3.7 The tester shall test the 3DS SDK by attempting to modify the 3DS SDK prior to and during execution. Testing shall include attempts to modify the 3DS SDK code itself or values used by the code (for example, modifying configuration files, the runtime code, encryption keys, or keys or parameters stored temporarily in files or live memory during execution that could compromise the secure execution of the SDK.) The tester shall then observe the response of the 3DS SDK to confirm these modifications are detected. The changes must be made in such a way to attempt to avoid detection. Where the 3DS SDK code may be present in different locations (such as in the form of a pre-compiled file, as well as an ahead-of- time compilation that is ready to execute) the tester shall attempt to modify the 3DS SDK code in each location.
T.1.3.8 The tester shall test the 3DS SDK by attempting to execute the 3DS SDK within an execution environment that allows for dynamic modification⎯such as a system that implements a hooking framework, a virtual machine (VM), or a device running a customized operating system to allow for such attacks to confirm that such modification attempts are detected by the 3DS SDK.
Guidance:
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.
Requirements:
1.4 Protection against Reverse Engineering
The 3DS SDK binaries are protected from reverse engineering.
Assessment Procedures:
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.
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 all locations where functions provided by the 3DS SDK are executed. This will include the main processing environment of the device, but may also include other local execution environments (such as a Trusted Execution Environment or embedded security processor).
T.1.4.4 Where cryptography is implemented for the purposes of obfuscation and anti-tamper, the tester shall determine the locations and data protected by those methods. The tester shall also determine what protection is provided by the cryptography (confidentiality, integrity, or both) and what algorithms and modes of operation are used. The tester shall confirm that cryptography meets PCI requirements for strong cryptography, including applicable cryptography requirements in this standard, and that all keys used for these cryptographic operations are protected.
T.1.4.5 Where protections are provided (partially or wholly) through code obfuscation, the tester shall perform the following:
T.1.4.5.1 Examine vendor materials and other evidence, including application installation files where the protection methods have been applied, and compare these files to files where protections have not yet been applied to confirm the validity of the vendor attestations and documentation regarding the protection methods implemented.
Note: This test may require the 3DS SDK Vendor to provide both obfuscated and un-obfuscated binaries or source code to the 3DS SDK Lab to validate this requirement.
T.1.4.5.2 Determine the comparative file sizes between unprotected and protected application samples, as well as the relative compression ratio of each file type when general purpose compression functions are applied to confirm that such analysis does not disclose any sensitive information about the 3DS SDK.
T.1.4.5.3 Examine vendor materials and other evidence, and test the software by attempting to reverse engineer the code or extract details of the code execution (e.g., through extraction of ASCII strings, functional linking/interface tables such as PLT/GOT, etc.) to confirm such attempts do not result in the disclosure of any sensitive information about the 3DS SDK.
T.1.4.5.4 Analyze any areas of non-traditional execution where the obfuscation relies on virtualized/interpreted commands, non-deterministic operations, or other such techniques to confirm that the exploitation of such techniques does not result in the disclosure of any sensitive information about the 3DS SDK.
T.1.4.6 Where protections are provided by the operating environment, the tester shall perform the following: T.1.4.6.1 Examine vendor materials and other evidence, including source code to confirm that such protections provide the required tamper-resistance features and that any elements of code or data that are not covered by these protections cannot be used to reverse engineer the code or disclose sensitive information about the 3DS SDK.
T.1.4.6.1 Examine vendor materials and other evidence, including source code to confirm that such protections provide the required tamper-resistance features and that any elements of code or data that are not covered by these protections cannot be used to reverse engineer the code or disclose sensitive information about the 3DS SDK.
T.1.4.6.2 Test the 3DS SDK to confirm that the 3DS SDK will only execute on platforms which provide such integrated protections.
T.1.4.7 Where protections are provided by runtime methods or anti-debugging features, the tester shall perform the following:
T.1.4.7.1 Examine vendor materials and other evidence to confirm that such protections provide the required tamper resistance features and that any elements of code or data that are not covered by these protections cannot be used to reverse engineer the code or disclose sensitive information about the 3DS SDK.
T.1.4.7.2 Confirm that the local software that provides these features is itself protected.
T.1.4.7.3 Where any features require interaction with an external system (such as a cloud-based monitoring system), the tester shall confirm that mechanisms are in place to prevent disabling of the remote protections, such as through traffic or communications manipulation.
T.1.4.8 Where additional protections are provided by the application, the tester shall confirm that these protections apply across all supported platforms and operating systems (as assessed under Requirement 1.1, “Security Checks”), or that any gaps that exist in coverage of these protections do notincrease the risk posed by those platforms.
T.1.4.9 Where device-specific features are relied upon, the tester shall attempt to execute the 3DS SDK on a system that either does not provide such features or has been modified to prevent the secure use of these features, and observe the operation of the 3DS SDK to confirm that the 3DS SDK does not execute when such features are absent or disabled.
Guidance:
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.
Requirements:
1.5 Protection of 3DS SDK Reference Data
3DS SDK Reference Data is securely stored within the 3DS SDK code to prevent unauthorized modification.
Assessment Procedures:
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”).
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 there is any 3DS SDK Reference Data that is not covered by these protections, the tester shall confirm that the lack of protection does not affect the security of the 3DS SDK or 3DS transaction process.
T.1.5.3 Where cryptography is implemented for the purposes of providing this protection, the tester shall confirm that the cryptographic protections include the protection of the integrity of the data. The tester shall also confirm that cryptography meets PCI requirements for strong cryptography, including applicable cryptography requirements in this standard, and that all keys used for these cryptographic operations are protected.
T.1.5.4 Where obfuscation is implemented to provide the protections, the tester shall confirm that this obfuscation is covered under testing performed in Requirement 1.4, “Protection against Reverse Engineering.”
T.1.5.5 Where device-specific features are relied upon to provide the protections, the tester shall attempt to execute the 3DS SDK on a system that either does not provide such features or has been modified to prevent the secure use of these features to confirm that the 3DS SDK does not execute when such features are absent or disabled.
T.1.5.6 The tester shall attempt to circumvent the features protecting the 3DS SDK Reference Data and modify this data in such a way that the modification is not detected by the 3DS SDK upon execution to confirm the 3DS SDK prohibits such modifications. This testing must consider the different types of protections applied and devices targeted by the SDK.
Guidance:
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.

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.