Document Comparison
MPoC-v1-1-Summary-of-Changes-to-v1-0-1.pdf
→
Mobile_Payments_on_COTS-v1_1.pdf
0% similar
10 → 282
Pages
2882 → 98541
Words
288
Content Changes
Content Changes
288 content changes. 270 administrative changes (dates, page numbers) hidden.
Added
p. 2
Jan 2023 1.0.1 Errata release.
Various typographical errors fixed.
Included missing "not” into Requirement 1D-4.3 to align with intent and testing instruction.
Updated Applicability Matrix (Table 2) to align with Domain 4 scoping statements including A&M Service Providers.
October 2024 1.1 (RFC Draft) Update for stakeholder feedback for next version.
Various typographical errors fixed.
Included missing "not” into Requirement 1D-4.3 to align with intent and testing instruction.
Updated Applicability Matrix (Table 2) to align with Domain 4 scoping statements including A&M Service Providers.
October 2024 1.1 (RFC Draft) Update for stakeholder feedback for next version.
Added
p. 8
Solutions that do not use COTS devices (as defined in this standard), use devices that are intended for integration into another product (such as a bare-board computer), are not considered by this standard. Use of MPoC Solutions in environments that are not merchant attended is considered out of scope of this standard, and any decisions in this regard are left to the compliance-accepting entity.
Use of MPoC implementations for non-payment acceptance, such as for transit validation where payment is processed by another system, is possible. MPoC implementors and deployers are encouraged to reach out to their compliance-accepting entities for any further details regarding deployment rules.
The security requirements described in this document provide a security framework to protect the confidentiality and integrity of sensitive payment information captured and processed in MPoC Solutions. The test requirements outlined in this document provide details of the testing processes performed by the evaluation laboratories as part …
Use of MPoC implementations for non-payment acceptance, such as for transit validation where payment is processed by another system, is possible. MPoC implementors and deployers are encouraged to reach out to their compliance-accepting entities for any further details regarding deployment rules.
The security requirements described in this document provide a security framework to protect the confidentiality and integrity of sensitive payment information captured and processed in MPoC Solutions. The test requirements outlined in this document provide details of the testing processes performed by the evaluation laboratories as part …
Added
p. 9
An MPoC Service may include listing of both MPoC SDKs and MPoC Applications.
• MPoC Solution: The set of components and processes that supports mobile payment acceptance and protection of account data on a COTS device. At a minimum, the solution includes the MPoC Application, attestation system, and the back-end systems and environments that perform attestation, monitoring, and payment processing. An MPoC Solution may be a monolithic implementation, that does not reference any other listed MPoC Products, or it may reference and rely upon one or more MPoC Software and MPoC Service products.
An MPoC Solution may not include an MPoC SDK as part of its listing, but it may include MPoC Applications that integrate an MPoC SDK from an associated MPoC Software or MPoC Service. An MPoC Solution may also list monolithic MPoC Applications developed as part of the MPoC Solution.
The requirements in this standard are organized in five Domains. The …
• MPoC Solution: The set of components and processes that supports mobile payment acceptance and protection of account data on a COTS device. At a minimum, the solution includes the MPoC Application, attestation system, and the back-end systems and environments that perform attestation, monitoring, and payment processing. An MPoC Solution may be a monolithic implementation, that does not reference any other listed MPoC Products, or it may reference and rely upon one or more MPoC Software and MPoC Service products.
An MPoC Solution may not include an MPoC SDK as part of its listing, but it may include MPoC Applications that integrate an MPoC SDK from an associated MPoC Software or MPoC Service. An MPoC Solution may also list monolithic MPoC Applications developed as part of the MPoC Solution.
The requirements in this standard are organized in five Domains. The …
Added
p. 10
• Domain 5: MPoC Solution: The security requirements and test procedures that apply to MPoC Solution providers who are responsible for managing the interaction between all parties in an MPoC Solution, and ensuring that any associated MPoC Applications, which are not already listed as part of an MPoC Software Product, meet the requirements of this standard and are included as part of their MPoC listing.
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 Mobile Payments on COTS standard.
• PCI SSC maintains various PCI standards, supporting programs, and related documentation. In relation to this standard, PCI SSC:
• Maintains the Mobile Payments on COTS Security and Test Requirements (this document).
• Maintains supporting documentation including reporting templates, attestation forms, technical frequently asked questions (FAQs), and guidance to assist entities implementing and assessing to the …
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 Mobile Payments on COTS standard.
• PCI SSC maintains various PCI standards, supporting programs, and related documentation. In relation to this standard, PCI SSC:
• Maintains the Mobile Payments on COTS Security and Test Requirements (this document).
• Maintains supporting documentation including reporting templates, attestation forms, technical frequently asked questions (FAQs), and guidance to assist entities implementing and assessing to the …
Added
p. 11
• MPoC Software vendor
• The MPoC Software vendor develops, supports, and distributes an MPoC Software product. An MPoC Software vendor is responsible for ensuring that the MPoC Software they develop meets the requirements outlined in Domain 1: MPoC Software Core Requirements.
• MPoC Service provider
• An MPoC Service provider is involved in the deployment and operation of services which include the operation of the MPoC Software, or support the operation of an MPoC Solution. For example, an entity operating the attestation and monitoring (A&M) service is responsible for ensuring that all requirements outlined in Domain 3: Attestation and Monitoring are met, and other aspects of the MPoC requirements may apply to each MPoC Service depending on the details and scope of that service.
• MPoC Solution provider
• An MPoC Solution provider is the entity that has overall responsibility for the implementation and management of an MPoC Solution. The MPoC Solution provider is …
• The MPoC Software vendor develops, supports, and distributes an MPoC Software product. An MPoC Software vendor is responsible for ensuring that the MPoC Software they develop meets the requirements outlined in Domain 1: MPoC Software Core Requirements.
• MPoC Service provider
• An MPoC Service provider is involved in the deployment and operation of services which include the operation of the MPoC Software, or support the operation of an MPoC Solution. For example, an entity operating the attestation and monitoring (A&M) service is responsible for ensuring that all requirements outlined in Domain 3: Attestation and Monitoring are met, and other aspects of the MPoC requirements may apply to each MPoC Service depending on the details and scope of that service.
• MPoC Solution provider
• An MPoC Solution provider is the entity that has overall responsibility for the implementation and management of an MPoC Solution. The MPoC Solution provider is …
Added
p. 12
Table 1: Glossary of Terms Term Definition Account data Account data consists of cardholder data and/or sensitive authentication data. See Cardholder data and Sensitive authentication data.
AES Abbreviation for “Advanced Encryption Standard.” Block cipher used in symmetric key cryptography adopted by NIST in November 2001 as FIPS PUB 197 (or FIPS 197).
Assets Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive elements. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. Software may also be considered an asset if the correct operation of that software is required to provide security protection to other assets.
See also Sensitive assets.
Asymmetric encryption Also known as public key cryptography, asymmetric cryptosystems are based on the intractability of certain mathematical problems. A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation …
AES Abbreviation for “Advanced Encryption Standard.” Block cipher used in symmetric key cryptography adopted by NIST in November 2001 as FIPS PUB 197 (or FIPS 197).
Assets Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive elements. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. Software may also be considered an asset if the correct operation of that software is required to provide security protection to other assets.
See also Sensitive assets.
Asymmetric encryption Also known as public key cryptography, asymmetric cryptosystems are based on the intractability of certain mathematical problems. A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation …
Added
p. 13
Attestation and monitoring software (also A&M software) The software used to implement the attestation and monitoring functions. Attestation and Monitoring software is a required part of any MPoC Software Product.
Back-end systems The set of systems providing the server-side functionality of the MPoC Solution. This includes monitoring, attestation and (optional) payment and PIN processing functions.
Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. See Sensitive authentication data for additional data elements that might be transmitted or processed (but not stored) as part of a payment transaction.
Cardholder data environment (CDE) The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.
Chip-based For the purposes of this standard, chip-based payment methods include any payment method that is based on an EMV …
Back-end systems The set of systems providing the server-side functionality of the MPoC Solution. This includes monitoring, attestation and (optional) payment and PIN processing functions.
Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. See Sensitive authentication data for additional data elements that might be transmitted or processed (but not stored) as part of a payment transaction.
Cardholder data environment (CDE) The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.
Chip-based For the purposes of this standard, chip-based payment methods include any payment method that is based on an EMV …
Added
p. 14
COTS platform The hardware and operating systems (OS) of the COTS device.
COTS platform baseline A measurable configuration reference point of the COTS device attributes and COTS operating systems (OS) on which the MPoC Application may be executed. The COTS platform baseline is used for periodic comparative analysis by the back-end attestation system to determine changes that would impact the overall security of the COTS device to continue to process transactions.
Cryptographic material All materials involved in the implementation of a cryptographic algorithm or process including keys, entropy seeds, nonces, and lookup tables involved in the execution of the algorithm, etc.
Data level Used in this standard to identify when a security control needs to be applied directly and specifically to a data type, such as PANs or PINs. Requirements for encryption at the data level cannot be met through use of Secure Channels alone.
Deterministic Random Number Generator (DRNG) A deterministic algorithm to …
COTS platform baseline A measurable configuration reference point of the COTS device attributes and COTS operating systems (OS) on which the MPoC Application may be executed. The COTS platform baseline is used for periodic comparative analysis by the back-end attestation system to determine changes that would impact the overall security of the COTS device to continue to process transactions.
Cryptographic material All materials involved in the implementation of a cryptographic algorithm or process including keys, entropy seeds, nonces, and lookup tables involved in the execution of the algorithm, etc.
Data level Used in this standard to identify when a security control needs to be applied directly and specifically to a data type, such as PANs or PINs. Requirements for encryption at the data level cannot be met through use of Secure Channels alone.
Deterministic Random Number Generator (DRNG) A deterministic algorithm to …
Added
p. 15
Execution environment The set of hardware and software on which a program is executed. This may be provided through hardware alone, include a combination of hardware and software elements, or be virtualized and implemented in software such that the execution environment can be similarly executed on different hardware platforms.
See Rich execution environment (REE), Trusted execution environment (TEE)Trusted execution environment (TEE), and Secure element (SE).
Hash A method to protect data that converts data into a fixed-length message digest. A hash is a one-way (mathematical) function in which a non-secret algorithm takes any arbitrary length message as input and produces a fixed length output (usually called a “hash code” or “message digest”). Hash functions are required to have the following properties:
• It is computationally infeasible to determine the original input given only the hash code,
• It is computationally infeasible to find two inputs that give the same hash code.
Hash-based message authentication code …
See Rich execution environment (REE), Trusted execution environment (TEE)Trusted execution environment (TEE), and Secure element (SE).
Hash A method to protect data that converts data into a fixed-length message digest. A hash is a one-way (mathematical) function in which a non-secret algorithm takes any arbitrary length message as input and produces a fixed length output (usually called a “hash code” or “message digest”). Hash functions are required to have the following properties:
• It is computationally infeasible to determine the original input given only the hash code,
• It is computationally infeasible to find two inputs that give the same hash code.
Hash-based message authentication code …
Added
p. 16
See also Non-PTS approved MSR.
Mandatory access control Access control by which the operating systems (OS) constrains the ability of a process or thread to access or perform an operation on objects or targets such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc., through an authorization rule enforced by the operating systems (OS) kernel.
Man-in-the-middle (MITM attack) attack An attack method where a malicious third party interposes between two other communicating parties and modifies the data sent between them.
Merchant-attended A deployment of a payment acceptance device or solution is merchant-attended where there is a merchant or merchant agent who is able to assist with, or provide oversight of, the payment process.
Message authentication code (MAC) In cryptography, a small piece of information used to authenticate a message.
See Hash-based message authentication code (HMAC).
Mobile device In the context of this Standard, see Commercial off-the-shelf (COTS) device.
Mobile Device Management (MDM) A system for …
Mandatory access control Access control by which the operating systems (OS) constrains the ability of a process or thread to access or perform an operation on objects or targets such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc., through an authorization rule enforced by the operating systems (OS) kernel.
Man-in-the-middle (MITM attack) attack An attack method where a malicious third party interposes between two other communicating parties and modifies the data sent between them.
Merchant-attended A deployment of a payment acceptance device or solution is merchant-attended where there is a merchant or merchant agent who is able to assist with, or provide oversight of, the payment process.
Message authentication code (MAC) In cryptography, a small piece of information used to authenticate a message.
See Hash-based message authentication code (HMAC).
Mobile device In the context of this Standard, see Commercial off-the-shelf (COTS) device.
Mobile Device Management (MDM) A system for …
Added
p. 17
MPoC Service An MPoC Product that provides the operational aspects of an MPoC Software product but does not meet the requirements of a full MPoC Solution. An MPoC Service is validated to all relevant MPoC requirements, based on the functionality provided.
MPoC Service (A&M) An MPoC Service product that provides the operational A&M aspects of an MPoC Software product.
MPoC Service (A&M and Payment Processing) An MPoC Service product that provides both the operation A&M aspects of an MPoC Software product, as well as operational aspects required for payment processing.
MPoC Service Provider An entity that develops, manages, and/or deploys an MPoC Service.
MPoC Software vendor An entity developing, distributing, and supporting the MPoC Software.
MPoC Solution provider An entity that develops, manages, and/or deploys MPoC Solutions.
MPoC Software Product The MPoC Software as validated and listed on the PCI SSC website.
Monitoring system Monitors and provisions security controls to detect, alert, and mitigate suspected or actual …
MPoC Service (A&M) An MPoC Service product that provides the operational A&M aspects of an MPoC Software product.
MPoC Service (A&M and Payment Processing) An MPoC Service product that provides both the operation A&M aspects of an MPoC Software product, as well as operational aspects required for payment processing.
MPoC Service Provider An entity that develops, manages, and/or deploys an MPoC Service.
MPoC Software vendor An entity developing, distributing, and supporting the MPoC Software.
MPoC Solution provider An entity that develops, manages, and/or deploys MPoC Solutions.
MPoC Software Product The MPoC Software as validated and listed on the PCI SSC website.
Monitoring system Monitors and provisions security controls to detect, alert, and mitigate suspected or actual …
Added
p. 18
Operating system (OS) System software that manages the underlying hardware and software resources and provides common services for programs. Common OSs used in a COTS environment include, but are not limited to, Android and iOS implementations.
OS store A digital distribution service operated by the COTS OS vendor or by the COTS device manufacturer used to distribute the MPoC Application.
Out-of-band Communication using a means independent of the primary communications means.
Payment-processing environment Back-end environment in which account data transferred from the MPoC Software is decrypted and/or processed.
PCI DSS The Data Security Standard published and maintained by the Payment Card Industry Security Standards Council. PCI DSS provides a baseline of technical and operational requirements designed to protect account data.
Perfect forward secrecy Also known as “Forward Secrecy.” A protocol has Perfect Forward Secrecy if a compromise of long-term keys does not also compromise past session keys.
Protection types The specific form of protection required for …
OS store A digital distribution service operated by the COTS OS vendor or by the COTS device manufacturer used to distribute the MPoC Application.
Out-of-band Communication using a means independent of the primary communications means.
Payment-processing environment Back-end environment in which account data transferred from the MPoC Software is decrypted and/or processed.
PCI DSS The Data Security Standard published and maintained by the Payment Card Industry Security Standards Council. PCI DSS provides a baseline of technical and operational requirements designed to protect account data.
Perfect forward secrecy Also known as “Forward Secrecy.” A protocol has Perfect Forward Secrecy if a compromise of long-term keys does not also compromise past session keys.
Protection types The specific form of protection required for …
Added
p. 19
Random Number Generator (RNG) The process of generating values with a high level of entropy and that satisfy various qualifications, using cryptographic and hardware-based “noise” mechanisms. This results in a value in a set that has equal probability of being selected from the total population of possibilities, hence unpredictable.
Replay attack A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.
Rich execution environment (REE) Refers to an execution environment where COTS device resources are shared by OS applications.
RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at Massachusetts Institute of Technology (MIT); letters RSA are the initials of their surnames.
Secure boot See trusted boot.
Secure Card Reader
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed …
Replay attack A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.
Rich execution environment (REE) Refers to an execution environment where COTS device resources are shared by OS applications.
RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at Massachusetts Institute of Technology (MIT); letters RSA are the initials of their surnames.
Secure boot See trusted boot.
Secure Card Reader
• PIN (SCRP) A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed …
Added
p. 20
Sensitive services A sensitive service is any service that may affect the security of the overall system, as well as those functions that affect underlying processes that support the protection of assets•e.g., cryptographic keys and account data. Common examples are key management, modification, or update of attestation services, or remote component of contactless kernels (or other remote processing components) and cryptographic signing of assets to allow their authenticity to be verified.
Service provider An entity responsible for deployment, operation, and management of the back-end monitoring; attestation; PIN processing; and account data processing environments.
Software-protection mechanisms Methods and implementations used to protect against the reverse-engineering and modification of software, including, but not limited to, hooking, rooting, emulation or debugging detection, verification, and validation of software.
Software-protected cryptography A method used to obfuscate the execution of a cryptographic algorithm in software, including the protection of the cryptographic key, with the goal of making determination of …
Service provider An entity responsible for deployment, operation, and management of the back-end monitoring; attestation; PIN processing; and account data processing environments.
Software-protection mechanisms Methods and implementations used to protect against the reverse-engineering and modification of software, including, but not limited to, hooking, rooting, emulation or debugging detection, verification, and validation of software.
Software-protected cryptography A method used to obfuscate the execution of a cryptographic algorithm in software, including the protection of the cryptographic key, with the goal of making determination of …
Added
p. 21
White-box cryptography A type of software-protected cryptography.
Added
p. 22
Figure 1: Traditional PIN Acceptance Solution Overview Mobile payment acceptance enables the processing of payment transactions (e.g., using a smartphone or tablet that performs the functions of an electronic point-of-sale terminal). These solutions rely on a combination of mechanisms and security controls including, but not limited to, COTS device hardware, application software, and independent management and oversight of the entire process to ensure the security of the transaction and the cardholder verification data.
This standard is designed to allow mobile payment solutions to support multiple payment-acceptance channels and cardholder verification methods. For example, one solution could support a COTS-native NFC interface without PIN entry, while another solution could be designed to support COTS-native-NFC interfaces for contactless card entry with PIN, as well as also supporting external PCI PTS POI devices.
This standard is designed to allow mobile payment solutions to support multiple payment-acceptance channels and cardholder verification methods. For example, one solution could support a COTS-native NFC interface without PIN entry, while another solution could be designed to support COTS-native-NFC interfaces for contactless card entry with PIN, as well as also supporting external PCI PTS POI devices.
Added
p. 23
Figure 2 below shows the functional model of the solution that uses a software MPoC Application, with the option of additional hardware in the form of external PCI PTS POI or magnetic-stripe reader (non-PTS approved MSR), for protecting account data. Where an external PCI PTS POI is used, this can provide for reading of payment cards (both magnetic-stripe and chip-based), as well as the entry of cardholder PINs. Account data-entry methods provided for use by the POI are dependent on the PCI PTS POI approval class and functions supported.
This standard defines the requirements for assessment to validate candidate MPoC Products prior to it being listed on the PCI SSC website. For details on compliance programs outlining the use of listed MPoC Products, please refer to the relevant payment card brands.
This standard defines the requirements for assessment to validate candidate MPoC Products prior to it being listed on the PCI SSC website. For details on compliance programs outlining the use of listed MPoC Products, please refer to the relevant payment card brands.
Added
p. 24
• COTS-native NFC interface
• PCI PTS POI devices for contact, contactless, and MSR-based transactions
• Non-PTS approved MSR devices validated through the MSR appendix of this standard
• Manually entered account data and cardholder verification methods
• COTS-native PIN entry Support for any of the payment acceptance channels and/or CVMs described above is optional•the only requirement is that an MPoC Solution, or MPoC Software Product, must support chip-based payments and at least one COTS-native method of entry. As examples, an MPoC Solution may support COTS-native NFC and COTS-native PIN entry on the same device, it may support COTS-native NFC without PIN, or it may support account data entry through external readers only with COTS-native PIN.
However, an MPoC Solution (or MPoC Software Product) may not support only MSR or manual entry-based payments, or methods of account data entry performed exclusively through a PCI PTS POI, without any COTS-native account data-entry methods. Individual transactions are …
• PCI PTS POI devices for contact, contactless, and MSR-based transactions
• Non-PTS approved MSR devices validated through the MSR appendix of this standard
• Manually entered account data and cardholder verification methods
• COTS-native PIN entry Support for any of the payment acceptance channels and/or CVMs described above is optional•the only requirement is that an MPoC Solution, or MPoC Software Product, must support chip-based payments and at least one COTS-native method of entry. As examples, an MPoC Solution may support COTS-native NFC and COTS-native PIN entry on the same device, it may support COTS-native NFC without PIN, or it may support account data entry through external readers only with COTS-native PIN.
However, an MPoC Solution (or MPoC Software Product) may not support only MSR or manual entry-based payments, or methods of account data entry performed exclusively through a PCI PTS POI, without any COTS-native account data-entry methods. Individual transactions are …
Added
p. 25
The architecture of an MPoC Solution relies on the following components that combine to provide for protection, attestation, detection, and response controls:
• A COTS device that is operated by the merchant to run the MPoC Application. The COTS device may have a TEE or secure element built-in, but this is not a requirement.
• MPoC Application that resides on the COTS device and:
• Collects and passes attestation data about any attached hardware systems (such as a PCI PTS POI or non-PTS approved MSR), COTS platform, and MPoC Application to the attestation and monitoring back-end systems.
• Contains software protection mechanisms to maintain its own integrity against attack.
• Securely communicates account data (and other sensitive assets such as cardholder PINs, where these are supported and used) to back-end systems.
• (Optional) a secure UI for entry of account data-entry methods (such as PIN, PAN, or security codes), and encryption of this data.
• (Optional) a …
• A COTS device that is operated by the merchant to run the MPoC Application. The COTS device may have a TEE or secure element built-in, but this is not a requirement.
• MPoC Application that resides on the COTS device and:
• Collects and passes attestation data about any attached hardware systems (such as a PCI PTS POI or non-PTS approved MSR), COTS platform, and MPoC Application to the attestation and monitoring back-end systems.
• Contains software protection mechanisms to maintain its own integrity against attack.
• Securely communicates account data (and other sensitive assets such as cardholder PINs, where these are supported and used) to back-end systems.
• (Optional) a secure UI for entry of account data-entry methods (such as PIN, PAN, or security codes), and encryption of this data.
• (Optional) a …
Added
p. 26
The MPoC Software is considered as two separate parts•the MPoC SDK (intended for integration into an MPoC Application) or complete MPoC Application itself, and the back-end software including the MPoC Attestation and Monitoring software. The MPoC SDK or MPoC Application execute on the COTS platform, although they may include remote execution components (such as a remote kernel).
Any MPoC Application may optionally support APIs that accept non-sensitive payment initiation data, such as an amount, from another “calling” application or function. This allows for an MPoC Solution to provide for payment initiation from applications outside of the scope of MPoC validation and listing•by providing an API through which an MPoC Application may receive non-sensitive payment initiation and response data (such as amount).
Therefore, there are three types of COTS software considered in an MPoC Solution:
1. The MPoC SDK, which is designed to be integrated into an MPoC Application.
2. The MPoC Application itself, which …
Any MPoC Application may optionally support APIs that accept non-sensitive payment initiation data, such as an amount, from another “calling” application or function. This allows for an MPoC Solution to provide for payment initiation from applications outside of the scope of MPoC validation and listing•by providing an API through which an MPoC Application may receive non-sensitive payment initiation and response data (such as amount).
Therefore, there are three types of COTS software considered in an MPoC Solution:
1. The MPoC SDK, which is designed to be integrated into an MPoC Application.
2. The MPoC Application itself, which …
Added
p. 27
• An Isolated MPoC SDK An Isolated MPoC SDK must provide for sufficient isolation of its memory space and be validated during the laboratory assessment that cleartext sensitive assets, such as account data or cryptographic keys, are not accessible by an MPoC Application that integrates that SDK.
• A non-Isolated MPoC SDK A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive assets from the MPoC Application.
In each case, the validation of “sufficient isolation” is based on the laboratory assessment and costing framework outlined in the MPoC standard. Assets that are already sufficiently protected, e.g., through the use of cryptography or truncation (for PANs), are not considered in the determination of an Isolated or non-Isolated SDK.
In all cases, an Isolated MPoC SDK cannot allow for sensitive cleartext data to be exposed to the MPoC Application, even if that functionality …
• A non-Isolated MPoC SDK A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive assets from the MPoC Application.
In each case, the validation of “sufficient isolation” is based on the laboratory assessment and costing framework outlined in the MPoC standard. Assets that are already sufficiently protected, e.g., through the use of cryptography or truncation (for PANs), are not considered in the determination of an Isolated or non-Isolated SDK.
In all cases, an Isolated MPoC SDK cannot allow for sensitive cleartext data to be exposed to the MPoC Application, even if that functionality …
Added
p. 31
Example (2) is similar to the first example, where two MPoC SDKs are integrated separately, but here the first MPoC SDK (MPoC SDK1) is integrated into the second MPoC SDK (MPoC SDK2). From the point of view of the MPoC Application, it is integrating only a single MPoC SDK (MPoC SDK2). Validation requirements are the same as those in the first example.
In Example (3), MPoC SDK1 handles all account data entry and encryption, as well as management of the Attestation and Monitoring. MPoC SDK2 provides payment routing and messaging services, which may include forwarding of (encrypted) payment-related cryptographic keys and formatting of messages so they can be accepted by the payment host.
Here, MPoC SDK2 would be assessed against any relevant requirements in MPoC Domain 1, such as the Secure Channel requirements, as well as the requirements of Domain 2A (if MPoC SDK1 is an Isolating SDK). However, depending on the …
In Example (3), MPoC SDK1 handles all account data entry and encryption, as well as management of the Attestation and Monitoring. MPoC SDK2 provides payment routing and messaging services, which may include forwarding of (encrypted) payment-related cryptographic keys and formatting of messages so they can be accepted by the payment host.
Here, MPoC SDK2 would be assessed against any relevant requirements in MPoC Domain 1, such as the Secure Channel requirements, as well as the requirements of Domain 2A (if MPoC SDK1 is an Isolating SDK). However, depending on the …
Added
p. 32
The MPoC standard allows for an entity to take on more than one role in an MPoC Solution. For example, an MPoC Software vendor may choose to also take the role of an MPoC Solution provider while outsourcing the A&M operation to an MPoC Service provider. In this case, the MPoC Solution may consist of an MPoC Application that exposes payment APIs for other applications to call, rather than an MPoC SDK to be integrated into new MPoC Applications (although this would also be possible).
In another example, an MPoC Software vendor may take the role of an MPoC Service provider themselves, operating their back-end software for different MPoC Solution providers. Other possible combinations also exist. However, in all cases, the requirements that apply to that role will apply to any entity taking on that role.
The MPoC standard allows for modular evaluation and certification of various MPoC Services and MPoC Software …
In another example, an MPoC Software vendor may take the role of an MPoC Service provider themselves, operating their back-end software for different MPoC Solution providers. Other possible combinations also exist. However, in all cases, the requirements that apply to that role will apply to any entity taking on that role.
The MPoC standard allows for modular evaluation and certification of various MPoC Services and MPoC Software …
Added
p. 37
Note: An MPoC Solution that relies on (one or more) MPoC Service(s) needs to ensure the MPoC Applications it deploys are supported by those services.
Monolithic MPoC Solution Examples A monolithic MPoC Solution is defined by the fact that it does not integrate or use any other listed MPoC Products. A monolithic MPoC Solution may include or use external card readers, such as a PCI PTS POI or non-PTS approved MSR. Monolithic MPoC Solutions are assessed to all Domains of the MPoC Standard, although some Modules/Sections/requirements may not apply where these are scoped solely for the integration or assessment of different MPoC Product or account data-entry types. Refer to Section: MPoC Domain and Section Applicability above for details on the specific Modules and Sections that may apply.
A monolithic MPoC Solution may implement multiple MPoC Applications, each with different account data-entry methods and CVM support. For example, a monolithic MPoC Solution may …
Monolithic MPoC Solution Examples A monolithic MPoC Solution is defined by the fact that it does not integrate or use any other listed MPoC Products. A monolithic MPoC Solution may include or use external card readers, such as a PCI PTS POI or non-PTS approved MSR. Monolithic MPoC Solutions are assessed to all Domains of the MPoC Standard, although some Modules/Sections/requirements may not apply where these are scoped solely for the integration or assessment of different MPoC Product or account data-entry types. Refer to Section: MPoC Domain and Section Applicability above for details on the specific Modules and Sections that may apply.
A monolithic MPoC Solution may implement multiple MPoC Applications, each with different account data-entry methods and CVM support. For example, a monolithic MPoC Solution may …
Added
p. 38
• and (in this example) also relies on the use of a listed MPoC Service (A&M) provider who supports the same MPoC Software Product that includes the MPoC SDK that is used.
In this example, the MPoC SDK being integrated supports an external non-PTS approved MSR and COTS-native NFC (with optional PIN support for the contactless payment channel). The MPoC Solution is deploying two MPoC Applications - one of the MPoC Applications implements both payment acceptance channels supported by the SDK (COTS-native NFC and non-PTS approved MSR), and one implements only the COTS-native NFC (with optional PIN) functions of the MPoC SDK.
In this case, the MPoC Solution would not be assessed against Domain 1 or Domain 3, as it is not implementing its own software or attestation and monitoring systems as part of the core of the MPoC Solution (if the MPoC Solution were to implement its own attestation and monitoring …
In this example, the MPoC SDK being integrated supports an external non-PTS approved MSR and COTS-native NFC (with optional PIN support for the contactless payment channel). The MPoC Solution is deploying two MPoC Applications - one of the MPoC Applications implements both payment acceptance channels supported by the SDK (COTS-native NFC and non-PTS approved MSR), and one implements only the COTS-native NFC (with optional PIN) functions of the MPoC SDK.
In this case, the MPoC Solution would not be assessed against Domain 1 or Domain 3, as it is not implementing its own software or attestation and monitoring systems as part of the core of the MPoC Solution (if the MPoC Solution were to implement its own attestation and monitoring …
Added
p. 39
MPoC Solution Implementing a Single MPoC Service (A&M and Payment Processing) An MPoC Solution could integrate a listed MPoC Service providing A&M and Payment Processing (as outlined above) and be assessed only to the requirements in Domain 5, as well as the requirements of Domain 2 for any MPoC Applications listed with that MPoC Solution (that have not already been assessed and listed as part of another MPoC Product that MPoC Solution is integrating). This provides for a light-touch path to validation for “white-label” implementations, and for entities choosing to build an MPoC Solution where they are not themselves performing any of the software development or maintenance, key management, or vulnerability management.
MPoC Solution Implemented by MPoC Software Vendor An MPoC Software vendor may choose to implement their own MPoC Solution, potentially as a completely monolithic MPoC Solution, or based on their separately listed MPoC Software Product and MPoC Service. Assessment …
MPoC Solution Implemented by MPoC Software Vendor An MPoC Software vendor may choose to implement their own MPoC Solution, potentially as a completely monolithic MPoC Solution, or based on their separately listed MPoC Software Product and MPoC Service. Assessment …
Added
p. 40
• COTS device, attestation, and monitoring security controls to protect the security of payment transactions on COTS devices are consistent with PCI Software-Based PIN Entry on COTS (SPoC) and PCI Contactless Payments on COTS (CPoC).
• POI devices are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements.
• HSMs in the back-end environment used for PIN and account-data decryption, and related cryptographic-key operations require validation to PCI PTS HSM or FIPS 140-2, or 140-3, Level 3 (or 4).
• Software used in the solution and software lifecycle practices are developed using best practices consistent with the PCI Software Security Framework (SSF).
• The back-end payment-processing environment is required to be PCI DSS compliant.
• The back-end PIN-processing environment is required to be PCI PIN Security compliant.
• The security requirements for back-end attestation and monitoring environment are developed from PCI DSS (where the back-end attestation and monitoring systems are sufficiently isolated from …
• POI devices are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements.
• HSMs in the back-end environment used for PIN and account-data decryption, and related cryptographic-key operations require validation to PCI PTS HSM or FIPS 140-2, or 140-3, Level 3 (or 4).
• Software used in the solution and software lifecycle practices are developed using best practices consistent with the PCI Software Security Framework (SSF).
• The back-end payment-processing environment is required to be PCI DSS compliant.
• The back-end PIN-processing environment is required to be PCI PIN Security compliant.
• The security requirements for back-end attestation and monitoring environment are developed from PCI DSS (where the back-end attestation and monitoring systems are sufficiently isolated from …
Added
p. 41
Use of PCI PTS POI Devices A PCI PTS POI used with an MPoC Solution must be an approved PCI PTS POI device that is listed on the PCI SSC Approved Device website with SRED functionality. This class of devices may optionally support contact magnetic-stripe reading functionality. When included with an MPoC Solution, a PCI PTS POI may be used for any method of card data presentment that it supports, including for the acceptance of contactless payment cards, as long as all account data output is encrypted. A PCI PTS POI may also be included when a COTS-native presentment method is used in place of one supported by the PCI PTS POI⎯e.g., a PCI PTS POI that supports contactless cards could be used with an MPoC Solution that uses COTS-native NFC acceptance instead.
Use of Non-PTS Approved MSR When non-PTS approved MSR is supported by the solution, the tester must validate …
Use of Non-PTS Approved MSR When non-PTS approved MSR is supported by the solution, the tester must validate …
Added
p. 42
Relationship between This Standard and PCI SPoC Standard and PCI CPoC Standard The MPoC standard incorporates and builds upon many of the concepts and requirements found in the PCI SPoC and PCI CPoC standards. However, the MPoC standard does not supersede or replace these other mobile standards. For details of any migration path from an existing SPoC or CPoC Solution to the listing of an MPoC Solution, refer to the MPoC Program Guide.
Added
p. 43
For an objective-based approach to be successful, entities are expected to possess a robust risk-management practice as an integral part of their “business-as-usual” operational process. While this approach provides the entities with the flexibility to implement security controls based on identified risk, the entity needs to be able to demonstrate how the implemented controls are supported by the results of its risk-identification and risk-management practices. Without a robust risk-management practice and evidence to support risk-based decision making, adherence to the requirements in this standard may be difficult to validate.
If security requirements do not define a specific level, rigor, or frequency for periodic or recurring activities (e.g., the maximum period in which an entity is required to release a security update to fix a known vulnerability), the entity may define the level of rigor or frequency that is appropriate. The rigor and frequency defined by the entity must be supported by …
If security requirements do not define a specific level, rigor, or frequency for periodic or recurring activities (e.g., the maximum period in which an entity is required to release a security update to fix a known vulnerability), the entity may define the level of rigor or frequency that is appropriate. The rigor and frequency defined by the entity must be supported by …
Added
p. 45
• Security Objective. Identifies the high-level security objective that the entity is required to meet. Security objectives are broadly stated to enable entities flexibility in determining the best methods to achieve the stated security objective. However, it is expected that the entity produces clear and unambiguous evidence to show that the chosen methods are appropriate, sufficient, and properly implemented to satisfy the security objective. Below the security objective, additional information has been provided to help both entities and laboratories understand the intent behind the security objective.
• Security Requirements. Specific security controls or activities that must be implemented by the entity to support the overarching security objective.
• Test Requirements. Describe the expected testing activities to be performed by the laboratory to validate whether an entity has met a particular security requirement. The test requirements are intended to provide both the entity and the laboratory with a common understanding of the assessment …
• Security Requirements. Specific security controls or activities that must be implemented by the entity to support the overarching security objective.
• Test Requirements. Describe the expected testing activities to be performed by the laboratory to validate whether an entity has met a particular security requirement. The test requirements are intended to provide both the entity and the laboratory with a common understanding of the assessment …
Added
p. 47
Sensitive assets are a sub-set of the asset class that require confidentiality protections.
The specific assets used in a solution are expected to be unique to how that solution operates, and therefore a comprehensive list is required to be developed as part of the evaluation of any MPoC Solution.
The security controls required to protect payment information depend on the type of payment acceptance channels and cardholder verification methods supported by the MPoC Software. All MPoC Software is required to meet the security objective, requirements, and test requirements in the Core Module. The objective of these security requirements is to ensure the integrity of the COTS device, and to reasonably ensure that the solutions provide adequate security mechanisms, controls, and mitigations to protect the cardholder’s account data and other assets such as cryptographic keys. These requirements assist with protection from unauthorized disclosure, modification, or misuse by restricting the available attack surface and …
The specific assets used in a solution are expected to be unique to how that solution operates, and therefore a comprehensive list is required to be developed as part of the evaluation of any MPoC Solution.
The security controls required to protect payment information depend on the type of payment acceptance channels and cardholder verification methods supported by the MPoC Software. All MPoC Software is required to meet the security objective, requirements, and test requirements in the Core Module. The objective of these security requirements is to ensure the integrity of the COTS device, and to reasonably ensure that the solutions provide adequate security mechanisms, controls, and mitigations to protect the cardholder’s account data and other assets such as cryptographic keys. These requirements assist with protection from unauthorized disclosure, modification, or misuse by restricting the available attack surface and …
Added
p. 49
The functional requirements of the MPoC Software can be further organized into the following components assessed under this Domain:
• A software application or a library that implements payment acceptance and optional supported cardholder verification methods and/or may influence the security of payment data processing on the COTS device (the COTS-based MPoC Software). This software may be executed, in part or as a whole, on the COTS device itself or executed remotely and rendered on the COTS device through other means.
• The back-end attestation and monitoring systems that cannot be entirely (logically) accessed from the merchant environment and that must be capable of being regularly/rapidly updated to respond to new threats and to apply changes or updates to the solutions.
• An optional API provided by the COTS-based MPoC Software that allows other third-party developers to interface with the MPoC Software.
• All contactless kernels used in the MPoC Software, regardless of their …
• A software application or a library that implements payment acceptance and optional supported cardholder verification methods and/or may influence the security of payment data processing on the COTS device (the COTS-based MPoC Software). This software may be executed, in part or as a whole, on the COTS device itself or executed remotely and rendered on the COTS device through other means.
• The back-end attestation and monitoring systems that cannot be entirely (logically) accessed from the merchant environment and that must be capable of being regularly/rapidly updated to respond to new threats and to apply changes or updates to the solutions.
• An optional API provided by the COTS-based MPoC Software that allows other third-party developers to interface with the MPoC Software.
• All contactless kernels used in the MPoC Software, regardless of their …
Added
p. 50
1A-1 Secure Software Requirements Software is to be developed and maintained according to a defined software-security development and lifecycle process. Software developers require knowledge to address software vulnerabilities and emerging risks.
Development of secure software requires knowledge of common attack techniques and vulnerabilities. These vulnerabilities can change over time; therefore, a continuous process to inform software developers about these changes is vital. It is not sufficient to confirm that the developers have been provided with documentation, books, and/or training on secure software development. There needs to be auditable confirmation that developers have knowledge of common vulnerabilities in the language and environment in which they develop software.
To facilitate reliable and accurate payment transactions, the systems and software used as part of the payment-transaction flow must be designed, developed, and maintained in a way that protects the integrity of payment transactions and the confidentiality of all sensitive assets stored, processed, or transmitted in …
Development of secure software requires knowledge of common attack techniques and vulnerabilities. These vulnerabilities can change over time; therefore, a continuous process to inform software developers about these changes is vital. It is not sufficient to confirm that the developers have been provided with documentation, books, and/or training on secure software development. There needs to be auditable confirmation that developers have knowledge of common vulnerabilities in the language and environment in which they develop software.
To facilitate reliable and accurate payment transactions, the systems and software used as part of the payment-transaction flow must be designed, developed, and maintained in a way that protects the integrity of payment transactions and the confidentiality of all sensitive assets stored, processed, or transmitted in …
Added
p. 51
There is no one-size-fits-all method to software security. As a result, entities need flexibility to determine the software security controls and features most appropriate to address their specific business and software risks. As such, it is required that entities possess a robust risk- management practice as an integral part of their business-as-usual operational processes and be able to demonstrate how the implemented security controls are supported by the results of their risk-management practices.
1A-1.2 A public security-flaw-reporting program is implemented to encourage the finding and reporting of vulnerabilities.
1A-1.2.a The tester must confirm through examination that a vulnerability-reporting program exists for the system, and there is evidence of accepting and remediating security vulnerabilities found through this program.
It is required that MPoC Vendors are able to receive and process security-flaw reports regardless of their origin. Therefore, vulnerability reporting programs are required to be publicly accessible, and clearly designated for this purpose. However, it …
1A-1.2 A public security-flaw-reporting program is implemented to encourage the finding and reporting of vulnerabilities.
1A-1.2.a The tester must confirm through examination that a vulnerability-reporting program exists for the system, and there is evidence of accepting and remediating security vulnerabilities found through this program.
It is required that MPoC Vendors are able to receive and process security-flaw reports regardless of their origin. Therefore, vulnerability reporting programs are required to be publicly accessible, and clearly designated for this purpose. However, it …
Added
p. 52
Penetration tests need to be performed by suitably skilled resources and may be performed by resources internal to the MPoC Solution provider if such resources exist. When penetration testing is performed by internal resources, the people performing the testing need to be separate from those who have been involved in the development of the MPoC Software. Skills expected from the resources used for penetration testing include:
• An understanding of EMV protocols and payment processing.
• Skills and experience with mobile security and communications protocols.
• A clear history of penetration testing experience.
Results from annual penetration testing may not exist for newly developed MPoC Software products but need to be provided for any review performed after the first year of validation. However, an initial penetration testing report is required to be available prior to the listing of the MPoC Software or the MPoC Solution (for monolithic solutions).
Penetration testing may be performed by the …
• An understanding of EMV protocols and payment processing.
• Skills and experience with mobile security and communications protocols.
• A clear history of penetration testing experience.
Results from annual penetration testing may not exist for newly developed MPoC Software products but need to be provided for any review performed after the first year of validation. However, an initial penetration testing report is required to be available prior to the listing of the MPoC Software or the MPoC Solution (for monolithic solutions).
Penetration testing may be performed by the …
Added
p. 53
1A-1.4.a The tester must confirm through examination and observation that the MPoC Software implements at a minimum (both of the following):
• Acceptance for at least one of either contact or contactless chip (through COTS-native interfaces, or through use of an external PCI PTS POI).
• COTS-native interfaces for the input at least one of either contactless chip, or cardholder PIN.
The MPoC standard is intended for use with solutions that use COTS-native interfaces for the acceptance of chip- based payment transactions, or cardholder verification methods (such as a PIN). Solutions that rely entirely on non-COTS devices for the acceptance of account data, and do not provide for any COTS-native acceptance of account data or PIN data, are not intended for assessment under this standard.
For example, solutions that support only magnetic-stripe cards, only manual PAN entry, or do not use the COTS device for any acceptance of account data, are not to be …
• Acceptance for at least one of either contact or contactless chip (through COTS-native interfaces, or through use of an external PCI PTS POI).
• COTS-native interfaces for the input at least one of either contactless chip, or cardholder PIN.
The MPoC standard is intended for use with solutions that use COTS-native interfaces for the acceptance of chip- based payment transactions, or cardholder verification methods (such as a PIN). Solutions that rely entirely on non-COTS devices for the acceptance of account data, and do not provide for any COTS-native acceptance of account data or PIN data, are not intended for assessment under this standard.
For example, solutions that support only magnetic-stripe cards, only manual PAN entry, or do not use the COTS device for any acceptance of account data, are not to be …
Added
p. 54
• The MPoC SDKs do not share payment acceptance channel resources (such as a COTS-native NFC interface, or connection to an external card reader).
• The MPoC SDKs do not share payment acceptance channel resources (such as a COTS-native NFC interface, or connection to an external card reader).
• The MPoC SDKs do not share sensitive assets in a way that assets collected in one MPoC SDK could be exposed in cleartext within another MPoC SDK.
• The MPoC SDK to be integrated does not itself integrate any other MPoC SDK.
• The MPoC SDK to be integrated does not itself integrate any other MPoC SDK.
• The MPoC SDK to be integrated is approved and listed as an Isolating SDK, meeting all relevant MPoC requirements.
• The MPoC SDK to be integrated is provided with clear guidance on how it can be securely integrated into another MPoC SDK.
• The MPoC SDK to be integrated is …
• The MPoC SDKs do not share payment acceptance channel resources (such as a COTS-native NFC interface, or connection to an external card reader).
• The MPoC SDKs do not share sensitive assets in a way that assets collected in one MPoC SDK could be exposed in cleartext within another MPoC SDK.
• The MPoC SDK to be integrated does not itself integrate any other MPoC SDK.
• The MPoC SDK to be integrated does not itself integrate any other MPoC SDK.
• The MPoC SDK to be integrated is approved and listed as an Isolating SDK, meeting all relevant MPoC requirements.
• The MPoC SDK to be integrated is provided with clear guidance on how it can be securely integrated into another MPoC SDK.
• The MPoC SDK to be integrated is …
Added
p. 55
Although functionality may be excluded from MPoC assessment scope in this way, any code that executes in the same memory space and/or could impact the security of the in-scope MPoC functionality, must be considered during vulnerability assessments, penetration testing, and laboratory attack costing development.
1A-1.8.a The tester shall confirm that there is a mechanism for a user to validate the version number of the COTS-based MPoC Software.
It is important that the COTS-based MPoC Software is able to be validated as correct, based on the MPoC listing. This includes ensuring there are methods to validate the version of any MPoC SDKs which are integrated into a deployed MPoC Application.
1A-1.8.a The tester shall confirm that there is a mechanism for a user to validate the version number of the COTS-based MPoC Software.
It is important that the COTS-based MPoC Software is able to be validated as correct, based on the MPoC listing. This includes ensuring there are methods to validate the version of any MPoC SDKs which are integrated into a deployed MPoC Application.
Added
p. 56
Any random numbers used for security purposes must be generated using a secure method, such as a DRNG seeded from a value that comes from a trusted source. A COTS device that has a TEE or SE evaluated as a random number generation source directly can be used as a source of entropy (see Requirement 1A-2.2 guidance for more details). Otherwise, a DRNG must be used, seeded from an external trusted source such as a PCI PTS POI or a back-end system such as an HSM, in addition to entropy from the COTS device itself. Combining these different entropy sources ensures that even if one is compromised it does not automatically invalidate the security of the random number generation process as a whole.
This applies to all components and parts of the MPoC Software where random numbers are required to be generated for security functions. Random numbers that are not relied …
This applies to all components and parts of the MPoC Software where random numbers are required to be generated for security functions. Random numbers that are not relied …
Added
p. 57
1A-2.1 Software development documentation provides details about how the MPoC Software generates secure random numbers, as required, on all deployed platforms.
1A-2.1.a The tester must confirm through examination that the software-development processes and practices used, with respect to the generation of random numbers, include the required information and are consistent with the tester’s understanding of the MPoC Software.
Information maintained for random number generation method must include at a minimum:
• The generation and origin of random numbers.
• The expected entropy of any seed values used.
• The seeding period.
• Details of any DRNG algorithms implemented.
This requirement applies to all MPoC Software regardless of where it is executed (i.e., this requirement applies to both back-end and COTS-based MPoC Software software).
Random number generation often sets the security baseline upon which other security controls rely. This may include the generation of padding data for use in certificates, key bundles, and EMV flows as well as the …
1A-2.1.a The tester must confirm through examination that the software-development processes and practices used, with respect to the generation of random numbers, include the required information and are consistent with the tester’s understanding of the MPoC Software.
Information maintained for random number generation method must include at a minimum:
• The generation and origin of random numbers.
• The expected entropy of any seed values used.
• The seeding period.
• Details of any DRNG algorithms implemented.
This requirement applies to all MPoC Software regardless of where it is executed (i.e., this requirement applies to both back-end and COTS-based MPoC Software software).
Random number generation often sets the security baseline upon which other security controls rely. This may include the generation of padding data for use in certificates, key bundles, and EMV flows as well as the …
Added
p. 58
1A-2.2.a The tester must confirm through examination that, where the security of assets requires the use of random numbers, an assessed Random Number Generator (RNG) is used.
This requirement applies to all MPoC Software regardless of where it is executed ⎯i.e., this requirement applies to both back-end and COTS-based MPoC Software.
Examples of situations where random numbers may be required to secure account data include the generation of cryptographic keys, padding prior to encryption of account or PIN data, or security controls such as attestation functions. The EMV Unpredictable Number (UN) used by a payment kernel is not included in the scope of this requirement. However, where a payment kernel requires entropy for other security purposes, these random numbers are in scope of this requirement.
It is required that account data and attestation data are protected with cryptographic controls. Such controls often depend on the quality of random numbers to maintain the designed …
This requirement applies to all MPoC Software regardless of where it is executed ⎯i.e., this requirement applies to both back-end and COTS-based MPoC Software.
Examples of situations where random numbers may be required to secure account data include the generation of cryptographic keys, padding prior to encryption of account or PIN data, or security controls such as attestation functions. The EMV Unpredictable Number (UN) used by a payment kernel is not included in the scope of this requirement. However, where a payment kernel requires entropy for other security purposes, these random numbers are in scope of this requirement.
It is required that account data and attestation data are protected with cryptographic controls. Such controls often depend on the quality of random numbers to maintain the designed …
Added
p. 59
1A-2.3.a The tester must confirm through examination that, where use of a hardware based true Random Number Generator (RNG) on the COTS device cannot be assured, the COTS-based MPoC Software implements a secure DRNG based on well-known international and industry-standard algorithms suitable for cryptography use.
DRNG algorithms used by the COTS-based MPoC Software are required to be secure algorithms and known international standards suitable for cryptography use as specified in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
Homegrown algorithms do not provide enough assurance on the quality of the random numbers provided or the security of the algorithm. It is expected that the algorithms used by the COTS-based MPoC Software use international and industry-standard algorithms⎯e.g., NIST SP 800-90A.
1A-2.4 DRNGs used by the COTS-based MPoC Software are regularly (re)seeded with unpredictable values of sufficient entropy, which are protected for confidentiality and integrity.
1A-2.4.a The tester must confirm through examination …
DRNG algorithms used by the COTS-based MPoC Software are required to be secure algorithms and known international standards suitable for cryptography use as specified in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
Homegrown algorithms do not provide enough assurance on the quality of the random numbers provided or the security of the algorithm. It is expected that the algorithms used by the COTS-based MPoC Software use international and industry-standard algorithms⎯e.g., NIST SP 800-90A.
1A-2.4 DRNGs used by the COTS-based MPoC Software are regularly (re)seeded with unpredictable values of sufficient entropy, which are protected for confidentiality and integrity.
1A-2.4.a The tester must confirm through examination …
Added
p. 60
Note: Appendix C outlines the requirements for minimum entropy of cryptographic keys.
1A-2.5 The DRNG used by the COTS- based MPoC Software uses more than one source of entropy to obtain its seed. Entropy sources include at least one external trusted source, as well as at least one trusted source from the COTS device.
1A-2.5.a The tester must confirm through examination that the DRNG seeding process includes random data from a trusted external source, such as a PCI PTS SCRP or back-end HSM, in addition to at least one trusted source from the COTS device.
The DRNG used by the COTS-based MPoC Software can use different sources of entropy to obtain its seed⎯e.g., one HSM and the COTS platform Random Number Generator (RNG). This increases the effort needed to compromise the DRNG used by the COTS-based MPoC Software.
A trusted source of entropy is one where the entropy output has been validated through testing …
1A-2.5 The DRNG used by the COTS- based MPoC Software uses more than one source of entropy to obtain its seed. Entropy sources include at least one external trusted source, as well as at least one trusted source from the COTS device.
1A-2.5.a The tester must confirm through examination that the DRNG seeding process includes random data from a trusted external source, such as a PCI PTS SCRP or back-end HSM, in addition to at least one trusted source from the COTS device.
The DRNG used by the COTS-based MPoC Software can use different sources of entropy to obtain its seed⎯e.g., one HSM and the COTS platform Random Number Generator (RNG). This increases the effort needed to compromise the DRNG used by the COTS-based MPoC Software.
A trusted source of entropy is one where the entropy output has been validated through testing …
Added
p. 61
Requirement 4A-2.2 specifies that HSMs used in the back-end systems are required to be compliant to FIPS140-2 level 3 (or above) or PCI HSM.
Devices approved to the SCRP approval class have been validated to provide functions to output entropy to attached devices. Where another POI approval class is used to provide external entropy, validation of the entropy provided is required.
The need for an external entropy source does not apply if the COTS platform provides a suitable hardware RNG, such as through an SE or TEE, which is used by the COTS-based MPoC Software. Note that this applies only if a hardware RNG is provided, not to DRNGs, which are the focus of this requirement.
For the purposes of this requirement, “sufficient entropy” is considered to be at least the same number of bits as the effective number of bits of the largest key used.
Devices approved to the SCRP approval class have been validated to provide functions to output entropy to attached devices. Where another POI approval class is used to provide external entropy, validation of the entropy provided is required.
The need for an external entropy source does not apply if the COTS platform provides a suitable hardware RNG, such as through an SE or TEE, which is used by the COTS-based MPoC Software. Note that this applies only if a hardware RNG is provided, not to DRNGs, which are the focus of this requirement.
For the purposes of this requirement, “sufficient entropy” is considered to be at least the same number of bits as the effective number of bits of the largest key used.
Added
p. 62
1A-2.6.a The tester must confirm through examination that the method used to reseed the DRNG ensures sufficient entropy is maintained.
When reseeding the DRNG, the new seed is required to add to the entropy of the DRNG and not be used to re- instantiate the DRNG to a previous or known state. This helps to mitigate the risk that a compromised future seed can be used to completely determine the output of the DRNG.
Adding to the entropy of the DRNG, rather than implanting another seeding process to restart the DRNG, ensures that any attacker who has compromised the current entropy values is not able to determine the output of the DRNG unless they have captured all entropy seeding values. This mitigates attacks against externally supplied entropy, such as that supplied by a PCI PTS SCRP or HSM.
Reseeding methods which combine the collected entropy inputs into a single seed for the DRNG …
When reseeding the DRNG, the new seed is required to add to the entropy of the DRNG and not be used to re- instantiate the DRNG to a previous or known state. This helps to mitigate the risk that a compromised future seed can be used to completely determine the output of the DRNG.
Adding to the entropy of the DRNG, rather than implanting another seeding process to restart the DRNG, ensures that any attacker who has compromised the current entropy values is not able to determine the output of the DRNG unless they have captured all entropy seeding values. This mitigates attacks against externally supplied entropy, such as that supplied by a PCI PTS SCRP or HSM.
Reseeding methods which combine the collected entropy inputs into a single seed for the DRNG …
Added
p. 63
Sensitive assets are required be encrypted on the COTS device for transporting to other components of the MPoC Solution using cryptographic algorithms and modes of operation known to provide suitable levels of security.
All cryptographic keys are required to be used for a single specific purpose. For example, a key used to encrypt account data is not permitted to also be used to protect the integrity of the tamper-detection data.
This requirement does not apply to cryptographic methods applied by the PCI PTS POI for onward processing by the payment processing environment (e.g., PIN block translation functions performed by the PCI PTS SCRP, which have been previously assessed to PCI PTS POI standard).
Security Requirements Test Requirements Guidance Objective: Industry-standard and accepted cryptography is used to protect sensitive assets.
1A-3.1 Software-development documentation provides details about acceptable cryptographic processes and operations to be used for security services.
1A-3.1.a The tester must confirm through examination that the …
All cryptographic keys are required to be used for a single specific purpose. For example, a key used to encrypt account data is not permitted to also be used to protect the integrity of the tamper-detection data.
This requirement does not apply to cryptographic methods applied by the PCI PTS POI for onward processing by the payment processing environment (e.g., PIN block translation functions performed by the PCI PTS SCRP, which have been previously assessed to PCI PTS POI standard).
Security Requirements Test Requirements Guidance Objective: Industry-standard and accepted cryptography is used to protect sensitive assets.
1A-3.1 Software-development documentation provides details about acceptable cryptographic processes and operations to be used for security services.
1A-3.1.a The tester must confirm through examination that the …
Added
p. 64
1A-3.2.a The tester must confirm through examination that the cryptographic algorithms and the key sizes comply with Appendix C Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
To withstand attacks, the solution is required to use the most robust and current encryption algorithms and key sizes. Legacy algorithms may have known weaknesses and provide security levels that are unsuitable given current and projected computing power.
Use of recognized cryptographic methods ensures that the solution adheres to industry-tested and accepted algorithms and appropriate key lengths that deliver effective key strength and proper key management practices. Proprietary or “home-grown” algorithms do not provide this assurance and are not permitted.
Hash functions are used to provide integrity and support authenticity controls over data. They may be used on their own or in combination with other cryptographic controls.
RSA 2048 bit may be used to load AES keys (128 bit to 256 bit) into the COTS-based …
To withstand attacks, the solution is required to use the most robust and current encryption algorithms and key sizes. Legacy algorithms may have known weaknesses and provide security levels that are unsuitable given current and projected computing power.
Use of recognized cryptographic methods ensures that the solution adheres to industry-tested and accepted algorithms and appropriate key lengths that deliver effective key strength and proper key management practices. Proprietary or “home-grown” algorithms do not provide this assurance and are not permitted.
Hash functions are used to provide integrity and support authenticity controls over data. They may be used on their own or in combination with other cryptographic controls.
RSA 2048 bit may be used to load AES keys (128 bit to 256 bit) into the COTS-based …
Added
p. 65
1A-3.3.a The tester must confirm through examination and observation that the public keys used in the MPoC Software are protected for authenticity and integrity.
Certificates are often used to exchange public keys. Verification of certificate signatures can be used to authenticate the public key and meta data. This is normally guaranteed by verifying the complete certificate chain up to the certificate authority.
However, in the case of MPoC Software, some certificates may be signed by the MPoC Solution provider and not by an established CA. These certificates can be authenticated by using application package signature as the root of trust protecting the application-embedded certificate(s) against tampering.
For certificates used by the MPoC Software that are signed by the MPoC Solution provider, a self-signed certificate embedded in the signed MPoC Software package may be used to validate other certificates.
Requirements for the security of signing operations performed by the MPoC Solution provider can be found …
Certificates are often used to exchange public keys. Verification of certificate signatures can be used to authenticate the public key and meta data. This is normally guaranteed by verifying the complete certificate chain up to the certificate authority.
However, in the case of MPoC Software, some certificates may be signed by the MPoC Solution provider and not by an established CA. These certificates can be authenticated by using application package signature as the root of trust protecting the application-embedded certificate(s) against tampering.
For certificates used by the MPoC Software that are signed by the MPoC Solution provider, a self-signed certificate embedded in the signed MPoC Software package may be used to validate other certificates.
Requirements for the security of signing operations performed by the MPoC Solution provider can be found …
Added
p. 66
1A-3.5.a The tester must confirm through examination that the derivation and key check functions present in the MPoC Software are one- way functions and do not expose information about the keys used in the derivation or check process.
Derivation and key check functions need to be selected such that an attacker cannot gain information of the key used as part of the derivation or check process (the “derivation key” or “original key”) by observing the derived value, or a set of them.
Examples of derivation functions that do not reveal the derivation key are encryption and one-way functions such as CMAC.
1A-3.5.b The tester must confirm through examination that it is not possible to calculate the derivation or key check function output without prior knowledge of the derivation or key check material, including the cryptographic key used.
Derivation and key check functions need to be selected such that an attacker cannot gain information of the key used as part of the derivation or check process (the “derivation key” or “original key”) by observing the derived value, or a set of them.
Examples of derivation functions that do not reveal the derivation key are encryption and one-way functions such as CMAC.
1A-3.5.b The tester must confirm through examination that it is not possible to calculate the derivation or key check function output without prior knowledge of the derivation or key check material, including the cryptographic key used.
Added
p. 67
• Distribution/conveyance
• Established cryptoperiods
• Replacement/rotation when the cryptoperiod is reached
• Key compromise and recovery
• Emergency procedures to destroy and replace keys
• Accountability and audit Secret and private cryptographic keys that are relied upon for security are required to be unique per device/application, with the exception of keys protected through software-protected cryptography means, which are used to establish an initial trust anchor prior to provisioning unique keys to the MPoC Application. Shared public keys are acceptable, but methods and procedures for revoking compromised public key/private key pairs must be implemented. For additional information about public key Infrastructure (PKI), refer to X9.79-4.
Operations that involve secret or private cryptographic keys are to be performed using split knowledge. Split knowledge requires that no one person can determine any single bit of a secret or private cryptographic key. Split knowledge can be provided in the following ways:
• Storing keys on secure cryptographic devices (SCD) approved …
• Established cryptoperiods
• Replacement/rotation when the cryptoperiod is reached
• Key compromise and recovery
• Emergency procedures to destroy and replace keys
• Accountability and audit Secret and private cryptographic keys that are relied upon for security are required to be unique per device/application, with the exception of keys protected through software-protected cryptography means, which are used to establish an initial trust anchor prior to provisioning unique keys to the MPoC Application. Shared public keys are acceptable, but methods and procedures for revoking compromised public key/private key pairs must be implemented. For additional information about public key Infrastructure (PKI), refer to X9.79-4.
Operations that involve secret or private cryptographic keys are to be performed using split knowledge. Split knowledge requires that no one person can determine any single bit of a secret or private cryptographic key. Split knowledge can be provided in the following ways:
• Storing keys on secure cryptographic devices (SCD) approved …
Added
p. 68
1A-4.1 An inventory of all keys used by the MPoC Software is maintained.
1A-4.1.a The tester must confirm through examination that the information provided matches their understanding of the MPoC Solution and contains the required information for all keys used in the MPoC Software.
For each key, the information must be provided containing at a minimum:
• ID or name of the key
• Uniqueness (e.g., per transaction, device, solution, etc.)
• Algorithm and key size
• Cryptoperiod (key lifetime)
• Key-generation location (Name of server, application, database, device, etc.)
• Key-generation method (SCD, PCI PTS POI, OS, SE, TEE, software, etc.)
• Key usage location (name of server, application, database, device, etc. For symmetric keys this is at least 2 locations.)
• Key loading (where relevant, how is the key loaded?)
• Confidentiality protection during transport
• Confidentiality protection during storage
• Integrity protection during transport
• Integrity protection during storage
• Removal/destruction A good key management process, whether manual or automated, is based …
1A-4.1.a The tester must confirm through examination that the information provided matches their understanding of the MPoC Solution and contains the required information for all keys used in the MPoC Software.
For each key, the information must be provided containing at a minimum:
• ID or name of the key
• Uniqueness (e.g., per transaction, device, solution, etc.)
• Algorithm and key size
• Cryptoperiod (key lifetime)
• Key-generation location (Name of server, application, database, device, etc.)
• Key-generation method (SCD, PCI PTS POI, OS, SE, TEE, software, etc.)
• Key usage location (name of server, application, database, device, etc. For symmetric keys this is at least 2 locations.)
• Key loading (where relevant, how is the key loaded?)
• Confidentiality protection during transport
• Confidentiality protection during storage
• Integrity protection during transport
• Integrity protection during storage
• Removal/destruction A good key management process, whether manual or automated, is based …
Added
p. 69
A cryptoperiod needs to be identified for each key based on a risk assessment, and keys are required to be changed when this period is reached. Additionally, keys are required to be immediately prevented from use. Compromised keys should be destroyed and replaced promptly upon confirmation 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 cleartext keys or key components.
• Defining roles and responsibilities for Key Custodians and Key Managers.
The key inventory must include any public keys or certificates used by the solution. Where possible, certificates should be maintained in a standard format such as X.509. When certificates are used or stored in other formats, information about the certificate use and context may need to be stored in another format.
For example, a specific protocol or implementation may use public keys in …
• Minimizing access to keys to the fewest number of custodians necessary.
• Enforcing split knowledge and dual control for activities involving cleartext keys or key components.
• Defining roles and responsibilities for Key Custodians and Key Managers.
The key inventory must include any public keys or certificates used by the solution. Where possible, certificates should be maintained in a standard format such as X.509. When certificates are used or stored in other formats, information about the certificate use and context may need to be stored in another format.
For example, a specific protocol or implementation may use public keys in …
Added
p. 70
It is not sufficient to send such keys protected only using secure channel protection, such as TLS. The keys are required to have their confidentiality separately protected, such as through use of a key encryption key dedicated for that purpose.
Keys should be created, and securely maintained, within the environment where they are used⎯e.g., hardware- backed keystore, software-protected cryptography, secure element, etc. Alternatively, cryptographic keys may be securely imported in an encrypted form, such that keys are not exposed outside of the environment where they were generated.
Use of the same cryptographic keys for transport and storage can cause additional risk of exposure to the operational keys being transported or stored.
Entering secret or private cryptographic keys as cleartext exposes the value of that key. Implementations need to ensure that the entry of secret or private cryptographic keys does not reduce the security of those keys.
Implementations may export a secret or private key …
Keys should be created, and securely maintained, within the environment where they are used⎯e.g., hardware- backed keystore, software-protected cryptography, secure element, etc. Alternatively, cryptographic keys may be securely imported in an encrypted form, such that keys are not exposed outside of the environment where they were generated.
Use of the same cryptographic keys for transport and storage can cause additional risk of exposure to the operational keys being transported or stored.
Entering secret or private cryptographic keys as cleartext exposes the value of that key. Implementations need to ensure that the entry of secret or private cryptographic keys does not reduce the security of those keys.
Implementations may export a secret or private key …
Added
p. 71
1A-4.3.a The tester must confirm through examination and observation that if secret and private keys are embedded in the COTS-based MPoC Software, they are in a form that is protected with software-based protection measures such as software-protected cryptography.
When secret or private keys are embedded in the MPoC Software, they need to be protected using software methods such as software-protected cryptography.
Embedding of secret or private cryptographic keys in aspects of the MPoC Software other than the COTS- based MPoC Software is not permitted.
1A-4.3.b The tester must confirm through examination that any software protection measures used are compliant to the 1B-2.x requirements of this standard.
1A-4.3.c The tester must confirm through examination that secret or private cryptographic keys are not embedded in any other aspects of the MPoC Software, other than the COTS-based MPoC Software.
1A-4.4 Certificates that exist on the COTS device as part of the COTS OS are considered in scope if …
When secret or private keys are embedded in the MPoC Software, they need to be protected using software methods such as software-protected cryptography.
Embedding of secret or private cryptographic keys in aspects of the MPoC Software other than the COTS- based MPoC Software is not permitted.
1A-4.3.b The tester must confirm through examination that any software protection measures used are compliant to the 1B-2.x requirements of this standard.
1A-4.3.c The tester must confirm through examination that secret or private cryptographic keys are not embedded in any other aspects of the MPoC Software, other than the COTS-based MPoC Software.
1A-4.4 Certificates that exist on the COTS device as part of the COTS OS are considered in scope if …
Added
p. 72
1A-4.6.a The tester must confirm through examination and observation that the MPoC Software is created to support the use of HSMs for storage and operation of cryptographic keys in the back-end environments.
Operational key management controls in Domain 4 require the use of HSMs to secure cryptographic keys used in the MPoC Solution. To ensure that any separately listed MPoC Software product does not prevent compliance to later operational requirements, it is important that the software is created to support HSM use.
Cryptographic keys which are used to secure data that may be exposed in back-end environments, such as A&M data or PAN data, may be operated outside of a HSM if the keys are unique per session.
This requirement applies to secret and private keys which are used for securing sensitive assets, including other cryptographic keys, in the back-end environment.
The implementation and operation of HSMs is assessed in Domain 4.
1A-4.6.b The tester …
Operational key management controls in Domain 4 require the use of HSMs to secure cryptographic keys used in the MPoC Solution. To ensure that any separately listed MPoC Software product does not prevent compliance to later operational requirements, it is important that the software is created to support HSM use.
Cryptographic keys which are used to secure data that may be exposed in back-end environments, such as A&M data or PAN data, may be operated outside of a HSM if the keys are unique per session.
This requirement applies to secret and private keys which are used for securing sensitive assets, including other cryptographic keys, in the back-end environment.
The implementation and operation of HSMs is assessed in Domain 4.
1A-4.6.b The tester …
Added
p. 73
1A-4.8.a The tester must confirm through examination and observation that the MPoC Software does not allow for a cryptographic key to be protected by a key of lesser strength.
Note: An exception to this requirement is when an AES key may be protected by an RSA key of 2048 bits during transmission if the COTS platform prevents use of larger RSA key sizes. See Requirement 1A-3.2.
It is common for cryptographic keys to be protected in some way by another cryptographic key•either through encryption (to provide confidentiality protections) or a digital signature or (H)MAC (to provide authenticity protections). If the key providing protections is weaker than the key it is protecting, this can become the most easily exploited path to the compromise of that key.
The minimum strength of cryptographic keys used in an MPoC Product is noted in Appendix C: Minimum Equivalent Key Sizes and Strengths for Approved Algorithms. A key encrypting …
Note: An exception to this requirement is when an AES key may be protected by an RSA key of 2048 bits during transmission if the COTS platform prevents use of larger RSA key sizes. See Requirement 1A-3.2.
It is common for cryptographic keys to be protected in some way by another cryptographic key•either through encryption (to provide confidentiality protections) or a digital signature or (H)MAC (to provide authenticity protections). If the key providing protections is weaker than the key it is protecting, this can become the most easily exploited path to the compromise of that key.
The minimum strength of cryptographic keys used in an MPoC Product is noted in Appendix C: Minimum Equivalent Key Sizes and Strengths for Approved Algorithms. A key encrypting …
Added
p. 74
1A-4.10.a The tester must confirm through examination and observation that any cryptographic keys used to encrypt account data on the COTS device are unique per installation of COTS-based MPoC Software.
Where secret or private cryptographic keys are shared across different systems, the risk of compromise for those keys increases. To ensure that the compromise of any one MPoC Application does not affect the security of any other MPoC Application, the cryptographic keys used to encrypt account data must be unique to each instance of an installed COTS-based MPoC Software (not just unique to a particular MPoC Application version).
This includes public keys, if account data is encrypted with those keys, to reduce the impact of any (potential) exposure of private keys in the back-end environment.
A common public key may be implemented for manual PAN entry, when used for the purposes of technical fallback.
Where common public keys are used for technical fallback, implementations …
Where secret or private cryptographic keys are shared across different systems, the risk of compromise for those keys increases. To ensure that the compromise of any one MPoC Application does not affect the security of any other MPoC Application, the cryptographic keys used to encrypt account data must be unique to each instance of an installed COTS-based MPoC Software (not just unique to a particular MPoC Application version).
This includes public keys, if account data is encrypted with those keys, to reduce the impact of any (potential) exposure of private keys in the back-end environment.
A common public key may be implemented for manual PAN entry, when used for the purposes of technical fallback.
Where common public keys are used for technical fallback, implementations …
Added
p. 75
1A-4.11.a The tester must confirm through examination and observation that if any secret and private cryptographic keys related to account data encryption are exposed in the rich execution environment of the COTS device, those keys are implemented using a unique key per transaction key management method which provides forward secrecy.
Note: This requirement does not apply to keys used only once per application install⎯e.g., during initial provisioning⎯or keys which are used to generate future keys (but cannot be used to derive historic keys).
Although cryptographic keys related to account data security are required to never be stored in cleartext within the rich execution environment, these keys may be exposed in the rich execution environment as cleartext during cryptographic operations.
Where this occurs, it is important that the increased risk of exposure of these keys is mitigated by ensuring that the keys are unique per transaction and implement perfect forward secrecy.
There should not be …
Note: This requirement does not apply to keys used only once per application install⎯e.g., during initial provisioning⎯or keys which are used to generate future keys (but cannot be used to derive historic keys).
Although cryptographic keys related to account data security are required to never be stored in cleartext within the rich execution environment, these keys may be exposed in the rich execution environment as cleartext during cryptographic operations.
Where this occurs, it is important that the increased risk of exposure of these keys is mitigated by ensuring that the keys are unique per transaction and implement perfect forward secrecy.
There should not be …
Added
p. 76
• Between the COTS-based MPoC Software and external card reader(s)
• Between the COTS-based MPoC Software and back-end environments If internal systems such as a TEE or SE are used, and these provide for the use of a secure channel to protect communications between itself and the REE, then these protections must be used.
It may be acceptable for the COTS-based MPoC Software that is integrating an MPoC SDK to manage the configuration of a secure channel, or implement the secure channel in its entirety, as long as the MPoC SDK used is designed to allow for this and has specific guidance on the secure configuration and implementation of the secure channel. This guidance must be included in the MPoC SDK evaluation, and adherence to this guidance by the COTS-based MPoC Software integrating the MPoC SDK is to be validated by the MPoC Laboratory during the integration testing (which will include validation …
• Between the COTS-based MPoC Software and back-end environments If internal systems such as a TEE or SE are used, and these provide for the use of a secure channel to protect communications between itself and the REE, then these protections must be used.
It may be acceptable for the COTS-based MPoC Software that is integrating an MPoC SDK to manage the configuration of a secure channel, or implement the secure channel in its entirety, as long as the MPoC SDK used is designed to allow for this and has specific guidance on the secure configuration and implementation of the secure channel. This guidance must be included in the MPoC SDK evaluation, and adherence to this guidance by the COTS-based MPoC Software integrating the MPoC SDK is to be validated by the MPoC Laboratory during the integration testing (which will include validation …
Added
p. 77
1A-5.1 Secure channels established by the MPoC Software are documented.
1A-5.1.a The tester must confirm through examination that the vendor secure channel information matches the design of the solution. The information must include at a minimum:
• The endpoints of each secure channel.
• The root of trust used for each secure channel.
• Cryptography supported by each secure channel.
• How the channel is established and how mutual authentication is guaranteed.
A secure design of the communication channels assists with protecting assets during transit. For a resilient design, it is necessary to have a clear understanding of how the secure channel is established and the root of trust relied upon for that secure channel.
The COTS-based MPoC Software will often establish more than one secure channel for its operation. It is not necessary that a single root of trust is used for all secure channels established.
Mutual authentication is not required upon first execution of the COTS-based …
1A-5.1.a The tester must confirm through examination that the vendor secure channel information matches the design of the solution. The information must include at a minimum:
• The endpoints of each secure channel.
• The root of trust used for each secure channel.
• Cryptography supported by each secure channel.
• How the channel is established and how mutual authentication is guaranteed.
A secure design of the communication channels assists with protecting assets during transit. For a resilient design, it is necessary to have a clear understanding of how the secure channel is established and the root of trust relied upon for that secure channel.
The COTS-based MPoC Software will often establish more than one secure channel for its operation. It is not necessary that a single root of trust is used for all secure channels established.
Mutual authentication is not required upon first execution of the COTS-based …
Added
p. 78
1A-5.3.a The tester must confirm through examination and observation that the keys used for the secure channels are unique per session except by chance.
Logical secure channels rely on cryptographic protections. Ensuring unique keys per session helps to isolate each connection, prevent replay or relay attacks, and complicate potential compromises of the cryptographic controls.
1A-5.4 Logical secure channels implement cryptographic controls for confidentiality, integrity, and authenticity.
1A-5.4.a The tester must confirm through examination that any logical secure channels implement cryptography compliant with Appendix C of this standard.
Mutual authentication between the communicating components is required to be based on cryptography that aligns with Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
1A-5.5 Each secure channel provides mutual authentication to uniquely identify each component prior to the exchange of sensitive assets and protect against MITM and replay attacks.
1A-5.5.a The tester must confirm through examination and observation that the secure channels that extend …
Logical secure channels rely on cryptographic protections. Ensuring unique keys per session helps to isolate each connection, prevent replay or relay attacks, and complicate potential compromises of the cryptographic controls.
1A-5.4 Logical secure channels implement cryptographic controls for confidentiality, integrity, and authenticity.
1A-5.4.a The tester must confirm through examination that any logical secure channels implement cryptography compliant with Appendix C of this standard.
Mutual authentication between the communicating components is required to be based on cryptography that aligns with Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
1A-5.5 Each secure channel provides mutual authentication to uniquely identify each component prior to the exchange of sensitive assets and protect against MITM and replay attacks.
1A-5.5.a The tester must confirm through examination and observation that the secure channels that extend …
Added
p. 79
1A-5.6.a The tester must confirm through examination, observation, and testing that the secure channels are not susceptible to downgrade attacks.
A downgrade attack may result in switching to a previous version of a protocol or a lower security setting of the same protocol, such as reducing the level of encryption applied.
The solution needs to prevent the downgrade of any protection levels provided by the secure channels.
1A-5.7 Assets are encrypted and authenticated at the data level during transport, and do not solely rely on the protections provided by any secure channel being used.
1A-5.7.a The tester must confirm through examination and observation that assets in transit are protected using application-level encryption applied at the data level in addition to the security and encryption provided by the secure channel.
Note: This requirement does not apply to platform- based attestation, which may be protected solely by the secure channel.
The MPoC Software assets need to be protected …
A downgrade attack may result in switching to a previous version of a protocol or a lower security setting of the same protocol, such as reducing the level of encryption applied.
The solution needs to prevent the downgrade of any protection levels provided by the secure channels.
1A-5.7 Assets are encrypted and authenticated at the data level during transport, and do not solely rely on the protections provided by any secure channel being used.
1A-5.7.a The tester must confirm through examination and observation that assets in transit are protected using application-level encryption applied at the data level in addition to the security and encryption provided by the secure channel.
Note: This requirement does not apply to platform- based attestation, which may be protected solely by the secure channel.
The MPoC Software assets need to be protected …
Added
p. 80
Security Requirements Test Requirements Guidance Objective: Assets that are transmitted through APIs to third-party applications are protected.
1A-6.1 Documentation of any API exposed to third parties exists.
1A-6.1.a The tester must confirm through examination that information provided includes the following at a minimum:
• UI display data that is communicated through third-party APIs exposed by the MPoC Software.
• Guidance for users of the API about how to securely use the API and protect the UI display data on the external application.
As part of the security design of the MPoC Software, the UI display data that is communicated to external parties, including the exposed API, need to be identified. As the handling of these UI display data involves an external third-party application, information needs to be included that guides the external application to take appropriate measures to protect the assets.
UI elements may include personalization graphics, names, and so forth for specific users, merchants, or …
1A-6.1 Documentation of any API exposed to third parties exists.
1A-6.1.a The tester must confirm through examination that information provided includes the following at a minimum:
• UI display data that is communicated through third-party APIs exposed by the MPoC Software.
• Guidance for users of the API about how to securely use the API and protect the UI display data on the external application.
As part of the security design of the MPoC Software, the UI display data that is communicated to external parties, including the exposed API, need to be identified. As the handling of these UI display data involves an external third-party application, information needs to be included that guides the external application to take appropriate measures to protect the assets.
UI elements may include personalization graphics, names, and so forth for specific users, merchants, or …
Added
p. 81
1A-6.3.a The tester must confirm through examination that the protection type of the communicated assets is maintained in any API interface.
Refer to table 3 in the introductory parts of this standard for examples of MPoC assets.
If assets, such as transaction data or A&M data, are to be communicated through an API, these assets are required to maintain the protection type that is required in the overall MPoC Solution. For example, if an identifier requires confidentiality protection, it is required to be communicated with its confidentiality protected and not in cleartext.
Protection may be provided using cryptographic means if the assets are to be exposed in untrusted memory or processing spaces, or through the shared memory protections provided by an integrated MPoC Software.
This requirement should be considered in conjunction with Requirement 1D-1.2, which covers the encryption of account data.
Non-sensitive payment initiation data, such as a payment amount, is an exception to this …
Refer to table 3 in the introductory parts of this standard for examples of MPoC assets.
If assets, such as transaction data or A&M data, are to be communicated through an API, these assets are required to maintain the protection type that is required in the overall MPoC Solution. For example, if an identifier requires confidentiality protection, it is required to be communicated with its confidentiality protected and not in cleartext.
Protection may be provided using cryptographic means if the assets are to be exposed in untrusted memory or processing spaces, or through the shared memory protections provided by an integrated MPoC Software.
This requirement should be considered in conjunction with Requirement 1D-1.2, which covers the encryption of account data.
Non-sensitive payment initiation data, such as a payment amount, is an exception to this …
Added
p. 82
1B-1 Software Security Mechanisms The security mechanisms that protect the COTS-based MPoC Software from attacks, such as reverse engineering, modification, and monitoring, also help protect the MPoC Solution assets as they are entered into, processed by, and transferred from the COTS device. The security mechanisms not only have a preventive role in the MPoC Software’s security; they also work as detection mechanisms where they are tied to the A&M.
Many types of security mechanisms exist, each with different strengths and protection goals. It is important that the security design of the MPoC Software considers the coverage of the security mechanisms and the interaction between them. Furthermore, it is important that the level of protection (strength) of the security mechanisms is evaluated.
Many types of security mechanisms exist, each with different strengths and protection goals. It is important that the security design of the MPoC Software considers the coverage of the security mechanisms and the interaction between them. Furthermore, it is important that the level of protection (strength) of the security mechanisms is evaluated.
Added
p. 83
1B-1.1 The security mechanisms implemented in the COTS-based MPoC Software are documented.
1B-1.1.a The tester must confirm through examination that the information provided is complete and consistent with the tester’s understanding of the solution. This information must include the list of security mechanisms included in the COTS-based MPoC Software, with the following items for each mechanism at a minimum:
• What the mechanism protects against.
• The party responsible for providing and/or implementing the security mechanism (i.e., the COTS-based MPoC Software or the platform).
• The location or component where the mechanism is implemented (e.g., REE, TEE, SE).
• The original source and provider of the mechanism (e.g., third-party vendor, MPoC Software vendor).
The COTS-based MPoC Software is required to implement protections to mitigate attacks on the COTS- based MPoC Software and assets, both during execution and when the MPoC Software is installed but not currently being executed. Multiple individual protection methods are likely to be …
1B-1.1.a The tester must confirm through examination that the information provided is complete and consistent with the tester’s understanding of the solution. This information must include the list of security mechanisms included in the COTS-based MPoC Software, with the following items for each mechanism at a minimum:
• What the mechanism protects against.
• The party responsible for providing and/or implementing the security mechanism (i.e., the COTS-based MPoC Software or the platform).
• The location or component where the mechanism is implemented (e.g., REE, TEE, SE).
• The original source and provider of the mechanism (e.g., third-party vendor, MPoC Software vendor).
The COTS-based MPoC Software is required to implement protections to mitigate attacks on the COTS- based MPoC Software and assets, both during execution and when the MPoC Software is installed but not currently being executed. Multiple individual protection methods are likely to be …
Added
p. 84
1B-1.2.a The tester must confirm through examination that the assets are correctly identified according to the tester’s understanding of the MPoC Software. The information provided must include, but not be limited to, the following:
• Assets name and description.
• Components that have access to the assets in cleartext or have enough information to recover it in cleartext⎯e.g., encrypted assets and encryption key.
• How the assets are protected according to their required protection type⎯e.g., confidentiality, integrity, authenticity⎯and lifecycle stages (generation, transmission, storage, process, and removal).
• Code flows involving assets.
Assets in the context of this requirement are resources or information valuable to the stakeholder or operation of the MPoC Solution that need protection. Examples of assets include cryptographic keys, account data, information supplied or used as part of an attestation system, etc. Refer to Table 4 for examples of MPoC assets.
The tester needs to use their understanding of the operation and security implementation …
• Assets name and description.
• Components that have access to the assets in cleartext or have enough information to recover it in cleartext⎯e.g., encrypted assets and encryption key.
• How the assets are protected according to their required protection type⎯e.g., confidentiality, integrity, authenticity⎯and lifecycle stages (generation, transmission, storage, process, and removal).
• Code flows involving assets.
Assets in the context of this requirement are resources or information valuable to the stakeholder or operation of the MPoC Solution that need protection. Examples of assets include cryptographic keys, account data, information supplied or used as part of an attestation system, etc. Refer to Table 4 for examples of MPoC assets.
The tester needs to use their understanding of the operation and security implementation …
Added
p. 85
1B-1.3.a The tester must confirm through examination that where security mechanisms used by the COTS-based MPoC Software rely on previous approvals or certifications that the evidence and scope of prior evaluation/certification is sufficient to ensure security to the assets they protect.
If the security mechanisms used by the COTS-based MPoC Software depend on an underlying system such as a TEE, SE, etc., there needs to be assurance on the security of the underlying system. Any prior certifications relied upon are required to be relevant to the payment acceptance and security scope of an MPoC Solution.
Examples of certifications that may be acceptable, include, but are not limited to:
• Common Criteria (at EAL4 with AVA_VAN 5)
• Common Criteria with Global Platform TEE PP
• EMVCo Chip and Global Platform
• PCI-PTS POI, PCI HSM
• FIPS 140-2/FIPS 140-3 (Level 3+) The tester needs to ensure that the scope and methods used in the prior evaluation are …
If the security mechanisms used by the COTS-based MPoC Software depend on an underlying system such as a TEE, SE, etc., there needs to be assurance on the security of the underlying system. Any prior certifications relied upon are required to be relevant to the payment acceptance and security scope of an MPoC Solution.
Examples of certifications that may be acceptable, include, but are not limited to:
• Common Criteria (at EAL4 with AVA_VAN 5)
• Common Criteria with Global Platform TEE PP
• EMVCo Chip and Global Platform
• PCI-PTS POI, PCI HSM
• FIPS 140-2/FIPS 140-3 (Level 3+) The tester needs to ensure that the scope and methods used in the prior evaluation are …
Added
p. 86
1B-1.4.a The tester must confirm through examination about how exposure of cleartext assets is minimized and how it is ensured that such assets are cleared from storage locations immediately after use. The removal method must not rely on language/platform mechanisms⎯e.g., garbage collectors.
Note: This requirement applies to whenever sensitive assets are no longer required, including after early termination of a transaction due to A&M or operational controls.
When assets (that are required to be protected for confidentiality) are to be present in cleartext in memory, the time they are present needs to be reduced as much as possible. This reduces the time that the data is exposed as cleartext and assists in ensuring that memory dumps or reuse do not expose previously processed values.
This requirement does not apply to areas of memory or COTS subsystems that the COTS-based MPoC Software does not have direct access or control over (such as a COTS …
Note: This requirement applies to whenever sensitive assets are no longer required, including after early termination of a transaction due to A&M or operational controls.
When assets (that are required to be protected for confidentiality) are to be present in cleartext in memory, the time they are present needs to be reduced as much as possible. This reduces the time that the data is exposed as cleartext and assists in ensuring that memory dumps or reuse do not expose previously processed values.
This requirement does not apply to areas of memory or COTS subsystems that the COTS-based MPoC Software does not have direct access or control over (such as a COTS …
Added
p. 87
• Hide data, such as (but not necessarily limited to), function/method names, strings and other data, and asset.
• Modify the code flow of the COTS-based MPoC Software.
Refer to the “Security Objective and Assets” section for details on assets, and the definition of sensitive assets.
Obfuscation reduces the efficacy of common code decompilation tools. Obfuscation methods may include, but are not limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, and symbol renaming, or protections provided by virtualized execution environments that are specifically designed to provide software-based protections to code execution flows (such as a vTEE).
If the COTS-based MPoC Software is provided as a number of files (libraries), the calls and interfaces between the libraries are required to be obfuscated as well.
Obfuscation is intended to complicate the reverse engineering of the software and execution process of the COTS-based MPoC Software.
These protections are not required across all code but …
• Modify the code flow of the COTS-based MPoC Software.
Refer to the “Security Objective and Assets” section for details on assets, and the definition of sensitive assets.
Obfuscation reduces the efficacy of common code decompilation tools. Obfuscation methods may include, but are not limited to, control-flow and data obfuscation, execution of code sections in remote/cloud environments, and symbol renaming, or protections provided by virtualized execution environments that are specifically designed to provide software-based protections to code execution flows (such as a vTEE).
If the COTS-based MPoC Software is provided as a number of files (libraries), the calls and interfaces between the libraries are required to be obfuscated as well.
Obfuscation is intended to complicate the reverse engineering of the software and execution process of the COTS-based MPoC Software.
These protections are not required across all code but …
Added
p. 88
1B-1.6.a The tester must confirm through examination, observation, and testing that code and data provisioned to the COTS-based MPoC Software after installation is transmitted, managed, and stored securely.
Note: This requirement applies to data that is security sensitive⎯e.g., configuration files, WebViews, keys, etc. as well as to all code that is executed by the COTS-based MPoC Software (that is not already part of the COTS Platform)⎯and merchant identifiers used as part of the transaction process.
After installation, the COTS-based MPoC Software needs to be provided with unique (configuration) data to be differentiated from other installations. During provisioning/personalization assets such as key material, configuration, and unique identifiers may be provisioned to the COTS device. Data provisioned this way is not covered by the authenticity controls of the OS store and so protections need to be provided by the MPoC Solution itself.
This includes any merchant identifiers required for the processing of payments, the management …
Note: This requirement applies to data that is security sensitive⎯e.g., configuration files, WebViews, keys, etc. as well as to all code that is executed by the COTS-based MPoC Software (that is not already part of the COTS Platform)⎯and merchant identifiers used as part of the transaction process.
After installation, the COTS-based MPoC Software needs to be provided with unique (configuration) data to be differentiated from other installations. During provisioning/personalization assets such as key material, configuration, and unique identifiers may be provisioned to the COTS device. Data provisioned this way is not covered by the authenticity controls of the OS store and so protections need to be provided by the MPoC Solution itself.
This includes any merchant identifiers required for the processing of payments, the management …
Added
p. 89
1B-1.7.a The tester must confirm through examination and observation that the COTS-based MPoC Software implements industry best practice with regard to the detection of compromised platforms and protection of COTS-based MPoC Software assets.
In the context of this requirement, detection of compromised platforms may include detection of rooting or jailbreaking, as well as other methods that may be used to compromise the integrity and security of the execution environment (such as the use of emulator systems), where this could impact the security of sensitive assets.
Some MPoC platforms provide attestation functions that can be used by applications to assess the platform integrity.
These mechanisms may be stronger than the ones provided by the COTS-based MPoC Software because they have insights into the platform. However, it may be possible to bypass them under certain circumstances.
Understanding the limitation of these mechanisms and their proper implementation is essential for robust software hardening.
Emulators facilitate the dynamic analysis …
In the context of this requirement, detection of compromised platforms may include detection of rooting or jailbreaking, as well as other methods that may be used to compromise the integrity and security of the execution environment (such as the use of emulator systems), where this could impact the security of sensitive assets.
Some MPoC platforms provide attestation functions that can be used by applications to assess the platform integrity.
These mechanisms may be stronger than the ones provided by the COTS-based MPoC Software because they have insights into the platform. However, it may be possible to bypass them under certain circumstances.
Understanding the limitation of these mechanisms and their proper implementation is essential for robust software hardening.
Emulators facilitate the dynamic analysis …
Added
p. 90
1B-1.8.a The tester must confirm through examination and observation that the COTS-based MPoC Software implements methods to bind itself to the COTS device upon initial execution. It must not be possible for the bound COTS-based MPoC Software to operate on a different device or emulator platform, even if:
• Data (e.g., files) can be shared from the original COTS device to the cloned device.
• The second device is under attacker control.
After the COTS-based MPoC Software is installed, it goes through a process upon first execution to uniquely bind that COTS-based MPoC Software to the specific COTS device on which it is stored.
The unique (configuration) data may also hold assets related to the merchant account or other operational data.
The COTS-based MPoC Software is required to implement controls to prevent the extraction of data from the COTS-based MPoC Software such that it is not possible to create a “clone” of the COTS-based MPoC …
• Data (e.g., files) can be shared from the original COTS device to the cloned device.
• The second device is under attacker control.
After the COTS-based MPoC Software is installed, it goes through a process upon first execution to uniquely bind that COTS-based MPoC Software to the specific COTS device on which it is stored.
The unique (configuration) data may also hold assets related to the merchant account or other operational data.
The COTS-based MPoC Software is required to implement controls to prevent the extraction of data from the COTS-based MPoC Software such that it is not possible to create a “clone” of the COTS-based MPoC …
Added
p. 91
1B-1.9.a The tester must confirm through examination and observation that removal of the COTS-based MPoC Software results in the deletion of all sensitive assets from the COTS device.
Provisioned and unique (configuration) data is not permitted to remain on the COTS device after the COTS- based MPoC Software has been removed. Although applications often do not have any control over their deletion, consideration during the design of the application can ensure that data is handled in a way that it is removed from the COTS device when the application is removed.
Where deletion by the COTS OS cannot be relied upon, the use of cryptographic deletion may be used. Cryptographic deletion refers to when data is encrypted with strong cryptography, and the decryption key is deleted. In such cases, even when the data remains, it may be considered removed for the purposes of this requirement.
Provisioned and unique (configuration) data is not permitted to remain on the COTS device after the COTS- based MPoC Software has been removed. Although applications often do not have any control over their deletion, consideration during the design of the application can ensure that data is handled in a way that it is removed from the COTS device when the application is removed.
Where deletion by the COTS OS cannot be relied upon, the use of cryptographic deletion may be used. Cryptographic deletion refers to when data is encrypted with strong cryptography, and the decryption key is deleted. In such cases, even when the data remains, it may be considered removed for the purposes of this requirement.
Added
p. 92
1B-1.10.a The tester must confirm through examination and observation that there is no option to turn on developer or debugger mode.
Prior to the release of a software build, it is common for applications to include debug or developer features that expose data and functions that would be an unacceptable risk in production systems. Such code or features are required to be removed from the distributed software object, not just disabled, prior to distribution.
However, this requirement does not imply or enforce the need for two code streams (a test stream, and a production stream). Removal of test or debug code during a build process may be an acceptable way to meet this requirement. Telemetry and data collection features may remain in a COTS-based MPoC Software for the purposes of collecting A&M data or validating the ongoing correctness of the solution. However, any remaining software features are not permitted to bypass or …
Prior to the release of a software build, it is common for applications to include debug or developer features that expose data and functions that would be an unacceptable risk in production systems. Such code or features are required to be removed from the distributed software object, not just disabled, prior to distribution.
However, this requirement does not imply or enforce the need for two code streams (a test stream, and a production stream). Removal of test or debug code during a build process may be an acceptable way to meet this requirement. Telemetry and data collection features may remain in a COTS-based MPoC Software for the purposes of collecting A&M data or validating the ongoing correctness of the solution. However, any remaining software features are not permitted to bypass or …
Added
p. 93
1B-1.11.a Through examination of the COTS-based MPoC Software implemented outside the REE, the tester must confirm that the exposed interface between this code and the REE is the minimum required to perform its task.
The COTS-based MPoC Software may implement functionality external to the REE of the COTS device using TEEs, SEs, or other separate execution environments such as external devices or servers.
It is required that this non-REE code is protected against tampering, either to interfere with its intended execution process or to subvert or intercept interfaces between this code and the REE.
Compliance to this requirement may be achieved through demonstration of previous evaluations, such as through EMVCo SBMP, GP, or similar schemes. Documentation needs to clearly include authenticatable evidence of such evaluation⎯i.e., a vendor assertion of evaluation or compliance is insufficient.
The tester is expected to validate the scope of any previous testing to ensure that any gaps between the previous …
The COTS-based MPoC Software may implement functionality external to the REE of the COTS device using TEEs, SEs, or other separate execution environments such as external devices or servers.
It is required that this non-REE code is protected against tampering, either to interfere with its intended execution process or to subvert or intercept interfaces between this code and the REE.
Compliance to this requirement may be achieved through demonstration of previous evaluations, such as through EMVCo SBMP, GP, or similar schemes. Documentation needs to clearly include authenticatable evidence of such evaluation⎯i.e., a vendor assertion of evaluation or compliance is insufficient.
The tester is expected to validate the scope of any previous testing to ensure that any gaps between the previous …
Added
p. 94
1B-1.12.a The tester must confirm through examination and observation that any isolating SDK is implemented in a way that secures the memory and sensitive assets of that SDK from any MPoC Application that integrates the SDK.
Many modern operating systems allow for a single application to launch multiple processes and provide to these processes their own virtual memory space. This new memory space can be isolated from other processes, even if those processes are owned by the same user.
In cases where the MPoC Laboratory is able to validate that the COTS Platform OS’s targeted by the MPoC SDK are able to provide memory isolation protection to the cleartext sensitive assets, use of separate processes may be sufficient to meet the requirements for an Isolating SDK.
In assessing whether an SDK can be classified as Isolating, only attacks against the built MPoC Application need to be considered. Assessment of the on-going processes used …
Many modern operating systems allow for a single application to launch multiple processes and provide to these processes their own virtual memory space. This new memory space can be isolated from other processes, even if those processes are owned by the same user.
In cases where the MPoC Laboratory is able to validate that the COTS Platform OS’s targeted by the MPoC SDK are able to provide memory isolation protection to the cleartext sensitive assets, use of separate processes may be sufficient to meet the requirements for an Isolating SDK.
In assessing whether an SDK can be classified as Isolating, only attacks against the built MPoC Application need to be considered. Assessment of the on-going processes used …
Added
p. 95
1B-1.14.a The tester must confirm through examination, observation, and testing the anti- tampering protections for COTS-based MPoC Software assets by attempting to expose or modify sensitive COTS-based MPoC Software data stored or processed on the COTS device without detection. The tester must provide a costing of this attack based on the method outlined in Appendix B. Attack Costing Framework. This requirement is passed if the most feasible attack cannot be costed for less than 25 points.
Note: It is not intended that the tester attempts to extract all the security assets of the COTS-based MPoC Software, but only those assets that represent the least amount of effort for an expert attacker, or the biggest gain⎯e.g., PIN.
The COTS-based MPoC Software may store data on the COTS device. This data could be abused to change the behavior of the COTS-based MPoC Software in unintended ways⎯e.g., change COTS-based MPoC Software configuration parameters.
Protection of assets …
Note: It is not intended that the tester attempts to extract all the security assets of the COTS-based MPoC Software, but only those assets that represent the least amount of effort for an expert attacker, or the biggest gain⎯e.g., PIN.
The COTS-based MPoC Software may store data on the COTS device. This data could be abused to change the behavior of the COTS-based MPoC Software in unintended ways⎯e.g., change COTS-based MPoC Software configuration parameters.
Protection of assets …
Added
p. 96
Examination only may be sufficient in cases where the assets are managed by a component or system that has undergone previous evaluation to a known standard, such as a HSM compliant to the PCI HSM requirements. However, in all cases, it is expected that the tester will perform sufficient testing to validate the security of the overall MPoC Solution.
Added
p. 97
Another way to protect cryptographic operations and sensitive assets is through software protections, such as software-protected cryptography, where the cryptographic functions and storage methods used to protect the cryptographic keys are obfuscated such that extraction of the sensitive assets or tracing of the execution flow of the cryptographic process is rendered computationally expensive. This includes systems such as white-box cryptography, and implementations where cryptographic operations are executed in a software- protected execution environment, such as a vTEE.
When purely software methods are used to protect cryptographic keys, such as with software-protected cryptography, the specific instance used in the COTS-based MPoC Software is to be changed periodically, where the maximum period is less than the estimated time it would take to reverse engineer the software protections. It is acceptable to have two sets of keys during the changeover period, but all old keys are to be invalidated when the new keys are …
When purely software methods are used to protect cryptographic keys, such as with software-protected cryptography, the specific instance used in the COTS-based MPoC Software is to be changed periodically, where the maximum period is less than the estimated time it would take to reverse engineer the software protections. It is acceptable to have two sets of keys during the changeover period, but all old keys are to be invalidated when the new keys are …
Added
p. 98
1B-2.1 Cryptography protected with software-only means is documented.
1B-2.1.a The tester must confirm through examination that the provided information is complete based on the tester’s understanding of the COTS-based MPoC Software. The information must include at a minimum:
• Which keys are secured using software- protected cryptography, in whole or in part.
• What algorithms are supported or implemented by the software-protected cryptography system used.
• How many instances of software-protected cryptography are present for each algorithm.
• The security mechanisms present in the software-protected cryptography.
• The key hierarchy of the keys protected by software-protected cryptography.
Clear information is required to outline how each cryptographic key is protected so that coverage can be confirmed to be comprehensive, and flaws can be identified easily.
For this requirement, it is required that the information provided covers all cryptographic keys that would otherwise be exposed in cleartext within the memory of the REE of the COTS device were it not …
1B-2.1.a The tester must confirm through examination that the provided information is complete based on the tester’s understanding of the COTS-based MPoC Software. The information must include at a minimum:
• Which keys are secured using software- protected cryptography, in whole or in part.
• What algorithms are supported or implemented by the software-protected cryptography system used.
• How many instances of software-protected cryptography are present for each algorithm.
• The security mechanisms present in the software-protected cryptography.
• The key hierarchy of the keys protected by software-protected cryptography.
Clear information is required to outline how each cryptographic key is protected so that coverage can be confirmed to be comprehensive, and flaws can be identified easily.
For this requirement, it is required that the information provided covers all cryptographic keys that would otherwise be exposed in cleartext within the memory of the REE of the COTS device were it not …
Added
p. 99
1B-2.3.a The tester must confirm through examination and observation that the implementation of software protected cryptography within the COTS-based MPoC Software only implements the operations required.
Usually, cryptographic implementations support at least two operations⎯e.g., encryption and decryption. If the COTS-based MPoC Software needs only to encrypt data before sending it to the back-end, the decryption operation is not required to be present in the COTS- based MPoC Software, since it helps reverse the encryption operation and may pose an additional security risk.
1B-2.4 The software-protected cryptography implementation, where it is used for the protection of secret or private keys embedded into the COTS-based MPoC Software, is required to be replaced before the estimated time needed to break the implementation. Replacement must include changing of any cryptographic keys, or other assets, within the software protected cryptographic implementation.
1B-2.4.a The tester must document an estimated exploitation time needed for an expert attacker with physical access …
Usually, cryptographic implementations support at least two operations⎯e.g., encryption and decryption. If the COTS-based MPoC Software needs only to encrypt data before sending it to the back-end, the decryption operation is not required to be present in the COTS- based MPoC Software, since it helps reverse the encryption operation and may pose an additional security risk.
1B-2.4 The software-protected cryptography implementation, where it is used for the protection of secret or private keys embedded into the COTS-based MPoC Software, is required to be replaced before the estimated time needed to break the implementation. Replacement must include changing of any cryptographic keys, or other assets, within the software protected cryptographic implementation.
1B-2.4.a The tester must document an estimated exploitation time needed for an expert attacker with physical access …
Added
p. 100
1B-2.5.a The tester must confirm through examination, observation, and interview (where appropriate), that the software-protected cryptography implementation supports secure key management processes, as well as secure key generation where key generation is implemented, including:
• Dual control and split knowledge of keys.
• Key generation methods that ensure keys have at least the same entropy as their effective key strength.
This requirement covers the implementation and support systems for any software-protected cryptography. Operation of those systems is covered under the operational requirements of this standard.
This requirement does not enforce the manual handling of cryptographic keys (as key components). Proper use of back-end HSMs may provide for dual control and split knowledge across the keys.
1B-2.6 Cryptographic keys deployed within a software-protected cryptography implementation is not used for encryption of account data or secret/private cryptographic keys during transmission.
1B-2.6.a The tester must confirm through examination and observation that keys deployed through the software-protected cryptographic implementation are …
• Dual control and split knowledge of keys.
• Key generation methods that ensure keys have at least the same entropy as their effective key strength.
This requirement covers the implementation and support systems for any software-protected cryptography. Operation of those systems is covered under the operational requirements of this standard.
This requirement does not enforce the manual handling of cryptographic keys (as key components). Proper use of back-end HSMs may provide for dual control and split knowledge across the keys.
1B-2.6 Cryptographic keys deployed within a software-protected cryptography implementation is not used for encryption of account data or secret/private cryptographic keys during transmission.
1B-2.6.a The tester must confirm through examination and observation that keys deployed through the software-protected cryptographic implementation are …
Added
p. 101
The security of any software-protected cryptography implementation is reliant upon periodic updates, which is validated in a separate requirement.
The intent of this requirement is that the security of the software protected cryptography implementation is tested directly. Therefore, this testing is to be performed without additional security controls such as A&M or anti-rooting. The vendor of the MPoC Software or Software Protected Cryptography implementation may need to provide a test artifact for the testing process.
Costing of the attack must consider the difficulty of disabling these features, and any code-lifting or emulation that is required as part of the attack. Code lifting can allow for the extraction of the software-protected cryptography implementation so that it can be executed in an environment or context under the control of an attacker.
Usually, this is done for analysis of the cryptographic implementation and can, if successful, permit fault injections, oracle attacks, etc.
A successful attack need not …
The intent of this requirement is that the security of the software protected cryptography implementation is tested directly. Therefore, this testing is to be performed without additional security controls such as A&M or anti-rooting. The vendor of the MPoC Software or Software Protected Cryptography implementation may need to provide a test artifact for the testing process.
Costing of the attack must consider the difficulty of disabling these features, and any code-lifting or emulation that is required as part of the attack. Code lifting can allow for the extraction of the software-protected cryptography implementation so that it can be executed in an environment or context under the control of an attacker.
Usually, this is done for analysis of the cryptographic implementation and can, if successful, permit fault injections, oracle attacks, etc.
A successful attack need not …
Added
p. 102
The attestation data may be determined in various ways, such as through a health-check interface that can be accessed by the prover. Attestation provides necessary assurance to the verifier that established and expected security controls at the prover are in an acceptable state and have not been tampered with. Organizations developing A&M components are subject to these requirements.
There are two types of attestations in MPoC Solutions, where the goal is to assess the integrity of the COTS-based MPoC Software, and where the goal is to assess the integrity of the COTS platform.
It is a requirement of this standard that the attestation system and monitoring system together form the attestation and monitoring (A&M). The attestation and monitoring (A&M) includes a back-end system that can interpret and respond to the attestation results (i.e., the attestation results are required to be monitored). The COTS-based MPoC Software can attest to the COTS platform or …
There are two types of attestations in MPoC Solutions, where the goal is to assess the integrity of the COTS-based MPoC Software, and where the goal is to assess the integrity of the COTS platform.
It is a requirement of this standard that the attestation system and monitoring system together form the attestation and monitoring (A&M). The attestation and monitoring (A&M) includes a back-end system that can interpret and respond to the attestation results (i.e., the attestation results are required to be monitored). The COTS-based MPoC Software can attest to the COTS platform or …
Added
p. 103
Security Requirements Test Requirements Guidance Objective: The attestation and monitoring (A&M) covers all assets and processing of the COTS-based MPoC Software throughout its lifecycle.
1C-1.1 Documentation on the coverage of the attestation and monitoring (A&M) exists.
1C-1.1.a The tester must confirm through examination that the required information exists, including, but not limited to:
• What checks are included in the COTS-based MPoC Software attestation and monitoring (A&M) and, if applicable, which parts of their result are checked or verified.
• What is covered by the checks (e.g., code, data, application, OS, cryptographic, etc.).
• When, where, and under which circumstances are these checks executed and validated.
• If a security mechanism covers code (e.g., checksums), which parts of the code are covered.
The attestation and monitoring (A&M) is a vital part of the overall security of an MPoC Solution and, therefore, the coverage provided by the attestation and monitoring (A&M) parts of the MPoC Software mut be …
1C-1.1 Documentation on the coverage of the attestation and monitoring (A&M) exists.
1C-1.1.a The tester must confirm through examination that the required information exists, including, but not limited to:
• What checks are included in the COTS-based MPoC Software attestation and monitoring (A&M) and, if applicable, which parts of their result are checked or verified.
• What is covered by the checks (e.g., code, data, application, OS, cryptographic, etc.).
• When, where, and under which circumstances are these checks executed and validated.
• If a security mechanism covers code (e.g., checksums), which parts of the code are covered.
The attestation and monitoring (A&M) is a vital part of the overall security of an MPoC Solution and, therefore, the coverage provided by the attestation and monitoring (A&M) parts of the MPoC Software mut be …
Added
p. 104
Although applications often do not have any control over their deployment and decommissioning, consideration during the design of the application can ensure that data is handled securely during these phases. The intent of this requirement is that the A&M validates the correct operation according to the design so that deployment and decommissioning can be validated as having been performed securely.
1C-1.3 The attestation and monitoring (A&M) checks cover the entire security- sensitive COTS-based MPoC Software code and execution flows that handle assets.
1C-1.3.a The tester must confirm through examination that:
• The COTS-based MPoC Software is protected by the attestation and monitoring (A&M) at runtime.
• The A&M checks provide coverage over all COTS-based MPoC Software code, execution flow, and assets.
• Some A&M validation checks are always active during execution of the COTS-based MPoC Software providing protection against COTS operating modes that may impact security.
The A&M checks are required to be implemented at different …
1C-1.3 The attestation and monitoring (A&M) checks cover the entire security- sensitive COTS-based MPoC Software code and execution flows that handle assets.
1C-1.3.a The tester must confirm through examination that:
• The COTS-based MPoC Software is protected by the attestation and monitoring (A&M) at runtime.
• The A&M checks provide coverage over all COTS-based MPoC Software code, execution flow, and assets.
• Some A&M validation checks are always active during execution of the COTS-based MPoC Software providing protection against COTS operating modes that may impact security.
The A&M checks are required to be implemented at different …
Added
p. 105
1C-1.4.a The tester must confirm through examination that the A&M system covers the COTS Platform and COTS-based MPoC Software and is able to attest its security state.
The A&M is required to provide assurance that the COTS- based MPoC Software is not running on a compromised COTS platform⎯e.g., rooted, jailbroken, etc. Although the COTS-based MPoC Software can use its own checks to perform this verification, there may be value in providing data to the A&M back-end for additional validation or updates to local checks.
For example, this may include validating the following information:
• If the COTS device is rooted, jailbroken, or operating in developer mode (where this may impact the security of MPoC assets).
• Modifications or tampering attempt events of the COTS-based MPoC Software and COTS execution environment.
• The version of the COTS OS and COTS-based MPoC Software, including detection of any rollback attempts.
• Details on the status of any COTS-native interfaces …
The A&M is required to provide assurance that the COTS- based MPoC Software is not running on a compromised COTS platform⎯e.g., rooted, jailbroken, etc. Although the COTS-based MPoC Software can use its own checks to perform this verification, there may be value in providing data to the A&M back-end for additional validation or updates to local checks.
For example, this may include validating the following information:
• If the COTS device is rooted, jailbroken, or operating in developer mode (where this may impact the security of MPoC assets).
• Modifications or tampering attempt events of the COTS-based MPoC Software and COTS execution environment.
• The version of the COTS OS and COTS-based MPoC Software, including detection of any rollback attempts.
• Details on the status of any COTS-native interfaces …
Added
p. 106
Similarly, detection of a roll-back of the COTS OS may not necessarily result in immediate response from the A&M system but may instead be noted and used in correlation with other signals from that same COTS device to determine the appropriate action, in line with the Attestation and Monitoring policy.
A COTS Platform may not be able to attest that a specific COTS-native interface is “secure,” and in such cases it may be sufficient for the attestation functions to validate that the interface is present, in good order, and not accessed by other applications.
COTS platforms may provide their own logging and monitoring of interfaces that could be used for the entry of account data. For example, an OS may log all traffic on the NFC or touch interfaces. The attestation policy and system baseline should consider and account for these COTS devices.
Detection of any individual item of concern during an A&M …
A COTS Platform may not be able to attest that a specific COTS-native interface is “secure,” and in such cases it may be sufficient for the attestation functions to validate that the interface is present, in good order, and not accessed by other applications.
COTS platforms may provide their own logging and monitoring of interfaces that could be used for the entry of account data. For example, an OS may log all traffic on the NFC or touch interfaces. The attestation policy and system baseline should consider and account for these COTS devices.
Detection of any individual item of concern during an A&M …
Added
p. 107
Security Requirements Test Requirements Guidance Objective: Sufficient information is collected to detect and mitigate threats to the MPoC Solution.
1C-2.1 The information that is collected for the purposes of attestation and monitoring is documented.
1C-2.1.a The tester must confirm through examination that the data collected for A&M purposes includes sufficient information to attest the COTS platform, MPoC Application, and MPoC SDK (where present), and identify any attached payment- card acceptance devices.
Knowledge of the signals collected from the COTS device is needed to develop the A&M service properly and assess the quality of the A&M.
This requirement includes information collected on the COTS device for A&M purposes and is not related directly to security checks (e.g., COTS device model, OS version, etc.).
A&M data where the COTS device or COTS-based MPoC Software is the prover may be assignable to that COTS device based on the method of collection (i.e., the signals collected can only have …
1C-2.1 The information that is collected for the purposes of attestation and monitoring is documented.
1C-2.1.a The tester must confirm through examination that the data collected for A&M purposes includes sufficient information to attest the COTS platform, MPoC Application, and MPoC SDK (where present), and identify any attached payment- card acceptance devices.
Knowledge of the signals collected from the COTS device is needed to develop the A&M service properly and assess the quality of the A&M.
This requirement includes information collected on the COTS device for A&M purposes and is not related directly to security checks (e.g., COTS device model, OS version, etc.).
A&M data where the COTS device or COTS-based MPoC Software is the prover may be assignable to that COTS device based on the method of collection (i.e., the signals collected can only have …
Added
p. 108
1C-2.2.a The tester must confirm through examination and observation that the A&M data sent to the A&M back-end reflects the current state of the COTS-based MPoC Software, COTS platform, and peripheral devices, in addition to any security relevant changes or measurements that have occurred since the last communication to the A&M back-end.
The measurements sent to the A&M back-end are required to reflect the current state of the solution. Stale measurements may provide a false sense of security or be used by an attacker to replace more current data.
However, an attacker may attempt to perform attacks during the window of time between communications to the A&M back-end, so that their attacks go undetected. Therefore, in addition to ensuring the most current data, it is important that any security relevant A&M data is also transmitted to the back-end when communication is performed.
1C-2.2.b The tester must confirm through examination and observation that any …
The measurements sent to the A&M back-end are required to reflect the current state of the solution. Stale measurements may provide a false sense of security or be used by an attacker to replace more current data.
However, an attacker may attempt to perform attacks during the window of time between communications to the A&M back-end, so that their attacks go undetected. Therefore, in addition to ensuring the most current data, it is important that any security relevant A&M data is also transmitted to the back-end when communication is performed.
1C-2.2.b The tester must confirm through examination and observation that any …
Added
p. 109
1C-2.4.a The tester must confirm through examination and observation that the A&M functions include checks that execute at all times when the COTS-based MPoC Software is executing to detect COTS operating modes that may impact security.
On-device attestation can be time and resource intensive, and therefore full attestation checks cannot be continually performed. However, some checks are less intensive
• such as the check for entry into developer mode, or activation of debug functionality
•and can be more easily performed in the background at all times.
To ensure the security of the MPoC Solution, it is important that the checks which are more easily deployed at all times, are not left until a full attestation is required.
On-device attestation can be time and resource intensive, and therefore full attestation checks cannot be continually performed. However, some checks are less intensive
• such as the check for entry into developer mode, or activation of debug functionality
•and can be more easily performed in the background at all times.
To ensure the security of the MPoC Solution, it is important that the checks which are more easily deployed at all times, are not left until a full attestation is required.
Added
p. 110
Security Requirements Test Requirements Guidance Objective: The A&M must be able to provide suitable responses to mitigate potential attacks.
1C-3.1 Documentation exists that describes the actions that can be taken if the attestation and monitoring (A&M) indicates that the COTS-based MPoC Software, or COTS platform is potentially compromised.
1C-3.1.a The tester must confirm through examination that the provided information is sufficient and consistent with the tester’s understanding of the solution.
The A&M system needs to implement actions when tampering of the COTS-based MPoC Software is detected.
Information outlining the functions provided by the attestation and monitoring (A&M) to indications of compromise is required. It is likely that the attestation and monitoring (A&M) back-end is able to be configured to act in different ways and, where this is possible, the documentation needs to reflect how such configuration is managed securely.
Common responses from the attestation and monitoring (A&M) include account deactivation, assets deletion, and temporal suspension …
1C-3.1 Documentation exists that describes the actions that can be taken if the attestation and monitoring (A&M) indicates that the COTS-based MPoC Software, or COTS platform is potentially compromised.
1C-3.1.a The tester must confirm through examination that the provided information is sufficient and consistent with the tester’s understanding of the solution.
The A&M system needs to implement actions when tampering of the COTS-based MPoC Software is detected.
Information outlining the functions provided by the attestation and monitoring (A&M) to indications of compromise is required. It is likely that the attestation and monitoring (A&M) back-end is able to be configured to act in different ways and, where this is possible, the documentation needs to reflect how such configuration is managed securely.
Common responses from the attestation and monitoring (A&M) include account deactivation, assets deletion, and temporal suspension …
Added
p. 111
1C-3.2.a The tester must confirm through examination and observation that the COTS-based MPoC Software is able to report any potential tampering events to the A&M back-end.
If a tamper attempt is detected by the COTS-based MPoC Software, it is required that the COTS-based MPoC Software informs the A&M back-end. This can assist with the understanding of risk for similar types of solutions, as well as helping the A&M responses to be further tuned or developed to accommodate similar types of attacks.
Additionally, as the COTS-based MPoC Software is considered to execute in a potentially hostile environment, communication of potential tamper events assists in aligning back-end responses with expected responses from the COTS-based MPoC Software. For example, if a COTS-based MPoC Software instance detects an attempted compromise and performs actions to halt payment processing, further payment processing from that instance received by the back-end system should be considered suspect.
1C-3.3 It is possible for …
If a tamper attempt is detected by the COTS-based MPoC Software, it is required that the COTS-based MPoC Software informs the A&M back-end. This can assist with the understanding of risk for similar types of solutions, as well as helping the A&M responses to be further tuned or developed to accommodate similar types of attacks.
Additionally, as the COTS-based MPoC Software is considered to execute in a potentially hostile environment, communication of potential tamper events assists in aligning back-end responses with expected responses from the COTS-based MPoC Software. For example, if a COTS-based MPoC Software instance detects an attempted compromise and performs actions to halt payment processing, further payment processing from that instance received by the back-end system should be considered suspect.
1C-3.3 It is possible for …
Added
p. 112
1C-3.4.a The tester must confirm through examination and observation that the COTS-based MPoC Software prevents further payment processing after 60 minutes of continuous operation without a passing response from the A&M back-end component when not operating in offline payment acceptance mode.
When not operating in offline payment-processing mode, the COTS-based MPoC Software is required to receive communications from the A&M back-end component at least every hour to ensure that the MPoC Solution is operating securely and that the COTS-based MPoC Software has passed all attestation checks successfully.
In the context of this requirement, a “passing response” from the A&M back-end component indicates that the A&M system has performed and validated all attestation checks required by the MPoC Software attestation policy.
This requirement does not supersede any other requirements for consistent A&M monitoring or checks to be performed on execution or prior to specific functions such as PIN entry.
This requirement does not replace Requirement …
When not operating in offline payment-processing mode, the COTS-based MPoC Software is required to receive communications from the A&M back-end component at least every hour to ensure that the MPoC Solution is operating securely and that the COTS-based MPoC Software has passed all attestation checks successfully.
In the context of this requirement, a “passing response” from the A&M back-end component indicates that the A&M system has performed and validated all attestation checks required by the MPoC Software attestation policy.
This requirement does not supersede any other requirements for consistent A&M monitoring or checks to be performed on execution or prior to specific functions such as PIN entry.
This requirement does not replace Requirement …
Added
p. 113
1C-3.6 A&M results that may require the cessation of payment acceptance are protected against manipulation during transmission to the payment back-end.
1C-3.6.a The tester must confirm through examination and observation that any A&M results that may require the cessation of payment acceptance are protected against manipulation during transmission to the payment back-end.
A&M results that indicate that the payment acceptance must be halted are likely to result from a compromised COTS device or COTS-based MPoC Software. This may impact the ability for the payment back-end to receive accurate and correct data from the COTS device.
This requirement does not prevent or preclude operational models that provide the COTS-based MPoC Software with explicit approval to perform payments on a per-transaction basis.
For the purposes of this requirement, blocking or otherwise preventing receipt of A&M results to the back- end
•for the purposes of continuing payment processing on a compromised system
•is considered manipulation.
1C-3.6.a The tester must confirm through examination and observation that any A&M results that may require the cessation of payment acceptance are protected against manipulation during transmission to the payment back-end.
A&M results that indicate that the payment acceptance must be halted are likely to result from a compromised COTS device or COTS-based MPoC Software. This may impact the ability for the payment back-end to receive accurate and correct data from the COTS device.
This requirement does not prevent or preclude operational models that provide the COTS-based MPoC Software with explicit approval to perform payments on a per-transaction basis.
For the purposes of this requirement, blocking or otherwise preventing receipt of A&M results to the back- end
•for the purposes of continuing payment processing on a compromised system
•is considered manipulation.
Added
p. 114
Security Requirements Test Requirements Guidance Objective: The attestation and monitoring (A&M), including the collection and transmission of data on the COTS device, is protected from compromise.
1C-4.1 The protections provided to the attestation and monitoring (A&M) are documented.
1C-4.1.a The tester must confirm through examination that the information provided sufficiently details the anti-tamper protections that have been validated through the COTS-based MPoC Software testing process.
Modification of the attestation and monitoring (A&M) data or code may, in practice, allow for the bypass of the security mechanisms. The A&M component on the COTS-based MPoC Software needs to be protected against tampering.
Documentation is required to indicate what protections are provided, so that these can be confirmed as in-place during the lab validation.
1C-4.2 The local time source used by the COTS-based MPoC Software is secured against tampering or alteration.
1C-4.2.a The tester must confirm through examination and observation that the local time source is protected against tampering.
The …
1C-4.1 The protections provided to the attestation and monitoring (A&M) are documented.
1C-4.1.a The tester must confirm through examination that the information provided sufficiently details the anti-tamper protections that have been validated through the COTS-based MPoC Software testing process.
Modification of the attestation and monitoring (A&M) data or code may, in practice, allow for the bypass of the security mechanisms. The A&M component on the COTS-based MPoC Software needs to be protected against tampering.
Documentation is required to indicate what protections are provided, so that these can be confirmed as in-place during the lab validation.
1C-4.2 The local time source used by the COTS-based MPoC Software is secured against tampering or alteration.
1C-4.2.a The tester must confirm through examination and observation that the local time source is protected against tampering.
The …
Added
p. 115
Validation of the local time source during connections to the attestation and monitoring (A&M) helps to identify attacks that may attempt to manipulate this source. Additionally, it helps to ensure that the attestation and monitoring (A&M) can correctly and accurately interpret any time stamps used in transmitted attestation and monitoring (A&M) data.
1C-4.3 The A&M back-end is able to detect failures in the A&M functions within the COTS-based MPoC Software.
1C-4.3.a The tester must confirm through examination and observation that the A&M back- end is able to detect and respond to failures in the COTS-based MPoC Software A&M functions.
The A&M back-end is required to monitor and be able to respond to situations where there is an indication of failure in the COTS-based MPoC Software. For example, if attestation data is repeated when it should not be, or is not present, when the COTS-based MPoC Software appears to be continuing to transact, it …
1C-4.3 The A&M back-end is able to detect failures in the A&M functions within the COTS-based MPoC Software.
1C-4.3.a The tester must confirm through examination and observation that the A&M back- end is able to detect and respond to failures in the COTS-based MPoC Software A&M functions.
The A&M back-end is required to monitor and be able to respond to situations where there is an indication of failure in the COTS-based MPoC Software. For example, if attestation data is repeated when it should not be, or is not present, when the COTS-based MPoC Software appears to be continuing to transact, it …
Added
p. 116
Security Requirements Test Requirements Guidance Objective: Sufficient guidance and features are provided to allow for the secure integration and operation of the attestation and monitoring (A&M).
1C-5.1 A&M back-end operation security guidance information that explains how the attestation and monitoring (A&M) is securely configured and operated exists.
1C-5.1.a The tester must confirm through examination that the attestation and monitoring (A&M) back-end operation security guidance contains the required information and comment on its sufficiency to securely configure the attestation and monitoring (A&M) back-end according to the tester’s understanding of the MPoC Software. The documentation must include the following at a minimum:
• How to configure the attestation and monitoring (A&M), including the offline policy, securely.
• A base configuration for the attestation and monitoring (A&M).
• Specific integration requirements that must be fulfilled to integrate the attestation and monitoring (A&M) component securely.
This information is required even when the attestation and monitoring (A&M) is operated by the …
1C-5.1 A&M back-end operation security guidance information that explains how the attestation and monitoring (A&M) is securely configured and operated exists.
1C-5.1.a The tester must confirm through examination that the attestation and monitoring (A&M) back-end operation security guidance contains the required information and comment on its sufficiency to securely configure the attestation and monitoring (A&M) back-end according to the tester’s understanding of the MPoC Software. The documentation must include the following at a minimum:
• How to configure the attestation and monitoring (A&M), including the offline policy, securely.
• A base configuration for the attestation and monitoring (A&M).
• Specific integration requirements that must be fulfilled to integrate the attestation and monitoring (A&M) component securely.
This information is required even when the attestation and monitoring (A&M) is operated by the …
Added
p. 117
1C-5.2.a The tester must confirm through examination that the security guidance includes at a minimum:
• How to deploy the A&M software component in a production-ready configuration⎯e.g., not debugging enabled.
• How to integrate the A&M software component into the MPoC Application.
• Specific dependencies of security checks on OS versions or COTS platforms.
Integration of the A&M functionality is required for all MPoC implementations. This security guidance may be a formal document for MPoC Software components that are to be operated by third parties, or internal knowledge base solutions for vendors performing all operations required of an MPoC Solution.
1C-5.3 Security guidance information details what A&M features are configurable, the processes for setting or changing these configurations, and how the applicable settings may affect the security and functionality of the overall MPoC Solution.
1C-5.3.a The tester must confirm through examination that the configuration options of the A&M are documented, including their possible settings.
An A&M can …
• How to deploy the A&M software component in a production-ready configuration⎯e.g., not debugging enabled.
• How to integrate the A&M software component into the MPoC Application.
• Specific dependencies of security checks on OS versions or COTS platforms.
Integration of the A&M functionality is required for all MPoC implementations. This security guidance may be a formal document for MPoC Software components that are to be operated by third parties, or internal knowledge base solutions for vendors performing all operations required of an MPoC Solution.
1C-5.3 Security guidance information details what A&M features are configurable, the processes for setting or changing these configurations, and how the applicable settings may affect the security and functionality of the overall MPoC Solution.
1C-5.3.a The tester must confirm through examination that the configuration options of the A&M are documented, including their possible settings.
An A&M can …
Added
p. 118
Only account data-entry systems specifically addressed by this standard may be used within an MPoC Solution. Future updates to this standard may include or support other methods of account data entry.
1D-1 Account Data Entry and Encryption This Section covers the requirements for all COTS-native account data-entry methods, and how this data must be secured as it is entered and processed. These requirements do not apply to data captured through a PCI PTS POI or non-PTS approved MSR device. PAN that is truncated in accordance with relevant PCI DSS FAQs is not considered in scope for these requirements.
Security Requirements Test Requirements Guidance Objective: All account data-entry methods are documented and provide encryption for onward processing.
1D-1.1 Documentation exists that details how account data is entered and secured.
1D-1.1.a For each of the account data-entry methods supported by the solution, the tester must confirm through examination that the required information for integration with the …
1D-1 Account Data Entry and Encryption This Section covers the requirements for all COTS-native account data-entry methods, and how this data must be secured as it is entered and processed. These requirements do not apply to data captured through a PCI PTS POI or non-PTS approved MSR device. PAN that is truncated in accordance with relevant PCI DSS FAQs is not considered in scope for these requirements.
Security Requirements Test Requirements Guidance Objective: All account data-entry methods are documented and provide encryption for onward processing.
1D-1.1 Documentation exists that details how account data is entered and secured.
1D-1.1.a For each of the account data-entry methods supported by the solution, the tester must confirm through examination that the required information for integration with the …
Added
p. 119
1D-1.2.a The tester must confirm through examination that for any account data-entry methods implemented on the COTS device, the card data is encrypted either immediately upon entry or immediately after any required processing through associated payment kernels.
Account data is required to be encrypted at the earliest to reduce the opportunity window in which account data can be compromised in cleartext. Normally, this is done in the external card reader itself or in the COTS-based MPoC Software when a COTS native interface, such as COTS- native NFC, is used.
Although it is not the scope of this requirement to assess the encryption of any external account data capture systems, such as a PCI PTS POI or non-PTS approved MSR, the assessor is required to confirm that there is no functionality on the COTS device that would expect this data to be provided in cleartext or allow for the decryption of the account …
Account data is required to be encrypted at the earliest to reduce the opportunity window in which account data can be compromised in cleartext. Normally, this is done in the external card reader itself or in the COTS-based MPoC Software when a COTS native interface, such as COTS- native NFC, is used.
Although it is not the scope of this requirement to assess the encryption of any external account data capture systems, such as a PCI PTS POI or non-PTS approved MSR, the assessor is required to confirm that there is no functionality on the COTS device that would expect this data to be provided in cleartext or allow for the decryption of the account …
Added
p. 120
1D-1.4.a The tester must confirm through examination and observation that the PAN is appropriately truncated or masked when output or displayed⎯e.g., by using the COTS device screen or printing a receipt⎯according to the relevant PCI DSS FAQs.
Customer receipts may be necessary for customer validation of the transaction and as part of a formal payment challenge process. When such data is sent from the back-end environment for display or printing in the merchant environment, any PAN data on the receipt is required to be truncated to ensure that it cannot be uniquely correlated with the customer and that full details are not available to the merchant.
Functions to display cardholder data, either during or post transaction processing, could be used to facilitate the disclosure and compromise of this data. The COTS- based MPoC Software can display PAN data that is truncated or masked as per relevant PCI DSS FAQs. The intent of …
Customer receipts may be necessary for customer validation of the transaction and as part of a formal payment challenge process. When such data is sent from the back-end environment for display or printing in the merchant environment, any PAN data on the receipt is required to be truncated to ensure that it cannot be uniquely correlated with the customer and that full details are not available to the merchant.
Functions to display cardholder data, either during or post transaction processing, could be used to facilitate the disclosure and compromise of this data. The COTS- based MPoC Software can display PAN data that is truncated or masked as per relevant PCI DSS FAQs. The intent of …
Added
p. 121
1D-1.5.a The tester must confirm through examination and observation that the following events which may impact the security of the account data-entry process are able to be detected:
• The COTS-based MPoC Software pauses or stops executing.
• The COTS-based MPoC Software loses its foreground focus.
• An external card reader provides cleartext account data.
The transaction process needs to be protected against manipulation or subversion. Attempts to modify or overlay the cardholder prompts⎯e.g., instructions to the cardholder⎯or other UI features that are important for the security of the solution are required to be prevented. Pausing the application usually means that the application remains partially visible while the user interacts with a different dialog or screen⎯e.g., in multi-screen mode.
When the user switches to a different application, the application is considered “stopped” until either the user switches back or the system destroys the instance of the application.
Although account data entered through external devices like a …
• The COTS-based MPoC Software pauses or stops executing.
• The COTS-based MPoC Software loses its foreground focus.
• An external card reader provides cleartext account data.
The transaction process needs to be protected against manipulation or subversion. Attempts to modify or overlay the cardholder prompts⎯e.g., instructions to the cardholder⎯or other UI features that are important for the security of the solution are required to be prevented. Pausing the application usually means that the application remains partially visible while the user interacts with a different dialog or screen⎯e.g., in multi-screen mode.
When the user switches to a different application, the application is considered “stopped” until either the user switches back or the system destroys the instance of the application.
Although account data entered through external devices like a …
Added
p. 122
1D-1.6.a The tester must confirm through examination and observation that account data is not stored on persistent storage, beyond the current transaction process, except for the purposes of offline payment processing.
Account data is permitted to be stored on the COTS device only for the purposes of offline payments. This includes storage where the account data may be protected through means such as encryption or storage in tamper-resistant processing elements.
For the purposes of this requirement, “storage” refers to any non-volatile or long-term memory, such as Flash or RAM discs. Temporary storage of data within the memory of the COTS devices is permitted; however, any such storage needs to be cleared securely as soon as possible•no later than when the transaction has been sent for processing.
Support for offline processing and associated data storage is not mandatory and may be conditional or disabled as required.
In the context of this requirement offline payment processing …
Account data is permitted to be stored on the COTS device only for the purposes of offline payments. This includes storage where the account data may be protected through means such as encryption or storage in tamper-resistant processing elements.
For the purposes of this requirement, “storage” refers to any non-volatile or long-term memory, such as Flash or RAM discs. Temporary storage of data within the memory of the COTS devices is permitted; however, any such storage needs to be cleared securely as soon as possible•no later than when the transaction has been sent for processing.
Support for offline processing and associated data storage is not mandatory and may be conditional or disabled as required.
In the context of this requirement offline payment processing …
Added
p. 123
Security Requirements Test Requirements Guidance Objective: Secure card readers supported by the solution provide sufficient protection to account data.
1D-2.1.a For each of the PCI PTS devices used in the solution, the tester must confirm through examination that, at a minimum, the following information is provided within the security guidance document assessed under Section 1G:
• Hardware, firmware, and listing details for each PCI PTS device used.
• Supported functionality of each secure card reader.
• All guidance required for the correct and approved operation of the used secure card reader.
Any PCI PTS devices used with the COTS-based MPoC Software need to have been assessed for the specific use implemented in the COTS-based MPoC Software. Use of functionality that has not been assessed presents a security risk to the COTS-based MPoC Software.
The documentation provided by the MPoC Software vendor needs to contain all the necessary information to integrate the PCI PTS POI securely into …
1D-2.1.a For each of the PCI PTS devices used in the solution, the tester must confirm through examination that, at a minimum, the following information is provided within the security guidance document assessed under Section 1G:
• Hardware, firmware, and listing details for each PCI PTS device used.
• Supported functionality of each secure card reader.
• All guidance required for the correct and approved operation of the used secure card reader.
Any PCI PTS devices used with the COTS-based MPoC Software need to have been assessed for the specific use implemented in the COTS-based MPoC Software. Use of functionality that has not been assessed presents a security risk to the COTS-based MPoC Software.
The documentation provided by the MPoC Software vendor needs to contain all the necessary information to integrate the PCI PTS POI securely into …
Added
p. 124
1D-2.3.a The tester must confirm through examination and observation of the A&M that:
• Any PCI PTS devices used are uniquely identified and validated.
• The firmware version is verified by the A&M.
• The state of the PCI PTS device is verified by the A&M.
• PCI PTS devices have an approved version of firmware installed, as listed on the PCI PTS listing for that device.
• The device is operating in an encrypting mode that prevents cleartext account data being transmitted to the COTS device.
The A&M needs to ensure that all aspects of the COTS- based MPoC Software are operating as expected and are not in a state that indicates or could facilitate compromise. This includes validating the state and security posture of any attached card-reading devices.
This validation included confirmation of the firmware version(s) of the attached devices, as well as hardware versions, and confirming that these meet the expectations of the implementation⎯e.g., …
• Any PCI PTS devices used are uniquely identified and validated.
• The firmware version is verified by the A&M.
• The state of the PCI PTS device is verified by the A&M.
• PCI PTS devices have an approved version of firmware installed, as listed on the PCI PTS listing for that device.
• The device is operating in an encrypting mode that prevents cleartext account data being transmitted to the COTS device.
The A&M needs to ensure that all aspects of the COTS- based MPoC Software are operating as expected and are not in a state that indicates or could facilitate compromise. This includes validating the state and security posture of any attached card-reading devices.
This validation included confirmation of the firmware version(s) of the attached devices, as well as hardware versions, and confirming that these meet the expectations of the implementation⎯e.g., …
Added
p. 125
Security Requirements Test Requirements Guidance Objective: Data from magnetic-stripe cards is secured through approved readers.
1D-3.1.a For each of the devices used to accept magnetic-stripe transactions in the solution, the tester must confirm through examination that, at a minimum, the following details are provided in the security guidance document assessed under Section 1G:
• The hardware, firmware, and validation details for each MSR used.
• The supported functionality of each MSR.
• All guidance required for the correct and approved operation of the used MSRs.
Any MSR devices used with the COTS-based MPoC Software need to have been assessed for the specific use implemented in the COTS-based MPoC Software. Use of functionality that has not been assessed presents a security risk to the COTS-based MPoC Software.
The documentation provided by the MPoC Software needs to contain all the necessary information to integrate any devices accepting magnetic-stripe-based transactions securely into an MPoC Solution. This may include the …
1D-3.1.a For each of the devices used to accept magnetic-stripe transactions in the solution, the tester must confirm through examination that, at a minimum, the following details are provided in the security guidance document assessed under Section 1G:
• The hardware, firmware, and validation details for each MSR used.
• The supported functionality of each MSR.
• All guidance required for the correct and approved operation of the used MSRs.
Any MSR devices used with the COTS-based MPoC Software need to have been assessed for the specific use implemented in the COTS-based MPoC Software. Use of functionality that has not been assessed presents a security risk to the COTS-based MPoC Software.
The documentation provided by the MPoC Software needs to contain all the necessary information to integrate any devices accepting magnetic-stripe-based transactions securely into an MPoC Solution. This may include the …
Added
p. 126
1D-3.3.a The tester must confirm through examination that:
• Any MSR device(s) used are uniquely identified and validated by the attestation and monitoring (A&M), including the firmware and hardware versions where applicable.
• The state of the MSR device is verified by the attestation and monitoring (A&M).
• The MSR devices(s) are confirmed by the attestation and monitoring (A&M) to have no known or exploitable vulnerabilities.
The attestation and monitoring (A&M) needs to ensure that all aspects of the COTS-based MPoC Software are operating as expected and are not in a state that indicates or could facilitate compromise. This includes validating the state and security posture of any attached card- reading devices.
Firmware in the context of this requirement may include operational code that is executed by an underlying processor, or the version of a dedicated ASIC used in place of a general-purpose processor.
1D-3.4 MSR data captured in an MPoC Solution is not made available …
• Any MSR device(s) used are uniquely identified and validated by the attestation and monitoring (A&M), including the firmware and hardware versions where applicable.
• The state of the MSR device is verified by the attestation and monitoring (A&M).
• The MSR devices(s) are confirmed by the attestation and monitoring (A&M) to have no known or exploitable vulnerabilities.
The attestation and monitoring (A&M) needs to ensure that all aspects of the COTS-based MPoC Software are operating as expected and are not in a state that indicates or could facilitate compromise. This includes validating the state and security posture of any attached card- reading devices.
Firmware in the context of this requirement may include operational code that is executed by an underlying processor, or the version of a dedicated ASIC used in place of a general-purpose processor.
1D-3.4 MSR data captured in an MPoC Solution is not made available …
Added
p. 127
The contactless kernel has direct access to assets. Therefore, the processing, memory, and storage used by this kernel must be protected to prevent the assets from being compromised when handled by the payment kernel.
The requirements in this Section apply to the COTS-native NFC interface only.
Security Requirements Test Requirements Guidance Objective: Account data is protected and securely processed when it is read by the COTS-native NFC interface.
1D-4.1 Information that details the implementation of the COTS-native NFC acceptance method, including the implementation for any contactless kernels, exists.
1D-4.1.a The tester must confirm the following through examination:
• That all COTS-native NFC acceptance methods are detailed.
• If part of the kernel is executed remotely (e.g., a cloud-based kernel), where and what parts of the kernel are included in this remote execution.
• How the kernel is configured and how the configuration is protected.
• How the kernel is secured against tampering.
Contactless kernels used by the COTS-based MPoC …
The requirements in this Section apply to the COTS-native NFC interface only.
Security Requirements Test Requirements Guidance Objective: Account data is protected and securely processed when it is read by the COTS-native NFC interface.
1D-4.1 Information that details the implementation of the COTS-native NFC acceptance method, including the implementation for any contactless kernels, exists.
1D-4.1.a The tester must confirm the following through examination:
• That all COTS-native NFC acceptance methods are detailed.
• If part of the kernel is executed remotely (e.g., a cloud-based kernel), where and what parts of the kernel are included in this remote execution.
• How the kernel is configured and how the configuration is protected.
• How the kernel is secured against tampering.
Contactless kernels used by the COTS-based MPoC …
Added
p. 128
1D-4.2.a The tester must confirm through examination and observation that the COTS-based MPoC Software implements mechanisms to prevent, monitor, or otherwise inhibit access to the COTS-native NFC interface by other applications during a payment transaction.
To prevent interference or interception of the COTS- native NFC communication, the COTS-based MPoC Software needs to attempt to implement methods to prevent or detect access to this interface by other applications during the payment transaction process.
This may involve attempting to assert exclusive control to the COTS-native NFC interface before initiating the transaction or monitoring if another application accesses the interface. Alternatively, exclusive operation may be ensured to any foreground application by the COTS platform.
The COTS-based MPoC Software needs to prevent transaction processing if it cannot provide a sufficient level of security to the COTS-native NFC interface.
1D-4.3 The COTS-based MPoC Software ensures that the COTS device camera(s) are not accessed by other applications during a payment …
To prevent interference or interception of the COTS- native NFC communication, the COTS-based MPoC Software needs to attempt to implement methods to prevent or detect access to this interface by other applications during the payment transaction process.
This may involve attempting to assert exclusive control to the COTS-native NFC interface before initiating the transaction or monitoring if another application accesses the interface. Alternatively, exclusive operation may be ensured to any foreground application by the COTS platform.
The COTS-based MPoC Software needs to prevent transaction processing if it cannot provide a sufficient level of security to the COTS-native NFC interface.
1D-4.3 The COTS-based MPoC Software ensures that the COTS device camera(s) are not accessed by other applications during a payment …
Added
p. 129
1D-4.4.a The tester must confirm through examination that the communication with remote components of the kernel is secure through use of secure channels, and relevant requirements of Domain 4 and Domain 5 are met.
For account data, protection using a secure channel is not considered sufficient, application-level encryption is required.
Remote kernel implementations are expected to manage account data, at least including PAN, and therefore are required to be validated to PCI DSS.
For account data, protection using a secure channel is not considered sufficient, application-level encryption is required.
Remote kernel implementations are expected to manage account data, at least including PAN, and therefore are required to be validated to PCI DSS.
Added
p. 130
Security Requirements Test Requirements Guidance Objective: Account data entered into the COTS device through manual entry methods is secured.
1D-5.1 Documentation exists that details the manual entry process and protection methods.
1D-5.1.a For each of the manual account data-entry methods used in the solution, the tester must confirm through examination that details about the following are provided at a minimum:
• The ways in which the manual entry method can be invoked.
• The protections applied to the manual entry method.
• The types of account data that may be manually entered.
The COTS-based MPoC Software may support manual entry of the PAN, e.g., to enable payment processing if other card presentment modes fail (due to a damaged chip or magnetic-stripe). Additional account data, such as the security code for the card, may be additionally required during such payment processing.
It is important that any such methods of manual entry are detailed to allow for a complete …
1D-5.1 Documentation exists that details the manual entry process and protection methods.
1D-5.1.a For each of the manual account data-entry methods used in the solution, the tester must confirm through examination that details about the following are provided at a minimum:
• The ways in which the manual entry method can be invoked.
• The protections applied to the manual entry method.
• The types of account data that may be manually entered.
The COTS-based MPoC Software may support manual entry of the PAN, e.g., to enable payment processing if other card presentment modes fail (due to a damaged chip or magnetic-stripe). Additional account data, such as the security code for the card, may be additionally required during such payment processing.
It is important that any such methods of manual entry are detailed to allow for a complete …
Added
p. 131
1D-5.3.a The tester must confirm through examination and observation the following for each of the manual account data-entry methods implemented:
• The entry methods do not allow the storage of the account data. This includes by the OS for purposes such as spell-checking dictionary creation.
• The account data is entered directly into the COTS-based MPoC Software. Third-party keyboard or data-entry applications are not used for account data entry.
• It is not possible to take screenshots or recordings of the COTS-based MPoC Software during PAN entry on the COTS device into which the PAN is entered.
It is common in many COTS OS for the OS-provided data-entry functions to store data entered so that it can build a dictionary of commonly used terms for the purposes of enhancing spell-check functions. In addition, some OSs allow for the replacement of the OS provided data-entry functions with third-party applications that may provide similar functions or …
• The entry methods do not allow the storage of the account data. This includes by the OS for purposes such as spell-checking dictionary creation.
• The account data is entered directly into the COTS-based MPoC Software. Third-party keyboard or data-entry applications are not used for account data entry.
• It is not possible to take screenshots or recordings of the COTS-based MPoC Software during PAN entry on the COTS device into which the PAN is entered.
It is common in many COTS OS for the OS-provided data-entry functions to store data entered so that it can build a dictionary of commonly used terms for the purposes of enhancing spell-check functions. In addition, some OSs allow for the replacement of the OS provided data-entry functions with third-party applications that may provide similar functions or …
Added
p. 132
An MPoC Software Product or MPoC Solution can support PIN entry only through use of the touch screen on the COTS platforms supported, or through use of a PIN entry device listed as validated to the PCI PTS POI standard. Use of physical keypads for PIN entry on non-tamper responsive devices is not permitted.
Accessibility features may be made available on a per-transaction basis and must not be the default or sole PIN entry method offered. Accessibility features must not display the individual PIN digits themselves or provide feedback (audio, visual, or haptic) that is unique to individual PIN digits. “Zoom” features to increase the size of keypad buttons may be provided, as long as individual PIN digits cannot be uniquely identified.
Side channel testing (Requirement 1E-1.3) of the accessible PIN entry mode is not required. The MPoC Software and the A&M system must be designed to protect any unique features of …
Accessibility features may be made available on a per-transaction basis and must not be the default or sole PIN entry method offered. Accessibility features must not display the individual PIN digits themselves or provide feedback (audio, visual, or haptic) that is unique to individual PIN digits. “Zoom” features to increase the size of keypad buttons may be provided, as long as individual PIN digits cannot be uniquely identified.
Side channel testing (Requirement 1E-1.3) of the accessible PIN entry mode is not required. The MPoC Software and the A&M system must be designed to protect any unique features of …
Added
p. 133
Security Requirements Test Requirements Guidance Objective: Cardholder PINs are protected as they are entered and processed on the COTS device.
1E-1.1 Documentation exists that describes the secure capture and processing of the cardholder PIN.
1E-1.1.a The tester must confirm through examination that the information provided contains, but is not limited to:
• How the PIN is protected during entry and prior to encryption.
• How the PIN is encrypted.
• The security mechanisms implemented to prevent the extraction of the PIN at runtime.
• Side-channel prevention mechanisms.
• The types of PIN-verification method(s) supported (offline, online, or both).
• Any accessible PIN entry modes that are implemented.
COTS-based MPoC Software that accepts account data entry, including PINs, on COTS devices has to provide a path for these sensitive assets from the hardware of the COTS device, through the OS and drivers, to the COTS- based MPoC Software itself.
Documentation is required to demonstrate an understanding and consideration for the entire …
1E-1.1 Documentation exists that describes the secure capture and processing of the cardholder PIN.
1E-1.1.a The tester must confirm through examination that the information provided contains, but is not limited to:
• How the PIN is protected during entry and prior to encryption.
• How the PIN is encrypted.
• The security mechanisms implemented to prevent the extraction of the PIN at runtime.
• Side-channel prevention mechanisms.
• The types of PIN-verification method(s) supported (offline, online, or both).
• Any accessible PIN entry modes that are implemented.
COTS-based MPoC Software that accepts account data entry, including PINs, on COTS devices has to provide a path for these sensitive assets from the hardware of the COTS device, through the OS and drivers, to the COTS- based MPoC Software itself.
Documentation is required to demonstrate an understanding and consideration for the entire …
Added
p. 134
1E-1.3.a The tester must confirm through examination that:
• The threat of extracting the PIN using the COTS device sensors was considered.
• Each sensor has a rationale on why they do not present a risk for side channel extraction of the PIN.
• Measures were implemented to prevent the leakage of the PIN using the sensors that present a risk.
Some COTS device sensors can be used at the time of PIN entry to extract the PIN that is being entered by the cardholder. Furthermore, a COTS device output⎯e.g., distinctive sounds per key or change in the key digit on screen when pressed⎯can be used to extract the PIN from the COTS device using screenshots or recordings.
Therefore, the COTS-based MPoC Software needs to ensure that the implementation accommodates for these issues and ensures that the method of PIN entry does not leak PIN digits through potential side channels.
Therefore, the COTS-based MPoC Software needs …
• The threat of extracting the PIN using the COTS device sensors was considered.
• Each sensor has a rationale on why they do not present a risk for side channel extraction of the PIN.
• Measures were implemented to prevent the leakage of the PIN using the sensors that present a risk.
Some COTS device sensors can be used at the time of PIN entry to extract the PIN that is being entered by the cardholder. Furthermore, a COTS device output⎯e.g., distinctive sounds per key or change in the key digit on screen when pressed⎯can be used to extract the PIN from the COTS device using screenshots or recordings.
Therefore, the COTS-based MPoC Software needs to ensure that the implementation accommodates for these issues and ensures that the method of PIN entry does not leak PIN digits through potential side channels.
Therefore, the COTS-based MPoC Software needs …
Added
p. 135
• The PIN is encrypted into an ISO format 4-PIN block upon entry, and in all cases prior to transmission outside of the boundary of the COTS-based MPoC Software and COTS device.
• If the cryptographic keys used to encrypt the PIN block are exposed in the rich execution environment of the COTS device, the PIN block is encrypted using unique keys per transaction.
Methods that capture and encrypt the PIN in ways not compliant to ISO9564 can result in unforeseen risk being introduced into the PIN-processing system. ISO 9564 Format 4 uses AES and encapsulates the PIN and PAN into the PIN block using separate encryption processes.
This separation of the encryption processes within an ISO format 4-PIN block allows for the PIN and PAN to be managed as separate items during the formatting of the PIN block (on the COTS device). Maintaining separation between the PIN and PAN can help increase …
• If the cryptographic keys used to encrypt the PIN block are exposed in the rich execution environment of the COTS device, the PIN block is encrypted using unique keys per transaction.
Methods that capture and encrypt the PIN in ways not compliant to ISO9564 can result in unforeseen risk being introduced into the PIN-processing system. ISO 9564 Format 4 uses AES and encapsulates the PIN and PAN into the PIN block using separate encryption processes.
This separation of the encryption processes within an ISO format 4-PIN block allows for the PIN and PAN to be managed as separate items during the formatting of the PIN block (on the COTS device). Maintaining separation between the PIN and PAN can help increase …
Added
p. 136
1E-1.6.a The tester must confirm through examination and observation that attestation is performed prior to each PIN entry.
PIN entry is permitted only when the COTS-based MPoC Software is running in a secure state. It is important that these attestation functions be performed before the cardholder is prompted to enter PIN data.
The COTS-based MPoC Software may have multiple levels of attestation and is required to have some level that is always active. Due to power and processing constraints, it may not be possible to have all attestation functions always active, and so execution of more complete attestation prior to PIN entry is required.
Validation of attestation data is expected to be performed online for any online PIN entry process.
1E-1.6.b The tester must confirm through examination and observation that attestation and monitoring (A&M) validation is performed on the COTS device immediately prior to PIN entry.
1E-1.7 The COTS-based MPoC Software detects when another application …
PIN entry is permitted only when the COTS-based MPoC Software is running in a secure state. It is important that these attestation functions be performed before the cardholder is prompted to enter PIN data.
The COTS-based MPoC Software may have multiple levels of attestation and is required to have some level that is always active. Due to power and processing constraints, it may not be possible to have all attestation functions always active, and so execution of more complete attestation prior to PIN entry is required.
Validation of attestation data is expected to be performed online for any online PIN entry process.
1E-1.6.b The tester must confirm through examination and observation that attestation and monitoring (A&M) validation is performed on the COTS device immediately prior to PIN entry.
1E-1.7 The COTS-based MPoC Software detects when another application …
Added
p. 137
1E-1.8.a The tester must confirm through examination and observation that PIN-related data is not stored in persistent storage.
Cleartext PINs, encrypted PIN blocks, and PIN-encryption keys need to be cleared from the system as soon as they are no longer required.
For both cleartext PINs and the PIN encryption key, this means once the encrypted PIN block is produced, these values are required to be securely erased.
The COTS-based MPoC Software may perform the two encryptions required for an ISO format 4-PIN block as separate parts of the transaction, enabling encryption of the PIN as soon as possible and prior to the inclusion of the PAN or PAN token into the PIN block.
The encrypted PIN block needs to be erased once the PIN block has been transmitted from the COTS device.
1E-1.9 Offline PIN verification is supported only through the use of PCI PTS POI devices which are approved for this purpose.
1E-1.9.a The tester …
Cleartext PINs, encrypted PIN blocks, and PIN-encryption keys need to be cleared from the system as soon as they are no longer required.
For both cleartext PINs and the PIN encryption key, this means once the encrypted PIN block is produced, these values are required to be securely erased.
The COTS-based MPoC Software may perform the two encryptions required for an ISO format 4-PIN block as separate parts of the transaction, enabling encryption of the PIN as soon as possible and prior to the inclusion of the PAN or PAN token into the PIN block.
The encrypted PIN block needs to be erased once the PIN block has been transmitted from the COTS device.
1E-1.9 Offline PIN verification is supported only through the use of PCI PTS POI devices which are approved for this purpose.
1E-1.9.a The tester …
Added
p. 138
1E-1.10.a The tester must confirm through examination and observation that any accessible PIN entry modes provided are implemented securely. This includes:
• Accessible PIN entry modes are not the default or sole mode of PIN entry.
• Individual PIN entry digits are not highlighted or exposed through features such as screen zooming.
• The accessible PIN entry mode provides a clear visual indication when it is enabled, and allows for the cardholder to disable this mode at any time.
• The A&M functions are designed to protect the unique features of the accessible PIN entry process, including monitoring and tracking of the number of times the accessible PIN entry method is used.
• Accessibility features exit on completion of the payment transaction process, including any error states, and require explicit enabling for each separate payment transaction.
Accessible PIN entry features are not required but may be made available on a per-transaction basis. They are not to …
• Accessible PIN entry modes are not the default or sole mode of PIN entry.
• Individual PIN entry digits are not highlighted or exposed through features such as screen zooming.
• The accessible PIN entry mode provides a clear visual indication when it is enabled, and allows for the cardholder to disable this mode at any time.
• The A&M functions are designed to protect the unique features of the accessible PIN entry process, including monitoring and tracking of the number of times the accessible PIN entry method is used.
• Accessibility features exit on completion of the payment transaction process, including any error states, and require explicit enabling for each separate payment transaction.
Accessible PIN entry features are not required but may be made available on a per-transaction basis. They are not to …
Added
p. 139
• That device is listed as validated to the PCI PTS POI requirements.
• That device is listed as validated to the PCI PTS POI requirements.
• An approved PIN entry function of the device is used, ensuring the PIN is encrypted into an ISO 9564 compliant PIN block before leaving the PCI PTS POI device.
• An approved PIN entry function of the device is used, ensuring the PIN is encrypted into an ISO 9564 compliant PIN block before leaving the PCI PTS POI device.
• The PIN is not exposed in cleartext on the COTS device.
• The PIN is not exposed in cleartext on the COTS device.
1E-1.11.a The tester must confirm through examination and observation that where a PIN may be entered through a device other than the COTS device:
PCI PTS POI devices have been validated to provide secure entry of PIN data, however the applications used on such devices may influence …
• That device is listed as validated to the PCI PTS POI requirements.
• An approved PIN entry function of the device is used, ensuring the PIN is encrypted into an ISO 9564 compliant PIN block before leaving the PCI PTS POI device.
• An approved PIN entry function of the device is used, ensuring the PIN is encrypted into an ISO 9564 compliant PIN block before leaving the PCI PTS POI device.
• The PIN is not exposed in cleartext on the COTS device.
• The PIN is not exposed in cleartext on the COTS device.
1E-1.11.a The tester must confirm through examination and observation that where a PIN may be entered through a device other than the COTS device:
PCI PTS POI devices have been validated to provide secure entry of PIN data, however the applications used on such devices may influence …
Added
p. 140
Depending on the type of transaction, different types of data may need to be stored on the COTS device for eventual transaction authorization. Types of data that may need to be stored and protected during an offline transaction includes account data and transaction results (cryptograms).
Offline PIN verification (with a contact chip card presented through a PCI PTS POI) may be used in either online or offline approval processes.
Assets stored for offline transactions must be protected according to their security needs. This Module covers additional security requirements that are needed to provide protection to these assets when stored on the COTS device. The protection of assets during the processing of a payment is covered by separate Modules.
Support for offline payment processing is not a required feature of an MPoC Solution and may not be possible in some payment solutions due to local or payment brand specific rules.
Offline PIN verification (with a contact chip card presented through a PCI PTS POI) may be used in either online or offline approval processes.
Assets stored for offline transactions must be protected according to their security needs. This Module covers additional security requirements that are needed to provide protection to these assets when stored on the COTS device. The protection of assets during the processing of a payment is covered by separate Modules.
Support for offline payment processing is not a required feature of an MPoC Solution and may not be possible in some payment solutions due to local or payment brand specific rules.
Added
p. 141
Security Requirements Test Requirements Guidance Objective: Offline transaction results and account data are protected.
1F-1.1 Stored assets, such as account data and transaction results, needed to process offline Payment transactions are encrypted in such a way that the cleartext values cannot be recovered on the COTS device after encryption.
1F-1.1.a The tester must confirm through examination, observation, and testing that any assets, such as account data and transaction results, stored for offline transactions cannot be decrypted or recovered on the COTS device after encryption.
To prevent the recovery of cleartext sensitive assets, such data needs to be stored so that it is not recoverable on the COTS device.
The requirement is required to be enforced cryptographically through the use of keys that are securely removed from the COTS device immediately after encryption or using an approved asymmetric cryptography algorithm as described in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
If …
1F-1.1 Stored assets, such as account data and transaction results, needed to process offline Payment transactions are encrypted in such a way that the cleartext values cannot be recovered on the COTS device after encryption.
1F-1.1.a The tester must confirm through examination, observation, and testing that any assets, such as account data and transaction results, stored for offline transactions cannot be decrypted or recovered on the COTS device after encryption.
To prevent the recovery of cleartext sensitive assets, such data needs to be stored so that it is not recoverable on the COTS device.
The requirement is required to be enforced cryptographically through the use of keys that are securely removed from the COTS device immediately after encryption or using an approved asymmetric cryptography algorithm as described in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
If …
Added
p. 142
1F-1.2.a The tester must confirm through examination and observation that any further transaction processing is prevented when the COTS-based MPoC Software has been operating in offline mode for more than 48 hours.
Attackers may attempt to exploit offline processing to process multiple transactions that would otherwise be rejected if processed online. To reduce this risk, offline processing systems need to prevent further processing if they are prevented from connecting to the back-end system.
The back-end payment-processing systems may be different to the back-end A&M processing systems. MPoC Software implementing offline payment processing need to achieve connectivity to the A&M back-end at least every 24 hours.
The A&M connectivity requirement is different from this requirement and tested separately. This requirement is to halt payment processing once offline payment processing has been enabled for more than 48 hours.
1F-1.3 Data stored for offline transaction processing is not accessible to other applications.
1F-1.3.a The tester must confirm through …
Attackers may attempt to exploit offline processing to process multiple transactions that would otherwise be rejected if processed online. To reduce this risk, offline processing systems need to prevent further processing if they are prevented from connecting to the back-end system.
The back-end payment-processing systems may be different to the back-end A&M processing systems. MPoC Software implementing offline payment processing need to achieve connectivity to the A&M back-end at least every 24 hours.
The A&M connectivity requirement is different from this requirement and tested separately. This requirement is to halt payment processing once offline payment processing has been enabled for more than 48 hours.
1F-1.3 Data stored for offline transaction processing is not accessible to other applications.
1F-1.3.a The tester must confirm through …
Added
p. 143
Security Requirements Test Requirements Guidance Objective: The COTS-based MPoC Software can securely operate and attest its environment during periods where connection to the A&M back-end is lost.
1F-2.1 The initiation of the offline mode is not available immediately after COTS device reboot. The COTS-based MPoC Software only works offline after being connected to the A&M back-end.
1F-2.1.a The tester must confirm through examination and observation that it is not possible to perform offline transactions if the A&M and payment-processing servers have not been contacted after a reboot of the COTS device.
The COTS-based MPoC Software cannot start in offline mode from a reboot state without first contacting the server. This helps mitigate attacks when the timer is manipulated by rebooting the COTS device or when the firmware is modified since the last contact with the A&M server.
Validation of the local time as indicated by the COTS device during reconnections may be used as …
1F-2.1 The initiation of the offline mode is not available immediately after COTS device reboot. The COTS-based MPoC Software only works offline after being connected to the A&M back-end.
1F-2.1.a The tester must confirm through examination and observation that it is not possible to perform offline transactions if the A&M and payment-processing servers have not been contacted after a reboot of the COTS device.
The COTS-based MPoC Software cannot start in offline mode from a reboot state without first contacting the server. This helps mitigate attacks when the timer is manipulated by rebooting the COTS device or when the firmware is modified since the last contact with the A&M server.
Validation of the local time as indicated by the COTS device during reconnections may be used as …
Added
p. 144
1F-2.3.a The tester must confirm through examination and observation that the A&M back- end implements controls to mitigate attacks attempting to delete the COTS-based MPoC Software during offline processing.
An attacker may attempt to delete the COTS-based MPoC Software from a COTS device during offline processing, so that any stored transactions are lost. Although this cannot be prevented, the A&M back-end is required to track offline use in attempts to identify such abuse.
This requirement is intended to help mitigate attacks where COTS-based MPoC Software that has multiple offline transactions stored is deleted to remove those transactions. The requirement does not necessarily require the detection or response to any deletion of the COTS-based MPoC Software.
For example, a system may flag merchants or COTS device instances where offline processing is enabled and the next appearance of that merchant or system is a new installation. This may not lead directly to disablement of that …
An attacker may attempt to delete the COTS-based MPoC Software from a COTS device during offline processing, so that any stored transactions are lost. Although this cannot be prevented, the A&M back-end is required to track offline use in attempts to identify such abuse.
This requirement is intended to help mitigate attacks where COTS-based MPoC Software that has multiple offline transactions stored is deleted to remove those transactions. The requirement does not necessarily require the detection or response to any deletion of the COTS-based MPoC Software.
For example, a system may flag merchants or COTS device instances where offline processing is enabled and the next appearance of that merchant or system is a new installation. This may not lead directly to disablement of that …
Added
p. 146
This Module applies in all cases to MPoC Software that is to be separately listed as an MPoC Product. This Module additionally applies to solutions that separate the MPoC functionality from other parts of an MPoC Application, including those where the MPoC Solution Provider and the MPoC Application vendor are the same organization.
Monolithic MPoC Solutions are exempt from this Module as they do not use an MPoC SDK, and do not outsource the operation of their Attestation and Monitoring services.
1G-1 Security Guidance The security guidance of a component is a document that defines the purpose and usage of the component, the security claims of the component, the component dependencies, and contains the required information to integrate and use the component in a secure manner. Different levels of guidance may be provided to different entities and parties in an overall MPoC Solution. For example, details on key management may be provided …
Monolithic MPoC Solutions are exempt from this Module as they do not use an MPoC SDK, and do not outsource the operation of their Attestation and Monitoring services.
1G-1 Security Guidance The security guidance of a component is a document that defines the purpose and usage of the component, the security claims of the component, the component dependencies, and contains the required information to integrate and use the component in a secure manner. Different levels of guidance may be provided to different entities and parties in an overall MPoC Solution. For example, details on key management may be provided …
Added
p. 147
1G-1.2.a The tester must determine through examination, observation, and testing that the MPoC SDK provided as part of the MPoC Software is either an Isolating SDK, or a non-Isolating SDK. The tester may refer to the results from previous test items in making this determination.
An MPoC SDK may take one of two types. The first type is an Isolating MPoC SDK, which prevents the MPoC Application from accessing the memory or sensitive assets of the MPoC SDK. Any MPoC SDK that does not meet this requirement to isolate and protect its own memory and sensitive assets is considered a non- Isolating SDK. 1G-1.2.b The tester must confirm through examination that the MPoC Software security guidance document correctly details the type of MPoC SDK implemented by the MPoC Software.
1G-1.3 The MPoC Software is provided with a security guidance document that describes how the MPoC Software is to be operated by an …
An MPoC SDK may take one of two types. The first type is an Isolating MPoC SDK, which prevents the MPoC Application from accessing the memory or sensitive assets of the MPoC SDK. Any MPoC SDK that does not meet this requirement to isolate and protect its own memory and sensitive assets is considered a non- Isolating SDK. 1G-1.2.b The tester must confirm through examination that the MPoC Software security guidance document correctly details the type of MPoC SDK implemented by the MPoC Software.
1G-1.3 The MPoC Software is provided with a security guidance document that describes how the MPoC Software is to be operated by an …
Added
p. 148
Clear documentation about how updates to the MPoC Software and its configuration can be made is vital. Because the MPoC Software is designed for integration into other components of an MPoC Solution, updates may require specific processes or prerequisites. When an MPoC Software makes assumptions about the source or protections provided to updates, this needs to be clearly detailed in the security guidance documentation.
Updates covered by this guidance includes data such as configuration for EMV kernels and updates for the MPoC Application to include the most recent versions of the MPoC SDK to cover new patches or updated SBC objects.
1G-1.6 The MPoC Software security guidance document provides details about how any software-protected cryptography implementations impact the frequency of MPoC Application updates.
1G-1.6.a The tester must confirm through examination that the MPoC Software security guidance documentation indicates how often any software-protected cryptography implementations must be updated. This time period must be no …
Updates covered by this guidance includes data such as configuration for EMV kernels and updates for the MPoC Application to include the most recent versions of the MPoC SDK to cover new patches or updated SBC objects.
1G-1.6 The MPoC Software security guidance document provides details about how any software-protected cryptography implementations impact the frequency of MPoC Application updates.
1G-1.6.a The tester must confirm through examination that the MPoC Software security guidance documentation indicates how often any software-protected cryptography implementations must be updated. This time period must be no …
Added
p. 149
1G-1.8.a The tester must confirm through examination that the security guidance details:
• How any configurations or implementations for the secure channels are to be performed in line with the MPoC requirements.
• If a secure channel may be implemented by an MPoC Application, this is permitted only for use with third-party payment hosts.
Both Isolating and non-Isolating MPoC SDKs may allow for an MPoC Application to configure the secure channels that are implemented by the MPoC SDK. For example, a TLS-based secure channel may have certificates and/or URLs configured by the MPoC Application. Such configurations cannot include changing supported cipher suites to ones not permitted under the MPoC requirements.
An MPoC SDK may allow for an MPoC Application to implement its own secure channel to a third-party payment host. Where this is possible, the MPoC Security Guidance is required to detail how the secure channel is to be implemented in line with MPoC …
• How any configurations or implementations for the secure channels are to be performed in line with the MPoC requirements.
• If a secure channel may be implemented by an MPoC Application, this is permitted only for use with third-party payment hosts.
Both Isolating and non-Isolating MPoC SDKs may allow for an MPoC Application to configure the secure channels that are implemented by the MPoC SDK. For example, a TLS-based secure channel may have certificates and/or URLs configured by the MPoC Application. Such configurations cannot include changing supported cipher suites to ones not permitted under the MPoC requirements.
An MPoC SDK may allow for an MPoC Application to implement its own secure channel to a third-party payment host. Where this is possible, the MPoC Security Guidance is required to detail how the secure channel is to be implemented in line with MPoC …
Added
p. 150
1G-1.11.a The tester must confirm through examination that the MPoC Software security guidance provides sufficient details on how to operate the key management required by the MPoC Software.
The MPoC Software is validated as implementing certain key management and encryption operations. However, all key management requires support from back-end systems, and it is required that the operational aspects of the key management are clearly defined in the MPoC Software security guidance document. Where different parties may be responsible for different aspects of key management, this is to be indicated in the document. 1G-1.11.b The tester must confirm through examination that the guidance clearly outlines who is responsible for the management of each key management aspect of the MPoC Software.
1G-1.12 Where vendor verification is to be used for the integration of their isolating SDK(s) procedures for the validation of MPoC Applications exist and are demonstrably in use.
1G-1.12.a The tester must confirm that:
• …
The MPoC Software is validated as implementing certain key management and encryption operations. However, all key management requires support from back-end systems, and it is required that the operational aspects of the key management are clearly defined in the MPoC Software security guidance document. Where different parties may be responsible for different aspects of key management, this is to be indicated in the document. 1G-1.11.b The tester must confirm through examination that the guidance clearly outlines who is responsible for the management of each key management aspect of the MPoC Software.
1G-1.12 Where vendor verification is to be used for the integration of their isolating SDK(s) procedures for the validation of MPoC Applications exist and are demonstrably in use.
1G-1.12.a The tester must confirm that:
• …
Added
p. 151
• The procedures have been followed as documented.
• The validation results are correct based on the supplied MPoC Applications.
MPoC Applications that integrate MPoC SDKs from more than one MPoC Software vendor must be validated through an MPoC Laboratory.
MPoC Applications that integrate an MPoC SDK that integrates another MPoC SDK must be validated either through laboratory testing, or through testing by the MPoC Software vendors of both MPoC SDKs (where both MPoC SDKs implement card-based payments). Where only one of the MPoC SDKs implements card-based payments, integration testing must be performed by the vendor of that MPoC SDK.
The laboratory is expected to validate output from testing against listed MPoC Applications, where possible. In instances where a new MPoC Software product is under evaluation, and there are no currently listed MPoC Applications, test applications may be provided by the MPoC Software vendor. In this case, the laboratory is expected to make modifications …
• The validation results are correct based on the supplied MPoC Applications.
MPoC Applications that integrate MPoC SDKs from more than one MPoC Software vendor must be validated through an MPoC Laboratory.
MPoC Applications that integrate an MPoC SDK that integrates another MPoC SDK must be validated either through laboratory testing, or through testing by the MPoC Software vendors of both MPoC SDKs (where both MPoC SDKs implement card-based payments). Where only one of the MPoC SDKs implements card-based payments, integration testing must be performed by the vendor of that MPoC SDK.
The laboratory is expected to validate output from testing against listed MPoC Applications, where possible. In instances where a new MPoC Software product is under evaluation, and there are no currently listed MPoC Applications, test applications may be provided by the MPoC Software vendor. In this case, the laboratory is expected to make modifications …
Added
p. 152
An MPoC Solution may have more than one MPoC Application listed as part of that MPoC Solution listing.
Further details on the different types of MPoC Applications can be found in Section: MPoC SDKs and MPoC Applications. Details on the applicability of the various Domains and requirements of this standard can be found in Section: MPoC Domain and Section Applicability. Details on the process and requirements for MPoC listings can be found in the MPoC Program Guide.
Module 2A: MPoC SDK Integration This Module covers the integration of one or more MPoC SDKs, which are part of listed MPoC Software Products, into an MPoC Application or another MPoC SDK (where that integrating MPoC SDK does not provide additional card-payment features, or accesses cleartext sensitive data). Any one MPoC Application is not permitted to integrate more than two MPoC SDKs.
An MPoC Application that integrates both an Isolating and non-Isolating MPoC SDK is assessed …
Further details on the different types of MPoC Applications can be found in Section: MPoC SDKs and MPoC Applications. Details on the applicability of the various Domains and requirements of this standard can be found in Section: MPoC Domain and Section Applicability. Details on the process and requirements for MPoC listings can be found in the MPoC Program Guide.
Module 2A: MPoC SDK Integration This Module covers the integration of one or more MPoC SDKs, which are part of listed MPoC Software Products, into an MPoC Application or another MPoC SDK (where that integrating MPoC SDK does not provide additional card-payment features, or accesses cleartext sensitive data). Any one MPoC Application is not permitted to integrate more than two MPoC SDKs.
An MPoC Application that integrates both an Isolating and non-Isolating MPoC SDK is assessed …
Added
p. 153
2A-1.1 When an MPoC SDK is used, the MPoC SDK is part of a listed MPoC Product.
2A-1.1.a The tester must confirm through examination that the version of the MPoC SDK used is listed on the PCI website as part of an existing MPoC Product.
MPoC Products, including the MPoC Applications are required to be evaluated in their entirety before approval. When an MPoC SDK is relied upon for some aspect of compliance, that MPoC SDK needs to have been previously assessed and listed as part of an MPoC Product.
2A-1.2 The MPoC SDK is integrated with the COTS-based MPoC Software and other aspects of the MPoC Product in accordance with the MPoC Software security guidance.
2A-1.2.a The tester must confirm through examination and observation that the MPoC SDK has been integrated into the COTS-based MPoC Software in accordance with the security guidance for that MPoC SDK.
An MPoC SDK provides various security services and …
2A-1.1.a The tester must confirm through examination that the version of the MPoC SDK used is listed on the PCI website as part of an existing MPoC Product.
MPoC Products, including the MPoC Applications are required to be evaluated in their entirety before approval. When an MPoC SDK is relied upon for some aspect of compliance, that MPoC SDK needs to have been previously assessed and listed as part of an MPoC Product.
2A-1.2 The MPoC SDK is integrated with the COTS-based MPoC Software and other aspects of the MPoC Product in accordance with the MPoC Software security guidance.
2A-1.2.a The tester must confirm through examination and observation that the MPoC SDK has been integrated into the COTS-based MPoC Software in accordance with the security guidance for that MPoC SDK.
An MPoC SDK provides various security services and …
Added
p. 154
2A-1.4.a The tester must confirm through examination and observation that the COTS-based MPoC Software that is integrating the MPoC SDK does not manage, process, or provide for the input of sensitive assets such as cardholder PINs, cryptographic keys, or account data.
The COTS-based MPoC Software that integrates the MPoC SDK relies on the MPoC SDK to manage all sensitive assets such as cardholder PINs and account data. Where the COTS-based MPoC Software manages, processes, or provides input to any sensitive assets, the COTS-based MPoC Software is required to be assessed against Domain 1 of this standard.
Assets that are encrypted by the MPoC Software (or by a system or entity external to the COTS device) using cryptographic methods and key management assessed under Domain 1 of this standard are considered suitably protected and not in scope of this requirement.
2A-1.4.b Where the COTS-based MPoC Software that is integrating the MPoC SDK is found …
The COTS-based MPoC Software that integrates the MPoC SDK relies on the MPoC SDK to manage all sensitive assets such as cardholder PINs and account data. Where the COTS-based MPoC Software manages, processes, or provides input to any sensitive assets, the COTS-based MPoC Software is required to be assessed against Domain 1 of this standard.
Assets that are encrypted by the MPoC Software (or by a system or entity external to the COTS device) using cryptographic methods and key management assessed under Domain 1 of this standard are considered suitably protected and not in scope of this requirement.
2A-1.4.b Where the COTS-based MPoC Software that is integrating the MPoC SDK is found …
Added
p. 155
Application must be evaluated as part of the attestation and monitoring process.
Attestation functions provided by the MPoC SDK may require specific integration steps or interactions with the MPoC Application. For example, specific triggers or data points to support the secure operation of the attestation functions may be required within the MPoC Application.
These interactions are required to have been documented properly as part of the MPoC SDK validation. The process that this documentation outlines needs to be followed to ensure that the MPoC SDK provides the security features that are expected of it.
Attestation needs to be an integral part of the MPoC SDK and MPoC Application flows. This means that initiating transactions, without having performed and passed attestation, needs to be prevented. This control may be enforced in the payment-processing environment⎯e.g., by requesting proof of successful attestation.
The payment-processing environment is required to be aware when attestation is due, and not process …
Attestation functions provided by the MPoC SDK may require specific integration steps or interactions with the MPoC Application. For example, specific triggers or data points to support the secure operation of the attestation functions may be required within the MPoC Application.
These interactions are required to have been documented properly as part of the MPoC SDK validation. The process that this documentation outlines needs to be followed to ensure that the MPoC SDK provides the security features that are expected of it.
Attestation needs to be an integral part of the MPoC SDK and MPoC Application flows. This means that initiating transactions, without having performed and passed attestation, needs to be prevented. This control may be enforced in the payment-processing environment⎯e.g., by requesting proof of successful attestation.
The payment-processing environment is required to be aware when attestation is due, and not process …
Added
p. 156
2A-1.6.a The tester must confirm through examination and observation that the MPoC Application does not integrate more than two MPoC SDKs.
Integration of multiple MPoC SDKs is permitted but increases the complexity and potential attack surface of the MPoC Application. To limit the risk posed by integration of multiple MPoC SDKs, no more than two may be integrated into a single MPoC Application.
2A-1.7 The COTS-based MPoC Software integrating the MPoC SDK does not implement, or allow for, the decryption of encrypted sensitive assets output by the MPoC SDK.
2A-1.7.a The tester must confirm through examination and observation that the COTS-based MPoC Software integrating the MPoC SDK does not implement or allow for the decryption of sensitive assets encrypted by the MPoC SDK.
During assessment to Domain 1, it is established that the MPoC SDK only outputs sensitive assets when that data is appropriately protected⎯e.g., through the use of encryption. It is important that …
Integration of multiple MPoC SDKs is permitted but increases the complexity and potential attack surface of the MPoC Application. To limit the risk posed by integration of multiple MPoC SDKs, no more than two may be integrated into a single MPoC Application.
2A-1.7 The COTS-based MPoC Software integrating the MPoC SDK does not implement, or allow for, the decryption of encrypted sensitive assets output by the MPoC SDK.
2A-1.7.a The tester must confirm through examination and observation that the COTS-based MPoC Software integrating the MPoC SDK does not implement or allow for the decryption of sensitive assets encrypted by the MPoC SDK.
During assessment to Domain 1, it is established that the MPoC SDK only outputs sensitive assets when that data is appropriately protected⎯e.g., through the use of encryption. It is important that …
Added
p. 157
2A-1.10.a The tester must confirm through observation if the guidance of the MPoC SDK requires or allows for the COTS-based MPoC Software that is integrating the MPoC SDK to implement its own secure channels. If so, the tester must validate that the MPoC Application meets the requirements of Section 1A-1.5.
An MPoC SDK may allow for the integrating COTS-based MPoC Software to provide its own secure channels for connections to remote payment hosts. In such cases the guidance for the MPoC SDK is required to clearly outline that this is permitted, and how the COTS-based MPoC Software may securely implement the secure channel.
2A-1.10.b Secure channels implemented by the COTS-based MPoC Software integrating the MPoC SDK are used only for connection to the payment host.
2A-1.11 The COTS-based MPoC Software that integrates the MPoC SDK is either unable to access any memory and storage locations where MPoC assets may be processed or reside, …
An MPoC SDK may allow for the integrating COTS-based MPoC Software to provide its own secure channels for connections to remote payment hosts. In such cases the guidance for the MPoC SDK is required to clearly outline that this is permitted, and how the COTS-based MPoC Software may securely implement the secure channel.
2A-1.10.b Secure channels implemented by the COTS-based MPoC Software integrating the MPoC SDK are used only for connection to the payment host.
2A-1.11 The COTS-based MPoC Software that integrates the MPoC SDK is either unable to access any memory and storage locations where MPoC assets may be processed or reside, …
Added
p. 158
The MPoC Software security guidance, and MPoC Software listing, details if an MPoC SDK is an Isolating SDK or non-Isolating SDK.
2B-1 MPoC Application Security MPoC Applications that may be able to access assets of the COTS-based MPoC Software must be developed in line with security best practices for COTS device applications.
Security Requirements Test Requirements Guidance Objective: MPoC Applications that could have access to assets are developed in line with security best practice.
2B-1.1 All software in the MPoC Application is developed by an entity that either:
• Meets the requirements of the PCI Secure Software Lifecycle (SLC) Qualified Software standard, or
• Meets the requirements of Appendix D.
2B-1.1.a When the software in the MPoC Application is developed by a PCI Secure SLC- approved software vendor, the tester must confirm through examination that the entity is either listed on the PCI website and it is valid at the time of evaluation⎯e.g., the listing has …
2B-1 MPoC Application Security MPoC Applications that may be able to access assets of the COTS-based MPoC Software must be developed in line with security best practices for COTS device applications.
Security Requirements Test Requirements Guidance Objective: MPoC Applications that could have access to assets are developed in line with security best practice.
2B-1.1 All software in the MPoC Application is developed by an entity that either:
• Meets the requirements of the PCI Secure Software Lifecycle (SLC) Qualified Software standard, or
• Meets the requirements of Appendix D.
2B-1.1.a When the software in the MPoC Application is developed by a PCI Secure SLC- approved software vendor, the tester must confirm through examination that the entity is either listed on the PCI website and it is valid at the time of evaluation⎯e.g., the listing has …
Added
p. 159
2B-1.2.a The tester must confirm through testing that the modification (including application rollback) is detected by the MPoC Application, and it is not possible to perform transactions.
If the modification is detected, the tester must attempt to bypass⎯i.e., disable or remove⎯the tamper detection code.
The MPoC Application installable package needs to have its authenticity protected. This is normally a task that the MPoC Software cannot perform, as it has no visibility on the integration part of the MPoC Application.
The MPoC Application binary code is required to be resistant against tampering. The MPoC Application is required to implement controls to prevent modification of the MPoC Application installed on the COTS device, including its configuration files, and binary code.
The MPoC Solution needs to prevent older and possibly vulnerable versions of the MPoC Application from running. The version allowed to be used is controlled by the MPoC A&M back-end, and validation of this functionality is …
If the modification is detected, the tester must attempt to bypass⎯i.e., disable or remove⎯the tamper detection code.
The MPoC Application installable package needs to have its authenticity protected. This is normally a task that the MPoC Software cannot perform, as it has no visibility on the integration part of the MPoC Application.
The MPoC Application binary code is required to be resistant against tampering. The MPoC Application is required to implement controls to prevent modification of the MPoC Application installed on the COTS device, including its configuration files, and binary code.
The MPoC Solution needs to prevent older and possibly vulnerable versions of the MPoC Application from running. The version allowed to be used is controlled by the MPoC A&M back-end, and validation of this functionality is …
Added
p. 160
Module 3A: MPoC Software Security Guidance Compliance This Module covers the deployment and configuration of a certified attestation and monitoring software into the back-end.
Note: This Module is applicable for composite solutions only.
3A-1 Deployment and Configuration of Back-end Systems An MPoC Software product, when used, must be securely and correctly integrated into an MPoC Service or MPoC Solution. This integration must follow the guidance provided by the MPoC Software vendor, as well as ensuring requirements of this standard are met for the integrated system.
Security Requirements Test Requirements Guidance Objective: MPoC Software back-end systems, when used, are securely and correctly deployed and configured.
3A-1.1 When an MPoC Software product is used, the MPoC Software product is listed on the PCI SSC website.
3A-1.1.a The tester must confirm through examination and observation that the version of the MPoC Software used by the Attestation and Monitoring Service provider is PCI approved.
MPoC Solutions need to be evaluated …
Note: This Module is applicable for composite solutions only.
3A-1 Deployment and Configuration of Back-end Systems An MPoC Software product, when used, must be securely and correctly integrated into an MPoC Service or MPoC Solution. This integration must follow the guidance provided by the MPoC Software vendor, as well as ensuring requirements of this standard are met for the integrated system.
Security Requirements Test Requirements Guidance Objective: MPoC Software back-end systems, when used, are securely and correctly deployed and configured.
3A-1.1 When an MPoC Software product is used, the MPoC Software product is listed on the PCI SSC website.
3A-1.1.a The tester must confirm through examination and observation that the version of the MPoC Software used by the Attestation and Monitoring Service provider is PCI approved.
MPoC Solutions need to be evaluated …
Added
p. 161
3A-1.3.a The tester must confirm through examination and observation that the integration of the MPoC Software did not modify or reimplement MPoC Software features that are within the MPoC Software boundary.
An MPoC Software is evaluated and approved based on the features that it provides. Alteration or bypassing of any of those features may impact the security of the MPoC Software and the MPoC Solution in unexpected ways.
3A-1.4 The Attestation and Monitoring Service provider has processes in place to detect when their back-end systems require updates.
3A-1.4.a The tester must confirm through examination that the back-end A&Ms supports secure updates according to the MPoC Software security guidance document.
The MPoC Software may be developed by an entity different to that which deploys and operates the back-end attestation system and back-end monitoring system. Even where the same entity develops and operates the back- end systems, there may be separate teams or resources used for …
An MPoC Software is evaluated and approved based on the features that it provides. Alteration or bypassing of any of those features may impact the security of the MPoC Software and the MPoC Solution in unexpected ways.
3A-1.4 The Attestation and Monitoring Service provider has processes in place to detect when their back-end systems require updates.
3A-1.4.a The tester must confirm through examination that the back-end A&Ms supports secure updates according to the MPoC Software security guidance document.
The MPoC Software may be developed by an entity different to that which deploys and operates the back-end attestation system and back-end monitoring system. Even where the same entity develops and operates the back- end systems, there may be separate teams or resources used for …
Added
p. 162
3B-1 Attestation and Monitoring Policy The attestation and monitoring system policy defines what data types are collected during the attestation process, and how this data is to be interpreted and managed through the attestation and monitoring components of the MPoC Software.
Security Requirements Test Requirements Guidance Objective: The COTS devices used provide a secure and trustworthy execution environment.
3B-1.1 A documented attestation policy exists and is demonstrably in use.
3B-1.1.a The tester must confirm through examination that an attestation policy exists and includes the following topics at a minimum:
• Roles and responsibilities.
• Data collected during attestation.
• Risk rating of attestation data.
• Follow-up actions and time frames when attestation data seem to suggest a tampered component.
• References to specific procedures and/or work instructions.
The attestation policy outlines what the requirements are to ensure that any COTS device executing the MPoC Software provides a secure execution environment for the MPoC Software.
The attestation policy differs from the …
Security Requirements Test Requirements Guidance Objective: The COTS devices used provide a secure and trustworthy execution environment.
3B-1.1 A documented attestation policy exists and is demonstrably in use.
3B-1.1.a The tester must confirm through examination that an attestation policy exists and includes the following topics at a minimum:
• Roles and responsibilities.
• Data collected during attestation.
• Risk rating of attestation data.
• Follow-up actions and time frames when attestation data seem to suggest a tampered component.
• References to specific procedures and/or work instructions.
The attestation policy outlines what the requirements are to ensure that any COTS device executing the MPoC Software provides a secure execution environment for the MPoC Software.
The attestation policy differs from the …
Added
p. 163
3B-1.2.a The tester must confirm through examination that an Offline Attestation Policy exists, and it includes at a minimum:
• Checks are enabled when operating in offline mode.
• The responses when a security check is triggered.
• Requirements for escalation are noted when offline transaction processing violates the requirements of Section 1F.
Attestation and monitoring functions provided to MPoC Solutions that allow for offline transactions need to account for the potential operation of those systems while they are disconnected from the A&M back-end systems.
Section 1F of this standard details requirements for the MPoC Software when operating in offline mode. This includes preventing offline acceptance for more than 48 hours, requiring online attestation to be performed prior to enablement of offline mode, as well as other requirements. It is important that the offline A&M policy outlines the escalation path required if any of these functions of the MPoC Software are found to have been …
• Checks are enabled when operating in offline mode.
• The responses when a security check is triggered.
• Requirements for escalation are noted when offline transaction processing violates the requirements of Section 1F.
Attestation and monitoring functions provided to MPoC Solutions that allow for offline transactions need to account for the potential operation of those systems while they are disconnected from the A&M back-end systems.
Section 1F of this standard details requirements for the MPoC Software when operating in offline mode. This includes preventing offline acceptance for more than 48 hours, requiring online attestation to be performed prior to enablement of offline mode, as well as other requirements. It is important that the offline A&M policy outlines the escalation path required if any of these functions of the MPoC Software are found to have been …
Added
p. 164
Security Requirements Test Requirements Guidance Objective: Attestation data is analyzed, and signs of potential attack are consistently responded to in a way that maintains the security and integrity of the MPoC Solution.
3B-2.1 There is an overview of the MPoC Solution being monitored.
3B-2.1.a The tester must confirm through examination that a list of all components that are included in the monitoring process exists and contains references to how these are integrated into the A&M. This is required to include at least:
• The platforms supported and operated.
• MPoC Application and MPoC SDK (if used).
• Any attached card reading devices.
A clear and thorough understanding of the components used in the solution, and how they are being monitored, is vital. This includes the identification of both OS versions, and COTS device types, as the security posture of each individual platform may have an impact on the security of payment processing. For example, some platforms …
3B-2.1 There is an overview of the MPoC Solution being monitored.
3B-2.1.a The tester must confirm through examination that a list of all components that are included in the monitoring process exists and contains references to how these are integrated into the A&M. This is required to include at least:
• The platforms supported and operated.
• MPoC Application and MPoC SDK (if used).
• Any attached card reading devices.
A clear and thorough understanding of the components used in the solution, and how they are being monitored, is vital. This includes the identification of both OS versions, and COTS device types, as the security posture of each individual platform may have an impact on the security of payment processing. For example, some platforms …
Added
p. 165
3B-2.2.a The tester must confirm through examination that monitoring procedures exist and that they contain the necessary information. The monitoring procedure needs to include at a minimum the following topics:
• Definition of possible events (warning alerts, errors, etc.) from the monitoring system.
• How specific events are processed.
• How undocumented, unexpected, and unknown events are handled.
• When and how events are escalated and when the incident management process is initiated.
• How it is ensured that personnel are qualified to handle events.
• References to work instructions for the actual MPoC Software used.
This requirement ensures common understanding for those involved in the monitoring of the solution. The monitoring process may include both manual and automated aspects.
3B-2.2.b The tester must confirm through observation and interview that the monitoring procedures are actually executed. The required evidence is an overview of events that have been managed. Information about events must include date, time, description, and follow-up …
• Definition of possible events (warning alerts, errors, etc.) from the monitoring system.
• How specific events are processed.
• How undocumented, unexpected, and unknown events are handled.
• When and how events are escalated and when the incident management process is initiated.
• How it is ensured that personnel are qualified to handle events.
• References to work instructions for the actual MPoC Software used.
This requirement ensures common understanding for those involved in the monitoring of the solution. The monitoring process may include both manual and automated aspects.
3B-2.2.b The tester must confirm through observation and interview that the monitoring procedures are actually executed. The required evidence is an overview of events that have been managed. Information about events must include date, time, description, and follow-up …
Added
p. 166
3B-2.3.a The tester must confirm through examination and observation that the A&M provides for an indication of A&M results to the payment processing back-end.
The A&M provides “health” checks of the COTS platform and MPoC Application to ensure the secure operation of the MPoC Solution. When the attestation and monitoring (A&M) checks indicate that there may be a problem with any MPoC Application or COTS platform, the A&M provides that information to the payment processing back- end so that the continued operation of that specific MPoC Application can be determined.
In cases where there is sufficient information indicating that the MPoC Application is at risk of compromise, the payment processing back-end needs to be informed so that payment processing for that MPoC Application can be stopped.
This requirement does not dictate how the attestation and monitoring (A&M) results are communicated but does require that the results are current and relevant for the purposes …
The A&M provides “health” checks of the COTS platform and MPoC Application to ensure the secure operation of the MPoC Solution. When the attestation and monitoring (A&M) checks indicate that there may be a problem with any MPoC Application or COTS platform, the A&M provides that information to the payment processing back- end so that the continued operation of that specific MPoC Application can be determined.
In cases where there is sufficient information indicating that the MPoC Application is at risk of compromise, the payment processing back-end needs to be informed so that payment processing for that MPoC Application can be stopped.
This requirement does not dictate how the attestation and monitoring (A&M) results are communicated but does require that the results are current and relevant for the purposes …
Added
p. 167
3C-1 Operational Management This Section covers the operational management of the A&M service.
Security Requirements Test Requirements Guidance Objective: A&M assets processed in back-end environments are secured according to their protection types.
3C-1.1 Where A&M systems are sufficiently isolated from any payment processing systems and Cardholder Data Environment the A&M environment complies with the relevant requirements defined in Appendix A: Back-end Environment Security Requirements 3C-1.1.a The tester must confirm through examination, observation, and interview that account data is not stored, processed, or transmitted through the back-end A&Ms, and that the A&Ms are sufficiently isolated from any such account data processing systems.
When the back-end A&Ms are isolated sufficiently from the cardholder data environment, which is used to process account data, it is not a requirement that the A&M systems also be compliant to PCI DSS. However, security controls are still required in the attestation and monitoring (A&M) environment, so assessment is required to …
Security Requirements Test Requirements Guidance Objective: A&M assets processed in back-end environments are secured according to their protection types.
3C-1.1 Where A&M systems are sufficiently isolated from any payment processing systems and Cardholder Data Environment the A&M environment complies with the relevant requirements defined in Appendix A: Back-end Environment Security Requirements 3C-1.1.a The tester must confirm through examination, observation, and interview that account data is not stored, processed, or transmitted through the back-end A&Ms, and that the A&Ms are sufficiently isolated from any such account data processing systems.
When the back-end A&Ms are isolated sufficiently from the cardholder data environment, which is used to process account data, it is not a requirement that the A&M systems also be compliant to PCI DSS. However, security controls are still required in the attestation and monitoring (A&M) environment, so assessment is required to …
Added
p. 168
3C-1.2.a The tester must confirm through examination and observation that the assets of the different MPoC Solution providers are segregated when operated by a single A&M service provider.
The specifics of how any segregation is actually implemented is based on a risk assessment. This requirement does not preclude the pooling of anonymized attestation data obtained from different MPoC Solution providers for the purposes of increasing the efficacy of the A&M detection mechanisms.
Penetration testing of the A&M service provider environment is required as part of PCI DSS, or Appendix A validation.
3C-1.2.b The tester must confirm through examination and interview that the implemented segregation controls included in the scope of the A&M penetration testing process.
The specifics of how any segregation is actually implemented is based on a risk assessment. This requirement does not preclude the pooling of anonymized attestation data obtained from different MPoC Solution providers for the purposes of increasing the efficacy of the A&M detection mechanisms.
Penetration testing of the A&M service provider environment is required as part of PCI DSS, or Appendix A validation.
3C-1.2.b The tester must confirm through examination and interview that the implemented segregation controls included in the scope of the A&M penetration testing process.
Added
p. 169
Module 4A: Software Management This Module contains the requirements for the secure operation and management of the software used in an MPoC Solution. This includes any COTS-based MPoC Software, A&M Software, and MPoC Application(s).
4A-1 COTS Software Distribution and Updates Software that is to be installed and executed on the COTS device for an MPoC Solution needs to be compliant to this Section. This includes the MPoC Application that integrates the MPoC SDK, or the COTS-based MPoC Software itself if it is instantiated and distributed as a stand-alone MPoC Application. Unlike Domain 2 of this standard, which covers the development and software of the MPoC Application, this Section covers the operational aspects of distributing and maintaining an MPoC Application. This includes any ongoing key management requirements, as well as the requirements for the secure distribution of the MPoC Application(s).
These requirements do not dictate any specific type of distribution method for the …
4A-1 COTS Software Distribution and Updates Software that is to be installed and executed on the COTS device for an MPoC Solution needs to be compliant to this Section. This includes the MPoC Application that integrates the MPoC SDK, or the COTS-based MPoC Software itself if it is instantiated and distributed as a stand-alone MPoC Application. Unlike Domain 2 of this standard, which covers the development and software of the MPoC Application, this Section covers the operational aspects of distributing and maintaining an MPoC Application. This includes any ongoing key management requirements, as well as the requirements for the secure distribution of the MPoC Application(s).
These requirements do not dictate any specific type of distribution method for the …
Added
p. 170
4A-1.1 Information about how software is provisioned securely to the supported COTS devices exists.
4A-1.1.a The tester must confirm through examination that the information provided includes at a minimum:
• The supported MPoC Application distribution methods.
• How the MPoC Application distribution methods supported are protected. How access to MPoC Application distribution methods is protected (for the purposes of uploading or changing security sensitive settings).
• How the data provisioned after the MPoC Application is installed and the purpose of that data. This includes executable files and configuration files.
The protection of the MPoC Application during the provisioning lifecycle stage is needed to prevent the distribution of a malicious MPoC Application. Documentation covering the MPoC Application distribution, and provisioning helps to identify vulnerabilities in this stage of the MPoC Software lifecycle.
The MPoC Application distribution method may include the OS store of the COTS device, or an MDM solution. Regardless of what method is used, MPoC …
4A-1.1.a The tester must confirm through examination that the information provided includes at a minimum:
• The supported MPoC Application distribution methods.
• How the MPoC Application distribution methods supported are protected. How access to MPoC Application distribution methods is protected (for the purposes of uploading or changing security sensitive settings).
• How the data provisioned after the MPoC Application is installed and the purpose of that data. This includes executable files and configuration files.
The protection of the MPoC Application during the provisioning lifecycle stage is needed to prevent the distribution of a malicious MPoC Application. Documentation covering the MPoC Application distribution, and provisioning helps to identify vulnerabilities in this stage of the MPoC Software lifecycle.
The MPoC Application distribution method may include the OS store of the COTS device, or an MDM solution. Regardless of what method is used, MPoC …
Added
p. 171
4A-1.2.a The tester must confirm through examination and observation that it is not possible to perform transactions on an MPoC Application loaded onto the COTS device through means other than the defined COTS application distribution methods.
The authenticity of the MPoC Application is a paramount concern in securing account data. Loading of applications from the OS store provides a level of confidence that the application has not been tampered with before being installed on the merchant COTS device.
In some OSs, it is possible to perform “side-loading” of applications
•that is, install them separate to the normal application distribution methods and controls
•at any time by configuring the COTS device to allow for this process. In other OSs, it may be necessary to establish a developer account or perform some other actions on the COTS device to allow for loading of applications outside the distribution store formally supported by the MPoC Solution.
It is necessary …
The authenticity of the MPoC Application is a paramount concern in securing account data. Loading of applications from the OS store provides a level of confidence that the application has not been tampered with before being installed on the merchant COTS device.
In some OSs, it is possible to perform “side-loading” of applications
•that is, install them separate to the normal application distribution methods and controls
•at any time by configuring the COTS device to allow for this process. In other OSs, it may be necessary to establish a developer account or perform some other actions on the COTS device to allow for loading of applications outside the distribution store formally supported by the MPoC Solution.
It is necessary …
Added
p. 172
4A-1.4.a The tester must confirm through examination and observation that all the methods supported for distribution of the MPoC Application provide authenticity prior to initial execution.
Only authentic MPoC Applications are permitted to be installed and operated as part of an MPoC Solution. The authenticity at installation time needs to be provided by the MPoC application defined distribution method and/or COTS platform, before the MPoC Application is executed for the first time following installation or updating.
COTS platforms that do not allow for the use of a COTS application distribution method that can provide authenticity to the MPoC Application at installation time are not suitable for use with an MPoC Solution.
The minimum requirements for the COTS platform baseline
•including the need to support validation of a digital signature across MPoC Applications that are loaded onto the device
•is covered in Requirement 4A- 3.x.
Some COTS platforms may support multiple signature types or allow for the …
Only authentic MPoC Applications are permitted to be installed and operated as part of an MPoC Solution. The authenticity at installation time needs to be provided by the MPoC application defined distribution method and/or COTS platform, before the MPoC Application is executed for the first time following installation or updating.
COTS platforms that do not allow for the use of a COTS application distribution method that can provide authenticity to the MPoC Application at installation time are not suitable for use with an MPoC Solution.
The minimum requirements for the COTS platform baseline
•including the need to support validation of a digital signature across MPoC Applications that are loaded onto the device
•is covered in Requirement 4A- 3.x.
Some COTS platforms may support multiple signature types or allow for the …
Added
p. 173
4A-1.5.a The tester must confirm through examination and observation that the MPoC Application, or the distribution methods used for the MPoC Application, implements methods to permit the merchant to validate the authenticity of the MPoC Application.
The defined COTS application distribution method may not guarantee that the application that is provided is genuine, instead simply providing confirmation that it did indeed come from the COTS application distribution method used. Therefore, the merchant needs to be able to separately validate the authenticity of the MPoC Application.
Some COTS Platforms may support self-signed certificates, and it is not a requirement for a signature to chain up to an authorized Certificate Authority. Because of this, it is necessary that the merchant is able to separately validate that the MPoC Application they have downloaded is not just a valid application but is the MPoC Application they intended to download and use for payment acceptance.
This requirement is …
The defined COTS application distribution method may not guarantee that the application that is provided is genuine, instead simply providing confirmation that it did indeed come from the COTS application distribution method used. Therefore, the merchant needs to be able to separately validate the authenticity of the MPoC Application.
Some COTS Platforms may support self-signed certificates, and it is not a requirement for a signature to chain up to an authorized Certificate Authority. Because of this, it is necessary that the merchant is able to separately validate that the MPoC Application they have downloaded is not just a valid application but is the MPoC Application they intended to download and use for payment acceptance.
This requirement is …
Added
p. 174
4A-1.6.a The tester must confirm through examination that the MPoC Application vendor implements a distribution method that is able to provide secure updates of the MPoC SDK according to the MPoC Software security guidance document.
Note: This requirement is concerned with the operational process of communicating and delivering updates, not with the technical process of maintaining and updating MPoC Software.
The MPoC SDK may be developed by an entity different than that which develops and maintains the MPoC Application. Even if the same entity produces both the MPoC Software and the MPoC Application, there may be separate teams or resources used for each.
In such scenarios, it is possible that the MPoC SDK has an update process and timing that are dislocated from that of the MPoC Application.
The MPoC Software vendor is required to keep MPoC Application vendors informed of releases and changelogs as part of their validation and listing. MPoC Application vendors …
Note: This requirement is concerned with the operational process of communicating and delivering updates, not with the technical process of maintaining and updating MPoC Software.
The MPoC SDK may be developed by an entity different than that which develops and maintains the MPoC Application. Even if the same entity produces both the MPoC Software and the MPoC Application, there may be separate teams or resources used for each.
In such scenarios, it is possible that the MPoC SDK has an update process and timing that are dislocated from that of the MPoC Application.
The MPoC Software vendor is required to keep MPoC Application vendors informed of releases and changelogs as part of their validation and listing. MPoC Application vendors …
Added
p. 175
Security Requirements Test Requirements Guidance Objective: Cryptographic keys and certificates are managed securely throughout their complete lifecycle.
4A-2.1 Procedures to generate, distribute, revoke, and renew keys and certificates follow the MPoC Software security guidance and are demonstrably in use.
4A-2.1.a The tester must confirm through examination, observation, and interview, that procedures for the generation, revocation, and renewing of keys and certificates follow the MPoC Software security guidance and are demonstrably in use. The procedures must, at a minimum, include the following topics:
• Relation to incident management processes.
• Assessment of impact of key replacement (replacement of a root CA key will have more impact than a device specific key).
• Communication to stakeholders.
• Work instructions about how to actually revoke and renew specific keys and certificates.
The MPoC Software implements cryptography for various controls, and this implementation is assessed under the requirements of Domain 1. However, to ensure the security of the MPoC Solution, the …
4A-2.1 Procedures to generate, distribute, revoke, and renew keys and certificates follow the MPoC Software security guidance and are demonstrably in use.
4A-2.1.a The tester must confirm through examination, observation, and interview, that procedures for the generation, revocation, and renewing of keys and certificates follow the MPoC Software security guidance and are demonstrably in use. The procedures must, at a minimum, include the following topics:
• Relation to incident management processes.
• Assessment of impact of key replacement (replacement of a root CA key will have more impact than a device specific key).
• Communication to stakeholders.
• Work instructions about how to actually revoke and renew specific keys and certificates.
The MPoC Software implements cryptography for various controls, and this implementation is assessed under the requirements of Domain 1. However, to ensure the security of the MPoC Solution, the …
Added
p. 176
• Protected through use of HSMs compliant to FIPS140-2/3 level 3, or PCI HSM requirements.
• Protected through use of HSMs compliant to FIPS 140-2/3 level 2 and deployed in a Controlled Environment (as per the definition in ISO13491).
• Unique per session and forward secret.
4A-2.2.a The tester must confirm through examination and observation that cleartext secret or private cryptographic keys in the back-end environments that are used for the security of the implementation and are not related to PIN security, are:
• Stored in HSMs compliant to FIPS140-2/3 level 3 (or above), or PCI HSM requirements.
• Stored in HSMs compliant to FIPS140-2/3 level 2 and deployed in a Controlled Environment (as per the definition in ISO13491).
Cryptographic keys need to be protected to prevent unauthorized or unnecessary access that could result in the exposure of encrypted data.
Secret or private cryptographic keys need to be stored in an encrypted form or within an SCD, …
• Protected through use of HSMs compliant to FIPS 140-2/3 level 2 and deployed in a Controlled Environment (as per the definition in ISO13491).
• Unique per session and forward secret.
4A-2.2.a The tester must confirm through examination and observation that cleartext secret or private cryptographic keys in the back-end environments that are used for the security of the implementation and are not related to PIN security, are:
• Stored in HSMs compliant to FIPS140-2/3 level 3 (or above), or PCI HSM requirements.
• Stored in HSMs compliant to FIPS140-2/3 level 2 and deployed in a Controlled Environment (as per the definition in ISO13491).
Cryptographic keys need to be protected to prevent unauthorized or unnecessary access that could result in the exposure of encrypted data.
Secret or private cryptographic keys need to be stored in an encrypted form or within an SCD, …
Added
p. 177
4A-2.4.a The tester must confirm through examination and interview that cryptographic keys are generated and managed by the Cloud HSM user, and not accessible to the Cloud HSM service provider.
Cloud service providers offer different ways to manage HSM keys. In general, three options are supported:
• Keys are generated and managed by the Cloud service provider. Depending on the HSM type, this could even mean that HSM keys are shared with other customers.
• Keys are generated and managed by the Cloud HSM user, but within the cloud environment. The keys are not shared with other customers, but security depends on the Cloud service provider’s configuration.
• Keys are generated by the Cloud HSM user in their own premises and the transferred securely to the Cloud service provider.
Some Cloud HSM systems use the HSM only for storage of keys and allow for export of keys for cryptographic operations. These types of Cloud HSM …
Cloud service providers offer different ways to manage HSM keys. In general, three options are supported:
• Keys are generated and managed by the Cloud service provider. Depending on the HSM type, this could even mean that HSM keys are shared with other customers.
• Keys are generated and managed by the Cloud HSM user, but within the cloud environment. The keys are not shared with other customers, but security depends on the Cloud service provider’s configuration.
• Keys are generated by the Cloud HSM user in their own premises and the transferred securely to the Cloud service provider.
Some Cloud HSM systems use the HSM only for storage of keys and allow for export of keys for cryptographic operations. These types of Cloud HSM …
Added
p. 178
4A-2.6.a The tester must confirm through examination, observation, and interview that all keys in the solution have their integrity and authenticity protected.
Cryptographic keys are to be protected against unauthorized or unintentional change. For example, this can be achieved by:
• Implementing cryptographic controls such as key blocks. Key blocks may be implemented entirely in the back-end systems, or in concert with the COTS-based MPoC Software (refer requirements in 1A-3.x and 1A- 4.x).
• Implementing key check value or key fingerprint verification processes.
• Managing public keys in certificates.
4A-2.7 Management of secret and private cryptographic keys implement the principles of dual control and split knowledge.
4A-2.7.a The tester must confirm through examination, observation, and interview that dual control and split knowledge are implemented in the organization to manage secret and private cryptographic keys.
Split knowledge requires that no individual has any information about any part, even a single bit, of the cleartext key. Dual control requires …
Cryptographic keys are to be protected against unauthorized or unintentional change. For example, this can be achieved by:
• Implementing cryptographic controls such as key blocks. Key blocks may be implemented entirely in the back-end systems, or in concert with the COTS-based MPoC Software (refer requirements in 1A-3.x and 1A- 4.x).
• Implementing key check value or key fingerprint verification processes.
• Managing public keys in certificates.
4A-2.7 Management of secret and private cryptographic keys implement the principles of dual control and split knowledge.
4A-2.7.a The tester must confirm through examination, observation, and interview that dual control and split knowledge are implemented in the organization to manage secret and private cryptographic keys.
Split knowledge requires that no individual has any information about any part, even a single bit, of the cleartext key. Dual control requires …
Added
p. 179
4A-2.8.a The tester must confirm through examination and observation that a revocation mechanism exists and is effective in preventing the use of revoked certificates.
Expired certificates can introduce unacceptable risk to the solution. Payment functions are required to be halted when certificates that are relied upon have expired or are otherwise detected as no longer valid. Expired certificates may be an indication of a malicious user acting as an imposter of a legitimate organization or process who is phishing for sensitive information.
Many security incidents are caused by expired or revoked certificates. While understanding of the keys used is important and collected in the key/certificate tables, it is equally important to have procedures to act upon if any key expires or is suspected of being compromised.
The requirement is applicable to all components of the solution and includes only the certificates upon which the solution relies for security purposes.
Expired certificates can introduce unacceptable risk to the solution. Payment functions are required to be halted when certificates that are relied upon have expired or are otherwise detected as no longer valid. Expired certificates may be an indication of a malicious user acting as an imposter of a legitimate organization or process who is phishing for sensitive information.
Many security incidents are caused by expired or revoked certificates. While understanding of the keys used is important and collected in the key/certificate tables, it is equally important to have procedures to act upon if any key expires or is suspected of being compromised.
The requirement is applicable to all components of the solution and includes only the certificates upon which the solution relies for security purposes.
Added
p. 180
Security Requirements Test Requirements Guidance Objective: The security of systems relied upon by the MPoC Product is sufficient and maintained over time.
4A-3.1 A penetration test has been performed on the interfaces between the COTS-based MPoC Software and back- end environments (e.g., A&M, payment processing and/or remote kernel) prior to the validation and listing of an MPoC Solution or A&M service provider, and at least once per year thereafter.
4A-3.1.a The tester must confirm through examination that a penetration test has been performed on the interfaces between the COTS- based MPoC Software in a suitable test application, and back-end environments prior to initial deployment, and at least annually thereafter. Penetration testing reports must be examined to confirm that the scope covers all aspects of the MPoC Solution, or A&Ms, and that any major vulnerabilities found during the penetration testing have been remediated.
All back-end entry points meant to parse and process data received …
4A-3.1 A penetration test has been performed on the interfaces between the COTS-based MPoC Software and back- end environments (e.g., A&M, payment processing and/or remote kernel) prior to the validation and listing of an MPoC Solution or A&M service provider, and at least once per year thereafter.
4A-3.1.a The tester must confirm through examination that a penetration test has been performed on the interfaces between the COTS- based MPoC Software in a suitable test application, and back-end environments prior to initial deployment, and at least annually thereafter. Penetration testing reports must be examined to confirm that the scope covers all aspects of the MPoC Solution, or A&Ms, and that any major vulnerabilities found during the penetration testing have been remediated.
All back-end entry points meant to parse and process data received …
Added
p. 181
4A-3.2.a The tester must confirm through examination that a vulnerability-reporting program exists for the system, and there is evidence of accepting and remediating security vulnerabilities found through this program.
Penetration tests need to be performed by suitably skilled resources and may be performed by resources internal to the entity if such resources exist. When penetration testing is performed by internal resources, the people performing the testing need to be separate from those who perform any operation, development, or integration work.
Skills expected from the resources used for penetration testing include an understanding of EMV protocols and payment processing, skills and experience with mobile security and communications protocols, and a clear history of penetration testing experience.
Results from annual penetration testing may not exist for newly deployed MPoC Solutions or A&M service providers but need to be provided for any review performed after the first year after their initial validation. However, an initial penetration …
Penetration tests need to be performed by suitably skilled resources and may be performed by resources internal to the entity if such resources exist. When penetration testing is performed by internal resources, the people performing the testing need to be separate from those who perform any operation, development, or integration work.
Skills expected from the resources used for penetration testing include an understanding of EMV protocols and payment processing, skills and experience with mobile security and communications protocols, and a clear history of penetration testing experience.
Results from annual penetration testing may not exist for newly deployed MPoC Solutions or A&M service providers but need to be provided for any review performed after the first year after their initial validation. However, an initial penetration …
Added
p. 182
The COTS platform baseline outlines the COTS platforms on which the MPoC Application may execute and accept payment transactions. The establishment and maintenance of this baseline must include the minimum set of features required of the MPoC Software, both those outlined in this standard and those self-imposed by the MPoC Solution itself.
The baseline may be instantiated in various ways and is expected to include use of both whitelist and specific block-list elements. For example, a baseline may include accommodation for COTS devices with a specific OS version, except for those COTS devices that also have certain undesirable features (such as NFC logging, or insecure OS modifications).
The inclusion of any COTS device executing the MPoC Software must be validated by the A&M.
The baseline may be instantiated in various ways and is expected to include use of both whitelist and specific block-list elements. For example, a baseline may include accommodation for COTS devices with a specific OS version, except for those COTS devices that also have certain undesirable features (such as NFC logging, or insecure OS modifications).
The inclusion of any COTS device executing the MPoC Software must be validated by the A&M.
Added
p. 183
4A-3.4.a The tester must confirm through examination that the COTS platform baseline procedure exists. The tester must examine the procedure to verify that it contains at a minimum:
• Roles and Responsibilities⎯e.g., who is allowed to update the COTS platform baseline.
• The acceptance process and criteria for adding COTS platforms to the COTS platform baseline (see next requirement).
• How COTS platforms are added to the COTS platform baseline.
• How decisions are made to remove previously acceptable COTS platforms from the COTS platform baseline. This must include a reference to the vulnerability management process.
• How affected entities are informed of changes to the COTS platform baseline that will affect them.
The COTS platform baseline is not static and will change over time. Therefore, a procedure is required be in place to manage the existing baseline with respect to risks to the solution.
There needs to be a clear process for accepting platforms into the …
• Roles and Responsibilities⎯e.g., who is allowed to update the COTS platform baseline.
• The acceptance process and criteria for adding COTS platforms to the COTS platform baseline (see next requirement).
• How COTS platforms are added to the COTS platform baseline.
• How decisions are made to remove previously acceptable COTS platforms from the COTS platform baseline. This must include a reference to the vulnerability management process.
• How affected entities are informed of changes to the COTS platform baseline that will affect them.
The COTS platform baseline is not static and will change over time. Therefore, a procedure is required be in place to manage the existing baseline with respect to risks to the solution.
There needs to be a clear process for accepting platforms into the …
Added
p. 184
• The COTS platform’s that are supported.
• Each supported COTS platform provides at a minimum:
• An enforcing mandatory access control framework.
• A trusted boot mechanism that validates the OS authenticity.
• Validation of an application cryptographic signature upon installation of applications.
• Isolation of the interfaces and memory spaces used by different applications.
4A-3.4.c The tester must confirm through examination and observation that, for any COTS- based MPoC Software that executes in the REE, COTS operating modes that may impact security are not part of the COTS platform baseline.
4A-3.4.d The tester must confirm through observation and interview that the COTS platform baseline procedure is actually executed. The required evidence is an overview of changes to the COTS platform baseline. This must include a description of the changes, related change management tickets, and communication to affected merchants.
• Each supported COTS platform provides at a minimum:
• An enforcing mandatory access control framework.
• A trusted boot mechanism that validates the OS authenticity.
• Validation of an application cryptographic signature upon installation of applications.
• Isolation of the interfaces and memory spaces used by different applications.
4A-3.4.c The tester must confirm through examination and observation that, for any COTS- based MPoC Software that executes in the REE, COTS operating modes that may impact security are not part of the COTS platform baseline.
4A-3.4.d The tester must confirm through observation and interview that the COTS platform baseline procedure is actually executed. The required evidence is an overview of changes to the COTS platform baseline. This must include a description of the changes, related change management tickets, and communication to affected merchants.
Added
p. 185
4A-3.5.a The tester must confirm through examination, observation, and interview that vulnerabilities in the COTS OS are analyzed periodically and assessed against known and unknown vulnerabilities.
It is intended that the vendor identifies the vulnerabilities that affect the system baseline.
It is expected that not all platform vulnerabilities will result in risk to MPoC Solutions, but a process to determine if this is the case needs to be implemented. It is not sufficient for vulnerabilities to be dismissed without appropriate research and testing.
Not all vulnerabilities that affect platforms within the COTS baseline require specific mitigations. Vulnerabilities that are not directly exploitable or cannot result in exposure or risk to the MPoC Solution assets may be considered and mitigations deferred until increased risk is noted.
Security review of the COTS OS requires both threat detection and mitigation, as well as vulnerability detection and mitigation. This may include detailed review of each CVE for all …
It is intended that the vendor identifies the vulnerabilities that affect the system baseline.
It is expected that not all platform vulnerabilities will result in risk to MPoC Solutions, but a process to determine if this is the case needs to be implemented. It is not sufficient for vulnerabilities to be dismissed without appropriate research and testing.
Not all vulnerabilities that affect platforms within the COTS baseline require specific mitigations. Vulnerabilities that are not directly exploitable or cannot result in exposure or risk to the MPoC Solution assets may be considered and mitigations deferred until increased risk is noted.
Security review of the COTS OS requires both threat detection and mitigation, as well as vulnerability detection and mitigation. This may include detailed review of each CVE for all …
Added
p. 186
MPoC allows for the use of devices and platforms which may not have otherwise undergone rigorous testing through other security validation methods. In such cases these items in the baseline are required to be included in the annual penetration testing.
For example, a device may be designed for use in an enterprise environment and therefore not undergo the testing normally required by the Operating System vendor. In such circumstances, these platform and operating system versions are to be included in scope for the annual penetration test.
For example, a device may be designed for use in an enterprise environment and therefore not undergo the testing normally required by the Operating System vendor. In such circumstances, these platform and operating system versions are to be included in scope for the annual penetration test.
Added
p. 187
Security Requirements Test Requirements Guidance Objective: Back-end environments are implemented and operated securely and in ways that maintain compliance to other applicable standards.
4A-4.1 Environments that store, process, or transmit account data comply with the requirements of PCI DSS (including environments implementing remote kernels).
4A-4.1.a The tester must confirm through examination that there exists a valid Attestation of Compliance (AOC) outlining compliance of any environment within the MPoC Solution that stores, processes, or transmits account data with the PCI DSS requirements.
Environments that are PCI DSS compliant demonstrate that the minimum set of industry-expected security controls have been applied to that environment, which reduces risk compared to environments that do not apply security controls.
This includes any payment processing back-ends directly implemented by the MPoC Solution, or where there is the ability for the MPoC Solution systems to have access to cleartext account data or the cryptographic keys that can be used to decrypt …
4A-4.1 Environments that store, process, or transmit account data comply with the requirements of PCI DSS (including environments implementing remote kernels).
4A-4.1.a The tester must confirm through examination that there exists a valid Attestation of Compliance (AOC) outlining compliance of any environment within the MPoC Solution that stores, processes, or transmits account data with the PCI DSS requirements.
Environments that are PCI DSS compliant demonstrate that the minimum set of industry-expected security controls have been applied to that environment, which reduces risk compared to environments that do not apply security controls.
This includes any payment processing back-ends directly implemented by the MPoC Solution, or where there is the ability for the MPoC Solution systems to have access to cleartext account data or the cryptographic keys that can be used to decrypt …
Added
p. 188
4A-4.4.a The tester must confirm either that the A&M environment complies with the requirements of Domain 3 of this standard or that the A&M service provider is listed on the PCI website as an approved A&M service provider.
The A&M environment may be operated by a service provider who already has been assessed and is listed as compliant to these requirements. Otherwise, the requirements in Domain 3: Attestation and Monitoring apply.
The A&M environment may be operated by a service provider who already has been assessed and is listed as compliant to these requirements. Otherwise, the requirements in Domain 3: Attestation and Monitoring apply.
Added
p. 189
Where the payment-processing and PIN processing are not performed by the MPoC Solution Provider those aspects may be considered out of scope of the assessment. Only those aspects that are included
•e.g., a payment switch operated by the MPoC Solution provider
•are to be included in the assessment of this Domain. However, it is not possible for an MPoC Solution that allows for PIN entry on the COTS device to never include validation of a PIN processing environment. Equally, it is also expected that all MPoC Solutions will include decryption or key management environments for account data sent from the MPoC Applications that are deployed as part of the MPoC Solution.
Although it is not necessary for the MPoC Solution provider to develop, implement, or operate all of these systems, it is the responsibility of the MPoC Solution provider to ensure that the relevant requirements for each are met. This may be achieved …
•e.g., a payment switch operated by the MPoC Solution provider
•are to be included in the assessment of this Domain. However, it is not possible for an MPoC Solution that allows for PIN entry on the COTS device to never include validation of a PIN processing environment. Equally, it is also expected that all MPoC Solutions will include decryption or key management environments for account data sent from the MPoC Applications that are deployed as part of the MPoC Solution.
Although it is not necessary for the MPoC Solution provider to develop, implement, or operate all of these systems, it is the responsibility of the MPoC Solution provider to ensure that the relevant requirements for each are met. This may be achieved …
Added
p. 190
5A-1 Merchant Identification and Communication Initial provisioning of the MPoC Application includes providing for the unique identification of the merchant. Ensuring that the merchant is informed of changes or requirements of the MPoC Solution as the solution changes over time is vital to the security of the solution.
Security Requirements Test Requirements Guidance Objective: The merchant is onboarded securely and kept up to date with relevant information in a timely manner.
5A-1.1 The process of onboarding new merchants is documented. At a minimum, the process must describe how merchant identification is performed.
5A-1.1.a The tester must confirm through examination that the onboarding process is documented.
Identification is an important security measure against financial fraud to verify the identity, suitability, and risks involved with maintaining a business relationship with the merchant.
This requirement is not intended to cover the legal or financial process of merchant on-boarding, but to ensure merchants are uniquely identified to help facilitate …
Security Requirements Test Requirements Guidance Objective: The merchant is onboarded securely and kept up to date with relevant information in a timely manner.
5A-1.1 The process of onboarding new merchants is documented. At a minimum, the process must describe how merchant identification is performed.
5A-1.1.a The tester must confirm through examination that the onboarding process is documented.
Identification is an important security measure against financial fraud to verify the identity, suitability, and risks involved with maintaining a business relationship with the merchant.
This requirement is not intended to cover the legal or financial process of merchant on-boarding, but to ensure merchants are uniquely identified to help facilitate …
Added
p. 191
5A-1.3.a The tester must confirm through examination that a communication plan exists and contains the following information at a minimum:
• Changes to the system baseline.
• Changes to any user manual including at a minimum:
• How the MPoC Application must be installed and provided with unique (configuration) data.
• How to use the MPoC Application securely⎯e.g., privacy during the customer PIN entry process.
• Any security responsibilities that belong to the merchant when using the Solution.
• User information about peripheral such as non-PTS approved MSR or PCI PTS POI if used in the Solution.
• How to contact the MPoC Solution provider.
• Planned maintenance downtime.
• Provisioned credentials.
• Information about potential compromise/security incidents.
• End User License Agreement (EULA).
It is important that the merchant receives relevant information in a timely manner, and this process cannot be performed ad hoc when issues arise. A merchant communication plan ensures that the processes for how and when to communicate …
• Changes to the system baseline.
• Changes to any user manual including at a minimum:
• How the MPoC Application must be installed and provided with unique (configuration) data.
• How to use the MPoC Application securely⎯e.g., privacy during the customer PIN entry process.
• Any security responsibilities that belong to the merchant when using the Solution.
• User information about peripheral such as non-PTS approved MSR or PCI PTS POI if used in the Solution.
• How to contact the MPoC Solution provider.
• Planned maintenance downtime.
• Provisioned credentials.
• Information about potential compromise/security incidents.
• End User License Agreement (EULA).
It is important that the merchant receives relevant information in a timely manner, and this process cannot be performed ad hoc when issues arise. A merchant communication plan ensures that the processes for how and when to communicate …
Added
p. 192
Security Requirements Test Requirements Guidance Objective: Formal processes exist to define and align the interaction and roles of the different entities in the MPoC Solution.
5A-2.1 Documentation exists that describes how the operational processes are aligned between the different entities in the MPoC Solution.
5A-2.1.a The tester must confirm through examination that documentation on cooperation exists and that it contains the required information.
Documentation must contain the following at a minimum:
• Contact information of all entities involved.
• Agreements on incident management processes.
• Agreements on escalation processes.
The Solution might be operationally managed by different entities. This often leads to problems in case of incidents covering more than one entity. Agreements on these kinds of topics help to solve potential incidents efficiently.
For example, in the case where a specific COTS Platform is removed from the A&M baseline due to security concerns, it must be clear how this process of removal is to be handled between …
5A-2.1 Documentation exists that describes how the operational processes are aligned between the different entities in the MPoC Solution.
5A-2.1.a The tester must confirm through examination that documentation on cooperation exists and that it contains the required information.
Documentation must contain the following at a minimum:
• Contact information of all entities involved.
• Agreements on incident management processes.
• Agreements on escalation processes.
The Solution might be operationally managed by different entities. This often leads to problems in case of incidents covering more than one entity. Agreements on these kinds of topics help to solve potential incidents efficiently.
For example, in the case where a specific COTS Platform is removed from the A&M baseline due to security concerns, it must be clear how this process of removal is to be handled between …
Added
p. 193
This appendix is referenced through test items outlined previously in the MPoC standard, where security assurance of those systems is required, but assessment to PCI DSS is not otherwise in scope. Where assessment against the requirements in this appendix is to be performed, the MPoC laboratory must confirm that all relevant systems and personnel are included. This may include subsets of all possible systems or personnel if sufficient clarity on the systems and operations of the environment can be determined. The term “all personnel” as used within these requirements refers to all personnel deemed to be in scope by the MPoC laboratory.
Assessments to Appendix A are expected to be performed by suitably qualified individuals and cannot be performed as a self-assessment. Remote assessments may be performed to Appendix A, if in line with current PCI SSC guidance on remote assessment processes.
Assessments to Appendix A are expected to be performed by suitably qualified individuals and cannot be performed as a self-assessment. Remote assessments may be performed to Appendix A, if in line with current PCI SSC guidance on remote assessment processes.
Added
p. 194
A.1.1 Security governance A.1.1.1 Security objectives are aligned with business objectives.
Added
p. 194
The security objectives need to be defined as part of an overarching security strategy that supports and facilitates business objectives. The security strategy needs to 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.
A.1.1.2 Responsibilities and accountability for meeting security objectives are assigned formally, including responsibilities for the security of the environment.
The assignment of specific roles and responsibilities need to include monitoring and measurement of performance to ensure security objectives are met. Roles and responsibilities may be assigned to a single owner or multiple owners for different aspects.
Ownership needs to be assigned to individuals with the authority to make risk-based decisions and upon whom accountability rests for the specific function. Duties are required to be defined formally, and owners must be able to demonstrate an understanding of their responsibilities and accountability.
A.1.1.3 Responsibility for identifying …
A.1.1.2 Responsibilities and accountability for meeting security objectives are assigned formally, including responsibilities for the security of the environment.
The assignment of specific roles and responsibilities need to include monitoring and measurement of performance to ensure security objectives are met. Roles and responsibilities may be assigned to a single owner or multiple owners for different aspects.
Ownership needs to be assigned to individuals with the authority to make risk-based decisions and upon whom accountability rests for the specific function. Duties are required to be defined formally, and owners must be able to demonstrate an understanding of their responsibilities and accountability.
A.1.1.3 Responsibility for identifying …
Added
p. 195
A strong security policy, or policies, set the security tone for the entity as a whole and inform personnel what is expected of them. All personnel must be aware of the sensitivity of data and their responsibilities for protecting it. The security policy needs to be updated as needed in response to changes in the environment, results of risk assessments, implementation of new technologies, and changes in business objectives.
Personnel must be aware of all policies and policy updates, including their applicable responsibilities. Methods of communicating policies need to include a mechanism for personnel to acknowledge they have received and read the policy or policy update. Personnel acknowledgment may be in writing or electronic.
All security policies and policy updates must be approved by management to ensure alignment with the entity’s security strategy and business objectives. Any exception to the policies requires management sign-off to ensure the appropriate due diligence is done …
Personnel must be aware of all policies and policy updates, including their applicable responsibilities. Methods of communicating policies need to include a mechanism for personnel to acknowledge they have received and read the policy or policy update. Personnel acknowledgment may be in writing or electronic.
All security policies and policy updates must be approved by management to ensure alignment with the entity’s security strategy and business objectives. Any exception to the policies requires management sign-off to ensure the appropriate due diligence is done …
Added
p. 196
• Interview personnel responsible for risk- assessment process.
Risks to environments must be assessed at least annually and upon significant changes. The risk assessment is required to identify assets, threats, likelihood, and potential impacts. Risk considerations need to include internal and external attacks⎯e.g., for cybercrime, fraud, or theft⎯internal control failures, and malware. Risks must be prioritized, and resources allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized. Considerations are required to include regulatory obligations and changes in technology⎯e.g., deprecation of encryption algorithms.
Note: Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
A.1.3.2 The documented risk-assessment process is performed at least annually and upon significant changes.
A.1.4 Manage risk A.1.4.1 A formal risk-management strategy is defined.
The risk-management strategy defines a structured approach for identifying, evaluating, managing, and monitoring risk. The strategy is required to include requirements for regularly …
Risks to environments must be assessed at least annually and upon significant changes. The risk assessment is required to identify assets, threats, likelihood, and potential impacts. Risk considerations need to include internal and external attacks⎯e.g., for cybercrime, fraud, or theft⎯internal control failures, and malware. Risks must be prioritized, and resources allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized. Considerations are required to include regulatory obligations and changes in technology⎯e.g., deprecation of encryption algorithms.
Note: Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
A.1.3.2 The documented risk-assessment process is performed at least annually and upon significant changes.
A.1.4 Manage risk A.1.4.1 A formal risk-management strategy is defined.
The risk-management strategy defines a structured approach for identifying, evaluating, managing, and monitoring risk. The strategy is required to include requirements for regularly …
Added
p. 197
• Examine results of due diligence efforts
Due-diligence processes need to include thorough vetting and a risk analysis prior to establishing a formal relationship with the third party. Specific due-diligence processes and goals will vary for each entity, and each is required to provide sufficient assurance that the third party can meet the entity’s security and operational needs.
A.1.5.3 Security responsibilities are defined clearly for each third-party engagement.
• Examine documentation
The specific approach for defining security responsibilities will depend on the type of service, as well as the particular agreement between the entity and any third parties. The entity needs to have a clear understanding of the security responsibilities to be met by the third party and those to be met by the entity.
A.1.5.4 The entity periodically verifies that the agreed-upon responsibilities are being met.
• Examine results of periodic verification.
The specific type of evidence provided by the third party will depend on the …
Due-diligence processes need to include thorough vetting and a risk analysis prior to establishing a formal relationship with the third party. Specific due-diligence processes and goals will vary for each entity, and each is required to provide sufficient assurance that the third party can meet the entity’s security and operational needs.
A.1.5.3 Security responsibilities are defined clearly for each third-party engagement.
• Examine documentation
The specific approach for defining security responsibilities will depend on the type of service, as well as the particular agreement between the entity and any third parties. The entity needs to have a clear understanding of the security responsibilities to be met by the third party and those to be met by the entity.
A.1.5.4 The entity periodically verifies that the agreed-upon responsibilities are being met.
• Examine results of periodic verification.
The specific type of evidence provided by the third party will depend on the …
Added
p. 198
• Examine security-awareness materials.
The security-awareness program needs to result in personnel understanding the security policy and procedures, and their responsibilities for following secure processes. All personnel
•including full-time, part-time and temporary employees, contractors, and consultants
• with access to or the ability to impact the security of the environment must be required to complete training. Training is required upon hire and include periodic refresher sessions at appropriate intervals. The frequency of training needs to be aligned with the entity’s policies for education and security awareness, and commensurate with personnel job function.
A.1.6.2 Personnel receive security awareness training at defined intervals, as appropriate for their job function but at least every 12 months.
• Examine records of attendance.
A.1.6.3 Personnel are aware of the security policy and responsibilities as applicable to their job function.
The security-awareness program needs to result in personnel understanding the security policy and procedures, and their responsibilities for following secure processes. All personnel
•including full-time, part-time and temporary employees, contractors, and consultants
• with access to or the ability to impact the security of the environment must be required to complete training. Training is required upon hire and include periodic refresher sessions at appropriate intervals. The frequency of training needs to be aligned with the entity’s policies for education and security awareness, and commensurate with personnel job function.
A.1.6.2 Personnel receive security awareness training at defined intervals, as appropriate for their job function but at least every 12 months.
• Examine records of attendance.
A.1.6.3 Personnel are aware of the security policy and responsibilities as applicable to their job function.
Added
p. 199
• Examine results of screening process.
The intent of screening personnel is to reduce the risk of fraud and unscrupulous behavior from an internal resource. Role descriptions need to describe the level of security or access required for the role, and the level of screening needs to be appropriate for the particular position. Positions requiring greater responsibility or that have administrative access to critical data or systems may warrant more detailed background checks than positions with less responsibility and access. The policy is required to also cover 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 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 …
The intent of screening personnel is to reduce the risk of fraud and unscrupulous behavior from an internal resource. Role descriptions need to describe the level of security or access required for the role, and the level of screening needs to be appropriate for the particular position. Positions requiring greater responsibility or that have administrative access to critical data or systems may warrant more detailed background checks than positions with less responsibility and access. The policy is required to also cover 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 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 …
Added
p. 200
• Examine evidence of reviews and/or ongoing monitoring.
Periodic reviews and/or ongoing monitoring of personnel and activities is required to ensure that security is included as part of normal business operations on an ongoing basis. Reviews must be performed by responsible personnel as defined by the entity. The frequency of reviews is required to be defined in accordance with the entity’s risk assessments and be appropriate for the particular job function.
A.1.8.2 Processes to detect and respond to security control failures are defined and implemented.
• Examine documented processes.
• Observe implemented processes.
The entity needs to be able to detect any failures in security controls and respond to them in a timely manner. Processes for responding to security control failures is required to include:
• Restoring the security control
• 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 …
Periodic reviews and/or ongoing monitoring of personnel and activities is required to ensure that security is included as part of normal business operations on an ongoing basis. Reviews must be performed by responsible personnel as defined by the entity. The frequency of reviews is required to be defined in accordance with the entity’s risk assessments and be appropriate for the particular job function.
A.1.8.2 Processes to detect and respond to security control failures are defined and implemented.
• Examine documented processes.
• Observe implemented processes.
The entity needs to be able to detect any failures in security controls and respond to them in a timely manner. Processes for responding to security control failures is required to include:
• Restoring the security control
• 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 …
Added
p. 201
A.2.1 Protect systems from untrusted systems and networks A.2.1.1 A security policy(s) and procedures for protection of the environment boundaries are maintained and implemented.
Policies for protecting the environment boundaries need to define the purpose, scope, roles, and responsibilities of defined boundaries to protect system components from untrusted networks. The policy is required to be kept up to date, approved by management, and communicated to applicable personnel.
A.2.1.2 Up-to-date network and data-flow information is maintained for all communication paths.
• Examine network and data-flow information.
• Observe methods used to maintain up-to-date network and data-flow information.
Network and data-flow information (e.g., diagrams or network-mapping tools) accurately document how the entity’s networks are configured, the identity and location of all systems, how systems are connected to each other, and all communication paths with trusted and untrusted networks.
A.2.1.3 Access between trusted and untrusted networks, systems, and applications is limited via physical and/or logical controls.
• Examine documentation describing …
Policies for protecting the environment boundaries need to define the purpose, scope, roles, and responsibilities of defined boundaries to protect system components from untrusted networks. The policy is required to be kept up to date, approved by management, and communicated to applicable personnel.
A.2.1.2 Up-to-date network and data-flow information is maintained for all communication paths.
• Examine network and data-flow information.
• Observe methods used to maintain up-to-date network and data-flow information.
Network and data-flow information (e.g., diagrams or network-mapping tools) accurately document how the entity’s networks are configured, the identity and location of all systems, how systems are connected to each other, and all communication paths with trusted and untrusted networks.
A.2.1.3 Access between trusted and untrusted networks, systems, and applications is limited via physical and/or logical controls.
• Examine documentation describing …
Added
p. 202
• Examine documented methods for monitoring and/or periodically reviewing network connectivity controls.
• Observe implemented methods and processes.
Reviewing device configurations allows the entity to identify and remove any unneeded, outdated, or incorrect rules and confirm that only authorized connections, ports, protocols, services, and APIs are allowed as defined in the documented business justifications. All other services, protocols, and ports need to remain disabled or be removed through periodic reviews. 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.
A.2.2 Protect systems from network threats A.2.2.1 Controls are implemented to detect and/or block known and unknown network attacks.
• Examine documented controls/configuration standards.
• Observe implemented methods and processes.
Reviewing device configurations allows the entity to identify and remove any unneeded, outdated, or incorrect rules and confirm that only authorized connections, ports, protocols, services, and APIs are allowed as defined in the documented business justifications. All other services, protocols, and ports need to remain disabled or be removed through periodic reviews. 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.
A.2.2 Protect systems from network threats A.2.2.1 Controls are implemented to detect and/or block known and unknown network attacks.
• Examine documented controls/configuration standards.
Added
p. 202
Controls must be implemented at the perimeter and critical systems points and include consideration of both network-based and application-based attack vectors. Methods of detection may include signature-based, behavioral, and other mechanisms that analyze traffic flows. Examples of tools include IDS/IPS, host firewalls, and real-time traffic analysis tools. All mechanisms
•such as detection engines, baselines, and signatures
•must be configured, maintained, and updated per vendor instructions to ensure optimal protection.
A.2.2.2 Suspicious traffic is blocked or generates an alert that is investigated and responded to.
• Observe implemented controls and processes.
If suspicious traffic is not automatically blocked, an alert should be generated that is actively monitored and immediately investigated.
When suspicious traffic is automatically blocked, a record of the traffic needs to be generated and investigated to determine whether action is needed to prevent further attack.
•such as detection engines, baselines, and signatures
•must be configured, maintained, and updated per vendor instructions to ensure optimal protection.
A.2.2.2 Suspicious traffic is blocked or generates an alert that is investigated and responded to.
• Observe implemented controls and processes.
If suspicious traffic is not automatically blocked, an alert should be generated that is actively monitored and immediately investigated.
When suspicious traffic is automatically blocked, a record of the traffic needs to be generated and investigated to determine whether action is needed to prevent further attack.
Added
p. 203
A.3.1 Secure application development A.3.1.1 A security policy(s) and procedures for secure management of the Software Development Lifecycle (SDLC) is maintained and implemented.
When software is developed by the entity or bespoke or custom software is developed by a third party for the entity, the software-development process is required to employ secure coding practices to address common vulnerabilities applicable to the particular technology. The entity needs to remain up to date with vulnerability trends and update its secure coding practices and developer training as needed to address new threats. Examples of current best practices include OWASP, SANS CWE Top 25, and CERT Secure Coding.
Application developers must be trained properly to identify and resolve issues related to common coding vulnerabilities. Having staff knowledgeable about secure software- development practices minimizes the number of security vulnerabilities accidentally introduced through poor coding practices. Training for developers may be provided in-house or by third parties and …
When software is developed by the entity or bespoke or custom software is developed by a third party for the entity, the software-development process is required to employ secure coding practices to address common vulnerabilities applicable to the particular technology. The entity needs to remain up to date with vulnerability trends and update its secure coding practices and developer training as needed to address new threats. Examples of current best practices include OWASP, SANS CWE Top 25, and CERT Secure Coding.
Application developers must be trained properly to identify and resolve issues related to common coding vulnerabilities. Having staff knowledgeable about secure software- development practices minimizes the number of security vulnerabilities accidentally introduced through poor coding practices. Training for developers may be provided in-house or by third parties and …
Added
p. 204
The policy document needs to explain the purpose, scope, roles and responsibilities, methods of access for different account types, configuration management, monitoring methodology, and controls to address known risks.
A.3.2.2 An up-to-date inventory of all system components in the environment is maintained.
• Examine system inventory.
Maintaining a current inventory of all system components enables an organization to accurately and efficiently apply security controls to protect the assets. The inventory should be periodically confirmed by either manual or automated process
•e.g., by correlation with the results of vulnerability scans or penetration testing
•to confirm it is up to date.
A.3.2.3 Configuration standards are defined and implemented for all system types.
• Examine system configuration standards and build procedures for all system component types.
• Examine system configuration standards and build procedures for all system component types.
A.3.2.2 An up-to-date inventory of all system components in the environment is maintained.
• Examine system inventory.
Maintaining a current inventory of all system components enables an organization to accurately and efficiently apply security controls to protect the assets. The inventory should be periodically confirmed by either manual or automated process
•e.g., by correlation with the results of vulnerability scans or penetration testing
•to confirm it is up to date.
A.3.2.3 Configuration standards are defined and implemented for all system types.
• Examine system configuration standards and build procedures for all system component types.
• Examine system configuration standards and build procedures for all system component types.
Added
p. 204
System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being deployed in the environment.
System configuration standards and related processes need to specifically address security settings and parameters that have known security implications for each type of system in use. Examples of industry-accepted configuration standards include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST) The implemented controls need to provide assurance that all systems in the environment have known secure configurations.
A.3.2.4 Configuration standards address all known security vulnerabilities and are based on industry-accepted system hardening standards.
A.3.2.5 Configuration standards and build procedures include:
• Changing all vendor-supplied default accounts and system settings.
• Removing or disabling all unnecessary system or application functionality.
• Preventing functions that require different security levels from co-existing on the …
System configuration standards and related processes need to specifically address security settings and parameters that have known security implications for each type of system in use. Examples of industry-accepted configuration standards include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST) The implemented controls need to provide assurance that all systems in the environment have known secure configurations.
A.3.2.4 Configuration standards address all known security vulnerabilities and are based on industry-accepted system hardening standards.
A.3.2.5 Configuration standards and build procedures include:
• Changing all vendor-supplied default accounts and system settings.
• Removing or disabling all unnecessary system or application functionality.
• Preventing functions that require different security levels from co-existing on the …
Added
p. 205
• Examine documented change-control procedures.
• Examine records of changes and compare to system configurations.
Defined change-control procedures must be followed for any change that impacts systems in the environment. The impact of the change needs to be documented so that all affected parties can plan appropriately for any processing changes. Changes must be authorized by appropriate parties, as defined by the change-management policy, to verify the change is legitimate.
Thorough testing is required to be performed to verify that the security of the environment is not reduced by implementing a change. Back-out procedures need to be documented in case the change fails or adversely affects the security of any system component.
A.3.3.2 All changes are authorized, and the security impact understood prior to implementing the change.
A.3.3.3 All changes are tested in a non- production environment.
A.3.3.4 Rollback procedures are prepared for all changes.
A.3.3.5 Unauthorized changes to system or application configurations are prevented and/or detected …
• Examine records of changes and compare to system configurations.
Defined change-control procedures must be followed for any change that impacts systems in the environment. The impact of the change needs to be documented so that all affected parties can plan appropriately for any processing changes. Changes must be authorized by appropriate parties, as defined by the change-management policy, to verify the change is legitimate.
Thorough testing is required to be performed to verify that the security of the environment is not reduced by implementing a change. Back-out procedures need to be documented in case the change fails or adversely affects the security of any system component.
A.3.3.2 All changes are authorized, and the security impact understood prior to implementing the change.
A.3.3.3 All changes are tested in a non- production environment.
A.3.3.4 Rollback procedures are prepared for all changes.
A.3.3.5 Unauthorized changes to system or application configurations are prevented and/or detected …
Added
p. 206
A.4.1 Protect against malicious software A.4.1.1 A security policy(s) and procedures for protecting systems against malware are maintained and implemented.
Controls must be implemented to help prevent the introduction and execution of malicious software (malware) on systems in the environment. A combination of methods, tools, and programs may be used•e.g., anti- malware software, application whitelisting, host-based and network-based intrusion-prevention tools, and system instrumentation. A combination of real-time protection and periodic scans should be considered.
The implemented controls must be kept current (e.g., updated signatures, baselines, etc.) as applicable for the technology. Anti-malware controls need to remain enabled unless disablement is specifically authorized by management on a case-by-case basis for a limited time period.
A.4.1.2 Controls to prevent and/or detect and remove malicious software are implemented, active, and maintained.
• Examine documented controls/configurations.
• Examine evidence of malware prevention and/or detection and removal.
Controls must be implemented to help prevent the introduction and execution of malicious software (malware) on systems in the environment. A combination of methods, tools, and programs may be used•e.g., anti- malware software, application whitelisting, host-based and network-based intrusion-prevention tools, and system instrumentation. A combination of real-time protection and periodic scans should be considered.
The implemented controls must be kept current (e.g., updated signatures, baselines, etc.) as applicable for the technology. Anti-malware controls need to remain enabled unless disablement is specifically authorized by management on a case-by-case basis for a limited time period.
A.4.1.2 Controls to prevent and/or detect and remove malicious software are implemented, active, and maintained.
• Examine documented controls/configurations.
• Examine evidence of malware prevention and/or detection and removal.
Added
p. 207
Policies and procedures define the methods used to identify and remediate vulnerabilities that could affect systems in the environment, and include:
• Monitoring vulnerability lists
• Performing vulnerability scans and penetration tests
• Establishing bug bounty programs Reputable outside sources should be used for security and vulnerability information.
A.4.2.2 Vulnerability scans, both internal and external, are performed at least quarterly to identify and address vulnerabilities.
• Examine vulnerability scanning reports
Vulnerability scans and all required remediation are to be completed as frequently as needed to ensure vulnerabilities are addressed in a timely manner. Rescans should be performed to verify vulnerabilities have been addressed. In addition to a regular scanning process, vulnerability scans need to be performed after any significant change to the environment.
A.4.2.3 Vulnerability scans are performed by qualified personnel:
• External scans are performed by a PCI SSC Approved Scanning Vendor (ASV).
• Internal scans are performed by qualified personnel.
• Examine vulnerability scanning reports.
Internal vulnerability scans can …
• Monitoring vulnerability lists
• Performing vulnerability scans and penetration tests
• Establishing bug bounty programs Reputable outside sources should be used for security and vulnerability information.
A.4.2.2 Vulnerability scans, both internal and external, are performed at least quarterly to identify and address vulnerabilities.
• Examine vulnerability scanning reports
Vulnerability scans and all required remediation are to be completed as frequently as needed to ensure vulnerabilities are addressed in a timely manner. Rescans should be performed to verify vulnerabilities have been addressed. In addition to a regular scanning process, vulnerability scans need to be performed after any significant change to the environment.
A.4.2.3 Vulnerability scans are performed by qualified personnel:
• External scans are performed by a PCI SSC Approved Scanning Vendor (ASV).
• Internal scans are performed by qualified personnel.
• Examine vulnerability scanning reports.
Internal vulnerability scans can …
Added
p. 208
• Examine penetration test reports.
• Examine penetration test reports.
Penetration tests must be performed at regular intervals and after significant changes to the environment. The penetration-testing methodology should be based on industry-accepted approaches and incorporate both application-layer and network-layer testing. The scope of testing needs to cover the perimeter and critical systems in the environment and include testing from both inside and outside the network. In addition, testing needs to be performed to verify that all segmentation controls are operational and effective, and that out-of-scope systems and networks do not have access to the environment. 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.
A.4.2.6 Penetration tests are performed by qualified personnel.
Penetration testing is to be performed only by qualified personnel who can demonstrate knowledge and experience, and who are organizationally independent of …
• Examine penetration test reports.
Penetration tests must be performed at regular intervals and after significant changes to the environment. The penetration-testing methodology should be based on industry-accepted approaches and incorporate both application-layer and network-layer testing. The scope of testing needs to cover the perimeter and critical systems in the environment and include testing from both inside and outside the network. In addition, testing needs to be performed to verify that all segmentation controls are operational and effective, and that out-of-scope systems and networks do not have access to the environment. 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.
A.4.2.6 Penetration tests are performed by qualified personnel.
Penetration testing is to be performed only by qualified personnel who can demonstrate knowledge and experience, and who are organizationally independent of …
Added
p. 209
• Examine results of penetration tests and vulnerability scanning reports.
• Examine evidence of remediation to address vulnerabilities and security issues.
Security patches and fixes must be implemented based on risk ranking. When high-risk vulnerabilities cannot be addressed within one month, a formal exception process needs to be followed, including approval by personnel with appropriate responsibility and accountability.
After remediation activities have been performed⎯e.g., implementing a patch or updating a configuration file to address a vulnerability or security flaw⎯rescans and penetration tests must be performed as necessary to verify the remediation is effective and that the identified vulnerability or security issue has been mitigated.
A record of remediation activities should be maintained⎯e.g., via change-control records, configuration file updates, and audit logs. All updates and patches must be managed in accordance with change- control processes. When applicable, changes to system configurations should be reflected in the configuration build standards.
A.5 Managing Access Security Requirements Test Requirements …
• Examine evidence of remediation to address vulnerabilities and security issues.
Security patches and fixes must be implemented based on risk ranking. When high-risk vulnerabilities cannot be addressed within one month, a formal exception process needs to be followed, including approval by personnel with appropriate responsibility and accountability.
After remediation activities have been performed⎯e.g., implementing a patch or updating a configuration file to address a vulnerability or security flaw⎯rescans and penetration tests must be performed as necessary to verify the remediation is effective and that the identified vulnerability or security issue has been mitigated.
A record of remediation activities should be maintained⎯e.g., via change-control records, configuration file updates, and audit logs. All updates and patches must be managed in accordance with change- control processes. When applicable, changes to system configurations should be reflected in the configuration build standards.
A.5 Managing Access Security Requirements Test Requirements …
Added
p. 210
• Examine defined roles and responsibilities.
Determining who has access to what, for how long, and what level of access they have needs to be based on established roles and responsibilities. This includes the processes used to maintain, monitor, and approve administrative and user access to systems and data.
A.5.1.3 Least privileges are assigned based on individual job function and periodically reviewed.
• Observe assigned access privileges.
• Examine evidence that access privileges are periodically reviewed.
Access to systems and data needs to be restricted based on business need, while also accounting for the sensitivity of the data being stored, processed, or transmitted. Access privileges must be reviewed by responsible personnel as defined by the entity. The frequency of reviews should be defined in accordance with the entity’s defined policies and be appropriate for the level of privilege assigned.
A.5.2 Account management A.5.2.1 A security policy(s) and procedures for managing accounts are maintained and implemented.
Established processes …
Determining who has access to what, for how long, and what level of access they have needs to be based on established roles and responsibilities. This includes the processes used to maintain, monitor, and approve administrative and user access to systems and data.
A.5.1.3 Least privileges are assigned based on individual job function and periodically reviewed.
• Observe assigned access privileges.
• Examine evidence that access privileges are periodically reviewed.
Access to systems and data needs to be restricted based on business need, while also accounting for the sensitivity of the data being stored, processed, or transmitted. Access privileges must be reviewed by responsible personnel as defined by the entity. The frequency of reviews should be defined in accordance with the entity’s defined policies and be appropriate for the level of privilege assigned.
A.5.2 Account management A.5.2.1 A security policy(s) and procedures for managing accounts are maintained and implemented.
Established processes …
Added
p. 211
Configuration and connection requirements must be defined and implemented for all access by third-party personnel. For example, ensuring accounts are enabled only during the time needed and disabled when not in use, and monitoring account activity when in use.
A.5.2.6 Access privileges are monitored and/or reviewed at least quarterly by an authorized individual to confirm access is still required.
• Examine evidence of monitoring and/or reviews.
All access privileges must be reviewed regularly, at least quarterly, by an authorized individual. Documentation of reviews needs to be retained. Results of these reviews need to include identification and removal of any unneeded or incorrect access, and to ensure that only individuals with a current business need are granted remote access.
Automated processes may be used to assist in reviewing access privileges⎯e.g., 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 …
A.5.2.6 Access privileges are monitored and/or reviewed at least quarterly by an authorized individual to confirm access is still required.
• Examine evidence of monitoring and/or reviews.
All access privileges must be reviewed regularly, at least quarterly, by an authorized individual. Documentation of reviews needs to be retained. Results of these reviews need to include identification and removal of any unneeded or incorrect access, and to ensure that only individuals with a current business need are granted remote access.
Automated processes may be used to assist in reviewing access privileges⎯e.g., 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 …
Added
p. 212
Multi-factor authentication (MFA) requires the completion of at least two different authentication methods (that is, something you know, something you have, and something you are) prior to access being granted. The authentication mechanisms used need to 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 can 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 secure network or network segment, or when connecting to an individual system component in the environment.
MFA is required …
• 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 can 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 secure network or network segment, or when connecting to an individual system component in the environment.
MFA is required …
Added
p. 213
A.6.1 Restrict physical access A.6.1.1 A security policy(s) and procedures for securing physical access to systems is maintained and implemented.
The entity needs to define the physical access controls required to prevent systems from being accessed physically by unauthorized persons. The controls need to cover all physical access points and include procedures for managing onsite employees and third parties. Specific procedures are required for managing visitors, including a visible means for identification and escorts by authorized personnel.
Physical access and monitoring controls need to include use of video cameras and/or access-control mechanisms. Data from video cameras and/or access-control mechanisms needs to be logged to provide an audit trail of all physical access to the environment. Access logs must be retained in accordance with the entity’s audit log policy. (Refer to Requirement A.7.2.) Monitoring and periodic reviews of physical access controls and audit logs need to be performed to allow early identification of …
The entity needs to define the physical access controls required to prevent systems from being accessed physically by unauthorized persons. The controls need to cover all physical access points and include procedures for managing onsite employees and third parties. Specific procedures are required for managing visitors, including a visible means for identification and escorts by authorized personnel.
Physical access and monitoring controls need to include use of video cameras and/or access-control mechanisms. Data from video cameras and/or access-control mechanisms needs to be logged to provide an audit trail of all physical access to the environment. Access logs must be retained in accordance with the entity’s audit log policy. (Refer to Requirement A.7.2.) Monitoring and periodic reviews of physical access controls and audit logs need to be performed to allow early identification of …
Added
p. 214
Controls and processes need to cover secure storage, transport, and disposal of all storage media used in the environment. Procedures and technical controls are needed to provide assurance that media cannot be removed, stolen, or copied by unauthorized persons. The specific controls and level of rigor required to protect media must be appropriate for the sensitivity of the data stored on the media.
A.7 Incident Response Preparedness Security Requirements Test Requirements Guidance Control Objective: An effective incident-response plan allows an entity to respond to potential security issues quickly and effectively and minimize the potential impact of a security incident or breach.
A.7.1 Incident-response plan A.7.1.1 A security policy(s) and procedures for managing and responding to security incidents is maintained and implemented.
The policy needs to define plans, procedures, and technologies to detect, analyze, and promptly respond to security incidents. Defined procedures need to include response activities, escalation, and notification, and cover all assets …
A.7 Incident Response Preparedness Security Requirements Test Requirements Guidance Control Objective: An effective incident-response plan allows an entity to respond to potential security issues quickly and effectively and minimize the potential impact of a security incident or breach.
A.7.1 Incident-response plan A.7.1.1 A security policy(s) and procedures for managing and responding to security incidents is maintained and implemented.
The policy needs to define plans, procedures, and technologies to detect, analyze, and promptly respond to security incidents. Defined procedures need to include response activities, escalation, and notification, and cover all assets …
Added
p. 215
• Roles and responsibilities
• Communication and contact strategies
• Specific incident response procedures
• 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
• Examine documented incident-response plans and procedures.
The incident-response plan needs to be comprehensive and include coverage of all systems in the environment.
At a minimum, communication and contact strategies need to include notification of the payment brands.
Incident response personnel/teams must be trained and knowledgeable in incident-response procedures and be available to respond immediately to an incident.
A.7.1.3 The plan is reviewed and tested at least annually.
• Examine evidence of reviews and testing.
The incident-response plan needs to be reviewed, tested, and updated periodically to incorporate lessons learned. Relevant staff must be included in the testing and be briefed on the post-test review. Testing needs to include validation that system, audit, and monitoring logs …
• Communication and contact strategies
• Specific incident response procedures
• 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
• Examine documented incident-response plans and procedures.
The incident-response plan needs to be comprehensive and include coverage of all systems in the environment.
At a minimum, communication and contact strategies need to include notification of the payment brands.
Incident response personnel/teams must be trained and knowledgeable in incident-response procedures and be available to respond immediately to an incident.
A.7.1.3 The plan is reviewed and tested at least annually.
• Examine evidence of reviews and testing.
The incident-response plan needs to be reviewed, tested, and updated periodically to incorporate lessons learned. Relevant staff must be included in the testing and be briefed on the post-test review. Testing needs to include validation that system, audit, and monitoring logs …
Added
p. 216
• Link all access to systems to an individual user.
• Record security events.
• Observe access attempts.
• Examine audit log files.
Recording all personnel access, both physical and logical, to systems in the environment is required to help the entity identify any misuse of accounts and ensure that each individual is accountable for their actions.
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 needs to include notifications or alerts related to suspicious or anomalous activities⎯e.g., as defined in Requirements A.2.2.2 and A.3.3.5. The level of detail logged is required to be sufficient to identify who, what, where, when, and how an event occurred in the environment.
A.7.2.3 Time synchronization is implemented on systems to ensure system clocks are synchronized and have the correct and consistent time.
• Examine system configurations. Designated central time server(s) …
• Record security events.
• Observe access attempts.
• Examine audit log files.
Recording all personnel access, both physical and logical, to systems in the environment is required to help the entity identify any misuse of accounts and ensure that each individual is accountable for their actions.
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 needs to include notifications or alerts related to suspicious or anomalous activities⎯e.g., as defined in Requirements A.2.2.2 and A.3.3.5. The level of detail logged is required to be sufficient to identify who, what, where, when, and how an event occurred in the environment.
A.7.2.3 Time synchronization is implemented on systems to ensure system clocks are synchronized and have the correct and consistent time.
• Examine system configurations. Designated central time server(s) …
Added
p. 217
• Examine controls/configurations.
• Observe attempts to modify audit logs Only individuals who have a job-related need should be able to view audit log files. Audit logs should be backed up promptly to a centralized log server or media that is difficult to alter. Physical and logical access controls must 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 generate an alert.
A.7.2.6 Audit and monitoring logs are retained for least one year, with a minimum of three months immediately available for analysis.
Log-retention policies need to include storage and retrieval procedures. If stored in off-line locations, procedures need to include assurance that log data can be retrieved in a timely manner. The logs to be retained include at least those defined in Requirement A.7.2.2.
• Observe attempts to modify audit logs Only individuals who have a job-related need should be able to view audit log files. Audit logs should be backed up promptly to a centralized log server or media that is difficult to alter. Physical and logical access controls must 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 generate an alert.
A.7.2.6 Audit and monitoring logs are retained for least one year, with a minimum of three months immediately available for analysis.
Log-retention policies need to include storage and retrieval procedures. If stored in off-line locations, procedures need to include assurance that log data can be retrieved in a timely manner. The logs to be retained include at least those defined in Requirement A.7.2.2.
Added
p. 218
It starts with the description of differences between hardware- and software-based tamper-responsive systems, followed by guidelines that must be considered for an attack cost calculation framework. The considerations include the importance of the attack scalability factor as well as its definition, remediation and pre-remediation solutions, and their role and construction of a full attack path. The full attack path rating is constructed based on the tests conducted during the evaluation as per testing requirements.
The rating process is described by listing the steps that the laboratory performs when rating a full attack based on the information collected by partial attack tests and documentation analysis.
The relevant factors that this costing framework considers include attack time, attacker expertise, scalability, knowledge of A&M back-end systems, equipment required for the attack, and COTS device access. The detailed description of all the factors is followed by a discussion about ratings, with examples that show the importance …
The rating process is described by listing the steps that the laboratory performs when rating a full attack based on the information collected by partial attack tests and documentation analysis.
The relevant factors that this costing framework considers include attack time, attacker expertise, scalability, knowledge of A&M back-end systems, equipment required for the attack, and COTS device access. The detailed description of all the factors is followed by a discussion about ratings, with examples that show the importance …
Added
p. 219
4. Use of COTS and attack stages: The use of numerous supporting technologies in a layered security architecture leads to a full attack necessarily consisting of several stages. The following stages are considered: a. Gaining control of the COTS device (rooting). Gaining control of the platform either by using an OEM supported method or based on existing exploits is often the first stage of an attack. While it is often the first stage, it could be that the MPoC Application itself has an exploitable vulnerability and that full control of the COTS is not needed for the full attack path. Prevention of remote attacks on platforms includes regularly updating the COTS OS. b. Gaining control of the MPoC Application. Even for a COTS device under full attacker control, several security mechanisms have to be circumvented to gain control of the MPoC Application. Gaining control of the MPoC Application is usually …
Added
p. 220
• Identification and exploitation stages
• Scalability rating factor
• Remediation and pre-remediation
• Partial and full attacks Identification and Exploitation Stages For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course, factors such as time need to be treated differently in these cases, and therefore the “cost” required to identify an exploit is included in the costing calculation.
Exploitation involves the actual performance of an attack (partial or full) on a live system.
Scalability Rating Factor This factor addresses the attack potential that affects large groups of merchants that …
• Scalability rating factor
• Remediation and pre-remediation
• Partial and full attacks Identification and Exploitation Stages For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a trivial separation, but it is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, and a simple attack method published on the Internet. Compare this to a vulnerability that is well known but requires enormous expenditure of time and resources to exploit. Of course, factors such as time need to be treated differently in these cases, and therefore the “cost” required to identify an exploit is included in the costing calculation.
Exploitation involves the actual performance of an attack (partial or full) on a live system.
Scalability Rating Factor This factor addresses the attack potential that affects large groups of merchants that …
Added
p. 221
In case of pre-remediation, the product is updated on a regular basis to implement proactive mitigations against known attack paths, or so that the learning curve for the execution of an attack is reset at every update•thereby necessitating a new identification phase for any known attacks. Pre-remediation may resolve the attack attempts that cannot be detected by A&M back-end systems or prevent those attacks that are already known.
Remediation and pre-remediation are not rated, but they determine whether a partial attack is feasible. If an attack requires more time than the pre-remediation cycle takes, or if the attack can be detected and mitigated before the fraud is performed, the partial attack is not considered when constructing the full attack.
Approach to Attack Calculations Where the MPoC standard requires a costing be provided as evidence for a testing requirement, the costing is to be provided for the specific asset or context of the …
Remediation and pre-remediation are not rated, but they determine whether a partial attack is feasible. If an attack requires more time than the pre-remediation cycle takes, or if the attack can be detected and mitigated before the fraud is performed, the partial attack is not considered when constructing the full attack.
Approach to Attack Calculations Where the MPoC standard requires a costing be provided as evidence for a testing requirement, the costing is to be provided for the specific asset or context of the …
Added
p. 224
The relevant factors for attack rating are shown in the following table.
Table 6: Attack Rating Table Attack Factor Identification Exploitation Attack time Attacker Expertise Scalability Knowledge back-end systems COTS device access As shown in Figure 5, partial attacks factors are assessed after the tester performs relevant tests. Partial attacks are analyzed, and the tester determines whether a composition could lead to a full attack. For a possible full attack, the laboratory will calculate the rating based on the factors determined for all partial attacks with the following approach:
• Attack time: The time taken for that stage of the attack (identification or exploitation) to be completed.
• Attacker Expertise: The partial attack with the highest expertise determines the expertise of the full attack. The full attack would not be possible without all the partial attacks and expertise needed for them.
• Knowledge back-end systems: If the knowledge of the back-end systems is needed …
Table 6: Attack Rating Table Attack Factor Identification Exploitation Attack time Attacker Expertise Scalability Knowledge back-end systems COTS device access As shown in Figure 5, partial attacks factors are assessed after the tester performs relevant tests. Partial attacks are analyzed, and the tester determines whether a composition could lead to a full attack. For a possible full attack, the laboratory will calculate the rating based on the factors determined for all partial attacks with the following approach:
• Attack time: The time taken for that stage of the attack (identification or exploitation) to be completed.
• Attacker Expertise: The partial attack with the highest expertise determines the expertise of the full attack. The full attack would not be possible without all the partial attacks and expertise needed for them.
• Knowledge back-end systems: If the knowledge of the back-end systems is needed …
Added
p. 227
• Instance specific: The attack is not scalable and needs to be heavily customized for each COTS device (e.g., the attack depends on the extraction of keys from each COTS device, and that extraction process must be performed as a bespoke process for each COTS device attacked).
• Scalable with physical access: The attack can be leveraged against multiple COTS Platforms and/or MPoC Application instances but requires that the attacker has physical access to the COTS device during the attack. Consideration for if locked or unlocked access is necessary is calculated in the “access” part of the costing.
• Remotely scalable: The attack may be leveraged against multiple COTS Platforms and/or MPoC Application instances and does not require the attacker to have any physical access to the COTS device during the attack. Scalability of the attack is of a very high importance for the MPoC; therefore, it has a high number of …
• Scalable with physical access: The attack can be leveraged against multiple COTS Platforms and/or MPoC Application instances but requires that the attacker has physical access to the COTS device during the attack. Consideration for if locked or unlocked access is necessary is calculated in the “access” part of the costing.
• Remotely scalable: The attack may be leveraged against multiple COTS Platforms and/or MPoC Application instances and does not require the attacker to have any physical access to the COTS device during the attack. Scalability of the attack is of a very high importance for the MPoC; therefore, it has a high number of …
Added
p. 228
Knowledge of A&M Identification Exploitation Public information 0 0 Restricted information 1 1 Sensitive information 3 4
• Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.
• Restricted information concerning the back-end monitoring system (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered.
• Sensitive information about the back-end monitoring system
•e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse-engineering.
• Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer.
• Restricted information concerning the back-end monitoring system (e.g., as gained from vendor technical specifications): Information is considered restricted if it is distributed on request and the distribution is registered.
• Sensitive information about the back-end monitoring system
•e.g., knowledge of internal design, which may have to be obtained by “social engineering” or exhaustive reverse-engineering.
Added
p. 229
• Standard SW/only includes pre-existing tools which can be easily obtained, such as Frida, Magisk, or jail-breaking scripts and procedures.
• Specialized equipment includes special software that is not readily available and has to be created.
Equipment Identification Exploitation Standard SW/only 0 0 Specialized 3 3 The COTS device security, including the acceptability of any hardware used in the MPoC Solution, is the responsibility of the MPoC Solution provider and their risk management system. Hardware-based security relies on the fact that such solutions have passed high assurance security assessments. The risk management system as well as methods used to determine the acceptability of any hardware security level is assessed by the MPoC laboratory with the documentation assessment based on the relevant security certification as listed in the requirements of this document. Therefore, hardware attacks themselves and hardware equipment used for such attacks are out of scope of this rating system.
COTS Device Access …
• Specialized equipment includes special software that is not readily available and has to be created.
Equipment Identification Exploitation Standard SW/only 0 0 Specialized 3 3 The COTS device security, including the acceptability of any hardware used in the MPoC Solution, is the responsibility of the MPoC Solution provider and their risk management system. Hardware-based security relies on the fact that such solutions have passed high assurance security assessments. The risk management system as well as methods used to determine the acceptability of any hardware security level is assessed by the MPoC laboratory with the documentation assessment based on the relevant security certification as listed in the requirements of this document. Therefore, hardware attacks themselves and hardware equipment used for such attacks are out of scope of this rating system.
COTS Device Access …
Added
p. 230
Three types of access are identified:
• Where no physical access is required.
• Where physical access is required, but the device may be in a locked state.
• Where physical access with the device in an unlocked state is required.
Access Identification Exploitation Remote 0 0 Local locked 0 2 Local unlocked 0 3 Attacks that are marked as “scalable with physical access” will always require local access in the costing as well.
• Where no physical access is required.
• Where physical access is required, but the device may be in a locked state.
• Where physical access with the device in an unlocked state is required.
Access Identification Exploitation Remote 0 0 Local locked 0 2 Local unlocked 0 3 Attacks that are marked as “scalable with physical access” will always require local access in the costing as well.
Added
p. 232
The examples provided include the following types of MPoC Solutions:
• A relatively weak MPoC Solution with a scalable attack and one that prevents a scalable attack.
• A relatively strong MPoC Solution with a scalable attack and non-scalable attack.
• An MPoC Solution where there is the ability to use legitimate functionality provided by the COTS OS to expose account data, in both remote and non-remote attack modes.
• A relatively weak MPoC Solution with a scalable attack and one that prevents a scalable attack.
• A relatively strong MPoC Solution with a scalable attack and non-scalable attack.
• An MPoC Solution where there is the ability to use legitimate functionality provided by the COTS OS to expose account data, in both remote and non-remote attack modes.
Added
p. 233
• Weak attestation functions (bypass possible).
• Lack of obfuscation.
• Successful dynamic binary instrumentation (requiring rooted COTS device), which leads to payment assets disclosure.
• Available remote exploit for several approved platforms as well as possibility for merchant and merchant employee to root the COTS device without being detected by the back-end.
The relevant parameters of this attack if it were scalable are:
• Lack of obfuscation.
• Successful dynamic binary instrumentation (requiring rooted COTS device), which leads to payment assets disclosure.
• Available remote exploit for several approved platforms as well as possibility for merchant and merchant employee to root the COTS device without being detected by the back-end.
The relevant parameters of this attack if it were scalable are:
Added
p. 235
• It takes an expert 2-3 weeks or more to reverse engineer the solution and circumvent the runtime security mechanisms.
• Obfuscation is very good.
• Rooting is not detected (or rooting detections can be easily circumvented).
The relevant parameters of this attack (for a scalable solution) are:
• Obfuscation is very good.
• Rooting is not detected (or rooting detections can be easily circumvented).
The relevant parameters of this attack (for a scalable solution) are:
Added
p. 236
Attack Factor Identification Exploitation Attack time < 1 month 5 < 1 day 2 Attacker Expertise Expert 4 Proficient 3 Scalability N/A 0 Instance specific 12 Knowledge back-end systems Public information 0 Public information 0 Equipment Specialized 3 Standard 0 COTS device access Local unlocked 0 Remote 0 Sub total 12 17 Use and Abuse of Legitimate Functionality Provided by OS Different attacks exist that use legitimate functionality provided by the OS to gain access to MPoC assets. Examples of such attacks include TeaBot, Cloak, or Dagger using an overlay function as well as accessibility services or developer controls. This example including rating indicates how laboratories should approach such risks during the evaluation.
An example of an abuse of legitimate functionality attack has the following evaluation results:
• Merchant security-guidance documents (user guidance) do not prevent merchant, employees, or attackers from installing a malicious application to monitor touch events, turn on developer …
An example of an abuse of legitimate functionality attack has the following evaluation results:
• Merchant security-guidance documents (user guidance) do not prevent merchant, employees, or attackers from installing a malicious application to monitor touch events, turn on developer …
Added
p. 238
Attack Factor Identification Exploitation Attack time < 1 month 5 < 1 day 2 Attacker Expertise Proficient 3 Layman 0 Scalability N/A 0 Scalable with physical access 6 Knowledge back-end systems Public information 0 Public information 0 Equipment Standard 0 Standard 0 COTS device access Local unlocked 0 Local unlocked 3 Sub total 8 11 If instead the attack requires more advanced expertise and tooling to expose, and more skill to perform on each device (but still with local unlocked access), the costing would instead be:
Added
p. 239
Example of Attack on a Platform: Full Attack − Remote Attack on Platform
Note: The attack activities are out of scope for testing activities within MPoC evaluation process.
The first example describes the attack on the platform that cannot be identified during the MPoC Application assessment by the laboratory. Nevertheless, this attack is included to provide insight into the effort needed for such attacks and show the rating approach. The risk of the remote attacks on the platform should be addressed by the MPoC Solution provider process that manages risks.
The full attack described here could lead to payment assets disclosure by gaining full control of the platform and assuming the MPoC Application is weak and trusts the COTS platform. The attack is based on the real-world attack presented by Samuel Groß (@5aelo), Project Zero in Full remote attack based on No Clicks Required - Exploiting Memory Corruption Vulnerabilities in Messenger Apps.
This attack …
Note: The attack activities are out of scope for testing activities within MPoC evaluation process.
The first example describes the attack on the platform that cannot be identified during the MPoC Application assessment by the laboratory. Nevertheless, this attack is included to provide insight into the effort needed for such attacks and show the rating approach. The risk of the remote attacks on the platform should be addressed by the MPoC Solution provider process that manages risks.
The full attack described here could lead to payment assets disclosure by gaining full control of the platform and assuming the MPoC Application is weak and trusts the COTS platform. The attack is based on the real-world attack presented by Samuel Groß (@5aelo), Project Zero in Full remote attack based on No Clicks Required - Exploiting Memory Corruption Vulnerabilities in Messenger Apps.
This attack …
Added
p. 241
Example: Full Attack − Perform Fake Payments This attack describes what is required to perform faked payments for a specific MPoC Application with several security measures that have been shown to provide limited resistance during laboratory testing.
Attack description. An attacker with MPoC Application control can modify the MPoC Application to simulate payments when the attacker card is detected. The attacker can acquire goods at the attacked merchant and the screen of the COTS device being used will behave normally, displaying the expected information on the screen; however, it will not send the payment to the back-end. A merchant with enough transactions per day will probably identify the theft as shoplifting, as it leaves no trace in the system.
The steps of the attack are:
1. Rooting the COTS device. Older Android versions can run the MPoC Application based on the policy of the MPoC Solution.
Therefore, the rooting of a COTS device can …
Attack description. An attacker with MPoC Application control can modify the MPoC Application to simulate payments when the attacker card is detected. The attacker can acquire goods at the attacked merchant and the screen of the COTS device being used will behave normally, displaying the expected information on the screen; however, it will not send the payment to the back-end. A merchant with enough transactions per day will probably identify the theft as shoplifting, as it leaves no trace in the system.
The steps of the attack are:
1. Rooting the COTS device. Older Android versions can run the MPoC Application based on the policy of the MPoC Solution.
Therefore, the rooting of a COTS device can …
Added
p. 241
• COTS device access: local locked
2. Running an MPoC Application on a rooted COTS device. It is possible to run the MPoC Application on a rooted COTS device as anti-instrumentation. Anti-debugging can be circumvented due to the following weakness found during the evaluation: a. Circumventing runtime protection. It was identified that runtime protection is limited to some parts of the code, leaving the possibility for the attacker to modify the unprotected code flow relevant for this attack. b. Sensitive information is logged. The current state of the execution flow of the MPoC Application reveals information such as messages from security components and the current state of the execution flow. This information can aid in attacking the MPoC Application flow.
The relevant parameters of this partial attack are:
• COTS device access: local locked
2. Running an MPoC Application on a rooted COTS device. It is possible to run the MPoC Application on a rooted COTS device as anti-instrumentation. Anti-debugging can be circumvented due to the following weakness found during the evaluation: a. Circumventing runtime protection. It was identified that runtime protection is limited to some parts of the code, leaving the possibility for the attacker to modify the unprotected code flow relevant for this attack. b. Sensitive information is logged. The current state of the execution flow of the MPoC Application reveals information such as messages from security components and the current state of the execution flow. This information can aid in attacking the MPoC Application flow.
The relevant parameters of this partial attack are:
• COTS device access: local locked
Added
p. 242
• Elapsed time: <1 week
• Attacker Expertise: Proficient
3. Developing exploit. Because the obfuscation and run-time integrity are found to be weak during the evaluation, the development of an exploit that modifies the code flow could be performed.
Circumventing the obfuscation and developing the exploit would require the following parameters:
• Elapsed time: >1 week
• Attacker Expertise: Expert
• COTS device access: local locked Therefore, the full attack would have the following rating:
• The elapsed time for identification is accumulated for all the steps resulting in the attack time below a month.
• The elapsed time for exploitation considers only the activities that must be repeated for other COTS devices with the same platform <1 day.
• For all other categories, the highest necessary rating is considered because it is the minimum for the full attack to be completed. For example, if one partial attack requires expert while the rest of the partial attacks require only …
• Attacker Expertise: Proficient
3. Developing exploit. Because the obfuscation and run-time integrity are found to be weak during the evaluation, the development of an exploit that modifies the code flow could be performed.
Circumventing the obfuscation and developing the exploit would require the following parameters:
• Elapsed time: >1 week
• Attacker Expertise: Expert
• COTS device access: local locked Therefore, the full attack would have the following rating:
• The elapsed time for identification is accumulated for all the steps resulting in the attack time below a month.
• The elapsed time for exploitation considers only the activities that must be repeated for other COTS devices with the same platform <1 day.
• For all other categories, the highest necessary rating is considered because it is the minimum for the full attack to be completed. For example, if one partial attack requires expert while the rest of the partial attacks require only …
Added
p. 244
Table 7 lists the minimum key sizes and parameters for the algorithms used with key transport, exchange, or establishment and for data protection in connection with these requirements. Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC3-based key agreement), NIST SP800-56B (IFC-based key agreement) and NIST SP800-38F (AES-based key encryption/wrapping).
Other key sizes and algorithms may be supported for non-payment brand relevant transactions; otherwise, these are the only encryption algorithms designated as Approved Algorithms.
Table 7: Minimum Key Size Algorithm IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits 2048 224 2048/224 128 Equivalent Key Sizes Key-encipherment keys are to be at least of equal or greater strength than any key they protect, except where explicitly allowed in this standard. This applies to any key-encipherment keys used to protect secret or private keys that are stored, keys used to encrypt any secret, …
Other key sizes and algorithms may be supported for non-payment brand relevant transactions; otherwise, these are the only encryption algorithms designated as Approved Algorithms.
Table 7: Minimum Key Size Algorithm IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits 2048 224 2048/224 128 Equivalent Key Sizes Key-encipherment keys are to be at least of equal or greater strength than any key they protect, except where explicitly allowed in this standard. This applies to any key-encipherment keys used to protect secret or private keys that are stored, keys used to encrypt any secret, …
Added
p. 245
Table 8: Equivalent Key Sizes Algorithm Effective Bit IFC (RSA) ECC (ECDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES Minimum key size in number of bits 112 2048 224 2048/224
• Minimum key size in number of bits 128 3072 256 3072/256 128 Minimum key size in number of bits 192 7680 384 7680/384 192 Minimum key size in number of bits 256 15360 512 15360/512 256 For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
• DH implementations entities must generate and distribute the system-wide parameters securely: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).
• ECDH implementations entities must securely generate and distribute …
• Minimum key size in number of bits 128 3072 256 3072/256 128 Minimum key size in number of bits 192 7680 384 7680/384 192 Minimum key size in number of bits 256 15360 512 15360/512 256 For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):
• DH implementations entities must generate and distribute the system-wide parameters securely: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long and parameter q must be at least 224 bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, q, g).
• ECDH implementations entities must securely generate and distribute …
Added
p. 246
Table 9: Hash Algorithms Algorithm Length SHA2 family >255 SHA3 family >255 RNGs are either a deterministic random number generator or a Non-deterministic Random Number Generator (NRNG).
Random Number Generators All DRNG must be seeded by an NRNG that provides sufficient authenticated entropy. The entropy required must be at least as many bits as the intended key strength and should be twice as many bits. Entropy sources are discussed in NIST SP800-90B.
Table 10: Random Number Generators RNG Requirement DRNG Tested and approved under NIST SP 800-90A or ISO/IEC 18031 [§9] NRNG Tested and approved under NIST SP 800-90C or ISO/IEC 18031 [§8] Prime Number Generators For cryptographic processes that require prime numbers, use prime number generators tested to ISO/IEC 18032 Information Technology-- Security Techniques: Prime Number Generation or X9.80 Prime Number Generation, Primality Testing, and Primality Certificates.
Random Number Generators All DRNG must be seeded by an NRNG that provides sufficient authenticated entropy. The entropy required must be at least as many bits as the intended key strength and should be twice as many bits. Entropy sources are discussed in NIST SP800-90B.
Table 10: Random Number Generators RNG Requirement DRNG Tested and approved under NIST SP 800-90A or ISO/IEC 18031 [§9] NRNG Tested and approved under NIST SP 800-90C or ISO/IEC 18031 [§8] Prime Number Generators For cryptographic processes that require prime numbers, use prime number generators tested to ISO/IEC 18032 Information Technology-- Security Techniques: Prime Number Generation or X9.80 Prime Number Generation, Primality Testing, and Primality Certificates.
Added
p. 247
• Evaluation per Appendix D by an approved MPoC Laboratory as part of its evaluation, or
• Through an independent assessment of software lifecycle management practices assessed by a Secure SLC Assessment performed by a Secure SLC Assessor (listed on the PCI SSC website) and confirmed by submitting a Secure SLC ROC and Secure SLC AOC.
Leveraging PCI Secure SLC Standard for Appendix D Security Requirements The SSF Secure SLC Standard defines security requirements for payment-software vendors to integrate security throughout the entire software lifecycle, resulting in software that is secure by design and better able to withstand attacks. Software vendors whose development processes have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.
It is possible to validate compliance to the security requirements in this appendix by confirming that the following are met:
• The software lifecycle management practices were assessed …
• Through an independent assessment of software lifecycle management practices assessed by a Secure SLC Assessment performed by a Secure SLC Assessor (listed on the PCI SSC website) and confirmed by submitting a Secure SLC ROC and Secure SLC AOC.
Leveraging PCI Secure SLC Standard for Appendix D Security Requirements The SSF Secure SLC Standard defines security requirements for payment-software vendors to integrate security throughout the entire software lifecycle, resulting in software that is secure by design and better able to withstand attacks. Software vendors whose development processes have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.
It is possible to validate compliance to the security requirements in this appendix by confirming that the following are met:
• The software lifecycle management practices were assessed …
Added
p. 248
Security Requirements Test Requirements Guidance D.1.1 Security Responsibility and Resources Senior leadership team establishes formal responsibility and authority for the security of the vendor’s products and services, and resources are allocated to execute the strategy and ensure that personnel are appropriately skilled D.1.1.1 Overall responsibility for the security of the vendor’s products and services is assigned by the vendor’s senior leadership team.
D.1.1.1.a Examine vendor evidence and interview the individual or individuals assigned overall responsibility for the security of the vendor’s products and services to confirm the following:
• Accountability for ensuring the security of the vendor’s products and services is formally assigned to an individual or team by the vendor’s senior leadership.
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the vendor’s products and services.
• Updates are provided to senior leadership at least annually on the performance of and changes to …
D.1.1.1.a Examine vendor evidence and interview the individual or individuals assigned overall responsibility for the security of the vendor’s products and services to confirm the following:
• Accountability for ensuring the security of the vendor’s products and services is formally assigned to an individual or team by the vendor’s senior leadership.
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the vendor’s products and services.
• Updates are provided to senior leadership at least annually on the performance of and changes to …
Added
p. 249
D.1.1.2 Software security responsibilities are assigned.
Added
p. 249
• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software-development personnel.
• Assignment of responsibilities for ensuring the security of the vendor’s products and services covers the entire software lifecycle.
Individuals, including third-party personnel, involved in the design, development, testing, and maintenance of the vendor’s products and services should be assigned responsibility and accountability for ensuring that software is designed and maintained in accordance with the vendor’s security strategy and all applicable security requirements, including software-specific requirements. Responsibilities can be assigned to an individual, group, or role; however, individuals assigned to a particular group or role should clearly understand how those software security responsibilities affect their individual job functions, the organization’s security expectations, and the individual’s role in fulfilling those expectations. Individuals assigned software-security responsibilities should be able to demonstrate an understanding of their responsibilities and accountability.
Evidence to support this security objective might include job descriptions, …
• Assignment of responsibilities for ensuring the security of the vendor’s products and services covers the entire software lifecycle.
Individuals, including third-party personnel, involved in the design, development, testing, and maintenance of the vendor’s products and services should be assigned responsibility and accountability for ensuring that software is designed and maintained in accordance with the vendor’s security strategy and all applicable security requirements, including software-specific requirements. Responsibilities can be assigned to an individual, group, or role; however, individuals assigned to a particular group or role should clearly understand how those software security responsibilities affect their individual job functions, the organization’s security expectations, and the individual’s role in fulfilling those expectations. Individuals assigned software-security responsibilities should be able to demonstrate an understanding of their responsibilities and accountability.
Evidence to support this security objective might include job descriptions, …
Added
p. 250
• A mature process is implemented and maintained for managing and maintaining software security skills for software-development personnel.
• The skills required for each defined role, responsibility, and job function are clearly defined.
• The criteria for maintaining individual skills are clearly defined.
• The process includes a review at least annually to ensure software-development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
To be effective in meeting their software security responsibilities, software-development personnel must be trained or have experience in performing such responsibilities and must maintain the appropriate skills to properly carry out those responsibilities.
At a minimum, all software-development personnel must have a basic understanding of general software security concepts and best practices. Individuals with specialized roles and responsibilities should additionally possess specialized skills relevant to the functions they perform. Examples of specialized skills include secure software design (software architects), secure coding techniques (software developers), and security-testing …
• The skills required for each defined role, responsibility, and job function are clearly defined.
• The criteria for maintaining individual skills are clearly defined.
• The process includes a review at least annually to ensure software-development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
To be effective in meeting their software security responsibilities, software-development personnel must be trained or have experience in performing such responsibilities and must maintain the appropriate skills to properly carry out those responsibilities.
At a minimum, all software-development personnel must have a basic understanding of general software security concepts and best practices. Individuals with specialized roles and responsibilities should additionally possess specialized skills relevant to the functions they perform. Examples of specialized skills include secure software design (software architects), secure coding techniques (software developers), and security-testing …
Added
p. 251
D.1.2.1 Examine vendor evidence and interview personnel to confirm the following:
• A mature process exists to identify and monitor external regulatory and industry security and compliance requirements.
• The process includes reviewing sources of regulatory and industry security and compliance requirements for changes at least annually.
• The process results in an inventory of external regulatory and industry security and compliance requirements.
• The inventory is updated as external security and compliance requirements change.
Many organizations are subject to requirements for protecting certain types of information and data such as personally identifiable information (PII), cardholder data (CHD), and protected health information (PHI).
Vendors should maintain awareness of evolving industry and regulatory requirements applicable to their operations and products. Maintaining ongoing awareness of external security and compliance obligations allows the vendor to ensure its processes adequately address those requirements at all times, including whenever those requirements are updated, or new requirements introduced.
Evidence to support this control …
• A mature process exists to identify and monitor external regulatory and industry security and compliance requirements.
• The process includes reviewing sources of regulatory and industry security and compliance requirements for changes at least annually.
• The process results in an inventory of external regulatory and industry security and compliance requirements.
• The inventory is updated as external security and compliance requirements change.
Many organizations are subject to requirements for protecting certain types of information and data such as personally identifiable information (PII), cardholder data (CHD), and protected health information (PHI).
Vendors should maintain awareness of evolving industry and regulatory requirements applicable to their operations and products. Maintaining ongoing awareness of external security and compliance obligations allows the vendor to ensure its processes adequately address those requirements at all times, including whenever those requirements are updated, or new requirements introduced.
Evidence to support this control …
Added
p. 252
D.1.2.3.a Examine vendor evidence and interview responsible personnel to confirm the following:
• A strategy to ensure the security of the vendor’s products and services is defined.
• The software-security strategy clearly outlines how the software security policy is to be satisfied.
• The software-security strategy is based on or aligned with industry-accepted methodologies.
• The software-security strategy covers the entire lifecycle of the vendor’s products and services.
• The software-security strategy is communicated to appropriate personnel, including software- development personnel.
• The software-security strategy is reviewed at least annually and updated as needed, such as when business needs, external drivers, and products and services evolve.
A software-security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the vendor’s products and services, and adherence to the vendor’s software- security policy.
Vendors should either adopt existing frameworks or methodologies or develop their own in accordance with industry-accepted practices for secure software …
• A strategy to ensure the security of the vendor’s products and services is defined.
• The software-security strategy clearly outlines how the software security policy is to be satisfied.
• The software-security strategy is based on or aligned with industry-accepted methodologies.
• The software-security strategy covers the entire lifecycle of the vendor’s products and services.
• The software-security strategy is communicated to appropriate personnel, including software- development personnel.
• The software-security strategy is reviewed at least annually and updated as needed, such as when business needs, external drivers, and products and services evolve.
A software-security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the vendor’s products and services, and adherence to the vendor’s software- security policy.
Vendors should either adopt existing frameworks or methodologies or develop their own in accordance with industry-accepted practices for secure software …
Added
p. 254
Note: The focus is on the overall management of security-assurance processes and provides the foundation for specific assurance processes defined within this document.
Added
p. 254
• Software security-assurance processes are defined, implemented, and maintained.
• An inventory of software security-assurance processes is maintained.
Software security-assurance processes are activities that are implemented to carry out the vendor’s software- security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the vendor’s products and services are secure and resistant to attack, vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software-development process where software is checked to make sure security requirements are met. Examples of software security- assurance processes and controls include software- design reviews, automated code reviews, security-specific functional testing, and change-management processes. For organizations that leverage Agile software- development methodologies, security checkpoints may be incorporated into the “story” acceptance criteria or the criteria for determining when work …
• An inventory of software security-assurance processes is maintained.
Software security-assurance processes are activities that are implemented to carry out the vendor’s software- security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the vendor’s products and services are secure and resistant to attack, vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software-development process where software is checked to make sure security requirements are met. Examples of software security- assurance processes and controls include software- design reviews, automated code reviews, security-specific functional testing, and change-management processes. For organizations that leverage Agile software- development methodologies, security checkpoints may be incorporated into the “story” acceptance criteria or the criteria for determining when work …
Added
p. 255
D.1.2.5.a Examine vendor evidence, including the inventory of software security-assurance processes, and interview personnel to confirm that evidence is generated and maintained for each security- assurance process.
To demonstrate the effectiveness of software security- assurance processes, evidence should be generated and maintained for each process to show that it directly results in or contributes to the expected security outcomes⎯e.g., fewer vulnerabilities or greater resistance to attacks.
Evidence needs to be frequently collected and kept up to date to ensure it accurately reflects the ongoing effectiveness of security-assurance processes. Without a track record of performance for software security- assurance processes, it becomes almost impossible to effectively perform root-cause analysis when such processes fail to produce the expected results.
Evidence to support this objective might include security control and evidence generation inventories, vulnerability reports, penetration testing results, or any other records and evidence that clearly and consistently show evidence is generated for each software security-assurance …
To demonstrate the effectiveness of software security- assurance processes, evidence should be generated and maintained for each process to show that it directly results in or contributes to the expected security outcomes⎯e.g., fewer vulnerabilities or greater resistance to attacks.
Evidence needs to be frequently collected and kept up to date to ensure it accurately reflects the ongoing effectiveness of security-assurance processes. Without a track record of performance for software security- assurance processes, it becomes almost impossible to effectively perform root-cause analysis when such processes fail to produce the expected results.
Evidence to support this objective might include security control and evidence generation inventories, vulnerability reports, penetration testing results, or any other records and evidence that clearly and consistently show evidence is generated for each software security-assurance …
Added
p. 256
• A mature process exists to detect and evaluate weak or ineffective security-assurance processes.
• The criteria for determining a weak or ineffective security-assurance process are defined and justified.
• Security assurance processes are updated, augmented, or replaced when deemed weak or ineffective.
Software vendors should monitor their security-assurance processes to confirm the processes remain appropriate⎯i.e., fit for purpose⎯and effective for their intended purpose and function. For example, the use of manual code reviews may be sufficient to detect all coding errors and vulnerabilities for software with a very limited code base. However, as the code base grows, the use of manual code reviews for the same purpose becomes increasingly impractical or insufficient, and automated testing tools (such as automated static-code scanners and dynamic software-analysis tools) should be used.
One method for detecting weak or ineffective security controls is to define a set of metrics or trends that can be used to measure the …
• The criteria for determining a weak or ineffective security-assurance process are defined and justified.
• Security assurance processes are updated, augmented, or replaced when deemed weak or ineffective.
Software vendors should monitor their security-assurance processes to confirm the processes remain appropriate⎯i.e., fit for purpose⎯and effective for their intended purpose and function. For example, the use of manual code reviews may be sufficient to detect all coding errors and vulnerabilities for software with a very limited code base. However, as the code base grows, the use of manual code reviews for the same purpose becomes increasingly impractical or insufficient, and automated testing tools (such as automated static-code scanners and dynamic software-analysis tools) should be used.
One method for detecting weak or ineffective security controls is to define a set of metrics or trends that can be used to measure the …
Added
p. 257
Security Requirements Test Requirements Guidance D.2.1 Threat Identification and Mitigation Continuously identifies, assesses, and manages risk to its software and services.
D.2.1.1 Critical assets are identified and classified.
• A mature process exists to identify and classify critical assets.
• The criteria for identifying critical assets and determining the confidentiality, integrity, and resiliency requirements for each critical assets are defined.
• The process accounts for all types of critical assets
•including sensitive assets, sensitive resources, and sensitive functions
•for the vendor’s software.
• The process results in an inventory of critical assets used by the vendor’s software.
Before the vendor can determine how to effectively secure and defend its software against attacks, it must first develop a thorough understanding of the software’s critical assets that could be targeted by attackers.
Critical assets include any sensitive assets collected, stored, processed, or transmitted by the vendor’s software, as well as any sensitive functions and sensitive resources within or used by the …
D.2.1.1 Critical assets are identified and classified.
• A mature process exists to identify and classify critical assets.
• The criteria for identifying critical assets and determining the confidentiality, integrity, and resiliency requirements for each critical assets are defined.
• The process accounts for all types of critical assets
•including sensitive assets, sensitive resources, and sensitive functions
•for the vendor’s software.
• The process results in an inventory of critical assets used by the vendor’s software.
Before the vendor can determine how to effectively secure and defend its software against attacks, it must first develop a thorough understanding of the software’s critical assets that could be targeted by attackers.
Critical assets include any sensitive assets collected, stored, processed, or transmitted by the vendor’s software, as well as any sensitive functions and sensitive resources within or used by the …
Added
p. 258
D.2.1.2.a Examine vendor evidence, including process documentation and assessment results to confirm the following:
• A mature process exists to identify, assess, and monitor software threats and design weaknesses (i.e., flaws).
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attacker.
• The assessment accounts for the entire code base, including how the use of third-party, open-source, or shared components or libraries, APIs, services, and applications used for the delivery and operation of the software may be leveraged in an attack.
• The assessment results in a recorded inventory of threats and design flaws.
• Assessments are routinely performed to account for changes to existing or the emergence of new threats or design flaws.
Determining how to effectively secure and defend software against attacks requires a thorough understanding of the specific threats and vulnerabilities applicable to the vendor’s software. This typically involves …
• A mature process exists to identify, assess, and monitor software threats and design weaknesses (i.e., flaws).
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attacker.
• The assessment accounts for the entire code base, including how the use of third-party, open-source, or shared components or libraries, APIs, services, and applications used for the delivery and operation of the software may be leveraged in an attack.
• The assessment results in a recorded inventory of threats and design flaws.
• Assessments are routinely performed to account for changes to existing or the emergence of new threats or design flaws.
Determining how to effectively secure and defend software against attacks requires a thorough understanding of the specific threats and vulnerabilities applicable to the vendor’s software. This typically involves …
Added
p. 259
• An inventory of open-source components used in the vendor’s software is maintained.
• A mature process exists to analyze and mitigate the use of open-source components with known vulnerabilities.
• The vendor monitors vulnerabilities in open- source components throughout their use or inclusion in the vendor’s software.
• An appropriate patching strategy for open- source components is defined.
When open-source software components are used, the vendor should consider any risks associated with the use of the open-source components and the extent to which the open-source software provider manages the security of those components. Additionally, the vendor will need to confirm that support
•including up-to-date security patches
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate …
• A mature process exists to analyze and mitigate the use of open-source components with known vulnerabilities.
• The vendor monitors vulnerabilities in open- source components throughout their use or inclusion in the vendor’s software.
• An appropriate patching strategy for open- source components is defined.
When open-source software components are used, the vendor should consider any risks associated with the use of the open-source components and the extent to which the open-source software provider manages the security of those components. Additionally, the vendor will need to confirm that support
•including up-to-date security patches
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate …
Added
p. 260
D.2.1.3.a Examine vendor evidence, including process documentation and software-specific threat and design information, to confirm the following:
• A mature process exists for defining software- specific security requirements and implementing software security controls within the software to mitigate software threats and design flaws.
• Decisions on whether and how to mitigate a specific threat or design flaw are recorded, justified, and approved by appropriate personnel.
• Any remaining residual risk is recorded, justified, and approved by appropriate personnel.
To ensure that its software is resistant to attacks, vendors must implement software-specific controls or countermeasures in their software to mitigate the specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software …
• A mature process exists for defining software- specific security requirements and implementing software security controls within the software to mitigate software threats and design flaws.
• Decisions on whether and how to mitigate a specific threat or design flaw are recorded, justified, and approved by appropriate personnel.
• Any remaining residual risk is recorded, justified, and approved by appropriate personnel.
To ensure that its software is resistant to attacks, vendors must implement software-specific controls or countermeasures in their software to mitigate the specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software …
Added
p. 261
• A mature process exists to identify weak or ineffective software security controls and to update, augment, or replace them.
• The criteria for determining a weak or ineffective security control are defined and justified.
• The process involves monitoring security control effectiveness throughout the software lifecycle.
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection.
Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software, SSL is no longer sufficient to adequately protect communications as new threats and attack methods have significantly reduced its effectiveness as a security control. …
• The criteria for determining a weak or ineffective security control are defined and justified.
• The process involves monitoring security control effectiveness throughout the software lifecycle.
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection.
Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software, SSL is no longer sufficient to adequately protect communications as new threats and attack methods have significantly reduced its effectiveness as a security control. …
Added
p. 262
D.2.2.1 Existing and emerging software vulnerabilities are detected in a timely manner.
• A mature process exists for testing software for the existence and emergence of vulnerabilities (i.e., security testing).
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities in the vendor’s software, and are suitable for the software architectures, and the software development languages and frameworks employed.
• Security testing is performed throughout the entire software lifecycle, including after release.
• Security testing accounts for the entire code base, including detecting vulnerabilities in any third-party, open-source, and shared components and libraries.
• Security testing is performed by authorized and objective vendor personnel or third parties.
• Security testing results in an inventory of identified vulnerabilities.
• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained.
Software should be monitored or routinely tested to confirm that vulnerabilities are identified and mitigated before software or code …
• A mature process exists for testing software for the existence and emergence of vulnerabilities (i.e., security testing).
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities in the vendor’s software, and are suitable for the software architectures, and the software development languages and frameworks employed.
• Security testing is performed throughout the entire software lifecycle, including after release.
• Security testing accounts for the entire code base, including detecting vulnerabilities in any third-party, open-source, and shared components and libraries.
• Security testing is performed by authorized and objective vendor personnel or third parties.
• Security testing results in an inventory of identified vulnerabilities.
• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained.
Software should be monitored or routinely tested to confirm that vulnerabilities are identified and mitigated before software or code …
Added
p. 263
• Security-testing tools are configured in a way that is appropriate for the intended tests performed.
• Security testing was performed by authorized and objective vendor personnel or third parties.
D.2.2.1.c Examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in the following areas in accordance with D1.1.3:
• Software security testing techniques
• Security testing tools settings, configurations, and recommended usage D.2.2.1.d Examine software-specific testing results to confirm that security testing is performed throughout the software lifecycle.
• Security testing was performed by authorized and objective vendor personnel or third parties.
D.2.2.1.c Examine vendor evidence and interview personnel to confirm that personnel responsible for testing are knowledgeable and skilled in the following areas in accordance with D1.1.3:
• Software security testing techniques
• Security testing tools settings, configurations, and recommended usage D.2.2.1.d Examine software-specific testing results to confirm that security testing is performed throughout the software lifecycle.
Added
p. 264
• A mature process exists for distributing and deploying fixes for newly discovered vulnerabilities and preventing the reintroduction of previously resolved vulnerabilities.
• The process includes methods to prevent previously resolved vulnerabilities or other similar vulnerabilities from being reintroduced into the software.
• The criteria for determining the “criticality” or “severity” of vulnerabilities and how to address vulnerabilities are defined and justified.
• Fixes to address vulnerabilities in production code are made available and deployed in accordance with defined criteria.
• Decisions not to provide fixes in accordance with defined criteria are approved and justified by appropriate personnel on a case-by-case basis.
Vulnerabilities should be addressed in a way commensurate with the risk they pose to the software or its stakeholders. The most critical or severe vulnerabilities (i.e., those with the highest exploitability and/or the greatest impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability and/or impact. Additionally, the discovery of …
• The process includes methods to prevent previously resolved vulnerabilities or other similar vulnerabilities from being reintroduced into the software.
• The criteria for determining the “criticality” or “severity” of vulnerabilities and how to address vulnerabilities are defined and justified.
• Fixes to address vulnerabilities in production code are made available and deployed in accordance with defined criteria.
• Decisions not to provide fixes in accordance with defined criteria are approved and justified by appropriate personnel on a case-by-case basis.
Vulnerabilities should be addressed in a way commensurate with the risk they pose to the software or its stakeholders. The most critical or severe vulnerabilities (i.e., those with the highest exploitability and/or the greatest impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability and/or impact. Additionally, the discovery of …
Added
p. 266
Security Requirements Test Requirements Guidance D.3.1 Change Management Identify and manage all software changes throughout the software lifecycle.
D.3.1.1 All changes to software are identified, assessed, and approved.
D.3.1.1.a Examine vendor evidence and interview personnel to confirm:
• A mature process exists to identify, assess, and approve all changes to software.
• The process includes an analysis of the security impact of all changes.
• The process results in an inventory of all changes made to software, including a record of the determined security impact.
• All change-management decisions are recorded.
• All implemented changes are authorized by responsible personnel.
• The inventory of changes identifies the individual creator of the code and individual authorizing the change, for each code change.
• All decisions to implement changes are justified.
All changes to software should be defined, documented, approved, and tracked so that any vulnerabilities attributed to such changes may be identified and resolved as quickly as possible. The harder it …
D.3.1.1 All changes to software are identified, assessed, and approved.
D.3.1.1.a Examine vendor evidence and interview personnel to confirm:
• A mature process exists to identify, assess, and approve all changes to software.
• The process includes an analysis of the security impact of all changes.
• The process results in an inventory of all changes made to software, including a record of the determined security impact.
• All change-management decisions are recorded.
• All implemented changes are authorized by responsible personnel.
• The inventory of changes identifies the individual creator of the code and individual authorizing the change, for each code change.
• All decisions to implement changes are justified.
All changes to software should be defined, documented, approved, and tracked so that any vulnerabilities attributed to such changes may be identified and resolved as quickly as possible. The harder it …
Added
p. 267
• A formal system or methodology for uniquely identifying each version of software is defined.
• The system or methodology includes arranging unique identifiers or version elements in a sequential and logical way.
• All changes to software functionality are clearly associated with a unique software version.
• All changes to software functionality are clearly associated with a unique software version.
Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of such changes.
The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management.
The versioning system or methodology should encompass all changes to all relevant software components. As several iterations of a …
• The system or methodology includes arranging unique identifiers or version elements in a sequential and logical way.
• All changes to software functionality are clearly associated with a unique software version.
• All changes to software functionality are clearly associated with a unique software version.
Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of such changes.
The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management.
The versioning system or methodology should encompass all changes to all relevant software components. As several iterations of a …
Added
p. 268
D.3.2.1 The integrity of all software code, including third-party components, is maintained throughout the entire software lifecycle.
D.3.2.1.a Examine evidence, interview personnel, and observe tools and processes to confirm:
• A mature process, mechanism, and/or tool(s) exist to protect the integrity of the software code, including third-party components.
• The processes, mechanisms, and/or tools are reasonable and appropriate for protecting the integrity of software code.
• Processes, mechanisms, or the use of tools results in the timely detection of any unauthorized attempts to tamper with or access software code.
• Unauthorized attempts to tamper with or access software code are investigated in a timely manner.
Effective software-code control practices help ensure that all changes to code are authorized and performed only by those with a legitimate reason to change the code. Examples of these practices include code check-in and check-out procedures with strict access controls, and a comparison
•e.g., using a checksum
•immediately before updating code to confirm …
D.3.2.1.a Examine evidence, interview personnel, and observe tools and processes to confirm:
• A mature process, mechanism, and/or tool(s) exist to protect the integrity of the software code, including third-party components.
• The processes, mechanisms, and/or tools are reasonable and appropriate for protecting the integrity of software code.
• Processes, mechanisms, or the use of tools results in the timely detection of any unauthorized attempts to tamper with or access software code.
• Unauthorized attempts to tamper with or access software code are investigated in a timely manner.
Effective software-code control practices help ensure that all changes to code are authorized and performed only by those with a legitimate reason to change the code. Examples of these practices include code check-in and check-out procedures with strict access controls, and a comparison
•e.g., using a checksum
•immediately before updating code to confirm …
Added
p. 269
D.3.3.1 Sensitive production data is only collected and retained on vendor systems where there is a legitimate business or technical need.
• A mature process exists to record and authorize the collection and retention of any sensitive production data.
• An inventory of sensitive production data captured or stored by the vendor’s products and services is maintained.
• Decisions to use sensitive production data are approved by appropriate vendor personnel.
• Decisions to use sensitive production data are recorded and reasonably justified.
To protect the confidentiality of any sensitive production data
•that is, sensitive assets that are owned by an entity other than the vendor
• and stored on vendor systems, such data should never be used for purposes other than those for which the data was originally collected. If the vendor provides services to its customers that could result in the collection of sensitive production data⎯e.g., for troubleshooting or debugging purposes⎯the vendor should record those specific …
• A mature process exists to record and authorize the collection and retention of any sensitive production data.
• An inventory of sensitive production data captured or stored by the vendor’s products and services is maintained.
• Decisions to use sensitive production data are approved by appropriate vendor personnel.
• Decisions to use sensitive production data are recorded and reasonably justified.
To protect the confidentiality of any sensitive production data
•that is, sensitive assets that are owned by an entity other than the vendor
• and stored on vendor systems, such data should never be used for purposes other than those for which the data was originally collected. If the vendor provides services to its customers that could result in the collection of sensitive production data⎯e.g., for troubleshooting or debugging purposes⎯the vendor should record those specific …
Added
p. 270
Security Requirements Test Requirements Guidance D.4.1 Vendor Implementation Guidance Stakeholders are provided with clear and thorough guidance on the secure implementation, configuration, and operation of its software.
D.4.1.1 The vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its software.
• A mature process exists to produce, maintain, and make available to stakeholders’ guidance on the secure implementation, configuration, and operation of its software.
• The implementation guidance includes documentation of all configurable security- related options and parameters for the vendor’s software, and instructions for properly configuring and securing each of those options and parameters.
When followed, the vendor's implementation guidance provides assurance that the software and patches are securely installed, configured, and maintained in the customer environment, and that all desired security functionality is active and working as intended. The guidance should cover all options and functionality available to software users that could affect the security …
D.4.1.1 The vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its software.
• A mature process exists to produce, maintain, and make available to stakeholders’ guidance on the secure implementation, configuration, and operation of its software.
• The implementation guidance includes documentation of all configurable security- related options and parameters for the vendor’s software, and instructions for properly configuring and securing each of those options and parameters.
When followed, the vendor's implementation guidance provides assurance that the software and patches are securely installed, configured, and maintained in the customer environment, and that all desired security functionality is active and working as intended. The guidance should cover all options and functionality available to software users that could affect the security …
Added
p. 271
• The secure implementation guidance includes instructions about how to securely install or initialize, configure, and maintain the software.
• The secure implementation guidance is sufficiently detailed.
• Evidence exists or is obtained to show that following the secure implementation guidance results in a secure software configuration.
As the vendor is expected to continuously identify, assess, and manage risks to its software, the vendor’s software-change processes should include determining the impact of the change to vendor guidance. Software changes that impact a configurable feature or option should result in an update to the secure implementation guidance.
D.4.1.3 Secure implementation guidance is aligned with software updates.
• The process to produce and maintain secure implementation guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.
• Secure implementation guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not …
• The secure implementation guidance is sufficiently detailed.
• Evidence exists or is obtained to show that following the secure implementation guidance results in a secure software configuration.
As the vendor is expected to continuously identify, assess, and manage risks to its software, the vendor’s software-change processes should include determining the impact of the change to vendor guidance. Software changes that impact a configurable feature or option should result in an update to the secure implementation guidance.
D.4.1.3 Secure implementation guidance is aligned with software updates.
• The process to produce and maintain secure implementation guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.
• Secure implementation guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not …
Added
p. 272
D.4.2.1 Communication channels are defined and made available for customers, installers, integrators, and other relevant parties to report and receive information on security issues and mitigation options.
D.4.2.1.a Examine evidence and interview personnel to confirm the following:
• A mature process exists to support open, bi- directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services.
• Communication channels provide stakeholders the ability to report security- related issues and to receive timely status updates on their queries.
• The vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
Vendors should monitor the threat landscape to identify new vulnerabilities and security issues that impact their software on the market. Vendors should also provide open lines of communication to enable researchers or other stakeholders to report newly discovered vulnerabilities in the vendor’s products and services. Communication channels could include a publicly disclosed …
D.4.2.1.a Examine evidence and interview personnel to confirm the following:
• A mature process exists to support open, bi- directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services.
• Communication channels provide stakeholders the ability to report security- related issues and to receive timely status updates on their queries.
• The vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
Vendors should monitor the threat landscape to identify new vulnerabilities and security issues that impact their software on the market. Vendors should also provide open lines of communication to enable researchers or other stakeholders to report newly discovered vulnerabilities in the vendor’s products and services. Communication channels could include a publicly disclosed …
Added
p. 273
D.4.3 Software Update Information Stakeholders are provided with detailed explanations of all software changes.
D.4.3.1 Upon release of any software updates, a summary of the specific changes made to the software is provided to stakeholders.
• A mature process exists to communicate all software changes to stakeholders upon software updates.
• The process results in a clear and detailed summary of all software changes.
• The change summary information clearly outlines the specific software functionality impacted by the changes.
• Change details are easily accessible to stakeholders.
Release notes should be provided for all software updates, including details of any impact on software functionality and security controls. Informing stakeholders of the impact of a software update enables them to make informed decisions on whether and when to implement it.
D.4.3.1.b For a sample of software updates, examine publicly available information or notifications regarding the software updates to confirm the following:
• Change summary information is made available to …
D.4.3.1 Upon release of any software updates, a summary of the specific changes made to the software is provided to stakeholders.
• A mature process exists to communicate all software changes to stakeholders upon software updates.
• The process results in a clear and detailed summary of all software changes.
• The change summary information clearly outlines the specific software functionality impacted by the changes.
• Change details are easily accessible to stakeholders.
Release notes should be provided for all software updates, including details of any impact on software functionality and security controls. Informing stakeholders of the impact of a software update enables them to make informed decisions on whether and when to implement it.
D.4.3.1.b For a sample of software updates, examine publicly available information or notifications regarding the software updates to confirm the following:
• Change summary information is made available to …
Added
p. 274
Only requirements for the non-PTS approved MSR device itself are covered in this Appendix. Requirements for the integration and use of a non-PTS approved MSR device within an overall MPoC Solution are covered within the MPoC requirements listed in the body of this document.
MSR Validation and Testing Requirements Magnetic-stripe data input to an MPoC Solution must be read by an approved device. This device may be a PCI PTS POI, tested and approved through the PCI PTS POI program, or a non-PTS approved MSR tested according to the requirements in this appendix. Regardless of validation, magnetic-stripe-based transactions may not be used by an MPoC Solution with PIN acceptance.
Many of the testing requirements in this appendix are based on, and reference, the PCI PTS POI v6.x Derived Test Requirements document. However, this appendix references only a subset of the requirements that would be tested against a PCI PTS POI device and …
MSR Validation and Testing Requirements Magnetic-stripe data input to an MPoC Solution must be read by an approved device. This device may be a PCI PTS POI, tested and approved through the PCI PTS POI program, or a non-PTS approved MSR tested according to the requirements in this appendix. Regardless of validation, magnetic-stripe-based transactions may not be used by an MPoC Solution with PIN acceptance.
Many of the testing requirements in this appendix are based on, and reference, the PCI PTS POI v6.x Derived Test Requirements document. However, this appendix references only a subset of the requirements that would be tested against a PCI PTS POI device and …
Added
p. 275
E.2.1.a The tester must confirm through examination and observation that the non-PTS approved MSR does not store account data. It must not be possible for more than one set of magnetic-stripe data to be present within the memory of the non-PTS approved MSR device at any one time.
Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be only one set of data within the non-PTS approved MSR device at any one time.
Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be only …
Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be only one set of data within the non-PTS approved MSR device at any one time.
Account data should be transferred from the non-PTS approved MSR device to the MPoC Software as soon as practicable. Although there may be some delay between the read of the data and the transfer of the data to the MPoC Software, there can be only …
Added
p. 276
E.5.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B5 and confirm compliance to all applicable requirements.
Although PCI PTS POI v6.x B5 includes testing requirements that cover aspects of PIN security, a non- PTS approved MSR device must not allow for the entry or processing of cardholder PINs.
E.6 Sensitive Service Limits Security Requirements Test Requirements Guidance E.6.1 To minimize the risks from unauthorized use of sensitive services, limits on the number of actions that can be performed, and a time limit shall be imposed, after which the device is forced to return to its normal mode.
E.6.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B6 and confirm compliance to all applicable requirements.
E.7 Key Management Security Requirements Test Requirements Guidance E.7.1 The key management techniques implemented in the device conform to ISO11568 and/or ANSI X9.24. When multiple cryptographic keys …
Although PCI PTS POI v6.x B5 includes testing requirements that cover aspects of PIN security, a non- PTS approved MSR device must not allow for the entry or processing of cardholder PINs.
E.6 Sensitive Service Limits Security Requirements Test Requirements Guidance E.6.1 To minimize the risks from unauthorized use of sensitive services, limits on the number of actions that can be performed, and a time limit shall be imposed, after which the device is forced to return to its normal mode.
E.6.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B6 and confirm compliance to all applicable requirements.
E.7 Key Management Security Requirements Test Requirements Guidance E.7.1 The key management techniques implemented in the device conform to ISO11568 and/or ANSI X9.24. When multiple cryptographic keys …
Added
p. 277
E.8.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B10 and confirm compliance to all applicable requirements.
Encryption algorithms used to protect account data are required to provide at least 128 bits of effective strength. TDEA encryption is not permitted to be used by a non- PTS approved MSR device for any security services.
Use of AES encryption for non-PTS approved MSR devices is recommended. E.8.1.b The tester must confirm through examination and observation that the non-PTS approved MSR uses only algorithms and key lengths that provide an effective key strength of at least 128 bits.
E.9 Remote Access Security Requirements Test Requirements Guidance E.9.1 If the device can be accessed remotely for the purposes of administration, all access attempts must be cryptographically authenticated. If the authenticity of the access request cannot be confirmed, the access request is denied.
E.9.1.a The tester must evaluate the non-PTS approved MSR …
Encryption algorithms used to protect account data are required to provide at least 128 bits of effective strength. TDEA encryption is not permitted to be used by a non- PTS approved MSR device for any security services.
Use of AES encryption for non-PTS approved MSR devices is recommended. E.8.1.b The tester must confirm through examination and observation that the non-PTS approved MSR uses only algorithms and key lengths that provide an effective key strength of at least 128 bits.
E.9 Remote Access Security Requirements Test Requirements Guidance E.9.1 If the device can be accessed remotely for the purposes of administration, all access attempts must be cryptographically authenticated. If the authenticity of the access request cannot be confirmed, the access request is denied.
E.9.1.a The tester must evaluate the non-PTS approved MSR …
Added
p. 278
E.10.1.a The tester must evaluate the non-PTS approved MSR to PCI PTS POI v6.x DTR B23 and confirm compliance to all applicable requirements.
Although PCI PTS POI v6.x B23 supports the testing of devices that provide for a non-encrypting mode, non-PTS approved MSR devices are not permitted to implement any mode where account data is output in cleartext.
E.11 Surrogate PAN Values Security Requirements Test Requirements Guidance E.11.1.a If the device is capable of generating surrogate PAN values to be outputted outside of the device, it is not possible to determine the original PAN knowing only the surrogate value. Where a hash function is used to generate surrogate PAN values, a keyed hash function must be implemented.
E.11.1.a Where a hash function is used to generate surrogate PAN values the tester shall verify: a) That an industry standard keyed hash function (such as HMAC) is implemented. b) How the key(s) are loaded and …
Although PCI PTS POI v6.x B23 supports the testing of devices that provide for a non-encrypting mode, non-PTS approved MSR devices are not permitted to implement any mode where account data is output in cleartext.
E.11 Surrogate PAN Values Security Requirements Test Requirements Guidance E.11.1.a If the device is capable of generating surrogate PAN values to be outputted outside of the device, it is not possible to determine the original PAN knowing only the surrogate value. Where a hash function is used to generate surrogate PAN values, a keyed hash function must be implemented.
E.11.1.a Where a hash function is used to generate surrogate PAN values the tester shall verify: a) That an industry standard keyed hash function (such as HMAC) is implemented. b) How the key(s) are loaded and …
Added
p. 279
E.12.1.a The tester must evaluate the non-PTS approved MSR to Module 3 of PCI PTS POI v6.x and confirm compliance to all applicable requirements.
E.13.1.a The tester must evaluate the non-PTS approved MSR to Module 4 of PCI PTS POI v6.x and confirm compliance to all applicable requirements.
Only applicable Sections of the Module 3 requirements must be assessed. For example, requirements covering the security of IP protocols need not be assessed against devices that do not provide IP connectivity.
Regardless of interface types supported, testing of requirements validating the implementation of data origin authentication are always required to be assessed.
E.13 Lifecycle Security Requirements Security Requirements Test Requirements Guidance E.13.1 The non-PTS approved MSR development, manufacturing, and distribution processes must be compliant to the requirements of PCI PTS POI v6.x Module 4.
On-site validation of the processes and security controls is not required.
E.13.1.a The tester must evaluate the non-PTS approved MSR to Module 4 of PCI PTS POI v6.x and confirm compliance to all applicable requirements.
Only applicable Sections of the Module 3 requirements must be assessed. For example, requirements covering the security of IP protocols need not be assessed against devices that do not provide IP connectivity.
Regardless of interface types supported, testing of requirements validating the implementation of data origin authentication are always required to be assessed.
E.13 Lifecycle Security Requirements Security Requirements Test Requirements Guidance E.13.1 The non-PTS approved MSR development, manufacturing, and distribution processes must be compliant to the requirements of PCI PTS POI v6.x Module 4.
On-site validation of the processes and security controls is not required.
Added
p. 280
The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical equivalent. The tester shall verify that the compiled instance of the STS tool is operating correctly on the testing device by testing the NIST-provided sample data and comparing the results with those found in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely continue to be applicable to future versions.
Note: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing …
Note: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test [Hamano 2009] and include fixes to the DFT (Spectral) test [Kim 2004], the Overlapping Template test [Hamano 2007], the Non-Overlapping test [NIST 2014], and the “Proportion of Sequences Passing …
Added
p. 281
Table 11: Configuration Settings Configuration Item Setting Reference in Key Below Length of bit streams (n) 1,000,000 n must be selected to be consistent with the requirements of all of the tests to be run. The Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant tests all require n to be greater than or equal to 106 in order to produce meaningful results. The Discrete Fourier Transform (Spectral) test requires n to equal 106. (See SP 800-22r1a Sections 2.8.7, 2.10.7, 2.14.7, 2.15.7, and [NIST 2010].) Number of bit streams (sample size) (M) 1,073 The number of bit sequences (sample size) must be 1,000 or greater in order for the "Proportion of Sequences Passing a Test" result to be meaningful. (See SP 800-22r1a Section 4.2.1.) This value will be 1,073 for the first test, but any additional testing (e.g., further testing to resolve test failures) will necessarily include more bit …
Added
p. 282
[Kim 2004] Kim, Song-Ju, et al., "Corrections of the NIST Statistical Test Suite for Randomness." [Hill 2004] Hill, Joshua (InfoGard Labs), "ApEn Test Parameter Selection." [Hamano 2007] Hamano, K. and Kaneko, T., “Correction of Overlapping Template Matching Test Included in NIST Randomness Test Suite,” IEICE Trans. Fundamentals, vol. E90-A, no. 9, pp. 1788-1792, Sept. 2007.
[Hamano 2009] Hamano, Kenji, “Analysis and Application of the T-complexity.” Ph.D. thesis, The University of Tokyo.
[NIST 2010] STS Software Revision History. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html. Internet Archive: http://web.archive.org/web/20150520193625/http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html [NIST 2014] Current STS Release Notes. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html. Internet Archive: http://web.archive.org/web/20150103230340/http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
[Hamano 2009] Hamano, Kenji, “Analysis and Application of the T-complexity.” Ph.D. thesis, The University of Tokyo.
[NIST 2010] STS Software Revision History. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html. Internet Archive: http://web.archive.org/web/20150520193625/http://csrc.nist.gov/groups/ST/toolkit/rng/revision_history_software.html [NIST 2014] Current STS Release Notes. URL: http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html. Internet Archive: http://web.archive.org/web/20150103230340/http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
Modified
p. 1
Payment Card Industry (PCI) Mobile Payments on COTS (MPoC) Summary of Changes from Version 1.0.1 to 1.1
Payment Card Industry (PCI) Mobile Payments on COTS Security and Test Requirements Version 1.1
Removed
p. 2
SCRP Secure Card Reader PIN. An approval class as defined in the PTS POI Device Testing and Approval Guide.
COTS device The platform on which an MPoC Application executes. Defined in the MPoC standard.
HSM Hardware Security Module
Table 1: Change Types Change Type Definition Clarification or Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Evolving requirement Changes to ensure that the standard is up to date with emerging threats and technologies, and changes in the payment industry. Examples include new or modified requirements or testing procedures, or the removal of a requirement.
Structure or Reorganization of content, including combining, separating, and renumbering of requirements to align content.
Note: The changes above do not include those that are corrections of grammar or typographical errors or other rephrasing of existing statements.
COTS device The platform on which an MPoC Application executes. Defined in the MPoC standard.
HSM Hardware Security Module
Table 1: Change Types Change Type Definition Clarification or Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Evolving requirement Changes to ensure that the standard is up to date with emerging threats and technologies, and changes in the payment industry. Examples include new or modified requirements or testing procedures, or the removal of a requirement.
Structure or Reorganization of content, including combining, separating, and renumbering of requirements to align content.
Note: The changes above do not include those that are corrections of grammar or typographical errors or other rephrasing of existing statements.
Modified
p. 2 → 17
SDK The subset of MPoC Software, that implements required functionality for the payment acceptance and attestation on the COTS device, and secure communication with the back-end systems.
Mobile Payments on COTS (MPoC) SDK (also MPoC SDK) The subset of MPoC Software that implements required functionality for the payment acceptance and attestation on the COTS device and secure communication with the back-end systems.
Modified
p. 2 → 134
• Where a physical keypad is used for PIN entry, that keypad is part of a device listed as validated to the PCI PTS POI requirements.
Removed
p. 3
Table 2: Summary of Changes Requirements Reference Change Type General Changed the Attestation and Monitoring Service MPoC Product to a more generic “MPoC Service” Product.
Structure or General Changed references to PCI PTS POI SCRP approval class to a more generic PCI PTS POI. Some changes to Security Requirements throughout the document to accommodate this change.
Structure or General Implemented the term ‘COTS-based MPoC Software’ throughout to reference instances where there is applicability to either an MPoC SDK or an MPoC Application.
Structure or General Introduced the ability for an MPoC SDK to integrate (up to one) other MPoC SDK.
Evolving requirement General Removed references to PCI DSS DESV. Some changes to Security Requirements throughout the document to accommodate this change.
Evolving requirement General Modified the definition of COTS devices, as well as aspects of the initial pre-amble of the document.
Evolving requirement General Updated the matrix of applicability to reflect associated changes in the MPoC …
Structure or General Changed references to PCI PTS POI SCRP approval class to a more generic PCI PTS POI. Some changes to Security Requirements throughout the document to accommodate this change.
Structure or General Implemented the term ‘COTS-based MPoC Software’ throughout to reference instances where there is applicability to either an MPoC SDK or an MPoC Application.
Structure or General Introduced the ability for an MPoC SDK to integrate (up to one) other MPoC SDK.
Evolving requirement General Removed references to PCI DSS DESV. Some changes to Security Requirements throughout the document to accommodate this change.
Evolving requirement General Modified the definition of COTS devices, as well as aspects of the initial pre-amble of the document.
Evolving requirement General Updated the matrix of applicability to reflect associated changes in the MPoC …
Modified
p. 3 → 53
1A-1.5 An MPoC SDK does not pass cleartext sensitive assets to another MPoC SDK or an MPoC Application.
Removed
p. 4
Evolving requirement SR 1A-2.3 Changed wording to clarify applicability when use of a true RNG cannot be assured.
Clarification or SR 1A-2.5 Changed wording to clarify that at least one trusted source of entropy is required from the COTS device. Updated guidance from existing MPoC FAQ.
Clarification or SR 1A-2.6 Changed wording to clarify the intent to ensure sufficient entropy. Added guidance.
Clarification or SR 1A-3.2 Added guidance noting that RSA 2048 bit may be used to load AES keys if the COTS platform prevents the use of larger RSA keys.
Evolving requirement SR 1A-3.3 Changed wording to clarify applicability is prior to certificate being relied upon for security services.
Clarification or SR 1A-4.6 Changed wording to allow for use of some backend keys outside of a HSM. Added new test steps and guidance.
Evolving requirement SR 1A-4.8 Added clarification regarding use of RSA2048 bit, aligned with changes to SR 1A-3.2. Additionally added guidance noting that …
Clarification or SR 1A-2.5 Changed wording to clarify that at least one trusted source of entropy is required from the COTS device. Updated guidance from existing MPoC FAQ.
Clarification or SR 1A-2.6 Changed wording to clarify the intent to ensure sufficient entropy. Added guidance.
Clarification or SR 1A-3.2 Added guidance noting that RSA 2048 bit may be used to load AES keys if the COTS platform prevents the use of larger RSA keys.
Evolving requirement SR 1A-3.3 Changed wording to clarify applicability is prior to certificate being relied upon for security services.
Clarification or SR 1A-4.6 Changed wording to allow for use of some backend keys outside of a HSM. Added new test steps and guidance.
Evolving requirement SR 1A-4.8 Added clarification regarding use of RSA2048 bit, aligned with changes to SR 1A-3.2. Additionally added guidance noting that …
Modified
p. 4 → 50
• 1A-412 Moved these requirements to here from 1D-1.3
• Meets the requirements of Appendix D.
Modified
p. 4 → 55
1A-1.7.a The tester must confirm through examination and observation that all cleartext card- based payment functionality has been included in the scope of the MPoC Software assessment.
Modified
p. 4 → 55
1A-1.8 The COTS-based MPoC Software provides a mechanism to validate its version number.
Modified
p. 4 → 74
Public keys not used for account data encryption, such as keys used as part of an initial provisioning process, are not included in scope of this requirement.
Removed
p. 5
Evolving requirement SR 1A-5.2 SR 1A-5.5 Changed wording requiring secure channel on connections between different logical elements.
Evolving requirement SR 1A-5.6 Changed wording to clarify applicability to Secure Channels supported by the MPoC Software.
Evolving requirement SR 1A-5.7 Added clarification that this requirement does not apply to platform-based attestation.
Clarification or SR 1B-1.4 Clarified that this requirement does not apply to areas of memory or COTS subsystems that the COTS-based MPoC Software does not have access to (such as a COTS keystore).
Clarification or SR 1B-1.5 Clarified scope to also include any sensitive assets managed by the MPoC SDK, as well as noting any features not provided must be considered in the attack costing calculation.
Evolving requirement SR 1B-1.7 Changed wording to clarify the intent is to prevent use of compromised platforms which may impact the security of sensitive assets.
Evolving requirement SR 1B-1.12 Added new requirement to capture testing to determine if an MPoC SDK …
Evolving requirement SR 1A-5.6 Changed wording to clarify applicability to Secure Channels supported by the MPoC Software.
Evolving requirement SR 1A-5.7 Added clarification that this requirement does not apply to platform-based attestation.
Clarification or SR 1B-1.4 Clarified that this requirement does not apply to areas of memory or COTS subsystems that the COTS-based MPoC Software does not have access to (such as a COTS keystore).
Clarification or SR 1B-1.5 Clarified scope to also include any sensitive assets managed by the MPoC SDK, as well as noting any features not provided must be considered in the attack costing calculation.
Evolving requirement SR 1B-1.7 Changed wording to clarify the intent is to prevent use of compromised platforms which may impact the security of sensitive assets.
Evolving requirement SR 1B-1.12 Added new requirement to capture testing to determine if an MPoC SDK …
Modified
p. 5 → 82
The requirements of Module 1B are applicable to the COTS-based MPoC Software only. They do not apply to back-end systems or software.
Modified
p. 5 → 93
1B-1.11.d The tester must confirm through examination that any parts of the COTS-based MPoC Software implemented outside the REE are authenticated prior to execution.
Modified
p. 5 → 94
1B-1.13 Payment transaction data is securely deleted from the COTS device once it has been transmitted to the payment back-end.
Removed
p. 6
Clarification or SR 1B-2.5 Changed wording to clarify that secure key generation is only required if key generation is implemented.
Clarification or SR 1C-3.6 Changed wording to clarify intent is to prevent manipulation of payment cessation messages.
Clarification or SR 1C-4.2 Removed previous requirement as considered redundant with requirement 1A-5.7. Intent of requirement remains.
Clarification or SR 1D-1.2 SR 1D-1.3 Split 1D-1.2 into two requirements. Added guidance on how a PCI PTS POI that is not an SCRP device may be validated to ensure all account data is encrypted.
Evolving requirement SRs 1D-1.3
• 1D-1.6 Moved the requirements in PCI MPoC v1.0.1 to Section 1A- 4.x in the updated document as previously noted.
Evolving requirement SR 1D-2.2 Changed wording in test step to clarify that the POI devices supported must be validated to support chip acceptance if they are used for chip acceptance.
Evolving requirement SR 1D-2.3 Changed wording to support PCI PTS POI devices that are …
Clarification or SR 1C-3.6 Changed wording to clarify intent is to prevent manipulation of payment cessation messages.
Clarification or SR 1C-4.2 Removed previous requirement as considered redundant with requirement 1A-5.7. Intent of requirement remains.
Clarification or SR 1D-1.2 SR 1D-1.3 Split 1D-1.2 into two requirements. Added guidance on how a PCI PTS POI that is not an SCRP device may be validated to ensure all account data is encrypted.
Evolving requirement SRs 1D-1.3
• 1D-1.6 Moved the requirements in PCI MPoC v1.0.1 to Section 1A- 4.x in the updated document as previously noted.
Evolving requirement SR 1D-2.2 Changed wording in test step to clarify that the POI devices supported must be validated to support chip acceptance if they are used for chip acceptance.
Evolving requirement SR 1D-2.3 Changed wording to support PCI PTS POI devices that are …
Modified
p. 6 → 108
1C-2.3 The A&M data sent to the back- end implements methods to ensure the freshness and authenticity of the data.
Modified
p. 6 → 121
Additionally, a PCI PTS POI device that is not an SCRP may output account data that is not encrypted, and the SDK should be able to detect and respond to such occurrences.
Modified
p. 6 → 123
1D-2.1 The security guidance document details the secure card readers supported by the MPoC Software.
Modified
p. 6 → 130
PAN that is truncated in accordance with relevant PCI DSS FAQs is not considered in scope for these requirements.
Modified
p. 6 → 130
1D-5.2 Manually entered account data is used only for the purposes of transaction processing.
Removed
p. 7
Clarification or SR 1D-3.3 Clarified that the validation of attached MSR devices includes the firmware and hardware versions only where these values are applicable.
Clarification or SR 1D-4.3 Clarified that this requirement applies only when presentment of the card may be captured on the COTS camera.
Clarification or SR 1D-4.4 Removed requirement for validation of contactless kernel functional approval.
Evolving requirement SR 1D-4.4 Renumbered requirement from 1D-4.5 in PCI MPoC v1.0.1. Changed wording to clarify scope includes validation of relevant sections of Domain 4 and Domain 5.
Structure or 1D-5 Preamble Added note to clarify that PAN truncated to relevant PCI DSS FAQs is not considered in scope for these requirements.
Clarification or 1E Preamble Added clarification items regarding use of external POIs for PIN entry, and implementation of accessibility features during PIN entry.
Clarification or SR 1E-1.1 Added test step to confirm that any accessible PIN entry features are documented.
Evolving requirement SR 1E-1.3 Added clarification …
Clarification or SR 1D-4.3 Clarified that this requirement applies only when presentment of the card may be captured on the COTS camera.
Clarification or SR 1D-4.4 Removed requirement for validation of contactless kernel functional approval.
Evolving requirement SR 1D-4.4 Renumbered requirement from 1D-4.5 in PCI MPoC v1.0.1. Changed wording to clarify scope includes validation of relevant sections of Domain 4 and Domain 5.
Structure or 1D-5 Preamble Added note to clarify that PAN truncated to relevant PCI DSS FAQs is not considered in scope for these requirements.
Clarification or 1E Preamble Added clarification items regarding use of external POIs for PIN entry, and implementation of accessibility features during PIN entry.
Clarification or SR 1E-1.1 Added test step to confirm that any accessible PIN entry features are documented.
Evolving requirement SR 1E-1.3 Added clarification …
Modified
p. 7 → 125
1D-3.1 The security guidance document details the MSRs supported by the MPoC Software.
Modified
p. 7 → 131
1D-5.4 The COTS-based MPoC Software is able to detect events that could impact the security of the entry process.
Removed
p. 8
Clarification or SR 1E-1.5 Added guidance to note that PCI PTS POI devices which are not part of the SCRP approval class may not be used for PIN translation functions.
Clarification or SR 1E-1.7 Changed wording to clarify intent is when there is an event that potentially impacts the security of the PIN entry process and that potential overlay attacks must be communicated to the back-end A&M system.
Clarification or SR 1E-1.9 Changed wording to allow for support of PCI PTS POI devices that are not an SCRP, and to clarify that the device must be validated as supporting offline PIN entry.
Evolving requirement SR 1E-1.10 Added new requirement for testing accessible PIN entry functions.
Evolving requirement SR 1E-1.11 Added new requirement for testing PIN entry implemented through an attached PCI PTS POI.
Evolving requirement SR 1E-1.12 Added new requirement for testing PAN tokens, where implemented.
Clarification or SR 1F-1.3 SR 1F-2.3 Added guidance to clarify …
Clarification or SR 1E-1.7 Changed wording to clarify intent is when there is an event that potentially impacts the security of the PIN entry process and that potential overlay attacks must be communicated to the back-end A&M system.
Clarification or SR 1E-1.9 Changed wording to allow for support of PCI PTS POI devices that are not an SCRP, and to clarify that the device must be validated as supporting offline PIN entry.
Evolving requirement SR 1E-1.10 Added new requirement for testing accessible PIN entry functions.
Evolving requirement SR 1E-1.11 Added new requirement for testing PIN entry implemented through an attached PCI PTS POI.
Evolving requirement SR 1E-1.12 Added new requirement for testing PAN tokens, where implemented.
Clarification or SR 1F-1.3 SR 1F-2.3 Added guidance to clarify …
Modified
p. 8 → 142
This requirement covers the storage of offline transaction data by the COTS-based MPoC Software. It does not prohibit the transmission of encrypted offline transaction data through other “calling” applications.
Removed
p. 9
Evolving requirement SR 1G-1.8 Added new requirement to cover validation of guidance for implementations where the MPoC SDK allows for the other COTS-based MPoC Software to manage or implement secure channels.
Evolving requirement SR 1G-1.9 Changed wording to include external readers into scope. Evolving requirement SR 1G-1.12 New requirement to allow for MPoC Software vendors to perform vendor verification of other COTS-based MPoC Software that integrate their the isolating SDK(s) of the MPoC SDK vendor.
Evolving requirement Module 2A Preamble Added guidance to clarify scope of this module. Clarification or SR 2A-1.3 Changed wording to clarify that all card-based payment functions must be provided by the MPoC SDK(s).
Clarification or SR 2A-1.11 Added requirement to cover testing of COTS-based MPoC Software that implements or manages its own secure channels.
Section 3B-1 Moved the majority of these requirements in PCI MPoC v1.0.1 from this module to Domain 4.
Structure or SR 3B-1.4 Requirement moved from Section …
Evolving requirement SR 1G-1.9 Changed wording to include external readers into scope. Evolving requirement SR 1G-1.12 New requirement to allow for MPoC Software vendors to perform vendor verification of other COTS-based MPoC Software that integrate their the isolating SDK(s) of the MPoC SDK vendor.
Evolving requirement Module 2A Preamble Added guidance to clarify scope of this module. Clarification or SR 2A-1.3 Changed wording to clarify that all card-based payment functions must be provided by the MPoC SDK(s).
Clarification or SR 2A-1.11 Added requirement to cover testing of COTS-based MPoC Software that implements or manages its own secure channels.
Section 3B-1 Moved the majority of these requirements in PCI MPoC v1.0.1 from this module to Domain 4.
Structure or SR 3B-1.4 Requirement moved from Section …
Removed
p. 10
Evolving requirement 4A-3 Title and Changed to reflect new items moved from Domain 3. Structure or SR 4A-3.3
• 4A-3.4 Requirements moved from Section 3B in v1.0.1. Structure or
Section 4A-4 Requirements moved from Domain 5 in v1.0.1. Structure or SR 5A-1.3 Added clarification that this requirement may apply to entities managing merchant systems on behalf of merchants.
Evolving requirement Appendix B ‘Scalability’ Fixed errata showing ‘instance specific’ as 18 points instead of the correct value of 12 points Structure or
• 4A-3.4 Requirements moved from Section 3B in v1.0.1. Structure or
Section 4A-4 Requirements moved from Domain 5 in v1.0.1. Structure or SR 5A-1.3 Added clarification that this requirement may apply to entities managing merchant systems on behalf of merchants.
Evolving requirement Appendix B ‘Scalability’ Fixed errata showing ‘instance specific’ as 18 points instead of the correct value of 12 points Structure or