"Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today!"
Can you elaborate a bit on that? Thank you.
Can you elaborate a bit on that? Thank you.
https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p...
http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-f...
If you want to use a PAAS and want to be able to pass any kind of infrastructure audit, the fastest path is probably via Aptible (YC S14)
With that in mind, this discussion only applies (right now) to sites who have never yet filled out a PCI form. For sites which have, it only applies when their annual re-certification comes up.
So for those sites which have to certify against 3.0, can they run on a PAAS and take payments? It depends, specifically on how the credit card number is entered. The general rule of thumb is that if the form in which the number is entered is delivered by the host (the PAAS), you'll have to use SAQ A-EP (which is extensive, and you don't want). if the form is delivered by the vendor (like Stripe) and injected into the page, you can still use SAQ A (which is small, and what you want).
How about Stripe? I'm not sure if they've released a PCI 3.0 version of Stripe.js yet, although they clearly will. Likewise, I'm not sure about the others, but I think it's safe to assume that they'll release versions similarly (the techniques to do this are well-known).
Lastly, I'm not a QSA, and this isn't advice.
The entire point of SAQ A-EP is to cover the edge case that was letting people use offsite, iframe, and js checkouts. It puts the web server that is doing the hosting of the site in general into PCI scope.
So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck.
If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.
No, including payment pages hosted by a third party:
https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...
The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type:
$ heroku document:network
The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth.
So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information...
PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.
As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid.
If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.
Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc.
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP.
If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)
Otherwise, the merchant still appears to come into scope, because at some point they must redirect their customer to the externally hosted payment pages or load the externally hosted checkout system from the merchant's site, one way or another.
So basically, it looks like anyone who has any sort of shopping site they run themselves (as opposed to hosting entirely on a third party marketplace site) but who uses Stripe, PayPal, a hosted card payment page offered by their bank, or literally any other third party card payment system, will fall into scope and be required to operate and audit the entire relevant part of their web site according to the PCI DSS 3 rules. But that is obviously far beyond the reasonable capabilities of most merchants who might find themselves in that position, either technically or commercially.
Edit: In short, when you wrote:
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
I haven't yet found anything that says why such a site doesn't fall into scope now just like everyone else. Indeed, the new rules seem to be clearly aimed at such sites as I read them.
The issue is that Heroku, because of its lack of transparency about what is actually going on in its routing mesh, is not necessarily secure, and it's not possible to just download a list of relevant firewall rules, etc. (the way you could if you set up a site on Amazon VPC).
SAQ A has always required the merchant using his/her own servers to provide some documentation and do some security scanning, the new thing with SAQ A-EP is that it no longer allows for the loophole of using a PAAS and claiming that simply b/c it is not managed by the e-commerce shop that it is out of scope.
I think you are dramatically underestimating how many very small businesses, private individuals, bootstrapped start-ups, etc. would be caught by this.
For one perspective, consider that in the current EU VAT mess, some estimates have suggested that over 250,000 microbusinesses are selling on-line in the UK alone right now (or at least were until the end of last year). Many of them are side businesses, either earning a little bit of extra money for selling anything from music to knitting patterns, or second businesses run by folks who already have full-time jobs. Of course some of them are entirely built on marketplace sites, but plenty aren't, they just know enough web design to set up a basic site and slap something like a PayPal or Stripe Checkout button on the page.
To a first approximation, none of those businesses is going to comply with the new rules, despite operating their own site and taking money on-line via credit card. They wouldn't even know what the long words meant. Even the outliers who do, either because they're in an IT field or maybe if they're a bit larger and have slightly more resources, probably don't have the time and money available to comply.
These are ma and pa shops, family businesses, side businesses run in people's spare time, start-ups trying to gain traction, and so on. They don't have their own networking team. They don't even have a dedicated IT guy. And they surely can't afford to double the number of servers they use just to avoid the redirect issue, to pay specialist consultants to figure out all the details of their almost certainly outsourced IT infrastructure, whether or not the infrastructure provider makes available the necessary data in some form, and to spend hours if not days figuring out how to self-certify under the new PCI-DSS rules.
Avoiding that kind of nonsense is, after all, why these organisations use services like PayPal or Stripe or the hosted pages from their bank in the first place.
> I think you are dramatically underestimating how many very small businesses, private individuals, bootstrapped start-ups, etc. would be caught by this.
This is not new, it has been part of SAQ A for quite some time.