Date: Fri, 14 Jan 2011 19:09:45 +0100
From: phocean <0x90@...cean.net>
To: lists@...com.org
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	Zach C <fxchip@...il.com>
Subject: Re: Getting Off the Patch

Pete,

I never admitted patching doesn't work. It does work everyday to fix
coding errors.
It is just one piece of the security puzzle. With the right processes in
the company, it is possible to reduce the risk.
And most important, security should start before the coding process,
which I admit is a very difficult thing to get : humans are so difficult
to change, aren't they ?.

Of course, there will always be a risk but what security solution can be
implemented with zero risk in a production environment?
I have seen more outages from anything (firewalls, IPS, routers, etc -
mostly human errors) but patches.

We may also not talk about "pathing" like a generic thing. Because there
are hundreds of bugs categories, there are hundreds of patches with
different risks.

Then, you use the example of sandboxing, which you certainly know can
often be passed over. You also know that there are bugs in sandboxing
code too (when it is not failing by design). So you won't patch it ?

I read the methodology (quickly I admit), it is full of nice theories
but it lacks practical examples and demonstrations in the real world.
I didn't see anything new or usable that I could take with me at work
and say "hey guys, we are going to stop patching".
Actually, what I read is more an alternative method of risk analysis
which doesn't convice me to leave the existing ones (eg MEHARI or
EBIOS).

Maybe it is my fault and I really missed something. If so, sorry, but I
guess it would be nice to give us some stuff that would incite us to
read deeply the 200+ pages.

Regards,
phocean

Le vendredi 14 janvier 2011 à 10:16 +0100, Pete Herzog a écrit :
> Hi phocean,
> 
> On 1/14/2011 9:25 AM, phocean wrote:
> > I don't understand this thread and what is new.
> 
> What is new is how we are trying to show patching as just one tactic 
> towards security and introducing an alternative which is just 
> controls. This increases stability and predictability by reducing 
> change control requirements while increasing efficiency by still 
> protecting the specific problem which has been patched in addition to 
> any new problems for which patches don't yet exist.
> 
> >
> > We all know it is rather hard to get protection from unknown threads,
> > and especially the unknow unknown. Competent administrator can try to
> > mitigate known unknown, eg common threats that may affect a software by
> > prevention.
> > In that way, patching is not on the front of the protections, true, but
> > it doesn't mean you can filter 100% of the potential threats. No one can
> > say it.
> 
> We disagree. We find that that the right balance of operational 
> controls at each interactive point within a vector can provide 
> protection against 100% of the threats including unknown threats. The 
> process and knowledge required is detailed in the OSSTMM 3 
> (www.osstmm.org).
> 
> > And anyway, patching is always a must because it is there to correct an
> > error, the source of the problem and leave a few less chances to the
> > attacker.
> 
> We disagree. Patches changes code which has already been operationally 
> and functionally tested. This requires additional testing for each 
> update and patch and that takes time, money, and other resources away 
> from other things. Therefore no wonder when operations scale upward, 
> the cost of security goes exponential. It's because of all the waste.
> 
> >
> > But this is so well known, at least I thought, that I wonder what is the
> > purpose of all of this.
> 
> The "well known" method has been failing for years and all new methods 
> based on previous assumptions keep failing as well. This is why we 
> researched the original assumptions in OSSTMM 3 and that some were 
> wrong only led to the creation of new methods that did not rely on 
> those old, wrong assumptions.
> 
> What is interesting is that people who do the same things and admit 
> that what they've been doing isn't working or isn't scaling continue 
> to do the things they know don't work. Change isn't always bad.
> 
> Sincerely,
> -pete.
> 


_______________________________________________
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