Full Disclosure mailing list archives
Re: Getting Off the Patch
From: Michael Krymson <krymson () gmail com>
Date: Wed, 19 Jan 2011 10:25:11 -0600
For once in this thread, thank you for a concrete example! :) As a follow-up pair of related questions... 1) Do you find it taxing (or costly) to have to always defend those moments where patching is not used? For instance, any auditor or evaluator of your security is going to immediately pounce on missing patches. 2) Somewhat similarly, you won't ever "pass" on any automated tools, which will certainly incur manual labor costs to iron out false positives, right? I'm not saying we should use and trust such automated (usually vulnerability) scans, but that's a reality of so many firms. I imagine every pen test or vuln scan or other audit is pretty intensive and requires lots of back and forth in an environment that has chosen other controls vs patching. The dangerous part of this paradigm about operations vs patching (and the original article in this thead!) is how truly difficult it is to get other people on board, from deeply technical to managerial and shallow. Even my mom would raise an eyebrow to hear that firm XYZ may not necessarily patch. It might be worthwhile to just patch and continue to do what is easy to understand and move on with, rather than incorporate so much complexity and head-spinning control? One of the very first bullet points on any corporate or home computer security regiment is to patch. And then we have people saying it's ok not to patch if/when/blah. How does that get us any further? How does that make management feel any better about what we offer? <- snip -> *Re: Getting Off the Patch* ------------------------------ *From*: "Cor Rosielle" <cor () outpost24 com> *Date*: Wed, 19 Jan 2011 12:08:48 +0100 ------------------------------ I don't agree with the statement: "From a security standpoint, patching is better than not patching. Period.". Sometimes patching is the right solution, often it is not. Since some asked experiences from larger companies, here is one: In 2001 I was responsible for maintaining all kinds of systems and services at a telephony and internet provider. One morning a list with our company name in it was mentioned in the radio news bulletins. We also found our name in this list in articles in newspapers. A "hacker" found we didn't install a patch on one of our web servers which ran IIS 5.0 on Windows 2000. The patch was available for about 3 months and the hacker claimed he could attack our server because of this specific patch missing. Because of his "ethical standards" he did not try to really attack the server but just publish about the shameful patching policies in large companies. Three years later, when a new website was developed, the server was replaced. The patch was still not installed. Even though we were in the radio news bulletins and news papers and the world knew about our vulnerable server, no successful attack occurred in all that time. O yes, they tried. I've seen it in our log files. But because other defense mechanisms, the known exploit did not work on our server. And since the web server was in no danger without this patch, we decided installing the patch would be a higher risk than leaving the server as is. I did not know about the OSSTMM in those days. If I did, I could have explained why patching is not always the best solution: it interferes with your operations. And if it influences you operations, you better control it. Not blindly execute it and install the patch using an automated update process, but actually control it. So the first thing to do is to decide if applying a patch is useful at all. And often it is not! E.g. why would you even consider to install MS10-085 on a http-only web server (MS10-085 apparently fixes an error in TLS handshake)? (Don't flame me on this one, it's just meant as an example). And if you concluded a patch is useful, then you decide if you do need to install it, or if it is not really necessary to install it. And if you install it, then decide if you do it manually, in a controlled manner, or use an automated update process, in an uncontrolled manner. The OSSTMM helps you to realize that an automated update process increases the attack surface, which better be controlled. Another option of course is to blindly install it, because you trust your vendor (you know, the one that provided buggy software in the first place). Then your not controlling, but trusting. Read chapter 5 in the OSSTMM to find out if that is wise for this particular vendor, or not. Bottom line is that patching interferes operations and therefore, from a security standpoint, it either has to be controlled or trusted. It is not always true that patching is better than not patching. So I would slightly like to rephrase that statement: "From a security standpoint, thinking is better than not thinking. Period.". (Now would it surprise you if I told you that critical thinking is one of the starting points of the OSSTMM??. Cor Rosielle Chief Technology Officer
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Getting Off the Patch, (continued)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Григорий Братислава (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Roger Casteele (Jan 16)
- Re: Getting Off the Patch Christian Sciberras (Jan 17)
- Re: Getting Off the Patch Cor Rosielle (Jan 13)