Published: 07 Sep 2010
PCI DSS has become one of the most controversial standards on the books. Many argue that PCI DSS has made great inroads in improving credit card security. Others contend the standard is a distraction from true security, and that the effort is too prescriptive, confusing, and artificially sets the bar for security and compliance too low. This fall, the PCI Security Standards Council is expected release a series of updates to the standard.
PCI VIRTUALIZATION AND IN-SCOPE GUIDANCE COMING
What can retailers, merchants and others who handle credit card data expect? Most are hoping for a number of updates that will remove perceived overly subjective interpretations, questions of scope and answer long-awaited virtualization security questions. In August, the PCI SSC released a high-level summary of changes to appear in PCI DSS 2.0. A detailed summary and pre-release version of the standard is scheduled for release in September with a final version published Oct. 28. According to Bob Russo general manager, PCI Security Standards Council, most of the updates this year will come in the form of standard clarifications, as well as the release of guidance.
The virtualization update, led by the virtualization special interest group (SIG) is expected to clarify existing ambiguity around how merchants can utilize virtualization technologies and still maintain compliance.
"The council does need to provide a supplementary guide for virtualization as there has been plenty of confusion in the marketplace," says Anton Chuvakin, Ph.D, independent security consultant and co-author of PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. "Section 2.2.1 states that there can only be one function per server. If the council means physical server, then that would, in effect, ban virtualization. But it could also mean virtual servers; and in that case merchants can use one physical server running separate, but dedicated virtual servers," he says. "But they have yet to officially explain what is allowed, and how that all fits together."
How is such haziness in the standard currently clarified should retailers deploy virtualization? Those that do must assert to their Qualified Security Assessor (QSA) that each virtual machine is, in fact, a dedicated server. And, unfortunately, the outcome boils down to the interpretation of the standard by their individual QSA.
"Some merchants are moving forward and adopting virtualization, while others have put off embracing it around payment systems," says Josh Corman, research director, for research firm 451 Group's enterprise security practice. But the question remains why, with virtualization hitting stride back in 2006, has it taken the PCI Security Standards Council so long to address virtualization?
"Everyone initially thought virtualization guidance was coming out in October 2008, and it didn't. We had to wait another two years to adopt cost savings technology? That is just ridiculous," says Corman.
Scott Crawford, managing research director, Enterprise Management Associates, however, argues that developing the appropriate level of virtualization security controls isn't as straightforward as it may seem. "Virtualization technology, for example, can be deployed in a number of different ways. And some approaches are vendor- or implementation-specific to boot. Defining an approach that is too prescriptive may not address the full scope of the issue, or may add substantially to the sheer volume of requirements if regulators attempt to cover all of the potential bases," he warns.
Another highly anticipated update this year is expected to be clarification surrounding what systems are in, and out, or PCI DSS regulatory scope. "I would argue some of the clarifications coming from the scoping SIG are going to be the most important," says Michael Dahn, PCI principal at Verizon Business, and member of both the virtualization and scoping SIGs. "That's where people find the most gray areas under the mandate." Generally, PCI DSS scope is defined as any system that stores or processes unencrypted credit card data. Sounds clear-cut. Yet while a business may separate all systems that store or process credit card data, they still may use a shared Active Directory, or perhaps a shared administrative LAN to manage other areas of their infrastructure as well as those systems dedicated to payments.
"There's nothing to say that the Active Directory or administrative LANs are in scope, but there's nothing to say that they aren't, either. And it's a gray area that continuously comes up," Dahn says.
According to Russo, proposed changes will recommend that merchants use data discovery tools or data leakage protection technology to discover where cardholder data resides on their systems prior to a PCI assessment.
Proposed changes also address secure coding and vulnerability discovery, including a recommendation that merchants apply a risk-based approach for addressing vulnerabilities.
What is not expected to be in the update is any further guidance when it comes to cloud computing. "Ultimately, it is the merchant's responsibility to make sure that they have the right contracts in place, and make certain that their providers are working in a compliant manner," says Russo. "As part of their due diligence, merchants need to make sure they are dealing with someone reputable," he adds. "The council will continue to rely on section 12.8, which governs the use of third-party providers, and states that the merchant must ensure that the provider is compliant to PCI DSS," says Chuvakin.
For many, that's not enough clarity, and will continue to be a sticking point for some time to come. "There are too many vagaries associated with making sure service providers are compliant," says Gartner IT security, fraud, and PCI compliance analyst Avivah Litan. "What's needed and warranted is specific advice on how to make sure service providers are compliant, and what that means to the compliance status of the service providers."
|For Better or Worse?|
Experts debate whether PCI has improved credit card security
Is PCI DSS a merchant security savior, or antagonist? Strong arguments are made on both sides of the debate. Some contend prior to PCI DSS that retailers and payment processors did hardly anything to ensure credit card security. "PCI has improved security," says Gartner IT security, fraud, and PCI compliance analyst Avivah Litan. "Unfortunately, compliance typically drives implementation of security solutions and the fact that merchants have had to comply with PCI has forced them to pay attention to the security in their environments and work on improving it," she adds.
That was certainly the spirit of PCI DSS when, by 2004, it became clear that when it came to securing credit card data something had to improve. Roughly a year after California enacted its data breach notification act, SB 1386, reports of breached credit card and other financial information was beginning to flow furiously. Among the breaches in that era included one of the largest of all time, CardSystems Solutions, encompassing 40 million credit card records in 2005.
Going into effect in 2004, the Payment Card Industry Data Security Standard (PCI DSS) aimed to stem the tide of credit card breaches and lower the costs of fraud on the industry and consumers. PCI's 12 discrete security requirements establish common procedures and security practices for handling, processing, storing and transmitting credit card data. Those mandates call on retailers and payment processors to create a risk management program that includes: segmenting cardholder data; encryption; vulnerability management; running antivirus software and intrusion detection systems; among other requirements.
However, many merchants argue that the standard has been confusing to comply with, and excessively expensive to maintain. That's a contention many PCI DSS experts disagree.
"I say PCI DSS 'done wrong' is usually expensive," says Anton Chuvakin, Ph.D, independent security consultant and co-author of PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. "For instance, securing a flat network is very hard and expensive, and securing card data on legacy systems is expensive. In those scenarios, it is usually cheaper to reconsider business processes that utilize card data and streamline them," he says.
Scientific data as to whether those efforts have increased overall merchant security is difficult, if not impossible, to uncover. However, according to the DataLoss Database, run by the Open Security Foundation, there were 24 incidents involving credit card data in 2005, while for all of 2009 there were 86.
"There's no doubt that the frequency of credit card breaches, and the number of cards involved in those breaches, as been increasing," says Josh Corman, research director, for research firm 451 Group's enterprise security practice. Still, that data doesn't necessarily mean that PCI DSS has failed, as the trend could be attributed to an increase in the number of states with database breach disclosure laws on the books as well as more merchants accepting online payments.
When it comes to the overall impact PCI DSS has had on retailer security, some argue that the standard actually creates a disincentive among some businesses to get by with less security than they would have otherwise.
"I think a lot of people miss the point that PCI was really intended to be the floor, not the ceiling. It was intended to define at least a minimum standard. Many organizations subject to it, however, too often see it as the ceiling. "If I'm in compliance, then I don't need to do more," says Scott Crawford, managing research director, Enterprise Management Associates.
--GEORGE V. HULME
PCI'S UPDATE TIMETABLE UNDER SCRUTINY
Some contend that PCI DSS moves too slowly to adapt to rising new technologies and attack trends. For instance, years ago a number of high-profile retail breaches were blamed, at least partially, on insecure wireless LANs such as the famous TJX Companies attack discovered in December 2006. But it wasn't until July 2009 when the PCI Security Council released a 28-page wireless security guide that provided guidance on how merchants could safely utilize wireless LANs in their operations.
"There is turbulent, rapid change in the IT industry, and to have a list of static controls just doesn't seem to make sense," says Corman. "You can regulate things such as car seat belts because the laws of physics don't change, but attack techniques change all of the time, and PCI DSS moves too slowly to adapt to the threats," Corman says.
Others argue that compliance to PCI DSS should be agnostic of technological change. "If we constantly wait for someone to be prescriptive about how we are going to apply a control, then we are thinking about it the wrong way," says Dahn. "Each of the PCI DSS requirements: restricting access, access controls, audit logging, network segmentation, antivirus, two-factor authentication, and others can all be applied to any technology," he says.
However, some businesses have shied away from innovative technologies out of the simple fear that they may not pass a PCI DSS audit. "Sometimes these mandates can stop innovation," says Corman. "If your business wants to change and outsource or embrace cost-saving technology, PCI DSS mandates can force them to put on the brakes," he says.
Those who would like to see a more agile, rapidly updated standard could be in for even more disappointment since the council decided this summer to move to a three-year update cycle for the standard. "We are always looking for ways to improve the standard, and one of those is how to improve the update cycle. Some feel the standard is changed too often, others feel it's not updated enough," says Russo. "But if you look at the standard over the past number of years, it's stood the test of time and hasn't changed much. And we are currently evaluating moving PCI to a three-year cycle, we may have a change in the next few months," he says.
No matter what the final updates to the standard look like later this fall, chances are they won't be detailed enough for some while too detailed for others.
"The notion of being prescriptive can be both good and challenging," says Christofer Hoff, director, cloud and virtualization solutions, Cisco Systems STBU (Security Technology Business Unit). "Just consider the business ecosystem involved with what the PCI DSS affects. When you make a change to something like that, it cascades down through hundreds of thousands if not millions of merchants. So one seemingly simple change to security folks could affect the operational capabilities of lots of businesses," he says. "I'm not making an excuse for it, but it is a very delicate situation."
Analyst Crawford agrees. "Particularly in IT security, compliance is a bit like trying to correct astigmatism. A lens that sharply focuses on one area may distort the focus elsewhere. Make requirements too prescriptive and you may be forcing organizations to comply with something that may no longer be relevant, especially if attack trends have moved on since the requirement was defined," he says. "Make them less prescriptive, and you make it difficult to hold subject organizations to a well-defined standard," adds Crawford.
No doubt even after the final updates are published this fall, the debates surrounding PCI DSS won't subside any time soon. However, the council's Russo is sure of this about the standard: "If you are a retailer, and you want to stay secure, becoming compliant to PCI DSS is the best thing you can do."
- Meet PCI DSS Requirements –HackerOne