Message-ID: <4D30579E.3070002@isecom.org>
Date: Fri, 14 Jan 2011 15:03:10 +0100
From: Pete Herzog <lists@...com.org>
To: Zach C <fxchip@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Getting Off the Patch

Zach,

> While true, the patch is still most likely going to eliminate the flaw I
> *do* know about. I don't have either the connections or the time to find
> and know about some flaws that aren't covered by the patch, this is
> true; but I will know about the ones that are, and given my lack of
> connections, so do many other people, which increases the potential of
> exploitation (not the likelihood so much, but the potential). If I have

Which is all the more reason to implement an array of controls 
(defense in width) for the interactive points rather than rely on 
patches to fix ONLY the problems you know about.

> the tools and the knowledge to fix a problem, I would figure that I
> would be remiss in not employing them merely because the other controls
> in place should keep my data safe. Especially if there is a direct
> interaction with what I'm patching and what I want to protect (website
> code & apache, can't expect it to work and not be able to read/run my
> code and such).

And you would be wrong because patching means changing the code. You 
know what you have and the operations are as you want them. Then you 
want to change the code to deal with some problem which requires you 
to verify your operations again to assure it is what you want. Perhaps 
you don't implement change control. Perhaps you don't do functional 
testing of operations after patching. Perhaps you choose to trust the 
same people who made the flaw in the first place. Perhaps you don't 
know your operational baseline. Perhaps you have lots of time to 
spare. All reasons why you may want to patch AND use controls. But you 
would be remiss to think that patching means only fixing a problem and 
changes nothing else.

>
> The tl;dr summary of that, I guess, is "patching will at least keep the
> skiddies out."

Which is good if the world was made of only skiddies and all the bad 
things that can happen are in the hands of the lowest common 
denominator. But operational controls will keep out the skiddies and 
all the rest of the undesirables.

>
> Potentially, yes. However, it's not exactly like patches I can somewhat
> trust can come from anywhere else (unless I wrote it), and if I continue
> to use the software I probably trust its author. It also takes
> substantial effort to evaluate switching products entirely as opposed to
> patching what you currently have, but that's just stating the obvious.

Or else, do what is realistic- control that which you have less than 
nominal reason to trust. If you can't control it, get rid of it. 
Patching it constantly will only constantly change your operations 
which, should be as stable as possible. The less stable it is, the 
less you can tell when something is wrong.

> All I'm really saying here is that controls external to what is weak are
> nice and definitely a recommendation, but ultimately can only mitigate
> what can be done. I'm saying it's generally worth it to patch for that
> extra assurance against well-known flaws -- but, granted, only
> especially so after a given period of time that sees many more and/or
> 'potentially fatal' flaws exposed to the public.

And I'm saying that's the wrong way to think about this because 
patches don't just fix the flaw. They change things. There is nothing 
wrong with a flaw in your software if it can be mitigated in other 
ways efficiently because your software is FULL of flaws that you don't 
know about anyways. So you can mitigate a large number of them or even 
all of them before they become zero days. So don't waste your time on 
the patching and the updating because a patch isn't always "just a patch".

-pete.


-- 
Pete Herzog - Managing Director - pete@...com.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists