The Green Sheet Online Edition
October 12, 2009 • Issue 09:10:01
Digging into PCI - Part 3:
Protecting stored cardholder data
In this installment of a multipart series, I will drill down on what is probably the most critical section of the Payment Card Industry (PCI) Data Security Standard (DSS): protecting stored cardholder data. I will discuss what the issues are, where the greatest challenges will be in practice and what can be done about them.
The third of the 12 PCI requirements is titled "Protecting Stored Cardholder Data" and is the first half of the section "Protect Cardholder Data" (the second half, to be dissected in my next article, talks about protecting that same data while it's in transit between computers).
While this is one of the most important sections of PCI, and the one where failures can have the most disastrous effects, it is fortunately not quite as technically demanding or complicated as the first two PCI requirement sets, and the challenges here can often either be avoided or solved more simply than the preceding ones.
The demands of Requirement 3
The focus of Requirement 3 is on stockpiles of cardholder data held by merchants (or processors, and so forth). These are an incredibly attractive target for thieves and hackers because the payoff can be enormous (huge volumes of data can be easily stored), merchant defenses are often weakest in this area and the attackers rarely need to do any highly demanding technical tricks such as on-the-fly interception of transactions.
To avoid widespread loss of cardholder data from attacks on stored data, Requirement 3 demands that merchants:
- Minimize the data they store (both the type of data and the amount), including never storing certain types of information such as the verification codes, PINs or encrypted PIN blocks
- Make sure that Primary Account Numbers (PANs) are not displayed or printed unnecessarily (for example, on receipts or in payment applications)
- Make sure that whenever sensitive cardholder data is stored, measures are taken to prevent outsiders from accessing that data improperly. This last phase of the requirement quickly becomes focused on encryption (because that is the most standard approach to protecting data at rest), but alternatives are also discussed such as truncation of PANs (that is to say, using and storing only the last four digits of account numbers, et cetera)
The challenges of Requirement 3
There are several challenges associated with complying with Requirement 3. These include:
- The direct challenges of implementing the encryption requirements laid out in the requirement.
- Dealing with the potential business disruption that can come with reducing data storage and encrypting the data. Merchants need to consider such questions as, Does my business currently use this stored cardholder data for customer relationship management or for managing chargebacks? What applications would be broken by this change? What other processes would need to change?
Note that I did not list the technical challenges of encrypting data as one of the main obstacles. This is because encryption is an area of technology in which almost no one, and certainly not merchants, should be trying to do anything too original or different.
With today's technology, merchants (and others) can and should treat cryptography as a tool to be applied, not as something that demands originality or high-tech skills.
Regarding implementation of encryption, most of the time merchants' biggest challenges will not be with the encryption technology itself, but rather with the procedural issues that come with it.
Requirement 3 devotes considerable space to talking about what are called "key management" procedures, and while these steps are not particularly complicated, they are new and strange to most merchants.
The point about business interruption is a clear example in which information technology security issues need to be considered in the broader business context: It's not just about technology; it's always about how technology impacts business operations.
What merchants need to do
For Requirement 3, more than any other section of PCI, merchants should try very hard to avoid the issues I just mentioned rather than defeat them. This means merchants should do everything possible to avoid storing customers' PANs or other sensitive card information.
Storing this type of data will always make merchants' lives significantly more risky and will always make their PCI burdens far more awkward and expensive.
The simplest way to see this is to look at merchants' Self-Assessment Questionnaire (SAQ) burdens: A merchant who stores cardholder data electronically is immediately dropped into the longest and most painful SAQ version, SAQ D, which leaves them with hundred of questions to answer when they might otherwise have only had to worry about a few dozen.
The first step in addressing Requirement 3, and one that too many merchants ignore, is for merchants to investigate their own systems to get clear insight into where they actually stand today.
- Do they know every place where their systems might be storing cardholder data?
- Are their payment applications or devices certified?
- Can these systems be misconfigured to store data without their knowing it?
Until merchants answer these questions, it's almost impossible for them to do the right thing, but once they do know the answers, it's at least possible to make correct, informed decisions.
The next step is to minimize the size of the issues that arise by reducing the volume of data stored to the absolute minimum.
Zero stored data is preferable, but every reduction is valuable: Losing 1,000 credit card numbers is bad, but it is a lot better than losing 10,000.
Only when that reduction has been made should merchants look at the next step: using encryption or something comparable to protect the data that is left.
The good news for merchants is the need for encryption has been around for a long time (since long before the PCI DSS was created), and there are plenty of products out there that do what is needed.
The best approach is to find a widely used encryption solution that fits a given merchant's specific business requirements and use it in the recommended way, paying attention to the procedural requirements as well as the technical ones.
What to do for your merchants
When I discussed the earlier PCI requirements in previous articles, it was clear that merchants would need significant, highly technical and merchant-specific help, making those issues very tough for ISOs and others to handle properly.
Requirement 3 is more important but a little easier to handle, since what merchants need here is less specific and entails more general PCI guidance such as help with setting priorities.
As always, though, ISOs, merchant level salespeople and other service providers need to provide their merchants with the necessary assistance or partner with a specialist security company that can provide it.
Doing so can turn PCI compliance from a stressful problem into a way for ISOs to deliver a highly visible value-add to merchants.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at firstname.lastname@example.org or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.