Test Environment

[SVK24]

I was wondering about a test environment that meets PCI requirements:

Apparently several large comapanies are using virtualization and/or their DR site as test environment where copies of actual live data are being used for test purposes.

I dont think that this violates the PCI (or even security) requirements. Any ideas or experience with these scenarios?

[jonassono]

Requirement 6.3.4 specifically states that production data (live PANs) are not to be used for development or testing.

In cases where the merchant's development or testing teams require a valid PAN for testing, we recommend the merchant obtain a legitimate credit card (or multiple card brands as needed) to be used expressly for this purpose, i.e. verifying the PAN and for end-to-end testing of card transaction processing logic including authorizations, payments, returns/chargebacks and other miscellaneous adjustments.

We have previously confirmed the acceptance of this approach with acquirers.

[dherrald]

Here are my thoughts and experiences. My background is as a gateway service provider and as a payment application vendor.

If you are referring to testing a DR site to ensure that it is functionally capable of taking over in case of a real disaster then I believe it is OK to use live data including live cardholder data so long as you have all PCI required controls in place for the DR environment. DR environments are part of the card data environment so they must have equivalent controls in place.

If you are referring to testing as part of the software development life cycle... Requirement 6.3.4 prohibits using production data (live PANs) for testing or development and the associated testing procedure allows for "sanitization" before test/development use. This is cut and dry, no live pans can be used in test/dev environments. Also beware that sanitization can be difficult to actually achieve. I've always found it to be more work than originally anticipated. For this reason I don't do it much for test/dev purposes and instead require developers to generate their own test data with test card data from the processors. Sometimes not a popular stance with the developers but...
I've seen attempts to use a DR environment as a dev/test environment (and vice versa) and it's pretty much impossible to do it in a PCI compliant manner. Even if you can creatively envision it "on paper", my experience is it's impossible as a practical matter. I wouldn't go there. Others may have other opinions.

Also, regarding virtualization--it's just a tool. The tool can be used in a compliant manner or a non-compliant manner. I believe that the fuss over how to make virtualized infrastructure compliant is generally over-blown (it's really not that hard) but others have other opinions. Different post ;-)

Hope this helps.

[jonassono]

Here are my thoughts and experiences. My background is as a gateway service provider and as a payment application vendor.

If you are referring to testing a DR site to ensure that it is functionally capable of taking over in case of a real disaster then I believe it is OK to use live data including live cardholder data so long as you have all PCI required controls in place for the DR environment. DR environments are part of the card data environment so they must have equivalent controls in place. A bit of a stretch, but why or under what circumstances would you need a copy of the live production data to test the backup site?

If you are referring to testing as part of the software development life cycle... Requirement 6.3.4 prohibits using production data (live PANs) for testing or development and the associated testing procedure allows for "sanitization" before test/development use. This is cut and dry, no live pans can be used in test/dev environments. Also beware that sanitization can be difficult to actually achieve. I've always found it to be more work than originally anticipated. For this reason I don't do it much for test/dev purposes and instead require developers to generate their own test data with test card data from the processors. Sometimes not a popular stance with the developers but...
I've seen attempts to use a DR environment as a dev/test environment (and vice versa) and it's pretty much impossible to do it in a PCI compliant manner. Even if you can creatively envision it "on paper", my experience is it's impossible as a practical matter. I wouldn't go there. Others may have other opinions. Regardless of the site (DR site, development, unit testing, functional testing, or performance testing) 6.3.4 still applies - Do not use production data (live PANs) for testing.

Also, regarding virtualization--it's just a tool. The tool can be used in a compliant manner or a non-compliant manner. I believe that the fuss over how to make virtualized infrastructure compliant is generally over-blown (it's really not that hard) but others have other opinions. Different post ;-)

Hope this helps.

Just my post-thoughts - very freudian!!

[El_Luke]

Of course, there are exceptions to every rule.
The intention behind the no-live-PANs-in-test rule was to protect your customer's data. They don't want a compromise of a test system to lead to the compromise of multiple cards. If I remember correctly, you could use your personal card or a company card, with the idea being that if those got compromised - its your own fault whereas if it was a customers they would have had no control over it. There are also PAN's you can get from your bank that will work for authorization but won't have any value to them. You could also get some real cards for testing but just keep them at a very low value limit so if they were stolen no one would care much. You're never going to get that answer from the cardbrands because they have to stick to the letter of their standard, but it will be ok as the main thing they care about, fraud capability, is limited to none.

[jonassono]

Of course, there are exceptions to every rule.
The intention behind the no-live-PANs-in-test rule was to protect your customer's data. They don't want a compromise of a test system to lead to the compromise of multiple cards. If I remember correctly, you could use your personal card or a company card, with the idea being that if those got compromised - its your own fault whereas if it was a customers they would have had no control over it. There are also PAN's you can get from your bank that will work for authorization but won't have any value to them. You could also get some real cards for testing but just keep them at a very low value limit so if they were stolen no one would care much. You're never going to get that answer from the cardbrands because they have to stick to the letter of their standard, but it will be ok as the main thing they care about, fraud capability, is limited to none.

Great explanation and advice!! Solves all of the attendant problems of trying to test card processing application logic with live cardholder data.

Every so often about 8 - 10 years back, I used get my Visa statement and it would have a bunch of weird charges and compensating reversals (error correction) that I couldn't explain - it was no huge sweat as they balanced to nil. Can't help wondering if that wasn't the result of tests being performed with live cardholder data.

[ADail]

Functionally speaking, I've been told it's alright to use live PANs in dev, IF dev has the same level of security as production.

What does bother me, however, is that we often get mainframe flat files from the issuer to do a test, and it's full of live PANs. Issuers are exempt from PCI DSS, but we are not.. so they're giving us a big ole' hot potato to deal with.

[jonassono]

Functionally speaking, I've been told it's alright to use live PANs in dev, IF dev has the same level of security as production. I suggest you refer who ever told you that to PCI-DSS Requirement 6.3.4 - it should be reasonably clear that live PANs are not to be used for any form of testing.

What does bother me, however, is that we often get mainframe flat files from the issuer to do a test, and it's full of live PANs. Issuers are exempt from PCI DSS, but we are not.. so they're giving us a big ole' hot potato to deal with. I'm curious to know why an issuer would give you their proprietary cardholder data to perform a test. What kind of test do they want you to perform with their live data??

[ADail]

We sold our proptietary card to them, so it's really a co-branded product (even though they technically own the accounts now, but they sub-contract portions to a 3rd party for some cards) and we are between the Acquirer and the sub-merchants as part of settlement. Usually it has to do with new products and BIN ranges, or changes they want to make to "our" cards for new issues after a specific date...etc.

[jonassono]

As an issuer, perhaps they have little or no concern about PCI-DSS compliance. I would opine, however, that they would have real concerns about the security and uses of their live cardholder information.

Using their live cardholder information for testing could be very damaging to their reputation should a whole collection of testing transactions show up on their cardholder's statements.

Even allowing for an explanation such as "Please ignore all the wierd transactions on your statement as we are testing some new functionality", I suspect the average cardholder would be really steamed.

Bizarre!!