Notes on the 2011 Verizon Breach Report

Friday, October 07, 2011

PCI Guru


At this year’s Community Meeting, Christopher Novak of Verizon Business Services made a presentation regarding the 2011 Data Breach Investigations Report

A lot of people blow off these sorts of presentations as being vendor focused or just a bunch of meaningless statistics. 

However, Verizon provided a very good presentation on the nature of today’s threats and what organizations should be doing to protect their networks and systems.  Verizon’s Data Breach reports are a wealth of information; however I wanted to highlight just a couple of things that all organizations should take away from the report.

The first take away from the Verizon statistics is that while the media focus on the threat of insiders, it is the threat presented by external parties that is accounting for 92% of breaches, up 22% over 2010.  Not that insiders are not a threat, but only 17% of breaches involved insiders, down 31% over 2010. 

Threats from business partners were less than 1% and only 9% involved multiple parties.  Yes, all of that adds to more than 100%, but as Mr. Novak reminded us, there are numerous instances while external actors ultimately breached the organization they were assisted by one or more insiders or a business partner.

The next important set of statistics is an analysis of breaches against the PCI DSS and its requirements for organizations that were in-scope for PCI compliance.  The first statistic that every organization should be concerned about is that Verizon found that 89% of all PCI in-scope organizations breached had been assessed by a QSA or themselves as not compliant with the PCI DSS. 

This statistic should be a wake-up call to all organizations that complying with the PCI DSS is important.

In reviewing this demographic mix and the associated lack of compliance, we believe that the data reinforces an assertion we’ve been making for the past three years: to reduce risk, organizations of all sizes need to implement the basic tenets of an information risk management program and maintain this initial investment over time.  This includes network and data defense technology basics (firewalls, anti-virus, identity and access management), as well as the non-technical aspects of security and risk management (policy and process development). ~ Verizon Business Services 2011 Data Breach Investigations Report – page 62

PCI DSS Compliance and Breach Correlation

But the really important statistics were the analysis of compliance against each of the 12 PCI DSS requirements when a breach occurred.  What this analysis shows is that there are a lot of areas for improvement.

For building and maintaining a secure network, less than 50% of breached organizations were compliant with requirements 1 and 2 of the PCI DSS.  In protecting cardholder data, while breached organizations (requirements 3 and 4) were better at protecting cardholder data when it was transmitted (63%), they were horrible at protecting cardholder data when it is stored (43%).

It appears that organizations were complying with requirement 5 at 70% compliance.  However, given other survey results that claim over 95% of organizations have anti-virus and anti-malware, this is a troubling statistic as it points to incompetence in the installation and operation of these tools.

As I would expect, less than 50% of organizations were in compliance with requirement 6.  Whether that is related to patching or poor development practices, this part of the PCI DSS is always a bone of contention.

While overall, the requirements to implement strong access control measures, requirement 8 lags physical security and having access control systems implemented.  What this says is that while organizations have the tools in place, they are doing a poor job of managing them.

Regularly monitoring and testing networks is probably the area that needs the most improvement but explains another statistic in the report.  Compliance with requirement 10 and 11 were only 39% and 38% respectively when a breach occurred. 

Earlier in the report, Verizon has a bubble chart that shows how long it took to breach an organization, how long it took the breached organization to acknowledge they were breached and then the time it took to address the breach.  It took attackers hours to days to breach an organization. 

Unfortunately, it took weeks or months for an organization to know they were breached.  And to add insult to injury, it took additional weeks to contain the breach.

And finally, compliance with requirement 12 was only 44%.  A lot of organizations blow off documentation.  But it is the foundation of an organization’s security posture because it explains and describes why the other 11 requirements are important.  Without that foundation, is it any wonder that the other requirements are not in compliance.

One of the lingering questions from our discussions around PCI in this report is always that of relevancy. It’s all well and good to validate compliance with the PCI DSS, but does it actually help reduce risk? Insofar as that translates to a sincere security program—one that seeks to maintain validation on an ongoing basis—the data strongly suggests the answer is “yes.” ~ Verizon Business Services 2011 Data Breach Investigations Report – page 64

So what should an organization focus on to improve their security posture?  Here are my thoughts on a shortlist of issues that, if dealt with, would go a long way in securing organizations.

  • Really monitor your networks and systems.  No, I am not suggesting that everyone needs to go out and invest in a security incident and event manager (SIEM) or similar log management and analysis solution, but some organizations have no other choices because of their size and situation.  Regardless of how you choose to approach this problem, the key is that you must monitor your networks and systems.  And you need to monitor them regularly (daily) if not in real time.  The best organizations are doing real time monitoring and go through the PCI DSS tests and develop rules to monitor compliance with those requirements.  Attackers know that they can get away with their breaches because organizations are lax in their monitoring.  Just tightening monitoring up would go a long way in reducing the amount of data breached if not reducing the number of breaches.
  • Manage your access control systems.  No, it is not sexy to review user lists on a quarterly basis and disable, remove or reclassify users.  But here is a prime example of where organizations have a tool and are not using it correctly to improve their security.  Based on the report, it turns out that a lot of breaches were the result of poor user management practices and lousy passwords.  If this area got addressed, it would also go a long way in cleaning up the problem.
  • Engineer your networks and systems to be secure.  It fascinates me how many security professionals do things in the name of expediency that open huge holes in an organization’s security posture.  Another fascinating thing is how many security professionals have little knowledge of operating systems and applications.  Most security professionals seem to come out of the network administration teams as they were maintaining firewalls and routers when they went into security.  As a result, while they are very good at securing the network, server and application security lag because they just do not understand it nor do some find it all that important.
  • Test your security.  The only reason I can figure that vulnerability scanning and penetration testing is not being performed is that it will be used against security personnel to show that they are not doing their job.  While there are those security personnel that talk the talk but do not walk the walk, the vast majority of security professionals do an admirable job with few resources and even fewer plaudits.  However, given the rate of vulnerability production by attackers and researchers, if an organization is not conducting quarterly or even monthly vulnerability testing, there is no way an organization is going to protect itself.  And while the value of penetration testing will probably always be argued, I can tell you that it does have its place and can be invaluable if properly conducted.  This is particularly true for all of those organizations that think that because their vulnerabilities are all less than CVSS 4 that they are secure.
  • It is time to get control of application patching.  For small organizations, patching is only an issue due to a lack of focus on it as an issue.  For large organizations, it is the sheer volume of systems and devices that need patching.  There are numerous solutions for large organizations to deal with this situation, so find the tool that best fits your organization and get it implemented.  Oh, and get off the 30 day issue, that was clarified years ago.  You only need to have a reliable process and demonstrate that your patching process works on your time frame and patches do not fall between the cracks.

If all organizations could just focus on these five items and execute them at least 90% or better all of the time, a lot of the current breach issues would go away.  But that is the rub is it not?  A lot of organizations have issues maintaining that level of execution compliance. 

Breaches occur because organizations get sloppy and, even with defense in depth in their security controls, there are too many controls where execution consistency has dropped leaving gaping holes in the various levels of security.

And as a reminder, these items address today’s problems.  However, once addressed, attackers will find other ways in, so the improvement process needs to be continuous.  And while organizations address the latest security concerns, they must be vigilant to cover the prior concerns because old vulnerabilities and exploits have a way of coming back.

Cross-posted from PCI Guru

Possibly Related Articles:
Information Security
breaches PCI DSS Compliance Network Security Controls 2011 Verizon Breach Report
Post Rating I Like this!
Joe Schorr I bookmarked this posting. Excellent review.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.