Speed of Patching Versus Breach Likelihood

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.