Article
PodcastYour SAQ and You: Common Misunderstandings in PCI Self-Assessments
The following article has been revised on April 12, 2022 to reflect updates to PCI DSS 4.0.
Growing businesses that accept credit cards are likely to be required to submit a Self-Assessment Questionnaire (SAQ) and Attestation of Compliance (AOC) for Payment Card Industry (PCI) compliance to acquirers (banks) or clients.
For merchants, the bank typically submits the request to the company’s finance manager. Service providers often receive similar requests from their merchant clients although the request will normally flow through the client account manager. In either case, the individual receiving the request often reviews the SAQ, quickly becomes confused by the regulatory jargon and technobabble, and passes it off to the IT team. The IT team may then check off the boxes and return the completed SAQ, which states that the organization is in compliance with PCI requirements. But is it?
Completing an SAQ accurately usually involves multiple hurdles and common misinterpretations. These may include selecting the right SAQ and properly defining your scope or understanding that marking a requirement as “In-Place” should be substantiated with test results. Another common misunderstanding is how to interpret the expected testing steps prescribed in the SAQ.
This article addresses the basics of how to complete your SAQ form correctly, including the need for testing, as well as common misunderstandings involving the expected testing procedures.
Testing to Assess Your Environment
The first common misunderstanding is that you can complete an SAQ without testing, based solely on your knowledge of the environment. In the SAQ instructions, the section Expected Testing refers to the test steps found in Section 2 of the SAQ template. It prescribes test steps you need to perform to assess your environment accurately against the PCI requirements. The depth of your testing may vary based on the specifics of the cardholder environment and the nature of the specific PCI requirement that you are testing. Once you understand the need for testing, you are ready to begin.
The Requirements: Step by Step
The following table summarizes the PCI DSS sub-requirements that, in our experience, tend to cause some level of confusion for organizations attempting to complete the SAQ. The table includes links to supporting details about what the misunderstandings are as well as our recommendations on how to properly address the requirements.
|
PCI DSS Objectives |
Top level |
Common Misunderstandings? |
Which PCI DSS 4.0 Subrequirements? |
Which PCI DSS v3.2.1 Subrequirement? |
|
Build and maintain a secure network and systems |
1. Install and maintain network security controls |
N |
||
|
2. Apply secure configurations to all system components |
Y |
2.2 2.3 |
||
|
Protect account data |
3. Protect stored account data |
Y |
3.4 |
|
|
4. Protect cardholder data with strong cryptography during transmission over open, public networks |
N |
|||
|
Maintain a vulnerability management program |
5. Protect all systems and networks from malicious software |
N |
||
|
6. Develop and maintain secure systems and software |
Y |
6.2 6.4 6.5 |
||
|
Implement strong access control measures |
7. Restrict access to system components and cardholder data by business need to know |
N |
||
|
8. Identify users and authenticate access to system components |
Y |
8.1.3 8.1.4 8.1.5 |
||
|
9. Restrict physical access to cardholder data |
N |
|||
|
Regularly monitor and test networks |
10. Log and monitor all access to system components and cardholder data |
Y |
10.2 & 10.3 10.5 |
|
|
11. Test security of systems and networks regularly |
Y |
11.2 |
||
|
Maintain an information security policy |
12. Support information security with organizational policies and programs |
N |
Requirement 1
This addresses firewall management standards being defined and implemented to restrict access between trusted/untrusted networks and traffic to/from the internet, installing a personal firewall on your portable computing devices, and ensuring those responsible for the firewalls know and use the documented standards. These are areas that IT networking personnel should be very familiar with, and are less likely to be misinterpreted.
Requirement 2
This addresses default accounts and settings. And while it’s common practice to change vendor-supplied passwords, this is where we come to the first of our common stumbling points.
2.2: Hardening Standards
This is multi-part, and that is what’s often overlooked. First you need to ensure the organization has both a hardening standard for all components (servers, network devices, etc.). This is likely something that exists informally, and needs to be written into a formal standard to address the requirement. Next, you need to verify the hardening standard is consistent with industry-accepted standards such as CIS Level 1 Benchmarks, NIST SP 800-123 Guide to General Server Security, or other similarly accepted standards applicable to your systems. If you are aligned to those types of standards, the rest of 2.2’s sub-requirements should be addressed within your documented standard.
2.2.7: Non-Console Administrative Access
This is also frequently misinterpreted. The meat of this requirement is that when you are not directly physically connected to the device (one end of a cable in your terminal, the other end of that same cable in the device), strong encryption and secure protocols must be used. While PCI DSS does not specify what is considered strong or insecure, industry guidelines (see Requirement 2.2 above) typically include the use of SSH2 for accessing network devices, TLS1.2 or higher for web interfaces, etc. Protocols and algorithms such as Telnet or DES should be avoided.
Requirements 3-4
These focus on protecting the actual cardholder data. Since most organizations shouldn’t be storing sensitive authentication data (E.g.: PIN, CVV codes, etc.) most of these requirements are easy to interpret.
One requirement that is harder to understand covers how to treat the Primary Account Number (PAN), or card numbers, in storage.
3.5.1: Unreadable PAN in Storage
This addresses restricting access to the PAN. The big question here is whether you have the PAN stored anywhere in your systems. This may be in the point of sale program, a database, or even an error log for troubleshooting. If you are uncertain if the system records the PAN, assume it does and manage your encryption accordingly (Requirement 3.5.1 through 3.7.9).
In Requirement 4 we again apply principles of strong encryption and key management to the transmission of information across open, public networks (internet, Bluetooth, cellular connections, etc.). With many organizations shifting to a remote workforce models throughout 2020 and 2021, a greater understanding of the value of encrypting data being sent over public networks has been achieved, leading to fewer misunderstandings around Requirement 4.
Requirements 5-6
These address the need to maintain vulnerability management programs. Requirement 5 focuses on installing, maintaining, and monitoring anti-virus/anti-malware systems, which is typically addressed through installation of anti-malware software, and appropriate configuration of the update frequency for the malware signatures files from a trusted source. Requirement 6’s focus is ensuring new vulnerabilities are not introduced through the development and change management processes, and contains a number of easily misunderstood sub-requirements.
6.3.3: Patching
Everyone that uses a Windows workstation has experienced the dreaded “Installing patch 1 of…” message when they shut down at the end of the day. This is an example of where IT has automated the patching process for a system, but there are other cases where it’s hard to automate. The most common is network devices, such as routers and firewalls. Because of the high availability nature of these systems, most have two configurations, saved and running. When an administrator patches the saved configuration they may need to restart the system to have the running configuration update as well. Depending on redundancy in the environment this can cause downtime, and so must be managed carefully. Even with the downtime considerations, failure to update both configurations within a reasonable timeframe would result in non-compliance. The definition of “reasonable timeframe” is not prescribed within the PCI DSS, and may vary by organization. Timeframes should be defined within organization policy, and should be based on a risk-prioritized approach, with priority determined by system criticality and potential impact of delays in remediating vulnerabilities.
6.2: Software Development Processes
Although this requirement is relatively straightforward it still is often misinterpreted. When you develop your own software or make changes to software, you must consider common coding vulnerabilities. Requirements 6.2.4 lists specific vulnerability categories to be considered, but as technology evolves it is important to consider current best practices, such as OWASP or SANS CWE for verifying that common vulnerabilities are addressed in your custom written code.
6.5: Change Control Processes
CChange control is often a frustrating topic for admins and developers. It’s far easier to create and implement a change directly in production than to create changes in non-production environments (6.5.3), have another person confirm it works as intended, have the change approved, and then have someone independent implement (6.5.4). But these segregations of duties, where possible and feasible, create additional layers of protection and error checking, to ensure the cardholder data environment remains secure.
Requirements 7-9
These involve various considerations for implementing strong access control measures, both logical and physical. This is the bread and butter of many IT control environments, so most IT personnel believe this area is locked down. While that is probably true, it’s important to note a few key phrases in the requirements that are often overlooked and may cause an issue.
8.2.5: Terminated Users
This requires access for any terminated user to be immediately deactivated or removed. “Immediate” can be hard to accomplish without a procedure defined in advance to resolve this need. As this requirement is specific to users with access to the cardholder data environment and relevant system components, many organizations can handle those revocations through the same process as privileged (administrator) accesses, which provides a defined path for addressing these accesses in a timely manner.
8.2.6: Inactive Users
While also straightforward, this requirement is often overlooked. If the user account hasn’t logged in for 90 days, disable it or remove it. The most common issues with this requirement come from interactive service accounts associated with legacy systems where it’s unknown if making the account non-interactive will break the system, and “break glass” accounts for emergency use which often remain unused for long periods of time. The solution to prevent these accounts from becoming dormant should not be logging into them each quarter. Making system and service accounts non-interactive is the preferred path. If accounts cannot be made non-interactive, document the account purpose and who can gain access to it. A process for reviewing who has accessed these accounts over a period of time is also recommended, where possible.
8.2.7: Third Party Access
If you have support from a third party, they may have an account on your systems. This requirement is intended to ensure that unless that third party is actively performing a function in your environment, their access to your systems is disabled. Usually, this is achieved in one of two ways:
- 1. Creating network accounts that are provisioned with remote access but are disabled by default, and only enabled when the third party requires access to perform their function, or
2. Creating accounts that are provisioned at the system or infrastructure layers without remote access capabilities, requiring the third party to work with an active user logged into the network, which can also simplify the requirement to monitor third party remote access while in use.
Requirements 10- 11
The objective for these is to monitor and test your networks, with Requirement 10 focusing on logging and monitoring, and Requirement 11 on testing security systems and processes.
10.2: Audit Trail Components
For 10.2, it’s not enough to just have audit logging turned on. 10.2.1 through 10.2.1.7 provide a list of specific events that must be logged, and 10.2.2 prescribes the information that must be logged when those events occur. It’s common for organizations to overlook some of these events and attributes, so it’s recommended to compare the logging configuration against the requirement to ensure the system is set up appropriately.
10.3: Protecting and Monitoring Audit Logs
This requirement focuses on the principle of least privilege. If a user does not need access to the audit logs based on their job responsibilities, then remove their access to the logs. What is frequently overlooked is server administrators. When logging server events, and subsequently storing those logs on a server, the administrator will likely have the ability to affect to the log, which is the scenario this requirement is established to avoid. Options such as writing logs to write-once devices or off-site systems that the administrators are unable to alter are recommended. Where that is not possible, file-integrity monitoring must be implemented on the logs.
11.3: Vulnerability Scanning
Performing the scans according to the prescribed frequency is straightforward. The overlooked component here is the required rescan to confirm remediation of identified vulnerabilities. When vulnerabilities are found and addressed, another scan should be performed to confirm the vulnerability has been remediated. Waiting until the next quarterly scan is typically not sufficient per the requirement, unless that next quarterly scan is scheduled to occur within a narrow window (e.g 1-2 weeks) from the remediation.
Requirement 12
This addresses maintaining an information security policy. The requirements are fairly straightforward. Focuses here are ensuring the organization has the prescribed policy statements and policy distribution, verifying PCI compliance of service providers, and training personnel on information security and incident response.
Appendix A
This is split into three sections, A1, A2, and A3. A1 applies to multi-tenant (shared hosting) service providers, and addresses segregation of each hosted entity’s environment. A2 is only applicable when SSL or early TLS is in place, and provides additional requirements to mitigate the risk of using these weaker protocols. A3 applies to designated entities which are determined by an acquirer (merchant bank) or payment brand (Visa, MasterCard, Discover, AmEx, and JCB) as requiring additional validation to existing PCI DSS requirements.
The considerations described in this article are recommendations for areas to pay extra attention to in your self-assessment. Implementing new compliance efforts can pose particular difficulties, so we recommend enlisting help for your first assessment.
Weaver has experience helping clients complete the SAQ, as well as providing the more comprehensive PCI Report on Compliance (ROC) and other PCI consulting services for many clients, ranging from Fortune 50 organizations to small merchants. To find out how we can help your organization achieve and maintain PCI DSS compliance, or help strengthen your security program in general, please contact us for more information.
Authored by David Friedenberg, CISA, CRISC, CISSP, PCIP, QSA.
© 2021