FOR PCI, THE FUTURE IS NOW

How to comply with the global standard without breaking the bank

BY SANDRA GITTLEN

It has been more than five years since the heavyweights in the payment card industry banded together to develop common stan­dards to protect users from fraud. Since then, the standards have gone global, expanding beyond merchants to include their application providers as well, and becoming more prescrip­tive.

More importantly, organizations of all sizes and industries have recognized that if they accept card-based transactions, then the Payment Card Industry Data Security Standard (PCI DSS) applies to them. This has meant taking a closer look at how they control access to sensi­tive customer data.

Unfortunately, all too often this “closer look” has resulted in last-minute fire drills to satisfy periodic audits or a decision to risk fines rather than spend money on compliance. “Audits can be expensive and resource-intensive. To some, they represent budget and productiv­ity that could be better spent elsewhere,” says Scott Crawford, research director at Enterprise Management Associates in Boulder, Colo.

As the PCI DSS and its sister standards con­tinue to evolve and gain momentum, organiza­tions will have to make compliance into their everyday operations in order to eliminate fire drills, contain costs, keep current customers, and attract new ones

Reasonable Risk Management

When the PCI Security Standards Council (PCI SSC) was formed, its goal was to create a uni­fied outline of the minimum security necessary to transmit, process and store cardholder infor­mation. Some institutions had their own guide­lines, but the industry felt it would be more ef­fective for them to join forces on a single stan­dard. Version 1.0 of the PCI DSS was released in late 2004.

“At the time, and still today, payment card in­formation is a high-profile target. The credit card issuers felt it was their responsibility to be arbiters of safe practices for that informa­tion,” Crawford says. The issuers also wanted to reduce their own risk as each time a breach occurred they were left holding the bag. “They had to raise the bar for merchants to protect themselves as well,” he says.

Over the next few years, the PCI SSC studied the impact of the standard and gathered feed­back, which led to the more clarified version 1.1. In late 2008, the council released version 1.2 of the standard to address newer threats, then released version 1.2.1 a year later to allow for future updates.

Today’s standard features 12 requirements that fall under six main topics: building and main­taining a secure network; protecting cardholder data; maintaining a vulnerability management program; implementing strong access control measures; regularly monitoring and testing net­works; and maintaining an information security policy.

While the overall framework has stayed the same since the original version, more recent ef­forts have taken into account technological ad­vances. “By version 1.2.1, the standard matured to include requirements for securing Web ap­plication environments, which is how most pay­ment card transactions are handled these days,” Crawford says.

Clearing the high bar

Not only did the PCI DSS outline requirements for securing cardholder data and the networks on which that information resides, it also broke merchants into tiers according to the number of transactions they handled each year. Level 1 merchants are defined as processing over 6 million transactions per year, Level 2 between 1 million and 6 million, Level 3 between 20,000 and 1 million, and Level 4 less than 20,000.

The higher up you are, the more intense your compliance requirements become. For example, Level 1 merchants must be audited annually by a qualified security assessor as well as quar­terly network scans. Level 2 and 3 merchants must do annual self-assessments and quarterly network scans. For Level 4 merchants, annual self-assessments are recommended rather than required.

For some companies, meeting these require­ments can be costly and labor-intensive. Gene Kim, co-founder and CTO of Portland, Ore.- based Tripwire, says, “A compliance manager at a large retailer told me he mobilizes over 600 of his workforce, spending tens of millions of dol­lars in labor, to get his stores ready for auditors.”

Kim accurately calls this approach unsustain­able. “That’s a horrible amount of time and money to spend on compliance. The worst part is as soon as he passes one audit, he has to turn around and do it six months later,” he says.

Even more unsettling is that once the PCI auditors leave or the self-assessment is com­plete, these “fire-drill” organizations undo all the controls they put in place for the review. “Compliance is supposed to be a report of how controls work in daily operations, but that is not reflected in most audits,” Kim says.

In fact, treating PCI compliance as a checklist creates a false sense of security. The audits are only point-in-time snapshots of security and, if taken as anything else, could open a company up to data leaks or other critical threats. “This industry has enough history under its belt to know better. The evidence is overwhelming that you can’t just try to be compliant once a year or even once a quarter. The process has to be on­going,” says Ed Rarick, Tripwire’s PCI evangelist.

If companies have seen compliance as onerous thus far, Rarick says it’s only going to get worse as PCI is bound to broaden. For instance, more stringent assessments and network scanning demands could extend to lower-level merchants and requirements could eventually include vir­tualization.

Lower-level merchants have fewer staff to deal with periodic assessments and scans so taking a fire drill or checklist approach puts an incred­ible burden on already limited resources. Trying to develop makeshift controls for technologies such as virtualization just to pass a compli­ance test is a waste of IT time and money—and since PCI is often just one of several compliance mandates companies have to meet, there is not much of either to spare.

Common sense: Becoming continuously compliant

To avoid these traps and to ensure a secure posture, organizations of all sizes should blend compliance into ongoing operations.

“There shouldn’t be a heroic effort to comply with standards. Security, by definition, involves safeguarding confidential information, protect­ing against fraud, ensuring systems are avail­able so you can generate revenue, and making sure there are no errors in the stack. When you do all these things, you inherently wind up ful­filling the intent of all major regulatory and in­dustry compliance regulations,” Kim says.

With continuous compliance, compliance be­comes the natural outcome of a sound security strategy, according to Crawford. The benefit, when it comes to PCI, is that as new versions of the standard emerge, organizations won’t have to scramble to check their controls; they’ll al­ready be compliant.

PCI, like many mandates, requires organizations to verify the soundness of user authorization, change and configuration management con­trols. For instance, you have to prove that only authorized users are able to access, configure and update servers and storage holding sensi­tive customer information. More than half of the 200 requirements in the PCI DSS prescribe some sort of change process or configuration control, Rarick says.

If you were practicing point-in-time compliance, this would be impossible as you wouldn’t have an end-to-end view of the network. While you might be able to tell that something changed, you would have no view of what the changes were, where they occurred and who made them. If auditors had questions, your team would have to manually cull through event logs and configuration files to track down policy infractions. “If you’re looking through more than 25,000 settings in a single report and some percentage is failing, how do you pick out which ones to fix?” Rarick says.

Automation makes the difference

More importantly, changes in configurations or unauthorized access in between audits would probably go undetected, opening you up to data breaches. This is the exact situation PCI was designed to prevent.

As proof, consider the Hannaford Bros. Co. data breach. The grocer suffered an attack that ex­posed four million credit and debit cards. The intrusion began in 2007, but was not discovered until early 2008. This happened despite the fact that the company had been certified PCI-compliant.

With continuous compliance, an organiza­tion uses automation to develop and maintain a known secure state for your infrastructure based on PCI and other requirements. Every time a physical or virtual server, physical or virtual switch, or other network device is de­ployed, it can be checked against a golden im­age before it is allowed online.