So, you accepted your limitations and settled on security patching timelines similar to this:
(source: “Improve Patch Management by Assessing Maturity and Applying Best Practices to Your IT Systems”)
Is this good enough? Please stop laughing now! Obviously, the attackers can develop exploits off public vulnerability announcements and patch releases much faster than weeks or months (on top of this, this schedule assumes they hadn’t possessed the exploit in its zero-day form).
On a more serious note, three related issues need to be addressed if your security update schedules look like anything similar to the above:
- How often do you scan (= use vulnerability assessment [VA] tools) and how does that frequency compare to the above patching frequencies? In other words, is there value in “scan daily – patch monthly” strategy?
- What do you do with “The Unpatchables” ™ – those vulnerabilities where a) patch is not coming (or not coming soon enough) and b) the risk is judged to be high?
- Which specific vulnerabilities and on which systems to patch first? – this topic has been addressed in this blog post and my published research on VM.
First, what is the value of VA if you *exclude* “the big one” – planning your remediation? Things like providing context to other tools (like SIEM and NIPS), compiling vulnerability metrics and using them to compare organizational units, testing other controls (NIPS, HIPS, etc), comparing live systems with local policies and standards, answering the vulnerability questions in the course of a risk assessment all come to mind. And, of course, making auditors and assessors happy (sort of – those puppies also care about your remediation more than scanning, at least in theory). Still, let’s think about it together: how much of VA value is tied to remediation for you … more like 50% or more like 90%?
In light of this, if your VA primarily serves the purpose of guiding remediation and not any other, decoupling the scanning and remediation schedules is rather senseless. The opposite is also senseless: that is, if your VA activities are completely disconnected from your patching efforts. By the way, scanning quarterly and patching monthly is truly and unquestionably dumb, for apparent reasons. I am sorry that you think that “PCI DSS makes you do that”, it really doesn’t. It only defines the quarterly scan schedule to produce reports to show your QSA, not the frequency at which you need to run your scanners.
Second, The Unpatchables. The best way to think about them is borrowed from the land of PCI DSS: compensating controls. What can I do to make this vulnerability on this system contribute 0.0 (or as little as possible, but within the acceptable bounds) to my risk equation? Note that this is broader than “make it NOT exploitable.” You can disable services, remove network access, harden configurations, deploy network, host or application controls, prevent exploitability, etc – or at least reduce the damage and/or your chance of being hit. Now, this discussion sounds basic (after all, “vulnerability management” [VM] always implied mitigation/shielding and not just remediation), but you’d be surprised at the number of people who equate VM with patching today. In fact, compare how much time was dedicated to system hardening in late 1990s and early 2000 – with how often you even hear the word “hardening” now. People had “show me your Unix hardening script – and I will show you mine“ parties, for god’s sake 🙂
So, what kinds of non-patch remediation and temporary mitigation do you do?
P.S. These patch management posts and my research into vulnerability remediation really do make me think that 1990s are back. Maybe somebody will write a paper titled …say….. “APT for Fun and Profit”?
Posts related to the same research project on patch management:
- What is Your Minimum Time To Patch or “Patch Sound Barrier”
- Patch Management – NOT A Solved Problem!
- Next Research Project: From Big Data Analytics to … Patching
- On Nebulous Security Policies (featuring “we patch all systems within 30 days” boondoggle)
- All posts related to patching
- All posts related to vulnerability management.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
2 Comments
Dear Anton,
As I read through your blog and can’t help wondering:
Is it going to be a day when we will be compliant because it will be a consequence of an effective vulnerability management process, rather than building ineffective VM processes focused on compliance which consequently fail to reduce risk?
and
If most organizations cannot even align to patch, is there any hope that we will come to the point where vulnerability assessment will be used to guide actions to reduce risk – no matter whether it will be patching of other mitigation actions?
It is always enlightening to read your blogs and your research.
Have a great weekend,
Marcelo
>Is it going to be a day when we will be compliant because it will be a consequence of an effective vulnerability management process, rather than building ineffective VM processes focused on compliance which consequently fail to reduce risk?
Well, we DO see this happening at some high security maturity orgs, where they do it well and are compliance as a byproduct of that. Admittedly, this is not as common as all of us would want 🙂
>is there any hope that we will come to the point where vulnerability assessment will be used to guide actions to reduce risk – no matter whether it will be patching of other mitigation actions?
There is HOPE 🙂 But hope and well-planned practice are millions of lightyears apart 🙁