Menu

Skip to content
Infosec Engineering

Infosec Engineering

Speed of Patching Versus Breach Likelihood

Posted on August 31, 2015 by jerry

I am a big fan of the Verizon DBIR.  I was just reading this interview with Mike Denning  from Verizon on Deloitte’s web site about this year’s report.  The whole article is worth reading, but I want to focus on one comment from Mr. Denning:

One of the biggest surprises was the finding that 99.9 percent of the exploited vulnerabilities had occurred more than a year after a patch, which quite possibly would have prevented them, had been published. Organizations are finding it difficult to maintain the latest patch releases. Additionally, the finding speaks to the challenges of endpoint security.

Today, coverage is more important than speed because, through scanning and other methods, attackers are able to find the weakest link in the chain and then quickly move laterally within the organization. …

This comment brought back some thoughts I had when I initially read the 99.9% statistic in the 2015 DBIR.  That number, while a bit surprising, fits the intuition most of us in the field have.  My concern, however, is that this may be interpreted as meaning the following:

“we can exclude ourselves from 99.9% of breaches by just ensuring we keep up with our patching.  After all, we should be able to meet the goal of applying patches no later than, say, 11 months after release.  Or 6  months.”

I see two problems with this thinking:

  1. Few organizations can apply EVERY patch to EVERY system.  Sometimes we consciously “exempt” systems from a patch for various business reasons, sometimes we simply don’t know about the systems or the patches.  If this is the case in your organization, and you get compromised through such a missing patch, you are part of the 99.9%.  You don’t get credit for patching 99.9%.  I wonder how many organizations in the 99.9% statistic thought they were reasonably up-to-date with patches?
  2. Outside of commodity/mass attacks, adversaries are intelligent.  If the adversary wants YOUR data specifically, he won’t slam his hands on the keyboard in exasperation because all of his year-plus old exploit code doesn’t work and then decide the job at McDonalds is a better way to make a living.  He’ll probably try some newer exploit until he finds one that works.  Or maybe not.

My point is not to diminish the importance of patching – clearly it is very important.  My point is, as with any given control, thinking that it will provide dramatic and sweeping improvements on its own is probably a fallacy.

 

 

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on Google+ (Opens in new window)
Posted in Management | Tagged DBIR Patch Management

Recent Posts

  • Treating The Disease of Bad IT Design, Rather Than The Symptoms
  • Differentiating IT Risk From Other Business Risk
  • Thoughts on Incentives Driving Bad Security Behavior
  • More Effective Security Policies
  • Thoughts on Autosploit

Categories

  • Advice
  • Behavioral Economics
  • Best Practice
  • Breach statistics
  • Economics
  • Hacking
  • Ideas
  • Malware
  • Management
  • Metrics
  • Resiliency
  • Risk
  • Security Awareness
  • Uncategorized
  • Uncertainty

Recent Comments

  • Fernando on Treating The Disease of Bad IT Design, Rather Than The Symptoms
  • Alex Humphrey on Thoughts on Incentives Driving Bad Security Behavior
  • Concentration of Risk and Internally Inconsistent Regulations – Infosec Engineering on Thoughts On Cyber Insurance and Ponemon Surveys
  • Alex Humphrey on Thoughts on Cloud Computing In The Wake of Meltdown
  • Christian Folini on Random Thoughts From The OReilly Security Conference 2017

Meta

  • Register
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
Proudly powered by WordPress
Theme: Flint by Star Verte LLC