Document Comparison
PCI-Secure-Software-Standard-v1_0.pdf
→
PCI-Secure-Software-Standard-v1_1.pdf
73% similar
67 → 87
Pages
21538 → 29566
Words
194
Content Changes
Content Changes
194 content changes. 95 administrative changes (dates, page numbers) hidden.
Added
p. 7
Equally important is the need for software vendors to understand all of the security requirements in this document and consider how the software vendor’s security controls and processes work together as a whole to satisfy the security requirements rather than focusing on any single requirement in isolation.
Secure Software Core Requirements: General security requirements that apply to all types of payment software regardless of the software’s function or underlying technology.
Module A
• Account Data Protection Requirements: Additional security requirements for payment software that stores, processes, or transmits account data.
Module B
• Terminal Software Requirements: Additional security requirements for payment software intended for deployment and operation on payment terminals (i.e., PCI-approved POI devices).
Within each of the sections defined above, the PCI Secure Software Requirements are further subdivided into the following components:
Use of a Test Platform To facilitate testing software in accordance with the assessment procedures contained in this standard, it may be necessary for …
Secure Software Core Requirements: General security requirements that apply to all types of payment software regardless of the software’s function or underlying technology.
Module A
• Account Data Protection Requirements: Additional security requirements for payment software that stores, processes, or transmits account data.
Module B
• Terminal Software Requirements: Additional security requirements for payment software intended for deployment and operation on payment terminals (i.e., PCI-approved POI devices).
Within each of the sections defined above, the PCI Secure Software Requirements are further subdivided into the following components:
Use of a Test Platform To facilitate testing software in accordance with the assessment procedures contained in this standard, it may be necessary for …
Added
p. 17
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.
Built-in accounts with known credentials such as default or empty passwords, or default keys are often overlooked during installation, initial configuration, or use, and can be used by a malicious user to bypass access controls. Therefore, the software should not use or rely on the default credentials for its operation upon installation, initialization, or first use.
Built-in accounts with known credentials such as default or empty passwords, or default keys are often overlooked during installation, initial configuration, or use, and can be used by a malicious user to bypass access controls. Therefore, the software should not use or rely on the default credentials for its operation upon installation, initialization, or first use.
Added
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.
(continued on next page) 3.2.b The assessor shall test the software to confirm that all available functions or services that retain transient sensitive data are supported by vendor evidence and do not use immutable objects.
(continued on next page) 3.2.b The assessor shall test the software to confirm that all available functions or services that retain transient sensitive data are supported by vendor evidence and do not use immutable objects.
Added
p. 24
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.
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.
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.
Added
p. 30
• A formal owner of the software is assigned. This may be a role for a specific individual or a specific name, but evidence must clearly show an individual who is accountable for the security of the software.
Added
p. 39
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.
• Only documented cryptographic algorithms and modes are used in the software and are implemented correctly, and
• 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 …
• Only documented cryptographic algorithms and modes are used in the software and are implemented correctly, and
• 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 …
Added
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.
Added
p. 53
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.
Added
p. 56
Most software vulnerabilities are introduced as a result of coding errors, bad design, improper implementation of software functionality, or the use of vulnerable components.
• 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 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.
Added
p. 62
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:
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.
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.
Added
p. 68
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 the PCI PIN Transaction Security (PTS) Point-of-Interaction (POI) Modular Security Requirements (hereinafter referred to as the “PCI PTS POI Standard”).
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 …
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 …
Added
p. 69
Additional Considerations Some assessment procedures in this module require examination of documentation describing the security features and functions of the underlying payment terminal. The terminal software vendor should work with their assessor(s)
•as well as the respective payment terminal vendors for each of the devices to be included as part of the terminal software evaluation
•to identify and compile all device documentation needed for the terminal software evaluation. For more information about Secure Software assessment preparation and activities, please refer to the Secure Software Program Guide.
•as well as the respective payment terminal vendors for each of the devices to be included as part of the terminal software evaluation
•to identify and compile all device documentation needed for the terminal software evaluation. For more information about Secure Software assessment preparation and activities, please refer to the Secure Software Program Guide.
Added
p. 70
Control Objectives Test Requirements Guidance Control Objective B.1: Terminal Software Documentation The software architecture is documented and includes diagrams that describe all software components and services in use and how they interact.
B.1.1 The software vendor maintains documentation that describes all software components, interfaces, and services provided or used by the software.
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:
• All third-party and open-source components, external services, and Application Programming Interfaces (APIs) used by the software.
• All User Interfaces (UI) and APIs provided or made accessible by the software.
Software vendors should also maintain detailed documentation that clearly and effectively describes the overall design and function of its software, including all services (internal and external), components, and functions used and provided by the software, and how those services, …
B.1.1 The software vendor maintains documentation that describes all software components, interfaces, and services provided or used by the software.
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:
• All third-party and open-source components, external services, and Application Programming Interfaces (APIs) used by the software.
• All User Interfaces (UI) and APIs provided or made accessible by the software.
Software vendors should also maintain detailed documentation that clearly and effectively describes the overall design and function of its software, including all services (internal and external), components, and functions used and provided by the software, and how those services, …
Added
p. 71
• All inputs, outputs, and possible error conditions for each function that handles sensitive data.
• All cryptographic algorithms, modes of operation, and associated key management practices for all functions that employ cryptography for the protection of sensitive data.
B.1.3 The software vendor maintains documentation that describes all configurable options that can affect the security of sensitive data.
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:
• All configurable options that could allow access to sensitive data.
• All configurable options that could enable modification of any mechanisms used to protect sensitive data.
• All remote access features, functions, and parameters provided or made available by the software.
• All remote update features, functions, and parameters provided or made available …
• All cryptographic algorithms, modes of operation, and associated key management practices for all functions that employ cryptography for the protection of sensitive data.
B.1.3 The software vendor maintains documentation that describes all configurable options that can affect the security of sensitive data.
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:
• All configurable options that could allow access to sensitive data.
• All configurable options that could enable modification of any mechanisms used to protect sensitive data.
• All remote access features, functions, and parameters provided or made available by the software.
• All remote update features, functions, and parameters provided or made available …
Added
p. 72
B.2.1 The software is intended for deployment and operation on payment terminals (i.e., PCI- approved POI devices).
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:
• PTS approval number
• Hardware version number
• Firmware version number(s) Payment terminals 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 these payment terminals should use the approved features and functions provided by the payment terminal rather than implementing its …
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:
• PTS approval number
• Hardware version number
• Firmware version number(s) Payment terminals 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 these payment terminals should use the approved features and functions provided by the payment terminal rather than implementing its …
Added
p. 73
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.
Payment terminal vendor security guidance/policy is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol (as well as other PTS) requirements as part of a PCI-approved POI device evaluation.
B.2.2.2 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:
• Link Layer protocols
• Link Layer protocols
• 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 …
•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.
Payment terminal vendor security guidance/policy is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol (as well as other PTS) requirements as part of a PCI-approved POI device evaluation.
B.2.2.2 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:
• Link Layer protocols
• Link Layer protocols
• 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 …
Added
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.
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.4 The software uses only the random number generation function(s) included in the payment terminal’s PTS device evaluation for all cryptographic operations involving sensitive data or sensitive functions where random values are required and does not implement its own random number generation …
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.4 The software uses only the random number generation function(s) included in the payment terminal’s PTS device evaluation for all cryptographic operations involving sensitive data or sensitive functions where random values are required and does not implement its own random number generation …
Added
p. 75
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.
Note: The software is allowed to share clear-text account data directly with the payment terminal’s firmware.
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:
• All logical interfaces and the purpose and function of each.
• The logical interfaces intended for sharing clear-text account data, such as those used to pass clear-text account data back to the approved firmware of the payment terminal.
• The logical interfaces not intended for sharing of clear-text account data, such as those for communication with other software.
Many payment terminals provide mechanisms for the secure reading and exchange of data (SRED). These mechanisms are rigorously tested as part of the payment terminal’s PTS device evaluation to confirm that the confidentially and integrity of clear- text …
Note: The software is allowed to share clear-text account data directly with the payment terminal’s firmware.
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:
• All logical interfaces and the purpose and function of each.
• The logical interfaces intended for sharing clear-text account data, such as those used to pass clear-text account data back to the approved firmware of the payment terminal.
• The logical interfaces not intended for sharing of clear-text account data, such as those for communication with other software.
Many payment terminals provide mechanisms for the secure reading and exchange of data (SRED). These mechanisms are rigorously tested as part of the payment terminal’s PTS device evaluation to confirm that the confidentially and integrity of clear- text …
Added
p. 76
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:
• 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 software vendor’s implementation guidance for secure integration with such shared resources is in accordance with the payment terminal vendor’s security guidance/policy.
Where the software uses or integrates shared resources provided by the payment terminal, the software must use or integrate resources in accordance with the payment terminal vendor’s guidance/policy. Failure to use such shared resources in accordance with payment terminal guidance puts any sensitive data shared with such resources at greater risk of unauthorized disclosure.
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 includes detailed instructions for how to configure the software to ensure secure integration with shared resources.
• 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.
Where the software uses or integrates shared resources provided by the payment terminal, the software must use or integrate resources in accordance with the payment terminal vendor’s guidance/policy. Failure to use such shared resources in accordance with payment terminal guidance puts any sensitive data shared with such resources at greater risk of unauthorized disclosure.
B.2.6.b The assessor shall install and configure the software in accordance with …
Added
p. 77
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.
Many payment terminals enforce logical separation between software applications. In the context of this module, software applications are logical entities that do not meet the PTS definition of “firmware”.
Logical application segmentation controls are intended to prevent one application on the payment terminal from interfering or tampering with other applications. However, these logical segregation controls are not intended to prevent applications from sharing data. They are mainly intended to prevent applications from modifying the structure or function of other applications or the payment terminal’s firmware.
To preserve the integrity of payment terminal application-segregation controls, all terminal software should adhere to those segregation controls and not include or introduce any function(s) that would allow the software to be used (intentionally or unintentionally) to bypass or …
•including the payment terminal vendor’s security guidance/policy
•necessary to determine whether and how application segregation is enforced by the payment terminal.
Many payment terminals enforce logical separation between software applications. In the context of this module, software applications are logical entities that do not meet the PTS definition of “firmware”.
Logical application segmentation controls are intended to prevent one application on the payment terminal from interfering or tampering with other applications. However, these logical segregation controls are not intended to prevent applications from sharing data. They are mainly intended to prevent applications from modifying the structure or function of other applications or the payment terminal’s firmware.
To preserve the integrity of payment terminal application-segregation controls, all terminal software should adhere to those segregation controls and not include or introduce any function(s) that would allow the software to be used (intentionally or unintentionally) to bypass or …
Added
p. 78
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 Public Keys are cryptographically signed in a manner that facilitates the cryptographic authentication of those files by the payment terminal.
Where terminal software supports EMV payment transactions, the EMV Certificate Authority public keys should also be signed and cryptographically authenticated using the same methods and procedures as the terminal software files.
B.2.9 The integrity of software prompt files is protected in accordance with Control Objective B.2.8.
B.2.9.a The assessor shall examine all relevant …
Where terminal software supports EMV payment transactions, the EMV Certificate Authority public keys should also be signed and cryptographically authenticated using the same methods and procedures as the terminal software files.
B.2.9 The integrity of software prompt files is protected in accordance with Control Objective B.2.8.
B.2.9.a The assessor shall examine all relevant …
Added
p. 79
Many prompt files are stored within a secure boundary of the device, such as a Secure Chip or Secure Element or within a Trusted Execution Environment. When prompt files are to be maintained in shared storage locations, the files should be cryptographically signed and authenticated by the payment terminal prior to installation or execution.
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 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.
Added
p. 80
B.3.1 The software validates all user and other external inputs.
Note: Control Objectives B.3.1 through B.3.3 are extensions of Control Objective 4.2. Validation of these control objectives should be performed at the same time.
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.
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.
Injection attacks are common for almost all types of software and are intended to manipulate input data in a way that causes software …
Note: Control Objectives B.3.1 through B.3.3 are extensions of Control Objective 4.2. Validation of these control objectives should be performed at the same time.
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.
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.
Injection attacks are common for almost all types of software and are intended to manipulate input data in a way that causes software …
Added
p. 81
Therefore, all inputs that can be interpreted as commands must be handled securely so that the execution of any constructed commands is controlled, as opposed to blindly executing whatever commands are included in the string.
B.3.1.2 The software checks inputs and rejects or otherwise securely handles any inputs that violate buffer size or other memory allocation thresholds.
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:
• Uses only unsigned variables to define buffer sizes.
• Conducts checks that confirm that buffers are sized appropriately for the data they are intended to handle, including consideration for underflows and overflows.
• Rejects or otherwise securely handles any inputs that violate buffer size or other memory allocation thresholds.
Payment terminals and terminal software …
B.3.1.2 The software checks inputs and rejects or otherwise securely handles any inputs that violate buffer size or other memory allocation thresholds.
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:
• Uses only unsigned variables to define buffer sizes.
• Conducts checks that confirm that buffers are sized appropriately for the data they are intended to handle, including consideration for underflows and overflows.
• Rejects or otherwise securely handles any inputs that violate buffer size or other memory allocation thresholds.
Payment terminals and terminal software …
Added
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:
• Checks return values for the presence of sensitive data
• Processes the return values in a way that does not inadvertently “leak” sensitive data.
Another common technique used by attackers to compromise sensitive data that is stored, processed, or transmitted by software is to manipulate the software in a way that generates unhandled exceptions.
Unhandled exceptions are error conditions that the software vendor has not anticipated and, therefore, has not factored into the software design. If an attacker can manipulate a software function that is known to handle sensitive data in a way that generates a condition that the software does not handle properly, it is possible that the software may …
• Checks return values for the presence of sensitive data
• Processes the return values in a way that does not inadvertently “leak” sensitive data.
Another common technique used by attackers to compromise sensitive data that is stored, processed, or transmitted by software is to manipulate the software in a way that generates unhandled exceptions.
Unhandled exceptions are error conditions that the software vendor has not anticipated and, therefore, has not factored into the software design. If an attacker can manipulate a software function that is known to handle sensitive data in a way that generates a condition that the software does not handle properly, it is possible that the software may …
Added
p. 83
To protect against race conditions, protection mechanisms should be implemented by the terminal software to control sequential processing more tightly. Using the example described above, a “locking” mechanism could be used to prevent updates to the file until the file can be processed completely.
Regardless of the methods used, any terminal software that requires sequential processing of data for its operation should implement protections to avoid race conditions.
Regardless of the methods used, any terminal software that requires sequential processing of data for its operation should implement protections to avoid race conditions.
Added
p. 84
B.4.1 A documented process is maintained and followed for testing software for vulnerabilities prior to each update or release.
Note: This control objective is an extension of Control Objective 10.2. Validation of these control objectives should be performed at the same time.
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:
• The presence or use of any unnecessary ports and protocols.
• The presence or use of any unnecessary ports and protocols.
Note: This control objective is an extension of Control Objective 10.2. Validation of these control objectives should be performed at the same time.
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:
• The presence or use of any unnecessary ports and protocols.
• The presence or use of any unnecessary ports and protocols.
Added
p. 84
• The presence of any default user accounts with default or static access credentials.
• The presence of any hard-coded authentication credentials in code or in configuration files.
• The presence of any test data or test accounts.
• The presence of any faulty or ineffective software security controls.
Many software vulnerabilities are the result of the software vendor’s failure to remove test functions or data. These lingering functions and data can provide an attacker with a path to compromise the software.
Before software is released to the public, it must be tested to confirm that test functions and data are not included in the release version. Examples of such functions and data that must be explicitly removed prior to release include:
• Any communication ports or protocols that are not absolutely required for software operation.
• Any functions that allow the unintended storage, transmission, or output of any clear- text account data.
• Any hard-coded authentication credentials …
• The presence of any hard-coded authentication credentials in code or in configuration files.
• The presence of any test data or test accounts.
• The presence of any faulty or ineffective software security controls.
Many software vulnerabilities are the result of the software vendor’s failure to remove test functions or data. These lingering functions and data can provide an attacker with a path to compromise the software.
Before software is released to the public, it must be tested to confirm that test functions and data are not included in the release version. Examples of such functions and data that must be explicitly removed prior to release include:
• Any communication ports or protocols that are not absolutely required for software operation.
• Any functions that allow the unintended storage, transmission, or output of any clear- text account data.
• Any hard-coded authentication credentials …
Added
p. 85
• The presence of any default user accounts with static access credentials.
Note: This control objective is an extension of Control Objective 12.1. Validation of these control objectives should be performed at the same time.
Note: This control objective is an extension of Control Objective 12.1. Validation of these control objectives should be performed at the same time.
Added
p. 86
B.5.1 The software vendor provides implementation guidance on how to implement and operate the software securely for the payment terminals on which it is to be deployed.
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.
Because many security features used by terminal software are provided by the underlying payment terminal, the terminal software vendor should include instructions in its implementation guidance on how to configure all the available security features of both the terminal software and underlying payment terminal where applicable.
B.5.1.1 Implementation guidance includes detailed instructions for how to configure all available security options and parameters of the software.
B.5.1.1 The assessor shall examine software vendor implementation guidance to confirm it includes detailed instructions on how to …
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.
Because many security features used by terminal software are provided by the underlying payment terminal, the terminal software vendor should include instructions in its implementation guidance on how to configure all the available security features of both the terminal software and underlying payment terminal where applicable.
B.5.1.1 Implementation guidance includes detailed instructions for how to configure all available security options and parameters of the software.
B.5.1.1 The assessor shall examine software vendor implementation guidance to confirm it includes detailed instructions on how to …
Added
p. 87
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.5 Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files.
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.2 Implementation guidance adheres to payment terminal vendor guidance on the secure configuration of the payment terminal.
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.
Software implementation guidance must exclude instructions that conflict with the guidance and recommendations …
B.5.1.5 Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files.
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.2 Implementation guidance adheres to payment terminal vendor guidance on the secure configuration of the payment terminal.
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.
Software implementation guidance must exclude instructions that conflict with the guidance and recommendations …
Modified
p. 1
Payment Card Industry Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.0
Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.1
Removed
p. 5
The Secure Software Requirements are organized as following:
• Secure Software Core Requirements apply to all types of payment software submitted for validation under the PCI Software Security Framework, regardless of the software’s functionality or underlying technology.
• Account Data Protection applies to payment applications that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
• Secure Software Core Requirements apply to all types of payment software submitted for validation under the PCI Software Security Framework, regardless of the software’s functionality or underlying technology.
• Account Data Protection applies to payment applications that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
Modified
p. 5
The PCI Secure Software Standard is intended for use as part of the PCI Software Security Framework. Payment software vendors (hereafter referred to as “vendor” or “vendors”) wishing to validate 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. Software vendors wishing to validate their payment software under the PCI Software Security Framework would do so to this PCI Secure Software Standard.
Modified
p. 5
Terminology A list of applicable terms and definitions specific to the PCI Secure Software Framework 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.or/document_library.
Modified
p. 5
Secure Software Requirements The PCI Secure Software Requirements ensure that payment software is designed, engineered, developed, and maintained in a manner that protects payment transactions and data, minimizes vulnerabilities, and defends itself from attacks.
PCI Secure Software Requirements The security requirements defined within the PCI Secure Software Standard (hereafter referred to as “PCI Secure Software Requirements”) ensure that payment software is designed, engineered, developed, and maintained in a manner that protects payment transactions and data, minimizes vulnerabilities, and defends against attacks.
Modified
p. 6
Processes used by the software vendor to identify and support software security controls.
Modified
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.).
Modified
p. 6
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.
Modified
p. 6
Note that the payment software vendor may be expected to provide such guidance even when the specific setting: a. Cannot be controlled by the payment software once the software is installed by the customer; or b. Is the responsibility of the customer, not the software vendor.
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 the software is installed by the customer; or b. Is the responsibility of the customer and not the software vendor.
Modified
p. 6
Coverage of all supported platforms and execution environments for the payment software.
Modified
p. 6
Coverage of all tools (reporting tools, logging tools, etc.) and functions (e.g., system calls or APIs) used by or within the payment software to access critical assets.
Modified
p. 6
Coverage of all payment software components and dependencies, including supported execution platforms or environments, third-party and open-source libraries, services, and other required functions.
Modified
p. 6
Coverage of any other types of software necessary for a full implementation of the payment software.
Removed
p. 7
Equally important is the need for vendors to take a holistic view of these software security controls. Vendors should understand all of the requirements in this document and consider how they work together as a whole rather than focusing on any single requirement in isolation.
Modified
p. 7
For this approach to be successful, 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 vendor as sensitive data1
•will depend on the vendor’s risk-management priorities and processes. While this approach provides the vendor with flexibility to implement software security controls based on identified risk, the vendor must be able to demonstrate …
•for example, additional data elements identified by the vendor as sensitive data1
•will depend on the vendor’s risk-management priorities and processes. While this approach provides the vendor with flexibility to implement software security controls based on identified risk, the vendor must be able to demonstrate …
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 …
•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 …
Modified
p. 7
Where a PCI Secure Software requirement does not define a specific level or rigor or frequency for periodic or recurring activities
•for example, the maximum period in which a vendor must provide a security update to fix a known vulnerability
•the vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the vendor must be supported by documented risk assessments and the resultant risk-management decisions. The vendorshould be able to demonstrate …
•for example, the maximum period in which a vendor must provide a security update to fix a known vulnerability
•the vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the vendor must be supported by documented risk assessments and the resultant risk-management decisions. The vendor
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 which a software vendor must provide a security update to fix a known vulnerability
•the software vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the software vendor must be supported by documented risk assessments and the resultant risk-management decisions. The vendor must be …
•for example, the maximum period in which a software vendor must provide a security update to fix a known vulnerability
•the software vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the software vendor must be supported by documented risk assessments and the resultant risk-management decisions. The vendor must be …
Removed
p. 8
1. Minimizing the Attack Surface
2. Software Protection Mechanisms
3. Secure Software Operations
4. Secure Software Lifecycle Management Each security objective includes a description of its intent and is further subdivided as follows:
2. Software Protection Mechanisms
3. Secure Software Operations
4. Secure Software Lifecycle Management Each security objective includes a description of its intent and is further subdivided as follows:
Modified
p. 8
• The specific software security controls and outcomes required to satisfy the parent security objective. While all control objectives must be met to be validated to this PCI Secure Software Standard, vendors may define the specific controls, tools, methods, and techniques they use to meet each control objective.
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.
• 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.
Modified
p. 8
• 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 will need to justify and document their testing approach as described in the “Validation Procedures and Test Requirements section.”
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.
• 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.
Modified
p. 8
• Additional information to help vendors and assessors further understand the intent of the control objective and how it could be met. The guidance may include best practices to be considered as well as examples of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a vendor may use to meet a control objective, nor does it replace or amend the control objective to …
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 of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a software vendor may use to meet a control objective, nor does it replace or amend the control …
• 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 of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a software vendor may use to meet a control objective, nor does it replace or amend the control …
Removed
p. 9
• How the assessor verified the evidence provided by the third-party as being appropriate for the assessor to rely on the test results.
Modified
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.
Modified
p. 9
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.
Modified
p. 9
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 …
Modified
p. 9
The test requirements provide both the vendor and assessors with a common understanding of the expected validation activities to be performed. The specific items to be examined, observed, or tested, and personnel to be interviewed should be appropriate for the control objective being validated and for each vendor’s unique software products and secure software lifecycle management processes. When documenting the assessment results, the assessor identifies the testing activities performed and the result of each activity. While it is expected that …
The test requirements provide both software vendors and assessors with a common understanding of the expected validation activities to be performed. The specific items to be examined, observed, or tested, and the personnel to be interviewed should be appropriate for the control objective being validated and for each software vendor’s unique software products and secure software lifecycle management processes. When documenting the assessment results, the assessor identifies the testing activities performed and the result of each activity. While it is …
Modified
p. 9
All test requirements are expected to be performed by the assessor. However, an assessor may choose to rely on testing performed by a third- party
•including the vendor
•to satisfy a test requirement. The assessor retains full responsibility for the testing activities and results regardless of whether the testing is performed by the assessor, the vendor, or a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify:
•including the vendor
•to satisfy a test requirement. The assessor retains full responsibility for the testing activities and results regardless of whether the testing is performed by the assessor, the vendor, or a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify:
All test requirements are expected to be performed by the assessor. However, an assessor may choose to rely on testing performed by a third- party
•including the software vendor
•to satisfy a test requirement. The assessor retains full responsibility for the testing activities and results regardless of whether the testing is performed by the assessor, the software vendor, or a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify:
•including the software vendor
•to satisfy a test requirement. The assessor retains full responsibility for the testing activities and results regardless of whether the testing is performed by the assessor, the software vendor, or a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify:
Modified
p. 9
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.
Modified
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 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.
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 …
Modified
p. 11
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), as well as 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 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).
Modified
p. 12
Note: The assessor may require and rely on assistance from the vendor to fulfill this test requirement (such as through access to a dedicated test environment). Any such specific assistance must be documented by the assessor.
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.
Modified
p. 13
1.2.b For each of the sensitive functions listed, the assessor shall examine vendor evidence to confirm that vendor evidence clearly describes how and where the sensitive data associated with this function 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.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.
Modified
p. 13
1.2.c Where the sensitive functions 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 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.
Modified
p. 13
Note: For example, by reviewing the security policy of a PTS or FIPS140-2 approved cryptographic system.
Note: For example, by reviewing the security policy of a PTS or FIPS140-2 or 140-3 approved cryptographic system.
Modified
p. 14
• The vendor defines classification criteria for identifying critical assets;
• The vendor defines classification criteria for identifying critical assets.
Modified
p. 14
• Vendor classification criteria identifies the confidentiality, integrity, and resiliency requirements for each critical asset; and
• Vendor classification criteria identifies the confidentiality, integrity, and resiliency requirements for each critical asset.
Modified
p. 14
There are numerous analysis techniques that can be used to identify critical assets, including Mission Impact Analysis (MIA), Functional Dependency Network Analysis (FDNA), and Mission Threat Analysis. Additional information and techniques can be found in publications such as the appendixes of NIST Special Publication 800-160 or in other publications from industry standards bodies such as EMVCo, ISO or ANSI.
There are numerous analysis techniques that can be used to identify critical assets, including Mission Impact Analysis (MIA), Functional Dependency Network Analysis (FDNA), and Mission Threat Analysis. Additional information and techniques can be found in publications such as the appendices of NIST Special Publication 800-160 or in other publications from industry standards bodies such as EMVCo, ISO or ANSI.
Modified
p. 15
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 install. 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 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).
Modified
p. 15
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 as required in Control Objective 5. 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 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.
Modified
p. 15
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 as required in Control Objective 6. 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 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.
Modified
p. 16
• The mitigations implemented by the software vendor to minimize exploit of these weakness have been identified.
• The mitigations implemented by the software vendor to minimize exploit of these weaknesses have been identified.
Modified
p. 16
• 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.
• 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.
Modified
p. 16
Note: The assessor should reference the vendor threat model as defined under Control Objective 4 for this item.
Note: The assessor should reference the vendor threat information defined in Control Objective 4.1 for this item.
Removed
p. 17
2.2.d The assessor shall examine vendor evidence and test the software to confirm that through following the provided vendor security guidance (per Control Objective 12), all security-relevant features, controls, and functionalities are enabled prior to the software enabling processing of sensitive data.
Modified
p. 17
Note: Specific software security controls required to protect the integrity and confidentiality of sensitive data, functions, and resources are captured in the next section, titled “Software Protection Mechanisms.” 2.2.a The assessor shall examine vendor evidence and test the software to identify all software security features and to confirm that any security features relied upon by the software for the protection of critical assets are enabled upon installation, initialization, or first use of the software.
Note: Specific software security controls required to protect the integrity and confidentiality of sensitive data, sensitive functions, and sensitive resources are captured in the Software Protection Mechanisms section.
Modified
p. 17
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 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.
Modified
p. 17
2.2.b Where any security features 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 no sensitive data can be processed until this initialization process has been completed.
Modified
p. 17
2.2.c Where user input or interaction is required to enable any security features (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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Removed
p. 18
Built-in accounts with known credentials such as default or empty passwords, default keys, etc. are often overlooked during installation or initial configuration and use, and can be used by a malicious user to bypass access controls. Therefore, the software should not use or rely on the default credentials for its operation upon installation, initialization, or first use.
Modified
p. 18
Note: The assessor should refer to Control Objectives 1, 5, and 7 to identify authentication and access control mechanisms, keys, and other critical assets used for authentication.
Note: The assessor should refer to evidence obtained in the testing of Control Objectives 1, 5, and 7 to determine the authentication and access control mechanisms, keys, and other critical assets used for authentication.
Modified
p. 18
Note: It is expected that this analysis will include, but not necessarily be limited to, the use of entropy analysis tools to look for hardcoded cryptographic keys, searches for common cryptographic function call and structures such as SBoxes and big- number library functions (and tracing these functions backwards to search for hardcoded keys), as well as checking for strings containing common user account names or password values.
Note: It is expected that this analysis will include, but not necessarily be limited to, the use of entropy analysis tools to look for hardcoded cryptographic keys, searches for common cryptographic function call and structures such as S-Boxes and big-number library functions (and tracing these functions backwards to search for hardcoded keys), as well as checking for strings containing common user account names or password values.
Modified
p. 18 → 19
2.3.d The assessor shall test the software to confirm that default authentication credentials or keys for built-in accounts are not used by the authentication and access mechanisms implemented by the software.
2.3.d The assessor shall test the software to confirm that default authentication credentials or keys for built-in accounts are not used by the authentication and access control mechanisms implemented by the software after software installation, initialization, or first use.
Modified
p. 18 → 19
Note: The assessor should refer to Control Objective 5 to identify authentication and access mechanisms.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 5 to determine the authentication and access control mechanisms implemented by the software.
Modified
p. 19
Note: The assessor should refer to Control Objective 6 to identify security control used to protect sensitive data.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 6 to determine the software security controls implemented to protect sensitive data.
Modified
p. 19 → 20
To minimize the software’s attack surface, the software should only request and be granted the minimum required privileges for its intended operation. For example, system service accounts that the software uses to operate, or accounts used by the software to access underlying components such as a database or invoke web-services calls should not require permissions that exceed the minimum necessary for the software perform its operations.
To minimize the software’s attack surface, the software should only request and be granted the minimum required privileges for its intended operation. For example, system service accounts that the software uses to operate, or accounts used by the software to access underlying components such as a database or invoke web-services calls should not require permissions that exceed the minimum necessary for the software to perform its operations.
Modified
p. 19 → 20
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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Removed
p. 21
3.1.d Where user input or interaction is required to configure the retention period of sensitive data, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process, including secure deletion procedures per Control Objective 3.4, provided in the vendor security guidance documents made available to stakeholders per Control Objective 12.
Modified
p. 21 → 22
Note: The assessor should refer to Control Objective 1 to identify all critical assets, including retained sensitive data.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine the sensitive data retained by the software.
Modified
p. 21 → 22
3.1.b The assessor shall test the software to confirm that all available functions or services designed for the retention 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 vendor evidence.
Modified
p. 21 → 22
Note: The assessor should refer to Control Objective 1 to identify all sensitive functions and services.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.2 to determine the sensitive functions and services provided or used by the software.
Modified
p. 21 → 22
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 is retained only for the duration necessary in accordance with reasonable vendor criteria. Closure of the software must result …
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 …
Removed
p. 22
Note: The assessor should refer to Control Objective 1 to identify all sensitive functions and services.
3.2.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 in accordance with Control Objective 6. Where data is stored for the sole purpose of debugging, error finding, or testing of systems, the assessor shall confirm that the functionality that allows for storage of data must be explicitly enabled through an interface that requires interaction and authorization by the user. Closure of the software must result in termination of this debugging state, such that it requires explicit re- enablement when the software is next executed; and any sensitive data is securely deleted per Control Objective 3.4.
3.2.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 in accordance with Control Objective 6. Where data is stored for the sole purpose of debugging, error finding, or testing of systems, the assessor shall confirm that the functionality that allows for storage of data must be explicitly enabled through an interface that requires interaction and authorization by the user. Closure of the software must result in termination of this debugging state, such that it requires explicit re- enablement when the software is next executed; and any sensitive data is securely deleted per Control Objective 3.4.
Modified
p. 22 → 23
Note: The assessor should refer to Control Objective 1 to identify all critical assets, including transient sensitive data.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.2 to determine the sensitive functions and services that retain transient sensitive data.
Modified
p. 22 → 23
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 …
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 …
Modified
p. 22 → 24
3.2.d Where users can configure retention of transient sensitive data, the assessor shall examine vendor evidence to confirm that there is clear and sufficient guidance on this process, including triggering secure deletion procedure per Control Objective 3.4, is provided in the vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Removed
p. 23
Note: Security Objective: Software Protection Mechanisms includes several specific software control objectives that are required to be implemented to protect sensitive data during storage, processing or transmission. Those control objectives should be analyzed to determine their applicability to the types of sensitive data retained by the software.
Modified
p. 23 → 25
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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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. 24
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 outlined in Control Objective 3.1 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. Examples of industry-accepted methods include those described in ISO 27038 Security techniques. Other reputable sources of industry-accepted methods may be used as well.
3.4.c The assessor shall test the software, including usage of forensic tools, to identify any sensitive data residue in the execution environment, and to confirm that the methods attested by the software vendor are correctly implemented and applied to all sensitive data. This analysis should accommodate for the data structures and methods used to …
3.4.c The assessor shall test the software, including usage of forensic tools, to identify any sensitive data residue in the execution environment, and to confirm that the methods attested by the software vendor are correctly implemented and applied to all sensitive data. This analysis should accommodate for the data structures and methods used to …
Modified
p. 24 → 25
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 such 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 …
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 …
Modified
p. 24 → 26
Note: Where forensic testing of the some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.
Note: Where forensic testing of some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.
Removed
p. 25
3.5.c The assessor shall test the software, including usage of forensic tools, to identify any sensitive data residue in the execution environment to confirm that the methods attested by the software vendor are correctly implemented and applied to all transient sensitive data. This analysis should accommodate for the data structures and methods used to store the sensitive data⎯e.g., by examining file systems at the allocation level, and translating data formats to identify sensitive data elements⎯as well as cover all non-transient sensitive data types as defined in Control Objective 3.1.
Modified
p. 25 → 26
3.5.a The assessor shall examine vendor evidence to identify all secure deletion methods for all transient sensitive data outlined in Control Objective 3.2, and to confirm that these methods ensure that the data is unrecoverable after deletion.
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. 25 → 26
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. 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 …
Modified
p. 25 → 27
Note: Where forensic testing of the some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.
Note: Where forensic testing of some or all aspects of the platform is not possible, the assessor should examine additional evidence to confirm secure deletion of sensitive data. Such evidence may include (but is not necessarily limited to) memory and storage dumps from development systems, evidence from memory traces from emulated systems, or evidence from physical extraction of data performed on-site by the software vendor.
Modified
p. 26 → 28
3.6.a The assessor shall examine vendor evidence to confirm that 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 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:
Modified
p. 26 → 28
• 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, etc.
Modified
p. 26 → 28
Proactive measures to ensure that sensitive data is not inadvertently “leaked” should be implemented by the software vendor or within the software. Disclosure of sensitive data to unauthorized parties often occurs via 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 or components, or through the use of shared resources such as memory, disk, files, keyboards, displays, and functions. Protective mechanisms, whether process or …
Proactive measures to ensure that sensitive data is not inadvertently “leaked” should be implemented by the software vendor or within the software. Disclosure of sensitive data to unauthorized parties often occurs via 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. Protective mechanisms, whether process …
Modified
p. 26 → 28
3.6.b The assessor shall examine vendor evidence, including the results of the analysis described in 3.2.a, and test the software to confirm the software vendor implemented mitigations to protect from 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 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).
Modified
p. 26 → 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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Removed
p. 28
• A formal owner of the software application is assigned. This may be a role for a specific individual or a specific name, but evidence must clearly show an individual who is accountable for the security of the software.
Modified
p. 28 → 30
Note: This requirement is an extension of Control Objective 10.
Note: This control objective is an extension of Control Objective 10.1. Validation of both control objectives should be performed at the same time.
Modified
p. 28 → 30
Software vendors should evaluate the design of their payment software applications 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 …
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 …
Modified
p. 28 → 30
When the software relies on execution environment security controls, the software vendor should review and reference the implementation documentation for the platform⎯such as Security Policies for PTS terminals or FIPS140-2 approved cryptographic modules⎯and confirm that the software and its associated documentation correctly and completely accommodates for the guidance in these documents.
When the software relies on execution environment security controls, the software vendor should review and reference the implementation documentation for the platform⎯such as Security Policies for PCI- approved POI devices or FIPS140-2 or 140-3 approved cryptographic modules⎯and confirm that the software and its associated documentation correctly and completely accommodates for the guidance in these documents.
Modified
p. 28 → 30
• All critical assets managed by and sensitive resources used by the system are documented.
• All critical assets managed by and all sensitive resources used by the system are documented.
Modified
p. 29 → 31
• All entry and egress methods for sensitive data by the software application, as well as the authentication and trust model applied to each of these entry/egress points, are defined.
• 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.
Modified
p. 29 → 31
• Consideration for the installed environment of the software application, 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.
• 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.
Modified
p. 30 → 32
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, 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.
Modified
p. 30 → 32
4.2.c Where any mitigations rely on settings within the software, the assessor shall test the software to confirm that such settings are applied by default, before first processing any sensitive data, upon install of the software.
4.2.c Where any mitigations rely on settings within the software, the assessor shall test the software to confirm that such settings are applied by default, before first processing any sensitive data, upon installation, initialization, or first use of the software.
Modified
p. 30 → 32
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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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. 30 → 32
Where the execution environment provides API 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.
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. 31 → 33
Note: The assessor should refer to Control Objective 1 to identify asset classification and all critical assets.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.3 to determine the classifications for all critical assets.
Modified
p. 31 → 33
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 to the software itself, directly⎯the assessor shall examine vendor evidence to confirm that clear and sufficient guidance on how to configure authentication mechanisms correctly is provided in the vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Removed
p. 32
Note: The assessor should refer to Control Objective 6 to identify controls to protect sensitive data at rest and in transit.
Modified
p. 32 → 34
Note: Control Objectives 3.3 and 4.2 require sensitive data and resources to be protected. Control Objective 1 requires sensitive data and resources to be defined.
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.
Modified
p. 32 → 34
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 vendor security guidance documents made available to stakeholders per Control Objective 12.
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.
Modified
p. 32 → 34
5.2.d The assessor shall examine vendor evidence to confirm that vendor security guidance provided to stakeholders (per Control Objective 12) 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 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.
Modified
p. 33 → 35
Note: The assessor should refer to Control Objective 4 to identify all 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. 33 → 35
For example, if the software uses biometric authentication, the vendor may want to identify all points at which a malicious user may attack the authenticator and implement mitigation strategy to address those risks. The authentication mechanism implemented in the software could rely on additional sensors to ensure the provided biometric sample is from a living human and not a forged or spoofed sample.
For example, if the software uses biometric authentication, the vendor may want to identify all points at which a malicious user may attack the authenticator and implement mitigations to address those risks. The authentication mechanism implemented in the software could rely on additional sensors to ensure the provided biometric sample is from a living human and not a forged or spoofed sample.
Modified
p. 33 → 35
Note: The vendor assessment and robustness justification include consideration of the full path of the user credentials, from any input source (such as a Human Machine Interface or other program), through transition to the execution environment of the software (including any switched/network transmissions and traversal through the execution environment’s software stack before being processed by the software application itself).
Note: The vendor assessment and robustness justification include consideration of the full path of the user credentials, from any input source (such as a Human Machine Interface or other program), through transition to the execution environment of the software (including any switched/network transmissions and traversal through the execution environment’s software stack before being processed by the software itself).
Modified
p. 35 → 37
In cases where the confidentiality of sensitive data is a concern, it is imperative to know where and for how long is the data 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 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.
Modified
p. 35 → 37
Note: The assessor should refer to Control Objective 1 to identify all critical assets and Control Objective 4 to identify all attack scenarios applicable to the software.
Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.1 to determine all sensitive data retained by the software, and Control Objective 4.1 to identify all attack scenarios applicable to the software.
Modified
p. 35 → 37
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 is compliant to Control Objective 7.
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.
Modified
p. 35 → 37
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”).
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”).
Modified
p. 36 → 38
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.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.
Modified
p. 36 → 38
Note: The assessor should refer to Control Objective 1 to identify all critical assets.
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. 36 → 38
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 sufficiently detailed instructions allowing for the secure settings to be applied during installation and operation of the vendor application are included in the vendor security guidance made available to stakeholders per Control Objective 12.
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.
Removed
p. 37
6.3.b Where third-party software or aspects of the execution environment or platform on which the application is run are relied upon for cryptographic services for the protection of sensitive data, the assessor shall examine vendor evidence and test the software to identify these methods and to confirm that the vendor security guidance provides clear and sufficient detail for correctly configuring these methods during the installation of the vendor software.
Removed
p. 38
Note: The assessor should refer to Control Objective 4 to identify common cryptography attacks.
Modified
p. 38 → 40
7.1.a The assessor shall examine the vendor evidence to confirm that, where that cryptography is relied upon (in whole or in part) for the security of the critical assets:
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:
Modified
p. 38 → 40
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 …
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 …
Modified
p. 39 → 41
Note: The assessor should refer to Control Objective 7.3 to identify secure random number generators.
Note: The assessor should refer to Control Objective 7.3 for more information on secure random number generators.
Modified
p. 40 → 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 application updates) have a unique purpose. For example, no key may be used for both encryption and authentication operations.
• 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.
Modified
p. 40 → 42
• 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 of the application (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 (e.g., white-box cryptography).
Modified
p. 40 → 42
(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 → 44
7.2.f Where public keys are used, the assessor shall examine vendor evidence and test the software to confirm that public keys manually loaded or used as root keys are installed and stored in a way that provides dual control (to a level that is feasible on the execution environment), preventing a single user from replacing a key to facilitate a man-in-the-middle attack, easy decryption of stored data, etc. Where complete dual control is not feasible (e.g., due to limitation of …
7.2.f Where public keys are used, the assessor shall examine vendor evidence and test the software to confirm that public keys manually loaded or used as root keys are installed and stored in a way that provides dual control (to a level that is feasible on the execution environment), preventing a single user from replacing a key to facilitate a man-in-the-middle attack, easy decryption of stored data, etc. Where complete dual control is not feasible (e.g., due to a limitation …
Modified
p. 42 → 44
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) 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. 43 → 45
Random numbers are used in numerous software applications, to protect sensitive information. Encryption keys and initialization values (seeds) are examples of implementations in which random numbers commonly used in applications.
Random numbers are often used with cryptography to protect sensitive information. Encryption keys and initialization values (seeds) are examples of implementations in which random numbers are required.
Modified
p. 43 → 45
It is not a trivial endeavor to design and implement a secure random number generator. Software vendors are required to use only approved random number generation algorithms and libraries, or provide evidence to illustrate how the random number generation algorithms and libraries were tested to confirm that random numbers generated are sufficiently unpredictable.
It is not a trivial endeavor to design and implement a secure random number generator. Software vendors are required to use only approved random number generation algorithms and libraries or provide evidence to illustrate how the random number generation algorithms and libraries were tested to confirm that random numbers generated are sufficiently unpredictable.
Modified
p. 43 → 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. 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 …
Modified
p. 44 → 45
Where problems are known, but have been mitigated by the application vendor, the assessor shall examine vendor evidence and test the software to confirm that the vulnerabilities have been sufficiently mitigated.
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.
Removed
p. 45
Note: The assessor should refer to Control Objective 1 to identify all critical assets, including keys and other cryptographic material.
Modified
p. 45 → 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 DSS, etc.) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.
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.
Modified
p. 46 → 47
• 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.
• 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.
Modified
p. 46 → 47
• Clear and sufficient guidance is provided in the vendor security guidance made available to stakeholders (per Control Objective 12) that any passphrase used must be:
• 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:
Modified
p. 46 → 47
• Never implemented by a single person, such that one person has an advantage in recovering the clear key value; violating the requirements for split knowledge (For example, for an AES128 key, 2 people must each enter 32 hex characters or 3 people must enter at least 16 hex characters each).
• Never implemented by a single person, such that one person has an advantage in recovering the clear key value; violating the requirements for split knowledge.
Modified
p. 48 → 49
• All individual user attempts to access to sensitive data or resources
• All individual user attempts to access sensitive data or resources
Modified
p. 48 → 49
• Initialization, stopping, or pausing of sensitive functions This Control Objective does not mandate the logging of each encryption operation or function processing sensitive data, but does require that access is tracked, and any methods that may expose sensitive data are also tracked.
• Initialization, stopping, or pausing of sensitive functions 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. 49
• Disabling or deleting a security control or altering security functionality By recording the details in this requirement for the all activity identified in Control Objective 8.1, 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 → 51
When activity records are managed by the software, the records must be protected in accordance with applicable requirements for the protection of sensitive data, including Control Objectives 3 and 5.
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.
Modified
p. 51
• The software does not overwrite existing tracking data upon a restart of the software. Each new start shall only append to existing datasets, or create a new tracking dataset.
• The software does not overwrite existing tracking data upon a restart of the software. Each new start shall only append to existing datasets or shall create a new tracking dataset.
Modified
p. 51
• Where unique dataset names are relied upon for maintaining integrity between execution instances, the implementation ensures that another application (including another instance of the same application) cannot overwrite or render invalid existing datasets.
• Where unique dataset names are relied upon for maintaining integrity between execution instances, the implementation ensures that other software (including another instance of the same software) cannot overwrite or render invalid existing datasets.
Modified
p. 52
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 put in place to prevent such scenarios from affecting the integrity of the tracking records.
Removed
p. 53
Note: The assessor should refer to Control Objective 4 for information on the possible attack scenarios and mitigation controls implemented by the software vendor.
Note: The assessor should refer to Control Objective 7 for information on appropriate and correct usage of cryptography.
Note: The assessor should refer to Control Objective 7 for information on appropriate and correct usage of cryptography.
Modified
p. 53
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, and shall test the software to confirm controls are implemented to minimize the associated risk.
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.
Modified
p. 53
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 a 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⎯e.g., frequent input of a password can be an indicator of brute-force attempts.
Modified
p. 53
9.1.b The assessor shall examine vendor evidence and test the software to confirm that integrity values used by the application and dataset(s) upon which it relies for secure operation are checked upon execution of the application, 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 …
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.
Removed
p. 54
Note: The assessor should refer to Control Objective 1 and 6 to identify all critical assets and implemented security controls.
9.1.e Where configuration or other dataset values can be modified by the software during execution, the assessor shall examine vendor evidence and test the software to confirm that integrity protections are implemented to allow for this update while still ensuring dataset integrity can be validated after update.
9.1.e Where configuration or other dataset values can be modified by the software during execution, the assessor shall examine vendor evidence and test the software to confirm that integrity protections are implemented to allow for this update while still ensuring dataset integrity can be validated after update.
Modified
p. 55
10.1.a The assessor shall examine vendor evidence to confirm that the vendor has identified common methods for attack against the software product. This may include platform-level, protocol-level, and/or language-level attacks.
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.
Modified
p. 55
Determining how to effectively secure and defend the software against attacks requires a thorough understanding of the specific threats and potential vulnerabilities applicable to the vendor’s software. This typically involves the following:
Determining how to effectively secure and defend the software against attacks requires a thorough understanding of the specific threats and potential vulnerabilities applicable to the vendor’s software. This typically involves understanding the following:
Modified
p. 55
• Understanding 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
• 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
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 NIST Special Publication 800-160, Appendix F.
Modified
p. 55
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 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 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.
Removed
p. 56
Note: The assessor should refer to Control Objective 4 for information on the possible attack scenarios and mitigation controls implemented by the software vendor.
To minimize the introduction of vulnerabilities into software applications from third-party components, those components must also be evaluated. Ideally, they should be subject to the same secure development and testing processes as the software created by the vendor.
To minimize the introduction of vulnerabilities into software applications from third-party components, those components must also be evaluated. Ideally, they should be subject to the same secure development and testing processes as the software created by the vendor.
Modified
p. 56
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 …
Modified
p. 57
• Includes, at a minimum, the use of automated tools capable of detecting vulnerabilities both in software code and during software execution, and that the tools used for security testing 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, at a minimum, the use of automated tools capable of detecting vulnerabilities both in software code and during software execution.
Modified
p. 57
• 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, including detecting vulnerabilities in third-party, open-source, or shared components and libraries.
Modified
p. 57
• The vendor implements an industry-standard vulnerability-ranking system (such as CVSS) that allows for the categorization of vulnerabilities.
• The vendor implements an industry-standard vulnerability- ranking system (such as CVSS) that allows for the categorization of vulnerabilities.
Modified
p. 58
• Reasonable criteria exist for releasing software updates to fix security vulnerabilities
• Reasonable criteria exist for releasing software updates to fix security vulnerabilities.
Modified
p. 58
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 vendor security guidance made available to stakeholders (per Control Objective 12).
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.
Modified
p. 60
When followed, the software vendor's security 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 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, …
Modified
p. 60
• Enabling and disabling application accounts, services, and features
• Enabling and disabling software accounts, services, and features
Modified
p. 60
• Does not instruct the user to disable security settings or parameters within the installed environment, such as anti-malware software or firewall or other network-level protection systems.
• Does not instruct the user to disable security settings or parameters within the installed environment, such as anti- malware software or firewall or other network-level protection systems.
Modified
p. 61
• 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 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.
Removed
p. 62
• 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 cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN, or are otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.
• 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 cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN, or are otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.
Modified
p. 62
The table on the following page illustrates commonly used elements of cardholder data and sensitive authentication data, whether storage of that data is permitted or prohibited, and whether this data needs to be protected. This table is not meant to be exhaustive, but is presented to illustrate the different types of requirements that apply to each data element.
The table on the following page illustrates commonly used elements of cardholder data and sensitive authentication data, whether storage of that data is permitted or prohibited, and whether this data needs to be protected. This table is not meant to be exhaustive, but it is presented to illustrate the different types of requirements that apply to each data element.
Modified
p. 64
A.1.1.a For each instance of sensitive authentication data identified in Control Objective 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).
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).
Modified
p. 64
Testing should include at least the following types of files, as well as any other output generated by the payment application:
Testing should include at least the following types of files, as well as any other output generated by the payment software:
Modified
p. 65
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:
Modified
p. 65
• Instructions on how to securely delete cardholder data stored by the payment application, including data stored on underlying software or systems (such as OS, databases, etc.).
• 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.).
Modified
p. 65
Customers and integrators/resellers must also be provided with configuration details for the underlying systems and software that the application runs on, to ensure these underlying systems are not capturing cardholder data without the customer’s knowledge.
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.
Modified
p. 65
A.2.2.a The assessor shall examine vendor evidence, including security guidance made available to stakeholders (per Control Objective 12), to confirm the guidance includes the following instructions for customers and integrators/resellers:
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:
Modified
p. 66
A.2.3.a The assessor shall examine vendor evidence, including the security guidance made available to stakeholders (per Control Objective 12) to verify the guidance includes the following:
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:
Modified
p. 66
• 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 application (per as identified in Control Objective A.2.1).
• 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.