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
| ||
|
Message-ID: <1295379837.2958.79.camel@subarashii> 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/
Powered by blists - more mailing lists