Date: Mon, 17 Jan 2011 13:41:01 +0100
From: Pete Herzog <lists@...com.org>
To: phocean <0x90@...cean.net>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Getting Off the Patch

phocean,

On 1/14/2011 7:09 PM, phocean wrote:
> Pete,
>
> I never admitted patching doesn't work. It does work everyday to fix
> coding errors.

I agree with that as well.

> 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 ?.

I agree with that as well. The truth is that once coding ends and 
product is delivered, as the receiver of the product I no longer have 
any influence on the product other than trust the vendor. My choice is 
to either continue trusting that human vendor and patch as I get them 
or to complement the installation with operational controls that 
function the way I want and need them to. I do know that I can measure 
the reasons I have to trust them and it's not acceptable to me. But 
depending on the op controls I choose and how I place them, based on 
how I want my operations to work, I can protect the interactions with 
the product. Or I don't use that product or that vendor.

>
> 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.

It is a sorry state that security software is insecure. One of the 
reasons I posted the article about patching is because patching has 
become so ingrained in the security culture that even the regular 
patching of security software has become acceptable as the norm when 
really, we should find it unacceptable that it wasn't created better 
in the first place. However, it's also the reason why a wide array of 
op controls should be used, defense in width, because security 
controls may fail and the additional controls can keep that failure 
from being messy.

>
> 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.

I agree which is why I focused on security patches that people 
auto-update and auto-install without thinking. I'm aware that there 
may be patches for desired functionality, including specific security 
functions you choose.

>
> 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 ?

Depending on the flaw in the sandbox, I expect the other op controls 
will protect the system when the sandbox breaks. For example, if I use 
system file and library integrity monitoring and least privilege for 
each application including the sandbox, that when something breaks the 
box, the system will not let the sand spill, so to speak. Now while I 
have practical knowledge of this and can use these controls on various 
OSes, there are some which I cannot because the solutions, the ability 
to do so, doesn't exist. In that case I have 2 options, patch or stop 
using the sandbox within that particular context.

>
> 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).

That's too bad. It was a way that we could verify certain facts about 
security and found some lacking and others wrong. For many it's a 
document to improve things by approaching their problem areas as they 
have found no good, elegant, or scalable solution. When people are 
stuck and looking for a new way to do things, the OSSTMM has a new 
perspective. We did try to put in many practical examples where we 
could to show controls, tests to make, means to analyze, but perhaps 
you missed those in your skimming of the document.

The OSSTMM may not be for you. I admit it's not for everyone. But it 
is there for the people who want to keep trying to find better 
solutions for the problems they encounter.

>
> 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.

Like what? Like coming up with a means to explain security that you 
can stop the patching and upgrade cycle and still be protected? I 
thought that would be something to incite people. But I tried that and 
you don't like it. ;)

Sincerely,
-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