Data Storage: What do I do?
Apologies for the delay in posting the missive below…You may have noticed the press release that went out regarding Commerce Enrollment. It has kept me a bit busy. If you are interested in additional detail, my previous post entitled Commerce Enrollment: Save Time, Make Money, Add Value has about all the explanation you could desire. Should you desire more, you know how to find me…
With that said, let us away.
When discussing security, in particular securing bankcard transactions, the single most frequent question I encounter is “What do I do with the card information?” Before discussing that in great detail, a quick thought.
There is ongoing argument about the applicability of PCI compliance requirements to the merchant. At its simplest, if you store, process, or transmit cardholder information it is necessary to achieve PCI compliance. NOTE: Those are “or” statements…not “ands” That seems relatively straightforward…but is oft debated. I plan on expounding on this at a later date.
All of what I will be discussing below is a bit of expansion and detailed pontification on a document released by the PCI Security Standards Council entitled PCI Data Storage Do’s and Dont’s. The beauty of the document is its intentional simplicity. But it touches on many of the issues I hear frequently.
Firstly, I’m often asked “What is cardholder data?”
A technically accurate answer includes a discussion of the PAN, name, expiration date, information stored on mag stripe, potential chip data, PIN, as well as detailed discussion on the difference between cardholder data, authentication information and the requirement for protection.
At its simplest, the data you have to be concerned with is anything…nay, everything…that is on, or read from, the card. A subset of the data (cardholder) can be stored and must be protected. The other subset (sensitive authentication data) can never be stored.
The concept of storage is hotly debated. There is argument that storage is necessary…there is argument that it is not…to quote the document linked above:
But merchants should take note: Requirement 3 applies only if cardholder data is stored. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves.
Are there scenarios where storage is necessary? Yes. If there is interest I can discuss the scenarios at a later point. However, there are 2 key elements in the document that are worth mentioning…should you not desire to read it in its entirety.
Do verify that your payment applications comply with the Payment Application Data Security Standard (PA-DSS)
PA-DSS is frequently misunderstood. Simply, it is the software specific requirements that are meant to address the security of a payment application. If you are buying software…ask if it is compliant. If you are building software…ensure you aren’t just building securely but having it certified by a QSA.
Do understand where payment card data flows for the entire transaction process
An interesting, and complex, recommendation. The vast majority of merchants I know (including those who I talked to during my vacation) haven’t the foggiest about their infrastructure or software. They are concerned primarily with simply getting paid. Understandably…but each new breach will increase the focus on secure software and compliance.
It is a non-trivial topic. But, ultimately, there is a public assumption that merchants are protecting the data on cards to prevent theft. Similarly, there is an assumption from the merchant that the software they are using is secure.
So, what do you do with data?
If you a merchant, get compliant. And ask your software company about their compliance.
If you are a software company, educate. Educate. Educate! There is a unique opportunity to ensure that you become the “go to” for any merchant using your software who is interested in security.
If you are a payment service provider, get a plan in place. The time is now (rather, yesterday) to ensure you are working with your VARs to ensure compliance to meet the upcoming deadlines.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below. . .
November 14, 2008