Common Barriers to PCI Compliance and DSS 2.0
As a QSA I’m often asked which requirements organizations typically struggle with, what solutions they implement, and how these factor into the cost of compliance. With the introduction of PCI DSS 2.0 this year I’m adding another question to the mix: how does the revised standard change this?
As I’ve posted previously the changes to the DSS are evolutionary and should not present any major issues to organizations already in compliance. I would further add that I do not see the changes significantly shifting the landscape with respect to the challenges that organizations already face in complying. Before I dig into that let’s take a look at what some of those are based on trends collected from the numerous PCI assessments Symantec’s Advisory Services QSA team has performed:
- Lack of formalized policies, standards, and procedures: these may be “social” but not written, and may not be reflected in the actual implementations (applies to multiple Requirements).
- “Roll Your Own” practices: re-inventing the wheel may lead to a poorly designed wheel, and you may miss lessons learned that have been captured in industry best practices (applies to multiple Requirements).
- Cardholder data environment is not segmented from operations: systems, people, and infrastructure are co-mingled, leading to increased and unmanageable scope for PCI compliance (PCI DSS scope).
- Lack of adequate logging and analysis capabilities: impairing the ability to detect and respond to incidents, and to perform effective forensics efforts (Requirement 10).
- Insufficient testing and follow-up: new vulnerabilities are not detected and addressed in a timely manner, possibly with little or no validation that installed controls are effective (Requirements 6 and 11).
- Emphasis on business operations at the expense of security: looking to minimize time to market, costs, etc., with poor security likely eventually having a negative impact on the business.
On October 4, 2010 Verizon released its “Verizon Payment Card Industry Compliance Report” (http://www.verizonbusiness.com/go/pcireport). Many of the findings overlap with what Symantec has seen and seem to indicate industry-wide trends.
Based on this, how will compliance with 2.0 be affected? From a requirements perspective, I feel the answer is not much. The clarifications being made should help organizations understand their responsibilities better, but should not increase or decrease them. Some changes may open new avenues to compliance that might make it easier to comply given an organization’s existing capabilities.
That said, responsibilities for understanding and documenting scope and cardholder data flow and storage will be shifting toward the organization with 2.0. I’ve seen organizations of all sizes struggle with this in the past, and would not be surprised to see this join the other challenges we’ve seen.
My suggestion would be that organizations continue addressing these challenges as they have been, and begin considering if the revised standard offers any new avenues for compliance in conjunction with their QSA, Acquirer, or Card Brand, as appropriate. I would also suggest developing a methodology for scoping and cardholder data flow to give yourself time to mature it and avoid facing another potential challenge.
As always, your feedback and questions are welcomed!
Symantec’s Lead Technical QSA, Michael Garvin has worked in information security, compliance, system administration, and enterprise architecture for nearly 20 years. His experience includes higher education, service providers, and corporations including Sun Microsystems. He has been delivering PCI assessments with Symantec for four years and participates in PCI SSC activities. Michael is a CISSP, PCI QSA, CHP (Certified HIPAA Professional), CHSS (Certified HIPAA Security Specialist), and is an early adopter of the Certificate of Cloud Security Knowledge (CCSK).
Tags: compliance, PCI 2.0, Symantec
Subscribe to the comments through RSS Feed
Leave a reply