Removal of Credit Card Data (Outsourced) from Network

[culps]

Hello. As you know the path to PCI compliance could be an expensive and resource intensive one. Why not just remove credit card data?

Can anyone tell me if they have successfully worked with a vendor to remove the credit card data from your applications on your network? I am looking speficially for a merchant who deals mostly with "card not present" transactions and re-occuring monthly transactions, as well as on-line transactions.

This can happen by replacing the credit card data with an alpha-numeric value which references the credit card data stored at the 3rd party. The 3rd party hosts and can also be a gateway for transactions. If you have a breach, there is no credit card data to be stolen.

This would relieve a lot if not all of the PCI burden because no credit card data would reside on your company internal systems.

If you have decided to go this route, can you please reply with success stories, gotchas, recommendations and an overall recommendation for someone going down this path?

What vendor did you use? What vendors would you recommend?

Thank you very much and have a great day!

[jbhall56]

Citibank/Suntrust and Chase Paymenttech have solutions available that do what you suggest which is to create a transaction identifier that is passed back to the merchant for reference and use at later times.

The reason these solutions are not used more often is that most merchants are using off-the-shelf software solutions and must wait for their vendor to update their software to support such a solution.

In addition, most merchants are not of a size to directly use such processors and therefore they are using processors or service providers that do not yet offer such a capability.

[cmark]

With regard to the solution you are asking about there are in fact several companies that provide 'tokens' back to the merchant instead of the cardholder data. This alone, however does not accomplish what you are asking.

To remove the burden of PCI compliance a company cannot store, transmit or process Cardholder Data as it is defined in the PCI DSS. Simply replacing a stored PAN with a token is only part of a solution. Any solution that is to remove the burden of PCI DSS must prohibit the merchant from transmiting cardholder data.

Using the definition of Cardholder Data this can be accomplished through the use of an encrypted mag stripe reader that uses DUKPT from the mag stripe reader where the decryption takes place at the processor/gateway etc.

If a solution simply transmits the data in a manner that is still considered Cardholder Data then the PCI DSS applies, although the company may have fewer requirements to comply with.

TrustCommerce' Trustee and other solutions, as well as Shift4's ForeGo accomplish this goal.

[culps]

Thank you for your responses. Remember, we are a "card not present" shop. There is no magnetic strip.

I have been talking to Trust Commerce and am very pleased so far, but my company would like for me to ensure we are exploring all possibilities and I was hoping for some experience stories and recommendations from experience.

Thanks!

[cmark]

Shannon,
Try Mercantec (Bill Tait is the CEO). They have a 'hosted payment' application that operates very nicely for small merchants.

In addition, I believe CyberSource has a product that is very similar called "fast track'. I believe they specialize in eCommerce acceptance and not all types of CNP.

Let me know if I can provide any other info...

[WeWontLoseItIPromise]

This approach is probably a good one for smaller operations; and also some larger operations I expect.

The caveat is, as has been mentioned, if your systems ever transmit CHD then you still have PCI to comply with on those systems. Unless you are willing to pollute your brand and customer experience by sending customers off to a 3rd party site to enter their credit card details, it's likely that you will be relying on a B2B connection between your web server and the 3rd party provider to send the PAN and receive the PAN-token.

It is very unfortunate that from a PCI perspective, this excellent technical solution, which hugely reduces the actual risk, still ties you into a substantial amount of compliance work. CHD is likely to be passing through a firewall, web server, switches and routers - which means you need to apply PCI DSS to those few components and "connected to" components IN FULL.

Unfortunately having a much reduced PCI scope, means your more likely to not pay sufficient attention to PCI compliance, which means you would probably fail an audit should you ever be audited following a possible breach.

[pciexpress]

This approach is probably a good one for smaller operations; and also some larger operations I expect.

The caveat is, as has been mentioned, if your systems ever transmit CHD then you still have PCI to comply with on those systems. Unless you are willing to pollute your brand and customer experience by sending customers off to a 3rd party site to enter their credit card details, it's likely that you will be relying on a B2B connection between your web server and the 3rd party provider to send the PAN and receive the PAN-token.

It is very unfortunate that from a PCI perspective, this excellent technical solution, which hugely reduces the actual risk, still ties you into a substantial amount of compliance work. CHD is likely to be passing through a firewall, web server, switches and routers - which means you need to apply PCI DSS to those few components and "connected to" components IN FULL.

Unfortunately having a much reduced PCI scope, means your more likely to not pay sufficient attention to PCI compliance, which means you would probably fail an audit should you ever be audited following a possible breach.

I disagree. This is a practical approach to reducing the costs associated with becoming (and staying) PCI compliant. Not only that, but the risk of being hacked is severely limited (which you pointed out).

I am surprised that more merchants aren't exploring semi-integrated or even non-integrated payment solutions. Just because the CHD traverses your network doesn't mean you'll end up doing the same work. Your assumptions are flawed: think of a brick and mortar chain, say with a dozen POS terminals per site, fifty sites total, that's 600 systems (not including back/front office servers) that you won't have to do the following (because you've greatly narrowed the PCI scope):

- maintain a retention/disposal policy (3.1)

- periodically change encryption keys (3.6.4) don't forget the "key custodians"

- install/maintain costly A/V software (5.1)

- ensure you have latest/greatest (production breaking) security patches (6.1)
(that don't necessarily apply to your operation anyway)

- identify all unique users (8.1) and maintain unique passwords and rotate every 90 days, don't forget: remove inactive users after 90 days

- restrict physical access to network jacks (9.1.3)

- establish process for linking all access to system components (again 600 systems); I dare you to read all of 10.1 and tell me this is nothing; check out 10.7: retain audit trail for one year with three-month on line availability

- see 11 - testing, another can of worms

Here's a few more thing's you'll avoid to a large degree at the very least:

- deal with all the wireless key rotation / firewalling / intrusion detection headaches, making you wish you would have pulled cat5 from day one

- use cameras to monitor sensitive areas (9.1.1); retain video for three months

- give tokens to visitors; setup "man traps"

- implement two factor authentication (which will drive your POS vendor's crazy btw)

- review custom code (6.3.7); code that may have nothing to do with payment processing, but so happens to "live" in the same bit-space

- do penetration scans

- the list is endless

Let's not forget: insure all this is working as planned and document every single bit of it.

Anyhow, let me elaborate on a much easier solution. It's really simple and it's not brilliant: put the payment terminals on their own physical (or virtual LAN) network (IP/serial/whatever, which uses a dedicated Internet connection or other Zone -> Internet, or lease line, whatever). Interface the terminal to the POS through a RS-xxx serial or USB connection and the POS is no longer part of the CHDE (the CHDE is limited to IP communications in case you don't know). If you are very paranoid you can establish one-way communications (tricky/kludgey/but possible). If PCI rules become more strict, you can use a directional parallel port interface or even a keyboard wedge. To make this all work you need a service provider that issues tokens and stores the transaction on their servers of course. You also need the support of your POS developer.

EVEN IF you decide not to use a third-party, at the very least you can limit the CHD to just one or few systems per site and issue your own tokens.

As a last resort, a totally non-integrated solution will still be cheaper for a great deal of merchants.

[PeterBell]

We're in the same situation except we're a software development company and can't justify getting PCI compliant for our hosting or PABP for our app. We're looking at http://www.braintreepaymentsolutions.com/. Have heard a couple of people say good withing about them, but have no personal experience. If you check them out please post a reply back with any thoughts/experiences!

[Brian Serra]

I second the previous post about Braintree. I have worked with them on a few client projects to eliminate the storage, processing and transmission of the PAN. They have a nice solution that will keep the PAN from ever touching your systems, thereby reducing or eliminating PCI scope.

[cmark]

Here are a list of companies that provide similar services...(not a complete list be should be enough to get started)

3Delta
EPX
MerchantLink
TrustCommerce
Shift4
BrainTree
NetworkMerchants

[Shift4SMS]

When you go through the list, you'll want to specifically look for solutions that remove all credit card data from being posted to your site. Even though you might do a straight pass through to the gateway API, if the hosting provider is not willing to become PCI compliant then you need to remove your entire site from scope.

From previous posters, it sounds like BrainTree has a solution that meets this requirement. Obviously we provide a solution as well (otherwise I would not be chiming in). A few on the list I know nothing about. I'm certain that a couple on the list do not have solutions that meet this requirement -- instead they only offer traditional tokenization where, at a minimum, card holder data is passed through your site to get the token. Using a traditional tokenization model, your site is fully in PCI scope. Do your research.

[lyricAKP]

I am surprised that more merchants aren't exploring semi-integrated or even non-integrated payment solutions. Just because the CHD traverses your network doesn't mean you'll end up doing the same work.

We're a large tier 1 merchant with thousands of retail stores and we're looking at doing this because the cost of being PCI compliant (and now PABP compliant) is something we see growing year after year. We've already spent millions. We're looking for ways to remove credit card processing from our POS registers completely if we can.

Matter of fact I'm on this site today to see if other retailers are starting to move in this direction or not.

[pcigal]

Here are a list of companies that provide similar services...(not a complete list be should be enough to get started)

3Delta
EPX
MerchantLink
TrustCommerce
Shift4
BrainTree
NetworkMerchants

I looked on Visa's website.. and it doesn't appear BrainTree is a certified CISP. But they are on the PCI Security Standards Council. Could that be right? If they aren't a CISP, and your processing bank is Visa, I'd look elsewhere.

Chris, please correct me if I'm wrong.

[Shift4SMS]

I looked on Visa's website.. and it doesn't appear BrainTree is a certified CISP. But they are on the PCI Security Standards Council.I have not looked but they might be in the same boat we are in that Visa has two lists. One is the PABP Validated Payment Applications; the other is the CISP List of Compliant Service Providers. You most likely checked the first. Our primary service offering is not on the PABP list and it confuses people all the time and we have to refer them to the provider list.

Hope this helps.

[cmark]

BrainTree appears to white-label another offering.

[pcigal]

I have not looked but they might be in the same boat we are in that Visa has two lists. One is the PABP Validated Payment Applications; the other is the CISP List of Compliant Service Providers. You most likely checked the first. Our primary service offering is not on the PABP list and it confuses people all the time and we have to refer them to the provider list.

Hope this helps.

They are not on either list (PABP or CISP).
Chris - Whose product are they White-labeling?

[cmark]

I don't know for sure. If they actually had their own offering they would be required to be registered as a Visa Agent and listed on the Visa website. Since they are not then my thought is that the solution is being white labeled.