Principal Security Analyst
CISSP, CISA, QSA
As expected, big changes have been made to the Self-Assessment Questionnaire (SAQ) A in PCI DSS version 4.0. Several PCI DSS requirements were added in the transition to version 4.0 to help better protect these e-commerce payment channels. Some of these requirements were existing PCI DSS requirements that have now been added to the SAQ A and some are new to version 4.0 of the PCI DSS. If requirements are new to the PCI DSS, merchants will have until March 31, 2025, to ensure these requirements are in place. For existing PCI DSS requirements that have been added to the SAQ A version 4.0, no such grace period is given. This post will highlight changes made to the SAQ A version 4.0 and provide guidance on how to comply with newly added requirements.
All SAQs include a list of criteria that are used to define what type of payment channels are eligible to be assessed using that particular SAQ. In PCI DSS version 4.0, the list of qualifying criteria can be found in Part 2h of the document.
The SAQ A is designed for e-commerce or mail-order/telephone-order merchants who have outsourced the payment capture, transmission, and processing of cardholder data to PCI DSS-compliant third-party vendors. The list of qualifying criteria between version 3.2.1 and version 4.0 remained relatively unchanged. There was one significant change made to one of the qualifying criteria that should be noted. The SAQ A version 3.2.1 included the following qualifying criteria:
“Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant”
This has been reworded in version 4.0 to the following:
“The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant”
The SAQ A version 4.0 is much more clear on how a merchant is to validate the PCI DSS compliance status of their third-party service providers (TPSPs). Merchants are not only to validate that their TPSP(s) are compliant but they are to ensure that the TPSP is compliant for the services used by the merchant.
A common way some merchants validate the PCI DSS compliance status of their TPSP(s) is to look up the TPSP company’s listing on the Visa Global Registry or the Master Site Data Protection Program Registry. These third-party registries provided by the card brands can be used in some cases to verify that a third party has a valid Attestation of Compliance. What these registries do not provide that is required in version 4.0 of the SAQ A is documentation that would help the merchant verify that the TPSP is “PCI DSS compliant for the services being used by the merchant”. By requesting a copy of the TPSP(s) Attestation of Compliance (AOC) form, the merchant can verify that the services provided by the TPSP to the merchant were included in the TPSP’s PCI DSS assessment.
When the PCI SSC updates the Self-Assessment Questionnaires, they will sometimes choose to include existing PCI DSS requirements that had not been part of a particular SAQ in the past. Several examples of newly-added existing requirements have been included in version 4.0 of the SAQ A. One thing to keep in mind with these new additions is that these are not future-dated requirements. These requirements will need to be validated when performing an assessment using version 4.0 of the SAQ A.
The following existing PCI DSS requirements were added to the SAQ A in version 4.0:
3.1 Processes and mechanisms for protecting stored account data are defined and understood.
This applies to merchants who store cardholder data on paper records (paper receipts or reports with full PAN data). Typical SAQ A merchants will not store unmasked credit card data (also referred to as PAN data) on paper reports as the capture and processing of cardholder data has been outsourced to PCI-compliant TPSP(s). If merchants do not store full PAN data on paper, this should be marked as Not Applicable.
If, however, a merchant does have paper storage with full PAN data, a data retention and disposal policy should be in place that defines the data retention period and outlines how this data is to be secured during storage and destroyed after the retention period expires.
3.2 Storage of account data is kept to a minimum.
If full PAN data is stored on paper by the merchant or stored in any format by the merchant’s TPSP(s), this requirement will apply. Any entity, merchant or service provider, that stores cardholder data must follow a documented data retention and disposal policy (as noted in Requirement 3.1 above).
For requirement 3.2, the merchant is expected to work with their TPSP(s) to identify any cardholder data storage and to understand how the TPSP meets this requirement for the data being stored on behalf of the merchant.
6.3 Security vulnerabilities are identified and addressed.
A vulnerability management strategy must be in place for any merchant website that implements an iframe provided by a TPSP for payment collection or redirects customers to a TPSP-managed website for payment collection. Merchants must be actively monitoring industry sources to identify vulnerabilities that may affect their e-commerce system and must have a documented procedure for ranking risks associated with identified vulnerabilities. Identifying high-risk vulnerabilities is required in order to properly implement the monthly patching required by 6.3.3.
8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
When accounts are being created on merchant e-commerce servers or when passwords are being reset for existing accounts, passwords must be set to a unique value. It is recommended that system administrators use password generators to create unique passwords that can be given to employees for their initial authentication. Additionally, administrators should use access control mechanisms to force the user to reset their password after they successfully authenticate.
8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
Password history must be enforced on administrative accounts on the merchant’s e-commerce web server (the server that redirects to a TPSP payment capture website or implements a TPSP-provided iframe for payment collection). The password history must prohibit the administrative user from using one of their previous four passwords when resetting the password on their account. It is recommended that controls be enabled to prevent a user from performing four password reset functions in rapid succession to circumvent the password history functionality.
8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single factor authentication implementation) then either:
Passwords/passphrases are changed at least once every 90 days,
The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Accounts for system/web administrators on the merchant’s e-commerce server (the server that redirects to a TPSP payment capture website or implements a TPSP-provided iframe for payment collection) must be set to require passwords to change every 90 days or undergo a security posture analysis to determine the safety of the current credentials in use.
11.3.2 External vulnerability scans are performed as follows:
External ASV scans must be performed against the merchant e-commerce server(s) used to redirect customers to TPSP payment capture websites or that use a TPSP-provided iframe to perform payment capture functions.
ASV scans are required to be performed every three months. Vulnerabilities identified must be remediated and rescans performed to ensure the vulnerability has been resolved per the ASV Program Guide requirements.
In addition to the above-mentioned existing PCI DSS requirements, a few requirements new to PCI DSS version 4.0 have been added to the SAQ A. Merchants performing a self-assessment using a version 4.0 SAQ are not required to validate these future-dated requirements until March 31, 2025.
Depending upon the size and complexity of the merchant’s environment, it may take considerable effort to implement some of these new requirements. It is recommended that SAQ A merchants begin now to plan for the implementation of the following new requirements:
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
Requirement 6.4.3 applies to the page(s) on the merchant’s website(s) that includes a third-party service provider's/payment processor’s embedded payment page/form (for example, an inline frame or iFrame). To comply with Requirement 6.4.3, merchants must implement policies and procedures for managing third or fourth-party scripts implemented on these webpage(s). Scripts that may seem harmless can have their functionality altered without the merchant’s knowledge. Such scripts may be able to be used to upload malicious scripts that could be used to perform an e-commerce skimming attack even though the merchant’s website was not designed to capture or transmit cardholder data.
Scripts may be verified by manual or automated processes. Tools such as Content Security Policy (CSP), Sub-Resource Integrity (SRI), or proprietary script management systems can be used to help meet the intent of this requirement.
8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
Requirement 8.3.6 is an evolving PCI DSS requirement. In version 3.2.1, passwords were required to be at least 7 characters in length consisting of a mix of numeric and alphabetic characters. Beginning on March 31, 2025, the password length requirement is increased to 12 characters in most instances while the password complexity requirement remains unchanged. This would apply to administrative access to the e-commerce web server(s) in use.
11.6.1 A change and tamper-detection mechanism is deployed as follows:
To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
The mechanism functions are performed as follows:
This requirement only applies to SAQ A merchants who make use of a third-party iframe to perform payment capture. If the merchant’s website is configured to redirect the customer’s browser to the TPSP’s payment acceptance page, they would mark this requirement as Not Applicable.
Similar to Requirement 6.4.3, a TPSP’s-provided iframe on a merchant’s website must be protected from e-commerce skimming attacks. Requirement 11.6.1 requires merchants to implement change detection procedures and technologies to alert personnel to unauthorized modifications to the HTTP headers and contents of the page(s) used to house the TPSP iframe. Such tamper-detection mechanisms must run at least weekly to look for unauthorized modifications to these critical web pages. The SecurityMetrics Shopping Cart Monitor can be used to help meet the intent of this requirement.
Version 3.2.1 of the PCI DSS will be retired on March 31, 2024. After that date, merchants performing self-assessments will be required to use version 4.0 of the Self-Assessment Questionnaires.
Due to the wide adoption of EMV-capable payment cards and readers, card-present fraud has become more challenging. This has caused an increase in e-commerce attacks and e-commerce fraud. Version 4.0 of the SAQ A has been strengthened to help address the increased risk to e-commerce merchants. While merchants can continue to use version 3.2.1 of the SAQ A until it is retired, it is recommended that merchants begin now to become compliant with all of the requirements listed in version 4.0. Doing this will help to prepare for future assessments when version 4.0 will be the only viable solution and it will help to more adequately address the risks faced by today’s e-commerce merchants.
|
| By: Michael Simpson Principal Security Analyst CISSP, CISA, QSA |
