26
Apr
14

Why SAQ A-EP Makes Sense

A colleague of mine attended the PCI SSC QSA Update session at the ETA convention a couple of weeks back.  One of the big discussion items was how the Council is being pilloried over SAQ A-EP.  This SAQ was developed to address the recommendations that were documented in the information supplement titled ‘PCI DSS E-commerce Guidelines’ that was published in January 2013.  Specifically, SAQ A-EP addresses the ecommerce sites that do redirects to a processor’s site that does the actual payment processing.

Based on the comments I have seen online and made in personal conversations, you would think that SAQ A-EP was heresy or a bad joke.  All of these derogatory comments are being driven by merchants that were sold a bill of goods by slick, non-PCI informed, sales people pushing redirected ecommerce solutions by claiming that it put the merchant entirely out of scope.  This was not the case and never was the case, particularly after the issuance of the information supplement.  However, we still encounter outsourcing vendors that continue to claim a redirect approach puts the merchant entirely out of scope.

To understand the rationale of SAQ A-EP we need to understand the risk surrounding these redirect solutions.  The risk is that an attacker modifies the redirect on the merchant’s server to now point to their own payment page, collects the customer’s cardholder data (CHD) on the attacker’s page and then, optionally, passes the customer on to the original payment page at the processor so the customer and merchant are none the wiser.

Under the PCI DSS and card brands’ security programs, redirect systems are still in-scope for PCI compliance because they are a key control in the payment process even though the merchant’s server issuing the redirect does not come into direct contact with CHD.

With all of that said, SAQ A-EP is not a full SAQ D, but it is not as short and simple as SAQ A either.  There are a lot of requirements to be met with SAQ A-EP which is why merchants are up in arms.  However, if you understand the aforementioned risk, you should understand why the requirements that have to be complied with in SAQ A-EP are there.

The requirement 1 requirements are all there to ensure that there is a firewall protecting the server that does the redirect.  This is Security 101 and I would doubt that any merchant would not have a firewall protecting all of their Internet facing servers.  Routers have always been optional and if the merchant does not have control of those devices, then they would not be included here.

Requirement 2 is all about making sure that all devices in the cardholder data environment (CDE) are properly configured and security hardened.  Again, this is Security 101 stuff.  If a merchant is not doing this for Internet facing devices, they are just begging to be attacked and compromised.

The requirements called out in SAQ A-EP for requirement 3 are there to confirm that the merchant is not storing cardholder data (CHD) or sensitive authentication data (SAD).  A merchant using a redirect should be marking these as Not Applicable (NA) and documenting that they do not store CHD in their system(s) because they use a redirect that processes and transmits CHD directly between their processor and their customer.  Any merchant that answers these requirements any other way should not be using SAQ A-EP.  All of that said, merchants need to have proof that they examined logs, trace files, history files, databases, etc. and did not find any CHD or SAD in those files.

Requirement 4 is provided to ensure that secure communications are used.  I would recommend documenting the SSL/TLS certificate information for your processor for the requirements in 4.1.  But do not pass over requirement 4.2.  A lot of ecommerce only merchants have call centers or take telephone calls and do order entry into the same Web site used by their customers.  As a result, merchants need to make sure that email, instant messaging, etc. are never used for communicating CHD/SAD.

Requirement 10 is important for any forensic research should the redirect be manipulated so that it can be determined when that event occurred so that the scope of any compromise can be determined.

While one would think that the vulnerability scanning and penetration testing requirements in requirement 11 would be thought of Security 101 and self-explanatory, you would be surprised at how many merchants argue about that fact.  Again, the driver of these redirect solutions was cost reduction and vulnerability scanning and penetration testing incur costs, sometimes significant costs depending on the number of servers, firewalls, load balancers, switches, etc. involved.  If you do not do vulnerability scanning and penetration testing as required, how do you know that the redirect system(s) are properly secured and patched?

However, the key requirement that cannot be missed is requirement 11.5 regarding critical file monitoring.  That is because the whole security of the redirect environment is pinned on detecting any modification of the redirect URL.  All of the other requirements in SAQ A-EP are there to minimize the risk of compromising the redirect.  11.5 is there to ensure that, if the other controls fail, at least the merchant would be alerted to the fact that the redirect had been changed.  If a modification to the redirect cannot be reliably detected by the critical file monitoring solution, then the security of the redirect cannot be assured.

The remaining requirements for 5, 6, 7, 8, 9 and 12 are all Security 101 items.  If you are not following these requirements as part of best practices for security and IT operations in general, then you need to consider what exactly you are doing.

Hopefully everyone now understands SAQ A-EP and why it is not as simple as that slick sales person implied.

Advertisements

23 Responses to “Why SAQ A-EP Makes Sense”


  1. 1 Owen
    August 11, 2014 at 9:03 AM

    I’m getting myself in a tizzle with picking the right SAQ. My thoughts on the following environment would be SAQ D.
    Merchant hosted website with paypal redirect for entering payment card details.
    PDQs at the shops for face to face transactions.
    Telephone (not IVR) card payments too.

    Does SAQ D seem right to you?

    • August 12, 2014 at 5:55 AM

      I would agree. The driver is multiple methods of accepting payments.

  2. May 19, 2014 at 12:51 PM

    Could you clarify how iframe payment pages could be SAQ-A, as they mention, when the Understand pdf also says on page 5,

    “If any element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A does not apply;”

    This seems contradictory since an iframe is never a whole page and typically the rest of the page comes from the merchant’s website?

    In what context would an iframe pass SAQ-A according to the specs?

    • May 21, 2014 at 6:12 AM

      That was the problem with the clarification and why a lot of eCommerce vendors are up in arms. Based on the “Understanding” PDF that was issued in April 2014, iFrames are in scope, albeit somewhat reduced from a Web server that is processing or transmitting CHD.

  3. 5 Fackler
    May 13, 2014 at 12:01 PM

    From the section on Req 4: “…A lot of ecommerce only merchants have call centers or take telephone calls and do order entry into the same Web site used by their customers. As a result, merchants need to make sure that email, instant messaging, etc. are never used for communicating CHD/SAD.”

    ?!? By entering a customer’s CC number into one of their (merchant’s) computers that computer is now In Scope for PCI Compliance and they have just gone to SAQ-D. It makes no difference if the website they are using to process the order is the same as the one the customer uses. The merchant’s computer has had a customer CC number transmitted through it.

    • May 18, 2014 at 9:19 AM

      The PCI DSS states that all systems that process, store or transmit cardholder data (CHD) are in scope. So what you are saying is that keying data into a system is not processing or transmitting? The difference is that there is nothing the PCI SSC can do about a consumer doing data entry. However, when an organization is doing call center work it does not matter how that data entry is done although some methods are more secure than others. But at the end of the day, a call center is not a consumer in the eyes of the Council. A call center encounters more than just one consumer’s CHD which is why they are in scope.

      That said, in such situations, the workstation used for data entry can meet a reduced amount of requirements if they are strictly used only for data entry and no other purposes. But how many of those requirements have to be met depends on a number of factors such as network segmentation, workstation configuration and potentially other factors.

  4. 7 JS
    May 7, 2014 at 6:53 PM

    Reading through the “Understanding the SAQs for PCI DSS v3.0” (https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf)…

    -The only type of website “redirect” payment processing that falls under the SAQ A-EP is the “Direct Post” method or if Javascript (or similar) is served up.
    – If I redirect my users to a PayPal site, where the payment fields are on PayPal.com, this continues to fall under an SAQ A.

    Now, we can argue about security vs. risk and compliance vs. validation, but strictly, from a PCI validation point, redirects to a PayPal are an SAQ A…. direct post (from like a Braintree) is a SAQ A-EP.

    Thoughts?

    • May 8, 2014 at 9:43 AM

      Agreed. We went back and had a brief discussion on this very topic and we are sticking to our guns on what needs to be in place regardless of the SAQ. It just makes sense for the reasons I point out. You can still fill out an SAQ A, but you should be doing all of the things I pointed out in my post because of the risk.

      • 9 Louis
        May 13, 2014 at 11:04 AM

        Can somebody explain to me exactly what happened between February and May ?

        It seems to me somebody, somewhere, kicked the PCI SSC’s derriere and managed to get some leeway.

        SAQ A-EP and even the “Understanding” guide in the table of page 4, both state that redirect is A-EP, yet at the same time, page 5 of the “Understanding” guide, the 3rd bullet of SAQ A says otherwise

        Is it just me or are we about to see a slew of QSA interpretations, yet again ?

      • May 18, 2014 at 9:23 AM

        The Council took a LOT of heat from all of those solution vendors that they irritated when they issued SAQ A-EP back in February. In the intervening months, the Council changed their mind and issued the “Understanding” document.

        And yes, you will see a lot of QSAs not accept the new ruling. I know my Firm has not and we are going to stick to our guns on this one because we think the Council put merchants that use redirects and iFrames the weak link.

  5. May 7, 2014 at 6:00 PM

    I’m just starting to dig deep into this topic and my initial impression is that this will be a boon for PayPal and I would not be surprised if they didn’t have significant input in the rework. A key point to all the SAQ’s and PCI is that the buck stops at the owner of the merchant account. In the case of PayPal, PayPal is the merchant of record — not the merchant using PayPal.

    The other beneficiary will be the large one-stop hosting storefront providers: bigcommerce, godaddy, amazon, etc. Many merchants with small to mid sized sites using shared hosting will be shocked and panicked come June 2015 (probably starting November 2014). And this is going to decimate the open source shopping cart community unless a lot of hosting providers figure out a way to offer PCI certified shared solutions. I’m not even sure “shared PCI compliant hosting” is possible?!

    • May 8, 2014 at 9:40 AM

      Good points Steve. We just discussed this internally, and while we agree that SAQ A-EP keeps the redirect/iFrame users out of scope, we do not concur with that for the reasons cited in my post. There is still a risk even in those environments and to not identify those risks is foolish. As a result, we’re sticking to our guns and keeping those sites in scope, albeit limited.

  6. 13 Jonathan
    May 6, 2014 at 3:03 AM

    I agree with you from a security perspective and am surprised by the Security Council’s document “Understanding the SAQs for PCI DSS v3.0” https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf From the document it says “Merchant website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process. Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.” are addressed by SAQ A.

    “Merchant website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as “Direct Post”). Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.” are addressed by SAQ A-EP.

    It appears iFrame and URL redirects are for now being treated as secure, and all those merchants who implemented “Direct Post” are now no longer out of scope. In my opinion all these solutions should be SAQ A-EP.

    • May 6, 2014 at 6:52 AM

      I agree with your analysis and we do not treat the redirect or iFrame conditions the same as the Council because of the risk.

      • 15 Dave
        May 7, 2014 at 6:13 AM

        This is the standard argument of Compliance vs. Security, and unfortunately for a lot of companies compliance wins. In that vein, surely if a merchant is using a redirect or iFrame then their web servers fall out of scope of a QSA audit. Although the RISK is pretty much the same from a security point of view, PCI is not a risk based system and as such they wouldn’t fail the audit.?

      • May 8, 2014 at 9:44 AM

        The funny thing is that the Council keeps touting the DSS and their other standards as “risk based”. Yet, here we are discussing risk, and they come up with something different in their ‘Understanding the SAQs’ document.

  7. 17 Dave
    April 28, 2014 at 2:56 AM

    Although I absolutely agree with the points from a security perspective, it is contradictory of the e-Commerce supplement they produced under v2 which merely states implementation of the PCI controls for Direct Post, iFrames and Hosted payment Pages is a recommendation not a requirement. I suppose they are covered by the fact that it states it is a supplement and does not override the standards documents.

    This will be painful for companies that have moved to such solutions to reduce scope as they will need to re-evaluate there environments, I think hosting companies could be in for a boost in business if they can certify as a Service Provider to provide full outsourcing.

    • April 28, 2014 at 5:35 AM

      The Council moved from “recommendations” in the information supplement to codifying them as requirements with the publication of SAQ A-EP. A number of information supplements have ended up driving new requirements in the PCI DSS, so this should not be a surprise.

      As I stated in my post, this “change” was not a change for those of us that knew that redirects to hosted payment pages (HPP) still required security on the server issuing the redirect. It was the sales and marketing people at the service providers that misinterpreted/misrepresented the PCI DSS and lead merchants to adopt a solution that does not take them completely out of scope. The information supplement was issued to get the Council on the record explaining these facts.

      The next issue that will be abused is the P2PE/E2EE solutions. I would bet good money that sales and marketing people will tell merchants that those solutions take the merchants out of scope as well which is not true. The merchants’ terminals will still be in scope with P2PE/E2EE. And if you believe that those terminals cannot be abused (yes, it is much harder but can be done), I have a bridge I’d like to sell you.

  8. 19 D
    April 27, 2014 at 11:48 AM

    I dont agree with this, I may be the only person in the world, but I still feel the PCI-DSS burden is a problem for the card companies. I am paying them for a service, I simply dont want to hear about redirects, log files and all that other stuff. How do they expect the many tiny busineses to do this, when many are run by people who hardly understand the Windows operating system, let alone servers, routers, firewalls etc. All us merchants are just rolling over and suffering being charged for a service, where we have to take the risk and do all the work.

    If it needs all this effort from every merchant then the whole system is rubbish and not fit for purpose. IMO

    I want a service that processes my payments (Fully, including all the security) for that the card companies can take their cut. If they cant afford to provide that for their fee they should not be in the game.

    • April 27, 2014 at 12:18 PM

      While I understand your frustration, you should have read your merchant agreement much more closely as this is what you signed up for when you agreed to accept credit/debit cards for payment. Unfortunately, statistics say that small merchants are much more likely targets for breaches than the big box retailers. That is because they are much less likely to be as secure, know they have been breached and also more likely to fall under law enforcement’s radar due to the small number of cards involved. However, once identified by the card brands, I can tell you from experience, small merchants are likely to be put out of business by such a breach.

      One of the easiest ways for small merchants to get out from under the majority of PCI is to use a card terminal separate from their point of sale (POS) solution. Yes, integration is nice, but for a lot of merchants, integrated POS is too complicated and brings too much PCI compliance baggage. However, a separate card terminal can be wired/wireless/cellular and secure and allows you to only have to worry about compliance with SAQ A.

      Want to totally avoid PCI? Don’t accept cards for payment. While you may feel that is draconian and non-competitive, you may find it a creative way to draw business.

      • 21 Derwent
        May 8, 2014 at 5:07 PM

        Hi thanks for the comment, I just had to get that off my chest that particular day. I did read the card processor terms & conditions, but you have no choice. You have to take cards, customers expect it.

        We have a separate terminal in the store and we don’t take card payments over the phone. Online we specifically use a payment provider to limit the SAQ rip-off, now it is suggested even that does not escape.

        Just because we understand the many ways the system can be attacked and the enormous job in trying to protect it, doesn’t mean it’ should be the merchants responsibility. When I opened my business I was shocked to find out I didn’t get the same protections the end customer gets using cards.

        The card companies need to spend their money on a new system, one that we pay for as part of our contract, that simply covers all of this. Yes it’s a big task, but they came up with and implemented this global monster called card processing, so it must be possible for them to take the next step and make their own secure process.

        Someone smart will pull the card companies rug from under them one day and let’s hope it’s sooner rather than later 🙂

      • May 9, 2014 at 9:44 AM

        At the rate that it is growing, at some point the PCI DSS is going to say that the only way to securely accept credit cards over Internet infrastructure is to simply not do it.

        It is my only hope that the ever-exacting standards of the PCI DSS will cause such disruption in e-commerce that merchants simply throw up their hands and stop taking credit cards en masse, transitioning to a payment system that was designed for the digital age. The card issuing banks could do that, of course, by coming up with a Visa or MasterCard equivalent to PayPal, but that won’t because it’s easier to just throw the book at the merchant and ask every merchant on the planet to keep a number a secret. I can’t help but shake my head at how PayPal has managed to screw up this opportunity over the past decade; someone needs to come in and disrupt the issuing banks.


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

April 2014
M T W T F S S
« Mar   May »
 123456
78910111213
14151617181920
21222324252627
282930  

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

Join 1,800 other followers


%d bloggers like this: