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]

Message-ID: <58DB1B68E62B9F448DF1A276B0886DF16EBD6A1C@EX2010.hammerofgod.com>
Date: Wed, 19 Jan 2011 17:05:00 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Getting Off the Patch

>Cor Rosielle wrote:
>> I don't agree with the statement: "From a security standpoint,
>> patching is better than not patching.  Period.".
>>
>> Sometimes patching is the right solution, often it is not. Since some
>> asked experiences from larger companies, here is one:
><snip>

I never saw this post for some reason.   Cor, I think we should be careful about the propensity one has to engage in exaggeration creep to make points.
"'Sometimes' it is right, 'Often' it is not" is an example of this.  If your patching model has whatever problems you "often" have, then you should look at the model.  But defending your viewpoint by throwing in "blinding execute and install the patch" is a simple sleight of hand maneuver to respond to something no one ever said.

I should probably define my terms better, particularly in these types of discussions:  "From a security standpoint" refers to what corporate security is about: Risk Management.  The OP of this thread and some others seem to think security in this environment means "don't get hacked"  It doesn't.   It means "design and implement an infrastructure that meets compliance standards and supports business needs while implementing effective controls that mitigate risk while performing within budgetary restraints."   I could certainly have made that longer to accommodate hyperbolic responses, but I it's not worth the time to do that.  

The OP was about security patches.  Patches that address known security issues.  Patching these vulnerabilities is mitigates the risk more than not patching.  Further risk mitigation controls should always be in place, and that model has been around for years and years.  

>> I did not know about the OSSTMM in those days. If I did, I could have
>> explained why patching is not always the best solution: it interferes
>> with your operations. And if it influences you operations, you better control
>it.

What exactly do you think operations does?  I'll tell you want.  Let's everyone from full disclosure who works in operations go to their management and tell them that "patching interferes with my operations" and see what they say.  This is clearly your stated point, and I think your operations should know about it.  *You* don't have to do that, since you are the CTO, but others do.

Relating to your Win2000 example:  If you knew the patch was out there, and that your company's decision not to patch was publicized, and you chose not to patch anyway, then you clearly had no threats associated with that install.   And if you could go three years without installing any patches, then clearly the system had no importance.  If it did, then you didn't do a good job of risk management.

Also, let's stay away from the George Burns examples - People always seem to defend smoking and indulgent eating with "George Burns smoked and ate sausage and lived to be 100!" This may be true.  But 500,000 people a year die from heart disease.   Let's keep it real, shall we?

t 

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