11
May
16

Heads Up – Changes To SAQ A

I had a question this week regarding v3.2 of SAQ A that pointed out there have been some changes to that SAQ that people may have not noticed given the larger issues with the changes to the PCI DSS.  As a reminder, SAQ A is the least amount of PCI requirements any in-scope organization can comply.

Those added requirements to SAQ A are:

  • 2.1(a) – Are vendor-supplied defaults always changed before installing a system on the network?
  • 2.1(b) – Are unnecessary default accounts removed or disabled before installing a system on the network?
  • 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data?
  • 8.1.3 – Is access for any terminated users immediately deactivated or removed?
  • 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
  • 8.2.3(a) – Are user password parameters configured to require passwords/passphrases meet the following?
  • 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited
  • 12.10.1(a) – Has an incident response plan been created to be implemented in the event of system breach?

Even when a merchant outsources all of their card processing, these are controls that can still apply because in a lot of cases, a merchant is responsible for setup, management and maintenance of their outsourced payment processes and applications.

In addition, merchant employees will also interact with an outsourced payment system to handle chargebacks and disputes.  Those user accounts used by the outsourced environment will normally be managed by someone at the merchant, not necessarily the service provider.

In regards to incident response, the merchant will be involved with incident response even when they have totally outsourced their payment environment.  The merchant will work with their outsourcer to work through an incident and those responsibilities of the merchant need to be documented.

As a result, the addition of these controls should not be a surprise to anyone.

Advertisements

9 Responses to “Heads Up – Changes To SAQ A”


  1. June 27, 2016 at 11:42 AM

    Hi,

    I wished that all our in-scope systems and processes are SAQ A. However, I observed that a SAQ A process (on the part of the merchant) is tricky. This is because the Service Provider said that although they provide the platform for the online form/shopping cart they are not involved in any way in the processing, storing and transmission of card data because they pass it to their partner payment gateway. Therefore, they do NOT need to be PCI compliant. Is this claim from a sevice provider true and correct?

    Thanks,
    raul

    • June 27, 2016 at 1:23 PM

      Service providers are service providers when it comes to PCI whether they actually touch data or not. See my post on the subject, Get Over It, You Are A Service Provider

  2. 3 Erik
    June 13, 2016 at 1:49 AM

    Me and my QSA colleagues are having a debate regarding what the new SAQ A requirements regarding authentication and accounts apply to. Do they apply to:

    * The Merchant’s web server (doing the redirect)?
    * Any access the Merchant has to the payment processor’s systems?

    The May 2016 Assessor Newsletter seems to incicate that they apply to the Merchant’s web server, but this seems like such a huge change to the SAQ A scope, it makes me unsure if that’s really what the council means.

    What do you think?

    • June 13, 2016 at 6:20 AM

      You and your friends are correct. They apply to the merchant’s Web server that does the redirect or invokes the iFrame. The reason for the change is that the Council and the card brands are finally realizing what the rest of the InfoSec community knew which was that those Web servers are part of the payment chain and need better protection. It is only a matter of time before those same Web servers will need to be ASV scanned as well.

      • 5 Vincent
        July 7, 2016 at 5:52 AM

        Where did you see that the webserver is in scope in case of an iFrame? I didn’t see any change there ! The SAQ A-EP does apply in case of a redirect but not iFrame.

      • July 7, 2016 at 6:21 AM

        Both the iFrame and redirect are covered by SAQ A. The management of users applies not only to the outsourced Web site, but also to the merchant’s Web site doing the redirect or the iFrame.

  3. 7 PCI Consultant
    June 8, 2016 at 1:02 PM

    I can’t say I disagree with the bare minimum reqs and intention of PCI-SSC. I would have also included the Integrity checking controls in section 11. Since SAQ A will often be used in e-commerce solutions having outsourced the storage, transmission and/or processing to a PCI compliant PSP using an iframe or re-direction integration… It would be of high value to ensure the page serving the redirect or iframe is not tampered with. I always recommend this to clients even if it isn’t a PCI requirement.

    On another note, since SAQ A is supposed to be the SAQ for when you do not have a CDE on site, against what does an organization apply the new controls? (i.e. If the org has a flat network, does it only apply them to e-commerce systems or every system?…) Curious to see how it will be interpreted in coming months/years.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

May 2016
M T W T F S S
« Apr   Jun »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,884 other followers


%d bloggers like this: