4 ms·

Your competitor's merchant processor should have an audit process where this is discovered. It is unlikely that reporting it to said merchant processor will re

Your competitor's merchant processor should have an audit process where this is discovered. It is unlikely that reporting it to said merchant processor will result in account termination since if your competitor is not at the level where an audit is required, he/she is simply filling out a form. Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today! https://www.google.com/#safe=off&q=add%20to%20cart%20site%3Aherokuapp.com https://www.google.com/#safe=off&q=add%20to%20cart%20site%3A...

spacefight 12y ago
"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.
51Cards 12y ago
Didn't PCI-DSS 3.0 go into effect January 1, 2014? Edit: The new questionnaires went into effect today. The previous year's were still applicable through last year.
matthewarkin 12y ago
Re: PCI-DSS 3 Uh no, if you qualify for PCI SAQ A, you are fine (so if you link off site, or use an iframe to collect info - like Stripe Checkout). If you used a direct post method or some JS tokenization, its likely that you know fall under the PCI SAQ A-EP rules which would require PCI compliant hosting.
- grandalf 12y ago
  Not sure where you got that idea. The entire purpose of SAQ A-EP is to bring the hosting site into PCI scope. Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js? This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
  - JimmyL 12y ago
    It would be trivial, which is one of the problems with A-EP when you look at it from the POV of someone who knows something about web security. As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/Understanding...: Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
    - grandalf 12y ago
      Right. Which is why SAQ A-EP was invented -- to prevent merchants from gaining compliance based on the loophole that they are using a js library or offsite link to collect payment.
      - matthewarkin 12y ago
verystealthy 12y ago
The Heroku situation is more nuanced than it seems. This is not a PCI DSS 3.0 issue. The thing is that Heroku provides a platform and this platform is not PCI DSS compliant (1.21, 2.0, 3.0, you name it) and Heroku is not willing to let QSAs verify their compliance on behalf of their clients (and, yes, I have first hand experience with this very scenario). There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go. Let's say you use a payment gateway and cardholder data never touches your Heroku environment (e.g. you're redirected to Payment Gateway XYZ's app to enter your payment information). In this case your Heroku environment would be potentially out of scope, as you're not transmitting, storing or processing cardholder data. If you're handling cardholder data in any capacity in your Heroku environment, then, yes, you're in for a big compliance surprise.
- grandalf 12y ago
  > Heroku is not willing to let QSAs verify their compliance on behalf of their clients This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes. > There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go Not true, see below: 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-...
  - verystealthy 12y ago
    >This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes. Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat. >Not true, see below: Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
    - grandalf 12y ago
      > what if you're not eligible for a self-assessment If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes. The QSA will make sure that all the required systems and processes are in place and sign off on it. PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.

spacefight 12y ago

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

51Cards 12y ago

Didn't PCI-DSS 3.0 go into effect January 1, 2014? Edit: The new questionnaires went into effect today. The previous year's were still applicable through last year.

matthewarkin 12y ago

Re: PCI-DSS 3 Uh no, if you qualify for PCI SAQ A, you are fine (so if you link off site, or use an iframe to collect info - like Stripe Checkout). If you used a direct post method or some JS tokenization, its likely that you know fall under the PCI SAQ A-EP rules which would require PCI compliant hosting.

grandalf 12y ago
Not sure where you got that idea. The entire purpose of SAQ A-EP is to bring the hosting site into PCI scope. Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js? This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
- JimmyL 12y ago
  It would be trivial, which is one of the problems with A-EP when you look at it from the POV of someone who knows something about web security. As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/Understanding...: Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
  - grandalf 12y ago
    Right. Which is why SAQ A-EP was invented -- to prevent merchants from gaining compliance based on the loophole that they are using a js library or offsite link to collect payment.
    - matthewarkin 12y ago

verystealthy 12y ago

The Heroku situation is more nuanced than it seems. This is not a PCI DSS 3.0 issue. The thing is that Heroku provides a platform and this platform is not PCI DSS compliant (1.21, 2.0, 3.0, you name it) and Heroku is not willing to let QSAs verify their compliance on behalf of their clients (and, yes, I have first hand experience with this very scenario). There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go. Let's say you use a payment gateway and cardholder data never touches your Heroku environment (e.g. you're redirected to Payment Gateway XYZ's app to enter your payment information). In this case your Heroku environment would be potentially out of scope, as you're not transmitting, storing or processing cardholder data. If you're handling cardholder data in any capacity in your Heroku environment, then, yes, you're in for a big compliance surprise.

grandalf 12y ago
> Heroku is not willing to let QSAs verify their compliance on behalf of their clients This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes. > There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go Not true, see below: 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-...
- verystealthy 12y ago
  >This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes. Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat. >Not true, see below: Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
  - grandalf 12y ago
    > what if you're not eligible for a self-assessment If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes. The QSA will make sure that all the required systems and processes are in place and sign off on it. PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.