The SAQ A Applicability Question

Introduction

It appeared to be an excellent idea for the Payment Card Industry Security Standards Council (PCI SSC) to help Merchants with the creation of various shortened Self Assessment Questionnaires. Each of the questionnaires contain an abridged suite of controls to represent specific kinds of payment channels:

1. SAQ A - Fully Outsourced.
2. SAQ A-EP - Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing.
3. SAQ B - Merchants with Only Imprint Machines or Only Standalone, Dial-out Terminals – No Electronic Cardholder Data Storage.
4. SAQ B-IP - Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage.
5. SAQ C-VT - Merchants with Web-Based Virtual Payment Terminals – No Electronic Cardholder Data Storage.
6. SAQ C - Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage.
7. SAQ P2PE - Merchants using a Validated PCI-Listed P2PE Solution Only – No Electronic Cardholder Data Storage.
8. SAQ D - Merchant - All other SAQ-Eligible Merchants.
9. SAQ D - Service Provider - SAQ-Eligible Service Providers.

However, when you take a deep dive look at the SAQ A, there are many contradictions contained within the SAQ.

How can this have happened?

The suite of 22 controls, in the SAQ A, are taken from the Payment Card Industry Data Security Standard (PCI DSS) catalogue of security controls. The problem being that the PCI DSS is designed for the following:

"PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data".

Now, the SAQ A has been developed to address requirements applicable to merchants whose cardholder data functions are completely outsourced to validated third parties, where the merchant retains only paper reports or receipts with cardholder data:

Consequently, when you deep dive into the specific controls, a great number of them may not make sense to a fully outsourced payment channel, which meets the aforementioned criteria.

Findings

The 22 controls of the SAQ A are taken from the following Requirement areas, from the PCI DSS:

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Requirement 6: Develop and maintain secure systems and applications.

Requirement 8: Identify and authenticate access to system components.

Requirement 9: Restrict physical access to cardholder data (Paper only).

Requirement 12: Maintain a policy that addresses information security for all personnel.

Thriving on Chaos

"If you're not confused, you're not paying attention".

― Tom Peters, Thriving on Chaos: Handbook for a Management Revolution

Letting the chaos ensue, I will carry out a deep dive into each of the SAQ A controls:

2.1 Vendor Defaults

• Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).

No electronic storage, processing, or transmission of any cardholder data on the Merchant's systems or premises, but relies entirely on a third party(s) to handle all these functions?

What vendor-supplied defaults?

What system?

What network?

The Merchant has confirmed that everything is outsourced and that everything is carried out by a 3rd Party.

6.2 System Updates

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.

What system?

Being that everything is outsourced, is it not the 3rd party who manages the access to the systems, under their PCI DSS compliance?

Any cardholder data is only retained on paper.

Management of the Third Parties, to which the payment card operations are FULLY OUTSOURCED!

 The Merchant does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions

What System has been breached?

What has been compromised?

What Data?

Recommendations

As you can see, based upon an auditors perspective, the content of the controls can be extremely confusing and the applicability of these controls can be interpreted differently.

For example, one interpretation could be that a Merchant has FULLY OUTSOURCED all the responsibilities to a PCI DSS compliant third party. Therefore, the only controls that should apply are the management of the third party (the 5 controls from Requirement 12.8).

Another Merchant might decide, in case of the unavailability of the third party's services (inability to take payments) to include the application of Incident Response (Requirement 12.10.1).

• If the Merchant is considering this, does this mean that they regard this as a risk?

If this is the case, shouldn't the Merchant be considering the Risk Assessment (12.2) control?

Oops!

That's not a control that is included within SAQ A.

Consequently, when completing your annual SAQ A, I would highly recommend that before start to complete the form, you familiarise yourself with the 'Before You Begin' section.

Having satisfied yourself that your business does 100% meet this requirement, you can then start to identify which controls you deem to be 'Applicable', 'Not Tested' or 'Not Applicable.

To do this, you need to take off the 'Auditor Glasses' and replace them with your 'Risk Glasses'.

• What risks are the intent of these controls helping to mitigate against?
• Do you want to mark a control as being not applicable, when the intent of the control (Not the exact wording) can help you to mitigate a risk?

If you are using an embedded iFrame or secure redirect (eligible for a SAQ A), where the customer enters their cardholder data directly into your PCI DSS compliant third party's interface (no cardholder interaction on your webpages), have you considered the risks of a vulnerability in your adjacent webpages (part of your customers' payment journey), which allows a threat actor to inject malicious code to redirect the customers' payment journeys?

• Would you benefit from monitoring your digital footprint for vulnerabilities?

E.g.

Network Security

Application Security

If I were this well-known online retailer, I would be very worried to be seeing such a significant drop in my public profile.

Whether you are an eCommerce Merchant that uses an embedded iFrame or secure redirect, I would highly recommend that you bolster your PCI DSS compliance (SAQ A) with some vulnerability scanning of your digital footprint.

Many such organisations are seen as low hanging fruit for attackers, such as the Magecart Group 8:

If you're concerned that your ecommerce (iFrame or secure redirect to a Payment Service Provider) might be vulnerable, why not reach out to Cyber Rescue Alliance to see how they may be able to assist you?

Contact: [email protected]

Conclusion

It is clear, just through this brief deep dive into the shortest SAQ there is much of the content that could be improved for clarity and to reduce the potential for misinterpretation.

In fact there's probably enough content for me to author a follow up book to PCI DSS: An Integrated Data Security Standard Guide, but that will need to wait until I have had chance to investigate and analyse the updated PCI DSS v4.0 controls and the supporting SAQs.

I hope that these findings have given you some food for thought and, all being well, much of these confusions and chaos will be addressed with the release of PCI DSS v4.0, following the Request For Comments (RFQs).