When should one apply security patches?
Finding the optimal time is a matter of finding the intersection of two curves. One curve is determined by the cost of recovering from a failed update, multiplied by the probability of such a failure. The probability of applying a bad update will fall over time, since these updates are discovered and fixed. The other curve, instead, is the cost of dealing with a security breach, multiplied by the probability of that breach happening. The chances of a particular vulnerability being exploited grow over time, of course, especially in the free software world, where vulnerabilities tend to be disclosed before they are actively exploited. The two curves will thus cross at some point; once they intersect, the costs of not applying the patch exceed those of pressing forward.
To find the probability of applying a bad patch, the authors dug through the CVE database, examining 136 entries. For those, they found twenty cases where patches were withdrawn or revised. The median time to revise a patch, it turns out, was just over 17 days; one patch was fixed after a year and a half. To finish the calculation, one must try to determine the probability of an unpatched system being compromised. The authors punt on this one, saying that it must be calculated "locally" for any individual network.
In the absence of that second probability, the authors make their final
conclusions from the "bad patch" data. Looking at a graph of when issues
were "resolved" (a good patch released), they note a couple of obvious
plateaus. "However, since [the probability of a compromise] is
difficult to compute, the pragmatist may want to observe the knees in the
curve ... and apply patches at either ten or thirty days.
" One
should bear in mind that the calculation would be different for a
vulnerability which is being actively exploited, however.
Posted Nov 21, 2002 10:46 UTC (Thu)
by tres (guest, #352)
[Link]
An example of this would be the old 'win-nuke' DoS exploit that blew out the network stacks in Windoze machines. I was in charge of security at a small ISP when this came out. It affected more than just windoze boxen though. It affected our Cisco router and our SGI Indy. The 'workaround' was to apply filtering rules on the router and log malicious packets from both our customers and our internal boxes. This prevented us from installing a M$ patch that was, at the time, an unkown in terms of what it did. After the patch had been available for a while and the feedback was positive we applied the patch to our servers and suggested it to our users. The packet filter had to modified to allow the WWW server to send out the malicious packet to our customers that wanted to see if their machines were vulnerable. (Don't worry, the WWW page stated in big flashing letters that the packet would crash the network stack on their machine and force them to reboot if they were vulnerable and would only send the packet to the machine that had requested it). We could also state that we had evaluated the patch and determined it to be 'a good thing' (TM) and that it wasn't totally necessary since our router would filter the packets before they ever reached their machine. Most people applied the patch but the way that we handled it was a big hit with the customers. We actually got many of them to take an interest in security; something that most either thought too complicated or one of the hazards of the wild wild web. I may have gotten the names mixed up in the last story as it played out a number of times in various forms through the years; the details of security incidents tend to blend together after the threats have passed. Regards,
Posted Nov 22, 2002 16:52 UTC (Fri)
by obobo (guest, #684)
[Link] (2 responses)
Standard sort of game theory problem, I suppose- by waiting you are acting in your own self interest at the expense of the community as a whole.
Posted Nov 28, 2002 15:03 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
Being careful with the production server is taken for granted ... Cheers,
Posted Nov 29, 2002 16:55 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
But I really don't think there would be a problem with everyone But one may have ethical concerns about protecting one's own ass by
Other things to consider in the time to apply patches would be the availability of a workaround, the effectiveness of the workaround, and the decrease in service that the workaround imposes. If a security vulnerability can be rendered invulnerable by the application of a quick work around then the patch can be given more time to be shaken out. An example would be a FTP vulnerability in which a cracker must first upload code to be executed. If the FTP server's uploading capability was eliminated (or restricted to known users) then you have effectively worked around the vulnerability but probably denied some functionality to some of your users. If this functionality is not critical (like the necessary files could be attached to an email) then applying this workaround would give you the luxury of letting others shake out the possible bugs in the patch. If after an appropriate amount of time the patch seems to fix the vulnerability, without introducing any new ones, it should then be applied.When should one apply security patches?
Tres
There would be a problem, however, if a majority of administrators follow the advice of waiting 10 or 30 days before applying a patch. If the patch has a bug (as opposed to being an insufficient or misguided fix for the underlying problem), then the bug will only be found when a sufficient number of users have installed the patch. If admins wait longer before applying a patch, then the bug won't be found as quickly, and the next such study will indicate that you should wait a bit longer (an extra 10-30 days, perhaps?) before applying patches.Feedback loop
But any administrator with half a brain SHOULD install the patch on a test server within ten minutes of it being released ...Feedback loop
Wol
A test server wouldn't help. The patch developer already tested it onFeedback loop
a test server. You find the bugs when you run it in production and
the particular conjunction of circumstances that triggers the bug,
which wouldn't occur to a tester, occurs.
waiting for everyone else to shake out the bugs. There will always
be a large number of people applying the patch immediately regardless
of any research or recommendations showing the value of waiting.
Just because of the diversity of the users.
letting one's neighbor walk point.