Verizon’s 2010 PCI Compliance Report published earlier this month provides yet another reminder that most organizations are not keeping up with “known good” security practices. Only 22% of organizations achieved a passing grade on their initial report on compliance, and Verizon found that these tended to be “year after year” compliance masters that view PCI as demanding a “lifestyle change” rather than compulsory acquiescence. This reminds me of a related statistic…90% of people diagnosed with heart disease are unable to change their lifestyle to reduce their risk…they’d literally rather die than change. Fortunately PCI is not a matter of life and death, but you get the point.

Like most other compliance regulations in the security industry, PCI was established for a specific purpose (protecting payment card data), but comprises requirements that can help any organization in any industry take a more methodical approach to information security. The report’s analysis of compliance by requirement illustrates that organizations are better at planning (Requirement 12) and doing (Requirements 1-9) than checking (Requirements 10-11), based on average compliance rates of 44%, 54% and 39%, respectively. Those of us that have studied quality know that you must “check” or “measure” to learn what to change and then follow through and repeat to maintain the cycle of continuous improvement. The most proficient information security organizations have applied at least basic quality principles and have established continuous improvement processes to cope with the ever-changing threat horizon.

The two lowest compliance rates were found in PCI Requirement 10, Track and monitor all access to network resources and cardholder data and PCI Requirement 11, Regularly test security systems and processes. I will leave the latter to other bloggers, but I have a vested interest in helping the industry do a better job with the former. Verizon’s findings on why Requirement 10 challenges may be summarized as follows:

• Implementing logging is easy on networking devices and operating systems but is hard on applications, particularly legacy applications
• Securing the logs from alteration is hard, since the default configuration is to overwrite old log data as local log storage space is consumed
• Maintaining an audit history for all logs is hard because this requires a comprehensive and timely logging infrastructure and centralized log file integrity monitoring
• Daily monitoring and review of logs is hard because “…the amount of information far exceeds our ability to extract meaning from it.”

These challenges are daunting but can be overcome with effective people, process and technology aimed at log management and analysis. Organizational commitment is essential, but it often requires an executive to step up and articulate a vision for comprehensive and continuous monitoring, analysis and adjustment. SenSage customers tend to have such a champion that has helped their organization realize that these challenges can be mastered and that the payoff is not only regulatory compliance but real reduction of risk. Applications – even homegrown legacy applications – can be monitored, if you have a technology that accepts native log data without the need to add agents to the applications. Once this application logging is established, you need a central repository to store this data along with all of the “easy logging” data from network devices and operating systems. The central repository should be “append only” to ensure that no log data can be changed (this is needed to satisfy PCI Requirement 10.5.5). And finally, the central repository must support a business intelligence layer that enables you to filter the data and isolate the conditions of concern. While some of these conditions are known in advance and therefore can be “shrink-wrapped,” most are the result of applying continuous improvement principles in the context of your unique environment. This approach is particularly effective when extended beyond the sphere of tracking and monitoring, and into the world of regular testing (PCI Requirement 11, the other weak area cited by the report). For example, in between quarterly network vulnerability scans (Requirement 11.2) and annual penetration tests (Requirement 11.3), log data may be filtered for conditions that caused prior test failures, such as inconsistent configuration settings and/or security patch levels.

The Verizon 2010 PCI Compliance Report highlights the need for progress, but also provides useful lessons from the ongoing effort. PCI Requirement 10 has presented particular challenges in application log enablement, log file integrity monitoring, system scalability and log data analysis that most log management solutions have been unable to address. Organizations that find themselves in the 61% not complying with Requirement 10 should consider SenSage Security Intelligence solutions that solve these issues as noted above. Together, we can do this!

permalink