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 standards 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 prescriptive.
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 sensitive 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 productivity 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 continue to evolve and gain momentum, organizations 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 unified outline of the minimum security necessary to transmit, process and store cardholder information. Some institutions had their own guidelines, but the industry felt it would be more effective for them to join forces on a single standard. Version 1.0 of the PCI DSS was released in late 2004.
“At the time, and still today, payment card information is a high-profile target. The credit card issuers felt it was their responsibility to be arbiters of safe practices for that information,” 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 feedback, 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 maintaining a secure network; protecting cardholder data; maintaining a vulnerability management program; implementing strong access control measures; regularly monitoring and testing networks; and maintaining an information security policy.
While the overall framework has stayed the same since the original version, more recent efforts have taken into account technological advances. “By version 1.2.1, the standard matured to include requirements for securing Web application environments, which is how most payment 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 quarterly 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 requirements 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 dollars in labor, to get his stores ready for auditors.”
Kim accurately calls this approach unsustainable. “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 complete, 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 ongoing,” 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 virtualization.
Lower-level merchants have fewer staff to deal with periodic assessments and scans so taking a fire drill or checklist approach puts an incredible burden on already limited resources. Trying to develop makeshift controls for technologies such as virtualization just to pass a compliance 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, protecting against fraud, ensuring systems are available 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 fulfilling the intent of all major regulatory and industry compliance regulations,” Kim says.
With continuous compliance, compliance becomes 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 already be compliant.
PCI, like many mandates, requires organizations to verify the soundness of user authorization, change and configuration management controls. For instance, you have to prove that only authorized users are able to access, configure and update servers and storage holding sensitive 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 exposed 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 organization 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 deployed, it can be checked against a golden image before it is allowed online.
IT can perform frequent system scans to ensure no critical files have been maliciously or accidentally altered. If something has changed, it can easily be returned to a previously approved configuration. This process wards off vulnerabilities that can occur between audits.
Continuous compliance has the added benefit of streamlining and speeding PCI audits, which means you’ll spend less manpower and money dealing with them. Also, because there is a common look and feel to the process, everyone (auditors, executives, staff and IT) is on the same page, saving a great deal of time.
“You can use continuous compliance to figure out how to intelligently and securely make changes, do releases and create reports. It moves compliance from a multi-month, 600-employee project to an ongoing effort where you can quickly and easily pull the right reports for auditors,” Kim says.