full-disclosure - Re: Getting Off the Patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 14 Jan 2011 10:16:07 +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>,
	Zach C <fxchip@...il.com>
Subject: Re: Getting Off the Patch

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.

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