Document Diff - PCI Watch

Added p. 5

Sensitive Assets This standard is based on the context of “sensitive assets”. To assist the software vendor and the software assessor, refer to the latest version of the external companion document to this standard, PCI Secure Software Standard - Sensitive Asset Identification.

The PCI Secure Software Standard - Sensitive Asset Identification is required to be used as part of this standard and its program.

Relationship with other PCI Standards This standard is intended as a stand-alone standard regarding software associated with sensitive assets. However, software vendors may also be interested in designing their software in accordance, at least in part, with other PCI standards. It is not prudent to attempt to copy all requirements and associated contexts from other PCI standards into this standard. Therefore, for software vendors with software intended for use in specific use cases and/or environments related to other PCI standards, the software vendor should consult the relevant PCI …

Added p. 6

§ Module B

• POI Device Software: Additional security objectives and security requirements for software specifically designed for deployment and operation on PIN Transaction Security Point-of- Interaction (PTS POI) devices.

§ Module C

• Publicly-accessible Software: Additional security objectives and security requirements for software that contains an interface that is accessible via public networks.

§ Module D

• Software Development Kits: Additional security objectives and security requirements for software development kits (SDKs).

Objective-Based Approach to Requirements This standard consists of an “objective-based” approach to defining the security requirements. An “objective-based” approach is one that states security requirements as a desired security goal or outcome without necessarily specifying the method(s) required to achieve the desired goal. This approach provides appropriate flexibility to the software vendor and enables the vendor to implement software security controls based on the risks identified for a given software implementation. The objective-based approach also allows for a wide range of programming languages, underlying …

Added p. 7

• Testing Notes: Provides additional information to clarify the context/scope of the associated test requirement(s).

The following illustration depicts the general structure as outlined above:

Test Requirement Methods To support the validation of their software to the requirements in this standard, software vendors are expected to produce evidence that they have satisfied the stated security objectives. The test requirements identified for each security objective describe the activities to be performed by the assessor to confirm that the software and/or software vendor have met the security objectives and security requirements. The software assessor can choose to include additional test activity, as denoted below, in addition to the test activity specified for the security requirement, as is reasonable and needed to assist in verifying if a security requirement is satisfied.

Test requirements can include the following testing activities (these test activity keywords are denoted in bold within the test requirements for easy identification):

Added p. 8

§ Observe: The assessor watches an action or views something. Examples of observation subjects include personnel performing tasks or processes, software or system components performing a function or responding to input, system configurations/settings, environmental conditions, and physical controls. Observation may include the performance of tests, so that the output of those tests may be observed, potentially under changing conditions as the input is manipulated by the tester or other systems.

§ Perform: Carry out the specified activity in the test requirement. This may implicitly include other test activities, such as examination and testing (e.g., including static and/or dynamic analysis of the software). Note that static and dynamic analyses implicitly include “test” activity.

§ Test: The assessor evaluates the software to analyze its characteristics and behavior in various scenarios to assist in determining whether the associated security requirement is satisfied. Testing is generally carried out using either static and/or dynamic analysis as specified …

Added p. 10

Technical Constraints If there are technical constraints of the architecture/language that present challenges to completely satisfying a particular security requirement, or otherwise in testing to properly validate that a security requirement has been absolutely satisfied, the following information is provided, at a minimum:

§ The extent to which the security requirement can be satisfied. § The technical limitation of the implementation and why the limitation cannot be resolved or otherwise remediated. § The residual risk that exists due to the technical limitation. § If any alternative means have been leveraged or implemented to reduce the residual risk incurred by the technical limitation, whether within the software product itself and/or external to it. Note: A “Technical Constraint” is not, nor does it imply the use of, a “Compensating Control” as defined in PCI DSS.

Technical FAQs The PCI Secure Software Technical FAQs is a separate document from this PCI Secure Software Standard and …

Added p. 11

The applicability of the modules

•which contain additional requirements

•to the software assessment does not supersede any requirements in this section.

1: Software Architecture, Composition, and Versioning 2: Sensitive Asset Identification 3: Sensitive Asset Storage and Retention 4: Sensitive Modes of Operation 5: Sensitive Asset Protection Mechanisms 6: Sensitive Asset Output 7: Random Numbers 8: Key Management 9: Cryptography 10: Threats and Vulnerabilities 11: Secure Deployment and Management Purpose and Scope This section defines a minimum baseline set of security objectives and associated security requirements for software that is associated with sensitive assets. This section is required for all software being designed and assessed to this standard. Refer to the PCI Secure Software Standard - Sensitive Asset Identification document for additional details and guidance regarding sensitive assets.

Added p. 12

Notes: This section encapsulates the entirety of the software intended to be assessed to this standard and subsequently represented by its potential validation.

Security Requirements Test Requirements Guidance 1-1 The overall architecture of the software is documented.

1-1.a Examine vendor documentation to verify the architecture of the software is documented. Leverage this information as relevant for the software assessment.

The software architecture is essential information to facilitate the software assessment. The software vendor is encouraged to detail as much information as is relevant to the requirements within this standard. Numerous requirements in this standard will necessitate appropriate documentation to assist the assessor in validating the software. This requirement assists in creating awareness and promoting this useful and necessary activity early in the engagement. The details should include information such as, but not limited to: the composition of the software, its overall architecture, how the software is intended to be used, typical implementation scenarios, …

Added p. 13

Implementation Notes This requirement is in context of the overall security architecture, as the software itself is a sensitive asset. It should be demonstrable that the software is proactively and purposefully designed with security and the protection of sensitive assets as a significant objective.

This requirement is not intended to duplicate the specific protection requirements for sensitive data and sensitive resources from Security Objectives 2 and 3.

1-1.1.a Examine vendor documentation to verify the security-relevant architectural aspects of the software design and implementation to protect sensitive assets are documented. Leverage this information as relevant for the software assessment, in particular for requirements in this Security Objective 5.

Where requirement 1-1 is for the overall software architecture, this requirement is specific to the security- relevant architectural aspects of the software.

The vendor documentation should detail all security-relevant aspects of the software, both in design and implementation. At a minimum, it should provide all requisite details …

Added p. 14

Implementation Notes The software vendor can choose the format for the bill of materials.

1-2.a Examine evidence to verify the composition of the software, including its software and hardware dependencies, is accurately documented in a bill of materials.

Modern software is rarely developed entirely in-house and is typically composed of numerous components integrated to deliver its intended functionality. What constitutes a software “component” depends on how the software is structured; however, it could include low-level modular code structures such as libraries, packages, modules, widgets, and other micro-applications, to services and systems that may be distributed across the Internet. Awareness of all the components that comprise a software implementation is critical to designing secure software, as well as minimizing and managing potential vulnerabilities within it. Properly documenting and maintaining the dependencies of the software product is essential to managing various security-related aspects of the software, from its own design implementation to tracking and …

Added p. 15

1-3.a Examine vendor documentation to verify the software is designed and built in a manner that facilitates its overall composition being restricted to only what is required for its intended functionality. Leverage information from 1-1 and 1-2. 1-3.b Perform static analysis to verify the information from 1-3.a. 1-3.c Examine evidence of the software-build process to verify the information from 1-2.

“Built” is used here generically to refer to the overall composition of the software, which includes both the software itself and any third-party code/libraries/components or equivalent.

To the extent possible, the software composition should be devoid of unnecessary and/or unused functionality, as they pose a risk of potential compromise. This is especially important for all third-party contexts.

1-3.1 This includes all third-party elements.

1-3.1.a Examine vendor documentation to verify the software is designed and built in a manner that only leverages third-party elements as needed for its intended functionality. Leverage information from 1- 2 …

Added p. 16

1-5.a Examine vendor documentation describing the versioning schema of the software and verify it is in accordance with the Program.

Software versioning, including the use of wildcards, is detailed in the associated PCI Secure Software Program Guide (the Program).

1-5.1 If wildcards are being used, the wildcarding schema is explicitly documented and will be implemented per the Program and used only for non-security-impacting changes to the software.

1-5.1.a Examine vendor documentation describing the wildcarding schema of the software and verify it is in accordance with the Program and intended for only non-security impacting changes to the software.

Added p. 17

Notes: 1 - Refer to the PCI Secure Software Standard

• Sensitive Asset Identification document for assistance in identifying and documenting sensitive assets. 2 - Accurate and complete identification and documentation for all sensitive assets is crucial

•this information is relevant to, and required for, additional security objective sections and their associated security requirements in this standard. 3 - Software vendors are encouraged to identify the sensitive assets early and often in the design of their software to assist in the software being designed with intent to satisfy the security objectives and security requirements in this standard. 4 - If the software contains account data as defined by PCI DSS (which is considered sensitive data within this standard), refer to Module A

• Account Data Protection in this standard for additional requirements and information. Module A

• Account Data Protection does not circumvent any requirements in the “Core

• All Software” section in this standard.

Security …

Added p. 18

2-1.2.a Examine vendor documentation to verify it contains details that describe whether or not each sensitive data element is, or can be, stored, in addition to the storage locations as applicable. 2-1.2.b Verify the sensitive data elements denoted as being stored, or capable of being stored, are permissible for storage.

Testing Notes The software is analyzed and tested in 3-1.1.

Testing Notes The software is analyzed and tested in 3-1.2.

Not all sensitive data is permissible to store. Even where storage is permissible, the software vendor is encouraged to only store sensitive data as required. Finally, ensure the documentation includes the requisite details regarding the storage locations for all sensitive data.

2-1.3 The retention policies for all sensitive data are documented, which includes:

2-1.3.a Examine vendor documentation to verify it contains details that describe the retention policies attributed to, and implemented for, each sensitive data element that:

Sensitive data should only be retained for the duration …

Added p. 19

Implementation Notes This applies regardless of the form, e.g., cleartext, encrypted, etc.

2-1.4.a Examine vendor documentation to verify it contains details that describe the methods implemented for each sensitive data element to render it unrecoverable once it is no longer required.

Testing Notes The software is analyzed and tested in 3-1.3, 3-1.4, and 3-2.

This is related to the defined retention policies for all sensitive data. Once the duration of retention is reached for each sensitive data element, it should no longer be required and therefore be securely deleted, regardless of form. While secure deletion is generally considered the most robust method, there may be platform-related considerations that can affect the absolute certainty, or verifiability, of secure deletion. Alternative methods can be employed to render the sensitive data element unrecoverable. Cryptographic deletion is an acceptable alternative to secure deletion, which refers to the process of deleting the decryption key that can decrypt encrypted …

Added p. 20

Implementation Notes All uses of cryptography to protect sensitive data must satisfy the definition of strong cryptography.

2-1.6.a Examine vendor documentation to verify it contains details that describe the protection methods attributed to, and implemented for, each sensitive data element. 2-1.6.b Examine vendor documentation to verify the protection methods employed for each sensitive data element are in accordance with and satisfy the protection classification attributions verified in 2-1.5.

The protection classification activity from 2-1.5 is used here to determine appropriate protection methods to implement in accordance with the defined protection classifications for each sensitive data type. Similar to 2-1.5, where a software vendor is designing their software to support a use case for another PCI standard, the software vendor should review those standards and determine if there are explicit protection methods required for defined data types and design their software accordingly. This requirement in this standard supports that activity. In general, the …

Added p. 20

Data Encryption Key (DEK), Key Encrypting Key (KEK), Public Key, Private Key, MAC key, etc.

Added p. 21

AES, RSA, DSA, SHA3, etc.

2-1.8.3 Associated key management schema 2-1.8.3.a Examine vendor documentation to verify it denotes the associated key management schema for each cryptographic key.

DUKPT, MK/SK, Fixed, One-time use, Elliptic Curve, etc.

2-1.8.4 Key length 2-1.8.4.a Examine vendor documentation to verify it denotes the associated key length for each cryptographic key.

Full length of the cryptographic key, including parity bits as applicable.

This is not to be confused with the bit (effective) strength of the key.

2-1.8.5 Generation Method & Origin 2-1.8.5.a Examine vendor documentation to verify it describes the generation method for each cryptographic key, including the origin.

Adequately document the method(s) used to generate each key type, in addition to where the key originates from.

2-1.8.6 Destruction Method 2-1.8.6.a Examine vendor documentation to verify it describes the destruction method for each cryptographic key.

Adequately document the method(s) used to destroy or otherwise erase each key type.

2-1.8.7 All associations with other sensitive data, as applicable.

2-1.8.7.a …

Added p. 22

This requirement is tested via 2.2.1 through 2-2.8.

This standard is defined by the protection of sensitive assets, and sensitive resources are a type of sensitive asset. Sensitive resources are different than sensitive data, and in certain use cases, they may require different protection considerations. It is imperative to accurately and completely identify and properly document all resources that satisfy the definition of a sensitive resource. The following sub-requirements provide a minimum baseline of required information regarding sensitive resources.

2-2.1.a Examine vendor documentation to verify it contains details that describe each sensitive resource and its use. 2-2.1.b Perform static analysis to verify the sensitive resources identified in 2-2.1.a.

2-2.1.c Perform static analysis to identify any resources that satisfy the definition of a sensitive resource and were not previously identified as a sensitive resource. The analysis is expected to check for qualifying sensitive resources that have been unaccounted for. Verify that all sensitive resources …

Added p. 23

2-2.3.a Examine vendor documentation to verify it contains details that describe whether or not each sensitive resource is, or can be, stored, in addition to the storage locations as applicable.

2-2.3.b Verify the sensitive resources that can be stored are permissible for storage.

2.2.3.c Examine vendor documentation to determine if there are any sensitive data elements contained within the sensitive resource and verify those sensitive data elements are permitted for storage.

It may be possible that a sensitive resource is not permissible to store. This effort creates the awareness and subsequent implementation within the software regarding whether each identified sensitive resource is permissible to store or not. Even where storage is permissible, the software vendor is encouraged to only store sensitive resources as required.

Finally, ensure the documentation includes the requisite details regarding the storage locations for all sensitive resources.

2-2.4 The retention policies for all sensitive resources are documented, which includes:

2-2.4.a Examine vendor documentation …

Added p. 24

2-2.5.a Examine vendor documentation to verify it contains details that describe the methods implemented for each sensitive resource to securely delete it or otherwise render it unrecoverable once it is no longer required.

This is related to the defined retention policies for all sensitive resources. Once the duration of retention is reached for each sensitive resource, it should no longer be required and therefore be securely deleted.

While secure deletion is generally considered the most robust method, there may be platform-related considerations that can affect the absolute certainty, or verifiability, of secure deletion. Alternative methods can be employed to render the sensitive resource unrecoverable. Cryptographic deletion is an acceptable alternative to secure deletion, which refers to the process of deleting the decryption key that can decrypt an encrypted resource. In such cases, even when the encrypted resource remains, it may be considered unrecoverable for the purposes of this requirement.

2-2.6 The protection classification …

Added p. 25

Implementation Notes All uses of cryptography to protect sensitive resources must satisfy the definition of strong cryptography.

2-2.7.a Examine vendor documentation to verify it contains details that describe the protection methods attributed to, and implemented for, each sensitive resource.

2-2.7.b Examine vendor documentation to verify the protection methods employed for each sensitive resource are in accordance with and satisfy the protection classification attributions verified in 2-2.6.

The protection classification activity from 2-2.6 is used here to determine appropriate protection methods to implement in accordance with the defined protection classifications for each sensitive resource. Similar to 2-2.6, where a software vendor is designing their software to support a use case for another PCI standard, the software vendor should review those standards and determine if there are explicit protection methods required for defined resources and design their software accordingly. This requirement in this standard supports that activity.

In general, the primary security objectives of confidentiality and/or …

Added p. 26

2-3.1.a Examine vendor documentation to verify it contains details that describe the sensitive functionality and its use. 2-3.1.b Perform static analysis to verify the sensitive functionality identified in 2-3.1.a.

2-3.1.c Perform static analysis to identify any functionality that satisfies the definition of sensitive functionality and was not previously identified as sensitive functionality. The analysis is expected to check for qualifying sensitive functionality that has been unaccounted for. Verify that all sensitive functionality is identified.

The test requirement 2-3.1.c is intended as a means to corroborate the sensitive functionality claimed by the vendor against the source code of the software product under assessment. A reasonable analysis should check for obvious qualifying sensitive functionality that has been unaccounted for.

Identify all the sensitive functionality of the software. Given the variance in programming languages, platforms, composition, implementation, etc., how the sensitive functionality is documented will depend on the explicit software implementation. However, the sensitive functionality should …

Added p. 27

Implementation Notes This requirement is specific to sensitive functionality, whereas requirements in 5-1[.x] are specific to the overall security architecture of the software itself. There may be overlap that can be leveraged.

All uses of cryptography to protect sensitive assets, which includes the software itself, must satisfy the definition of strong cryptography.

2-3.3.a Examine vendor documentation to verify it contains details that describe how the software is designed and implemented to facilitate mitigating the unauthorized access, disclosure, modification, and/or misuse of all sensitive functionality, as appropriate. Leverage the information examined as part of 2-3.1 and 2- 3.2.

Sensitive functionality may necessitate different concerns and considerations than sensitive data and/or sensitive resources. For example, as in 2-3.2, it may be necessary to partially expose sensitive functionality for the purposes of an external interface. In general, as much of the software functionality that can be protected or otherwise prevented from exposure and compromise is beneficial …

Added p. 28

2-3.6.a Examine vendor documentation to verify it denotes all sensitive functionality that is a sensitive mode of operation. Leverage the information examined as part of 2-3.1.

2-3.6.b Perform static analysis to verify the sensitive modes of operation identified in 2-3.6.a.

2-3.6.c Perform static analysis to identify any functionality that satisfies the definition of sensitive modes of operation and was not previously identified as a sensitive mode of operation. The analysis is expected to check for qualifying sensitive modes of operation that have been unaccounted for. Verify that all sensitive modes of operation are identified.

Document all sensitive functionality that satisfies the definition of a sensitive mode of operation.

Added p. 29

Notes: Leverage the relative documented information from Security Objective 2 once it is verified.

Security Requirements Test Requirements Guidance 3-1 Sensitive data that is capable of being stored is:

3-1.a Examine vendor documentation to verify the requirements in 3-1.1 through 3-1.4. Leverage the information examined and verified in Security Objective 2, in particular all relevant requirements in 2-1.x, 2-2.x, and 2-3.x, to assist in the assessment.

Requirement 3-1, including the sub-requirements, ensure the software is designed to properly account for the secure storage of sensitive data. The software design and implementation will be analyzed and tested to ensure they satisfy the requirements and align with the relevant documentation reviewed in Security Objective 2.

3-1.1 Only stored if storage of the sensitive data type is permissible and only as necessary.

3-1.1.a Perform static analysis to verify that all sensitive data capable of being stored is only stored as necessary and is permissible to be stored. 3-1.1.b …

Added p. 30

3-1.2.a Perform static analysis to verify that all sensitive data capable of being stored is protected in accordance with its type and use. 3-1.2.b Perform dynamic analysis to verify that all sensitive data capable of being stored is protected in accordance with its type and use. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the defined and implemented protection methods.

Refer to the guidance for 2-1.5 and 2-1.6.

3-1.2.1 Strong cryptography is used where cryptography is implemented or required to protect sensitive data in storage.

3-1.2.1.a Perform static analysis to verify that cryptography leveraged to protect sensitive data in storage satisfies the definition of strong cryptography. 3-1.2.1.b Perform static and/or dynamic analysis as necessary to verify that the use of strong cryptography being leveraged to protect sensitive data in storage cannot be violated, bypassed, or otherwise circumvented.

Strong cryptography is the minimum baseline of acceptable cryptography.

3-1.3 Stored …

Added p. 31

3-1.4.a Perform static analysis to verify the sensitive data is securely deleted once it is no longer necessary to retain. If this is not possible due to a legitimate and verified technical constraint, then verify the sensitive data is rendered unrecoverable. 3-1.4.b Perform dynamic analysis to verify the analysis and findings in 3-1.4.a. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the methods employed to securely delete or render the sensitive data unrecoverable. - Where a technical constraint is stated, verify the technical constraint. - Attempting to recover sensitive data after being securely deleted or otherwise rendered unrecoverable.

- Attempting to violate, bypass, or otherwise circumvent the methods employed to securely delete or render the sensitive data unrecoverable. - Where a technical constraint is stated, verify the technical constraint. - Attempting to recover sensitive data after being securely deleted or otherwise rendered unrecoverable.

For 3-1.4 …

Added p. 32

3-3.a Examine vendor documentation to verify the requirements in 3-3.1 through 3-3.4. Leverage the information examined and verified in 2-1.x, 2-2.x, and 2- 3.x to assist in the assessment.

Requirement 3-3, including the sub-requirements, ensure the software is designed to properly account for the secure storage of sensitive resources. The software design and implementation will be analyzed and tested to ensure they satisfy the requirements and align with the relevant documentation reviewed in Security Objective 2.

3-3.1 Only stored if storage of the sensitive resource is permissible, and only as necessary.

3-3.1.a Perform static analysis to verify that all sensitive resources capable of being stored are only stored as necessary and are permissible to be stored. 3-3.1.b Perform static analysis to identify all sensitive resources that are capable of being stored that were not previously identified as being stored. Verify at this point that all sensitive resources capable of being stored are accounted …

Added p. 33

3-3.2.1.a Perform static analysis to verify that cryptography leveraged to protect sensitive resources in storage satisfies the definition of strong cryptography. 3-3.2.1.b Perform static and/or dynamic analysis as necessary to verify that the use of strong cryptography being leveraged to protect sensitive resources in storage cannot be violated, bypassed, or otherwise circumvented.

3-3.3.a Perform static analysis to verify the sensitive resources are stored in accordance with the defined retention policies that are reviewed and verified from all applicable requirements in Security Objective 2, in particular 2-2.4[.x]. 3-3.3.b Perform dynamic analysis to verify that sensitive resources are retained in accordance with the defined retention policies. Testing includes, but is not limited to:

Added p. 34

3-3.4.a Perform static analysis to verify the sensitive resources are securely deleted once they are no longer necessary to retain. If this is not possible due to a legitimate and verified technical constraint, then verify the sensitive resources are rendered unrecoverable. 3-3.4.b Perform dynamic analysis to verify the analysis and findings in 3-3.4.a. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the methods employed to securely delete or render the sensitive resources unrecoverable. - Where a technical constraint is stated, verify the technical constraint. - Attempting to recover sensitive resources after being securely deleted or otherwise rendered unrecoverable.

- Attempting to violate, bypass, or otherwise circumvent the methods employed to securely delete or render the sensitive resources unrecoverable. - Where a technical constraint is stated, verify the technical constraint. - Attempting to recover sensitive resources after being securely deleted or otherwise rendered unrecoverable.

Where there …

Added p. 35

Notes: Refer to the PCI Secure Software Standard

• Sensitive Asset Identification document for information regarding sensitive modes of operation.

The software is not required to implement a sensitive mode of operation; however, if it contains sensitive functionality that meets the definition of a sensitive mode of operation, then the requirements here in Security Objective 4 apply.

Security Requirements Test Requirements Guidance 4-1 Sensitive modes of operation are designed to facilitate mitigating their unauthorized access and minimizing their misuse during authorized access, which includes but is not limited to the following:

4-1.a Examine vendor documentation to verify the requirements in 4-1.1 through 4-1.9. Leverage the information examined and verified in Security Objective 2, in particular from 2-3.[x], to assist in the assessment.

Sensitive modes of operation are a defined type of sensitive functionality. These modes of operation open up potential for increased risk, and as such, they warrant additional implementation considerations within the software design.

4-1.1 …

Added p. 36

4-1.2.a Examine vendor documentation to verify a defined maximum number of failed access attempts within a defined period of time is implemented for each sensitive mode of operation. 4-1.2.b Perform static analysis to verify the information from 4-1.2.a. 4-1.2.c Perform dynamic analysis to verify the analysis and findings from 4-1.2.a/b. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the threshold limits and/or duration of time it occurs in.

Absence of a defined limit of allowable failed access attempts allows for unlimited and continual access attempts, until eventually an access attempt is successful.

A defined limit within a defined period of time mitigates this potential form of attempted compromise aimed at gaining unauthorized access to sensitive modes of operation. The limit threshold and the duration of time it occurs in should be as low and short, respectively, as is reasonably possible. They should be based on …

Added p. 37

4-1.4.a Examine vendor documentation to verify for each sensitive mode of operation that failed access attempts do not disclose information that can assist in gaining unauthorized access. 4-1.4.b Perform static analysis to verify the information from 4-1.4.a. 4-1.4.c Perform dynamic analysis to verify the analysis and findings from 4-1.4.a/b. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the methods employed in order to obtain useful information that can be used to gain unauthorized access.

Disclosing certain information on failed access attempts can assist in attempts to gain unauthorized access.

For example, if one or more authentication factors are entered, do not disclose if any of them are invalid. Rather, at most, provide a generic message or indication that the access attempt is unsuccessful. The same applies to any information being provided that is used to determine successful access.

4-1.5 Implement a timeout based on a defined …

Added p. 38

4-1.6.a Examine vendor documentation to verify for each sensitive mode of operation that a maximum duration of use timeout has been implemented, upon which the software exits the sensitive mode of operation and returns to normal operation. 4-1.6.b Perform static analysis to verify the information from 4-1.6.a. 4-1.6.c Perform dynamic analysis to verify the analysis and findings from 4-1.6.a/b. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the implemented maximum duration of use timeouts.

Allowing an unrestricted duration of use for a sensitive mode of operation can lead to potential compromise or exacerbate compromise from successful unauthorized access. It can also fail to mitigate or reduce potential misuse from authorized access.

The maximum timeout duration, which can be a configurable value, should be based on an appropriate risk analysis relative to the potential consequences of both unauthorized access and authorized access, in addition to the …

Added p. 39

4-1.7.1.a Examine vendor documentation to verify for each sensitive mode of operation that records include information that can uniquely identify each failed access attempt. 4-1.7.1.b Perform static analysis to verify the information from 4-1.7.1.a. 4-1.7.1.c Perform dynamic analysis to verify the analysis and findings from 4-1.7.1.a/b. Testing should include, but is not limited to:

- Attempting to access each sensitive mode of operation using invalid information and verifying the subsequent record creation for the unique failed access attempt.

Recording failed access attempts can be used to identify potential unauthorized access attempts.

The recorded event should be uniquely identifiable from any other attempted access event (e.g., including a timestamp of the event, or any other pertinent information to facilitate the uniqueness of the event).

4-1.7.2 The records include information that can uniquely identify each successful access event, including traceability to the entity that access was granted to.

4-1.7.2.a Examine vendor documentation to verify for each sensitive …

Added p. 40

4-1.7.3.a Examine vendor documentation to verify for each sensitive mode of operation that records include information that can uniquely identify the net effect, or change, resulting from access to the sensitive mode of operation. 4-1.7.3.b Perform static analysis to verify the information from 4-1.7.3.a. 4-1.7.3.c Perform dynamic analysis to verify the analysis and findings from 4-1.7.3.a/b. Testing should include, but is not limited to:

Recording the net effect, or change, provides an auditable record of changes to the software, or otherwise, the result of the access granted to the sensitive mode of operation.

In the event of unauthorized access, or misuse of authorized access, this information can be used to perform a risk assessment of the net result of the event.

4-1.7.4 The software is designed to protect these records from compromise using strong cryptography.

4-1.7.4.a Examine vendor documentation to verify for each sensitive mode of operation that records are protected using strong cryptography. …

Added p. 41

Implementation Notes The software is not required to retain the records on the same system the software resides. The records can be offloaded elsewhere, in either physical and/or logical form. However, doing so still requires the records to be protected.

4-1.7.6.a Examine vendor documentation to verify for each sensitive mode of operation that records are retained for a defined retention period. 4-1.7.6.b Perform static analysis to verify the information from 4-1.7.6.a. 4-1.7.6.c Perform dynamic analysis to verify the analysis and findings from 4-1.7.6.a/b. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the implemented record-retention parameters.

Retaining records for either too short or too long of a period of time likely poses risks or issues.

The record-retention period should be based on an appropriate risk analysis relative to the potential consequences of retaining them for too short or too long a period of time. This will also …

Added p. 42

Notes: The mechanisms that can be employed to satisfy these requirements will be specific to each unique software implementation, including the particular programming languages used, third-party elements used, and underlying platform considerations. The security requirements are designed to provide the necessary flexibility for the software vendor in designing their software to satisfy this security objective.

Security Requirements Test Requirements Guidance 5-1 Platform-based security mechanisms relied upon by the software to facilitate protecting sensitive assets have been evaluated.

Implementation Notes Leveraging underlying platform-based security mechanisms is not required; however, their use does not supersede or otherwise replace any security requirements in this standard.

5-1.a Examine vendor documentation to verify the platform mechanisms used, and to what extent they are relied on, to protect sensitive assets. 5-1.b Examine vendor documentation and all necessary additional evidence to verify that where security mechanisms leveraged by the software under assessment to this standard rely on previous approvals or …

Added p. 43

5-2.a Examine vendor documentation to verify how the software is designed to facilitate pre-emptively mitigating anomalous behavior from occurring to protect sensitive assets.

5-2.b Perform static analysis to verify the information from 5-2.a. 5-2.c Perform dynamic analysis to verify the analysis and findings from 5-2.a/b. Testing should include, but is not limited to:

- Attempting to bypass or otherwise circumvent the implemented mechanisms.

Anomalous behavior is any unexpected behavior. At the time something unexpected occurs, it may not be possible to identify if the behavior is in fact related to malicious intent or potential compromise.

Therefore, the software is designed to operate in the context of an ideally zero-trust model regarding anomalous behavior, in an attempt to proactively and defensively mitigate

•or where that isn’t possible

• minimize the impact, of unexpected behavior, with the intent to protect sensitive assets.

5-2.1 Facilitating the mitigation of anomalous behavior as a result of input from external sources.

5-2.1.a Examine vendor …

Added p. 43

- Attempting to purposefully manipulate inputs with intent to cause risk to sensitive assets.

Testing Notes The testing strategies will be highly contingent on, and should be catered to: the type of software, the programming language(s), the specific design and interfaces, etc. The goal is to verify there is demonstrable evidence that mechanisms are in place and seemingly effective at satisfying the requirement.

Input from external sources, especially originating from untrusted networks, can pose significant risk to the software and its underlying sensitive assets. A zero, or as near zero as possible, trust model can be useful to employ in the design of the software regarding inputs, and to limit the potential attack surface. This generally results in a proactive, defensive strategy being implemented.

Generally, securely handling input can include, but is not limited to:

- Define inputs, e.g., type, range, length, format, etc. - Validate input - Canonicalization - Whitelist known-good inputs - …

Added p. 44

5-2.2.a Examine vendor documentation to verify how the software is designed to facilitate mitigating anomalous behavior as a result of expected error conditions.

- Attempting to purposefully manipulate the software with intent to cause risk to sensitive assets due to unexpected consequences of errors.

Added p. 44

Plan to identify the potential for where and when errors could occur and design the software to handle the errors securely. The consequence of not doing so can risk compromising sensitive assets.

Added p. 45

5-2.3.a Examine vendor documentation to verify if the software is capable of retrieving or receiving externally- hosted third-party elements during runtime.

5-2.3.b Perform static analysis to verify the information from 5-2.3.a. If it is determined that the software is capable of retrieving or receiving externally-hosted third- party elements during runtime, assess the remaining test requirements below. 5-2.3.c Leverage the information from 5-2.3.a/b and perform static analysis to verify the mechanisms implemented to facilitate the mitigation of anomalous behavior as a result of retrieving or receiving externally- hosted third-party elements during runtime. 5-2.3.d Perform dynamic analysis to verify the analysis and findings from 5-2.3.c. Testing should include, but is not limited to:

- Attempting to violate, bypass, or otherwise circumvent the implemented mechanisms. For example, by forcing the software to retrieve third-party elements without any protective/defensive mechanisms being employed. This can include fetching an element with an invalid signature, no signature, malformed code, …

Added p. 46

Implementation Notes This is related to 5-2; however, it is not identical in intent. 5-2 facilitates designing the software to prevent anomalous behavior from ever occurring. However, as that is statistically impossible to achieve absolutely, this requirement 5-3 facilitates identifying and securely handling unexpected behavior should it occur.

5-3.a Examine vendor documentation to verify how the software is designed to facilitate detecting suspected anomalous behavior in order to protect sensitive assets.

In addition to the intentional security-relevant architectural design aspects related to 5-2[.x], the software is also designed to facilitate the detection and handling of anomalous behavior in the event it does occur.

Plan to design the software to attempt to identify unexpected behavior. Solely here as a contextual example, assertions can be used to validate ‘something” is as expected, e.g., the state or value of something. This methodology can be useful to identify that something unexpected might have occurred; however, it isn’t …

Added p. 47

5-3.1.a Examine vendor documentation to verify how the software is designed to facilitate mitigating, or at least minimizing, the impact of suspected anomalous behavior, or otherwise fails in a secure manner.

Based on the detection in 5-3, the software is then designed to securely handle the suspected anomalous behavior to protect sensitive assets. Mitigation is ideal, or at least the minimization of potential impact, even if it means the software needs to fail in a secure manner.

Examples of mitigation and minimization of impact include, but are not limited to: preventing the execution of the anomalous behavior, breaking or stopping code execution, terminating an authenticated session, executing a preprogrammed risk-mitigation routine, or deleting or clearing memory.

5-3.2 The software is designed to provide an immediate indication of suspected anomalous behavior.

5-3.2.a Examine vendor documentation to verify how the software is designed to provide an immediate indication of suspected anomalous behavior.

If the software identifies suspected …

Added p. 48

5-3.2.1.a Examine vendor documentation to verify how the software is designed to protect the indication of suspected anomalous behavior against compromise.

5-3.2.1.b Perform static analysis to verify the information from 5-3.2.1.a. 5-3.2.1.c Perform dynamic analysis to verify the analysis and findings from 5-3.2.1.a/b. Testing should include, but is not limited to:

An indication or notification isn’t particularly useful if it can be easily subverted or compromised; therefore, it should be designed robustly.

The vendor should implement the indication/notification mechanism in a manner that is appropriate for their software and its intended environment, and is in accordance with their own risk analysis.

5-3.3 The software is designed to retain, or facilitate the retention of, a record of suspected events of anomalous behavior.

Creating and retaining records is essential to monitor for potential compromise resulting from suspected anomalous behavior.

Records regarding suspected anomalous behavior are considered a sensitive resource and are therefore subject to requirements regarding sensitive resources …

Added p. 49

5-3.3.2.a Examine vendor documentation to verify that records are protected using strong cryptography. 5-3.3.2.b Perform static analysis to verify the information from 5-3.3.2.a. 5-3.3.2.c Perform dynamic analysis to verify the analysis and findings from 5-3.3.2.a/b. Testing should include, but is not limited to:

- Attempting to bypass the protection mechanisms to gain access to cleartext records and/or the relevant information.

5-3.3.3.a Examine vendor documentation to verify that strong authentication is required to access associated records. 5-3.3.3.b Perform static analysis to verify the information from 5-3.3.3.a. 5-3.3.3.c Perform dynamic analysis to verify the analysis and findings from 5-3.3.3.a/b. Testing should include, but is not limited to:

5-3.3.4 The records are retained for a defined retention period.

5-3.3.4.a Examine vendor documentation to verify records of suspected anomalous behavior events are retained for a defined retention period.

Retaining records for either too short or too long a period of time likely poses risks or issues.

The record-retention period should …

Added p. 50

5-3.3.5.a Verify that records associated with anomalous behavior events (requirements 5-3[.x]) have been accounted for in the assessment of requirement 6-2[.x].

5-4 The software is designed to facilitate securely implementing authorized access to sensitive assets, which includes access to:

5-4.a Examine vendor documentation to verify that the software is designed to facilitate securely implementing authorized access to sensitive assets, including the avoidance of known authorization-based flaws. Leverage this information for 5-4.[x].

Access-control issues are a well-documented risk that can be used to propagate or otherwise facilitate compromising the software.

Permissible access to sensitive assets needs to be limited to only the absolutely required means/entities.

There is extensive documentation online regarding authorization-based flaws for specific languages/frameworks. These resources can be leveraged to obtain information to assist in designing the software to facilitate satisfying this requirement.

Note that authorization is uniquely different than authentication (e.g., an authenticated entity may not be authorized for a particular activity. Also note …

Added p. 51

- Attempting to violate, bypass, or otherwise circumvent the authorized access mechanisms to sensitive modes of operation.

Additional or unique considerations are needed for sensitive modes of operation, given their criticality and ability to significantly affect the software itself, as well as all underlying sensitive assets.

5-5 The software is designed to facilitate mitigating inadvertently disclosing, exposing, or otherwise leaking sensitive assets, which includes:

Implementation Notes There is going to inevitably be partial overlap here with requirements in other Security Objectives (e.g., encrypting sensitive data can help prevent disclosure). Requiring authentication to a sensitive mode of operation can help protect sensitive assets. Implementation according to least privilege can also help. This requirement, however, is more encompassing and overarching in consideration of the overall software architecture. Refer to the guidance for more information.

5-5.a Examine vendor documentation to verify the software is designed to facilitate mitigating inadvertently disclosing, exposing, or otherwise leaking sensitive assets. This …

Added p. 52

The strategies employed for sensitive data and sensitive resources might be similar in design. However, those employed for sensitive functionality are likely different, given the fundamental difference in context.

5-5.2 Sensitive resources 5-5.2.a Perform static analysis to verify the software is designed to facilitate mitigating inadvertently disclosing, exposing, or otherwise leaking sensitive resources. Leverage, in part, the information from Security Objective 2 regarding sensitive resources, including information regarding sensitive functionality related to sensitive resources. 5-5.2.b Perform dynamic analysis to verify the analysis and findings from 5-5.2.a. Testing should include, but is not limited to:

5-5.3.a Perform static analysis to verify the software is designed to facilitate mitigating inadvertently disclosing, exposing, or otherwise leaking sensitive functionality. Leverage, in part, the information from Security Objective 2 regarding sensitive functionality. 5-5.3.b Perform dynamic analysis to verify the analysis and findings from 5-5.3.a. Testing should include, but is not limited to:

- Attempting to find unexpected ways …

Added p. 53

- Attempting to find unexpected ways to gain access to sensitive modes of operation. isolated as possible. This is especially true for sensitive modes of operation.

Added p. 54

Notes: “Output” refers to any form of output of a sensitive asset from the software that results in the software essentially relinquishing direct control and protection of that asset. This can include, but is not limited to: transmission over a network, output to the operating system, output to a co-resident application on the same underlying hardware platform, output to shared memory, output through a hardware interface/port, etc.

Security Requirements Test Requirements Guidance 6-1 All forms of sensitive assets that are capable of being output from the software are identified and documented.

Implementation Notes While the flow diagrams in 2-1.7 and 2- 2.8 are used to document all sensitive data and sensitive resources being output from the software, they are confirmed here in the context of Security Objective 6. This requirement is in regard to any output: cleartext, encrypted, truncated, hashed, and/or any other form.

6-1.a Leverage the information from 2-1[.x] and 2-2[.x], in …

Added p. 55

6-2.1.a Examine vendor documentation to verify the cryptographic algorithms and associated key lengths are documented and satisfy the use of strong cryptography. 6-2.1.b Perform static analysis to verify the software is designed to encrypt the applicable cleartext sensitive assets identified in 6-1 using strong cryptography. 6-2.1.c Perform dynamic analysis to verify the analysis and findings from 6-2.1.a/b. Testing should include, but is not limited to:

- Attempting to obtain applicable sensitive assets being output in cleartext from the software.

This information should correlate to the cryptographic key information from 2-1[.x][.y], and the sensitive functionality from 2-3[.x].

6-2.2 If the software facilitates establishing a channel to transmit sensitive assets, a secure channel is used, which includes:

6-2.2.a Examine vendor documentation to verify if the software facilitates the establishment of any channels to transmit sensitive assets.

6-2.2.b Based on 6-2.2.a, leverage the information from 6- 1 and verify 6-2.2.1 through 6-2.2.7.

6-2.2.c Perform static analysis to verify the …

Added p. 56

6-2.2.5.a Examine vendor documentation to verify the mutual authentication details of each secure channel are identified and documented.

Mutual authentication can facilitate the protection of the sensitive assets, as well as protect against man-in-the- middle (MITM) and/or replay attacks.

6-2.2.6 Secret or private cryptographic keys used to establish and maintain secure channels are unique per session, except by chance.

6-2.2.6.a Examine vendor documentation to verify the secret or private cryptographic keys used to establish and maintain each secure channel are unique per session, except by chance.

Reuse of keys poses risks of potential compromise of sensitive assets and/or the secure channel itself.

6-2.2.7 The secure channels are implemented to mitigate downgrade attacks.

6-2.2.7.a Examine vendor documentation to verify each secure channel is implemented in a manner that mitigates downgrade attacks.

Manipulating the channel to “fallback” or be “downgraded” to an insecure protocol or lower encryption strength that does not meet the intent of strong cryptography will put …

Added p. 57

Notes: The software is not required to use random values; however, if it does, in association with sensitive assets, then this Security Objective 7 applies.

Security Requirements Test Requirements Guidance 7-1 The sensitive assets associated with random numbers are identified and documented.

7-1.a Examine vendor documentation to verify if the software uses random values, and if so, all correlations with the sensitive assets identified and verified in Security Objective 2.

7-1.b Perform static analysis and verify the analysis and findings from 7-1.a. All use cases of random values being used in association with sensitive assets must be accounted for.

Random numbers are relied upon by many security processes and secure communications methods. Generation of random numbers with insufficient entropy has been the cause of many high-profile vulnerabilities.

Random numbers are to be generated using a process that ensures sufficient entropy and lack of statistical correlation.

Both direct and indirect associations need to be accounted for. A …

Added p. 58

Implementation Notes It is permitted for the software to leverage an RNG implementation provided by the underlying platform, especially if it is a sufficient hardware- based RNG. This can also be used to provide the entropy sources into a DRNG, provided requirement 7-1.1 is satisfied.

“Security strength” can be used interchangeably with “effective key strength”.

7-1.1.a Examine vendor documentation to verify the random-number generator implementation, which includes the entropy source, supports the security strength equal to or greater than the security strength of the strongest cryptographic key supported. Demonstrable test evidence must corroborate this finding.

The software vendor needs to exercise due diligence and determine, where an RNG is needed, an appropriate RNG implementation that can be leveraged.

It is highly encouraged to use generally “known-good” implementations that are recognized to provide the necessary characteristics in the context of cryptography and security, specifically the minimum required level of entropy.

The randomness of the seed is …

Added p. 59

Implementation Notes By definition, this is a deterministic random-number generator (DRNG) and therefore requires a sufficient entropy source.

For software being assessed to Module B, refer to B2-7.

7-1.3.a Examine vendor documentation to verify if the software design includes its own random-number generator implementation. If it does, assess 7-1.3[.x].

As stated for 7-1.1, it is highly encouraged to use generally “known-good” implementations that are recognized to provide the necessary sufficient characteristics in the context of cryptography and security. There may be additional risk when creating new RNG implementations within the software directly.

7-1.3.1 The DRNG algorithm is designed and implemented based on industry-recognized standards.

7-1.3.1.a Examine vendor documentation to verify the random-number generator implementation is designed based on industry-recognized standards.

7-1.3.1.b Perform static analysis to verify the analysis and findings from 7-1.3.1.a.

7-1.3.1.c Perform dynamic analysis to verify the analysis and findings from 7-1.3.1.a/b.

Leverage industry resources, e.g., NIST SP800-90a or ISO/IEC 18031, regarding appropriate algorithms.

7-1.3.2 A trusted …

Added p. 60

7-1.3.3.a Examine vendor documentation to verify the seeding period.

A DRNG, by definition, is deterministic. Given the same input, it will produce the same output. Therefore, it is important that the input to a DRNG

•the ‘seed”

•is sufficiently unpredictable.

To ensure that a compromise of a DRNG state during operation does not result in the compromise of all further values output from that DRNG, the DRNG is required to be regularly reseeded.

7-1.3.4 The seed values are protected from disclosure and modification using strong cryptography.

7-1.3.4.a Examine vendor documentation to verify the protection mechanisms implemented to facilitate the mitigation of the seed values from disclosure/modification.

7-1.3.4.b Perform static analysis to verify the analysis and findings from 7-1.3.4.a, in the context of the software under assessment, regarding the protection of seed values from their initial existence within the software up to their use in the RNG and their subsequent secure deletion.

The criticality of the seed values, relative …

Added p. 61

Notes: These requirements relate to all cryptographic keys associated with sensitive assets, which includes sensitive data, sensitive resources, sensitive functionality, and sensitive modes of operation. Where there is an association between a cryptographic key and a sensitive asset, that inherently qualifies the cryptographic key, and any associated key material, as sensitive data and needs to be identified in Security Objective 2.

Leverage the information from Security Objective 2 regarding cryptographic keys, as well as for certificates that qualify as a sensitive resource.

Security Requirements Test Requirements Guidance 8-1 Cryptographic keys that are generated by the software use an entropy source as input that is at least equal to the intended effective strength of the key being generated.

Implementation Notes The software is not required to generate its own cryptographic keys; however, if it does, then the generation process must be sufficient, including the sourced entropy.

8-1.a Examine vendor documentation to verify if the software …

Added p. 62

8-2.1.a Perform static analysis to verify cleartext cryptographic keys are not stored in non-volatile memory.

Ephemeral cryptographic keys might be loaded into the software to perform a defined cryptographic function. They should only exist within volatile memory for only as long as necessary, and they cannot be stored or otherwise retained in cleartext in non-volatile memory unnecessarily.

This requirement should be represented in the information reviewed and verified in Security Objective 2, both in terms of identifying such keys, as well as the storage and retention parameters.

8-3 Cryptographic keys are only used for a single, predetermined purpose.

8-3.a Perform static analysis to verify cryptographic keys are only used for a single, predetermined purpose.

8-3.b Perform dynamic analysis to verify the analysis and findings from 8-3.a. Attempt to use keys for more than one purpose, or otherwise for a purpose they are not defined to be used for.

Isolating the use of cryptographic keys to a …

Added p. 63

8-5.a Leverage the information from Security Objective 2 regarding cryptographic keys. Perform static analysis to verify public keys are protected for integrity and authenticity and are authenticated before they are used.

8-5.b Perform dynamic analysis to verify the analysis and findings from 8-5.a. Attempt to use public keys in a manner that is not in accordance with requirement 8-5.

Certificates are often used to exchange public keys. Verification of certificate signatures can be used to authenticate the public key. This is normally guaranteed by verifying the complete certificate chain up to the certificate authority.

8-6 Cryptographic key derivation and key check functions are required to be implemented:

8-6.a Leverage information from Security Objective 2, in particular from 2-3[.x], for 8-6.1 and 8-6.2.

These functions can leak sensitive information and therefore should be implemented in a manner that makes the discovery of any inputs into these functions infeasible. 8-6.1 As one-way functions. 8-6.1.a Perform static analysis …

Added p. 64

Notes: Strong cryptography is the minimum baseline allowed for the use of cryptography regarding sensitive assets. Refer to the definition of strong cryptography in the ‘terminology’ section in this standard.

Security Requirements Test Requirements Guidance 9-1 The use of cryptography related to sensitive assets that is not already accounted for elsewhere in this standard satisfies the definition of strong cryptography.

9-1.a Examine vendor documentation to verify if the software is leveraging cryptography, in relation to sensitive assets, that is not otherwise already accounted for by the other explicit requirements in this standard.

9-1.c Verify, based on the analysis and findings from 9- 1.a/b, that either:

(1) There is no additional use of cryptography, in relation to sensitive assets, that is not otherwise accounted for elsewhere in this standard. Or, (2) There is additional use of cryptography, in relation to sensitive assets, that is not otherwise accounted for elsewhere in this standard, and it satisfies …

Added p. 65

Notes: [No Notes] Security Requirements Test Requirements Guidance 10-1 The software is designed and updated as needed to mitigate known threats and vulnerabilities that could pose risks to sensitive assets.

10-1.a Examine vendor documentation to verify the software is designed to mitigate known threats and vulnerabilities that could pose risks to sensitive assets.

10-1.b Examine vendor documentation to verify that processes exist to update the software as needed to account for newly-discovered relevant threats and vulnerabilities.

Due diligence includes creating awareness of known threats and vulnerabilities that could be exploited and attempting to mitigate them.

This context will be highly dependent on the unique software under assessment, including the programming language(s) used, third-party libraries, underlying platform considerations, etc.

Evidence should demonstrate that the intent to mitigate relevant potential threats was proactively factored into the software design, and processes exist to reconsider them for all software update activity.

Robust policies and processes in this regard can increase …

Added p. 66

10-1.1.2.a Examine vendor documentation to verify the software is designed with an awareness of avoiding known security issues in all third-party elements being used by, or within, the software. Leverage information from Security Objective 1 regarding the composition of the software, as well as noted dependencies, including the documented provenance information.

10-1.1.2.b Perform static analysis to verify the software is designed in accordance with requirement 10-1.1.2 and the information from 10-1.1.2.a.

The use of third-party elements, e.g., code, libraries, components, etc., can pose a risk to the software and the sensitive assets.

There needs to be an awareness not to implicitly trust these elements, and have a process by which any known security-relevant issues in third-party elements are avoided or mitigated, to facilitate the protection of sensitive assets.

10-1.1.3 Protocols Implementation Notes It is possible this might overlap with 10-1.1.1 and/or 10-1.1.2. However, the context of protocols and their potential risk warrants being accounted …

Added p. 67

Notes: [No Notes] Security Requirements Test Requirements Guidance 11-1 The processes involving the release and delivery of the software facilitate maintaining its security and integrity.

11-1.a Examine vendor documentation to verify the processes involving the release and delivery of the software are intended to facilitate maintaining the security and integrity of the software.

Well-documented processes and their adherence are essential to facilitate the secure delivery of the software. This helps mitigate tampering of the software itself and increases the assurance of the software through to its deployment and installation.

11-2 The processes to provide security- relevant software updates facilitate prompt deployment to all affected customers.

11-2.a Examine vendor documentation to verify the processes involving the release and delivery of security- relevant software updates facilitate prompt deployment to affected customers.

Expedient remediation of security-relevant issues helps maintain the security posture of the software and thwarts security concerns or risks.

11-3 The software vendor maintains and provides current …

Added p. 68

11-4.a Examine vendor documentation to verify the mechanisms that are implemented to verify the integrity of the software as part of the initial installation and for updates.

11-4.b Perform dynamic analysis to verify the information from 11-4.a. Testing should include attempts to bypass or circumvent the integrity verification mechanisms.

The capability to verify the successful installation and updates of the software is essential. The mechanisms employed should provide confidence that the integrity of the software is intact, e.g., by verifying a signature of the software.

11-5 The software provides a mechanism to provide its software version information.

11-5.a Leverage the information from 11-3.7 and verify that the software provides a mechanism to provide its software version information.

The software needs to provide its version information. This is useful in any context where the version information needs to be confirmed. The inability to verify the software version information may have undesired consequences.

11-6 The software is designed …

Added p. 69

A1: Securing Account Data Purpose and Scope This module defines additional security objectives and security requirements for software that stores, processes, and/or transmits account data (as defined by PCI DSS). Refer to the PCI Secure Software Standard - Sensitive Asset Identification document for additional details and guidance regarding handling account data.

All software that stores, processes, or transmits account data, or that could impact the security of cardholder data and/or sensitive authentication data, is in scope for an entity’s PCI DSS assessment. While the use of validated software in accordance with this PCI Secure Software Standard supports the security of an entity’s cardholder data environment (CDE), the use of such software does not by itself make an entity PCI DSS compliant, nor does it mean the software itself is PCI DSS compliant. Refer to PCI DSS for detailed information.

Added p. 70

Notes: The handling of PAN and SAD by the software is accounted for generically in relative requirements regarding sensitive data in the “Core

• All Software” section in this standard. Refer to the PCI Secure Software Standard

• Sensitive Asset Identification document for additional assistance regarding PAN and SAD.

These requirements in “Module A

• Account-Data Protection” are intended to facilitate explicitly satisfying respective requirements regarding PAN and SAD in PCI DSS. Refer to the latest version of PCI DSS for complete information and expectations regarding the handling of PAN and SAD as it pertains to the software under assessment for this PCI Secure Software Standard.

Security Requirements Test Requirements Guidance A1-1 SAD is handled in accordance with PCI DSS requirements.

A1-1.a Examine vendor documentation to verify how SAD is managed within the software. Leverage all requisite information from the requirements in Security Objective 2 as is relevant.

A1-1.b Based on the use of SAD by the …

Added p. 71

B1: PTS Approval B2: Approved POI Device Functionality B3: Authentication Purpose and Scope This module defines additional security objectives and security requirements for software that is intended for deployment and execution on Point- of-Interaction (POI) devices that have been evaluated and approved in accordance with the Payment Card Industry (PCI) PIN Transaction Security (PTS) Point-of-Interaction (POI) Standard and Program (otherwise referred to as PTS POI devices).

Added p. 72

Notes: Refer to the PCI SSC’s List of Approved PTS Devices at: https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices Security Requirements Test Requirements Guidance B1-1 The software is intended for deployment and operation on devices that have been evaluated and approved per the PCI PTS POI Standard and its Program.

B1-1.a Examine the software vendor’s documentation to verify the PTS POI devices the software is intended to operate on.

B1-1.b Examine the PCI SSC List of Approved PTS Devices to verify the following information for each PTS device model:

- Model Name/Number - Hardware Version Number(s) - Firmware Version Number (s) - Application (“Applic”) Number(s) - SRED (as applicable) - Open Protocols (OP) (as applicable) - PTS approval number(s) PTS-approved Point of Interaction (POI) payment devices have been evaluated and approved to strict physical and logical protection mechanisms within the PCI PTS POI Standard.

Software that is deployed and executed on these devices should use the approved features and functions …

Added p. 73

Notes: It is not the intent to “reassess” the PTS POI firmware. The intent is to verify the functionality of the software being assessed to this standard as it relates to the PTS POI device, which includes its already-approved hardware and firmware.

Depending on the POI devices being supported, which include the individual HW/FW, it may be possible that both B2-1 and/or B2-2 apply to the software. For example, there could be a build-time option that includes different functionality (depending on the target platform), which might result in different functionality, depending on the underlying HW/FW POI platform.

Security Requirements Test Requirements Guidance If the POI device's HW/FW is not approved to SRED:

B2-1 The software uses strong cryptography to protect account data.

B2-1.a Examine the software vendor’s documentation to verify all mechanisms used to protect account data, both from the underlying POI device platform and within the software itself. Leverage all information/testing from relevant …

Added p. 74

B2-2 The software does not bypass or circumvent the PTS-approved SRED- related functions of the POI device.

B2-2.a Examine the software vendor’s documentation to verify how the software is designed to leverage the PTS POI device’s SRED-approved functionality for each relevant PTS POI device, including the specific HW/FW approved to SRED.

Added p. 74

Testing Notes If all the HW/FW in a unique PTS approval is approved to SRED, only one HW/FW combination for that PTS POI device from the PTS approval needs to be tested in the following requirements.

If some of the HW/FW in a unique PTS approval is approved to SRED and some of the HW/FW is not, only one HW/FW combination for that PTS POI device from the PTS approval needs to be tested in the following requirements.

Leverage the information obtained and verified in B1-1.

SRED is a set of requirements in the PTS POI Standard governing the protection of account data, which cover functionality beyond just encrypting account data before transmitting it. The software needs to leverage the SRED-approved functionality such that it does not inadvertently violate the established PTS approval of the POI device.

B2-2.1 If the software requires account data related encryption functionality that the POI device’s firmware and SRED-related …

Added p. 75

B2-3.a Examine the software vendor’s documentation to verify the software does not contain any functionality to share cleartext account data with any other software other than the PTS POI device’s firmware.

Sharing cleartext account data directly with other software (non-firmware) that may be present on the POI device poses a risk, as the functionality of the other software is unknown.

B2-4 The software does not output cleartext account data outside of the POI device, which also includes:

B2-4.a Examine the software vendor’s documentation to verify the software does not contain any functionality that is capable of outputting cleartext account data from the PTS POI device.

B2-4.c Perform dynamic analysis to verify B2-4.a/b.

This requirement is an extension to 6-2[.x], as there are additional considerations for POI devices.

B2-4.1 The software does not facilitate the visual presentation of cleartext account data.

B2-4.1.a Examine the software vendor’s documentation to verify the software does not contain any functionality that is …

Added p. 76

B2-5.a Examine the software vendor’s documentation to verify the software does not implement its own functionality that is considered an “Open Protocol” as defined in the PCI PTS POI Standard. It is acceptable for the software to use the approved Open Protocols of the PTS POI device’s firmware.

Refer to the PCI PTS POI Standard regarding “Open Protocols”. Another useful source of information can be the security policy that is made available on the individual PTS approvals for the POI devices.

In general, Open Protocols include:

- Link Layer protocols - IP protocols - Security protocols - IP Services B2-6 The software facilitates the management or use of shared platform resources in a secure manner and in accordance with applicable POI device guidance.

B2-6.a Examine the software vendor’s documentation to verify the software facilitates the management or use of shared platform resources in a secure manner and in accordance with applicable POI device guidance.

This …

Added p. 77

Notes: [No Notes] Security Requirements Test Requirements Guidance If the software is capable of facilitating loading additional files/content into the POI device:

B3-1 The software vendor includes additional details in the secure implementation guidance for the process to facilitate the authentication of the files/content by the POI device‘s firmware.

B3-1.a Examine the software vendor’s documentation to verify if the software is capable of facilitating loading additional files/content into the POI device.

B3-1.b Perform static analysis to verify B3-1.a.

B3-1.c Perform dynamic analysis to verify B3-1.a/b.

B3-1.d Examine the implementation documentation from Security Objective 11 and verify it includes secure implementation guidance for the processes to facilitate the authentication of the files/content by the POI device‘s firmware.

The capability to load additional files/content into the POI device can introduce risk. Therefore, where the software itself can facilitate the loading of files, the files are signed and subsequently authenticated in the POI device. Be advised, there are strict …

Added p. 78

C1: HTTP Headers C2: Input Protection Mechanisms C3: Session Management C4: User Authentication Purpose and Scope This module defines additional security objectives and security requirements for software that is accessible over public networks. This implies that essentially anyone or anything that has access to the public network also has access to the software, at least in part. This type of software generally relies on internet-based implementations and protocols. The requirements in this module are intended to address the potential for increased risk due to the public accessibility.

Software that is not publicly accessible can also be assessed to this module at the software vendor’s discretion, as the requirements in Module C can also help reduce risk for those software implementations.

Added p. 79

Notes: There is significant potential risk related to HTTP headers. However, there are also dedicated informative resources available online to assist in utilizing and implementing HTTP headers in a [more] secure manner. As this information is subject to change based on known issues/threats, proactive research is prudent.

Security Requirements Test Requirements Guidance C1-1 HTTP security-related headers are used and configured in a manner to increase the security of the software.

C1-1.a Perform research as needed to determine the current recommendations/options of HTTP security- related headers and their particular configuration options. Leverage this information in the subsequent test requirements.

C1-1.b Examine vendor documentation to verify that security-related headers are used and configured in a manner to increase the security of the software. Where a particular header, or its more secure configuration, isn’t being leveraged, assess C1-1.1.

C1-1.c Perform static analysis and/or dynamic analysis to verify the information and analysis from C1-1.b.

C1-1.1 Where a security-related header …

Added p. 80

C1-2.a Perform research as needed to determine the current HTTP headers that have known security- impacting concerns. Leverage this information in the subsequent test requirements.

C1-2.b Examine vendor documentation to verify that HTTP headers that are known to be vulnerable or otherwise could negatively impact the security of the software are avoided. Where that isn’t being accommodated, assess C1-2.1.

Certain HTTP headers, or their configuration, may be vulnerable or otherwise contribute negatively to the security posture of the software. This information can be ever-changing, and as such, the most current known information in this regard should be leveraged in the software design.

C1-2.1 Where the use of a header or its configuration satisfying this condition cannot be avoided, vendor documentation explains the constraint.

C1-2.1.a Leverage information from C1-2 to verify that the use of HTTP headers that are known to be vulnerable or otherwise could negatively impact the security of the software cannot be …

Added p. 81

Notes: These requirements are intended as an extension to requirement 5-2.1 for input considerations that pose additional and unique risk for publicly-exposed web-based software implementations.

Security Requirements Test Requirements Guidance C2-1 The software is designed to facilitate mitigating injection attacks.

C2-1.a Perform research as needed to determine the current recommendations/options regarding mitigating injection attacks as it pertains to the unique software implementation being assessed (e.g., the programming languages used, the API interface for inputs, etc.). Leverage this information in the subsequent test requirements.

C2-1.b Examine vendor documentation to verify that the software is designed to facilitate mitigating anomalous behavior from content being uploaded.

C2-1.c Perform static analysis to verify the information and analysis from C2-1.b.

C2-1.d Perform dynamic analysis to verify the information and analysis from C2-1.b/c. Testing should include attempts to exploit content uploads in a manner intended to compromise the software and/or underlying sensitive assets.

Web-based software is highly susceptible to injection attacks.

The software …

Added p. 82

C2-2.a Perform research as needed to determine the current recommendations/options regarding secure deserialization techniques that apply to the unique implementation of the software being assessed. Leverage this information in the subsequent test requirements.

C2-2.b Examine vendor documentation to verify that the software is designed to implement secure deserialization.

C2-2.d Perform dynamic analysis to verify the information and analysis from C2-2.b/c. Testing should include attempts to exploit the deserialization functionality.

Deserialization functionality can be susceptible to the exploitation of serialized formats, e.g., XML, JSON, etc.

The software should be designed to securely implement deserialization functionality.

C2-3 The software is designed to securely implement and configure the use of parser and interpreter functionality.

C2-3.a Perform research as needed to determine the current recommendations/options regarding secure parser/interpreter implementations and configurations that apply to the unique implementation of the software being assessed. Leverage this information in the subsequent test requirements.

C2-3.b Examine vendor documentation to verify that the software is designed …

Added p. 83

C2-4.a Examine vendor documentation to verify that the software is designed to facilitate mitigating anomalous behavior from content being uploaded.

C2-4.b Perform static analysis to verify the information and analysis from C2-4.a.

C2-4.c Perform dynamic analysis to verify the information and analysis from C2-4.a/b. Testing should include attempts to exploit content uploads in a manner intended to compromise the software and/or underlying sensitive assets.

Generally, but not exclusively, content is uploaded in the form of files. Uploaded content may be designed to exploit or otherwise compromise the software.

There are numerous ways uploaded content/files can be used for malicious intent.

A few items of consideration might include, but are not limited to:

- Allowable and blocked file extensions - Filename safety - Allowable file size - Content validation - Maximum allowable number of uploaded files - Allowable file storage locations - File permissions (e.g., user, filesystem)

C2-5.b Perform static analysis to verify the information and analysis from …

Added p. 84

C2-5.a Examine vendor documentation to verify that the software is designed to facilitate mitigating resource starvation.

C2-5.c Perform dynamic analysis to verify the information and analysis from C2-5.a/b. Testing should include attempts to exploit the implemented resource starvation mitigation mechanisms.

Web-based interfaces can be [more] susceptible to or otherwise propagate resource starvation attacks. These types of attacks can directly affect the software’s functionality or potentially create risk to underlying sensitive assets.

Such attacks aim to overwhelm the software (and underlying system) with requests, or fill all available system resources such as processing time or memory, thereby starving the software/system of the resources it requires for normal operation.

These attacks can also be used to try and force the software to behave in unintended ways, which could potentially enable an attacker to execute arbitrary code on the targeted system or expose sensitive assets, e.g., through error messages. A few items of consideration might include, but …

Added p. 85

Notes: [No Notes] Security Requirements Test Requirements Guidance C3-1 The software securely implements and manages sessions, which includes but is not limited to accounting for the following:

C3-1.a Perform research as needed to determine mechanisms and strategies regarding session management (including all contexts from C3-1.[x]) that apply to the unique implementation of the software being assessed. Leverage this information in the subsequent test requirements.

C3-1.b Examine vendor documentation to verify that the software is designed to securely implement and manage sessions.

Session management refers to essentially creating a context of state, which is useful for stateless protocols such as HTTP.

However, elements of the session can potentially be compromised, which can lead to compromise of the session itself (commonly referred to as session hijacking).

Session implementation and management considerations will be highly dependent on the specific software use case, design, web framework, and overall implementation.

C3-1.1 Session identifier token exchange mechanisms C3-1.1.a Examine vendor documentation to …

Added p. 85

Per OWASP, example considerations for the session identifiers include: - Name Fingerprinting - Entropy - Length - Content/Value C3-1.3 Session timeouts C3-1.3.a Examine vendor documentation to verify that the software is designed to securely manage and implement session timeouts.

This should include consideration for maximum use/session duration timeout, inactivity timeout, etc.

Added p. 86

Sessions should be terminated securely, which can also include securely establishing a new session after termination (e.g., by requiring reauthentication).

C3-1.5 Concurrent sessions C3-1.5.a Examine vendor documentation to verify that the software is designed to securely manage and implement concurrent sessions.

There should be a defined limit for the allowable number of concurrent sessions attributed to the same entity.

C3-1.6 Use of secure session- management implementations C3-1.6.a Examine vendor documentation to verify that the software is designed to utilize known-good session- management implementations.

Known-good, or well-established session-management implementations based on the web framework being leveraged should be used as they are widely adopted and well-documented. These types of implementations are generally more secure and reliable. This is preferable over custom or proprietary implementations.

Added p. 87

Notes: [No Notes] Security Requirements Test Requirements Guidance C4-1 The software authenticates authorized user access to sensitive assets via publicly-accessible interfaces.

C4-1.b Perform static analysis to verify the information and analysis from C4-1.a.

C4-1.c Perform dynamic analysis to verify the information and analysis from C4-1.a/b. Testing should include ensuring non-authorized users cannot be authenticated or otherwise provided access. Leverage information and testing from 5-4.

Authentication, in addition to authorization, helps mitigate malicious access to sensitive assets via the software’s publicly-accessible interfaces.

The authorization can be at the individual level, or a group-identity level, as appropriate based on context. The authentication should be unique to the user.

Added p. 89

Notes: [No Notes] Security Requirements Test Requirements Guidance D1-1 The SDK is designed to mitigate the tampering of its execution and the compromise of its sensitive assets.

D1-1.a Examine the software vendor’s documentation to verify the SDK is designed to mitigate the tampering of its execution and the compromise of its sensitive assets.

D1-1.b Perform static analysis to verify D1-1.a D1-1.c Perform dynamic analysis as deemed necessary to verify D1-1.a/b. Sample tests might be to reconstruct the code or functionality in an effort to alter the SDK code, attempt to hook the SDK, or otherwise reverse engineer the SDK with the intent of attempting to compromise its execution and/or sensitive assets.

As an SDK is generally provided to third parties for integration into other software, there is risk of tampering or modification of the SDK code/functionality. This risk should be accounted for.

Code obfuscation techniques can be a viable mechanism. Obfuscation reduces the efficacy …

Added p. 91

Operating System (OS) System software that manages the underlying hardware and software resources and provides common services for programs.

PAN Refer to the PCI Secure Software Standard

• Sensitive Asset Identification document and PCI DSS.

Private Key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and is not made public.

In the case of an asymmetric signature system, the private key defines the signature transformation. In the case of an asymmetric encipherment system, the private key defines the decipherment transformation.

Program The latest version of the PCI Secure Software - Program Guide that is associated with this version of the PCI Secure Software Standard.

Provenance Information Information that describes the chronology of ownership, custody, and/or location of a particular software component.

Public Key A cryptographic key used with a public-key cryptographic algorithm that is uniquely associated with an entity and may be made public.

In the case of an asymmetric …

Added p. 92

Static Analysis Any means of analyzing software without executing it.

Strong Authentication User authentication that requires the use of two or more authentication factor types (multi-factor authentication).

Phishing-resistant authentication can be used as a factor type in a multi-factor implementation if the user is required to supply another factor (such as a PIN, password, or biometric) to enable the phishing-resistant factor, or in addition to the phishing-resistant authentication.

The use of secrets (e.g., a password) as an authentication factor requires industry-recognized composition considerations, such as length and complexity. Refer to guidance such as NIST SP800-63B.

Strong Cryptography Refer to entry for Strong Cryptography in the PCI SSC Glossary located at: https://www.pcisecuritystandards.org/glossary Third-Party Element Any element that is not directly designed, created, or otherwise managed by the software vendor submitting the software product for assessment to this standard. This includes, but is not limited to, libraries, components, dlls, files, lists, content, scripts, etc.

Added p. 93

PCI SSC Note: PCI SSC resources can be found at: https://www.pcisecuritystandards.org/document_library

PCI Secure Software Standard

• Sensitive Asset Identification

PCI Secure Software Technical FAQs

PCI Secure Software Report on Validation (ROV) Template

PCI Secure Software Attestation of Validation (AOV) Template

PCI Data Security Standard

Added p. 94

• Security techniques

• Random bit generation SP800-63B - Digital Identity Guidelines: Authentication and Lifecycle Management SP800-90A - Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation SP800-90C - Recommendation for Random Bit Generator (RBG) Constructions

Modified p. 1

Payment Card Industry (PCI) Software Security Framework Secure Software ~~Requirements and Assessment Procedures Version 1.2.1~~

Payment Card Industry (PCI) Software Security Framework Secure Software Standard Version: 2.0

Removed p. 6

The PCI Secure Software Standard is intended for use as part of the PCI Software Security Framework (SSF). Entities wishing to have their payment software validated under the PCI SSF would do so to this standard.

Terminology A list of applicable terms and definitions is provided in the PCI Software Security Framework Glossary of Terms, Abbreviations, and Acronyms, available in the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library/.

Modified p. 6 → 5

Additionally, definitions for general PCI terminology is provided in the PCI Glossary on the PCI SSC website at: https://www.pcisecuritystandards.org/pci_security/glossary/.

Additionally, definitions for general PCI terminology are provided in the PCI Glossary on the PCI SSC website at: https://www.pcisecuritystandards.org/pci_security/glossary/.

Removed p. 7

Document Name Description

PCI Software Security Framework

• Technical FAQs for Secure Software Standard (“Secure Software Technical FAQs”) Technical Frequently Asked Questions (FAQs) provide a mechanism to address questions related to the interpretation and application of the associated PCI Standard and Program. Technical FAQs are considered ‘normative,’ and they must be fully considered within the scope of assessment activity for the associated Standard.

PCI Software Security Framework

• PCI Secure Software Lifecycle Standard (“Secure SLC Standard”) Additional security requirements for software development organizations to ensure they develop and maintain software securely throughout the entire software lifecycle.

PCI Software Security Framework

• Glossary of Terms, Abbreviations, and Acronyms (“SSF Glossary”) Describes important terms, abbreviations, and acronyms used throughout the Secure Software Standard and supporting documentation.

PCI Software Security Framework

• Secure Software Program Guide (“Secure Software Program Guide”) Describes the program requirements for entities to validate their payment software for compliance to the Secure Software Standard and have their …

Removed p. 8

Stakeholder Roles and Responsibilities There are numerous stakeholders involved in maintaining and managing PCI standards. The following describes the high-level roles and responsibilities of these stakeholders as they relate to the PCI Software Security Framework:

PCI SSC

• Responsible for maintaining the standards, supporting programs, and related documentation associated with the PCI Software Security Framework including, but not limited to:

• Maintaining the PCI Secure Software Standard (this document).

• Maintaining all supporting documentation including reporting templates, attestation forms, frequently asked questions (FAQs), and guidance to assist entities implementing and assessing to this standard.

• Providing instructions and guidance for SSF Assessors in accordance with the requirements and assessment procedures in this standard.

• Maintaining a list of all SSF Assessors qualified to perform assessments to this standard (on the PCI SSC Website).

• Maintaining a quality assurance program for SSF Assessors.

Participating Payment Brands

• Responsible for developing and enforcing their respective compliance programs related to PCI standards …

Removed p. 10

Scope of Security Requirements The security requirements defined in this standard describe the security characteristics, controls, features, and capabilities that payment software must possess to protect the integrity of payment functions and the confidentiality of sensitive payment data. The payment software features that are in scope for these requirements include, but are not limited to:

• All end-to-end payment software functionality, including:

− All payment functions.

− Inputs and outputs.

− Handling of error conditions.

− Interfaces and connections to other files, systems, and/or software.

− Security mechanisms, controls, and countermeasures, such as authentication, authorization, validation, parameterization, segmentation, logging, and so on.

• Processes used by the software vendor, provider, or developer to identify and support software security controls.

• Guidance that the software vendor, provider, or developer is expected to provide to stakeholders that describes:

− How to implement and operate the payment software securely.

− All configuration options available that can impact the security of payment software, including …

Modified p. 11 → 6

~~The requirements~~ in ~~this standard are organized into~~ the following ~~four requirement modules:~~

Requirement Structure This standard is structured in the following format:

Modified p. 11 → 6

• Account Data ~~Protection Requirements (“Account Data Protection Module”):~~ Additional security requirements for ~~payment~~ software that ~~store, process, or transmit~~ account data.

§ Module A

• Account Data Protection: Additional security objectives and security requirements for software that stores, processes, and/or transmits account data.

Removed p. 12

Objective-Based Approach to Requirements The PCI Software Security Framework has adopted an “objective-based” approach to defining the security requirements in this standard. The PCI SSC acknowledges that there is no “one size fits all” approach to software security and that software vendors need flexibility to determine the software security controls and features most appropriate to address their specific business needs and risks.

An “objective-based” approach is one that states security requirements as a desired security goal or outcome without necessarily specifying the method(s) to be used to achieve the desired goal. This approach enables entities to implement software security controls based on the risks identified by the software vendor for a given software application. For this approach to be successful, software vendors must possess a robust risk-management practice as an integral part of their software development lifecycle (SDLC) and be able to demonstrate how the implemented security controls are supported by …

Removed p. 13

• The expected assessment activities to be performed by an assessor to determine whether a specific control objective has been met. Test requirements are intended to provide both the software vendor and assessor with a common understanding of the tasks expected to be carried out by the assessor during testing. The specific method(s) used, the item(s) examined, and the personnel interviewed must be appropriate for the control objective being validated and for the software being assessed.

Testing Methods To support the validation of their software to the requirements in this standard, software vendors are expected to produce evidence that they have satisfied the stated control objectives. The test requirements identified for each control objective describe the activities to be performed by the assessor to confirm that the software and/or software vendor have met the control objective(s). Test requirements include the following testing activities:

• Test: The assessor evaluates the software operation to …

Modified p. 13 → 7

• Additional information to help ~~payment~~ software vendors and assessors understand the intent of each ~~control objective.~~ The guidance may also include best practices that should be considered and examples of controls or methods that may be used to satisfy the ~~control~~ objective. 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 objective~~ to which it refers.

§ Guidance

• Additional information to help software vendors and assessors understand the intent of each security objective and the security requirements. The guidance may also include best practices that should be considered and examples of controls or methods that may be used to satisfy the security objective. Guidance is not intended to preclude other methods that a software vendor may use to meet a security requirement, nor does it replace or amend the security requirements to which it refers.

Modified p. 13 → 7

• Examine: The assessor critically evaluates ~~data~~ evidence. Common examples ~~include~~ software design and architecture documents (electronic or physical), source code, configuration and metadata files, bug tracking ~~data and other output from software development systems,~~ and security-testing results. The choice of evidence that may be used to meet an “examination” requirement is deliberately left open for the ~~tester~~ to determine. ~~However, it is a requirement of this standard that the software source code be made available for review as part …~~

§ Examine: The assessor critically evaluates evidence. Common examples include, but are not limited to, software design and architecture documents (electronic or physical), source code, configuration and metadata files, bug tracking data, log files, and security-testing results. The choice of evidence that may be used to meet an “examination” requirement is deliberately left open for the assessor to determine.

Modified p. 13 → 7

• Interview: The assessor converses with individual personnel. The ~~purposes~~ of interviews ~~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.~~

§ Interview: The assessor converses with individual personnel. The purpose of interviews includes determining how an activity is performed, whether an activity is performed as defined, and whether

Removed p. 14

Reliance on Third-Party Testing All test requirements are expected to be performed by the assessor. An assessor may choose, however, to rely on testing performed by a third- party to satisfy a test requirement, including the software provider. The assessor retains full responsibility for the testing activities and results, regardless of whether the testing is performed by the assessor, by the software provider, or by a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify the following:

• 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 that the third-party testing relied upon by the assessor is appropriate.

Where an assessed entity’s testing is to be used for the purposes of satisfying test requirements, the assessor must first verify the software vendor is Secure SLC-qualified1 before software vendor testing can …

Removed p. 16

Control Objectives Test Requirements Guidance Control Objective 1: Critical Asset Identification All software critical assets are identified and classified.

1.1.a The assessor shall examine evidence to confirm that information is maintained that details all sensitive data that is stored, processed, and/or transmitted by the software. At a minimum, this shall include all payment data; authentication credentials; cryptographic keys and related data (such as IVs and seed data for random number generators); and system configuration data (such as registry entries, platform environment variables, prompts for plaintext data in software allowing for the entry of PIN data, or configuration scripts).

Software security controls are designed and implemented to protect the confidentiality and/or integrity of critical assets. To make sure these controls are effective and appropriate, the software vendor should identify all sensitive data the software collects, stores, processes, or transmits, as well as all sensitive functions and resources it either provides or uses.

1.1.b The …

Removed p. 17

1.1.f The assessor shall examine evidence and test the software to identify the cryptographic implementations that are supported by the software (including cryptography used for storage, transport, and authentication), and to confirm that the cryptographic data for all of these implementations is supported by the evidence examined in Test Requirements 1.1.a through 1.1.c, and that the evidence describes whether these are implemented by the software itself, through third-party software, or as functions of the execution environment.

1.1.g The assessor shall examine evidence and test the software to identify the accounts and authentication credentials supported by the software (including both default and user- created accounts) and to confirm that these accounts and credentials are supported by the evidence examined in Test Requirements 1.1.a through 1.1.c.

1.1.h The assessor shall examine evidence and test the software to identify the configuration options provided by the software that can impact sensitive data (including those provided through …

Removed p. 18

1.2.c Where the sensitive functions or sensitive resources are provided by third-party software or systems, the assessor shall examine evidence and test the software to confirm that the software correctly follows available guidance for the third-party software.

Note: For example, by reviewing the security policy of a PTS or FIPS140-2 or 140-3 approved cryptographic system.

Removed p. 18

• The software vendor defines criteria for classifying critical assets in accordance with the confidentiality, integrity, and resiliency requirements for each critical asset.

• An inventory of all critical assets with appropriate classifications is maintained.

Critical assets represent the sensitive data, functions, and resources that have business value and require confidentiality, integrity, or resiliency protection.

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.

Removed p. 19

2.1.a The assessor shall examine evidence and test the software to identify any software APIs or other interfaces that are provided or exposed by default upon installation, initialization, or first use. For each of these interfaces, the assessor shall confirm that the vendor has documented and justified its use as part of the software architecture. Testing shall include methods to reveal any exposed interfaces or other software functionality (such as scanning for listening services where applicable).

Note: This includes functions that are auto-enabled as required during operation of the software.

Software often contains functionality (for example, web services, administrative interface, application heartbeat, etc.) that is optional and is generally unused by many users. This functionality typically does not receive the same attention as standard or essential software functions and services, and often contains security weaknesses that can be exploited by malicious users to bypass security controls.

To ensure a secure software deployment, the …

Removed p. 20

2.1.e Where known vulnerabilities in exposed interfaces exist, the assessor shall examine evidence and test the software to confirm the following:

• Methods are implemented to mitigate the exploitation of these weaknesses.

• The risks posed by the use of known vulnerable protocols, functions, or ports are documented.

• Clear and sufficient guidance on how to correctly implement sufficient security to meet applicable control objectives in this standard is provided to stakeholders in accordance with Control Objective 12.1.

Note: The assessor should reference the vendor threat information defined in Control Objective 4.1 for this item.

2.1.f The assessor shall examine evidence to identify any third- party modules used by the software and to confirm that any such functions exposed by each module are disabled, unable to be accessed through mitigation methods implemented by the software, or formally documented and justified by the software vendor.

Where access to third-party functions is prevented through implemented protection methods, the …

Removed p. 21

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.

2.2.a The assessor shall examine evidence and test the software to identify all software security controls, features and functions relied upon by the software for the protection of critical assets and to confirm that all are enabled upon installation, initialization, or first use of the software.

As previously noted earlier in guidance, software security controls are designed and implemented to protect the confidentiality and integrity of critical assets. Examples of such software security controls include authentication and authorization mechanisms, cryptographic controls, and controls to prevent leakage of sensitive data.

Default software settings should result in a secure software configuration and should not rely on the end-user being a subject-matter expert to ensure a secure configuration. To that effect, all available software security controls should be …

Removed p. 21

2.3.a The assessor shall examine evidence to identify the default credentials, keys, certificates, and other critical assets used for authentication by the software.

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.

To protect against unauthorized access, payment software should prevent the use of built-in accounts until the default authentication credentials can be changed.

Removed p. 22

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.

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.

2.3.c Where user input or interaction is required to disable or change any authentication credentials or keys for built-in accounts, the assessor shall examine evidence to confirm that guidance on …

Removed p. 23

2.4.a The assessor shall examine evidence to identify the privileges and resources required by the software and to confirm that information is maintained that describes and reasonably justifies all privileges and resources required, including explicit permissions for access to resources, such as cameras, contacts, etc.

In many attacks on software or underlying systems, the software is often used to execute functions on the underlying operating systems or to abuse accessible external resources. When the software requires excessive permissions, such permissions may be exploited by a malicious user.

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 …

Removed p. 24

2.5.a The assessor shall examine the evidence to identify all default accounts provided by the software and to confirm that the privileges assigned to these accounts are justified and reasonable.

In support of the principle of “least privilege,” built-in accounts should only have the privileges required for the intended function of the account, including access to sensitive data and resources as well as the ability to execute sensitive functions. For example, a built-in administrator account may require the ability to configure the software and associated user accounts, but not the ability to access areas containing sensitive data.

Applying the principle of least privilege to user accounts helps prevent users without sufficient knowledge about the software from incorrectly or accidentally changing the software configuration or its security settings. Enforcing least privilege also helps to minimize the effects of unauthorized access to software user accounts.

To limit access to sensitive data, functions, and resources to …

Removed p. 25

3.1.a The assessor shall examine evidence to identify the sensitive data that is collected by the software for use beyond any one transaction, the default time period for which it is retained, and whether the retention period is user-configurable, and to confirm that the purpose for retaining the sensitive data in this manner is justified and reasonable.

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.

To prevent the unauthorized disclosure of sensitive data to unauthorized parties, the software should retain sensitive data only for the duration necessary to perform the specific operation for which sensitive data is collected. Retaining sensitive data longer than required presents opportunity for the data to be mishandled, misused, or accidentally disclosed.

This control objective differentiates between transient sensitive data retained temporarily and persistent sensitive data that is retained on a more permanent …

Removed p. 26

3.2.a Using information obtained in Test Requirement 1.1.a, the assessor shall examine evidence to identify all sensitive data that is retained by the software for transient use, what triggers the secure deletion of this data, and to confirm that the purposes for retaining the data are justified and reasonable. This includes data that is stored only in memory during the operation of the software.

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, or user within the environment may not access or capture the sensitive data.

Software vendors should also be aware of and account for how other aspects of the software architecture (such as the software-development language …

Removed p. 27

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.3.a The assessor shall examine the evidence to identify the methods implemented to protect sensitive data during storage.

The software should maintain security controls and mechanisms to protect all sensitive data while it is retained by the software. Examples of software security controls include writing to a secure memory location or using cryptography to render the data unreadable.

3.3.b Where sensitive data is stored outside of temporary variables within the code itself, the assessor shall test the software to confirm that sensitive data is protected using either strong cryptography or other methods that provide an equivalent level of security.

3.3.c Where protection methods use cryptography, the …

Removed p. 28

3.4.a The assessor shall examine evidence to identify the methods implemented to render persistent sensitive data irretrievable and to confirm that sensitive data is rendered unrecoverable after the process is complete.

Secure deletion is the process of rendering data irretrievable to other people, processes, or systems.

Secure deletion may be required at the end of a software-specific operation or upon completion of user-specified retention requirements. In the latter case, the software should be able to securely delete the sensitive data after expiry of the user-specified retention period.

Only in circumstances where the retention of sensitive data is explicitly permitted should the data be retained after transaction processing is complete.

3.4.b The assessor shall examine evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the …

Removed p. 29

3.5.a The assessor shall examine evidence to identify the methods implemented to render transient sensitive data irretrievable and to confirm that sensitive data is unrecoverable after the process is complete.

Note: This includes data which may be stored only temporarily in program memory / variables during operation of the software.

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 locations where sensitive data is stored, regardless of the intended duration of storage, and ensure that such data is securely deleted once the purpose …

Removed p. 30

3.6.a The assessor shall examine evidence to confirm the software vendor has performed a thorough analysis to account for all sensitive data disclosure attack vectors including, but not limited to:

• Error messages, error logs, or memory dumps.

• Execution environments that may be vulnerable to remote side-channel attacks to expose sensitive data, such as attacks that exploit cache timing or branch prediction within the platform processor.

• 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.

• Sensors or services provided by the execution environment that may be used to extract or leak sensitive data, such as through use of an accelerometer to capture input of a passphrase to be used as a seed for a cryptographic key, or through capture of sensitive data through use of cameras or near-field communication (NFC) interfaces.

Proactive measures to ensure …

Removed p. 32

Control Objectives Test Requirements Guidance Control Objective 4: Critical Asset Protection Critical assets are protected from attack scenarios.

Removed p. 32

Note: This control objective is an extension of Control Objective 10.1. Validation of both control objectives should be performed at the same time.

4.1.a The assessor shall examine evidence to confirm that the software vendor has identified and documented relevant attack scenarios for the software.

Software vendors should evaluate the design of their payment software to identify attack scenarios applicable to the software and should document the results of that analysis. Documentation should describe the various aspects of the code that could be attacked (including tasks or actions that frameworks and libraries do on the software’s behalf), the difficulty in mounting a successful attack, the mitigation techniques used to protect against such attacks, and the methodology used for measuring the likelihood and impact of each potential attack method.

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 …

Removed p. 33

• 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.

• A methodology is defined for measuring the likelihood and impact for any exploit of the system.

• Generic threat methods and types that may be applicable to the software are documented.

• All entry and egress points for sensitive data, as well as the authentication and trust model applied to each of these entry/egress points, are documented.

• All data flows, network segments, and authentication/privilege boundaries are documented.

• All static IPs, domains, URLs, or ports required by the software for operation are documented.

• Considerations for cryptography elements like cipher modes, and protecting against relevant attacks such as timing attacks, padded oracles, brute force, “rainbow table” attacks, and dictionary attacks against the input domain are documented.

• …

Modified p. 33 → 22

~~• All critical assets managed,~~ and all sensitive resources ~~used by the system~~ are documented.

2-2.1 The description and use of all sensitive resources are documented.

Removed p. 34

4.2.a The assessor shall examine evidence to confirm that one or more mitigation methods are defined for each of the threats identified in Test Requirement 4.1.a or that justification for the lack of mitigations is provided.

Once attack scenarios are identified, the risk of their occurrence should be mitigated. Software vendors should define and implement mechanisms to protect the software from attacks and reduce the likelihood and impact of successful execution. Any attack scenarios left unmitigated or insufficiently mitigated should be reasonably justified.

The exact nature of the protection mechanism(s) will depend on the attack scenarios, the development platform, and the software-development languages, frameworks, libraries, and APIs used by the software, as well as the execution environment where the software is intended to be deployed.

To minimize the software attack surface, the software should be developed using secure design principles such as layered defense, application segmentation and isolation (logical), and adaptive response.

Examples of …

Removed p. 35

5.1.a The assessor shall examine evidence to confirm that authentication requirements are defined (i.e., type and number of factors) for all roles based on critical asset classification, the type of access (e.g., local, non-console, remote) and level of privilege.

Note: The assessor should refer to evidence obtained in the testing of Control Objective 1.3 to determine the classifications for all critical assets.

Secure authentication ensures individual responsibility for actions and allows the software to maintain an effective audit trail of user activity. This expedites issue resolution and containment when the software is misused for malicious purposes.

Authentication mechanisms should cover all non- public resources managed by or accessible through the software, as well as sensitive functions that can alter the software operation or impact the security of sensitive data and sensitive resources. Examples of authentication methods include:

• Something you know, such as a password or passphrase.

• Something you have, such as a token …

Removed p. 36

Other factors such as the type of access (for example, local, non-console, or remote access) and the level of privilege (for example, the ability to invoke sensitive functions such as pause logging or change access privileges) may influence the level of authentication that should be required.

Removed p. 36

5.2.a The assessor shall examine evidence and test the software to confirm that all implemented authentication methods require unique identification.

The software should not require the use of any group, shared, or generic accounts. The use of group or shared accounts makes it more difficult to determine which individuals execute specific actions since a given action could have been performed by anyone that has knowledge of the group or shared accounts’ authentication credentials.

5.2.b Where interfaces, such as APIs, allow for automated access to critical assets, the assessor shall examine 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 provided to stakeholders in accordance with Control Objective 12.1.

5.2.c Where identification is supplied across a non-console interface, the assessor …

Removed p. 37

5.3.a Using information obtained in Test Requirement 4.1.a, the assessor shall examine evidence to confirm that authentication methods implemented by the software are evaluated to identify known vulnerabilities or attack methods involving the authentication method and how the implementation of these methods mitigates against such attacks. The assessor shall also confirm that the evidence examined demonstrates the implementation used in the software was considered. For example, a fingerprint may be uniquely identifiable to an individual, but the ability to spoof or otherwise bypass such technology can be highly dependent on the way the solution is implemented.

The software vendor must evaluate, document, and justify the usage of implemented authentication methods to demonstrate that they are sufficiently strong to protect authentication credentials in the software’s intended specific use case or deployment scenario.

For example, if the software uses biometric authentication, the vendor may want to identify all points at which a malicious user …

Removed p. 38

5.4.a The assessor shall examine evidence to confirm that information is maintained that identifies and justifies the required access for all critical assets.

To ensure the software protects the confidentiality and integrity of critical assets, access privileges to those critical assets should be restricted based on vendor- defined access requirements. There are various approaches to implementing privilege restriction, such as trust-based privilege management, attribute-based usage restriction, and dynamic privileges. To reduce the attack surface of the software, the software authorization mechanisms might limit access to critical assets to only those accounts that need such access (the principle of “least privilege”). Other techniques include implementation of Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), time-based adjustment to privilege, and dynamic revocation of access authorization.

5.4.b The assessor shall examine evidence and test the software to identify the level of access that is provided to critical assets and to confirm that such access correlates …

Removed p. 39

6.1.a The assessor shall examine evidence to confirm that protection requirements for all sensitive data are defined, including requirements for rendering sensitive data with confidentiality considerations unreadable anywhere it is stored persistently.

Sensitive data must be protected wherever it is stored. In some cases, the integrity may be the primary concern. In other cases, it may be the confidentiality of the sensitive data that must be protected. Sometimes, both the integrity and confidentiality must be secured. The type of data and the purpose for which it is generated will often determine the need for integrity or confidentiality protection. In all cases, those protection requirements must be clearly defined.

In cases where the confidentiality of sensitive data is a concern, it is imperative to know where and for how long the data is retained. The vendor must have details of all locations where the software may store sensitive data, including in any underlying …

Removed p. 40

Where the integrity of sensitive data is a concern, strong cryptography with appropriate key-management practices is one method that could be used to satisfy integrity protection requirements during storage.

6.1.f Where protection methods rely on the security properties of third-party software, the assessor shall examine evidence and test the software to confirm that there are no unmitigated vulnerabilities or issues with the software providing the security properties.

Removed p. 40

6.2.a The assessor shall examine evidence to identify the locations within the software where sensitive data is transmitted outside of the physical execution environment and to confirm protection requirements for the transmission of all sensitive data are defined.

To prevent malicious individuals from intercepting or diverting sensitive data while in transit, it must be protected during transmission.

One method to protect sensitive data in transit is to encrypt it using strong cryptography prior to transmission.

Alternatively, the software could establish an authenticated and encrypted channel using only trusted keys and certificates (for authentication) and appropriate encryption strength for the selected protocols.

6.2.b The assessor shall examine evidence and test the software to confirm that for each of the ingress and egress methods that allow for transmission of sensitive data outside of the physical execution environment, the data is encrypted with strong cryptography prior to transmission or is transmitted over an encrypted channel using strong …

Removed p. 41

6.2.e Where the methods implemented for encrypting sensitive data allow for the use of different types of cryptography or different levels of security, the assessor shall examine evidence and test the software, including capturing software transmissions, to confirm the software enforces the use of strong cryptography at all times during transmission.

Removed p. 41

6.3.a Where cryptography is relied upon (in whole or in part) for the security of critical assets, the assessor shall examine evidence and test the software to confirm that the use of cryptography is compliant to Control Objective 7.

Note: The assessor should refer to Control Objective 7 to identify all requirements for appropriate and correct implementation of cryptography.

Wherever cryptography is used to meet software security requirements in this standard, it must be done in accordance with the specific security requirements related to the use of cryptography (including those in Control Objective 7).

For example, storing a cryptographic key used for protecting sensitive data in a plaintext file would not be considered sufficient security unless additional controls are implemented to prevent the file containing the cryptographic key from being accessed or modified by, or exposed to unauthorized parties.

Further guidance on appropriate uses of cryptographic algorithms can be found in current versions of …

Removed p. 42

7.1.a The assessor shall examine evidence to determine how cryptography is used for the protection of critical assets and to confirm that:

• Industry-standard cryptographic algorithms and modes of operation are used.

• The use of any other algorithms is in conjunction with industry-standard algorithms.

• The implementation of non-standard algorithms does not reduce the equivalent cryptographic key strength provided by the industry-standard algorithms.

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 level of testing that industry-accepted implementations have undergone. Only those implementations that have been subjected to sufficient testing (for example, by NIST, ANSI, or other recognized industry …

Removed p. 43

7.1.e Where hash functions are used to protect sensitive data, the assessor shall examine evidence and test the software to confirm that:

• Only approved, collision-resistant hash algorithms and methods are used for this purpose, and

• A salt value of appropriate strength that is generated using a secure random number generator is used to ensure the resultant hash has sufficient entropy.

Note: The assessor should refer to Control Objective 7.3 for more information on secure random number generators.

Removed p. 43

7.2.a The assessor shall examine evidence to confirm that information is maintained that describes the following for each key specified in the inventory:

• Key generation method/algorithm used

• Key length Whether implemented within or outside the software, the manner in which cryptographic keys are managed is a critical part of the continued security of payment software and the sensitive data it handles.

While cryptographic key management processes are often implemented as operational procedures, the software should support secure key-management practices based on industry standards or best practices.

Removed p. 44

• All cryptographic keys that are used for providing security to critical assets (confidentiality, integrity, and authenticity) and other security services to the software have a unique purpose, and that no key is used for both encryption and authentication operations.

• All keys have defined generation methods, and no secret or private cryptographic keys relied upon for security of critical assets are shared between software instances, except when a common secret or private key is used for securing the storage of other cryptographic keys that are generated during the installation, initialization, or first use of the software (for example, white-box cryptography).

• All cryptographic keys have an equivalent bit strength of at least 128 bits in accordance with industry standards.

• All keys have a defined cryptoperiod aligned with industry standards, and methods are implemented to retire and/or update each key at the end of the defined cryptoperiod.

• The integrity and confidentiality of …

Modified p. 44 → 62

~~• Secure cryptographic key storage.~~

2) Strong cryptography is still required.

Modified p. 44 → 91

~~• The generation of strong cryptographic keys.~~

See Strong Cryptography.

Removed p. 45

7.2.d Where public keys are used by the system, the assessor shall examine evidence and test the software to confirm that the authenticity of all public keys is preserved.

7.2.e Where public or white-box keys are not unique per software instantiation the assessor shall examine evidence to confirm that methods and procedures to revoke and/or replace such keys (or key pairs) exist.

7.2.f Where the software relies upon external files or other data elements for key material, such as for public TLS certificates, the assessor shall examine evidence to confirm that guidance on how to install such key material, including details noting any security requirements for such key material is provided to stakeholders in accordance with Control Objective 12.1.

7.2.g Where public keys are manually loaded or used as root keys, the assessor shall examine evidence and test the software to confirm that the keys are installed and stored in a way that …

Removed p. 46

7.3.a The assessor shall examine evidence and test the software to identify all random number generators used by the software and to confirm that all random number generation methods:

• Use at least 128 bits of entropy prior to the output of any random numbers.

• Ensure it is not possible for the system to provide or produce reduced entropy upon start-up or entry of other predictable states of the system.

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.

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.

The implementation may rely …

Removed p. 47

Note: The assessor can use the NIST Statistical Test Suite to identify statistical correlation in the random number generation implementation.

Removed p. 47

7.4.a The assessor shall examine evidence and test the software to confirm that the methods used for the generation of all cryptographic keys and other material (such as IVs, “k” values for digital signatures, and so on) have entropy that meets the minimum effective strength requirements of the cryptographic primitives and keys.

Entropy is the degree of randomness of a random value generator. The higher the entropy, the less predictable the next value in a random number generator is likely to be.

Removed p. 48

• Methods used for generating keys directly from a password/passphrase enforce an input domain that is able to provide sufficient entropy, such that the total possible inputs are at least equal to that of the equivalent bit strength of the key being generated (for example, a 32- hex-digit input field for an AES128 key).

• Passphrases are passed through an industry-standard key- derivation function, such as PBKDF2 or bcrypt, which extends the work factor for any attempt to brute-force a passphrase value. The assessor shall confirm that a work factor of at least 10,000 is applied to any such implementation.

• Guidance is provided to stakeholders in accordance with Control Objective 12.1 that includes instructions that any passphrase used must:

• Be randomly generated itself using a valid and secure random process, and that an online random number generator must not be used for this purpose.

• Not be implemented by a single person, …

Removed p. 49

Control Objectives Test Requirements Guidance Control Objective 8: Activity Tracking All software activities involving critical assets are tracked.

Removed p. 49

Note: This Secure Software Standard recognizes that some execution environments cannot support the detailed logging requirements in other PCI standards. Therefore, the term “activity tracking” is used here to differentiate the expectations of this standard with regards to logging from similar requirements in other PCI standards.

Removed p. 49

To ensure user accountability and to support post- incident forensic investigation, payment software should capture and maintain historical records of all software activities involving critical assets and ensure that all such activities are traceable to a unique user (for example, a person, system, or other entity).

Examples of activities that the software should record include:

• Usage of or changes to sensitive functions, such as the software’s identification and authentication mechanisms or activity tracking mechanisms.

• 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.

Modified p. 49 → 52

~~• All individual user attempts~~ to access sensitive ~~data or~~ resources.

- Attempting to find unexpected ways to gain access to sensitive resources.

Removed p. 50

8.2.a The assessor shall examine evidence and test the software to confirm that the tracking method(s) implemented capture specific activity performed, including:

• Enablement of any privileged modes of operation.

• Exporting of sensitive data to other systems or processes.

• Failed authentication attempts.

• Disabling or deleting a security control or altering security functions.

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.

8.2.b The assessor shall examine evidence and test the software to confirm that the tracking method(s) implemented provide the following:

• A unique identification for the individual, system, or entity accessing or using critical assets.

• A timestamp for each tracked event.

• Details on what …

Modified p. 50 → 17

~~• Decryption~~ of sensitive ~~data.~~

2-1.1 The description and use of all sensitive data are documented.

Modified p. 50 → 52

~~• Disabling of encryption of~~ sensitive data.

- Attempting to find unexpected ways to gain access to sensitive data.

Removed p. 51

Without adequate protection of activity records, their completeness, accuracy, and integrity cannot be guaranteed and any reliance that would otherwise be placed on them (such as during a forensic investigation) would be negated.

When activity records are managed by the software, the records must be protected in accordance with all applicable requirements for the protection of sensitive data. 8.3.c The assessor shall test the software to confirm methods are implemented to secure the authenticity of the tracking data during transmission to the log storage system, and to confirm that this protection meets the requirements of this standard (for example, authenticity parameters must be applied using strong cryptography) and any account or authentication parameters used for access to an external logging system are protected.

Removed p. 51

8.4.a The assessor shall examine evidence and test the software to confirm that the failure of the activity-tracking mechanism(s) does not violate the integrity of existing records by confirming that:

• 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.

• 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.

(continued on next page) Software security controls should be implemented to ensure that when activity-tracking mechanism(s) fail, those failures are handled in a way that maintains the integrity of the records. Otherwise, attackers may intentionally target activity-tracking mechanisms and cause failures that would allow the attackers to conceal or overwrite evidence of their activities.

• The software applies, where …

Removed p. 53

9.1.a The assessor shall examine evidence and test the software to confirm that methods are implemented to validate the integrity of software executables and any configuration options, files, and datasets that the software relies upon for operation such that unauthorized post-deployment changes are detected.

Where the execution environment prevents this, the assessor shall examine evidence (including publicly available literature on the platform and associated technologies) to confirm that there are indeed no methods for validating authenticity, and that additional security controls are implemented to minimize the associated risk.

Software should possess basic functionality to differentiate between normal and anomalous user behavior. Examples of anomalous behavior that should be automatically detected by the software include changes in post-deployment (or post-initialization) configurations or obvious automated-attack behaviors, such as repeated authentication attempts at a frequency that is infeasible for a human user.

In some cases, it may be impractical to implement these capabilities directly into payment …

Removed p. 54

9.1.g Where third-party tools or services are relied upon by the software to provide attack detection capabilities, the assessor shall examine evidence to confirm that guidance on how to configure such tools and services to support this control objective is provided to stakeholders in accordance with Control Objective 12.1.

Removed p. 55

Control Objectives Test Requirements Guidance Control Objective 10: Threat and Vulnerability Management Payment software threats and vulnerabilities are identified, assessed, and managed appropriately.

Removed p. 55

10.1.a Using information obtained in Test Requirement 4.1.a, the assessor shall examine evidence to confirm that common attack methods against the software are identified. This may include platform-level, protocol-level, and/or language-level attacks.

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:

• The types of information collected, stored, processed, or transmitted by the software.

• The motivations an attacker may have for attacking the software.

• The methods an attacker might utilize or the vulnerabilities an attacker might try to exploit during an attack.

• The exploitability of any identified vulnerabilities.

• The impact a successful attack.

The identified threats and vulnerabilities should be tracked, assigned to responsible personnel, and fixed or mitigated prior to payment software release.

For guidance on threat analysis and cyber-resiliency design principles, refer to industry standards and guidance, such …

Removed p. 56

10.2.a The assessor shall examine evidence to confirm that robust testing processes are used throughout the software lifecycle to manage vulnerabilities in software and to verify that the mitigations used to secure the software against attacks remain in place and are effective.

Most software vulnerabilities are introduced as a result of coding errors, bad design, improper implementation, or the use of vulnerable components.

Software should be developed and tested in a manner that minimizes the existence of any vulnerabilities and detects those that emerge over time, such that the vulnerabilities may be addressed before the software is released or updated. Techniques to avoid the introduction of vulnerabilities during development include the use of security coding practices, testing code during each phase of the development lifecycle using automated tools (such as static/dynamic analysis tools and interactive security testing tools), and the use of known secure components (for example, common code that has already …

Removed p. 57

11.1.a The assessor shall examine evidence to confirm that:

• Reasonable criteria are defined for releasing software updates to fix security vulnerabilities.

• Security updates are made available to stakeholders in accordance with the defined criteria.

Vulnerabilities in software should be fixed as soon as possible to enable software users and other stakeholders to address any risks before vulnerabilities in their payment systems and software can be exploited by attackers.

Vulnerabilities should be addressed in a manner that is commensurate with the risk they pose to software users or other stakeholders. The most critical or severe vulnerabilities (those with the highest exploitability and the greatest potential impact to stakeholders) should be patched immediately, followed by those with moderate-to-low exploitability or potential impact. The criteria for determining how and when to make patches available to stakeholders should be defined and followed.

11.1.b The assessor shall examine evidence, including update- specific security-testing results and details, to confirm …

Removed p. 57

11.2.a The assessor shall examine evidence to confirm that the method(s) by which the vendor releases software updates maintain the integrity of the software code during transmission and installation.

Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include, but are not limited to, checksums and digitally signed certificates (where implemented correctly). Verification could be implemented within the software itself or through guidance that is provided to stakeholders to direct them on the manual verification of software updates.

In addition, the process of distributing updates and patches should prevent malicious individuals from intercepting the updates in transit, modifying them, and then redistributing them to unsuspecting stakeholders.

11.2.b Where user input or interaction is required to validate the integrity of the software code, the assessor shall examine evidence to confirm that guidance on this process is provided …

Removed p. 58

11.2.e The assessor shall examine evidence to confirm that stakeholders are notified when known vulnerabilities are detected in software that has not yet been updated with a fix. This includes vulnerabilities that may exist in third-party software and libraries used by the software. The assessor shall confirm that this process includes providing the stakeholders with suggested mitigations for any such vulnerabilities.

11.2.f The assessor shall examine evidence to confirm that the software update mechanisms cover all software, configuration files, and other metadata that may be used by the software for security purposes or which may in some way affect the security of the software.

Removed p. 59

12.1.a The assessor shall examine evidence to confirm that the vendor creates and provides stakeholders, clear and sufficient guidance to allow for the secure installation, configuration, and use of the software.

When followed, the software vendor's implementation guidance provides assurance that the software and patches can be securely installed, configured, and maintained in a customer environment, and that all desired security functions are active and working as intended. The guidance should cover all options and functions available to software users that could affect the security of the software or the data it interacts with. The guidance should also include secure configuration options for any components provided with or supported by the software, such as external software and underlying platforms.

Examples of configurable options include:

• Changing default credentials and passwords.

• Enabling and disabling software accounts, services, and features.

• Changes in resource access permissions.

• Integration with third-party cryptographic libraries, random number generators, and so …

Removed p. 60

• Provides justification for any requirements in this standard that are to be assessed as not applicable. For each of these, the assessor shall confirm justification exists for why this is the case and shall confirm that it agrees with their understanding and the results of their software testing.

Removed p. 61

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:

Account Data Cardholder Data includes: Sensitive Authentication Data includes:

• Primary Account Number (PAN)

• Full track data (magnetic-stripe data or equivalent on a chip)

• PINs/PIN blocks The primary account number (PAN) is the defining factor for cardholder data. If PAN is stored, processed, or transmitted or is otherwise present, the requirements in this module apply in addition to the Secure Software Core Requirements.

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 …

Removed p. 63

A.1.1 The software does not store sensitive authentication data after authorization (even if encrypted) unless the software is intended only for use by issuers or organizations that support issuing services.

A.1.1 Using information obtained in Test Requirement 1.1.a in the Core Requirements section, the assessor shall examine evidence and test the software to identify all potential storage locations for Sensitive Authentication Data, and to confirm that the software does not store such data after transaction authorization is complete. This includes storage of SAD in temporary storage (such as volatile memory), semi-permanent storage (such as RAM disks), and non-volatile storage (such as magnetic and flash storage media).

Where Sensitive Authentication Data is stored after authorization, the assessor shall examine evidence to confirm that the software is designed explicitly for issuing purposes or for use by issuers or organizations that support issuing services.

Sensitive authentication data consists of full track data, card validation code or …

Removed p. 64

A.2.1 The software vendor provides guidance to stakeholders regarding secure deletion of cardholder data after expiration of defined retention period(s).

A.2.1 The assessor shall examine evidence to confirm that guidance is provided to stakeholders in accordance with Control Objective 12.1 that details:

• All locations where the software stores cardholder data.

• How to securely delete cardholder data stored by the payment software, including cardholder data stored on underlying software or systems (such as in OS files or in databases).

• How to configure the underlying software or systems to prevent the inadvertent capture or retention of cardholder data (for example, by system backup or restore points).

The software vendor must provide details of all locations where the software may store cardholder data, including in any underlying software or systems (such as OS, databases, and so on), as well as instructions for securely deleting the data from these locations once the data has exceeded any …

Removed p. 65

A.2.2.d The assessor shall test the software to confirm that all displays of PAN are completely masked by default, and that explicit authorization is required to display any element of the PAN.

A.2.3 PAN is rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:

• Truncation (hashing cannot be used to replace the truncated segment of PAN).

• Index tokens and pads (pads must be securely stored).

• Strong cryptography with associated key-management processes and procedures.

A.2.3.a The assessor shall examine evidence and test the software to confirm that methods are implemented to render PAN unreadable anywhere it is stored using the following methods:

• Index tokens and pads, with the pads being securely stored.

• Strong cryptography, with associated key-management processes and procedures.

Note: The assessor should examine several tables, files, log files, and any other resources created or generated by the …

Removed p. 67

B.1: Terminal Software Documentation B.2: Terminal Software Design B.3: Terminal Software Attack Mitigation B.4: Terminal Software Security Testing B.5: Terminal Software Implementation Guidance Purpose and Scope This section (hereinafter referred to as the “Terminal Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that rely on the security features of PCI-approved POI devices to protect payment data. Software applications that are developed explicitly for deployment and execution on PCI-approved POI devices that do 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”) are in scope for the requirements in this module.

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 …

Removed p. 69

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 evidence to confirm that documentation is maintained that describes 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, components, and functions interact.

B.1.2 The software vendor maintains documentation that describes all data flows and functions that involve sensitive data.

Note: This control objective is an extension of Control Objectives 1.1 and 1.2. Validation of these control objectives …

Removed p. 70

• 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 evidence to confirm that documentation is maintained that describes all configurable options provided or made available by the software that can impact the security of sensitive data including, but not limited to, the following:

• 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 by the software.

• The default settings …

Removed p. 71

B.2.1 The software is intended for deployment and operation on payment terminals (PCI-approved POI devices).

B.2.1 The assessor shall examine evidence to determine the payment terminals upon which the software is to be deployed. For each of the payment terminals identified and included in the software assessment, the assessor shall examine the payment terminal’s device characteristics and compare them with the following characteristics specified in the PCI SSC’s List of Approved PTS Devices to confirm they match:

• 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 own equivalent features or functions, to avoid exposing vulnerabilities or other weaknesses …

Removed p. 72

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 evidence (including source code) to confirm that the software does not circumvent, bypass, or add additional services or protocols …

Removed p. 73

B.2.3.c The assessor shall examine evidence (including source code) to confirm that the software does not bypass or render ineffective any encryption methods provided by the payment terminal in accordance with the payment terminal vendor’s security guidance/policy.

B.2.3.d Where the software provides encryption of sensitive data, but the payment terminal is not required to provide approved encryption methods (per the PCI PTS POI Standard), the assessor shall examine evidence (including source code) to confirm that the encryption methods used or implemented by the software for encrypting sensitive data provide “strong cryptography” and are implemented in accordance with Control Objectives 7.1 and 7.2.

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 function(s).

B.2.4.a The assessor shall examine evidence (including source …

Modified p. 73 → 76

The unpredictability of random numbers is ~~of critical importance~~ to ensure the effectiveness of cryptographic operations. It is not a trivial endeavor to design and implement a secure ~~random number~~ generator. For this reason, the ~~terminal~~ software should only use the ~~random~~ number generation function(s) implemented by the ~~payment terminal~~ for all cryptographic operations involving sensitive ~~data or sensitive functions~~ where random values are required.

The unpredictability of random numbers is critically important to ensure the effectiveness of cryptographic operations. It is not a trivial endeavor to design and implement a secure random-number generator. For this reason, the software should only use the random- number generation function(s) implemented by the PTS POI device for all cryptographic operations involving sensitive assets, where random values are required.

Removed p. 74

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 evidence (including source code) 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 account data is maintained during information exchange with the payment terminal’s firmware. Software that provides its own mechanisms for sharing clear-text account data directly …

Modified p. 74 → 75

~~B.2.5~~ The software ~~does not provide, through its own logical interface(s), the sharing of clear-text~~ account data directly with ~~other software.~~

The software being assessed to this standard can share cleartext account data directly with the POI device’s approved firmware.

Removed p. 75

B.2.6.a The assessor shall examine evidence (including source code) to determine whether and how the software connects to and/or uses any shared resources provided by the payment terminal, and to confirm that:

• The guidance required in Control Objectives 12.1 and B.5.1 includes detailed instructions for how to configure the software to ensure secure integration with shared resources.

• The required guidance for secure integration with 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 guidance required in Control Objectives 12.1 and B.5.1. Using …

Removed p. 76

B.2.7.a The assessor shall examine all relevant payment terminal documentation (including the payment terminal vendor’s security guidance/policy) to determine whether and how application segregation is enforced by the payment terminal.

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 …

Removed p. 77

B.2.8.d The assessor shall examine evidence (including source code) to determine whether and how the software supports EMV® payment transactions. Where EMV payment transactions are supported by the software, the assessor shall install and configure the software in accordance with the guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall confirm that all EMV Certification Authority Public Keys are cryptographically signed in a manner that enables the 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 evidence (including source code) to determine whether the software supports the use of …

Removed p. 78

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 guidance required in Control Objectives 12.1 and B.5.1. Using an appropriate “test platform” and suitable forensic tools and/or methods, the assessor shall confirm that all prompt files are cryptographically signed in a manner that enables the cryptographic authentication of those files by the payment terminal in accordance with B.2.8.

Removed p. 79

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 evidence (including source code) to identify all locations where the software accepts input data from untrusted sources. For each instance, the assessor shall confirm that input data is required to conform to a list of expected characteristics and that all input that does not conform to the list of expected characteristics is rejected by the software or otherwise handled securely.

Any terminal software functions that accept externally supplied data (directly or indirectly) is a potential attack vector, particularly when the data is processed by an interpreter.

Injection attacks are common for almost all types of software and are intended to manipulate input data in a way that causes software to behave unexpectedly or unintentionally. For …

Removed p. 80

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 evidence (including source code) to identify all software functions that handle buffers and process data supplied from untrusted sources. For each of the noted functions, the assessor shall confirm that each of the identified functions:

• Uses only unsigned variables to define buffer sizes.

• Conducts checks to 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 often leverage low-level programming …

Removed p. 81

B.3.2.a Using information obtained in Test Requirement 1.2.a, the assessor shall examine evidence (including source code) to identify all software functions that handle sensitive data. 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 output an error …

Removed p. 82

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.

Removed p. 83

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 evidence to confirm that the software vendor maintains a documented process in accordance with Control Objective 10.2 for testing the software for vulnerabilities prior to each update or release, and that the documented process includes detailed descriptions of how the vendor tests for the following:

• The presence or use of any unnecessary ports and protocols.

• The presence or use of any unnecessary ports and protocols.

• The unintended storage, transmission, or output of any clear-text account data.

• The unintended storage, transmission, or output of any clear-text account data.

• The presence of any default user accounts with default or static access credentials.

• The presence of any hard-coded …

Removed p. 85

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 evidence to confirm that guidance on how to securely implement and operate the software for all applicable payment terminals is provided to stakeholders in accordance with Control Objective 12.1.

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 evidence to confirm that the required guidance includes detailed instructions on how to configure all available security options and parameters of the software …

Removed p. 86

B.5.1.4 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions on how to cryptographically sign the software files in a manner that enables the cryptographic authentication of all such files by the payment terminal in accordance with Control Objective B.2.8.

B.5.1.5 Implementation guidance includes instructions for stakeholders to cryptographically sign all prompt files.

B.5.1.5 The assessor shall examine evidence to confirm that the required guidance includes detailed instructions for stakeholders to cryptographically sign all prompt files in accordance with Control Objective B.2.9.

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 evidence (including the payment terminal vendor’s security guidance/policy and the guidance required in Control Objective B.5.1) to confirm that the guidance aligns with the payment terminal vendor’s security guidance/policy.

Software implementation guidance must exclude instructions that conflict with the guidance and recommendations of the payment terminal …

Removed p. 87

C.1: Web Software Components & Services C.2: Web Software Access Controls C.3: Web Software Attack Mitigation C.4: Web Software Communications Purpose and Scope This section (hereinafter referred to as the “Web Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that use Internet technologies, protocols, and languages for the purposes of initiating or supporting electronic payment transactions. This includes both traditional (monolithic) and cloud-native payment applications, APIs, web services, microservices, serverless functions, GRPC, and any other methods used to make payment functions accessible or to conduct electronic payment transactions over the Internet. Any software-based features or functions that handle requests from Internet “clients” and generate responses to initiate or support an electronic payment transaction are in scope for the requirements in this module.

Considerations Web software architectures can be extremely complex and involve features and functions that are provided by different entities and may …

Removed p. 88

C.1.1 All software components and services are documented or otherwise cataloged in a software bill of materials (SBOM).

C.1.1 The assessor shall examine evidence to confirm that information is maintained that describes all software components and services comprising the software solution, including:

• All proprietary software libraries, packages, modules, and/or code packaged in a manner that enables them to be tracked as a freestanding unit of software.

• All third-party and open-source frameworks, libraries, and code embedded in or used by the software during operation.

• All third-party software dependencies, APIs, and services called by the software during operation.

Modern software is rarely created entirely in-house and is typically composed of various bespoke code segments integrated with numerous components such as commercial and/or open-source frameworks, libraries, APIs, and services. Any part of this code may have or develop vulnerabilities over time that will require patching or mitigation.

Knowing all of the components that comprise a software …

Removed p. 89

C.1.2.a The assessor shall examine evidence to confirm that the SBOM describes all primary (top-level) components and services in use and all of their secondary transitive relationships and dependencies.

Software components and services may have many nested relationships and dependencies with other software components and services that are owned or maintained by multiple different entities. Identifying all of these different relationships can be challenging where there are many different third-party components nested in the software code.

Fortunately, many software development frameworks and compilers provide the capabilities to identify and map nested and transient dependencies. For the purposes of this standard, the SBOM is expected to identify, at a minimum, the code obtained from third parties as well as their secondary transitive component relationships and dependencies (i.e., code embedded in third-party code).

If circumstances exist that complicate or prevent the identification of secondary transitive component relationships and dependencies, then such circumstances should be documented, …

Removed p. 90

Examples of these types of components include, but are not limited to, database servers, web servers, application servers, runtime platform(s), authentication servers/services, "plugins", and any other components or services present in the production environment.

C.1.4 The SBOM includes sufficient information about each component or service to enable tracking each component or service across the software supply chain.

C.1.4.a The assessor shall examine evidence to confirm that information is maintained in the SBOM that describes the following for each component and service in use, including secondary component relationships and dependencies:

• A description of the relationship(s) between the component and service and other components/services embedded in or used by the software.

• The version of the component or service as defined by the original supplier to differentiate it from previous or other versions.

• The name of the author who designed/developed the component or service.

• Any other identifiers provided by the original supplier to uniquely identify …

Modified p. 90 → 15

• The original ~~source/supplier of the component~~ or ~~service.~~

1-4.1 The original source or supplier.

Modified p. 90 → 15

• The name ~~of the component~~ or ~~service~~ as ~~defined~~ by the original supplier.

1-4.2 The name or reference as specified by the original source or supplier.

Removed p. 91

C.1.5 The assessor shall examine evidence to confirm that a new SBOM is created or otherwise generated for each new release of the software.

To enable tracking of vulnerabilities across different versions of a payment software, it is imperative that each version of the software has a SBOM generated that accurately reflects the components and services in use by that version.

Since many different versions of a payment software may be available (or active) at any given time and may include multiple versions of numerous third- party components and services, each version of the payment software must be tracked independently of other versions.

Failure to identify and describe the components and services unique to a given version of payment software could enable vulnerabilities to be introduced without the software provider’s knowledge if they are unaware that a vulnerable version of a software component or service is in use.

C.1.6 Vulnerabilities in third-party components and …

Removed p. 92

C.1.7.a Where software components and resources are fetched from external and/or third-party repositories, the assessor shall examine evidence to confirm that the authenticity of the software component is verified each time the component is fetched.

It is a common architectural design technique in modern web applications to download or “fetch” third-party components and resources (for example, files, scripts, stylesheets, packages, and libraries) that are housed on publicly available code repositories (such as public content delivery networks) at the time they are needed rather than embedding and maintaining those components and resources in local code repositories. This technique provides many benefits including the ability to automatically deploy updates to third-party components and resources without necessarily having to recompile code.

Unfortunately, there are some significant drawbacks to this approach. Third-party code repositories are heavily targeted by attackers because it enables them to potentially compromise numerous applications and entities by compromising a single package, library, …

Removed p. 93

C.2.1 User access to sensitive functions and sensitive resources exposed through Internet-accessible interfaces is authenticated.

C.2.1 Using information obtained in Test Requirements 1.2.a and 2.1.a in the Core Requirements, the assessor shall examine evidence to identify all sensitive functions and sensitive resources exposed through Internet-accessible interfaces.

Writing custom authentication functions is not a trivial matter. There are numerous issues and considerations that must be factored into the design and implementation of such functions including, but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses in design and must be resistant to targeted attacks.

Given the importance of and the heavy reliance on such functions for security purposes (and those of this standard), it is recommended that entities use third-party authentication functions, modules, libraries, services, and so on, that are already widely used within the industry and have been subjected to thorough security …

Removed p. 94

Similar to developing one’s own authorization mechanisms, developing custom authentication mechanisms can be quite a complex undertaking. Much of an application’s security is dependent on the strength and robustness of its authentication and authorization mechanisms. There are numerous issues and considerations that must be factored into the design and implementation of such functions including but not limited to, the fact that they are a significant target for attackers. Authentication functions must be free from weaknesses and must be able to withstand targeted attacks.

For this reason, only well-designed and well-tested mechanisms should be used. Authentication mechanisms that are provided by industry-accepted suppliers and widely adopted within the industry are generally understood to have been subjected to substantial testing and validation throughout the course of that adoption. Therefore, it is strongly recommended that these mechanisms be used by other entities instead of writing and implementing their own mechanisms.

Where the use of third-party …

Modified p. 94 → 87

~~C.2.1.1.a The assessor shall examine evidence~~ to ~~identify all methods implemented by~~ the software ~~to authenticate~~ access to sensitive ~~functions and sensitive resources.~~

C4-1.a Examine vendor documentation to verify that the software authenticates authorized user access to sensitive assets via publicly-accessible interfaces.

Removed p. 95

C.2.1.2 Using information obtained in Test Requirement C.2.1.1.a, the assessor shall examine evidence to confirm that the authentication methods implemented are sufficiently strong and robust to protect authentication credentials in accordance with Control Objective 5.3 in the Core Requirements section.

Strong and robust authentication methods are those that are resistant to common attacks. Examples of such methods include, but are not limited to, multi- factor authentication and/or authentication methods that employ strong cryptography (such as digital signatures or certificates).

C.2.1.3 Authentication decisions are enforced within a secure area of the software.

C.2.1.3.a The assessor shall examine evidence to identify where within the software architecture authentication decisions are enforced.

Like authorization decisions, authentication decisions must be enforced within a secure area of the software. Authentication methods should never rely solely on scripts or data obtained from the client or browser. With that said, it is permissible to use client-side scripts and data when combined with …

Removed p. 96

• implemented correctly;

• appropriate for the types of users expected to use the interface; and

• does not expose known vulnerabilities.

One key difference between traditional “monolithic” web applications and modern web applications is the degree to which an application is exposed (or potentially exposed) to the Internet. Where monolithic web applications tend to keep interactions between software components confined to a single security context (such as an internal or isolated system or network), modern web applications are typically segmented into many distinct and/or independent software functions that are then exposed to the Internet through APIs so that they may be accessible to other application or users, regardless of where they may reside.

Unfortunately, each Internet accessible interface (and the functions and resources it provides) is a potential attack vector. To mitigate the risks associated with exposing so many software functions to the Internet, each interface must implement access control mechanisms to ensure …

Removed p. 97

C.2.3.1.a Using information obtained in Test Requirement C.2.3, the assessor shall examine evidence to determine how the software controls access to individual functions and resources exposed (or potentially exposed) through Internet-accessible interfaces.

To support the fine-grained access control needs of modern web application architectures and to ensure that users are only able to access the software functions and resources that they are authorized to use, the software must support the ability to define and enforce access control rules at varying “levels” within the interface’s hierarchy, including at the individual function and resource level(s).

Depending upon the types of functions and resources exposed in a given software interface, the methods used to authorize access at the interface- level may not be appropriate to provide access to individual functions and resources exposed through such interfaces.

For example, API keys are often used to authorize access to an API for a particular entity (also called project-level …

Removed p. 98

Where fined-grained access control is necessary, the methods implemented to control access to all software functions and resources exposed through Internet accessible interfaces must be appropriate for the types of authorization(s) required (for example, user versus entity) and the functions and resources involved (sensitive versus non-sensitive functions and resources).

Wherever end users are required to configure the access control authorizations and permissions for individual functions and resources exposed through Internet accessible interfaces, the software vendor must provide guidance (or otherwise make guidance accessible) to users and other stakeholders to explain how to configure such permissions and to alert them to important security considerations when configuring available options and parameters.

C.2.3.1.e The assessor shall examine evidence and test the software to confirm that the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet-accessible interfaces require users to be explicitly authorized prior to being granted such access.

C.2.3.2 …

Removed p. 99

C.2.3.3.a The assessor shall examine evidence to identify where in the software architecture authorization and access control decisions are enforced.

Payment software should never rely on unknown or insecure services and features for security-related purposes. Secure areas or systems are those within the software architecture where the integrity of available services and data is ensured, and therefore can be relied upon by the software.

Historically, web application architectures consisted of “client-side” components and “server-side” components. Client-side functions are those typically performed by a common web browser. Server-side functions are those typically performed by web, application, and/or database servers. Given the open nature and design of most common web browsers and the fact that they are maintained by end users, server-side functions are typically considered to be more secure given a software/service provider’s ability to control and secure those aspects of the software architecture.

Modern web software architectures, however, have become increasingly complex with …

Removed p. 100

C.3.1 The software enforces or otherwise supports the use of the latest HTTP Security Headers to protect Internet accessible interfaces from attacks.

C.3.1.a The assessor shall examine evidence to confirm the software supports the use of the latest HTTP Security Headers, and to determine the options available and how such settings are configured.

HTTP Security Headers are a set of security-related configuration options available on most common web servers. Examples include the X-Frame-Options header, the HTTP-Strict-Transport-Security header, and the Content-Security-Policy header.

C.3.1.b Where HTTP Security Headers are configured and controlled by the software provider, the assessor shall examine evidence to confirm that the software is configured to use the latest available HTTP Security Headers and that the configuration settings are reasonable and justified.

C.3.1.c Where user input or interaction is required to configure HTTP Security Headers, the assessor shall examine evidence to confirm that guidance is made available to stakeholders in accordance with Control …

Modified p. 100 → 79

~~The use of these options~~ can protect against ~~a variety of~~ different types of ~~attacks~~ including ~~cross- site~~ scripting, clickjacking, and cross-site request forgery attacks.

HTTP security-related headers and their configurations can protect against different types of attacks, including cross-site scripting, clickjacking, and cross-site request forgery attacks.

Modified p. 100 → 79

While support for specific HTTP ~~Security Headers~~ may differ depending on the underlying platform or software technology, these options are widely available and should be enabled and configured to the most secure configuration feasible for a given implementation.

While support for specific HTTP headers may differ depending on the underlying platform or software technology, these options are widely available and should be enabled and configured to the most secure configuration feasible for a given implementation.

Removed p. 101

Two of the most common types of attacks, Injection (SQL, XML, Code, String, and so on) and Cross-Site Scripting (XSS), exploit the software’s trust in input data provided by untrusted sources to execute malicious code or to force the software to behave in unintended ways.

To protect against these and other types of related attacks, input data must never be trusted, and software security controls must be implemented to ensure input data is validated, rendered safe, or otherwise handled in a manner that mitigates the likelihood and/or impacts of executing malicious input data.

C.3.2.d Where such attacks are acknowledged and using information obtained in Test Requirement 4.2.a in the Core Requirements section, the assessor shall examine evidence to confirm that software security controls are defined and implemented to mitigate attacks that attempt to exploit vulnerabilities through the manipulation of input data.

C.3.2.e Where the implementation of software security controls is configurable or otherwise …

Removed p. 102

Other methods, such as parameterization and output escaping, are better suited as primary defense mechanisms. While the type and complexity of the input data and how the data is expected to be used often dictate the methods that are most appropriate for a given input, parameterization should be used where possible. Output escaping can be used as an alternative if parameterization is not feasible. The use of input validation may be used as a secondary defense, where appropriate, to provide defense-in- depth.

As is the case with other critical functions such as authentication and authorization, input protection methods should leverage industry-accepted third- party mechanisms where possible. If the use of such mechanisms is not feasible, then custom methods may be used if they are designed and implemented in accordance with applicable industry standards or best practices.

C.3.2.1.c The assessor shall examine evidence and test the software to confirm that the implemented methods:

• …

Removed p. 103

Where certain parser/interpreter features cannot be configured securely, the assessor shall examine evidence to confirm that other methods are implemented to mitigate the lack of secure settings and to further protect against the execution of malicious commands.

The specific settings that must be disabled/enabled to protect against certain attacks depends on the parsers and interpreters. For more information, refer to available security guidance on the specific parsers/interpreters in use.

Where certain features of the parsers or interpreters cannot be configured with the most secure settings possible, then the processing of untrusted input data should use techniques such as sandboxing to prevent (or otherwise mitigate the impacts of) malicious code execution.

C.3.3 Software security controls are implemented to protect software interfaces from resource starvation attacks.

C.3.3.a Using information obtained in Test Requirements C.2.1.a and C.2.2, the assessor shall examine evidence to identify all Internet accessible interfaces and the functions and resources exposed (or potentially exposed) …

Removed p. 103

C.3.3.c The assessor shall examine evidence to confirm that the software security controls implemented to mitigate resource starvation and other similar attacks on Internet accessible interfaces are designed and implemented in accordance with applicable industry standards and best practices.

Modified p. 103 → 16

• The ~~threat of such attacks~~ is documented in accordance with ~~Control Objective 4.1, and~~

1-5 The software versioning schema is documented and in accordance with the Program.

Removed p. 104

Examples of methods used to mitigate the risk of such attacks include limiting the rate on the number of requests that can be submitted within a given time period (rate limiting). Additional methods to prevent such attacks may include defining other limits such as the number of users and/or systems that can submit requests, mutually authenticating those users and systems, or using CAPTCHA or other anti- automation techniques that can prevent large volumes of requests being submitted to software interfaces within a short time period.

For SaaS or other similar environments, appropriate network-based controls may also be used to address these types of attacks.

C.3.4 Software security controls are implemented to protect Internet accessible interfaces from malicious file content.

C.3.4.a Using information obtained in Test Requirement C.2.1.a, the assessor shall examine evidence to identify all Internet accessible interfaces that accept file uploads and the file types permitted.

File uploads can be used to provide …

Removed p. 105

Many file formats allow for the embedding of other files or data which can be ‘expanded’ out when parsing the source file. In some scenarios this can be used to gain privileges or exploit vulnerabilities on the host platform which would not otherwise be possible. Uploaded files need to be managed in ways that prevent the exploitation of file parsing or expansion attacks.

To prevent the exploitation of file upload systems, any files that are uploaded cannot be assigned writable or executable privileges. Files which are required to be writable need to be copied across to a separate file managed only by the software to prevent a malicious user from exploiting the file between upload and use.

For defense-in-depth, some software development languages and frameworks include the ability to make calls to anti-malware systems to scan these files upon upload. For more information, refer to relevant third-party documentation.

File and file type parsers …

Removed p. 106

C.3.5.a Using information obtained in Test Requirements C.2.1.a and C.2.2, the assessor shall examine evidence to identify all software functions exposed through Internet accessible interfaces that accept and process data objects as inputs.

Some software APIs accept serialized data objects (for example, arrays, cookies, tokens, and so on) to be passed from other systems. However, without appropriate methods in place to restrict object deserialization and creation, malicious individuals may be able to use these APIs to launch denial-of- service attacks, compromise access control mechanisms, or inject and execute malicious code on underlying systems.

There are numerous methods to protect against serialization (and deserialization) attacks. Some programming languages, libraries, and APIs provide features and functions that are resistant to serialization attacks. Other methods include using deserialization mechanisms that only support pure data formats like JSON or XML, limiting data types allowed during object creation, encrypting communications, and authenticating API clients.

Appropriate methods to protect …

Removed p. 107

Some file-parsing mechanisms are inherently susceptible to certain vulnerabilities. For example, XML parsers are often vulnerable to External Entity attacks. Similarly, JSON parsers are vulnerable to attacks where insecure commands, such as eval(), can enable the execution of malicious code.

To mitigate attacks that attempt to exploit vulnerabilities in file-parsing mechanisms, it may be necessary for entities to implement additional software security controls. Examples of such controls include, but are not limited to, configuring file-parsing mechanisms to use the most restrictive configuration feasible, avoiding or escaping certain commands that are known issues for file-parsing mechanisms, or isolating and executing file-parsing commands in a sandbox. The methods used to further mitigate such attacks should consider the specific parsers and interpreters in use and be implemented in a manner appropriate for each parser and interpreter.

C.3.5.h Where the software security controls implemented to protect against hostile object creation and data tampering are user configurable …

Removed p. 109

C.4.1.a Using information obtained in Test Requirement 6.2.a, the assessor shall examine evidence to determine how communications are handled by the software, including those between separate systems in the overall software architecture.

The types of data which may be considered sensitive may vary across different implementations. See Control Objective 1.1 for more information on identifying sensitive data.

It is therefore important that any connection that transmits sensitive data is encrypted using strong cryptography. Common methods for achieving this will include the use of TLS using appropriate cipher suites.

Although connections that do not transmit sensitive data do not explicitly require the use of encryption, it is noted that the use of strong cryptography to secure all connections is considered a best practice and should be implemented for all communications unless legitimate business or technological constraints exist that render such an approach infeasible. In most cases, however, communications between web application components include the …

Modified p. 109 → 41

~~C.4.1~~ Sensitive ~~data transmissions~~ are ~~encrypted~~ in accordance with ~~Control Objectives 6.2 and 6.3.~~

4-1.8 Sensitive modes of operation are designed in accordance with requirement 5-4.3.1.

Removed p. 110

Where sensitive data is transmitted between systems operating within different security contexts and/or different environments, it is important that such communications be restricted to an explicitly approved list of systems, and that the systems involved be mutually authenticated such that attempts to intercept or compromise such communications are appropriately mitigated.

Where the software provider controls the configuration of such communications, mutual authentication must be enforced. Otherwise, the software provider must provide features to support the mutual authentication of disparate systems so that an implementing entity may configure such features accordingly.

C.4.1.d Where internally generated or self-signed certificates are used for securing sensitive data transmissions, the assessor shall examine evidence to confirm that:

• The use of internally generated or self-signed certificates is reasonable and justified.

• The software is configured to accept the minimum feasible number of internally generated or self-signed certificates.

Many organizations that choose to use internally generated and/or self-signed certificates do so …

Document Comparison

Content Changes