Merchants using the SAQ C to validate their PCI DSS compliance should be aware of changes that were introduced into this questionnaire during the publication of the SAQ C version 4.0.
The Payment Card Industry Data Security Standard (PCI DSS) includes a list of security requirements designed to protect cardholder data transmitted or stored in a merchant environment. The Self-Assessment Questionnaires (SAQs) were created to simplify PCI DSS compliance for small merchants. Each SAQ is designed for a specific type of payment environment and includes a mix of controls specifically suited for that specific environment. Small merchants who support card-present payments using traditional Point-of-Sale deployments configured not to store cardholder data may find they meet all of the eligibility criteria (see Part 2h of the SAQ C) for validating their PCI DSS compliance using this simplified form.
Merchants using the SAQ C to validate their PCI DSS compliance should be aware of changes that were introduced into this questionnaire during the publication of the SAQ C version 4.0. In this blog we will review these newly added requirements to the SAQ C.
Future-dated requirements added to PCI DSS version 4.0 are considered best practice until March 31, 2025. Entities are not required to validate compliance to these requirements until that date.
Depending upon the size and complexity of your environment, it may take considerable effort to implement some of these new requirements. It is recommended that SAQ C Merchants begin now to plan for the implementation of the following new requirements:
While some elements of Requirement 4.2.1 are not new to the SAQ C, the requirement to ensure certificates used to protect cardholder data during transmission are not expired or revoked has been newly added and merchants will need to have a process in place to address this requirement prior to 3/31/2025.
The overall risk assessment required by PCI DSS v3.2.1 has been replaced with targeted risk assessments. For Requirement 5.2.3.1, merchants who have identified systems in their CDE as not being commonly affected by malware must perform a targeted risk assessment to define the frequency at which the merchant will reassess the finding of non-applicability for malware protection. This is considered a best practice until 3/31/2025.
If a combination of real-time scanning and periodic malware scans are used to protect CDE systems from the threat of malware (as opposed to performing continuous behavioral analysis of systems or processes), a merchant must perform a targeted risk assessment to determine the frequency of malware scans. This is considered a best practice until 3/31/2025.
OR
Requirement 5.3.3 can be considered an evolving requirement for malware prevention. Malware protection in place in the environment should be configured to either automatically scan removable electronic media (USB drives, external hard drives, SSD memory cards, etc.) when mounted or the malware solution should be continuously performing behavioral analysis to provide automatic malware protection for these connected media types. This is considered a best practice until 3/31/2025.
Phishing attacks are becoming more prevalent and more sophisticated in recent years. While employee training is critical to preventing successful phishing attacks from negatively affecting the security of a merchant’s environment, technical controls should be added to provide more layers of protection against these attacks. For requirement 5.4.1, it is recommended that merchants implement a combination of approaches to prevent spoofing attacks. Anti-fishing tactics include anti-spoofing technologies (domain-based message authentication, domain keys identified mail, and sender policy framework) and phishing email blocking or link scrubbing technologies.
This is considered a best practice until 3/31/2025.
In order to show evidence of compliance for this requirement you will want to show that a bi-annual user account and access privileges review happens and has management acknowledgement or signoff. It may work well to pair this up with a bi-annual firewall ruleset review or rotate quarterly between a firewall review and a user access privilege review.
This is considered a best practice until 3/31/2025.
In order to show evidence of compliance for 7.2.5 you will need to confirm the application and system accounts only have the access and privileges necessary for their function. If you give an account access to more than is needed or privileges more than is used you will run the risk of a compromised application or system account being accessed and doing things they shouldn’t.
This is considered a best practice until 3/31/2025.
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.
In requirement 8.4.2, multi-factor authentication is required for all access into the CDE. However, this requirement does not apply to application or system accounts performing automated functions or user accounts on POI terminals that have access to only one card number at a time to facilitate a single transaction. MFA is required for both access into the CDE and for remote access originating outside the entity’s network that could access or impact the CDE (requirement 8.4.3).
Multi-factor authentication solutions need to be implemented securely and cannot be susceptible to replay attacks, user permission bypass (unless authorized and documented), have to use two different types of factors, and success of all authentication factors is required before access is granted.
Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. These accounts often come with local admin privileges and even some domain privileges that could allow these accounts access to other systems. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. If you hard code the authentication credentials or include them in a configuration file or custom source code then anyone who has access to that code or configuration file can then obtain the interactive login credentials and possibly gain local admin privileges and privileges across the domain. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
It’s common for application and system accounts to be overlooked and forgotten. To show evidence of compliance for this requirement you will need to perform a risk assessment (NIST 800-30 would suffice) and make sure that it includes the risk posed by not changing or infrequently changing an application or system account or not having sufficient complexity for that password. After the risk assessment has been performed you will also need to show the policy created to address the application and system account password risks. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
Because of the vast amounts of logging data collected it becomes almost impossible to manually review it and so PCI is requiring you to use an automated solution that scans through the logs and looks for anomalies or issues. To show evidence of compliance for 10.4.2.1 you will need to assess the risk of the frequency in which periodic reviews for all other systems not defined in 10.4.1 are considered, and create a documented policy and procedure to address that risk.
A good way to satisfy this requirement is to do a NIST 800-30 risk assessment and include the threat events posed by the PCI requirements throughout the report, along with a baseline of threat events provided in the NIST 800-30 guidance document and any threat events that have or could occur to your environment based on the people, processes and technologies used. The risk assessment should include a spreadsheet of threat events and their corresponding risk determination. The risk assessment should have management signoff and have CDE-wide (ideally organization-wide) contribution and should be a living document that is periodically updated. Ideally the risk assessment document would be used to justify security control expenditures and to prioritize mitigation and risk-treatment efforts. A rigorous risk assessment and resulting documentation would satisfy the risk aspects of requirements: 1.2.6, 2.2.5, 5.2.3, 5.2.3.1, 5.3.2.1, 6.3.1, 6.3.3, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1, 11.3.1.1, 11.3.1.3, 11.4.1, 11.4.4, 11.6.1, 12.3.1, 12.7.1, 12.8, 12.10.4.1, A2.1.2, and Appendix B: Compensating Controls Worksheet (4. Identified Risk).
As discussed in requirement 5.4.1 above, companies should be taking a defense-in-depth approach to prevent phishing and other social engineering-related attacks. To be compliant with requirement 12.6.3.1, a merchant’s security awareness training program needs to include education on how to detect, react to, and report phishing and social engineering attempts. It is also recommended that members of the merchant’s incident response team are made aware of how to properly respond to notifications of these types of attacks against the organization.
In addition to newly added requirements, several existing PCI DSS requirements were enhanced. These enhanced/evolving requirements include the following:
Well-documented security policies and procedures can help merchants maintain a PCI DSS-compliant environment if employees working in the environment are aware of policies and procedures that apply to their job responsibilities. PCI DSS Requirements 1.1.1, 2.1.1, 3.1.1, … 12.1.1 focus on ensuring policies related to these sections are up to date and are distributed to affected parties.
For example, for Requirement 3, a merchant should have a defined data retention policy that prohibits any electronic storage of cardholder data within the merchant environment and defines data retention and data destruction procedures for any physical media containing cardholder data.
Prior to PCI DSS v4.0, secure software development requirements had not been included in the SAQ C. For Requirement 6.2.1, if a merchant develops software used in their payment environment, a software development life cycle policy based on industry standards and best practices must be in place. Policies and procedures should guide the developers and security engineers in meeting Requirements 6.2.2, 6.2.3.1, and 6.2.4 discussed below.
Merchants who develop custom or bespoke software in their CDE need to ensure their developers receive training annually. This training should be relevant to their job functions and languages used and include secure code design and coding techniques. Online or in-house training can be used to meet this requirement.
Merchants who develop custom or bespoke software in their CDE must ensure a process is in place to have all code changes reviewed by someone, other than the original author, who is knowledgeable about secure coding principles. It is recommended that review checklists or other tools be used to guide the peer review process to ensure code changes are not introducing new vulnerabilities into the CDE. In addition to performing code reviews, management review and approval prior to deploying code into the production environment must be documented.
It is important that developers understand techniques to prevent common software attacks and vulnerabilities from being introduced into their code base. This begins with ensuring secure coding practices are included in the SDLC and in annual developer training. The peer review process should include steps to look for these common vulnerabilities that may have been inadvertently introduced in code changes. Several code scanning tools are available to search for these common software attacks and can be incorporated in the code review and deployment process.
While the SAQ C in version 3.2.1 did require merchants to document significant changes to their CDE to ensure continued compliance with all applicable PCI DSS requirements, in version 4.0 the SAQ C requires merchants to have change management policies and procedures in place to review, approve, and document changes to all system components in the CDE. Change control tickets should capture the reason for the change, the security impact, approval by authorized parties (peer review, management, etc.), security testing performed, and rollback procedures.
Note: This requirement applies to all user accounts, including employees, contractors, consultants, temporary workers, and third-party vendors.
To meet this requirement merchants will need to have a documented account provisioning process that would capture authorized approval for any new or modified user account in the cardholder data environment and the privileges associated with the account.
If an employee with access to the merchant’s cardholder data environment is terminated or their job role is changed in such a way that access to the CDE is no longer required, their account must be disabled or removed. This should be included as part of the merchants user account provisioning and removal policy mentioned above.
User accounts in the CDE must be disabled or removed if they are not used for more than 90 days. It is recommended that this be an automated process.
User authentication credentials used in the CDE must be strongly encrypted or hashed during transmission and storage. Unencrypted remote access methods, like Telnet or HTTP, should not be used when authenticating to systems in the CDE. Strong cryptography or encryption must be in place to protect the passwords during storage. Disabling legacy password hashing protocols like the Windows LAN Manager hash and using NTLMv2 on Windows systems and SHA512 for Linux can help to meet this requirement.
If a merchant supports a non-face-to-face password reset process, this process must include steps to verify the user’s identity prior to resetting their password.
Audit logs must be protected from unauthorized modification or destruction by ensuring read access is limited to those with a job-related need. Protections are in place to prevent individuals from modifying audit log data. Log files need to be promptly backed up to a secure log server and FIM or file change detection mechanisms need to be in place to ensure that existing log data cannot be modified without generating an alert.
Systems within the CDE need to be configured to synchronize their clocks with one or more designated time servers to ensure time-stamped log data is useful. Only the designated time server should be receiving time information from an external source. Time received from external sources must be based on international atomic time or UTC. If more than one designated time server is in use, these servers must be configured to peer with one another to keep accurate time.
Access to time configuration on CDE systems must be limited to personnel with a business need. Any changes to time settings on critical systems must be logged, monitored, and reviewed.
While an incident response plan was required in version 3.2.1, the SAQ C has added the sub requirement that says a merchant must have personnel available 24/7 to respond to suspected or confirmed security incidents.
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.
The SAQ C has seen some substantial changes in version 4.0. There are a number of future-dated requirements that merchants will need to address prior to March 31, 2025 and several existing PCI requirements were added to the SAQ C that were not included under v3.2.1. These existing requirements that were newly added to the SAQ C must be in place when performing an SAQ C assessment of the merchant environment.
.svg)
