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: Tue, 18 Jan 2011 20:43:57 +0100
From: phocean <0x90@...cean.net>
To: coderman <coderman@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
Subject: Re: Getting Off the Patch

I just agree with all that.

But once again, as with Pete, how is this new ? It has been the best
practice of good system/security administrators for years.

And it doesn't look like a "no patching" policy yet...

Le mardi 18 janvier 2011 à 11:19 -0800, coderman a écrit :
> On Tue, Jan 18, 2011 at 10:39 AM, Thor (Hammer of God)
> <thor@...merofgod.com> wrote:
> > ... Any security model that not only advocates non-patching, but that is designed with the intent of not patching is completely retarded.  I defy anyone to provide verifiable evidence to the contrary that is not based on a server and a couple of workstations.
> 
> while the vast majority of this thread has sucked the will to live
> from my consciousness, the concept of a non-patch model is
> interesting.
> 
> i have used something similar to great success with some specific caveats:
> 
> a. you still need to patch sometimes.  based on past experience this
> can be as infrequent as once or twice a year.
> 
> b. you have a compensating control (more below) for your not-patching
> preference.  If you can't manage testing and deployment of patches,
> you are not in good shape no matter the defense in depth.
> 
> c. trade-off need for patching by reducing attack surface of
> applications and systems by disabling all unnecessary features,
> services, and capabilities.  this can vastly reduce the scope of
> software under test and affected by patching, often by orders of
> magnitude.
> 
> d. trade-off patching and testing difficulty by virtualizing the
> software into a common environment more suited for automation,
> expansive testing, rapid deployment, limited scope, and overall
> robustness.
> 
> e. trade-off patching induced service interruptions by utilizing a
> highly available cluster configuration with distinct pools of software
> for on-demand halt, update, and restore with only transient service
> interruption. where possible, hot binary patching of kernel and
> applications without interruption in processing state is ideal.
> 
> f. monitor service availability and vulnerability impact. identify
> patches affecting components not in use, and patches incurring a test
> and release cycle.  confirm that you are actually better off focused
> on a hardened, agile, automated process less focused on patching as
> security strategy given the man hours used to achieve a, b, c, d and
> e.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/


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