Full Disclosure mailing list archives
Re: Getting Off the Patch
From: phocean <0x90 () phocean net>
Date: Tue, 18 Jan 2011 20:43:57 +0100
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 () hammerofgod 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/
Current thread:
- Re: Getting Off the Patch, (continued)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 17)
- Message not available
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Valdis . Kletnieks (Jan 18)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 18)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 18)
- Re: Getting Off the Patch coderman (Jan 18)
- Re: Getting Off the Patch phocean (Jan 18)
- Re: Getting Off the Patch coderman (Jan 18)
- Re: Getting Off the Patch Christian Sciberras (Jan 18)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 19)
- Re: Getting Off the Patch Christian Sciberras (Jan 19)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 19)
- Re: Getting Off the Patch Valdis . Kletnieks (Jan 18)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 18)
- Re: Getting Off the Patch Cor Rosielle (Jan 19)
- Re: Getting Off the Patch Jeffrey Walton (Jan 19)
- Re: Getting Off the Patch Christian Sciberras (Jan 19)