Document Comparison
PCI-Secure-Software-Standard-v1_1.pdf
→
PCI-Secure-Software-Standard-v1_2.pdf
30% similar
87 → 109
Pages
29566 → 39040
Words
346
Content Changes
Content Changes
346 content changes. 127 administrative changes (dates, page numbers) hidden.
Added
p. 7
Document Name Description
PCI Software Security Framework
• PCI Secure Software Lifecycle Standard (“Secure SLC Standard”) Additional security requirements for software development organizations to ensure they develop and maintain software securely throughout the entire software lifecycle.
PCI Software Security Framework
• Glossary of Terms, Abbreviations, and Acronyms (“SSF Glossary”) Describes important terms, abbreviations, and acronyms used throughout the Secure Software Standard and supporting documentation.
PCI Software Security Framework
• Secure Software Program Guide (“Secure Software Program Guide”) Describes the program requirements for entities to validate their payment software for compliance to the Secure Software Standard and have their software listed and maintained on the PCI SSC’s List of Validated Payment Software.
PCI Software Security Framework
• Secure Software Template for Report on Validation (“Secure Software ROV Reporting Template”) The mandatory template that qualified SSF Assessors must use to document the results of a Secure Software Assessment and report those results to PCI SSC.
PCI Software Security Framework
• Secure Software …
PCI Software Security Framework
• PCI Secure Software Lifecycle Standard (“Secure SLC Standard”) Additional security requirements for software development organizations to ensure they develop and maintain software securely throughout the entire software lifecycle.
PCI Software Security Framework
• Glossary of Terms, Abbreviations, and Acronyms (“SSF Glossary”) Describes important terms, abbreviations, and acronyms used throughout the Secure Software Standard and supporting documentation.
PCI Software Security Framework
• Secure Software Program Guide (“Secure Software Program Guide”) Describes the program requirements for entities to validate their payment software for compliance to the Secure Software Standard and have their software listed and maintained on the PCI SSC’s List of Validated Payment Software.
PCI Software Security Framework
• Secure Software Template for Report on Validation (“Secure Software ROV Reporting Template”) The mandatory template that qualified SSF Assessors must use to document the results of a Secure Software Assessment and report those results to PCI SSC.
PCI Software Security Framework
• Secure Software …
Added
p. 11
Objective-Based Approach to Requirements The PCI Software Security Framework has adopted an “objective-based” approach to defining the security requirements in this standard. The PCI SSC acknowledges that there is no “one size fits all” approach to software security and that software vendors need flexibility to determine the software security controls and features most appropriate to address their specific business needs and risks.
An “objective-based” approach is one that states security requirements as a desired security goal or outcome without necessarily specifying the method(s) to be used to achieve the desired goal. This approach enables entities to implement software security controls based on the risks identified by the software vendor for a given software application. For this approach to be successful, software vendors must possess a robust risk-management practice as an integral part of their software development lifecycle (SDLC) and be able to demonstrate how the implemented security controls are supported by …
An “objective-based” approach is one that states security requirements as a desired security goal or outcome without necessarily specifying the method(s) to be used to achieve the desired goal. This approach enables entities to implement software security controls based on the risks identified by the software vendor for a given software application. For this approach to be successful, software vendors must possess a robust risk-management practice as an integral part of their software development lifecycle (SDLC) and be able to demonstrate how the implemented security controls are supported by …
Added
p. 15
1.1.b The assessor shall examine evidence to confirm that information is maintained that describes where sensitive data is stored. This includes the storage of sensitive data in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), non-volatile storage (such as magnetic and flash storage media), or in specific locations or form factors (such as with an embedded system that is only capable of local storage).
1.1.c The assessor shall examine evidence to confirm that information is maintained that describes the security controls that are implemented to protect sensitive data.
1.1.d The assessor shall test the software to validate the evidence obtained in Test Requirements 1.1.a through 1.1.c.
1.1.f The assessor shall examine evidence and test the software to identify the cryptographic implementations that are supported by the software (including cryptography used for storage, transport, and authentication), and to confirm that the cryptographic data for all of these implementations is supported …
1.1.c The assessor shall examine evidence to confirm that information is maintained that describes the security controls that are implemented to protect sensitive data.
1.1.d The assessor shall test the software to validate the evidence obtained in Test Requirements 1.1.a through 1.1.c.
1.1.f The assessor shall examine evidence and test the software to identify the cryptographic implementations that are supported by the software (including cryptography used for storage, transport, and authentication), and to confirm that the cryptographic data for all of these implementations is supported …
Added
p. 19
2.1.f The assessor shall examine evidence to identify any third- party modules used by the software and to confirm that any such functions exposed by each module are disabled, unable to be accessed through mitigation methods implemented by the software, or formally documented and justified by the software vendor.
2.2.c Where user input or interaction is required to enable software security controls, features, or functions (such as the installation of certificates), the assessor shall examine evidence to confirm that clear and sufficient guidance on configuring these options is provided to stakeholders in accordance with Control Objective 12.1.
2.2.c Where user input or interaction is required to enable software security controls, features, or functions (such as the installation of certificates), the assessor shall examine evidence to confirm that clear and sufficient guidance on configuring these options is provided to stakeholders in accordance with Control Objective 12.1.
Added
p. 21
2.3.c Where user input or interaction is required to disable or change any authentication credentials or keys for built-in accounts, the assessor shall examine evidence to confirm that guidance on configuring these options is provided to stakeholders in accordance with Control Objective 12.1.
Added
p. 24
This control objective differentiates between transient sensitive data retained temporarily and persistent sensitive data that is retained on a more permanent basis. Examples of transient sensitive data include the retention account data in memory until payment authorization is received. Examples of persistent sensitive data include the storage of account data on disk to support recurrent payment transactions.
After payment processing is complete, all transient sensitive data should be securely deleted from all locations where it has been retained such that any subsequent process, component, function, application, or user within the environment may not access or capture the sensitive data.
After payment processing is complete, all transient sensitive data should be securely deleted from all locations where it has been retained such that any subsequent process, component, function, application, or user within the environment may not access or capture the sensitive data.
Added
p. 26
3.3.c Where protection methods use cryptography, the assessor shall examine vendor evidence and test the software to confirm that the cryptographic implementation complies with Control Objective 7 of this standard.
3.3.d Where sensitive data is protected using methods other than strong cryptography, the assessor shall examine evidence and test the software to confirm that the protections are present in all environments where the software is designed to be executed and are implemented correctly.
3.3.e Where user input or interaction is required to configure protection methods, the assessor shall examine evidence to confirm that guidance on configuring these options is provided to stakeholders in accordance with Control Objective 12.1.
3.4.a The assessor shall examine evidence to identify the methods implemented to render non-transient sensitive data irretrievable and to confirm that sensitive data is rendered unrecoverable after the process is complete.
Secure deletion is the process of rendering data irretrievable to other people, processes, or systems.
3.5.a …
3.3.d Where sensitive data is protected using methods other than strong cryptography, the assessor shall examine evidence and test the software to confirm that the protections are present in all environments where the software is designed to be executed and are implemented correctly.
3.3.e Where user input or interaction is required to configure protection methods, the assessor shall examine evidence to confirm that guidance on configuring these options is provided to stakeholders in accordance with Control Objective 12.1.
3.4.a The assessor shall examine evidence to identify the methods implemented to render non-transient sensitive data irretrievable and to confirm that sensitive data is rendered unrecoverable after the process is complete.
Secure deletion is the process of rendering data irretrievable to other people, processes, or systems.
3.5.a …
Added
p. 32
• Considerations for the software execution environment, the size of the install base, and the attack surfaces that must be mitigated are documented. Examples of such attack surfaces may include insecure user prompts or protocol stacks, or the storage of sensitive data post authorization or using insecure methods.
4.2.a The assessor shall examine evidence to confirm that one or more mitigation methods are defined for each of the threats identified in Test Requirement 4.1.a or that justification for the lack of mitigations is provided.
4.2.c Where user input or interaction can disable, remove, or bypass any such mitigations, the assessor shall examine evidence and test the software to confirm that such action requires authentication and authorization and that guidance on the risk of such actions is provided to stakeholders in accordance with Control Objective 12.1.
Other factors such as the type of access (for example, local, non-console, or remote access) and the level …
4.2.a The assessor shall examine evidence to confirm that one or more mitigation methods are defined for each of the threats identified in Test Requirement 4.1.a or that justification for the lack of mitigations is provided.
4.2.c Where user input or interaction can disable, remove, or bypass any such mitigations, the assessor shall examine evidence and test the software to confirm that such action requires authentication and authorization and that guidance on the risk of such actions is provided to stakeholders in accordance with Control Objective 12.1.
Other factors such as the type of access (for example, local, non-console, or remote access) and the level …
Added
p. 42
• Key generation method/algorithm used
• Key length Whether implemented within or outside the software, the manner in which cryptographic keys are managed is a critical part of the continued security of payment software and the sensitive data it handles.
While cryptographic key management processes are often implemented as operational procedures, the software should support secure key-management practices based on industry standards or best practices.
• All cryptographic keys that are used for providing security to critical assets (confidentiality, integrity, and authenticity) and other security services to the software have a unique purpose, and that no key is used for both encryption and authentication operations.
Industry-standard key management practices should be applied to the following:
7.2.f Where the software relies upon external files or other data elements for key material, such as for public TLS certificates, the assessor shall examine evidence to confirm that guidance on how to install such key material, including details noting …
• Key length Whether implemented within or outside the software, the manner in which cryptographic keys are managed is a critical part of the continued security of payment software and the sensitive data it handles.
While cryptographic key management processes are often implemented as operational procedures, the software should support secure key-management practices based on industry standards or best practices.
• All cryptographic keys that are used for providing security to critical assets (confidentiality, integrity, and authenticity) and other security services to the software have a unique purpose, and that no key is used for both encryption and authentication operations.
Industry-standard key management practices should be applied to the following:
7.2.f Where the software relies upon external files or other data elements for key material, such as for public TLS certificates, the assessor shall examine evidence to confirm that guidance on how to install such key material, including details noting …
Added
p. 45
7.3.c Where the software vendor relies on a previous assessment of the random number generator or source of initial entropy, the assessor shall examine evidence (such as the approval records of the previous assessment) to confirm that this scheme and specific approval include the correct areas of the software in the scope of its assessment, and that the vendor claims do not exceed the scope of the evaluation or approval of that software. For example, some cryptographic implementations approved under FIPS 140-2 or 140-3 require seeding from an external entropy source to correctly output random data.
Added
p. 47
• Methods used for generating keys directly from a password/passphrase enforce an input domain that is able to provide sufficient entropy, such that the total possible inputs are at least equal to that of the equivalent bit strength of the key being generated (for example, a 32- hex-digit input field for an AES128 key).
• Passphrases are passed through an industry-standard key- derivation function, such as PBKDF2 or bcrypt, which extends the work factor for any attempt to brute-force a passphrase value. The assessor shall confirm that a work factor of at least 10,000 is applied to any such implementation.
• Guidance is provided to stakeholders in accordance with Control Objective 12.1 that includes instructions that any passphrase used must:
• Be randomly generated itself using a valid and secure random process, and that an online random number generator must not be used for this purpose.
• Not be implemented by a single person, …
• Passphrases are passed through an industry-standard key- derivation function, such as PBKDF2 or bcrypt, which extends the work factor for any attempt to brute-force a passphrase value. The assessor shall confirm that a work factor of at least 10,000 is applied to any such implementation.
• Guidance is provided to stakeholders in accordance with Control Objective 12.1 that includes instructions that any passphrase used must:
• Be randomly generated itself using a valid and secure random process, and that an online random number generator must not be used for this purpose.
• Not be implemented by a single person, …
Added
p. 60
• Primary Account Number (PAN)
• Full track data (magnetic-stripe data or equivalent on a chip)
• PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If PAN is stored, processed, or transmitted or is otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.
A.1.1 Using information obtained in Test Requirement 1.1.a in the Core Requirements section, the assessor shall examine evidence and test the software to identify all potential storage locations for Sensitive Authentication Data, and to confirm that the software does not store such data after transaction authorization is complete. This includes storage of SAD in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).
Where Sensitive Authentication Data is stored after authorization, the assessor shall examine evidence to confirm that the software is designed explicitly for …
• Full track data (magnetic-stripe data or equivalent on a chip)
• PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If PAN is stored, processed, or transmitted or is otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.
A.1.1 Using information obtained in Test Requirement 1.1.a in the Core Requirements section, the assessor shall examine evidence and test the software to identify all potential storage locations for Sensitive Authentication Data, and to confirm that the software does not store such data after transaction authorization is complete. This includes storage of SAD in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).
Where Sensitive Authentication Data is stored after authorization, the assessor shall examine evidence to confirm that the software is designed explicitly for …
Added
p. 72
B.2.3.c The assessor shall examine evidence (including source code) to confirm that the software does not bypass or render ineffective any encryption methods provided by the payment terminal in accordance with the payment terminal vendor’s security guidance/policy.
B.2.5.b The assessor shall examine evidence (including source code) to confirm that the software does not allow sharing of clear-text account data directly with other software through its own logical interfaces.
B.2.5.b The assessor shall examine evidence (including source code) to confirm that the software does not allow sharing of clear-text account data directly with other software through its own logical interfaces.
Added
p. 76
B.2.9.a The assessor shall examine evidence (including source code) to determine whether the software supports the use of data entry prompts and/or prompt files. Where the software supports such features, the assessor shall confirm the software protects the integrity of those prompts as defined in Test Requirements B.2.9.b through B.2.9.c.
B.3.1.a The assessor shall examine evidence (including source code) to identify all locations where the software accepts input data from untrusted sources. For each instance, the assessor shall confirm that input data is required to conform to a list of expected characteristics and that all input that does not conform to the list of expected characteristics is rejected by the software or otherwise handled securely.
B.3.1.1.a The assessor shall examine evidence (including source code) to identify all terminal software functions where string values are passed as inputs, and to confirm that all strings are checked for text or data that can be …
B.3.1.a The assessor shall examine evidence (including source code) to identify all locations where the software accepts input data from untrusted sources. For each instance, the assessor shall confirm that input data is required to conform to a list of expected characteristics and that all input that does not conform to the list of expected characteristics is rejected by the software or otherwise handled securely.
B.3.1.1.a The assessor shall examine evidence (including source code) to identify all terminal software functions where string values are passed as inputs, and to confirm that all strings are checked for text or data that can be …
Added
p. 84
B.5.1 The assessor shall examine evidence to confirm that guidance on how to securely implement and operate the software for all applicable payment terminals is provided to stakeholders in accordance with Control Objective 12.1.
Added
p. 86
C.1: Web Software Components & Services C.2: Web Software Access Controls C.3: Web Software Attack Mitigation C.4: Web Software Communications Purpose and Scope This section (hereinafter referred to as the “Web Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that use Internet technologies, protocols, and languages for the purposes of initiating or supporting electronic payment transactions. This includes both traditional (monolithic) and cloud-native payment applications, APIs, web services, microservices, serverless functions, gRPC, and any other methods used to make payment functions accessible or to conduct electronic payment transactions over the Internet. Any software-based features or functions that handle requests from Internet “clients” and generate responses to initiate or support an electronic payment transaction are in scope for the requirements in this module.
Considerations Web software architectures can be extremely complex and involve features and functions that are provided by different entities and may …
Considerations Web software architectures can be extremely complex and involve features and functions that are provided by different entities and may …
Added
p. 87
C.1.1 All software components and services are documented or otherwise cataloged in a software bill of materials (SBOM).
C.1.1 The assessor shall examine evidence to confirm that information is maintained that describes all software components and services comprising the software solution, including:
• All proprietary software libraries, packages, modules, and/or code packaged in a manner that enables them to be tracked as a freestanding unit of software.
• All third-party and open-source frameworks, libraries, and code embedded in or used by the software during operation.
• All third-party software dependencies, APIs, and services called by the software during operation.
Modern software is rarely created entirely in-house and is typically composed of various bespoke code segments integrated with numerous components such as commercial and/or open-source frameworks, libraries, APIs, and services. Any part of this code may have or develop vulnerabilities over time that will require patching or mitigation.
Knowing all of the components that comprise a software …
C.1.1 The assessor shall examine evidence to confirm that information is maintained that describes all software components and services comprising the software solution, including:
• All proprietary software libraries, packages, modules, and/or code packaged in a manner that enables them to be tracked as a freestanding unit of software.
• All third-party and open-source frameworks, libraries, and code embedded in or used by the software during operation.
• All third-party software dependencies, APIs, and services called by the software during operation.
Modern software is rarely created entirely in-house and is typically composed of various bespoke code segments integrated with numerous components such as commercial and/or open-source frameworks, libraries, APIs, and services. Any part of this code may have or develop vulnerabilities over time that will require patching or mitigation.
Knowing all of the components that comprise a software …
Added
p. 88
C.1.2.a The assessor shall examine evidence to confirm that the SBOM describes all primary (top-level) components and services in use and all of their secondary transitive relationships and dependencies.
Software components and services may have many nested relationships and dependencies with other software components and services that are owned or maintained by multiple different entities. Identifying all of these different relationships can be challenging where there are many different third-party components nested in the software code.
Fortunately, many software development frameworks and compilers provide the capabilities to identify and map nested and transient dependencies. For the purposes of this standard, the SBOM is expected to identify, at a minimum, the code obtained from third parties as well as their secondary transitive component relationships and dependencies (i.e., code embedded in third-party code).
If circumstances exist that complicate or prevent the identification of secondary transitive component relationships and dependencies, then such circumstances should be documented …
Software components and services may have many nested relationships and dependencies with other software components and services that are owned or maintained by multiple different entities. Identifying all of these different relationships can be challenging where there are many different third-party components nested in the software code.
Fortunately, many software development frameworks and compilers provide the capabilities to identify and map nested and transient dependencies. For the purposes of this standard, the SBOM is expected to identify, at a minimum, the code obtained from third parties as well as their secondary transitive component relationships and dependencies (i.e., code embedded in third-party code).
If circumstances exist that complicate or prevent the identification of secondary transitive component relationships and dependencies, then such circumstances should be documented …
Added
p. 89
Examples of these types of components include, but are not limited to, database servers, web servers, application servers, runtime platform(s), authentication servers/services, "plugins", and any other components or services present in the production environment.
C.1.4 The SBOM includes sufficient information about each component or service to enable tracking each component or service across the software supply chain.
C.1.4.a The assessor shall examine evidence to confirm that information is maintained in the SBOM that describes the following for each component and service in use, including secondary component relationships and dependencies:
• The original source/supplier of the component or service.
• The name of the component or service as defined by the original supplier.
• A description of the relationship(s) between the component and service and other components/services embedded in or used by the software.
• The version of the component or service as defined by the original supplier to differentiate it from previous or other versions.
• The …
C.1.4 The SBOM includes sufficient information about each component or service to enable tracking each component or service across the software supply chain.
C.1.4.a The assessor shall examine evidence to confirm that information is maintained in the SBOM that describes the following for each component and service in use, including secondary component relationships and dependencies:
• The original source/supplier of the component or service.
• The name of the component or service as defined by the original supplier.
• A description of the relationship(s) between the component and service and other components/services embedded in or used by the software.
• The version of the component or service as defined by the original supplier to differentiate it from previous or other versions.
• The …
Added
p. 90
C.1.5 The assessor shall examine evidence to confirm that a new SBOM is created or otherwise generated for each new release of the software.
To enable tracking of vulnerabilities across different versions of a payment software, it is imperative that each version of the software has a SBOM generated that accurately reflects the components and services in use by that version.
Since many different versions of a payment software may be available (or active) at any given time and may include multiple versions of numerous third- party components and services, each version of the payment software must be tracked independently of other versions.
Failure to identify and describe the components and services unique to a given version of payment software could enable vulnerabilities to be introduced without the software provider’s knowledge if they are unaware that a vulnerable version of a software component or service is in use.
C.1.6 Vulnerabilities in third-party components and …
To enable tracking of vulnerabilities across different versions of a payment software, it is imperative that each version of the software has a SBOM generated that accurately reflects the components and services in use by that version.
Since many different versions of a payment software may be available (or active) at any given time and may include multiple versions of numerous third- party components and services, each version of the payment software must be tracked independently of other versions.
Failure to identify and describe the components and services unique to a given version of payment software could enable vulnerabilities to be introduced without the software provider’s knowledge if they are unaware that a vulnerable version of a software component or service is in use.
C.1.6 Vulnerabilities in third-party components and …
Added
p. 91
C.1.7.a Where software components and resources are fetched from external and/or third-party repositories, the assessor shall examine evidence to confirm that the authenticity of the software component is verified each time the component is fetched.
It is a common architectural design technique in modern web applications to download or “fetch” third-party components and resources (for example, files, scripts, stylesheets, packages, and libraries) that are housed on publicly available code repositories (such as public content delivery networks) at the time they are needed rather than embedding and maintaining those components and resources in local code repositories. This technique provides many benefits including the ability to automatically deploy updates to third-party components and resources without necessarily having to recompile code.
Unfortunately, there are some significant drawbacks to this approach. Third-party code repositories are heavily targeted by attackers because it enables them to potentially compromise numerous applications and entities by compromising a single package, library, …
It is a common architectural design technique in modern web applications to download or “fetch” third-party components and resources (for example, files, scripts, stylesheets, packages, and libraries) that are housed on publicly available code repositories (such as public content delivery networks) at the time they are needed rather than embedding and maintaining those components and resources in local code repositories. This technique provides many benefits including the ability to automatically deploy updates to third-party components and resources without necessarily having to recompile code.
Unfortunately, there are some significant drawbacks to this approach. Third-party code repositories are heavily targeted by attackers because it enables them to potentially compromise numerous applications and entities by compromising a single package, library, …
Added
p. 92
C.2.1 User access to sensitive functions and sensitive resources exposed through Internet accessible interfaces is authenticated.
C.2.1 Using information obtained in Test Requirements 1.2.a and 2.1.a in the Core Requirements, the assessor shall examine evidence to identify all sensitive functions and sensitive resources exposed through Internet accessible interfaces.
Writing custom authentication functions is not a trivial matter. There are numerous issues and considerations that must be factored into the design and implementation of such functions including, but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses in design and must be resistant to targeted attacks.
Given the importance of and the heavy reliance on such functions for security purposes (and those of this standard), it is recommended that entities use third-party authentication functions, modules, libraries, services, and so on, that are already widely used within the industry and have been subjected to …
C.2.1 Using information obtained in Test Requirements 1.2.a and 2.1.a in the Core Requirements, the assessor shall examine evidence to identify all sensitive functions and sensitive resources exposed through Internet accessible interfaces.
Writing custom authentication functions is not a trivial matter. There are numerous issues and considerations that must be factored into the design and implementation of such functions including, but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses in design and must be resistant to targeted attacks.
Given the importance of and the heavy reliance on such functions for security purposes (and those of this standard), it is recommended that entities use third-party authentication functions, modules, libraries, services, and so on, that are already widely used within the industry and have been subjected to …
Added
p. 93
C.2.1.1.a The assessor shall examine evidence to identify all methods implemented by the software to authenticate access to sensitive functions and sensitive resources.
Similar to developing one’s own authorization mechanisms, developing custom authentication mechanisms can be quite a complex undertaking. Much of an application’s security is dependent on the strength and robustness of its authentication and authorization mechanisms. There are numerous issues and considerations that must be factored into the design and implementation of such functions including but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses and must be able to withstand targeted attacks.
For this reason, only well-designed and well-tested mechanisms should be used. Authentication mechanisms that are provided by industry-accepted suppliers and widely adopted within the industry are generally understood to have been subjected to substantial testing and validation throughout the course of that adoption. Therefore, it is …
Similar to developing one’s own authorization mechanisms, developing custom authentication mechanisms can be quite a complex undertaking. Much of an application’s security is dependent on the strength and robustness of its authentication and authorization mechanisms. There are numerous issues and considerations that must be factored into the design and implementation of such functions including but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses and must be able to withstand targeted attacks.
For this reason, only well-designed and well-tested mechanisms should be used. Authentication mechanisms that are provided by industry-accepted suppliers and widely adopted within the industry are generally understood to have been subjected to substantial testing and validation throughout the course of that adoption. Therefore, it is …
Added
p. 94
C.2.1.2 Using information obtained in Test Requirement C.2.1.1.a, the assessor shall examine evidence to confirm that the authentication methods implemented are sufficiently strong and robust to protect authentication credentials in accordance with Control Objective 5.3 in the Core Requirements section.
Strong and robust authentication methods are those that are resistant to common attacks. Examples of such methods include, but are not limited to, multi- factor authentication and/or authentication methods that employ strong cryptography (such as digital signatures or certificates).
C.2.1.3 Authentication decisions are enforced within a secure area of the software.
C.2.1.3.a The assessor shall examine evidence to identify where within the software architecture authentication decisions are enforced.
Like authorization decisions, authentication decisions must be enforced within a secure area of the software. Authentication methods should never rely solely on scripts or data obtained from the client or browser. With that said, it is permissible to use client-side scripts and data when combined with …
Strong and robust authentication methods are those that are resistant to common attacks. Examples of such methods include, but are not limited to, multi- factor authentication and/or authentication methods that employ strong cryptography (such as digital signatures or certificates).
C.2.1.3 Authentication decisions are enforced within a secure area of the software.
C.2.1.3.a The assessor shall examine evidence to identify where within the software architecture authentication decisions are enforced.
Like authorization decisions, authentication decisions must be enforced within a secure area of the software. Authentication methods should never rely solely on scripts or data obtained from the client or browser. With that said, it is permissible to use client-side scripts and data when combined with …
Added
p. 95
• Is implemented correctly;
• Is appropriate for the types of users expected to use the interface; and
• Does not expose known vulnerabilities.
One key difference between traditional “monolithic” web applications and modern web applications is the degree to which an application is exposed (or potentially exposed) to the Internet. Where monolithic web applications tend to keep interactions between software components confined to a single security context (such as an internal or isolated system or network), modern web applications are typically segmented into many distinct and/or independent software functions that are then exposed to the Internet through APIs so that they may be accessible to other application or users, regardless of where they may reside.
Unfortunately, each Internet accessible interface (and the functions and resources it provides) is a potential attack vector. To mitigate the risks associated with exposing so many software functions to the Internet, each interface must implement access control mechanisms …
• Is appropriate for the types of users expected to use the interface; and
• Does not expose known vulnerabilities.
One key difference between traditional “monolithic” web applications and modern web applications is the degree to which an application is exposed (or potentially exposed) to the Internet. Where monolithic web applications tend to keep interactions between software components confined to a single security context (such as an internal or isolated system or network), modern web applications are typically segmented into many distinct and/or independent software functions that are then exposed to the Internet through APIs so that they may be accessible to other application or users, regardless of where they may reside.
Unfortunately, each Internet accessible interface (and the functions and resources it provides) is a potential attack vector. To mitigate the risks associated with exposing so many software functions to the Internet, each interface must implement access control mechanisms …
Added
p. 96
C.2.3.1.a Using information obtained in Test Requirement C.2.3, the assessor shall examine evidence to determine how the software controls access to individual functions and resources exposed (or potentially exposed) through Internet accessible interfaces.
To support the fine-grained access control needs of modern web application architectures and to ensure that users are only able to access the software functions and resources that they are authorized to use, the software must support the ability to define and enforce access control rules at varying “levels” within the interface’s hierarchy, including at the individual function and resource level(s).
Depending upon the types of functions and resources exposed in a given software interface, the methods used to authorize access at the interface- level may not be appropriate to provide access to individual functions and resources exposed through such interfaces.
For example, API keys are often used to authorize access to an API for a particular entity (also called …
To support the fine-grained access control needs of modern web application architectures and to ensure that users are only able to access the software functions and resources that they are authorized to use, the software must support the ability to define and enforce access control rules at varying “levels” within the interface’s hierarchy, including at the individual function and resource level(s).
Depending upon the types of functions and resources exposed in a given software interface, the methods used to authorize access at the interface- level may not be appropriate to provide access to individual functions and resources exposed through such interfaces.
For example, API keys are often used to authorize access to an API for a particular entity (also called …
Added
p. 97
Where fined-grained access control is necessary, the methods implemented to control access to all software functions and resources exposed through Internet accessible interfaces must be appropriate for the types of authorization(s) required (for example, user versus entity) and the functions and resources involved (sensitive versus non-sensitive functions and resources).
Wherever end users are required to configure the access control authorizations and permissions for individual functions and resources exposed through Internet accessible interfaces, the software vendor must provide guidance (or otherwise make guidance accessible) to users and other stakeholders to explain how to configure such permissions and to alert them to important security considerations when configuring available options and parameters.
C.2.3.1.e The assessor shall examine evidence and test the software to confirm that the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet accessible interfaces require users to be explicitly authorized prior to being granted such …
Wherever end users are required to configure the access control authorizations and permissions for individual functions and resources exposed through Internet accessible interfaces, the software vendor must provide guidance (or otherwise make guidance accessible) to users and other stakeholders to explain how to configure such permissions and to alert them to important security considerations when configuring available options and parameters.
C.2.3.1.e The assessor shall examine evidence and test the software to confirm that the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet accessible interfaces require users to be explicitly authorized prior to being granted such …
Added
p. 98
C.2.3.3.a The assessor shall examine evidence to identify where in the software architecture authorization and access control decisions are enforced.
Payment software should never rely on unknown or insecure services and features for security-related purposes. Secure areas or systems are those within the software architecture where the integrity of available services and data is ensured, and therefore can be relied upon by the software.
Historically, web application architectures consisted of “client-side” components and “server-side” components. Client-side functions are those typically performed by a common web browser. Server-side functions are those typically performed by web, application, and/or database servers. Given the open nature and design of most common web browsers and the fact that they are maintained by end users, server-side functions are typically considered to be more secure given a software/service provider’s ability to control and secure those aspects of the software architecture.
Modern web software architectures, however, have become increasingly complex with …
Payment software should never rely on unknown or insecure services and features for security-related purposes. Secure areas or systems are those within the software architecture where the integrity of available services and data is ensured, and therefore can be relied upon by the software.
Historically, web application architectures consisted of “client-side” components and “server-side” components. Client-side functions are those typically performed by a common web browser. Server-side functions are those typically performed by web, application, and/or database servers. Given the open nature and design of most common web browsers and the fact that they are maintained by end users, server-side functions are typically considered to be more secure given a software/service provider’s ability to control and secure those aspects of the software architecture.
Modern web software architectures, however, have become increasingly complex with …
Added
p. 99
C.3.1 The software enforces or otherwise supports the use of the latest HTTP Security Headers to protect Internet accessible interfaces from attacks.
C.3.1.a The assessor shall examine evidence to confirm the software supports the use of the latest HTTP Security Headers, and to determine the options available and how such settings are configured.
HTTP Security Headers are a set of security-related configuration options available on most common web servers. Examples include the X-Frame-Options header, the HTTP-Strict-Transport-Security header, and the Content-Security-Policy header.
The use of these options can protect against a variety of different types of attacks including cross- site scripting, clickjacking, and cross-site request forgery attacks.
While support for specific HTTP Security Headers may differ depending on the underlying platform or software technology, these options are widely available and should be enabled and configured to the most secure configuration feasible for a given implementation.
C.3.1.b Where HTTP Security Headers are configured and controlled by the …
C.3.1.a The assessor shall examine evidence to confirm the software supports the use of the latest HTTP Security Headers, and to determine the options available and how such settings are configured.
HTTP Security Headers are a set of security-related configuration options available on most common web servers. Examples include the X-Frame-Options header, the HTTP-Strict-Transport-Security header, and the Content-Security-Policy header.
The use of these options can protect against a variety of different types of attacks including cross- site scripting, clickjacking, and cross-site request forgery attacks.
While support for specific HTTP Security Headers may differ depending on the underlying platform or software technology, these options are widely available and should be enabled and configured to the most secure configuration feasible for a given implementation.
C.3.1.b Where HTTP Security Headers are configured and controlled by the …
Added
p. 100
Two of the most common types of attacks, Injection (SQL, XML, Code, String, and so on) and Cross-Site Scripting (XSS), exploit the software’s trust in input data provided by untrusted sources to execute malicious code or to force the software to behave in unintended ways.
To protect against these and other types of related attacks, input data must never be trusted and software security controls must be implemented to ensure input data is validated, rendered safe, or otherwise handled in a manner that mitigates the likelihood and/or impacts of executing malicious input data.
C.3.2.d Where such attacks are acknowledged and using information obtained in Test Requirement 4.2.a in the Core Requirements section, the assessor shall examine evidence to confirm that software security controls are defined and implemented to mitigate attacks that attempt to exploit vulnerabilities through the manipulation of input data.
C.3.2.e Where the implementation of software security controls is configurable or otherwise …
To protect against these and other types of related attacks, input data must never be trusted and software security controls must be implemented to ensure input data is validated, rendered safe, or otherwise handled in a manner that mitigates the likelihood and/or impacts of executing malicious input data.
C.3.2.d Where such attacks are acknowledged and using information obtained in Test Requirement 4.2.a in the Core Requirements section, the assessor shall examine evidence to confirm that software security controls are defined and implemented to mitigate attacks that attempt to exploit vulnerabilities through the manipulation of input data.
C.3.2.e Where the implementation of software security controls is configurable or otherwise …
Added
p. 101
Other methods, such as parameterization and output escaping, are better suited as primary defense mechanisms. While the type and complexity of the input data and how the data is expected to be used often dictate the methods that are most appropriate for a given input, parameterization should be used where possible. Output escaping can be used as an alternative if parameterization is not feasible. The use of input validation may be used as a secondary defense, where appropriate, to provide defense-in- depth.
As is the case with other critical functions such as authentication and authorization, input protection methods should leverage industry-accepted third- party mechanisms where possible. If the use of such mechanisms is not feasible, then custom methods may be used if they are designed and implemented in accordance with applicable industry standards or best practices.
C.3.2.1.c The assessor shall examine evidence and test the software to confirm that the implemented methods:
• …
As is the case with other critical functions such as authentication and authorization, input protection methods should leverage industry-accepted third- party mechanisms where possible. If the use of such mechanisms is not feasible, then custom methods may be used if they are designed and implemented in accordance with applicable industry standards or best practices.
C.3.2.1.c The assessor shall examine evidence and test the software to confirm that the implemented methods:
• …
Added
p. 102
Where certain parser/interpreter features cannot be configured securely, the assessor shall examine evidence to confirm that other methods are implemented to mitigate the lack of secure settings and to further protect against the execution of malicious commands.
The specific settings that must be disabled/enabled to protect against certain attacks depends on the parsers and interpreters. For more information, refer to available security guidance on the specific parsers/interpreters in use.
Where certain features of the parsers or interpreters cannot be configured with the most secure settings possible, then the processing of untrusted input data should use techniques such as sandboxing to prevent (or otherwise mitigate the impacts of) malicious code execution.
C.3.3 Software security controls are implemented to protect software interfaces from resource starvation attacks.
C.3.3.a Using information obtained in Test Requirements C.2.1.a and C.2.2, the assessor shall examine evidence to identify all Internet accessible interfaces and the functions and resources exposed (or potentially exposed) …
The specific settings that must be disabled/enabled to protect against certain attacks depends on the parsers and interpreters. For more information, refer to available security guidance on the specific parsers/interpreters in use.
Where certain features of the parsers or interpreters cannot be configured with the most secure settings possible, then the processing of untrusted input data should use techniques such as sandboxing to prevent (or otherwise mitigate the impacts of) malicious code execution.
C.3.3 Software security controls are implemented to protect software interfaces from resource starvation attacks.
C.3.3.a Using information obtained in Test Requirements C.2.1.a and C.2.2, the assessor shall examine evidence to identify all Internet accessible interfaces and the functions and resources exposed (or potentially exposed) …
Added
p. 102
C.3.3.c The assessor shall examine evidence to confirm that the software security controls implemented to mitigate resource starvation and other similar attacks on Internet accessible interfaces are designed and implemented in accordance with applicable industry standards and best practices.
Added
p. 103
Examples of methods used to mitigate the risk of such attacks include limiting the rate on the number of requests that can be submitted within a given time period (rate limiting). Additional methods to prevent such attacks may include defining other limits such as the number of users and/or systems that can submit requests, mutually authenticating those users and systems, or using CAPTCHA or other anti- automation techniques that can prevent large volumes of requests being submitted to software interfaces within a short time period.
For SaaS or other similar environments, appropriate network-based controls may also be used to address these types of attacks.
C.3.4 Software security controls are implemented to protect Internet accessible interfaces from malicious file content.
C.3.4.a Using information obtained in Test Requirement C.2.1.a, the assessor shall examine evidence to identify all Internet accessible interfaces that accept file uploads and the file types permitted.
File uploads can be used to provide …
For SaaS or other similar environments, appropriate network-based controls may also be used to address these types of attacks.
C.3.4 Software security controls are implemented to protect Internet accessible interfaces from malicious file content.
C.3.4.a Using information obtained in Test Requirement C.2.1.a, the assessor shall examine evidence to identify all Internet accessible interfaces that accept file uploads and the file types permitted.
File uploads can be used to provide …
Added
p. 104
Many file formats allow for the embedding of other files or data which can be ‘expanded’ out when parsing the source file. In some scenarios this can be used to gain privileges or exploit vulnerabilities on the host platform which would not otherwise be possible. Uploaded files need to be managed in ways that prevent the exploitation of file parsing or expansion attacks.
To prevent the exploitation of file upload systems, any files that are uploaded cannot be assigned writable or executable privileges. Files which are required to be writable need to be copied across to a separate file managed only by the software to prevent a malicious user from exploiting the file between upload and use.
For defense-in-depth, some software development languages and frameworks include the ability to make calls to anti-malware systems to scan these files upon upload. For more information, refer to relevant third-party documentation.
File and file type parsers …
To prevent the exploitation of file upload systems, any files that are uploaded cannot be assigned writable or executable privileges. Files which are required to be writable need to be copied across to a separate file managed only by the software to prevent a malicious user from exploiting the file between upload and use.
For defense-in-depth, some software development languages and frameworks include the ability to make calls to anti-malware systems to scan these files upon upload. For more information, refer to relevant third-party documentation.
File and file type parsers …
Added
p. 105
C.3.5.a Using information obtained in Test Requirements C.2.1.a and C.2.2, the assessor shall examine evidence to identify all software functions exposed through Internet accessible interfaces that accept and process data objects as inputs.
Some software APIs accept serialized data objects (for example, arrays, cookies, tokens, and so on) to be passed from other systems. However, without appropriate methods in place to restrict object deserialization and creation, malicious individuals may be able to use these APIs to launch denial-of- service attacks, compromise access control mechanisms, or inject and execute malicious code on underlying systems.
There are numerous methods to protect against serialization (and deserialization) attacks. Some programming languages, libraries, and APIs provide features and functions that are resistant to serialization attacks. Other methods include using deserialization mechanisms that only support pure data formats like JSON or XML, limiting data types allowed during object creation, encrypting communications, and authenticating API clients.
Appropriate methods to protect …
Some software APIs accept serialized data objects (for example, arrays, cookies, tokens, and so on) to be passed from other systems. However, without appropriate methods in place to restrict object deserialization and creation, malicious individuals may be able to use these APIs to launch denial-of- service attacks, compromise access control mechanisms, or inject and execute malicious code on underlying systems.
There are numerous methods to protect against serialization (and deserialization) attacks. Some programming languages, libraries, and APIs provide features and functions that are resistant to serialization attacks. Other methods include using deserialization mechanisms that only support pure data formats like JSON or XML, limiting data types allowed during object creation, encrypting communications, and authenticating API clients.
Appropriate methods to protect …
Added
p. 106
Some file-parsing mechanisms are inherently susceptible to certain vulnerabilities. For example, XML parsers are often vulnerable to External Entity attacks. Similarly, JSON parsers are vulnerable to attacks where insecure commands, such as eval(), can enable the execution of malicious code.
To mitigate attacks that attempt to exploit vulnerabilities in file-parsing mechanisms, it may be necessary for entities to implement additional software security controls. Examples of such controls include, but are not limited to, configuring file-parsing mechanisms to use the most restrictive configuration feasible, avoiding or escaping certain commands that are known issues for file-parsing mechanisms, or isolating and executing file-parsing commands in a sandbox. The methods used to further mitigate such attacks should consider the specific parsers and interpreters in use and be implemented in a manner appropriate for each parser and interpreter.
C.3.5.h Where the software security controls implemented to protect against hostile object creation and data tampering are user configurable …
To mitigate attacks that attempt to exploit vulnerabilities in file-parsing mechanisms, it may be necessary for entities to implement additional software security controls. Examples of such controls include, but are not limited to, configuring file-parsing mechanisms to use the most restrictive configuration feasible, avoiding or escaping certain commands that are known issues for file-parsing mechanisms, or isolating and executing file-parsing commands in a sandbox. The methods used to further mitigate such attacks should consider the specific parsers and interpreters in use and be implemented in a manner appropriate for each parser and interpreter.
C.3.5.h Where the software security controls implemented to protect against hostile object creation and data tampering are user configurable …
Added
p. 108
C.4.1 Sensitive data transmissions are encrypted in accordance with Control Objectives 6.2 and 6.3.
C.4.1.a Using information obtained in Test Requirement 6.2.a, the assessor shall examine evidence to determine how communications are handled by the software, including those between separate systems in the overall software architecture.
The types of data which may be considered sensitive may vary across different implementations. See Control Objective 1.1 for more information on identifying sensitive data.
It is therefore important that any connection that transmits sensitive data is encrypted using strong cryptography. Common methods for achieving this will include the use of TLS using appropriate cipher suites.
Although connections that do not transmit sensitive data do not explicitly require the use of encryption, it is noted that the use of strong cryptography to secure all connections is considered a best practice and should be implemented for all communications unless legitimate business or technological constraints exist that render such an …
C.4.1.a Using information obtained in Test Requirement 6.2.a, the assessor shall examine evidence to determine how communications are handled by the software, including those between separate systems in the overall software architecture.
The types of data which may be considered sensitive may vary across different implementations. See Control Objective 1.1 for more information on identifying sensitive data.
It is therefore important that any connection that transmits sensitive data is encrypted using strong cryptography. Common methods for achieving this will include the use of TLS using appropriate cipher suites.
Although connections that do not transmit sensitive data do not explicitly require the use of encryption, it is noted that the use of strong cryptography to secure all connections is considered a best practice and should be implemented for all communications unless legitimate business or technological constraints exist that render such an …
Added
p. 109
Where sensitive data is transmitted between systems operating within different security contexts and/or different environments, it is important that such communications be restricted to an explicitly approved list of systems, and that the systems involved be mutually authenticated such that attempts to intercept or compromise such communications are appropriately mitigated.
Where the software provider controls the configuration of such communications, mutual authentication must be enforced. Otherwise, the software provider must provide features to support the mutual authentication of disparate systems so that an implementing entity may configure such features accordingly.
C.4.1.d Where internally generated or self-signed certificates are used for securing sensitive data transmissions, the assessor shall examine evidence to confirm that:
• The use of internally generated or self-signed certificates is reasonable and justified.
• The software is configured to accept the minimum feasible number of internally generated or self-signed certificates.
Many organizations that choose to use internally generated and/or self-signed certificates do so …
Where the software provider controls the configuration of such communications, mutual authentication must be enforced. Otherwise, the software provider must provide features to support the mutual authentication of disparate systems so that an implementing entity may configure such features accordingly.
C.4.1.d Where internally generated or self-signed certificates are used for securing sensitive data transmissions, the assessor shall examine evidence to confirm that:
• The use of internally generated or self-signed certificates is reasonable and justified.
• The software is configured to accept the minimum feasible number of internally generated or self-signed certificates.
Many organizations that choose to use internally generated and/or self-signed certificates do so …
Modified
p. 1
Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.1
Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.2
Modified
p. 5 → 6
The PCI Secure Software Standard is intended for use as part of the PCI Software Security Framework. Software vendors wishing to validate their payment software under the PCI Software Security Framework would do so to this PCI Secure Software Standard.
The PCI Secure Software Standard is intended for use as part of the PCI Software Security Framework (SSF). Entities wishing to have their payment software validated under the PCI SSF would do so to this standard.
Modified
p. 5 → 6
Terminology A list of applicable terms and definitions is provided in the PCI Software Security Framework Glossary of Terms, Abbreviations, and Acronyms, available in the PCI SSC Document Library: https://www.pcisecuritystandards.or/document_library.
Terminology A list of applicable terms and definitions is provided in the PCI Software Security Framework Glossary of Terms, Abbreviations, and Acronyms, available in the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library/.
Modified
p. 5 → 6
Additionally, definitions for general PCI terminology is provided in the PCI Glossary on the PCI SSC website at: https://www.pcisecuritystandards.org/pci_security/glossary.
Additionally, definitions for general PCI terminology is provided in the PCI Glossary on the PCI SSC website at: https://www.pcisecuritystandards.org/pci_security/glossary/.
Removed
p. 6
Coverage of all payment software functionality, including but not limited to: a. End-to-end payment functionality, b. Inputs and outputs, c. Handling of error conditions, d. Interfaces and connections to other files, systems, and/or software or software components, e. All data flows, and f. All security mechanisms, controls, and countermeasures (e.g., authentication, authorization, validation, parameterization, segmentation, logging, etc.).
Coverage of guidance the software vendor is expected to provide to its customers to ensure: a. Customers are aware how to implement and operate the payment software securely; b. Customers are provided guidance on configuration options of the execution environment and system components; c. Customers are provided guidance on how to implement security updates; and d. Customers and other stakeholders are aware how and where to report security issues.
Note that the software vendor may be expected to provide such guidance even when the specific setting: a. Cannot be controlled by the payment software once …
Coverage of guidance the software vendor is expected to provide to its customers to ensure: a. Customers are aware how to implement and operate the payment software securely; b. Customers are provided guidance on configuration options of the execution environment and system components; c. Customers are provided guidance on how to implement security updates; and d. Customers and other stakeholders are aware how and where to report security issues.
Note that the software vendor may be expected to provide such guidance even when the specific setting: a. Cannot be controlled by the payment software once …
Modified
p. 6 → 9
Processes used by the software vendor to identify and support software security controls.
• Processes used by the software vendor, provider, or developer to identify and support software security controls.
Modified
p. 6 → 10
− Features and functions of a supported platform or the execution environment relied upon by the payment software for security purposes.
Modified
p. 6 → 10
• Any other software, software functionality, or services necessary for a full implementation of the payment software, including but not limited to:
Removed
p. 7
For this approach to be successful, software vendors must possess a robust risk-management practice as an integral part of their “business as usual” operational processes. The specific software security controls needed to meet certain requirements in this standard
•for example, additional data elements identified by the software vendor as sensitive data1
•will depend on the software vendor’s risk-management priorities and processes. While this approach provides the software vendor with flexibility to implement software security controls based on identified risk, the software vendor must be able to demonstrate how the implemented controls are supported by the results of their risk-management practices. Without a robust risk-management practice in place and evidence available to support risk-based decision making, adherence to the PCI Secure Software Requirements may be difficult to validate.
Where a PCI Secure Software Requirement does not define a specific level of rigor or frequency for periodic or recurring activities
•for example, the maximum period in …
•for example, additional data elements identified by the software vendor as sensitive data1
•will depend on the software vendor’s risk-management priorities and processes. While this approach provides the software vendor with flexibility to implement software security controls based on identified risk, the software vendor must be able to demonstrate how the implemented controls are supported by the results of their risk-management practices. Without a robust risk-management practice in place and evidence available to support risk-based decision making, adherence to the PCI Secure Software Requirements may be difficult to validate.
Where a PCI Secure Software Requirement does not define a specific level of rigor or frequency for periodic or recurring activities
•for example, the maximum period in …
Removed
p. 8
Within each of the sections defined above, the PCI Secure Software Requirements are further subdivided into the following components:
Control Objectives
• The security outcomes that must be achieved. While all control objectives must be met to be validated to this PCI Secure Software Standard, software vendors may define the specific controls, tools, methods, and techniques they use to meet each control objective.
Test Requirements
• The validation activities to be performed by an assessor to determine whether a specific control objective has been met. If an assessor determines that alternative testing methods are appropriate to validate a particular control objective, they must justify and document their testing approach as described in the Assessment Procedures and Test Requirements section.
Guidance
• Additional information to help software vendors and assessors further understand the intent of each control objective and how it could be met. The guidance may include best practices to be considered as well as examples …
Control Objectives
• The security outcomes that must be achieved. While all control objectives must be met to be validated to this PCI Secure Software Standard, software vendors may define the specific controls, tools, methods, and techniques they use to meet each control objective.
Test Requirements
• The validation activities to be performed by an assessor to determine whether a specific control objective has been met. If an assessor determines that alternative testing methods are appropriate to validate a particular control objective, they must justify and document their testing approach as described in the Assessment Procedures and Test Requirements section.
Guidance
• Additional information to help software vendors and assessors further understand the intent of each control objective and how it could be met. The guidance may include best practices to be considered as well as examples …
Modified
p. 8 → 10
• Core Requirements (“Core Module”): General security requirements that apply to all types of payment software regardless of software function, design, or underlying technology.
Modified
p. 8 → 10
• Account Data Protection
• Account Data Protection Requirements (“Account Data Protection Module”): Additional security requirements for payment software that store, process, or transmit account data.
Modified
p. 8 → 10
• Terminal Software
• Terminal Software Requirements (“Terminal Software Module”): Additional security requirements for payment software specifically designed for deployment and operation on PCI-approved POI devices.
Removed
p. 9
Examine: The assessor critically evaluates data evidence. Common examples include software design and architecture documents (electronic or physical), source code, configuration and metadata files, and security-testing results.
Interview: The assessor converses with individual personnel. The purposes of such interviews may include determining how an activity is performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of applicable policies, processes, responsibilities, or concepts.
Test: The assessor evaluates the software code or the operation of the software using a variety of security-testing tools and techniques. At a minimum, assessors must use the appropriate combination of static and dynamic analyses to validate each control objective. Examples of such tools and techniques might include the use of automated static analysis security testing (SAST), dynamic analysis security testing (DAST), interactive application security testing (IAST), and software composition analysis (SCA) tools⎯as well as manual techniques such as manual code reviews and …
Interview: The assessor converses with individual personnel. The purposes of such interviews may include determining how an activity is performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of applicable policies, processes, responsibilities, or concepts.
Test: The assessor evaluates the software code or the operation of the software using a variety of security-testing tools and techniques. At a minimum, assessors must use the appropriate combination of static and dynamic analyses to validate each control objective. Examples of such tools and techniques might include the use of automated static analysis security testing (SAST), dynamic analysis security testing (DAST), interactive application security testing (IAST), and software composition analysis (SCA) tools⎯as well as manual techniques such as manual code reviews and …
Modified
p. 9 → 13
How the evidence provided by the third-party supports the same level of rigor as testing performed by the assessor, and How the assessor verified the evidence provided by the third-party as being appropriate for the assessor to rely on the test results.
• How the evidence provided by the third-party supports the same level of rigor as testing performed by the assessor, and
Removed
p. 10
Where appropriate, the assessor may utilize sampling as part of the testing process. This may include choosing representative areas of source code to examine, or a representative sample of software vendor personnel to interview. Samples must be a representative selection of the people, processes, and technologies covered by the PCI Secure Software assessment. The sample size must be sufficiently large to provide the assessor with assurance that the sample accurately reflects the larger population and that controls are implemented as expected.
Use of a Test Platform To facilitate testing software in accordance with the assessment procedures contained in this standard, it may be necessary for the software vendor to provide a test platform. A test platform is considered to be special test functionality that is either separate or absent from production- level code. The test platform must rely on as much underlying intended production-level functionality as possible. The test platform is …
Use of a Test Platform To facilitate testing software in accordance with the assessment procedures contained in this standard, it may be necessary for the software vendor to provide a test platform. A test platform is considered to be special test functionality that is either separate or absent from production- level code. The test platform must rely on as much underlying intended production-level functionality as possible. The test platform is …
Modified
p. 10 → 13
In all instances where the assessor’s findings are based on a representative sample rather than the complete set of applicable items, the assessor should explicitly note this fact, detail the items chosen as samples for the testing, and provide a justification of the sampling methodology used.
In instances where the assessor’s findings are based on a representative sample rather than the complete set of applicable items, the assessor must explicitly note this fact in the ROV, detail the items chosen as samples for the testing, and provide references to the applicable sections of the assessor’s sampling methodology provided with the ROV. Where the assessor selects samples that do not align with the assessor’s documented sampling methodology, the assessor must provide justification in the ROV for each …
Removed
p. 11
1.1.b For each item of sensitive data, the assessor shall examine vendor evidence to confirm that evidence describes where this data is stored, and the applicable security controls implemented to protect the data. This includes in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).
1.1.c The assessor shall examine vendor evidence and test the software to identify where the implementation enforces storage within a specific location or form factor (such as with an embedded system that is only capable of local storage). The assessor shall confirm that the data for all of these is supported by the vendor evidence.
1.1.c The assessor shall examine vendor evidence and test the software to identify where the implementation enforces storage within a specific location or form factor (such as with an embedded system that is only capable of local storage). The assessor shall confirm that the data for all of these is supported by the vendor evidence.
Modified
p. 11 → 15
1.1.a The assessor shall examine vendor evidence to confirm that it details all sensitive data that is stored, processed, and/or transmitted by the software. At a minimum, this shall include all payment data; authentication credentials; cryptographic keys and related data (such as IVs and seed data for random number generators); and system configuration data (such as registry entries, platform environment variables, prompts for plaintext data in software allowing for the entry of PIN data, or configuration scripts).
1.1.a The assessor shall examine evidence to confirm that information is maintained that details all sensitive data that is stored, processed, and/or transmitted by the software. At a minimum, this shall include all payment data; authentication credentials; cryptographic keys and related data (such as IVs and seed data for random number generators); and system configuration data (such as registry entries, platform environment variables, prompts for plaintext data in software allowing for the entry of PIN data, or configuration scripts).
Modified
p. 11 → 15
Software security controls are designed and implemented to protect the confidentiality or integrity of critical assets. To make sure these controls are effective and appropriate, the software vendor should identify all sensitive data the software collects, stores, processes, or transmits, as well as all sensitive functions and resources it either provides or uses.
Software security controls are designed and implemented to protect the confidentiality and/or integrity of critical assets. To make sure these controls are effective and appropriate, the software vendor should identify all sensitive data the software collects, stores, processes, or transmits, as well as all sensitive functions and resources it either provides or uses.
Removed
p. 12
Note: The assessor may require and rely on assistance from the software vendor to complete this test requirement (such as through access to a dedicated test environment). Any such specific assistance must be documented by the assessor.
1.1.e The assessor shall examine vendor evidence and test the software to identify the transaction types and/or card data elements that are supported by the software. The assessor shall confirm that the data for all of these is supported by the vendor evidence.
1.1.f The assessor shall examine vendor evidence and test the software to identify the cryptographic implementations that are supported by the software, including (but not limited to) cryptography used for storage, transport, and authentication. The assessor shall confirm that the cryptographic data for all of these implementations is supported by the vendor evidence, and that the evidence describes whether these are implemented by the software itself, through third-party software, or as functions …
1.1.e The assessor shall examine vendor evidence and test the software to identify the transaction types and/or card data elements that are supported by the software. The assessor shall confirm that the data for all of these is supported by the vendor evidence.
1.1.f The assessor shall examine vendor evidence and test the software to identify the cryptographic implementations that are supported by the software, including (but not limited to) cryptography used for storage, transport, and authentication. The assessor shall confirm that the cryptographic data for all of these implementations is supported by the vendor evidence, and that the evidence describes whether these are implemented by the software itself, through third-party software, or as functions …
Modified
p. 12 → 16
1.1.g The assessor shall examine vendor evidence and test the software to identify any accounts or authentication credentials supported by the software, including both default and user created accounts. The assessor shall confirm that these accounts and credentials are supported by the vendor evidence.
1.1.g The assessor shall examine evidence and test the software to identify the accounts and authentication credentials supported by the software (including both default and user created accounts) and to confirm that these accounts and credentials are supported by the evidence examined in Test Requirements 1.1.a through 1.1.c.
Modified
p. 12 → 16
1.1.h The assessor shall examine vendor evidence and test the software to identify any configuration options provided by the software that can impact sensitive data, including through separate files or scripts, or internal functions, menus and options provided by the software. The assessor shall confirm that these are supported by the vendor evidence.
1.1.h The assessor shall examine evidence and test the software to identify the configuration options provided by the software that can impact sensitive data (including those provided through separate files or scripts, internal functions, or menus and options), and to confirm that these are supported by the evidence examined in Test Requirements 1.1.a through 1.1.c.
Removed
p. 13
1.2.b For each of the sensitive functions and sensitive resources listed, the assessor shall examine vendor evidence to confirm that vendor evidence clearly describes how and where the sensitive data associated with these functions and resources is stored. This includes in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media). The assessor shall confirm that this information is supported by the information provided in Test Requirement 1.1.a.
1.2.d The assessor shall examine vendor evidence and test the software to confirm that the sensitive functions and sensitive resources provided or used by the software are supported by the vendor evidence.
1.2.d The assessor shall examine vendor evidence and test the software to confirm that the sensitive functions and sensitive resources provided or used by the software are supported by the vendor evidence.
Modified
p. 13 → 16
1.2.a The assessor shall examine vendor evidence to confirm that it details all sensitive functions and sensitive resources provided or used by the software. At a minimum, this shall include all functions that are designed to store, process, or transmit sensitive data, and those services, configuration files, or other information necessary for the normal and secure operation of those functions.
1.2.a The assessor shall examine evidence to confirm that information is maintained that details all sensitive functions and sensitive resources provided or used by the software. At a minimum, this shall include all functions that are designed to store, process, or transmit sensitive data and those services, configuration files, or other information necessary for the normal and secure operation of those functions.
Modified
p. 13 → 17
1.2.c Where the sensitive functions or sensitive resources are provided by third-party software or systems, the assessor shall examine third-party software or system evidence and test the software to confirm that the vendor software is correctly following the guidance for this third-party software.
1.2.c Where the sensitive functions or sensitive resources are provided by third-party software or systems, the assessor shall examine evidence and test the software to confirm that the software correctly follows available guidance for the third-party software.
Removed
p. 14
• The vendor defines classification criteria for identifying critical assets.
Modified
p. 14 → 17
• Vendor classification criteria identifies the confidentiality, integrity, and resiliency requirements for each critical asset.
• The software vendor defines criteria for classifying critical assets in accordance with the confidentiality, integrity, and resiliency requirements for each critical asset.
Modified
p. 14 → 17
• An inventory of all critical assets with appropriate classifications is defined.
• An inventory of all critical assets with appropriate classifications is maintained.
Modified
p. 15 → 18
2.1.a The assessor shall examine vendor evidence and test the software to identify any software APIs or other interfaces that are provided or exposed by default upon installation, initialization, or first use. For each of these functions, the assessor shall confirm that the vendor has documented and justified its use as part of the software architecture. Testing shall include methods to reveal any exposed functionality of the software (such as scanning for listening services where applicable).
2.1.a The assessor shall examine evidence and test the software to identify any software APIs or other interfaces that are provided or exposed by default upon installation, initialization, or first use. For each of these interfaces, the assessor shall confirm that the vendor has documented and justified its use as part of the software architecture. Testing shall include methods to reveal any exposed interfaces or other software functionality (such as scanning for listening services where applicable).
Modified
p. 15 → 18
Note: This includes functions which are auto-enabled as required during operation of the software.
Note: This includes functions that are auto-enabled as required during operation of the software.
Modified
p. 15 → 18
Software often contains functionality (e.g., web services, administrative interface, application heartbeat, etc.) that is optional and is generally unused by many users. This functionality does not receive the same attention as standard or essential software functions and services, and often contains security weaknesses that can be exploited by malicious users to bypass security controls.
Software often contains functionality (for example, web services, administrative interface, application heartbeat, etc.) that is optional and is generally unused by many users. This functionality typically does not receive the same attention as standard or essential software functions and services, and often contains security weaknesses that can be exploited by malicious users to bypass security controls.
Modified
p. 15 → 18
To facilitate secure deployment, the software’s default configuration should only expose secure functionality that has been reviewed, justified, and approved. This should include the default configuration for all software APIs, protocols, daemons, listeners, components, etc.
To ensure a secure software deployment, the software’s default configuration should only expose functionality that has been reviewed, justified, and approved. This should include the default configuration for all software APIs, protocols, daemons, listeners, components, etc.
Modified
p. 15 → 18
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, etc.).
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (for example, NIST, ENISA, etc.).
Modified
p. 15 → 18
2.1.b The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for authentication. If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper authentication remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.
2.1.b The assessor shall test the software to determine whether any of the interfaces identified in Test Requirement 2.1.a rely on external resources for authentication. Where such resources are relied upon, the assessor shall examine evidence to confirm that methods are implemented to ensure that proper authentication remains in place and that these methods are included in the assessment of other applicable requirements in this standard.
Modified
p. 15 → 18
2.1.c The assessor shall test the software to determine whether any of the functions identified in Test Requirement 2.1.a rely on external resources for the protection of sensitive data during transmission. If such resources are relied upon, the assessor shall examine vendor evidence to identify what methods are required to ensure proper protection remains in place and shall confirm that these methods are included in the assessment of all other requirements of this standard.
2.1.c The assessor shall test the software to determine whether any of the interfaces identified in Test Requirement 2.1.a rely on external resources for the protection of sensitive data during transmission. Where such resources are relied upon, the assessor shall examine evidence to confirm that methods are implemented to ensure proper protection remains in place and that these methods are included in the assessment of other applicable requirements in this standard.
Removed
p. 16
2.1.f The assessor shall examine vendor evidence and test the software to confirm available functionality matches what is described in vendor documentation. Testing shall include methods to reveal any exposed functionality of the software (such as scanning for listening services where applicable).
Modified
p. 16 → 19
2.1.e Where vulnerabilities in exposed functions exist, the assessor shall examine vendor evidence and test the software to confirm the following:
2.1.e Where known vulnerabilities in exposed interfaces exist, the assessor shall examine evidence and test the software to confirm the following:
Modified
p. 16 → 19
• The mitigations implemented by the software vendor to minimize exploit of these weaknesses have been identified.
• Methods are implemented to mitigate the exploitation of these weaknesses.
Modified
p. 16 → 19
• Clear and sufficient guidance on how to correctly implement sufficient security to meet the security and control objectives of this standard is made available to stakeholders per Control Objective 12.1.
• Clear and sufficient guidance on how to correctly implement sufficient security to meet applicable control objectives in this standard is provided to stakeholders in accordance with Control Objective 12.1.
Removed
p. 17
2.2.c Where user input or interaction is required to enable any software security controls, features, or functions (such as the installation of certificates) the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on the process provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
Modified
p. 17 → 19
Where access to third-party functions is prevented through implemented mitigations, the assessor shall test the software to confirm that they do not rely on a lack of knowledge of the functions as their security mitigation method⎯e.g., by simply not documenting an otherwise accessible API interface⎯and to verify the mitigations in place are effective at preventing the insecure use of such third-party functions.
Where access to third-party functions is prevented through implemented protection methods, the assessor shall test the software to confirm that it does not rely on a lack of knowledge of such functions as a security mitigation method by simply not documenting an otherwise accessible API interface and to confirm that the protection methods are effective at preventing the insecure use of such third-party functions.
Modified
p. 17 → 20
2.2.a The assessor shall examine vendor evidence and test the software to identify all software security controls, features and functions, and to confirm that any such controls, features and functions relied upon by the software for the protection of critical assets are enabled upon installation, initialization, or first use of the software.
2.2.a The assessor shall examine evidence and test the software to identify all software security controls, features and functions relied upon by the software for the protection of critical assets and to confirm that all are enabled upon installation, initialization, or first use of the software.
Modified
p. 17 → 20
Default software settings should result in a secure software configuration and should not rely on the end-user being a subject-matter expert to facilitate a secure configuration. To that effect, all available software security controls should be active upon software installation, initialization, or first use, depending upon how the software is deployed.
Default software settings should result in a secure software configuration and should not rely on the end-user being a subject-matter expert to ensure a secure configuration. To that effect, all available software security controls should be active upon software installation, initialization, or first use, depending upon how the software is deployed.
Modified
p. 17 → 20
2.2.b Where any software security controls, features and functions are enabled only upon initialization or first use, the assessor shall test the software to confirm that no sensitive data can be processed until this initialization process has been completed.
2.2.b Where any software security controls, features and functions are enabled only upon initialization or first use, the assessor shall test the software to confirm that sensitive data is processed only after this initialization process is complete.
Removed
p. 18
2.3.b The assessor shall test the software to confirm that all default credentials, keys, certificates, and other critical assets used for authentication by the software are supported by the vendor evidence.
Modified
p. 18 → 20
2.3.a The assessor shall examine vendor evidence to identify all default credentials, keys, certificates, and other critical assets used for authentication by the software.
2.3.a The assessor shall examine evidence to identify the default credentials, keys, certificates, and other critical assets used for authentication by the software.
Modified
p. 19 → 21
2.3.e The assessor shall test the software to confirm that default authentication credentials or keys for built-in accounts are not used to protect the storage and transmission of sensitive data.
2.3.e The assessor shall test the software to confirm that cryptographic keys used for authentication are not used for other purposes, such as protecting sensitive data during storage and transmission.
Modified
p. 20 → 22
2.4.a The assessor shall examine vendor evidence to identify all privileges and resources required by the software and to confirm the evidence describes and reasonably justifies all privileges and resources required, including explicit permissions for access to resources, such as cameras, contacts, etc.
2.4.a The assessor shall examine evidence to identify the privileges and resources required by the software and to confirm that information is maintained that describes and reasonably justifies all privileges and resources required, including explicit permissions for access to resources, such as cameras, contacts, etc.
Modified
p. 20 → 22
In many attacks on software or underlying systems, the software is often used to execute functions on the underlying operating systems or to abuse accessible external resources. When the software requires excessive permissions, those permissions could be exploited by a malicious user.
In many attacks on software or underlying systems, the software is often used to execute functions on the underlying operating systems or to abuse accessible external resources. When the software requires excessive permissions, such permissions may be exploited by a malicious user.
Modified
p. 20 → 22
The same concept applies to resources used by the software. The software should be granted access to only the minimum required resources for its expected operation. For example, mobile applications that do not require access to the camera or photographs should not request such access unless they are a necessary part of the software architecture. Similarly, software should not have access to sensitive files (e.g., /etc/passwd or Ntuser.dat) unless there is a legitimate need for the software to access those …
The same concept applies to resources used by the software. The software should be granted access to only the minimum required resources for its expected operation. For example, mobile applications that do not require access to the camera or photographs should not request such access unless they are a necessary part of the software architecture. Similarly, software should not have access to sensitive files (for example, /etc/passwd) unless there is a legitimate need for the software to access those files.
Modified
p. 20 → 22
2.4.b Where limiting access is not possible⎯e.g., due to the architecture of the solution or the execution environment in which the software is executed⎯the assessor shall examine vendor evidence to identify all mechanisms implemented by the software to prevent unauthorized access, exposure, or modification of critical assets, and to confirm there is clear and sufficient guidance on properly implementing the mechanisms provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
2.4.b Where limiting access is not possible due to the architecture of the solution or the execution environment in which the software is executed the assessor shall examine evidence to identify all mechanisms implemented by the software to prevent unauthorized access, exposure, or modification of critical assets, and to confirm that guidance on properly implementing and configuring these mechanisms is provided to stakeholders in accordance with Control Objective 12.1.
Modified
p. 20 → 22
2.4.c The assessor shall test the software to confirm that access permissions and privileges are assigned according to the vendor evidence. The assessor shall, where possible, use suitable tools for the platform on which the software is installed to review the permissions and privileges of the software itself, as well as the permissions and privileges of any resources, files, or additional elements generated or loaded by the software during use.
2.4.c The assessor shall test the software to confirm that access permissions and privileges are assigned according to the evidence examined in Test Requirement 2.4.a. The assessor shall, where possible, use suitable tools for the platform on which the software is installed to review the permissions and privileges of the software itself, as well as the permissions and privileges of any resources, files, or additional elements generated or loaded by the software during use.
Modified
p. 20 → 22
2.4.d Where the software execution environment provides legacy features for use by older versions of the software, the assessor shall examine vendor evidence and test the software to confirm that these are not utilized, and only recent and secured functionality is implemented. For example, software should “target” the latest versions of APIs provided by the environment they run on, where available.
2.4.d Where the software execution environment provides legacy features for use by older versions of the software, the assessor shall examine evidence and test the software to confirm that these are not used, and that only recent and secured functionality is implemented. For example, software should “target” the latest versions of APIs provided by the environment on which they run, where available.
Modified
p. 21 → 23
2.5.a The assessor shall examine the vendor evidence to identify all default accounts provided by the software and to confirm vendor evidence includes reasonable justification for the privileges assigned to these accounts.
2.5.a The assessor shall examine the evidence to identify all default accounts provided by the software and to confirm that the privileges assigned to these accounts are justified and reasonable.
Modified
p. 21 → 23
To limit access to sensitive data, functions, and resources to only those accounts that require such access, the level of privilege and access required should be defined and documented for each built-in account⎯e.g., an access matrix⎯such that its assigned functions may be performed, but that no additional or unnecessary access or privileges are granted.
To limit access to sensitive data, functions, and resources to only those accounts that require such access, the level of privilege and access required should be defined and documented for each built-in account in an access matrix such that its assigned functions may be performed, but no additional or unnecessary access or privileges are granted.
Modified
p. 21 → 23
2.5.b The assessor shall test the software to confirm that all default accounts provided or used by the software are supported by the vendor evidence.
2.5.b The assessor shall test the software to confirm that all default accounts provided or used by the software are supported by the evidence examined in Test Requirement 2.5.a.
Modified
p. 21 → 23
2.5.c The assessor shall examine vendor evidence and test the software to confirm that exposed functionalities (i.e., APIs) are protected from use by unauthorized users to modify account privileges and elevate user access rights.
2.5.c The assessor shall examine evidence and test the software to confirm that exposed interfaces, such as APIs, are protected from attempts by unauthorized users to modify account privileges and elevate user access rights.
Removed
p. 22
This control objective differentiates between transient sensitive data retained temporarily to facilitate software operation (e.g., retention of payment information in memory until completion of the authorization process) and sensitive data that is retained on a more permanent basis for the intended business use when the software user configures the retention period.
Modified
p. 22 → 24
3.1.a The assessor shall examine vendor evidence to identify what sensitive data is collected by the software for use beyond any one transaction, the default time period for which it is retained, and whether the retention period is user-configurable, and to confirm vendor evidence includes reasonable justification for retaining the sensitive data.
3.1.a The assessor shall examine evidence to identify the sensitive data that is collected by the software for use beyond any one transaction, the default time period for which it is retained, and whether the retention period is user-configurable, and to confirm that the purpose for retaining the sensitive data in this manner is justified and reasonable.
Modified
p. 22 → 24
3.1.b The assessor shall test the software to confirm that all available functions or services designed for the retention of sensitive data are supported by the vendor evidence.
3.1.b The assessor shall test the software to confirm that all available functions or services designed for the retention of sensitive data are supported by the evidence examined in Test Requirement 3.1.a.
Modified
p. 22 → 24
3.1.c The assessor shall test the software to confirm that sensitive data stored solely for the purposes of debugging, error finding, or testing of systems is protected during storage in accordance with Control Objective 6. Any such functionality that allows for storage of sensitive data must be explicitly enabled through an interface that requires interaction and authorization by the user and retained only for the duration necessary in accordance with reasonable vendor criteria. Closure of the software must result in …
3.1.c The assessor shall examine evidence and test the software to determine whether the software facilitates the storage of persistent sensitive data for the purposes of debugging, error finding or testing of systems, and to confirm that such data is protected during storage in accordance with Control Objective 6.1. Any function that allows for storage of sensitive data for these purposes must be explicitly enabled through an interface that requires interaction and authorization by the user and retains the data …
Removed
p. 23
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the transient sensitive data retained temporarily by the software.
Sensitive data elements collected in conjunction with software operations should only be retained for as long as required to complete that operation or related transaction. After payment processing is complete, all transient sensitive data should be securely deleted from all locations where it has been retained such that any subsequent process, component, function, application, entity, etc., within the environment may not access or capture the sensitive data. Software vendors should also be aware of and account for how other aspects of the software architecture (such as the software-development language and operating environment) may affect how and where transient sensitive data is retained. For example, operating-system usage of swap partitions or virtual memory files can cause information that should have been transient to persist longer than …
Sensitive data elements collected in conjunction with software operations should only be retained for as long as required to complete that operation or related transaction. After payment processing is complete, all transient sensitive data should be securely deleted from all locations where it has been retained such that any subsequent process, component, function, application, entity, etc., within the environment may not access or capture the sensitive data. Software vendors should also be aware of and account for how other aspects of the software architecture (such as the software-development language and operating environment) may affect how and where transient sensitive data is retained. For example, operating-system usage of swap partitions or virtual memory files can cause information that should have been transient to persist longer than …
Modified
p. 23 → 25
3.2.a The assessor shall examine vendor evidence to identify all sensitive data that is retained by the software for transient use, what triggers the secure deletion of this data, and confirm reasonable justification exists for retaining the data. This includes data that is stored only in memory during the operation of the software.
3.2.a Using information obtained in Test Requirement 1.1.a, the assessor shall examine evidence to identify all sensitive data that is retained by the software for transient use, what triggers the secure deletion of this data, and to confirm that the purposes for retaining the data are justified and reasonable. This includes data that is stored only in memory during the operation of the software.
Modified
p. 23 → 25
3.2.b Using information obtained in Test Requirement 1.2.a, the assessor shall test the software to confirm that all available functions or services that retain transient sensitive data are supported by evidence examined in Test Requirement 3.2.a and do not use immutable objects.
Removed
p. 24
3.2.d Where users can configure retention of transient sensitive data, the assessor shall examine vendor evidence to confirm that clear and sufficient guidance on this process is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
3.3.b The assessor shall test the software to confirm that no additional storage of sensitive data is included.
3.3.b The assessor shall test the software to confirm that no additional storage of sensitive data is included.
Modified
p. 24 → 25
If any sensitive data (e.g., pre-authorization data, etc.) must be used for debugging or troubleshooting purposes, the software should only capture the minimum amount of data necessary and store it securely in a known location.
If any sensitive data must be used for debugging or troubleshooting purposes, the software should only capture the minimum amount of data necessary and store it securely in a known location.
Modified
p. 24 → 26
Note: The Software Protection Mechanisms section includes several specific software security controls that are required to be implemented to protect sensitive data during storage, processing or transmission. Those software security controls should be analyzed to determine their applicability to the types of sensitive data retained by the software.
Note: The Software Protection Mechanisms section includes several specific software security controls that are required to be implemented to protect sensitive data during storage, processing, or transmission. Those software security controls should be analyzed to determine their applicability to the types of sensitive data retained by the software.
Modified
p. 24 → 26
3.3.a The assessor shall examine the vendor evidence to identify the protection methods implemented for all sensitive data during storage and transmission.
3.3.a The assessor shall examine the evidence to identify the methods implemented to protect sensitive data during storage and transmission.
Modified
p. 24 → 26
3.3.b Where sensitive data is stored outside of temporary variables within the code itself, the assessor shall test the software to confirm that sensitive data is protected using either strong cryptography or other methods that provide an equivalent level of security.
Removed
p. 25
3.3.e Where sensitive data is protected using methods other than strong cryptography, the assessor shall examine vendor evidence and test the software to confirm that the protections are present in all environments where the software is designed to be executed, are correctly implemented, and are covered by the vendor evidence.
3.3.f Where users are required to configure protection methods, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
3.3.f Where users are required to configure protection methods, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
Removed
p. 25
3.4.a The assessor shall examine vendor evidence to identify all secure deletion methods implemented by the software for all non-transient sensitive data.
Modified
p. 25 → 27
Secure deletion may be required at the end of a software-specific operation or upon completion of user-specified retention requirements. In the latter case, the software should be developed to provide functionality to facilitate secure deletion of the sensitive data after expiry of the user-specified retention period.
Secure deletion may be required at the end of a software-specific operation or upon completion of user-specified retention requirements. In the latter case, the software should be able to securely delete the sensitive data after expiry of the user-specified retention period.
Modified
p. 25 → 27
3.4.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is unrecoverable after deletion. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) which have been used to encrypt the data, or platform …
3.4.b The assessor shall examine evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is rendered unrecoverable. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) that have been used to encrypt the data, or platform specific functions …
Removed
p. 26
3.5.a The assessor shall examine vendor evidence to identify all secure deletion methods for all transient sensitive data and to confirm that these methods ensure that the data is unrecoverable after deletion.
Modified
p. 26 → 28
Where sensitive data is only retained temporarily to perform a specific function (such as a payment transaction), mechanisms are required to securely delete the sensitive data once the specific function has completed. Transient sensitive data is often erased from temporary storage locations after processing is complete. However, that data may remain resident in volatile memory (RAM) or in other storage locations for longer periods than anticipated (such as in swap files/partitions or log files). Software vendors should account for all …
Where sensitive data is only retained temporarily to perform a specific function (such as a payment transaction), mechanisms are required to securely delete the sensitive data once the specific function has completed.
Modified
p. 26 → 28
3.5.b The assessor shall examine vendor evidence and test the software to identify any platform or implementation level issues that complicate the erasure of such transient sensitive data⎯such as abstraction layers between the code and the hardware execution environment⎯and to confirm what methods have been implemented to minimize the risk posed by these complications.
3.5.b The assessor shall examine evidence and test the software to identify any platform or implementation level issues that complicate the erasure of such transient sensitive data such as abstraction layers between the code and the hardware execution environment and to confirm that methods have been implemented to minimize the risk posed by these complications.
Removed
p. 28
3.6.c The assessor shall examine vendor evidence to confirm that clear and sufficient guidance on the proper configuration and use of such mitigations is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
Modified
p. 28 → 29
3.6.a The assessor shall examine vendor evidence to confirm the software vendor has performed a thorough analysis to account for all sensitive data disclosure attack vectors including, but not limited to:
3.6.a The assessor shall examine evidence to confirm the software vendor has performed a thorough analysis to account for all sensitive data disclosure attack vectors including, but not limited to:
Modified
p. 28 → 29
• Execution environments that may be vulnerable to remote side-channel attacks to expose sensitive data⎯such as attacks that exploit cache timing or branch prediction within the platform processor.
• Execution environments that may be vulnerable to remote side-channel attacks to expose sensitive data, such as attacks that exploit cache timing or branch prediction within the platform processor.
Modified
p. 28 → 29
• Automatic storage or exposure of sensitive data by the underlying execution environment, such as through swap- files, system error logging, keyboard spelling, and auto- correct features, etc.
• Automatic storage or exposure of sensitive data by the underlying execution environment, such as through swap- files, system error logging, keyboard spelling, and auto- correct features.
Modified
p. 28 → 29
• Sensors or services provided by the execution environment that may be used to extract or leak sensitive data such as through use of an accelerometer to capture input of a passphrase to be used as a seed for a cryptographic key, or through capture of sensitive data through use of cameras, near-field communication (NFC) interfaces, etc.
• Sensors or services provided by the execution environment that may be used to extract or leak sensitive data, such as through use of an accelerometer to capture input of a passphrase to be used as a seed for a cryptographic key, or through capture of sensitive data through use of cameras or near-field communication (NFC) interfaces.
Modified
p. 28 → 29
Disclosure of sensitive data to unauthorized parties often occurs through unknown or unintended outputs or channels. For example: sensitive data could be unintentionally disclosed through error- or exception- handling routines, logging or debugging channels, third-party services and/or components, or through the use of shared resources such as memory, disk, files, keyboards, displays, and functions.
Modified
p. 28 → 29
3.6.b The assessor shall examine vendor evidence, including the results of the analysis described in Test Requirement 3.6.a, and test the software to confirm the software vendor implements mitigations to protect against unintended disclosure of sensitive data. Mitigations may include usage of cryptography to protect the data, or the use of blinding or masking of cryptographic operations (where supported by the execution environment).
3.6.b The assessor shall examine evidence, including the results of the analysis described in Test Requirement 3.6.a, and test the software to confirm that methods are implemented to protect against unintended disclosure of sensitive data. Such methods may include usage of cryptography to protect the data, or the use of blinding or masking of cryptographic operations (where supported by the execution environment).
Removed
p. 30
4.1.c The assessor shall examine the vendor evidence to confirm the following:
Modified
p. 30 → 31
4.1.a The assessor shall examine vendor evidence to confirm that the software vendor has identified, documented, and prepared mitigations for relevant attack scenarios for the software.
4.1.a The assessor shall examine evidence to confirm that the software vendor has identified and documented relevant attack scenarios for the software.
Modified
p. 30 → 31
Software vendors should evaluate the design of their payment software to identify attack scenarios applicable to the software, and the results of that analysis should be documented. Documentation should describe the various aspects of the code that could be attacked (including tasks or actions that frameworks and libraries do on the software’s behalf), the difficulty in mounting a successful attack, how widely the program will be distributed, and what mitigation techniques are used (for example, how the security functionality of …
Software vendors should evaluate the design of their payment software to identify attack scenarios applicable to the software and should document the results of that analysis. Documentation should describe the various aspects of the code that could be attacked (including tasks or actions that frameworks and libraries do on the software’s behalf), the difficulty in mounting a successful attack, the mitigation techniques used to protect against such attacks, and the methodology used for measuring the likelihood and impact of each …
Modified
p. 30 → 31
Where the software relies on execution environment security controls, the software vendor should review and reference the implementation documentation for the platform (such as the Security Policies for PCI- approved POI devices or FIPS140-2 or 140-3 approved cryptographic modules) and should confirm that the software and its associated documentation correctly and completely accommodate the guidance in these documents.
Modified
p. 30 → 31
4.1.b The assessor shall examine vendor evidence to determine whether any specific industry-standard methods or guidelines were used to identify relevant attack scenarios, such as the threat model guidelines. Where such industry standards are not used, the assessor shall confirm that the methodology used provides an equivalent coverage of the attack scenarios and methods for the software.
4.1.b The assessor shall examine evidence to determine whether any specific industry-standard methods or guidelines were used to identify relevant attack scenarios.
Modified
p. 30 → 32
• All critical assets managed by and all sensitive resources used by the system are documented.
• All critical assets managed and all sensitive resources used by the system are documented.
Removed
p. 31
• Consideration for the installed environment of the software, including any considerations for the size of the install base are documented. All attack surfaces that must be mitigated⎯such as implementing insecure user prompts or separating open protocol stacks; storage of sensitive data post authorization or storage of sensitive data using insecure methods, etc.⎯are documented.
4.1.d The assessor shall examine vendor evidence to confirm that the threat model created is reasonable to address the potential risks posed by the install and use of the software in a production environment⎯i.e., not in a test environment⎯given the assessor’s understanding through evaluation of the payment software to this standard.
4.1.d The assessor shall examine vendor evidence to confirm that the threat model created is reasonable to address the potential risks posed by the install and use of the software in a production environment⎯i.e., not in a test environment⎯given the assessor’s understanding through evaluation of the payment software to this standard.
Modified
p. 31 → 32
• All entry and egress methods for sensitive data by the software, as well as the authentication and trust model applied to each of these entry/egress points, are defined.
• All entry and egress points for sensitive data, as well as the authentication and trust model applied to each of these entry/egress points, are documented.
Modified
p. 31 → 32
• All data flows, network segments, and authentication/privilege boundaries are defined.
• All data flows, network segments, and authentication/privilege boundaries are documented.
Modified
p. 31 → 32
• Considerations for cryptography elements like cipher modes, protecting against timing attacks, padded oracles, brute force, “rainbow table” attacks, dictionary attacks against the input domain, etc. are documented.
• Considerations for cryptography elements like cipher modes, and protecting against relevant attacks such as timing attacks, padded oracles, brute force, “rainbow table” attacks, and dictionary attacks against the input domain are documented.
Modified
p. 31 → 32
• Execution environment implementation specifics or assumptions such as network configurations, operating system security configurations, etc. are documented.
• Execution environment implementation specifics or assumptions, such as network configurations and operating system security configurations, are documented.
Removed
p. 32
4.2.a The assessor shall examine vendor evidence to confirm that for each of the threats identified in Control Objective 4.1, one or more mitigation methods are clearly defined, or reasonable justification for the lack of mitigations is provided.
4.2.b The assessor shall examine vendor evidence and test the software to confirm that the implemented mitigation methods are reasonable for the threat they address.
Where user input or interaction can disable, remove, or bypass any such mitigations, the assessor shall test the software to confirm that such action requires authorization and strong authentication, and examine vendor evidence to confirm that clear and sufficient guidance on the risk of this action and that installation in this manner will invalidate any security validation that has been performed is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
4.2.b The assessor shall examine vendor evidence and test the software to confirm that the implemented mitigation methods are reasonable for the threat they address.
Where user input or interaction can disable, remove, or bypass any such mitigations, the assessor shall test the software to confirm that such action requires authorization and strong authentication, and examine vendor evidence to confirm that clear and sufficient guidance on the risk of this action and that installation in this manner will invalidate any security validation that has been performed is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
Modified
p. 32 → 33
The exact nature of the protection mechanism(s) will depend on the attack scenarios, the development platform, the software-development language, frameworks, libraries and APIs used by the software, as well as the operating environment (e.g., mobile device or distributed cloud-based application) upon which the software is intended to be deployed.
The exact nature of the protection mechanism(s) will depend on the attack scenarios, the development platform, and the software-development languages, frameworks, libraries, and APIs used by the software, as well as the execution environment where the software is intended to be deployed.
Modified
p. 32 → 33
To minimize the attack surface of the software, the software can be developed using secure design principles such as layered defense, application segmentation and isolation (logical), and adaptive response.
To minimize the software attack surface, the software should be developed using secure design principles such as layered defense, application segmentation and isolation (logical), and adaptive response.
Modified
p. 32 → 33
Examples of software security controls include input and output validation, authentication, parameterization, escaping, segmentation, logging, etc. For guidance on implementing cyber resiliency techniques and approaches, refer to industry standards and guidance such as NIST Special Publication 800-160, Appendix E.
Examples of software security controls include input and output validation, authentication, parameterization, escaping, segmentation, logging, etc. For guidance on implementing cyber resiliency techniques and approaches, refer to industry standards and guidance such as the current version of NIST Special Publication 800-160.
Modified
p. 32 → 33
4.2.b Where any mitigations rely on settings within the software, the assessor shall test the software to confirm that such settings are applied by default upon installation, initialization, or first use of the software.
Modified
p. 32 → 33
4.2.d When any mitigations rely on features of the execution environment, the assessor shall examine vendor evidence to confirm that guidance is provided to the software users to enable such settings as part of the install process.
4.2.d When any mitigations rely on features of the execution environment, the assessor shall examine evidence to confirm that guidance is provided to stakeholders on how to enable such settings in accordance with Control Objective 12.1.
Modified
p. 32 → 33
Where the execution environment provides APIs to query the status of mitigation controls, the assessor shall test the software to confirm that software checks for these mitigations are in place and active prior to being launched, and periodically throughout execution.
4.2.e Where the execution environment provides APIs to query the status of mitigation controls, the assessor shall test the software to confirm that software checks for these mitigations are in place and active prior to being launched and periodically throughout execution.
Modified
p. 33 → 34
5.1.a The assessor shall examine vendor evidence to confirm that the vendor has identified authentication requirements (i.e., type and number of factors) for all roles based on critical asset classification, the type of access (e.g., local, non-console, remote) and level of privilege.
5.1.a The assessor shall examine evidence to confirm that authentication requirements are defined (i.e., type and number of factors) for all roles based on critical asset classification, the type of access (e.g., local, non-console, remote) and level of privilege.
Modified
p. 33 → 34
Secure authentication facilitates individual responsibility for actions and allows the software to maintain an effective audit trail of user activity. This expedites issue resolution and containment when misuse or malicious intent occurs.
Secure authentication ensures individual responsibility for actions and allows the software to maintain an effective audit trail of user activity. This expedites issue resolution and containment when the software is misused for malicious purposes.
Modified
p. 33 → 34
Authentication mechanisms should cover all non- public resources managed by or accessible through the software, as well as sensitive functions that can alter the software functionality or impact the security of the sensitive data and resources. Examples of authentication methods include:
Authentication mechanisms should cover all non- public resources managed by or accessible through the software, as well as sensitive functions that can alter the software operation or impact the security of sensitive data and sensitive resources. Examples of authentication methods include:
Modified
p. 33 → 34
(continued on next page) 5.1.b The assessor shall examine vendor evidence and test the software to confirm that all access to critical assets is authenticated and authentication mechanisms are implemented correctly.
(continued on next page) 5.1.b The assessor shall examine evidence and test the software to confirm that access to critical assets is authenticated and authentication mechanisms are implemented correctly.
Modified
p. 33 → 34
5.1.c Where the software recommends, suggests, relies on, or otherwise facilitates the use of additional mechanisms (such as third-party VPNs, remote desktop features, etc.) to facilitate secure non-console access to the system on which the software is executed or directly to the software itself, the assessor shall examine vendor evidence to confirm that clear and sufficient guidance on how to configure authentication mechanisms correctly is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
5.1.c Where the software recommends, suggests, relies on, or otherwise supports the use of external mechanisms (such as third-party VPNs, remote desktop features, etc.) to provide secure non-console access to the system on which the software is executed or directly to the software itself, the assessor shall examine evidence to confirm that guidance on how to configure authentication mechanisms correctly is provided to stakeholders in accordance with Control Objective 12.1.
Removed
p. 34
Note: Control Objectives 3.3 and 4.2 require sensitive data, sensitive functions, and sensitive resources to be protected. Control Objectives 1.1 and 1.2 require sensitive data, sensitive functions, and sensitive resources to be identified/defined.
5.2.a The assessor shall examine vendor evidence and test the software to confirm that all implemented authentication methods require unique identification.
5.2.b Where interfaces, such as APIs, allow for automated access to critical assets, the assessor shall examine vendor evidence and test the software to confirm that unique identification of different programs or systems accessing the critical assets is required (for example, through use of multiple public keys) and that guidance on configuring a unique credential for each program or system is included in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
5.2.e The assessor shall examine vendor evidence, including source code of the software, to confirm that there are no additional methods for accessing …
5.2.a The assessor shall examine vendor evidence and test the software to confirm that all implemented authentication methods require unique identification.
5.2.b Where interfaces, such as APIs, allow for automated access to critical assets, the assessor shall examine vendor evidence and test the software to confirm that unique identification of different programs or systems accessing the critical assets is required (for example, through use of multiple public keys) and that guidance on configuring a unique credential for each program or system is included in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
5.2.e The assessor shall examine vendor evidence, including source code of the software, to confirm that there are no additional methods for accessing …
Modified
p. 34
For example, a user with limited access to sensitive data and sensitive resources could be required to perform authentication using a single authentication factor (e.g., password or a passphrase) while a user that is able to export the entire database might be required to perform multi-factor authentication. Other factors such as type of access (e.g., local, non- console, remote) and level of privilege (e.g., the ability to invoke sensitive functions such as pause logging or change access privileges) may influence …
For example, a user with limited access to sensitive data and sensitive resources could be required to perform authentication using a single authentication factor (for example, a password or a passphrase) while a user that is able to export the entire database might be required to perform multi-factor authentication.
Modified
p. 34 → 35
5.2.c Where identification is supplied across a non-console interface, the assessor shall test the software to confirm that authentication mechanisms are protected.
5.2.c Where identification is supplied across a non-console interface, the assessor shall test the software to confirm that authentication credentials are protected from attacks that attempt to intercept them in transit.
Modified
p. 34 → 35
5.2.d The assessor shall examine vendor evidence to confirm that the software vendor’s implementation guidance provided to stakeholders per Control Objective 12.1 specifically notes that identification and authentication parameters must not be shared between individuals, programs, or in any way that prevents the unique identification of each access to a critical asset.
5.2.d The assessor shall examine evidence to confirm that the guidance provided to stakeholders per Control Objective 12.1 specifically notes that identification and authentication parameters must not be shared between individuals, programs, or in any way that prevents the unique identification of each access to a critical asset.
Removed
p. 35
5.3.a The assessor shall examine vendor evidence to confirm that all implemented authentication methods were evaluated to identify the details of known vulnerabilities or attack methods on the authentication method, and how the implementation mitigates against such attacks. The evidence must also illustrate that the implementation used in the software was considered. For example, a fingerprint may be uniquely identifiable to an individual, but the ability to spoof or otherwise bypass such technology can be highly dependent on the way the solution is implemented.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 4.1 to determine the attack scenarios applicable to the software.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 4.1 to determine the attack scenarios applicable to the software.
Modified
p. 35 → 36
In some use cases or deployment scenarios, an authentication mechanism that relies on a single authentication method may not be sufficient. In such circumstances, the software vendor may want to implement additional mitigation strategies (e.g., multi- factor authentication mechanism).
In some use cases or deployment scenarios, an authentication mechanism that relies on a single authentication method may not be sufficient. In such circumstances, the software vendor may want to implement additional mitigation strategies (for example, multi-factor authentication mechanism).
Modified
p. 35 → 36
To support a claim that the implemented authentication mechanism is sufficiently strong and robust, a vendor should adopt an industry-accepted methodology for assigning assurance levels (e.g., NIST SP800-63-3 and NIST SP800-63B).
To support a claim that the implemented authentication mechanism is sufficiently strong and robust, a vendor should adopt an industry-accepted methodology for assigning assurance levels (for example, NIST SP800-63-3 and NIST SP800-63B).
Modified
p. 35 → 36
5.3.b The assessor shall examine vendor evidence to confirm that implemented authentication methods are robust and that robustness of the authentication methods was evaluated using industry-accepted methods.
5.3.b The assessor shall examine evidence to confirm that the implemented authentication methods are robust, and that the robustness of the authentication methods was evaluated using industry-accepted methods.
Modified
p. 35 → 36
5.3.c The assessor shall test the software to confirm the authentication methods are implemented correctly and do not expose vulnerabilities.
5.3.c The assessor shall test the software to confirm that the authentication methods are implemented correctly and do not expose vulnerabilities.
Removed
p. 36
5.4.b The assessor shall examine vendor evidence and test the software to identify what access is provided to critical assets and confirm that such access correlates with the vendor evidence. The test to confirm access is restricted should include attempts to access critical assets through user accounts, roles, or services which should not have the required privileges.
Modified
p. 36 → 37
5.4.a The assessor shall examine vendor evidence to confirm that the vendor has clearly identified and reasonably justified the required access for all critical assets.
5.4.a The assessor shall examine evidence to confirm that information is maintained that identifies and justifies the required access for all critical assets.
Modified
p. 36 → 37
To ensure the software protects the confidentiality and integrity of critical assets, access privileges to those critical assets should be restricted based on vendor- defined access requirements. There are various approaches to implementing privilege restriction, such as trust-based privilege management, attribute-based usage restriction, and dynamic privileges. To reduce the attack surface of the software, the software authorization mechanisms might limit access to critical assets to only those accounts that need such access⎯i.e., the principle of “least privilege.” Other techniques include …
To ensure the software protects the confidentiality and integrity of critical assets, access privileges to those critical assets should be restricted based on vendor- defined access requirements. There are various approaches to implementing privilege restriction, such as trust-based privilege management, attribute-based usage restriction, and dynamic privileges. To reduce the attack surface of the software, the software authorization mechanisms might limit access to critical assets to only those accounts that need such access (the principle of “least privilege”). Other techniques include …
Removed
p. 37
6.1.b The assessor shall examine vendor evidence and test the software to confirm that security methods implemented to protect all sensitive data during storage appropriately address all defined protection requirements and identified attack scenarios.
6.1.d Where index tokens are used for securing sensitive data, the assessor shall examine vendor evidence and test the software to confirm that these are generated in a way that ensures there is no correlation between the value and the sensitive data that is being referenced (without access to the vendor software to perform the correlation as part of a formally defined and assessed feature of that software⎯such as “de- tokenization”).
Sensitive data requiring confidentiality protection, when stored persistently, must be protected to prevent malicious or accidental access. Examples of methods to render sensitive data unreadable include usage of a one-way hash or the use of strong cryptography with associated key-management processes. (Refer to Control Objective 7 for …
6.1.d Where index tokens are used for securing sensitive data, the assessor shall examine vendor evidence and test the software to confirm that these are generated in a way that ensures there is no correlation between the value and the sensitive data that is being referenced (without access to the vendor software to perform the correlation as part of a formally defined and assessed feature of that software⎯such as “de- tokenization”).
Sensitive data requiring confidentiality protection, when stored persistently, must be protected to prevent malicious or accidental access. Examples of methods to render sensitive data unreadable include usage of a one-way hash or the use of strong cryptography with associated key-management processes. (Refer to Control Objective 7 for …
Modified
p. 37 → 38
6.1.a The assessor shall examine vendor evidence and test the software to identify all locations where sensitive data is stored to confirm protection requirements for all sensitive data are defined, including requirements for rendering sensitive data with confidentiality considerations unreadable anywhere it is stored persistently.
6.1.a The assessor shall examine evidence to confirm that protection requirements for all sensitive data are defined, including requirements for rendering sensitive data with confidentiality considerations unreadable anywhere it is stored persistently.
Modified
p. 37 → 38
In cases where the confidentiality of sensitive data is a concern, it is imperative to know where and for how long the data is retained. The vendor must have details of all locations where the software may store the data, including in any underlying software or systems⎯such as OS, log files, databases, etc.⎯as well as documentation of the security controls used to protect the data.
In cases where the confidentiality of sensitive data is a concern, it is imperative to know where and for how long the data is retained. The vendor must have details of all locations where the software may store sensitive data, including in any underlying software or systems, and documentation detailing the security controls used to protect the data.
Modified
p. 37 → 38
6.1.c Where cryptography is used for securing sensitive data, the assessor shall examine vendor evidence and test the software to confirm that any method implementing cryptography for securing sensitive data complies with Control Objective 7.
6.1.c Where cryptography is used for securing sensitive data, the assessor shall examine evidence and test the software to confirm that methods implementing cryptography for securing sensitive data comply with Control Objective 7.
Removed
p. 38
A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching, one-time pad and key.
6.1.f Where protection methods rely on security properties of third-party software, the assessor shall examine vendor evidence and test the software to confirm that this software provides security that is sufficient to meet the requirements of this standard. The assessor shall perform a review of current publicly available literature and vulnerability disclosures to confirm that there are no unmitigated vulnerabilities or issues with the security properties relied upon with that software.
6.2.b The assessor shall examine vendor evidence and test the software to confirm that for each of the ingress and egress methods that allow for transmission of sensitive data with confidentiality considerations outside of the physical execution environment, sensitive data is always encrypted with strong cryptography prior to transmission …
6.1.f Where protection methods rely on security properties of third-party software, the assessor shall examine vendor evidence and test the software to confirm that this software provides security that is sufficient to meet the requirements of this standard. The assessor shall perform a review of current publicly available literature and vulnerability disclosures to confirm that there are no unmitigated vulnerabilities or issues with the security properties relied upon with that software.
6.2.b The assessor shall examine vendor evidence and test the software to confirm that for each of the ingress and egress methods that allow for transmission of sensitive data with confidentiality considerations outside of the physical execution environment, sensitive data is always encrypted with strong cryptography prior to transmission …
Modified
p. 38 → 39
Where the integrity of sensitive data is a concern, strong cryptography with appropriate key- management practices is one method that could be used to satisfy integrity protection requirements during storage.
Where the integrity of sensitive data is a concern, strong cryptography with appropriate key-management practices is one method that could be used to satisfy integrity protection requirements during storage.
Modified
p. 38 → 39
6.2.a The assessor shall examine vendor evidence and test the software to identify all locations within the software where sensitive data is transmitted and confirm protection requirements for the transmission of all sensitive data are defined.
6.2.a The assessor shall examine evidence to identify the locations within the software where sensitive data is transmitted outside of the physical execution environment and to confirm protection requirements for the transmission of all sensitive data are defined.
Modified
p. 38 → 39
One method to protect sensitive data in transit is to encrypt it using strong cryptography prior to transmission. (Refer to Control Objective 7 for more information and guidance on strong cryptography.) Alternatively, the software could establish an authenticated and encrypted channel using only trusted keys and certificates (for authentication) and appropriate encryption strength for the selected protocols.
One method to protect sensitive data in transit is to encrypt it using strong cryptography prior to transmission.
Modified
p. 38 → 39
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the sensitive data stored, processed or transmitted by the software.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the sensitive data stored, processed, or transmitted by the software.
Modified
p. 38 → 39
6.2.c Where third-party or execution-environment features are relied upon for the security of the transmitted data, the assessor shall examine vendor evidence to confirm that clear and sufficient guidance on how to configure such features are included in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
6.2.c Where third-party or execution-environment features are relied upon for the security of the transmitted data, the assessor shall examine evidence to confirm that guidance on how to configure such features is provided to stakeholders in accordance with Control Objective 12.1.
Modified
p. 39 → 40
6.2.e Where the methods implemented for encrypting sensitive data allow for the use of different types of cryptography or different levels of security, the assessor shall test the software, including capturing software transmissions, to confirm the software enforces the use of strong cryptography at all times during transmission.
6.2.e Where the methods implemented for encrypting sensitive data allow for the use of different types of cryptography or different levels of security, the assessor shall examine evidence and test the software, including capturing software transmissions, to confirm the software enforces the use of strong cryptography at all times during transmission.
Modified
p. 39 → 40
6.3.a The assessor shall examine vendor evidence and test the software to confirm that each use of cryptography
•where cryptography is relied upon (in whole or in part) for the security of critical assets
•is compliant to Control Objective 7.
•where
•is
6.3.a Where cryptography is relied upon (in whole or in part) for the security of critical assets, the assessor shall examine evidence and test the software to confirm that the use of cryptography is compliant to Control Objective 7.
Modified
p. 39 → 40
Wherever cryptography is used to meet software- security requirements in this standard, it must be done in accordance with the specific security requirements related to the use of cryptography (including those in Control Objective 7). For example, storing a cryptographic key (used for protecting sensitive data) in a plaintext file would not be considered sufficient security unless additional controls prevented the file containing the cryptographic key from being accessed, modified, or exposed.
Wherever cryptography is used to meet software security requirements in this standard, it must be done in accordance with the specific security requirements related to the use of cryptography (including those in Control Objective 7).
Modified
p. 39 → 40
6.3.b Where cryptographic methods provided by third-party software or aspects of the execution environment or platform on which the application is run are relied upon for the protection of sensitive data, the assessor shall examine vendor evidence and test the software to confirm that the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 provides clear and sufficient detail for correctly configuring these methods during the installation, initialization, or first use of the software.
6.3.b Where cryptographic methods provided by third-party software or aspects of the execution environment or platform on which the application is run are relied upon for the protection of sensitive data, the assessor shall examine evidence and test the software to confirm that guidance on configuring these methods during the installation, initialization, or first use of the software is provided to stakeholders in accordance with Control Objective 12.1.
Modified
p. 39 → 40
6.3.c Where asymmetric cryptography such as RSA or ECC is used for protecting the confidentiality of sensitive data, the assessor shall examine vendor evidence and test the software to confirm that private keys are not used for providing confidentiality protection to the data.
6.3.c Where asymmetric cryptography such as RSA or ECC is used for protecting the confidentiality of sensitive data, the assessor shall examine evidence and test the software to confirm that private keys are not used for providing confidentiality protection to the data.
Removed
p. 40
• Only documented cryptographic algorithms and modes are used in the software and are implemented correctly, and
Modified
p. 40 → 41
7.1.a The assessor shall examine the vendor evidence to confirm that, where cryptography is relied upon (in whole or in part) for the security of the critical assets:
7.1.a The assessor shall examine evidence to determine how cryptography is used for the protection of critical assets and to confirm that:
Modified
p. 40 → 41
• Industry-accepted cryptographic algorithms and modes of operation are used in the software as the primary means for protecting critical assets; and
• Only documented cryptographic algorithms and modes of operation are used in the software.
Modified
p. 40 → 41
• Use of any unapproved algorithms must be in conjunction with approved algorithms and implemented in a manner that does not reduce the equivalent cryptographic key strength provided by the approved algorithms.
• The implementation of non-standard algorithms does not reduce the equivalent cryptographic key strength provided by the industry-standard algorithms.
Modified
p. 40 → 41
Not all cryptographic algorithms are sufficient to protect sensitive data. It is a well-established principle in software security to utilize only recognized cryptographic implementations based on current, industry-accepted standards such as those from industry bodies like NIST, ANSI, ISO, and EMVCo. The use of proprietary cryptographic implementations may increase the risk of data compromise as proprietary implementations are often not subjected to the same rigorous level of testing that industry-accepted implementations have undergone. Only those implementations that have been subjected …
Not all cryptographic algorithms are sufficient to protect sensitive data. It is a well-established principle in software security to utilize only recognized cryptographic implementations based on current, industry-accepted standards such as those from industry bodies like NIST, ANSI, ISO, and EMVCo.
Modified
p. 40 → 41
• Protections are incorporated to prevent common cryptographic attacks such as the use of the software as a decryption oracle, brute-force or dictionary attacks against the input domain of the sensitive data, the re-use of security parameters such as IVs, or the re-encryption of multiple datasets using linearly applied key values (such as XOR’d key values in stream ciphers or one-time pads).
• Protection methods are implemented to mitigate common attacks on cryptographic implementations (for example, the use of the software as a decryption oracle, brute-force or dictionary attacks against the input domain of the sensitive data, the re-use of security parameters such as IVs, or the re-encryption of multiple datasets using linearly applied key values, such as XOR’d key values in stream ciphers or one-time pads).
Removed
p. 41
7.1.e Where hash functions are used within the software, the assessor shall:
• Examine publicly available literature and research to identify vulnerable algorithms that can be exploited, and
• Examine publicly available literature and research to identify vulnerable algorithms that can be exploited, and
Modified
p. 41 → 42
7.1.e Where hash functions are used to protect sensitive data, the assessor shall examine evidence and test the software to confirm that:
Modified
p. 41 → 42
• Test the software to confirm that only approved, collision- resistant hash algorithms and methods are used with a salt value of appropriate strength, generated using a secure random number generator.
• Only approved, collision-resistant hash algorithms and methods are used for this purpose, and
Removed
p. 42
• All cryptographic keys that are used for providing security to critical assets⎯including both confidentiality and authenticity⎯as well as for providing other security services to the software (such as authentication of end- point or software updates) have a unique purpose. For example, no key may be used for both encryption and authentication operations.
(continued on next page) Whether implemented within or outside the software functionality, the manner in which cryptographic keys are managed is a critical part of the continued security of the software and the sensitive data it manages. While cryptographic key-management processes are often implemented as operational procedures, the software should support secure key- management practices based on industry standards or best practices (for example, NIST Special Publication 800-57 or PCI TSP Security Requirements), including:
(continued on next page) Whether implemented within or outside the software functionality, the manner in which cryptographic keys are managed is a critical part of the continued security of the software and the sensitive data it manages. While cryptographic key-management processes are often implemented as operational procedures, the software should support secure key- management practices based on industry standards or best practices (for example, NIST Special Publication 800-57 or PCI TSP Security Requirements), including:
Modified
p. 42
7.2.a The assessor shall examine vendor evidence and test the software to confirm that:
7.2.a The assessor shall examine evidence to confirm that information is maintained that describes the following for each key specified in the inventory:
Modified
p. 42 → 43
• All keys have defined generation methods, and no secret or private cryptographic keys relied upon for security of critical assets are shared between software instances, except when a common secret or private key is used for securing the storage of other cryptographic keys that are generated during the installation, initialization, or first use of the software (e.g., white-box cryptography).
• All keys have defined generation methods, and no secret or private cryptographic keys relied upon for security of critical assets are shared between software instances, except when a common secret or private key is used for securing the storage of other cryptographic keys that are generated during the installation, initialization, or first use of the software (for example, white-box cryptography).
Modified
p. 42 → 43
• The integrity and confidentiality of all secret and private cryptographic keys managed by the software are protected when stored (e.g., encrypted with a key-encrypting key that is at least as strong as the data-encrypting key and is stored separately from the data-encrypting key, or as at least two full-length key components or key shares, in accordance with an industry-accepted method).
• The integrity and confidentiality of all secret and private cryptographic keys managed by the software are protected when stored (for example, encrypted with a key-encrypting key that is at least as strong as the data-encrypting key and is stored separately from the data-encrypting key, or as at least two full-length key components or key shares, in accordance with an industry-accepted method).
Modified
p. 42 → 43
• Cryptographic key changes for keys that have reached the end of their crypto-period
• Cryptographic key changes for keys that have reached the end of their cryptoperiod
Removed
p. 43
7.2.c Where any public keys are used by the system, the assessor shall examine vendor evidence and test the software to confirm that the vendor maintains an inventory of all cryptographic keys used by the software and that the authenticity of all public keys is maintained. Vendor evidence must identify:
• Effective and expiration date
• Effective and expiration date
Modified
p. 43 → 44
7.2.d Where public keys are used by the system, the assessor shall examine evidence and test the software to confirm that the authenticity of all public keys is preserved.
Modified
p. 43 → 44
7.2.e Where public or white-box keys are not unique per software instantiation the assessor shall examine evidence to confirm that methods and procedures to revoke and/or replace such keys (or key pairs) exist.
Removed
p. 44
7.2.g The assessor shall examine vendor evidence and test the software to confirm that any secret and/or private keys are managed in a way that ensures split knowledge over the key, to a level that is feasible given the platform on which the software is executed. Where absolute split knowledge is not feasible, the assessor shall confirm that methods implemented are reasonable to protect secrets and/or private keys.
7.2.h The assessor shall examine vendor evidence and test the software to confirm that methods are implemented to “roll” any keys at the end of their defined crypto-period that ensure the security of the sensitive data (both cryptographic keys and data secured through use of these keys) is in line with the requirements of this standard.
7.2.h The assessor shall examine vendor evidence and test the software to confirm that methods are implemented to “roll” any keys at the end of their defined crypto-period that ensure the security of the sensitive data (both cryptographic keys and data secured through use of these keys) is in line with the requirements of this standard.
Modified
p. 44
7.2.g Where public keys are manually loaded or used as root keys, the assessor shall examine evidence and test the software to confirm that the keys are installed and stored in a way that provides dual control (to a level that is feasible for the execution environment), preventing a single user from replacing a key to enable a man-in-the-middle attack or the allow for unauthorized decryption of stored data. Where complete dual control is not feasible (for example, due to …
Removed
p. 45
Where problems are known, but have been mitigated by the software vendor, the assessor shall examine vendor evidence and test the software to confirm that the vulnerabilities have been sufficiently mitigated.
The assessor shall test the software to confirm that third-party software, platforms, or libraries are correctly integrated, implemented, and configured.
The assessor shall test the software to confirm that third-party software, platforms, or libraries are correctly integrated, implemented, and configured.
Modified
p. 45
7.3.a The assessor shall examine vendor evidence to confirm that all random number generation methods implemented in the software:
7.3.a The assessor shall examine evidence and test the software to identify all random number generators used by the software and to confirm that all random number generation methods:
Modified
p. 45
• Use at least 128 bits of entropy prior to the output of any random numbers from the random number generator.
• Use at least 128 bits of entropy prior to the output of any random numbers.
Modified
p. 45
The implementation may rely on either a validated cryptographic library or module. The software vendor should have a good understanding of the installation, initialization, configuration, and usage⎯for example, initial seeding of the random function⎯of the RNG mechanisms to ensure that the implementation can meet the effective security strength required for the intended use. The calls to these libraries should also be protected from being “hooked.” 7.3.b Where the vendor is relying upon previous assessment of the random number generator, or …
The implementation may rely on either a validated cryptographic library or module. The software vendor should have a good understanding of the installation, initialization, configuration, and usage (for example, initial seeding of the random function) of the RNG mechanisms to ensure that the implementation can meet the effective security strength required for the intended use.
Modified
p. 45
7.3.b Where third-party software, platforms, or libraries are used for all or part of the random number generation process, the assessor shall examine evidence (such as current publicly available literature) to confirm that the third-party software does not expose any vulnerabilities that may compromise its use for generating random values.
Modified
p. 46
7.4.a The assessor shall examine vendor evidence and test the software to confirm that the methods used for the generation of all cryptographic keys and other material (such as IVs, “k” values for digital signatures, etc.) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.
7.4.a The assessor shall examine evidence and test the software to confirm that the methods used for the generation of all cryptographic keys and other material (such as IVs, “k” values for digital signatures, and so on) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.
Removed
p. 47
• Any methods used for generating keys directly from a password/passphrase enforces an input domain that is able to provide sufficient entropy, such that the total possible inputs are at least equal to that of the equivalent bit strength of the key being generated (e.g., a 32-hex-digit input field for an AES128 key).
• The passphrase is passed through an industry-standard key-derivation function, such as PBKDF2 or bcrypt, which extends the work factor for any attempt to brute-force the passphrase value. The assessor shall confirm that a work factor of at least 10,000 is applied to any such implementation.
• Clear and sufficient guidance is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 that any passphrase used must be:
• Randomly generated itself, using a valid and secure random process: an online random number generator must not be used for this purpose.
• Never implemented by a …
• The passphrase is passed through an industry-standard key-derivation function, such as PBKDF2 or bcrypt, which extends the work factor for any attempt to brute-force the passphrase value. The assessor shall confirm that a work factor of at least 10,000 is applied to any such implementation.
• Clear and sufficient guidance is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 that any passphrase used must be:
• Randomly generated itself, using a valid and secure random process: an online random number generator must not be used for this purpose.
• Never implemented by a …
Modified
p. 49 → 48
Control Objectives Test Requirements Guidance Control Objective 8: Activity Tracking All software activity involving critical assets is tracked.
Control Objectives Test Requirements Guidance Control Objective 8: Activity Tracking All software activities involving critical assets are tracked.
Modified
p. 49 → 48
To facilitate user accountability and to allow post- incident forensic investigation, payment software should capture and maintain historical records of all software activity involving critical assets (i.e., sensitive data and resources and usage of sensitive functions), and ensure such activity is traceable to a unique user (e.g., person), system, or other entity accessing critical assets.
To ensure user accountability and to support post- incident forensic investigation, payment software should capture and maintain historical records of all software activities involving critical assets and ensure that all such activities are traceable to a unique user (for example, a person, system, or other entity).
Modified
p. 49 → 48
• All individual user attempts to access sensitive data or resources
• All individual user attempts to access sensitive data or resources.
Modified
p. 49 → 48
• Usage of or changes to sensitive functions, such as the software’s identification and authentication mechanisms or activity tracking mechanisms
• Usage of or changes to sensitive functions, such as the software’s identification and authentication mechanisms or activity tracking mechanisms.
Modified
p. 49 → 48
This control objective does not mandate the logging of each encryption operation or function processing sensitive data, but it does require that access is tracked and any methods that may expose sensitive data are also tracked.
Removed
p. 50
• Disabling or deleting a security control or altering security functionality By recording the details in this requirement for all attempts to access or use critical assets, malicious activity or potential software or data compromise can be quickly identified and with sufficient detail to know who performed the activity, whether the attempt was successful, when the activity occurred, what critical assets were affected, and the origination of the event.
Modified
p. 50 → 49
8.2.a The assessor shall examine vendor evidence and test the software to confirm that the tracking method(s) implemented capture specific activity performed, including:
8.2.a The assessor shall examine evidence and test the software to confirm that the tracking method(s) implemented capture specific activity performed, including:
Modified
p. 50 → 49
• Enablement of any privileged modes of operation
• Enablement of any privileged modes of operation.
Modified
p. 50 → 49
• Disabling of encryption of sensitive data
• Disabling of encryption of sensitive data.
Modified
p. 50 → 49
• Decryption of sensitive data
• Decryption of sensitive data.
Modified
p. 50 → 49
• Exporting of sensitive data to other systems or processes
• Exporting of sensitive data to other systems or processes.
Modified
p. 50 → 49
• Failed authentication attempts
• Failed authentication attempts.
Modified
p. 50 → 49
8.2.b The assessor shall examine vendor evidence and test the software to confirm that the tracking method(s) implemented provide:
8.2.b The assessor shall examine evidence and test the software to confirm that the tracking method(s) implemented provide the following:
Modified
p. 50 → 49
• A unique identification for the person, system, or entity performing the access
• A unique identification for the individual, system, or entity accessing or using critical assets.
Modified
p. 50 → 49
• A timestamp for each tracked event
• A timestamp for each tracked event.
Modified
p. 50 → 49
8.2.c The assessor shall test the software to confirm that confidential data is not directly recorded in the tracking data.
Modified
p. 50 → 49
8.3.a Where the activity records are managed by the software, including only temporarily before being passed to other systems, the assessor shall examine vendor evidence and test the software to confirm that the protection methods are implemented to protect completeness, accuracy, and integrity of the activity records.
8.3.a Where the activity records are managed by the software, including only temporarily before being passed to other systems, the assessor shall examine evidence and test the software to confirm that the protection methods are implemented to protect completeness, accuracy, and integrity of the activity records.
Modified
p. 50 → 49
In order to identify anomalous behavior and to facilitate forensic investigation upon suspicion of potential software or data compromise, the software must facilitate the retention of detailed activity records either through native functionality (i.e., within the software itself) or support integration with other solutions such as centralized log servers, cloud-based logging solutions, or a back-end monitoring solution.
In order to identify anomalous behavior and to enable forensic investigation upon suspicion of potential software or data compromise, the software must provide for the retention of detailed activity records either through native means (within the software itself) or support integration with other solutions such as centralized log servers, cloud-based logging solutions, or a back-end monitoring solutions.
Removed
p. 51
8.4.a The assessor shall examine vendor evidence and test the software to confirm that failure of the activity tracking system does not violate the integrity of existing records. The assessor shall explicitly confirm that:
Modified
p. 51 → 50
Without adequate protection of activity records, their completeness, accuracy, and integrity cannot be guaranteed, and any reliance that would otherwise be placed on them (such as during a forensic investigation) would be negated.
Without adequate protection of activity records, their completeness, accuracy, and integrity cannot be guaranteed and any reliance that would otherwise be placed on them (such as during a forensic investigation) would be negated.
Modified
p. 51 → 50
When activity records are managed by the software, the records must be protected in accordance with all applicable requirements for the protection of sensitive data.
When activity records are managed by the software, the records must be protected in accordance with all applicable requirements for the protection of sensitive data. 8.3.c The assessor shall test the software to confirm methods are implemented to secure the authenticity of the tracking data during transmission to the log storage system, and to confirm that this protection meets the requirements of this standard (for example, authenticity parameters must be applied using strong cryptography) and any account or authentication parameters …
Modified
p. 51 → 50
Software security controls should be implemented to ensure that when activity-tracking mechanism(s) fail, those failures are handled in a way that maintains the integrity and confidentiality (if applicable) of the records.
(continued on next page) Software security controls should be implemented to ensure that when activity-tracking mechanism(s) fail, those failures are handled in a way that maintains the integrity of the records. Otherwise, attackers may intentionally target activity-tracking mechanisms and cause failures that would allow the attackers to conceal or overwrite evidence of their activities.
Modified
p. 51
• Where possible the software applies suitable file privileges to assist with maintaining the integrity of the tracking dataset (such as applying an append only access control to a dataset once created). Where the software does not apply such controls, the assessor shall confirm reasonable justification exists describing why this is the case, why the behavior is sufficient, and what additional mitigations are applied to maintain the integrity of the tracking data.
• The software applies, where possible, suitable file privileges to assist with maintaining the integrity of the tracking dataset (such as applying an append only access control to a dataset once created). Where the software does not apply such controls, the assessor shall confirm reasonable justification exists describing why this is the case, why the behavior is sufficient, and what additional mitigations are applied to maintain the integrity of the tracking data.
Modified
p. 52 → 51
• Preventing the creation of new dataset entries by preventing further writing to the media on which the dataset is located (e.g., by using media that has insufficient available space).
• Preventing the creation of new dataset entries by preventing further writing to the media on which the dataset is located (for example, by using media that has insufficient available space).
Modified
p. 52 → 51
Where any of the tests above are not possible, the assessor shall interview personnel to confirm reasonable justification exists to describe why this is the case and shall confirm protections are put in place to prevent such scenarios from affecting the integrity of the tracking records.
Where any of the tests above are not possible, the assessor shall interview personnel to confirm reasonable justification exists to describe why this is the case and shall confirm protections are in place to prevent such scenarios from affecting the integrity of the tracking records.
Removed
p. 53
9.1.a The assessor shall examine vendor evidence and test the software to confirm that, where possible, the software implements a method to validate the integrity of its own executable and any configuration options, files, and datasets that it relies upon for operation (such that unauthorized, post- deployment changes can be detected).
Modified
p. 53 → 52
Where the execution environment prevents this, the assessor shall examine vendor evidence and current publicly available literature on the platform and associated technologies to confirm that there are indeed no methods for validating authenticity. The assessor shall then test the software to confirm controls are implemented to minimize the associated risk.
Where the execution environment prevents this, the assessor shall examine evidence (including publicly available literature on the platform and associated technologies) to confirm that there are indeed no methods for validating authenticity, and that additional security controls are implemented to minimize the associated risk.
Modified
p. 53 → 52
Software should possess basic functionality to differentiate between normal and anomalous user behavior. Examples of anomalous behavior that should be automatically detected by the software include changes in post-deployment (or post-initialization) configurations or obvious automated-attack behaviors⎯e.g., frequent input of a password can be an indicator of brute-force attempts.
Software should possess basic functionality to differentiate between normal and anomalous user behavior. Examples of anomalous behavior that should be automatically detected by the software include changes in post-deployment (or post-initialization) configurations or obvious automated-attack behaviors, such as repeated authentication attempts at a frequency that is infeasible for a human user.
Modified
p. 53 → 52
9.1.b The assessor shall examine vendor evidence and test the software to confirm that integrity values used by the software and dataset(s) upon which it relies for secure operation are checked upon software execution, and at least every 36 hours thereafter (if the software continues execution during that time period). The assessor shall confirm what action the software takes upon failure of these checks and confirm that the processing of sensitive data is halted until this problem is remediated.
9.1.b The assessor shall examine evidence and test the software to confirm that integrity values used by the software and dataset(s) upon which it relies for secure operation are checked upon software execution, and at least every 36 hours thereafter (if the software continues execution during that time period).
Modified
p. 53 → 52
9.1.c Where cryptographic primitives are used by any anomaly- detection methods, the assessor shall examine vendor evidence and test the software to confirm that cryptographic primitives are protected.
9.1.c Where cryptographic primitives are used by any anomaly- detection methods, the assessor shall examine evidence and test the software to confirm that the cryptographic primitives are protected.
Modified
p. 53 → 52
9.1.d Where stored values are used by any anomaly-detection methods, the assessor shall examine vendor evidence and test the software to confirm that these values are considered sensitive data and protected accordingly.
9.1.d Where stored values are used by any anomaly detection methods, the assessor shall examine evidence and test the software to confirm that these values are considered sensitive data and are protected accordingly.
Removed
p. 54
9.1.f The assessor shall examine vendor evidence and test the software to confirm that the software implements controls to prevent brute-force attacks on account, password, or cryptographic-key input fields (e.g., input rate limiting).
Removed
p. 55
10.1.a The assessor shall examine vendor evidence to confirm that the vendor identifies common methods for attack against the software product. This may include platform-level, protocol- level, and/or language-level attacks.
10.1.c The assessor shall examine vendor evidence to confirm that mitigations against each identified attack vector exists, and that the vendor’s software release process includes validation of the existence of these mitigations.
10.1.c The assessor shall examine vendor evidence to confirm that mitigations against each identified attack vector exists, and that the vendor’s software release process includes validation of the existence of these mitigations.
Modified
p. 55 → 54
Control Objectives Test Requirements Guidance Control Objective 10: Threat and Vulnerability Management The software vendor identifies, assesses, and manages threats and vulnerabilities to its payment software.
Control Objectives Test Requirements Guidance Control Objective 10: Threat and Vulnerability Management Payment software threats and vulnerabilities are identified, assessed, and managed appropriately.
Modified
p. 55 → 54
• The types of information collected, stored, processed, or transmitted by the software;
• The types of information collected, stored, processed, or transmitted by the software.
Modified
p. 55 → 54
• The motivations an attacker may have for attacking the software;
• The motivations an attacker may have for attacking the software.
Modified
p. 55 → 54
• The methods an attacker might utilize or the vulnerabilities an attacker might try to exploit during an attack;
• The methods an attacker might utilize or the vulnerabilities an attacker might try to exploit during an attack.
Modified
p. 55 → 54
• The exploitability of any identified vulnerabilities; and
• The exploitability of any identified vulnerabilities.
Modified
p. 55 → 54
For guidance on threat analysis and cyber-resiliency design principles, refer to industry standards and guidance such as NIST Special Publication 800-160, Appendix F.
For guidance on threat analysis and cyber-resiliency design principles, refer to industry standards and guidance, such as the current version of NIST Special Publication 800-160.
Modified
p. 55 → 54
10.1.b The assessor shall examine vendor evidence to confirm that the list of common attacks is valid for the software the vendor has produced and shall note where this does not include common attack methods detailed in industry-standard references such as OWASP and CWE lists.
10.1.b The assessor shall examine evidence to confirm that the identified attacks are valid for the software and shall note where this does not include common attack methods detailed in industry-standard references such as OWASP and CWE lists.
Removed
p. 56
10.2.a The assessor shall examine vendor evidence to confirm that the software vendor has implemented robust testing processes throughout the software lifecycle to validate the mitigations used to secure the software against attacks outlined in the vendor threat model and vulnerability assessment.
Modified
p. 56 → 55
Most software vulnerabilities are introduced as a result of coding errors, bad design, improper implementation of software functionality, or the use of vulnerable components.
Most software vulnerabilities are introduced as a result of coding errors, bad design, improper implementation, or the use of vulnerable components.
Modified
p. 56 → 55
Software should be developed and tested in a manner that minimizes the existence of any vulnerabilities and detects those that emerge over time, such that the vulnerabilities may be addressed before the software is released or updated. Techniques to avoid the introduction of vulnerabilities during development include the use of security coding practices, testing code during each phase of the development lifecycle using automated tools (such as static/dynamic analysis tools, interactive security testing tools, etc.), and standardizing the use of …
Software should be developed and tested in a manner that minimizes the existence of any vulnerabilities and detects those that emerge over time, such that the vulnerabilities may be addressed before the software is released or updated. Techniques to avoid the introduction of vulnerabilities during development include the use of security coding practices, testing code during each phase of the development lifecycle using automated tools such as static/dynamic analysis tools and interactive security testing tools, and standardizing the use of …
Modified
p. 57 → 55
• Includes the use of tools for security testing that are appropriate for detecting applicable vulnerabilities and are suitable for the software architecture, development languages, and frameworks used in the development of the software.
• Includes the use of security testing tools that are suitable for the software architecture, development languages, and frameworks used in the development of the software.
Modified
p. 57 → 55
• Accounts for the entire code base, including detecting vulnerabilities in third-party, open-source, or shared components and libraries.
• Accounts for the entire code base and detects vulnerabilities in third-party, open-source, or shared components and libraries.
Modified
p. 57 → 55
• Demonstrates a history of finding software vulnerabilities and remediating them prior to retesting of the software.
• Demonstrates a history of finding software vulnerabilities and remediating them prior to software release.
Modified
p. 57 → 55
10.2.c Where vendor evidence shows the release of software with known vulnerabilities, the assessor shall examine vendor evidence to confirm that:
10.2.c Where evidence examined in Test Requirement 10.2.b shows the release of software with known vulnerabilities, the assessor shall examine further evidence to confirm that:
Modified
p. 57 → 55
• The vendor implements an industry-standard vulnerability- ranking system (such as CVSS) that allows for the categorization of vulnerabilities.
• An industry-standard vulnerability-ranking system (such as CVSS) is used to classify/categorize vulnerabilities.
Modified
p. 57 → 55
• For all vulnerabilities, the vendor provides a remediation plan⎯it is unacceptable for a known vulnerability to remain unmitigated for an indefinite period.
• A remediation plan is maintained for all detected vulnerabilities that ensures vulnerabilities do not remain unmitigated for an indefinite period.
Removed
p. 58
11.1.b For a sample of vendor software updates, the assessor shall examine vendor evidence, including update-specific security-testing results and details, to confirm security fixes have been made available to stakeholders in accordance with defined criteria. Where updates were not provided in accordance with defined criteria, such instances are be reasonably justified by the vendor.
11.2.a The assessor shall examine vendor evidence to confirm that the method by which the vendor releases software updates ensures the integrity of the software and its code during transmission and install. Where user instructions are required to validate the integrity of the code, the assessor shall confirm that clear and sufficient guidance to enable the process to be correctly performed is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
11.2.b Where the integrity method implemented is not cryptographically secure (such as through the use of digital signatures), the assessor shall …
11.2.a The assessor shall examine vendor evidence to confirm that the method by which the vendor releases software updates ensures the integrity of the software and its code during transmission and install. Where user instructions are required to validate the integrity of the code, the assessor shall confirm that clear and sufficient guidance to enable the process to be correctly performed is provided in the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1.
11.2.b Where the integrity method implemented is not cryptographically secure (such as through the use of digital signatures), the assessor shall …
Modified
p. 58 → 56
11.1.a The assessor shall examine vendor evidence to confirm that:
11.1.a The assessor shall examine evidence to confirm that:
Modified
p. 58 → 56
• Reasonable criteria exist for releasing software updates to fix security vulnerabilities.
• Reasonable criteria are defined for releasing software updates to fix security vulnerabilities.
Modified
p. 58 → 56
• Security updates are made available to stakeholders in accordance with defined criteria.
• Security updates are made available to stakeholders in accordance with the defined criteria.
Modified
p. 58 → 56
Vulnerabilities should be addressed in a manner that is commensurate with the risk they pose to software users or other stakeholders. The most critical or severe vulnerabilities (i.e., those with the highest exploitability and the greatest potential impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability or potential impact. The criteria for determining how and when to make patches available to stakeholders should be defined and followed.
Vulnerabilities should be addressed in a manner that is commensurate with the risk they pose to software users or other stakeholders. The most critical or severe vulnerabilities (those with the highest exploitability and the greatest potential impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability or potential impact. The criteria for determining how and when to make patches available to stakeholders should be defined and followed.
Modified
p. 58 → 56
Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include, but are not limited to, checksums and digitally signed certificates (where implemented appropriately), etc. Verification could be implemented within the software itself, or instruction (e.g., release notes) can be provided by the vendor to allow verification of the software updates by its customers.
Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include, but are not limited to, checksums and digitally signed certificates (where implemented correctly). Verification could be implemented within the software itself or through guidance that is provided to stakeholders to direct them on the manual verification of software updates.
Modified
p. 58 → 56
In addition, the process of distributing updates and patches should prevent malicious individuals from intercepting the updates in transit, modifying them, and then redistributing them to unsuspecting customers.
In addition, the process of distributing updates and patches should prevent malicious individuals from intercepting the updates in transit, modifying them, and then redistributing them to unsuspecting stakeholders.
Removed
p. 59
11.2.d The assessor shall examine vendor evidence to confirm the vendor has a process for informing users of the software of known vulnerabilities that have not yet been patched by a new version of the software. This includes vulnerabilities that may exist in third-party software and libraries used by the vendor’s software product. The assessor shall confirm that this process includes providing the users with suggested mitigations for any such vulnerabilities.
11.2.e The assessor shall examine vendor evidence to confirm the update mechanisms cover all software, configuration files, and other metadata that may be used by the software for security purposes, or which may in some way affect security.
11.2.e The assessor shall examine vendor evidence to confirm the update mechanisms cover all software, configuration files, and other metadata that may be used by the software for security purposes, or which may in some way affect security.
Removed
p. 60
12.1.a The assessor shall examine vendor evidence to confirm that the vendor creates and provides, to all stakeholders, clear and sufficient guidance to allow for the secure installation and use of the software.
Modified
p. 60 → 58
When followed, the software 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 of the software or the data it interacts with. The guidance should also include secure configuration options for any components provided with or supported by the software, …
When followed, the software vendor's implementation guidance provides assurance that the software and patches can be securely installed, configured, and maintained in a customer environment, and that all desired security functions are active and working as intended. The guidance should cover all options and functions available to software users that could affect the security of the software or the data it interacts with. The guidance should also include secure configuration options for any components provided with or supported by the …
Modified
p. 60 → 58
• Changing default credentials and passwords
• Changing default credentials and passwords.
Modified
p. 60 → 58
• Enabling and disabling software accounts, services, and features
• Enabling and disabling software accounts, services, and features.
Modified
p. 60 → 58
• Changes in resource access permissions
• Changes in resource access permissions.
Modified
p. 60 → 58
• Integration with third-party cryptographic libraries, random number generators, etc.
• Integration with third-party cryptographic libraries, random number generators, and so on.
Modified
p. 60 → 58
The provided guidance should result in a secure configuration across all configurable options.
The provided guidance should result in a secure configuration across all supported platforms and all configurable options.
Modified
p. 60 → 58
12.1.b The assessor shall examine vendor evidence to confirm that the guidance:
12.1.b The assessor shall examine evidence to confirm that the guidance:
Modified
p. 60 → 58
• Includes instructions for key management (e.g., use of keys, how keys are distributed, loaded, removed, changed, destroyed, etc.)
• Includes instructions for key management (for example, the use of keys and how they are distributed, loaded, removed, changed, and destroyed.)
Modified
p. 61 → 59
• Provides justification for any requirements in this standard that are to be assessed as not applicable. For each of these, the assessor shall confirm reasonable justification exists for why this is the case and confirm that it agrees with their understanding and the results of their testing of the software.
• Provides justification for any requirements in this standard that are to be assessed as not applicable. For each of these, the assessor shall confirm justification exists for why this is the case and shall confirm that it agrees with their understanding and the results of their software testing.
Removed
p. 62
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If PAN is stored, processed, or transmitted or is otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.
Modified
p. 62 → 60
A.1: Sensitive Authentication Data A.2: Cardholder Data Protection Purpose and Scope This section (hereinafter referred to as the “Account Data Protection Module”) defines security requirements and assessment procedures for software that stores, processes, or transmits account data. For the purposes of this module, account data is defined as follows:
A.1: Sensitive Authentication Data A.2: Cardholder Data Protection Purpose and Scope This section (hereinafter referred to as the “Account Data Protection Module”) defines security requirements and assessment procedures for software that stores, processes, or transmits Account Data. For the purposes of this module, account data is defined as follows:
Removed
p. 64
Control Objectives Test Requirements Guidance Control Objective A.1: Sensitive Authentication Data Sensitive authentication data is not retained after authorization.
A.1.1.a For each instance of sensitive authentication data identified in Control Objective 1.1,the assessor shall test the software, including generation of error conditions and log entries, and usage of forensic tools and/or methods, to identify all potential storage locations and to confirm that the software does not store sensitive authentication data after authorization. This includes temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).
• Database contents A.1.1.b Where sensitive authentication data is stored after authorization, the assessor shall examine vendor evidence to confirm the software is intended only for use by issuers or organizations that support issuing services.
A.1.1.a For each instance of sensitive authentication data identified in Control Objective 1.1,the assessor shall test the software, including generation of error conditions and log entries, and usage of forensic tools and/or methods, to identify all potential storage locations and to confirm that the software does not store sensitive authentication data after authorization. This includes temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).
• Database contents A.1.1.b Where sensitive authentication data is stored after authorization, the assessor shall examine vendor evidence to confirm the software is intended only for use by issuers or organizations that support issuing services.
Modified
p. 64 → 62
A.1.1 The software does not store sensitive authentication data after authorization⎯even if encrypted⎯unless the software is intended only for use by issuers or organizations that support issuing services.
A.1.1 The software does not store sensitive authentication data after authorization (even if encrypted) unless the software is intended only for use by issuers or organizations that support issuing services.
Modified
p. 64 → 62
Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited. This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.
Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited. This data is valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.
Modified
p. 64 → 62
• Audio and image files (digital voice, biometrics, etc.)
• Audio and image files (for example, digital voice and biometrics)
Removed
p. 65
Customers and integrators/resellers must also be provided with configuration details for the underlying systems that the software runs on, to ensure these underlying systems are not capturing cardholder data without the customer’s knowledge.
A.2.2 The software masks the PAN such that only a maximum of the first six and last four digits are displayed by default.
A.2.2.a The assessor shall examine vendor evidence, including the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1, to confirm the guidance includes the following instructions for customers and integrators/resellers:
• Details of all instances where PAN is displayed.
• Confirmation that the payment software masks PAN to display a maximum of the first six and last four digits by default on all displays.
• Instructions for how to configure the software to display more than the first six/last four digits of the PAN (includes displays of the full PAN).
A.2.2 The software masks the PAN such that only a maximum of the first six and last four digits are displayed by default.
A.2.2.a The assessor shall examine vendor evidence, including the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1, to confirm the guidance includes the following instructions for customers and integrators/resellers:
• Details of all instances where PAN is displayed.
• Confirmation that the payment software masks PAN to display a maximum of the first six and last four digits by default on all displays.
• Instructions for how to configure the software to display more than the first six/last four digits of the PAN (includes displays of the full PAN).
Modified
p. 65 → 63
A.2.1 The software vendor provides guidance to customers regarding secure deletion of cardholder data after expiration of the customer-defined retention period.
A.2.1 The software vendor provides guidance to stakeholders regarding secure deletion of cardholder data after expiration of defined retention period(s).
Modified
p. 65 → 63
A.2.1 The assessor shall examine the instructions prepared by the software vendor and confirm the documentation includes the following guidance for customers, integrators, and resellers:
A.2.1 The assessor shall examine evidence to confirm that guidance is provided to stakeholders in accordance with Control Objective 12.1 that details:
Modified
p. 65 → 63
• A list of all locations where the software stores cardholder data.
• All locations where the software stores cardholder data.
Modified
p. 65 → 63
• Instructions on how to securely delete cardholder data stored by the payment software, including data stored on underlying software or systems (such as OS, databases, etc.).
• How to securely delete cardholder data stored by the payment software, including cardholder data stored on underlying software or systems (such as in OS files or in databases).
Modified
p. 65 → 63
• Instructions for configuring the underlying software or systems (such as OS, databases, etc.) to prevent inadvertent capture or retention of cardholder data •for example, system backup or restore points.
• How to configure the underlying software or systems to prevent the inadvertent capture or retention of cardholder data (for example, by system backup or restore points).
Modified
p. 65 → 63
The software vendor must provide details of all locations where the software may store cardholder data, including in any underlying software or systems (such as OS, databases, etc.), as well as instructions for securely deleting the data from these locations once the data has exceeded the customer’s defined retention period.
The software vendor must provide details of all locations where the software may store cardholder data, including in any underlying software or systems (such as OS, databases, and so on), as well as instructions for securely deleting the data from these locations once the data has exceeded any defined retention period(s).
Modified
p. 65 → 63
Stakeholders need to know how underlying systems could be capturing data from the software so they can either prevent it from being captured or ensure the data is properly protected.
Modified
p. 65 → 63
The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits.
The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, the software should provide features to mask the PAN so that individuals performing that function can view only the last four digits.
Removed
p. 66
A.2.2.c The assessor shall examine vendor evidence and test the software to confirm that for each instance where the PAN is displayed, the instructions for displaying more than the first six/last four digits are accurate.
• Details of any configurable options for each method used by the software to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment software.
• A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering the PAN unreadable in all such instances.
• Instruction that if debugging logs are ever enabled (for example, for troubleshooting purposes) and they include the PAN, they must be protected, disabled as soon as troubleshooting is complete, and securely deleted when no longer needed.
An index token is a cryptographic …
• Details of any configurable options for each method used by the software to render cardholder data unreadable, and instructions on how to configure each method for all locations where cardholder data is stored by the payment software.
• A list of all instances where cardholder data may be output for the customer to store outside of the payment application, and instructions that the customer is responsible for rendering the PAN unreadable in all such instances.
• Instruction that if debugging logs are ever enabled (for example, for troubleshooting purposes) and they include the PAN, they must be protected, disabled as soon as troubleshooting is complete, and securely deleted when no longer needed.
An index token is a cryptographic …
Modified
p. 66 → 64
A.2.3 Render the PAN unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:
A.2.3 PAN is rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:
Modified
p. 66 → 64
A.2.3.a The assessor shall examine vendor evidence, including the software vendor’s implementation guidance made available to stakeholders per Control Objective 12.1 to verify the guidance includes the following:
A.2.3.a The assessor shall examine evidence and test the software to confirm that methods are implemented to render PAN unreadable anywhere it is stored using the following methods:
Modified
p. 66 → 64
The intent of strong cryptography is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm), with strong cryptographic keys.
The intent of strong cryptography is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm) with strong cryptographic keys.
Removed
p. 67
Note: The assessor should examine several tables, files, log files and any other resources created or generated by the software to verify the PAN is rendered unreadable.
Modified
p. 67 → 65
A.2.3.c Where software creates both tokenized and truncated versions of the same PAN, the assessor shall test the software to confirm that the tokenized and truncated versions cannot be correlated to reconstruct the original PAN.
A.2.3.c Where software creates both tokenized and truncated versions of the same PAN, the assessor shall examine evidence and test the software to confirm that the tokenized and truncated versions cannot be correlated to reconstruct the original PAN.
Modified
p. 67 → 65
A.2.3.d Where software creates or generates files for use outside the software⎯for example, files generated for export or backup⎯including for storage on removable media, the assessor shall test the software, including examining a sample of generated files, such as those generated on removable media (for example, back-up tapes), to confirm that the PAN is rendered unreadable.
A.2.3.d Where software creates or generates files for use outside the software (for example, files generated for export or backup) including for storage on removable media, the assessor shall examine evidence and test the software to confirm that PAN is rendered unreadable.
Modified
p. 67 → 65
A.2.3.e If the software vendor stores the PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), the assessor shall examine vendor evidence and test the software to confirm that the PAN is rendered unreadable in accordance with this requirement.
A.2.3.e If the software vendor stores PAN for any reason (for example, because log files, debugging files, and other data sources are received from customers for debugging or troubleshooting purposes), the assessor shall examine evidence and test the software to confirm that PAN is rendered unreadable in accordance with this control objective.
Removed
p. 68
Terminal Software Evaluation In addition to the requirements and assessment procedures defined in the Terminal Software Module, the requirements and assessment procedures defined in the Secure Software Core Requirements section of this document (i.e., the “Core Module”) also apply to terminal software. Some of the requirements defined within the Terminal Software Module are extensions of Core Module requirements. Where such extensions are noted, the Terminal Software Requirements should be evaluated in conjunction with their associated Secure Software Core Requirements.
Modified
p. 68 → 66
B.1: Terminal Software Documentation B.2: Terminal Software Design B.3: Terminal Software Attack Mitigation B.4: Terminal Software Security Testing B.5: Terminal Software Implementation Guidance Purpose and Scope This section (hereinafter referred to as the “Terminal Software Module” or “this module”) defines security requirements and assessment procedures for software intended for deployment and execution on PCI-approved POI devices. Terminal software is developed explicitly for deployment and execution on PCI-approved POI devices and does not meet the definition of Firmware as defined in …
B.1: Terminal Software Documentation B.2: Terminal Software Design B.3: Terminal Software Attack Mitigation B.4: Terminal Software Security Testing B.5: Terminal Software Implementation Guidance Purpose and Scope This section (hereinafter referred to as the “Terminal Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that rely on the security features of PCI-approved POI devices to protect payment data. Software applications that are developed explicitly for deployment and execution on PCI-approved POI devices that do …
Modified
p. 68 → 66
Background PCI-approved POI devices provide a high degree of confidentiality and integrity protection for payment data and payment transactions through the implementation of strict physical and logical protection mechanisms. Software that is deployed and executed on PCI-approved POI devices must not degrade or adversely affect the protection mechanisms provided by the device. In addition, the software must not provide features or functions that could facilitate or allow those protection mechanisms to be circumvented or rendered ineffective.
Background PCI-approved POI devices provide a high degree of confidentiality and integrity protection for payment data and payment transactions through the implementation of strict physical and logical protection mechanisms. Software that is deployed and executed on PCI-approved POI devices must not degrade or adversely affect the protection mechanisms provided by the device. In addition, the software must not provide features or functions that could allow those protection mechanisms to be circumvented or rendered ineffective.
Modified
p. 70 → 68
B.1.1 The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing the software’s overall design and function including, but not limited to, the following:
B.1.1 The assessor shall examine evidence to confirm that documentation is maintained that describes the software’s overall design and function including, but not limited to, the following:
Modified
p. 70 → 68
B.1.2.a The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing all sensitive data flows including, but not limited to, the following:
B.1.2.a The assessor shall examine evidence to confirm that documentation is maintained that describes all sensitive data flows including, but not limited to, the following:
Modified
p. 71 → 69
B.1.3 The assessor shall examine all relevant documentation and evidence necessary to confirm that the software vendor maintains documentation describing all configurable options provided or made available by the software that can impact the security of sensitive data including, but not limited to, the following:
B.1.3 The assessor shall examine evidence to confirm that documentation is maintained that describes all configurable options provided or made available by the software that can impact the security of sensitive data including, but not limited to, the following:
Modified
p. 72 → 70
B.2.1 The software is intended for deployment and operation on payment terminals (i.e., PCI- approved POI devices).
B.2.1 The software is intended for deployment and operation on payment terminals (PCI-approved POI devices).
Modified
p. 72 → 70
B.2.1 The assessor shall examine all relevant software documentation and evidence necessary to determine the payment terminals upon which the software is to be deployed. For each of the payment terminals identified in the software documentation and included in the software assessment, the assessor shall examine the payment terminal’s device characteristics and compare them with the following characteristics specified in the PCI SSC’s List of Approved PTS Devices to confirm they match:
B.2.1 The assessor shall examine evidence to determine the payment terminals upon which the software is to be deployed. For each of the payment terminals identified and included in the software assessment, the assessor shall examine the payment terminal’s device characteristics and compare them with the following characteristics specified in the PCI SSC’s List of Approved PTS Devices to confirm they match:
Modified
p. 72 → 70
B.2.2.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software supports external communications.
B.2.2.a The assessor shall examine evidence (including source code) to determine whether the software supports external communications.
Modified
p. 72 → 70
To ensure software does not degrade or defeat the security mechanisms provided by the underlying payment terminal, the software must use the device- provided security features and functions in accordance with the payment terminal vendor’s security guidance/policy. This is particularly true for external communication methods. Under no circumstances should the software provide its own communication methods (e.g., VMs, IP stack, scripting languages, etc.) to control device-level interfaces. The introduction of any such function by the software could introduce new vulnerabilities …
To ensure software does not degrade or defeat the security mechanisms provided by the underlying payment terminal, the software must use the device- provided security features and functions in accordance with the payment terminal vendor’s security guidance/policy. This is particularly true for external communication methods. Under no circumstances should the software provide its own communication methods (for example, VMs, IP stack, scripting languages, and so on) to control device-level interfaces. The introduction of any such function by the software could …
Modified
p. 72 → 70
B.2.2.b Where the software supports external communications, the assessor shall examine all relevant payment terminal documentation •including the payment terminal vendor’s security guidance/policy
•to determine which external communication methods were included in the payment terminal’s PTS device evaluation.
•to
B.2.2.b Where the software supports external communications, the assessor shall examine all relevant payment terminal documentation (including the payment terminal vendor’s security guidance/policy) to determine which external communication methods were included in the payment terminal’s PTS device evaluation.
Modified
p. 72 → 70
B.2.2.c The assessor shall examine all relevant software documentation and source code necessary to confirm that the software uses only the external communication methods included in the payment terminal’s PTS device evaluation and does not implement its own external communication methods (i.e., its own IP stack).
B.2.2.c The assessor shall examine evidence (including source code) to confirm that the software uses only the external communication methods included in the payment terminal’s PTS device evaluation and does not implement its own external communication methods or IP stack.
Modified
p. 73 → 71
B.2.2.1 The assessor shall examine all relevant payment terminal documentation •including the payment terminal vendor’s security guidance/policy
•and all relevant software vendor process documentation and software design documentation to confirm that the software is developed in accordance with the payment terminal vendor’s security guidance/policy.
•and
B.2.2.1 The assessor shall examine all relevant payment terminal documentation (including the payment terminal vendor’s security guidance/policy) and all relevant software vendor process documentation and software design documentation to confirm that the software is developed in accordance with the payment terminal vendor’s security guidance/policy.
Modified
p. 73 → 71
• IP Services B.2.2.2 The assessor shall examine all relevant software documentation and source code to confirm that the software does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the payment terminal as approved and documented in the payment terminal vendor’s security guidance/policy. This includes the use of:
• IP Services B.2.2.2 The assessor shall examine evidence (including source code) to confirm that the software does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the payment terminal as approved and documented in the payment terminal vendor’s security guidance/policy. This includes the use of:
Modified
p. 73 → 71
B.2.3.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software facilitates encryption of sensitive data. Where the software does provide such a function, the assessor shall confirm the software does not bypass or render ineffective any encryption methods or account data security methods implemented by the payment terminal as follows:
B.2.3.a The assessor shall examine evidence (including source code) to determine whether the software provides encryption of sensitive data. Where the software does provide such a function, the assessor shall confirm the software does not bypass or render ineffective any encryption methods or account data security methods implemented by the payment terminal as follows:
Removed
p. 74
B.2.3.c The assessor shall examine all relevant software documentation and source code necessary to confirm that the software does not bypass or render ineffective any encryption methods provided by the payment terminal in accordance with the payment terminal vendor’s security guidance/policy.
Modified
p. 74 → 72
B.2.3.d Where the software facilitates encryption of sensitive data, but the payment terminal is not required to provide approved encryption methods (per the PCI PTS POI Standard), the assessor shall examine all relevant software documentation and source code necessary to confirm that the encryption methods used or implemented by the software for encrypting sensitive data provide “strong cryptography” and are implemented in accordance with Control Objectives 7.1 and 7.2.
B.2.3.d Where the software provides encryption of sensitive data, but the payment terminal is not required to provide approved encryption methods (per the PCI PTS POI Standard), the assessor shall examine evidence (including source code) to confirm that the encryption methods used or implemented by the software for encrypting sensitive data provide “strong cryptography” and are implemented in accordance with Control Objectives 7.1 and 7.2.
Modified
p. 74 → 72
B.2.4.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software requires random values to be generated for any cryptographic operations involving sensitive data or sensitive functions.
B.2.4.a The assessor shall examine evidence (including source code) to determine whether the software requires random values to be generated for any cryptographic operations involving sensitive data or sensitive functions.
Modified
p. 74 → 72
B.2.4.b Where the software requires random values for cryptographic operations involving sensitive data or sensitive functions, the assessor shall examine all relevant payment terminal documentation •including payment terminal vendor security guidance/policy
•necessary to determine all of the random number generation functions included in the payment terminal’s PTS device evaluation.
•necessary
B.2.4.b Where the software requires random values for cryptographic operations involving sensitive data or sensitive functions, the assessor shall examine all relevant payment terminal documentation (including payment terminal vendor security guidance/policy) to determine all of the random number generation functions included in the payment terminal’s PTS device evaluation.
Removed
p. 75
B.2.5.b The assessor shall examine all relevant software documentation and source code necessary to confirm that the software does not facilitate sharing of clear-text account data directly with other software through its own logical interfaces.
Modified
p. 75 → 73
B.2.5 The software does not facilitate, through its own logical interface(s), the sharing of clear-text account data directly with other software.
B.2.5 The software does not provide, through its own logical interface(s), the sharing of clear-text account data directly with other software.
Modified
p. 75 → 73
B.2.5.a The assessor shall examine all relevant software documentation and source code necessary to determine all logical interfaces of the software, including:
B.2.5.a The assessor shall examine evidence (including source code) to determine all logical interfaces of the software, including:
Modified
p. 75 → 73
B.2.5.c The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software using all software functions that handle account data to confirm that the software does not facilitate the sharing of clear-text account data directly with other software through its own logical interfaces.
B.2.5.c The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall test the software using all software functions that handle account data to confirm that the software does not allow the sharing of clear-text account data directly with other software through its own logical interfaces.
Modified
p. 76 → 74
B.2.6.a The assessor shall examine all relevant software documentation and source code necessary to determine whether and how the software connects to and/or uses any shared resources provided by the payment terminal, and to confirm that:
B.2.6.a The assessor shall examine evidence (including source code) to determine whether and how the software connects to and/or uses any shared resources provided by the payment terminal, and to confirm that:
Modified
p. 76 → 74
• The software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1 includes detailed instructions for how to configure the software to ensure secure integration with shared resources.
• The guidance required in Control Objectives 12.1 and B.5.1 includes detailed instructions for how to configure the software to ensure secure integration with shared resources.
Modified
p. 76 → 74
• The software vendor’s implementation guidance for secure integration with such shared resources is in accordance with the payment terminal vendor’s security guidance/policy.
• The required guidance for secure integration with shared resources is in accordance with the payment terminal vendor’s security guidance/policy.
Modified
p. 76 → 74
B.2.6.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software using all software functions that use or integrate shared resources to confirm that any connections to or use of shared resources are handled securely.
B.2.6.b The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall test the software using all software functions that use or integrate shared resources to confirm that any connections to or use of shared resources are handled securely.
Modified
p. 77 → 75
B.2.7.a The assessor shall examine all relevant payment terminal documentation •including the payment terminal vendor’s security guidance/policy
•necessary to determine whether and how application segregation is enforced by the payment terminal.
•necessary
B.2.7.a The assessor shall examine all relevant payment terminal documentation (including the payment terminal vendor’s security guidance/policy) to determine whether and how application segregation is enforced by the payment terminal.
Modified
p. 77 → 75
B.2.7.b The assessor shall examine all relevant software documentation and source code necessary to confirm that the software does not introduce any function(s) that would allow it to bypass or defeat any device-level application segregation controls.
B.2.7.b The assessor shall examine evidence (including source code) to confirm that the software does not introduce any function(s) that would allow it to bypass or defeat any device- level application segregation controls.
Modified
p. 77 → 75
B.2.8 All software files are cryptographically signed to facilitate cryptographic authentication of the software files by the payment terminal firmware.
B.2.8 All software files are cryptographically signed to enable cryptographic authentication of the software files by the payment terminal firmware.
Modified
p. 77 → 75
B.2.8.a The assessor shall examine the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1 to confirm it includes detailed instructions for how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal.
B.2.8.a The assessor shall examine the guidance required in Control Objectives 12.1 and B.5.1 to confirm that it includes detailed instructions for how to cryptographically sign the software files in a manner that enables the cryptographic authentication of all such files by the payment terminal.
Modified
p. 77 → 75
B.2.8.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall confirm that all software files are cryptographically signed in a manner that facilitates the cryptographic authentication of all software files.
B.2.8.b The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall confirm that all software files are cryptographically signed in a manner that enables the cryptographic authentication of all software files.
Removed
p. 78
B.2.9.a The assessor shall examine all relevant software documentation and source code necessary to determine whether the software supports the use of data entry prompts and/or prompt files. Where the software supports such features, the assessor shall confirm the software protects the integrity of those prompts as defined in Test Requirements B.2.9.b through B.2.9.c.
Modified
p. 78 → 76
B.2.8.d The assessor shall examine all relevant software documentation and source code necessary to determine whether and how the software supports EMV® payment transactions. Where EMV payment transactions are supported by the software, the assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall confirm that all EMV Certification Authority …
B.2.8.d The assessor shall examine evidence (including source code) to determine whether and how the software supports EMV® payment transactions. Where EMV payment transactions are supported by the software, the assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall confirm that all EMV Certification Authority Public Keys are cryptographically signed in a manner that enables the …
Modified
p. 78 → 76
Sensitive data (including PIN and other account data) captured and handled by the software and underlying payment terminal is often controlled using prompt files.
Modified
p. 78 → 76
Prompt files are configuration files that control software display prompts. To preserve the integrity of the prompts, prompt files should be stored and managed securely. Anywhere clear-text data entry is facilitated by the software, prompt controls should be implemented.
Prompt files are configuration files that control software display prompts. To preserve the integrity of the prompts, prompt files should be stored and managed securely. Anywhere clear-text data entry is allowed by the software, prompt controls should be implemented.
Modified
p. 79 → 77
B.2.9.c The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall confirm that all prompt files are cryptographically signed in a manner that facilitates the cryptographic authentication of those files by the payment terminal in accordance with B.2.8.
B.2.9.c The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall confirm that all prompt files are cryptographically signed in a manner that enables the cryptographic authentication of those files by the payment terminal in accordance with B.2.8.
Removed
p. 80
B.3.1.a The assessor shall examine all relevant software documentation and source code necessary to identify all external inputs to the software. For each user or other external input, the assessor shall examine all relevant software documentation and source code to confirm that inputs conform to a list of expected characteristics and that all input that does not conform to expected characteristics is rejected by the software or otherwise handled securely.
B.3.1.1.a The assessor shall examine all relevant software documentation and source code necessary to identify all terminal software functions where string values are passed as inputs to confirm that all strings are checked for text or data that can be erroneously or maliciously interpreted as a command.
B.3.1.1.a The assessor shall examine all relevant software documentation and source code necessary to identify all terminal software functions where string values are passed as inputs to confirm that all strings are checked for text or data that can be erroneously or maliciously interpreted as a command.
Modified
p. 80 → 78
Any terminal software functions that accept externally supplied data (directly or indirectly) is a potential attack vector, particularly when that data is evaluated by a command interpreter.
Any terminal software functions that accept externally supplied data (directly or indirectly) is a potential attack vector, particularly where the data is processed by an interpreter.
Modified
p. 80 → 78
Injection attacks are common for almost all types of software and are intended to manipulate input data in a way that causes software to behave unexpectedly or unintentionally. For example, software that accepts externally supplied information, such as a file name or file path to construct a search command, can be easily manipulated to disclose information about sensitive files and resources that were never intended to be accessed through the software interface. To protect against this and other types of …
Injection attacks are common for almost all types of software and are intended to manipulate input data in a way that causes software to behave unexpectedly or unintentionally. For example, software that accepts externally supplied information, such as a file name or file path to construct a search command, can be easily manipulated to disclose information about sensitive files and resources that were never intended to be accessed through the software interface. To protect against this and other types of …
Modified
p. 80 → 78
B.3.1.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software by attempting to supply each user or other external input with invalid or unexpected characteristics to confirm that the software validates all inputs and either rejects or securely handles all unexpected characteristics.
B.3.1.b The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall test the software by attempting to supply each user or other external input with invalid or unexpected characteristics to confirm that the software validates all inputs and either rejects or securely handles all unexpected characteristics.
Modified
p. 80 → 78
Externally supplied inputs that can be interpreted as commands are particularly susceptible to injection attacks. Even if externally supplied inputs are processed or transformed in some way (e.g., augmented with additional data or sanitized), they may still be susceptible.
Externally supplied inputs that can be interpreted as commands are particularly susceptible to injection attacks. Even if externally supplied inputs are processed or transformed in some way (for example, augmented with additional data or sanitized), they may still be susceptible.
Modified
p. 81 → 79
B.3.1.2.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that handle buffers and process data supplied by external inputs. For each of the noted functions, the assessor shall confirm that each of the identified functions:
B.3.1.2.a The assessor shall examine evidence (including source code) to identify all software functions that handle buffers and process data supplied from untrusted sources. For each of the noted functions, the assessor shall confirm that each of the identified functions:
Modified
p. 81 → 79
• Conducts checks that confirm that buffers are sized appropriately for the data they are intended to handle, including consideration for underflows and overflows.
• Conducts checks to confirm that buffers are sized appropriately for the data they are intended to handle, including consideration for underflows and overflows.
Modified
p. 81 → 79
B.3.1.2.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.) the assessor shall test the software by attempting to supply each noted function with inputs that violate buffer size thresholds to confirm that the software either rejects or securely handles all such attempts.
B.3.1.2.b The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall test the software by attempting to supply each noted function with inputs that violate buffer size thresholds to confirm that the software either rejects or securely handles all such attempts.
Removed
p. 82
B.3.2.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that handle the sensitive data predefined in Control Objective 1.2. For each of the noted software functions, the assessor shall confirm that each function:
B.3.3 Race conditions are avoided. B.3.3.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that rely on synchronous processing. For each of the noted functions, the assessor shall confirm that protection mechanisms have been implemented in the software to mitigate race conditions.
B.3.3 Race conditions are avoided. B.3.3.a The assessor shall examine all relevant software documentation and source code necessary to identify all software functions that rely on synchronous processing. For each of the noted functions, the assessor shall confirm that protection mechanisms have been implemented in the software to mitigate race conditions.
Modified
p. 82 → 80
• Checks return values for the presence of sensitive data
• Checks return values for the presence of sensitive data.
Modified
p. 82 → 80
B.3.2.b The assessor shall install and configure the software in accordance with the software vendor’s implementation guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods (commercial tools, scripts, etc.), the assessor shall test each software function that handles sensitive data by attempting to manipulate the software in a manner that generates an unhandled exception to confirm that error conditions do not expose sensitive data.
B.3.2.b The assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall test each software function that handles sensitive data by attempting to manipulate the software in a manner that generates an unhandled exception to confirm that error conditions do not expose sensitive data.
Modified
p. 84 → 82
B.4.1.a The assessor shall examine all relevant software documentation and evidence necessary to confirm that the software vendor maintains a documented process in accordance with Control Objective 10.2 for testing the software for vulnerabilities prior to each update or release, and that the documented process includes detailed descriptions of how the vendor tests for the following:
B.4.1.a The assessor shall examine evidence to confirm that the software vendor maintains a documented process in accordance with Control Objective 10.2 for testing the software for vulnerabilities prior to each update or release, and that the documented process includes detailed descriptions of how the vendor tests for the following:
Modified
p. 84 → 82
B.4.1.b The assessor shall examine all relevant documentation and evidence necessary (such as software testing artifacts, etc.) to confirm that the software is tested for vulnerabilities prior to each release and that the testing covers the following:
B.4.1.b The assessor shall examine evidence to confirm that the software is tested for vulnerabilities prior to each release and that the testing covers the following:
Removed
p. 86
B.5.1 The assessor shall examine all relevant software documentation and evidence necessary to confirm that the software vendor provides detailed implementation guidance to stakeholders in accordance with Control Objective 12.1 on how to securely implement and operate the software for all applicable payment terminals.
Modified
p. 86 → 84
B.5.1.1 The assessor shall examine software vendor implementation guidance to confirm it includes detailed instructions on how to configure all available security options and parameters of the software in accordance with Control Objective B.1.3.
B.5.1.1 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions on how to configure all available security options and parameters of the software in accordance with Control Objective B.1.3.
Modified
p. 86 → 84
B.5.1.2 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions on how to securely configure the software to use the security features and functions of the payment terminal where applicable.
B.5.1.2 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions on how to securely configure the software to use the security features and functions of the payment terminal where applicable.
Modified
p. 86 → 84
B.5.1.3 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions on how to configure the software to securely integrate or use any shared resources provided by the payment terminal in accordance with Control Objective B.2.6.
B.5.1.3 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions on how to configure the software to securely integrate or use any shared resources provided by the payment terminal in accordance with Control Objective B.2.6.
Modified
p. 87 → 85
B.5.1.4 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions on how to cryptographically sign the software files in a manner that facilitates the cryptographic authentication of all such files by the payment terminal in accordance with Control Objective B.2.8.
B.5.1.4 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions on how to cryptographically sign the software files in a manner that enables the cryptographic authentication of all such files by the payment terminal in accordance with Control Objective B.2.8.
Modified
p. 87 → 85
B.5.1.5 The assessor shall examine the software vendor implementation guidance to confirm it includes detailed instructions for stakeholders to cryptographically sign all prompt files in accordance with Control Objective B.2.9.
B.5.1.5 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions for stakeholders to cryptographically sign all prompt files in accordance with Control Objective B.2.9.
Modified
p. 87 → 85
B.5.2 The assessor shall examine the payment terminal vendor’s security guidance/policy and the software implementation guidance required in Control Objective B.5.1 to confirm that the software implementation guidance aligns with the payment terminal vendor’s security guidance/policy.
B.5.2 The assessor shall examine evidence (including the payment terminal vendor’s security guidance/policy and the guidance required in Control Objective B.5.1) to confirm that the guidance aligns with the payment terminal vendor’s security guidance/policy.