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: 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ