By convention, "Ask HN" posts don't have links; put the link to the PCI standard in the text of your post.
The short answer to "how should my startup deal with PCI DSS" is "don't accept cardholder information". Outsource the handling and processing of credit card information. There is a "self-attestation" questionairre the PCI-powers-that-be apparently want you to fill out even though you're not handling credit cards. Uh, fill it out.
What you should not do is pay for consultants to checklist your app if you're not taking credit card numbers directly. If you are collecting cards, you already knew you were in for a whole big bucket of drama.
tptacek has this right. Also, to clarify an all too common misconception, if you TAKE credit cards on your site, you STILL need to be PCI compliant, even if you don't STORE credit card numbers. Not storing them gets you out of a few requirements, but you still have to be compliant with most of them.
Nobody's going to want to say 'No' for fear of incriminating themselves. However, this is a serious issue. These changes went into effect in July, and I have seen very few hosting companies that offer PCI DSS compliant options. If more people were trying to get up to compliance, I suspect there'd be more of a market for those services.
I'm currently implementing our PCI compliance (i work in Germany so it might be a little different here). We used to temporarily save the credit credit data until we got an ok from the payment provider and afterwards mask all data. Now everything is off site: we only hand over the amount and wait until we get the okay.
We were in my last job. Never again if I can help it.
The codebase was close to a decade old, and a lot of customers were subscribed via a recurring payment feature where our payment processor held their CC#. So transitioning away from ever seeing cardholder data was the least economic option for us.
If you don't store credit card information locally, then it's pretty easy to be PCI-compliant. Just make sure everything's secured and only a few people have access, pay for security sweeps, and you're good.
If you're storing credit card numbers, things get much more complicated.
If you don't store it you get to skip Req 3 basically. You still have most of the other 11 Requirements to worry about... Multi-key strong encryption and key rotation isn't that hard... The policies, documentation, and other areas are harder imho.
We did our whole review 2 weeks ago and made some changes to our privacy policy to be all up to par. We only use PayPal for processing online payments so it's a lot easier to be PCI DSS compliant but still good thing to do!
It's still all under review at our agency. This is a little out of my area of expertise, but it seems like offloading all processing to a gateway doesn't cut it anymore, which is kind of a big deal.
* I don't store process or transmit any cardholder data on my premises, but rely entirely on third party services to handle these functions.
* The third parties I use for handling storage, processing, and transmission of cardholder data is PCI certified.
* I don't store any cardholder data in electronic format.
* What physical cardholder data I store is only paper reports and copies of receipts and is never received electronically?
Yes? Then you can self-attest (presumably at any time, such as when asked, but dont' quote me) compliance. You'll sign a document that says:
* I read the PCI DSS (sorry).
* The above conditions about not handling cardholder data are true.
* (9.6) All paper and electronic media that contain cardholder data is physically secure.
* (9.7a) Strict control is maintained over internal and external distribution of any media containing cardholder information.
* (9.7b) Controls include (9.7.1) such media being "classified" so everyone knows its confidential and (9.7.2) when transported it's sent by courier or other trackable secure carrier.
* (9.8) Processes and procedures are in place to ensure management approval before moving any media containing cardholder data from a secure area.
* (9.9) Strict control is maintained over storage and access of media containing cardholder data.
* (9.10) Cardholder-carrying media is destroyed as soon as it is no longer need for legal or business reasons, and (9.10.1) hardcopy material is cross-cut shredded, incinerated, staked through the heart, chained in silver, buried under a full moon in a Scottish peat bog, and pulped so that cardholder data cannot be reconstructed.
* (12.8) Cardholder data once shared with service providers are secured with policies and procedures that:
* (12.8.1) Include keeping (yes wait for it) a list of service providers
* (12.8.2) You have written agreements with those providers that say "yes we know what PCI means"
* (12.8.3) You have some due diligence process for choosing providers that know what PCI is.
* (12.8.4) You have a policy for monitoring those providers PCI compliance so if they suddenly decide PCI is a big joke you'll stop funnelling cards to them.
That's it. No app pentests required. No firewalls installed. More than half of it is about physical storage of cardholder records which you aren't doing because that's crazy.
I don't store process or transmit any cardholder data on my premises, but rely entirely on third party services to handle these functions.
Lots of people on this forum seem to misread this one.
If cardholder data is POSTed to your server, and then you send it on to a third party, then you're receiving and transmitting, and you've got to be in compliance.
I hope I was clear about this. You're right. Cardholder data is radioactive. It can't touch your servers. If it does, I have no sympathy for you: you're in for a lot of pain, some of it reasonable and a lot of it not.
Don't touch credit card numbers. Not even to hot-potato it. If it touches you, it leaves a stain, and removing it will cost you high tens of thousands of dollars.
So, you need to pay tens of thousands of dollars in order to be a Reputable Business that doesn't disconcert your customers with a third-party checkout page. Got it.
Pretty much:( Usually lots of tens of thousands. Luckily PayPal and Google Checkout are getting more popular, but still, it just feels sort of ghetto, imho. The vast majority of small eCommerce sites out there are almost certain not PCI compliant, or at least not properly audited by an accredited 3rd party.
It's sort of like speeding, but with bigger tickets. Most people do it, but it's risky.
If cardholder data is POSTed to your server, and then you send it on to a third party, then you're receiving and transmitting, and you've got to be in compliance.
Why isn't anyone offering a thin wrapper service that lets you host a payment form yourself (giving you complete control of the page), and then POST the result to the service which just forwards to one of the major processors?
You get full control of the form, and your server never transmits CC data, so it's out of scope for PCI compliance.
I probably didn't help in describing the idea clearly, but who do you mean by "which you host"?
My thought process was that it would work like this:
Merchant - Hosts a a payment form, but it POSTs to the service's server basically <form method="post" action="https ://someservice.com">
Service - Receives the POST and forwards it on to Auth.NET, Paypal Pro, or whoever the Merchant is using to process transactions. The user is redirected back to merchantwebsite.com with appropriate response data.
Are you saying the merchant website would still need to be PCI compliant or just the Service's?
I definitely understand that the service would have to be PCI compliant. But it seems like it'd be a valuable service for a number of small e-commerce providers to essentially outsource online PCI compliance with minimal downside.
EDIT: While I haven't used them, my understanding is that Braintree offers pretty much exactly this service, except that they require that they provide your merchant account and act as your payment processor.
While I can go for hours talking about the actual technical risks here, I'm less firm about how a PCI auditor is going to interpret any specific thing you do. We don't PCI audit; we find and fix vulnerabilities in software.
Having said that:
The technical risk of you hosting HTML that POST's via HTTPS somewhere else is that any input that influences any dynamic component of the page on which the form is hosted could alter the "action" attribute of the form to point somewhere else, without it even being detectable in the page source.
You can say that about any chain of pages, including in-app page flows all the way through Google SERPs, but it's a particularly severe risk on the actual page that asks for the credit card number, since there are no macro-level cues a user has as to whether the page is valid or not.
OWASP is making more noise about things like "insecure redirects" for, among other things, this exact scenario. Expect the "host the HTML FORM that asks for the credit card number and send it to the payment processor" technique to run afoul of PCI DSS any year now.
Braintree offers this. We call it Transparent Redirect. We've worked with several QSA assessors who have verified that by using our TR API merchants do not fall in scope for the requirements for transmission of credit card data and can therefore complete SAQ A to become PCI compliant. http://www.braintreepaymentsolutions.com/credit-card-storage...
The short answer to "how should my startup deal with PCI DSS" is "don't accept cardholder information". Outsource the handling and processing of credit card information. There is a "self-attestation" questionairre the PCI-powers-that-be apparently want you to fill out even though you're not handling credit cards. Uh, fill it out.
What you should not do is pay for consultants to checklist your app if you're not taking credit card numbers directly. If you are collecting cards, you already knew you were in for a whole big bucket of drama.