Let’s talk about being an e-commerce company. We have this fun thing called PCI DSS that has a few hundred security and procedural requirements for anyone taking credit cards. Then we have third party integrations like product fulfillment that require us, as the intermediary, to pass around the credit card number to complete the transaction.
So here’s the catch-22; you want to use a secure vault option that eliminates the “storage, transmission or processing” of credit cards from your network so that PCI DSS does not meaningfully impact you. But you need the credit card number in order to ship it off to your fulfillment or third-party partner. What to do?
The answer is a secure proxy combined with secure remote data storage. We need to be able to transparently put sensitive data like credit card numbers and expiration dates into an encrypted vault without the number traversing our network. This part exists today. But we also need the ability to tell the PCI DSS-compliant server to take that credit card number and send it somewhere else, without the number ever coming back to our network.
In order to scale, the proxy must not be customized on an API-by-API basis. Rather it should be generic and be customized by configuration. As a user of the secure proxy, I would define my API endpoint via a secure web interface (Thanks to Peter Bell for ideas here). This lets the proxy operator grab my endpoint and add an appropriate outbound firewall rule. Specifying the endpoint prevents a compromised server from arbitrarily sending data off to hackerz.ru. Each of my proxy requests would include at least three options:
- GET or POST
- Request format like SOAP, REST, RPC-XML, etc.
- Key/value pairs to send along as parameters
With this proxy, I could relay my sensitive data to any server on the Internet facilitating integration with vendors who won’t or can’t write their own integrations. A payment gateway, a third-party fulfillment center, an airline booking engine, whatever. I could specify placeholders for data to be pulled from the secure vault to be included in the request. The secure proxy API would let us control a remote PCI DSS-compliant server putting our entire network out of scope and reducing our compliance requirements to obtaining a certificate from the secure proxy operator to satisfy requirement 12.8.
For startups and small organizations, this approach would protect sensitive data for a minimum of cost and effort. Compliance is a major time and money suck for any organization but especially so for small teams who are trying to focus on building a successful business. For large organizations with ample internal resources, this approach may still be valuable as it offloads the liability associated with sensitive data to a third party. Oh doesn’t TJ MAXX wish they had one of these?
Thoughts? Anyone else need one of these?
All Categories from Feedburner
Jimmy said:
on October 7, 2008 at 9:41 am
As you explained, dealing with PCI DSS is a big big pain in the butt. When building the credit card processing for Music Arsenal, rather than dealing with all the rules of PCI DSS and potentially putting myself at lots of risk I decided to use Authorize.nets Customer Information Manager.
When I do a monthly charge to a customer instead of using authnets clunky recurring billing I’m able to pass an encrypted customer and card id to the CIM and have their server do all the charging and authorization.
I built a CFC to manage the integration with that and I’ll get it up on RIAForge one of these days soon. (Along with the Eventful CFC which is coming along nicely!)
Peter Bell said:
on October 8, 2008 at 1:24 am
@Brin, I want one.
@Jimmy, I have bad news and bad news for you. We’re also looking at using auth.net’s CIM, but it does NOT mean your website is out of scope. You’ve handled the “store part”, but because your network transmits cardholder data, your website and web hosting environment are IN SCOPE for PCI DSS. The only way to keep your website out of scope is for your clients to post their form the with cc data to someone elses website. If they post the data to your site, even if you just pass it immediately to auth.net and then kill it, your entire website is in scope and will have to be PCI compliant.
Welcome to the wonderful world of PCI
Jimmy said:
on October 8, 2008 at 8:04 am
Griiiiiiiipes! I spoke with my merchant company and understood everything was on the up and up. Looks like I need to do some work.
Now, at Brian…. add me to the list of people who would be interested in that proxy.
brian said:
on October 8, 2008 at 11:28 am
@Jimmy – now you’re feeling the pain. The catch that most people don’t understand is that if your network or systems EVER sees a full credit card number in plain text, you are subject to PCI DSS. It doesn’t matter if you process and forget, or quickly ship it off to a third party, etc. If the number traverses your network, you’re on the hook.
I’m got something brewing that might alleviate this for a lot of people… we’ll see!
Henry said:
on October 9, 2008 at 3:45 pm
Who will come knock your door and check if you’re PCI DSS compliant?
Brian said:
on October 9, 2008 at 3:56 pm
@Henry – today, if you’re a small merchant, no one. Within the next few years, I suspect all merchant levels are going to be required to submit their report on compliance. The average level 3 and 4 merchant will not have even the foggiest clue here. Failure to comply will result in fines and ultimately loss of your merchant account.
In the mean time, if credit cards are compromised from your system (which the banks can tell by cross-referencing where cards have been used and finding the common point), then you will be subject to LARGE fines which your merchant agreement already states you agree to pay. Most small businesses will go bankrupt since general E&O insurance will generally not cover hacking losses (if you have E&O to start with).