GS Logo
The Green Sheet, Inc

Please Log in

Banner Ad
View Archives

View PDF of this issue

Care to Share?


Table of Contents

Lead Story

Hard times expose vulnerable residuals

News

Industry Update

7-Eleven takes interchange issue to D.C.

Canadian debit shake-up

Two companies, two new security departments

Cyber thieves stealing from students

Features

How to leverage available technologies to manage risk and prevent fraud in RDC

Ed McLaughlin
RemoteDepositCapture.com

Research rundown

Selling Prepaid

Prepaid in brief

Vigilance is watchword in fraud prevention

Empowering the cash-compensated

Is PayPal a threat to prepaid?

Views

Portfolio conversions done right

Biff Matthews
CardWare International

The MLS and the ISO:
Cause for concern?

Brandes Elitch
CrossCheck Inc.

Education

Street SmartsSM:
Microbranding

Jon Perry and Vanessa Lang
888QuikRate.com

Reserve accounts and processor meltdowns

Adam Atlas
Attorney at Law

Digging into PCI - Part 3:
Protecting stored cardholder data

Tim Cranny
Panoptic Security Inc.

A practiced approach

Jeff Fortney
Clearent LLC

Revving up business with profit-controlled marketing

Daniel Wadleigh
Marketing Consultant

Company Profile

Payvision

New Products

Gateway as a service

paymentAccess
paymentAccess

First Data's new dynamic duo

First Data Secure Transaction Management
First Data Corp.

Inspiration

Little actions add up

Departments

Forum

Resource Guide

Datebook

Skyscraper Ad

The Green Sheet Online Edition

October 12, 2009  •  Issue 09:10:01

previous next

Digging into PCI - Part 3:
Protecting stored cardholder data

By Tim Cranny

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:

The challenges of Requirement 3

There are several challenges associated with complying with Requirement 3. These include:

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.

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 tim.cranny@panopticsecurity.com or 801-599 3454.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

previous next

Spotlight Innovators:

North American Bancard | Harbortouch | USAePay | IRISCRM.COM | Humboldt Merchant Services