PCI Compliance - What would you pay for peace of mind?
There is a lot of misunderstanding about PCI compliance, but basically it is a security standard for anyone who "stores, processes or transmits" cardholder data. So, for example, if a user fills out a form with their credit card information, that form is posted to your server, you use that to call auth.net and then discard the information (don't store it) you are STILL REQUIRED to be PCI compliant. If the cardholder data touches your server, the standard applies. In practice, creating a PCI compliant environment is a five to six figure undertaking making it impractical for most smaller merchants. So, what is the answer?
The answer is to somehow get out of storing, processing and transmitting cardholder data and there are two ways to get this done.
The simplest solution is to use Paypal or Google checkout or the like so you don't even host the credit card form. You don't have control over look and feel or the details of the back end of the checkout flow, so it isn't ideal, but it's a quick and easy solution for any merchants that can live with it.
If your clients won't accept that (they want to have their own checkout form), the solution is something like Braintrees secure vault with transparent redirect. Basically, the form is sent to their server, they get the cardholder data, store it, process it and return you a response with the status of the payment and a secure vault key for future charges (if you need that). You then display the appropriate response page. This is fairly easy to integrate with, visually seamless (the user never appears to leave your site) and removes the storing, processing or transmiting of the cardholder data as it never touches your servers.
Unfortunately, when I tried to sign a client up with Braintree this morning I found their minimum volume is now $1M a year which excludes a lot of smaller merchants and I've been unable to find another provider (auth.net has a CIM product which is their secure vault offering, but because they don't offer the transparent redirect, you still have to meet PCI standards for your web server, negating most of the benefits of the solution).
Long before Braintree got into this business, we were considering creaing a credit card lockbox service to do just what they do - probably $25-$50 a month with a nominal per transaction fee. It would offer the same basic kind of service as Braintree, but would be available to smaller merchants.
I know many clients don't want to pay extra for this, but I think that will change over time, and I see the real opportunity as follows. As a web developer, if you create a solution that ISN'T PCI compliant (and you probably are right now), given the widespread publicity, what might be your professional liability for the sites you're creating? Imagine if we could provide a packet you'd give to all of your clients basically saying "we recommend you do this to avoid PCI compliance liability with your website. You don't have to do this, but we do want you to sign a form to say we recommended this and you declined". In that way you're more likely to be covered for not providing a PCI compliant solution, and of course, some of the clients would sign up for the service. It wouldn't be a revenue center for developers - more of a liability reduction as well as offering your clients a chance to have a safer solution for a relatively low cost.
What do you think? Would anyone be interested? Any thoughts on improving the approach? Any ideas on what you think would be a fair price for the clients to pay?
Any input appreciated!
I ask because, just scanning the 12 requirements, it seems all of my customers are covered by
1) not storing CC details
2) our managed hosting account that takes care of all the encryption, virus protection, etc.
Just wondering. Six figures seems kind of large. We're into the 3 figure range averaged out by client, I think. Of course, I may not understand what all compliance entails from reading the 12 steps at the PCI compliance website.
Thanks for bringing this up. It's something we all need to think about.
Have a look point by point at the requirements and then google for some information about the implementation requirements. I need to check with the latest version, but the last time I looked at the requirements and the guidance available for implementing them, the requirements were pretty extensive. As for your managed hosting account, I'd drop a line to the provider and just ask them to drop you an email certifying that your hosting complies with all of the relevant PCI standards. Let me know what response you get :-)
I guess all that matters is that it be substantially more than the net present value of spending (say) $50/mo indefinitely, so as long as it's a high four figure cost the math would add up . . .
>> Any thoughts on improving the approach?
Also offer a package with only a per transaction fee, (i.e. no monthly fee).
It would work out more expensive like-for-like vs the monthly one, but allows for people to support more occasional sales (e.g. one-off pieces of art) without potentially losing money for a monthly subscription.
Interesting that you should bring this up. The project I'm working on right now is an e-commerce project. We dealt with this same issue - to outsource or not.
Like you said, PayPal and others are the traditional way. I haven't tried Braintree, but we use a company formerly known as Lecayla. They are the Web 2.0/SaaS version, and offer a Web Services API (for those who want to do it themselves and handle PCI) or an IFrame version which gives you control over CSS, but all the processing is done on their side (with their fields). They then dump the XML over.
There are some warts, but overall its getting there. I think you'll find a lot of providers entering this space. But they are slow, and their product, well, not ripe...
So I'm saying, yes, I would definitely encourage you to enter this space. We can talk offline on how SaaS providers are making $$$.
>Build and Maintain a Secure Network
>Requirement 1: Install and maintain a firewall configuration to protect cardholder data
We have a firewall set up on the box(es). It's an extra hundred or so dollars a month compared to not having one, split among many clients.
>Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Doing so is silly. Clearly, we've changed the passwords. Cost is nothing, except a few moments of time - not enough to charge for.
>Protect Cardholder Data
>Requirement 3: Protect stored cardholder data
We don't store it, so we don't need to protect "stored cardholder data." We do protect addresses and phone numbers, at the application level, the box level, the DB level, and the network level.
>Requirement 4: Encrypt transmission of cardholder data across open, public networks
We use SSL to transmit this data. Some clients use a shared certificate, where the cost is negligible. Others have their own certificates, where the cost may be 120 dollars or so. I think that might be for 2 years, but lets just say it's 1.
>Maintain a Vulnerability Management Program
>Requirement 5: Use and regularly update anti-virus software
We have updated anti-virus software. The cost is negligible.
>Requirement 6: Develop and maintain secure systems and applications
Taken care of during the development of the system, so the cost is included in the app itself. It's pretty standard security. I don't know if they mean something special, which wouldn't normally be a part of any app.
>Implement Strong Access Control Measures
>Requirement 7: Restrict access to cardholder data by business need-to-know
Done as part of development, using roles based authentication.
>Requirement 8: Assign a unique ID to each person with computer access
No one but us has access to the computer. Everyone has their own account to access the application. They may decide to share it at their peril. Of course, we advise them not to do so.
There's also not much cost involved in setting up accounts. 2 minutes to do, and the customer can do it themselves or ask us to. We probably wouldn't bother billing for it unless it was a common occurrence.
>Requirement 9: Restrict physical access to cardholder data
No CC numbers are stored. I do not even have physical access to the servers, only rackspace does and I don't think it costs extra.
Regularly Monitor and Test Networks
>Requirement 10: Track and monitor all access to network resources and cardholder data
All access is logged. I am not the admin, so they may or may not receive warnings as to possible attacks. I believe they probably do, as they notified us recently of attempted SQL injection. I'm not sure what "monitor" means. Should we be scouring the logs daily?
>Requirement 11: Regularly test security systems and processes
I'll admit that this is foreign to me. I have no idea what is involved.
>Maintain an Information Security Policy
>Requirement 12: Maintain a policy that addresses information security
We could probably stand to put the policy in writing. Perhaps a few hundred dollars if we want to hire an attorney - a one time cost which averages to zero per client over time.
Those are my thoughts when I say I don't understand how the cost can grow significantly. Hope that helps explain my POV so that hopefully, (if you care to) you can explain where you think our ideas are divergent.
That said, the system you're talking about interests me. If there was a one-stop shop for compliance, that wasn't a PITA to integrate with and we'd be guaranteed compliance, I think a lot of people could take comfort in that.
That said, your description of braintree sounds just like available connections to authorize net or paypal. I won't say everyone uses those methods, but they are available.
I think you need to check through the specs in a little more detail. In my experience, it's kinda like saying "I secure my web apps - I have a secure certificate" when the actual requirements are for an active Intrusion Detection System, the ability to log all accesses to non-rewritable media, etc. In my experience getting a PCI compliant system is way more involved than the kind of 101 stuff you're discussing.
Also, it's not the same as auth.net or paypal. Paypal is a great solution, but you don't control the look and feel of the checkout which is a no-no for some clients. Auth.net, the card info passes through your server (assuming using AIM), so you still have to comply with PCI as you're transmiting cardholder data.
(a) Become PCI compliant - very expensive/time consuming
(b) Don't become PCI compliant - default approach. Works right up until you get hacked/sued
(c) Use a third party provider who certifies they are PCI compliant - then it isn't your problem as when the issuing bank comes along you can say you did the right thing, we show we were audited and providing we were compliant, everyone shrugs their shoulders and admits nobody can truly stop a hacker, but none of us are on the line for it.
Will drop you a line offline . . .
One example: even if you don't "store" CC info, you have to make sure form posts don't "log" that info, which is easy for a web server, CF, or even products like FusionDebug/Reactor to do. It can start to get pretty crazy.
@Peter,
Yup, iFrames are VERY icky.
I turned down some freelance work a little while back because of all the stuff they wanted to comply with. I told them it would take me more time to read the documents than to build the application. =) Of course, my lack of free time was an issue as well...
I'm no lawyer, but I would guess PCI compliance would not by itself mitigate legal liabilty. I am absolutely certain the FDIC would not insure losses in this case.
If I were to pay a 3rd party for this service, no question part of the agreement would be that the party would assume all liability for lawsuits... otherwise what benefit am I actually getting for the service?
Peter, I'm not saying there isn't a valid business model here, but the bottom line is what you would really be trying to sell is freedom from liability, and the only way to ensure that is to assume the liability yourself.
Gus
Thanks very much for the feedback.
I wouldn't be interested in selling freedom from liability as I'd imagine the cost of the insurance to provide that would be a lot greater than the price point I'd be charging. However, under the PCI standards there is language clarifying benefits (in terms of liability) for meeting the PCi standards. The purpose of this service would be to allow someone to remove the PCI liabilities from their website by using a third party that had certified that they were PCI compliant. Risk removal clearly has benefits, but so does risk reduction. This would be a reduction of risk, not a removal of it.
We used ScanAlert - they give you a list of things you need to do to become compliant and also run hack tests against all your servers to find vulnerabilities.
The main things were:
encrypt cc data
do not save cvv code
firewalls/virus on all machines with access
delete private data from any backup/dev servers
have procedures in place for security
Most other things like physical security, using ssl, and monitor/testing should all be standard.
Also, i've read of a device (Barracuda?) that is a firewall/filter that "instantly" makes you PCI Compliant.
And in the end, we were only as compliant as what Sammy was discussing. I'm not sure how well our "ghetto compliance" would have held up if there had been a breach and MasterCard or VISA had come knocking.
I guess this is a long way of me saying that, if I were developing an e-commerce system for a small or medium-sized client, I'd be interested in an outsourced solution. Compliance is expensive not only in money, but also in the time it takes to monitor and enforce.
@Seth, yeah, even little things like having to have the separate db server behind the DMZ are a pain. I do believe the standards have been pared down recently, but speaking with people who've been through the process it still seems a huge amount of work . . .
I'm seeing developers still believing that all they need to do is spend $300 with McAfee to become PCI compliant or buy a firewall or encrypt the cc data and with so much mis-information it's just too high a burden for a small dev shop to explain what it really takes to be PCI compliant. More help from the issuing banks and PCI would be appreciated!
Use a third-party API such as Moneris eSelect Plus. Works with .NET, PHP and other popular languages.
All you have to do, as a developer, is host your site on a PCI-Compliant host. To insure that the host and the customer's browser are secure, purchase a secure certificate from DigiCert, VeriSign, GeoTrust or any top trustees and assign the certificate to your website's domain/server. Your website (or at least the payment form) must be hosted on HTTPS (port 443) protocol.
The customer types sensitive information into their browser and posts it. The browser and the application host encrypt and communicate the information according to the secure certificate. From there, the web-host uses the API to transmit the information to the payment gateway.
The API returns an instant response with ALOT of useful information. You don't even have to process the payment the same day. You can issue pre-authorizations, captures, refunds, voids, recurring payments all without ever touching sensitive information.
Any other system that uses the API to modify the original request must pass a PCI compliance scan by a PCI complaint and trusted authority such as COMODO. What's involved in the scan? You provide the address of the server you'd like to scan, and it checks to see how secure the system is by checking which services are running on it. If you have a mail host, ftp host, http/https host all running on the same server, you're likely to fail. To pass the scan, run only 1 service (https on port 443). If you try to trick the service by blocking access to the host, you'll fail because the server must be accessible and be running at least 1 hosted service. When you pass, you get a nice report and certificate. (This is done annually).
IF there was ever a breach by decrypting 512-bit cyphers (some even more complex depending on the certificate and browser) and somehow gaining access to sensitive information, you can still be covered by the secure-certificate issuer and any agreements that the host provides adding up to approximately $50M in insurance and that's not mentioning the amount of liability assumed by the service provider.