New! More! A First Look at the PCI DSS 3.0 SAQs

In November 2013 the PCI Security Standards Council (SSC) released version 3.0 of the Data Security Standard (DSS). As my colleague Chris Bucolo shared previously, v3.0 is heavily influenced by recent breach trends and is meant to more strongly address the basics of payment data security.

This past week, the SSC released the Self-Assessment Questionnaires (SAQs) supporting PCI DSS v3.0. The 3.0 SAQs include substantial modifications as well as all-new questionnaires, presenting a learning curve for small and mid-sized merchants as well as the ISOs and acquirers serving them.

‍

What’s new? A first look…

The QSAs and small-business security experts at ControlScan have invested significant time and energy to analyze the 3.0 SAQs. Reading through and comparing the 3.0 SAQs with those tied to PCI DSS 2.1 yields some noteworthy observations.

‍

V3.0

• A Card-not-present merchants: All payment processing functions fully outsourced, no electronic cardholder data storage 14 +1 No No
• A-EP E-commerce merchants re-directing to a third-party website for payment processing, no electronic cardholder data storage 139 NEW Yes Yes
• B Merchants with only imprint machines or only standalone dial-out payment terminals: No e-commerce or electronic cardholder data storage 41 +12 No No
• B-IP Merchants with standalone, IP-connected payment terminals: No e-commerce or electronic cardholder data storage 83 NEW Yes No
• C Merchants with payment application systems connected to the Internet: No e-commerce or electronic cardholder data storage 139 +59 Yes Yes
• C-VT Merchants with web-based virtual payment terminals: No e-commerce or electronic cardholder data storage 73 +22 No No
• D-MER All other SAQ-eligible merchants 326 +38 Yes Yes
• D-SP SAQ-eligible service providers 347 NEW Yes Yes
• P2PE Hardware payment terminals in a validated PCI P2PE solution only: No e-commerce or electronic cardholder data storage 35 +17 No No

‍

New SAQ types: A-EP and B-IP

The PCI SSC has continued its work in issuing SAQs to cover specific merchant payment processing circumstances, as seen in previous years with the addition of the SAQ C-VT for virtual terminals and SAQ P2PE for merchants incorporating an SSC-approved point-to-point encryption solution. In 3.0, an SAQ A-EP and an SAQ B-IP have been added, and the SAQ D has been formally split into two versions: one for merchants and one for service providers.

It appears that the SAQ A-EP was developed to address instances where an attacker takes over a merchant site, injects malicious code and links, and redirects the unsuspecting consumer to a false payment page. The SAQ A-EP adds a significant number of controls that must be put in place by an e-commerce merchant utilizing a hosted payment solution to ensure that the merchant’s web infrastructure is secured and cannot impact the security of the payment transaction.

The new SAQ B-IP accommodates merchants using a standalone payment terminal (NOT a POS system) that is connected over the Internet to a payment processor (NOT dial-up). The SAQ B-IP recognizes the specialized and more closed nature of the Internet-connected terminal while increasing the required security controls to ensure it is used in a secure manner. This should be a welcome improvement for these merchant types, who previously were required to complete the much lengthier SAQ C.

‍

More requirements across the board

With the release of 3.0, every single SAQ includes additional requirements, clearly indicating that there has been scrutiny about how every SAQ type is being used. In many cases, the new requirements provide additional refinement and detail to the requirements that were already included, clarifying to eliminate confusion about what is expected of the merchant when it comes to putting a control in place. When it comes to critical processes, the merchant has to define it, document it, make sure it’s communicated to the right people, and make sure the process is properly followed. As SSC General Manager Bob Russo has said, “Payment security becomes business as usual.”

In particular, there are now quite a few more scenarios where the three vulnerability detection approaches of ASV scanning, internal scanning and penetration testing must be employed. The relevant SAQs provide more detail on how often they must be conducted, but it is critically important to acknowledge that they are not one-time events; each of these vulnerability detection approaches must be repeated on a regular basis.

‍

More guidance for the merchant

Along with all of the new requirements, the 3.0 SAQs bring new examples and notes for the merchant, as well as refinements to those that were already present. Many of these comments are highly useful in providing context to the merchant as they fill out the questionnaire.

There is also an entirely new column – “Expected Testing” – which explains how the merchant should go about validating that the related security requirement is actually in place and being exercised. ControlScan anticipates that all the additional requirements and content will likely give pause to anyone who has developed an online SAQ tool for merchant use. It is clear that the PCI SSC will continue to drive specificity into the SAQs, tailoring them for large segments of merchants based on the way payments are being processed. It is also clear that the PCI SSC will add more requirements over time to remove ambiguity over how the PCI DSS is to be applied.