4 ms·

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

grandalf 12y ago
more details here: https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p... http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-for-online-merchants/#.VKWeQIrF8Sg 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)
- nsxwolf 12y ago
  Still not sure. What counts, and what doesn't? Does this mean that any service you host on Heroku has to be free? You can't integrate Stripe and accept payments?
  - JimmyL 12y ago
    The main thing to remember about the deadline today is that what's changed is the forms needed for certification. If you're already certified, nothing changes today - but when you do your annual re-certification, you'll need to use the 3.0 forms (and not the 2.0 ones). Until such point, you're still certified and compliant. If you're not yet already certified, you'll need to use the 3.0 forms; this is what most people are referring to. 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.
    - grandalf 12y ago
      I think you're incorrect. An attacker could simply change the code on your server to make the form submit to a malicious location. The user would never know there was an attack going on. 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.
      - Silhouette 12y ago
        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.
        grandalf 12y ago
        > beyond directly linking to an entire page hosted by a third party No, including payment pages hosted by a third party: https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-e-commerce-merchants-using-payment-redirects/ 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 and it should spit out a csv with ingress and egress ports, virtual server IPs, etc. That would cover half of the requirement from SAQ A-EP. 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.
  - grandalf 12y ago
    PCI covers the handling of payment information. So any service on Heroku can't handle payment data unless in the form of a token. Hosting a form that posts to a 3rd party host is what has now become "in scope" with v3.0 of PCI DSS.

grandalf 12y ago

more details here: https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p... http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-for-online-merchants/#.VKWeQIrF8Sg 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)

nsxwolf 12y ago
Still not sure. What counts, and what doesn't? Does this mean that any service you host on Heroku has to be free? You can't integrate Stripe and accept payments?
- JimmyL 12y ago
  The main thing to remember about the deadline today is that what's changed is the forms needed for certification. If you're already certified, nothing changes today - but when you do your annual re-certification, you'll need to use the 3.0 forms (and not the 2.0 ones). Until such point, you're still certified and compliant. If you're not yet already certified, you'll need to use the 3.0 forms; this is what most people are referring to. 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.
  - grandalf 12y ago
    I think you're incorrect. An attacker could simply change the code on your server to make the form submit to a malicious location. The user would never know there was an attack going on. 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.
    - Silhouette 12y ago
      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.
      - grandalf 12y ago
        > beyond directly linking to an entire page hosted by a third party No, including payment pages hosted by a third party: https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-e-commerce-merchants-using-payment-redirects/ 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 and it should spit out a csv with ingress and egress ports, virtual server IPs, etc. That would cover half of the requirement from SAQ A-EP. 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.
- grandalf 12y ago
  PCI covers the handling of payment information. So any service on Heroku can't handle payment data unless in the form of a token. Hosting a form that posts to a 3rd party host is what has now become "in scope" with v3.0 of PCI DSS.