SAQ Version 1.2 Brings Some Clarity for Level 4 Merchants
Oct. 30, 2008
The PCI Council released the Payment Card Industry Data Security Standards (PCI DSS) 1.2 at the beginning of October, and a few days ago they released the corresponding changes to the Self Assessment Questionnaire. We've had a chance to examine the new versions of the SAQ and have some observations.
While overall the changes weren't significant, there is evidence that the PCI Council is making strides in clarifying the questionnaire’s language, which is particularly helpful for small merchants. This is especially true for those merchants who use the PCI DSS as an opportunity to achieve and maintain a high security posture. Since ControlScan is exclusively focused on small merchants (Level 4 as defined by VISA), our analysis is focused on this audience.
The most notable change in SAQ 1.2 is the ability to select "Non-Applicable" for questions in the SAQ. Previously, only merchants qualifying for SAQ D (versus A, B and C) could respond to questions with "Special" and still achieve compliance. In this case their alternate answer was "Compensating Controls" which required that the spirit of the requirement still be met. The merchant was also required to fill out a large worksheet that detailed the specific compensating control employed by the merchant. With SAQ 1.2, merchants filling out SAQ A, B or C can indicate that a specific requirement is not applicable to their environment and then provide a brief explanation. For example, if a merchant is trying to answer question 9.7.2, “Is the media sent by secure courier or other delivery method that can be accurately tracked?" and the merchant never sends media by courier, the merchant can indicate that information on the SAQ.
SAQ Form B:
Requirement 4 (Encrypt transmission of cardholder data across open, public networks):
Requirement 4.2: The requirement has been expanded to include all end-user messaging technologies such as email, instant messenger and chat.
Requirement 9 (Restrict physical access to cardholder data):
Requirement 9.10.1: The requirement qualifies that the destruction of cardholder data must ensure that the information cannot be reconstructed.
Requirement 12 (Maintain a policy that addresses information security for employees and contractors):
- This requirement has been expanded to include more examples of critical employee-facing technology. The list of examples now includes: remote access technologies, wireless technologies, removable electronic media, email usage, Internet usage, laptops and personnel data/digital assistants (PDA's). The key takeaway is to make sure that you update your policies to include new technologies that may not have been main stream when the policy was originally written.
- The biggest change to requirement 12 relates to 12.8.4 and 12.8.2. Your compliance is no longer directly tied to the compliance of your service provider, but you must maintain a program to regularly engage with them and push them towards validating their compliance. In addition, you now need a written agreement with service providers that indicates that they are responsible for the security of any cardholder data that you give them. This is a key change, especially for smaller merchants. Compliance is no longer tied directly to the compliance of your service providers (though you must constantly monitor it); however, it is still critical that you seek out service providers that have validated compliance.
SAQ Form C:
Requirement 1 (Install and maintain a firewall configuration to protect data):
Overall this requirement provides clarification around firewall requirements.
Requirement 2 (Do not use vendor-supplied defaults for system passwords and other security parameters):
The requirement modifies setting requirements around wireless devices. You no longer required to turn off SSID Broadcasts. This is one less thing to do to satisfy the DSS. It does not really impact overall security in any way as you could always retrieve the SSID of a wireless access point regardless of whether it is broadcasting or not.
Requirement 5 (Use and update anti-virus software or programs):
Requirement 5.1, 5.1.1 and 5.2: The requirements have been tightened up and now clarify that anti-virus software must be capable of detecting, removing and protecting against all known forms of malicious software.
Requirement 6 (Develop and maintain secure systems and applications):
Requirement 6: This requirement changes the patching requirement from 30 days to one month and now allows for a risk-based patching approach. This is very helpful to teams that release patches at the beginning or end of the month, bringing more consistency to the process. Please see the new DSS for the full requirements around risk-based patching.
Requirement 11 (Regularly test security systems and processes):
Requirement 11.1: The requirement now allows for the use of wireless IDS/IPS, which operates on its own, versus using a wireless analyzer, which involves walking around the building with a laptop looking for wireless signals. This change should make compliance a little easier to achieve.
SAQ Form D:
The SAQ form D is primarily for merchants who store cardholder data. If you are a small merchant storing card-holder data, you may want to consider finding solutions to help you offload the storage of data onto another entity that has already been approved by the PCI Council. In almost every case where we encounter a Level 4 merchant who stores cardholder data, the merchant has changed their business processes to discontinue storing card data (usually by offloading the storage to their gateway/processor who can recall card purchases in the case of charge-backs refunds etc).
Overall the changes to the SAQ are fairly mixed. For those companies that use the DSS as a big checkbox to satisfy and forget, the changes may take some effort to implement; however, for those companies that use the DSS as an opportunity for better security practices, the changes will bring additional clarity and should require minimal implementation effort.
To view the full set of changes between versions, of the PCI DSS please visit https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf.