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

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


  1. 1 PCIduck
    November 27, 2017 at 2:14 PM

    There appears to be a scoping issue with the addition of 2.1. Given the wording the of the question – this control would have to apply to every system on the same network as the Merchant’s system webpage hosting the redirect/iFrame page. Is that the intent? If this was taken literally – from a practical standpoint – Network controls would have to be applied around the merchants web server to limit the scope of checking the systems 2.1 would apply to…

    • November 28, 2017 at 4:18 PM

      SAQ A assumes that everything related to processing, storing or transmitting SAD/CHD is outsourced to third parties and there is nothing in-scope other than possibly a Web server that does a redirect/iFrame. Under that scenario, even the Web server has limited scope and never comes into contact with SAD/CHD. As a result, the only scope is that Web server if it exists.

      • 3 PCIduck
        December 1, 2017 at 12:00 PM

        Thanks for the response! That is the issue I’m referring to as far as the the merchants web server with the redirect/iFrame which I believe is a very common scenario as company’s try to reduce their PCI scope. That would pull all of the systems on the merchants web server into scope for requirement 2.1.

      • December 1, 2017 at 2:14 PM

        If the Web server is the only system on that network segment, then it would be the only system in-scope for PCI compliance.

      • 5 PCIduck
        December 1, 2017 at 4:34 PM

        Thanks for the quick response! Yes, that was the point I was trying to make. In many cases I believe the merchants web server will not be on an isolated network segment – which could bring requirement 2.1 into scope for all of those systems on the same network (bringing potential gray area around network segmentation/firewalling). I believe this brings unintended scope creep with this addition to SAQ A.

      • December 8, 2017 at 9:08 AM

        Yes, there will be a larger PCI scope if other servers are in the same network segment.

  2. 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

  3. 9 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.

      • 11 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.

  4. 13 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 )

Google+ photo

You are commenting using your Google+ 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 )

w

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,985 other followers

Advertisements

%d bloggers like this: