mailing list archives
Re: Getting Off the Patch
From: Pete Herzog <lists () isecom org>
Date: Mon, 17 Jan 2011 13:41:01 +0100
On 1/14/2011 7:09 PM, phocean wrote:
I never admitted patching doesn't work. It does work everyday to fix
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
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
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. ;)
Pete Herzog - Managing Director - pete () isecom 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.
Hosted and sponsored by Secunia - http://secunia.com/