I left a comment on Doug Hughes’ blog and thought it would be worth repeating here because I know that I didn’t hear about PCI DSS early enough. And I figure if I didn’t hear about it, then other heads-down developers may also have been missing this. Let’s get it out of the way:
If you store, process or transmit credit card details, you are subject to the PCI DSS created by the card brands!
You can get an overview from Wikipedia, read the full specification and requirements, check the PCI Demystified blog for helpful posts and participate in the PCI Auditors forums.
Understand compliance is not optional. If you process even a single card, you’re considered a level 4 merchant and depending on which card brands you accept, the compliance target is October 1st, 2007.
The only case in which you might not be subject to PCI DSS is if you do “the Paypal”. E.g., you redirect your paying users off to a third party who handles processing and then redirects them back to your site where you handle post-payment processing. Since few serious e-commerce companies accept this limitation, there are few of us for whom compliance will be optional.
The good news is that the DSS is largely best practices and common sense in network and software security but as a compliance standard, it has been taken to an occasional level of insanity and will cost you significant time and/or money to implement. Let me just welcome you to two-factor authentication. For 2008, the DSS 1.1 is going to require either an application firewall or a code review. Yikes!
Would it be helpful to post my notes on hardware and (open source) software we’re evaluating to handle each of the 12 requirements?
All Categories from Feedburner
Josen Ruiseco said:
on September 6, 2007 at 11:08 pm
Yes…
Peter Bell said:
on September 7, 2007 at 5:12 am
We’ve been looking into this for a couple of years now. There was some press recently noting that Mastercard and Visa are backpeddling on compliance even for level 1 merchants because so few of them are actually in compliance.
If this is followed through it is going to fundamentally change the business of developing and hosting small e-commerce sites. For example, how many people now run Miva with MySQL on a single shared server? That won’t fly with PCI. It’s going to substantially raise the bar for providing such services (especially with even the cheapest single location audits running around $15k).
It will definitely be interesting to see how this plays out, but I believe in future that more people will offload the storage of credit card information just because PCI compliance is too onerous for most smaller businesses.
We’re actually thinking of developing a “lockbox” service to solve this problem – there are some out there, but nothing compelling yet.
brian said:
on September 7, 2007 at 9:51 am
@Peter – no kidding. What struck me most about this is that it’s a deal killer for 90% of the small e-commerce guys out there. It’s a huge win for Google Checkout/Paypal because it makes it more cost and resource-prohibitive to do it on your own. The alternative is to use the gateway-hosted payment pages where you redirect there and back but I am not a fan of these for a long number of reasons on the user experience side.
It’s important to note that until you’re a level 1 merchant, you are only required to SELF-CERTIFY so audit costs are not an issue. However, should one take this as an opportunity to fudge the results and later have a breach, you’re on the hook not only for fines ($50k+) but also the cost of reissuing every compromised credit card (@ $35/pop). Although there is backpeddling on compliance deadlines, there is no backpeddling on the fines: compliance will happen for everyone because there are going to be some high-profile breaches that wind up bankrupting an acquirer.
For lockbox services, I came across TrustCommerce the other day which does exactly this. I will post my notes in an additional entry to give people a starting point in their own research.
Mike said:
on September 21, 2007 at 4:25 am
Hey, thank you for the link, but you hit the wrong PCI forum. (ok, I’m biased.)
If you want answers to your questions from the people who train the auditors then mosey on over to: http://forum.aegenis.com/
This is the forum associated with PCIAnswers.com
Danny Lieberman said:
on October 2, 2007 at 11:20 am
There is absolutely NO requirement for an expensive $15k external audit for Level 2-4 merchants (1 million or less transactions a year).
There is a great deal of confusion about the idea behind the standard – namely, improving cardholder data security and not compliance for compliance sake.
If you’re a small merchant – you can do a self-assessment and be pro-active about security as well as cost-effective.
We have found that Practical Threat Analysis is a good way to understand the threats to a business and do a PCI DSS 1.1 self-assessment and keep it up t date. The application is available as a free download for all merchants – and we’d love to hear feedback from folks – you can download PTA PCI here – http://www.software.co.il/content/view/214/1/
Best regards
Danny
Mike said:
on October 2, 2007 at 3:12 pm
The PCI Security Standards Council sets the rules and the card brands (Visa, MC, AE, Discover, JCB) handle the enforcement. If a merchant wants to know what they need for compliance and validation they should ask their acquirer and/or go to the respective card brand websites.
Danny Lieberman said:
on October 3, 2007 at 2:16 am
Mike
That’s right – the requirements are available for download from the VISA and MC Web sites.
Having said that – the PCI DSS 1.1 requirements are confusing and a mixed bag of countermeasures. Some are very sensible things like modifying vendor provided passwords alongside of some very archaic things like using anti-virus to mitigate “threats”.
This can result in a PCI auditor taking advantage of a merchant and overstocking them with security technology and professional services.
We know of one client who purchased a database firewall at the recommendation of their auditors (KPMG). They spent over Euro 100k on technology over 9 months ago that is still not fully implemented and for what – to prevent users from accessing the Oracle database with the production dba password. They could have and should have separated their test, development, staging and production environments and prevented developers from connecting to the production server with a simple firewall rule. That could have been implemented with a cheap Linux box running Centos and iptables for basically nothing.
The case with small merchants is that on one hand they don’t have the budget nor the mentality to spend although they have the most to lose in a security breach and as a collective group constitute the most significant source of vulnerabilities in the payment card network.
Clearly – there is a business case both for the card associations AND the small merchant to improve their security.
I’m skeptical about MS Word checklists and Euro15/month network scans as a means of attaining this goal.
I think it’s an insult to the intelligence of any decent business owner/manager. As an alternative, we suggest that the small merchant use Practical Threat Analysis to examine his own business situation, mitigate threats and comply.
This is what PCI is about really, at the end of the day.