So, you accepted your limitations and settled on security patching timelines similar to this:
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.
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.