Fix inconsistencies about what falls into a PCI SAQ A classification.

[rickmanelius]

Matt White left some great feedback here http://soundpostmedia.com/article/drupal-pci-compliance-white-paper%E2%80%94officially-released#comment-976073132

In the earlier portion of the paper, we allude to the possibility of PCI SAQ A if one uses a HPP, but later we still provide caveats and other recommendations. The latter portions are more accurate so the verbiage in the earlier part should match said recommendations.

[mattfff]

Matt White here... Wandered back around and realized I never responded to this!

So I'm still stuck on the fact that it seems like SAQ-A is simply not achievable by any means, regardless if you use Paypal Express or any HPP system, which makes SAQ-A seem entirely useless... I'm really just trying to understand if that is indeed the case, or if cart software (not uniquely DC or UC, but any cart software) is automatically kicked into SAQ-C simply because most can be easily reconfigured via a compromised admin account to store and provide card #'s to an intruder, without actual source code modifications? I.e. in UC you could put it into card debug mode (not sure if this is still an option, though?), which would allow a hacker to intercept card #'s...

Thanks again! I'm happy to help think through any re-wording, I'm just trying to get at the logic behind the categorization so that I can better conceptualize the split between A and C...

[rickmanelius]

Hi Matt. The nuances with respect to this particular issue are worthy of another article, which I'm already start to draft.

I think we can both agree that merchant-managed solutions fall into SAQ-C by the very nature that the credit cards pass through the server and therefore the merchant is responsible for the security of the entire CDE. The issue is the promises of shared-management solutions, where the credit card data is technically never sent to the merchants server and therefore one could make the argument that the merchant server is completely removed from the CDE and therefore one is completely outsourced into SAQ A.

The issue with all shared-management solutions (direct post, hosted payment page, and hosted iframe) is that all of them are still vulnerable based on what is displayed by Drupal. The rule of thumb I've been using that if it's possible to modify a configuration, code, or server in order to open up a vulnerability, then the CDE includes those components and then you're back to SAQ C.

The most obvious example is direct post because one could install a javascript keylogger on the page that in no way interrupted the actual customer experience while harvesting cards. And it doesn't have to be installed by an external hacker. If someone working within a Drupal shop wanted to, they could intentionally install this without anyone knowing. The mere fact that either a hacker or an insider could modify the Drupal app code to harvest the numbers means that SAQ-C should apply because it's up to the merchant to ensure their code has not been compromised, misconfigured, etc.

Where things get very grey is in the case of Hosted Payment Pages and Hosted iFrame solutions. With Hosted Payment Pages, a hacker would have to be so elaborate as to make a spoofed version of paypal that could handle all the redirects back and forth. It's not to say that it's impossible, but it's extremely difficult and would take a lot more effort to pull off versus just scraping cards as they went through.

If it were up to me, I would still consider HPP as SAQ-A (and perhaps, if we pressed the PCI council for a more definitive answer, they would be more clear about it). However, it appears that they lump all shared-management solutions in the same bucket as still being vulnerable and therefore within SAQ-C.

That all said, I still think it's substantially easier to achieve SAQ-C when using shared-management solutions because you're mainly focused on those few attack points (they either have to have a keylogger on the page, change the HPP redirect, or embed in alternative iframe).

I'll reach out to my colleagues to discuss this further and see if we can improve the verbiage within this section of the white paper and as part of a followup article. Again, I wish it was more black and white (and more favorable to the merchant), but as of now the best answer I can give is that all shared-management solutions still fall into SAQ-C. When we were in the earlier stages of the paper, I was trying to push back on that conclusion, which is why that internal discrepancy still exists.

Either way, this issue will be resolved prior to the v1.1 release!

[rickmanelius]

Given some conversations from the last few months, I have some additional ideas on this and I'll add to the 1.1 milestone. Thanks, again, for your thoughtfulness on this matter.