Gartner Blog Network


What is Your Minimum Time To Patch or “Patch Sound Barrier”

by Anton Chuvakin  |  October 9, 2013  |  5 Comments

My time this quarter is not only occupied by the exciting realm of big data, but also by the less exciting – but waaaaay more common – problem: security patching.

Here is a thought: every organization on this planet has an upper limit to their patching speed. For example, even if you threaten every sysadmin with torture upon failure and/or offer to pay them a $1m each upon success, there is no way (for example) to patch every Windows system at a large global bank in 3 days. The real situation is of course more nuanced and different systems have different time limits. Patching all Oracle databases within a week of patch release date is as unrealistic as patching all Windows desktops within one day, etc.

So, think of this as a “patching sound barrier”- you can try to break it, but your craft may well shatter to pieces. The knowledge of your limit is important since if your patch management is tied to risk reduction (as it should), and you are trying to reduce risk further by reducing your patching window, there is a point at which you really should stop trying… Also, if you can work *really* hard and shrink your patching window from 90 days to 30 days, meanwhile the attacker gets in within 3 days of patch release date, is your work really justified? Maybe other safeguard should be considered instead.

What factors affect this “patching sound barrier”? They include:

  • Size of an organization
  • Utilized system types (legacy, traditional, virtual, etc)
  • Type of technology being patched (stock Windows desktop vs complex distributed application)
  • System Admin/system ratio
  • Degree of automation acceptance
  • Change management process maturity
  • Available patch management tools
  • Desired risk balance (risk of patch crashing the system vs risk of unpatched system exploitation).

This limit needs to be taken into account when security recommendations and practices are considered and implemented.

Related blog posts on patching:

Category: patching  security  vulnerability-management  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on What is Your Minimum Time To Patch or “Patch Sound Barrier”


  1. Alex Parkinson says:

    Hi,

    I think this is problem of the mismatching between various rates of activity. At a minimum there is:

    Rate of vendor patch release – The rate new patches are being released by a vendor. Since organisations use multple products, there are multple release rates to deal with.

    Rate of Approved Patch Release – The rate the organisation can approve matches for deployment. This is often a refelcetion of the change and release menagemetn practices used by the organisation.

    Rate and Frequency of Patch Deployment – This refers to the actual deployment of patches to the organisations systems. A big factor in this is the actual schedule appllied to patch deployement., rather than number of deployed patches verses time.

    A key measure here is the what “velocity of change” can an organisation and its systems can support. This where I think established change management practices haven’t helped and that something new with reagrds to change and configuraton control is requried to accelerate the deployment of patches and other security controls.

    This raises the question:
    “Can DevOps methods be used to solve security problems?”

    Kind Regards,
    Alex Parkinson

  2. Adding comment from another source for tracking:

    “The fastest I’ve seen at a Fortune 50 is 32 days from release to placed in production. However, I would say the average for such firms is closer to somewhere around 50 days.”

  3. @alex Thanks a lot for your thoughtful comment.

    “A key measure here is the what “velocity of change” can an organisation and its systems can support. ” <- this is probably at the very center of this question. Is the org "agile" or slow? Do agile orgs patch faster?

    “Can DevOps methods be used to solve security problems?” <- we are definitely wondering about this as well. Another analyst on the team may soon undertake a project to figure out how DevOps/Agile/etc affects security and how to make security agile as well…

  4. Marcelo Pereira says:

    Hi Anton,

    I would assume an average 50 days from patch release to production would be acceptable if all the critical patches were applied to the critical areas of the network at a faster pace. Though I believe that such slow process creates room to potential failures in maintaining security levels.

    What I believe is the most pressing issue here is developing a strong risk assessment program and building cooperation between security teams and sysadmins to ensure that patching is prioritized accordingly. That includes alligning business needs, people, technology and processes.

    And I continue my personal quest: can this be achieved at all?

    Thank you for the ever enlightining posts!

    Marcelo Pereira

  5. @marcelo The person who made the 50 day comment likely meant “for non-emergency patches.” But how rare should an emergency be to still be considered such? 1/year? 1/quarter?

    >building cooperation between security teams and sysadmins to ensure that patching is prioritized accordingly

    That is exactly the trick, but it is waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay easier said than done :-)



Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.