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 11:19:36 -0800
From: coderman <coderman@...il.com>
To: "Thor (Hammer of God)" <thor@...merofgod.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

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/