It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it …  21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.

So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your  organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements.   I think recent breach surveys or reports are a great source to identify such controls  with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.

I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then,  the threat environment has probably evolved somewhat and exploitation of certain  vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.

Here are some findings from three recent reports on which I am basing my recommendations:

#	Report	Findings	Relevant Controls (Our Analysis)
1	Verizon Data Breach Investigations Report 2010	· 61% of the breaches were discovered by a third party · 86% of victims had evidence of the breach in their log files	· Technology – Monitoring, correlation, reporting and alerting off the log events · Process – Regular reviews of logs, log reports or alerts · People – Clear definition and assignment of responsibilities around log reviews and incident response
2	Verizon Data Breach Investigations Report 2010	· 94% of breached records had malware as one of the causes and 96% of breached records involved hacking · 51% of malware was installed or injected remotely by the attacker (by obtaining privileged access to the system or other means such as SQL Injection) · 85% of records breached by malware involved the attacker gaining backdoor access to the system · 81% of records breached by malware involved data being sent to an external entity or site · 86% of records breached by hacking involved use of stolen login credentials · 86% of records breached by hacking involved use of stolen login credentials · 89% of records breached by hacking involved SQL Injection · 92% of records breached by hacking used web applications as the attack pathway	· Technology – Proper configuration and lockdown of systems, strong access credentials, access controls or assurance, assessment of web applications and remediation for OWASP Top 10 vulnerabilities, deployment of Web Application Firewalls, Logging/Monitoring/Reporting/Alerting of important events on critical systems · Process – Configuration reviews, OWASP Top 10 vulnerability management, access assurance in the form of ongoing role/privilege management processes and periodic access certifications, regular reviews of logs, log reports or alerts, effective security incident response · People – Clear definition and assignment of responsibilities around configuration reviews, access certifications, log reviews and incident response
3	Verizon Data Breach Investigations Report 2010	· More than 50% of breaches remain undiscovered for months or more · 61% of the breaches were discovered by 3rd parties, and not the victim organization itself	· Technology – Monitoring, correlation, reporting and alerting off the log events · Process – regular reviews of logs, log reports or alerts · People – Clear definition and assignment of responsibilities around log reviews and incident response, User awareness and training
4	Verizon Data Breach Investigations Report 2010	· Few breaches were caused due to exploitation of vulnerabilities for which a patch was available. · Likelihood of exploitation of an unpatched vulnerability is far less as compared to a vulnerability caused by a configuration issue.	Lockdown (secure configuration) of systems may receive higher priority over application of vendor patches unless there is a specific reason not to do so
5	Leaking Vault – Five years of data breaches – July 2010	· Drives/Media and hacking were the top two breach vectors · Documents and Fraud (Social Engineering) have been increasing in prominence as threat breach vectors recently · Of the breaches that involved hacking, SQL Injection, stolen credentials and malware accounted for most breaches	· Technology – Disk/Tape encryption, appropriate system lockdown to prevent use of media such as USB drives , Encryption of unstructured data (documents), Refer to controls in #2 against hacking · Process – Physical Security, Encryption and Key Management · People – Awareness and Training
6	Ponemon Institute – Annual Cost of Cybercrime study – July 2010	· The most costly cyber crimes are those caused by web attacks, malicious code and malicious insiders, which account for more than 90 percent of all cyber crime costs per organization on an annual basis. · The average number of days to resolve a cyber attack was 14 days with an average cost to the organization of $17,696 per day. The survey revealed that malicious insider attacks can take up to 42 days or more to resolve.	Refer to #2 above

Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.

Key Control (Our Analysis)	Relevant PCI DSS Requirement Numbers (See Notes below)
Secure Configuration and Lockdown	1.1.5 (2), 1.2 (2), 2.1 (2), 2.2.3 (3), 2.2.4 (3), 2.3 (2)
Web Application Security	6.5 (3)
Strong Access Credentials including periodic changes in credentials (e.g. password)	8 (4)
Access Assurance (Least Privilege access based on users’ business or job roles, timely revocation of access privileges)	7 (4), 12.2(6), 12.5.4(6), 12.5.5(6)
Logging, Monitoring and Reporting	10.1(4), 10.2(4), 10.3(4), 10.4(4), 10.5(4), 10.5(6), 10.7(4), 12.2(6), 12.5.2(6),
Encryption (Data at rest, media), Physical security of media	3.3(5), 3.4(5), 3.5(5), 9.5(5), 9.6(5), 9.7(5), 9.8(5), 9.9(5)
Security Incident Response	12.5.3(6), 12.9(6)
Security Awareness and Training	12.3(6), 12.3.10(6), 12.4(6), 12.6(6)

Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.

As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies.  I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.

Hope this is useful! As always, we welcome your thoughts and comments.