Re: [Full-disclosure] Getting Off the Patch

["Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>]

[Combining Threads]

>-----Original Message-----
>From: Pete Herzog [mailto:lists@xxxxxxxxxx]
>Sent: Friday, January 14, 2011 10:19 AM
>To: Thor (Hammer of God)
>Cc: Valdis.Kletnieks@xxxxxx; phocean; full-disclosure@xxxxxxxxxxxxxxxxx; Zach
>C
>Subject: Re: [Full-disclosure] Getting Off the Patch
>
>> It's brilliant!  Where do I sign up?
>>
>> t
>
>What you run a patch management company? What's your problem with
>trying to improve the way we do things? If we find patching isn't a good nor
>necessary solution for better security then why shouldn't we propose a new
>model?

No, I do not run a patch management company, but despite that, I successful 
patch on an ongoing basis without experiencing any of your claimed wastes of 
money, time, and resources.  And within the context of this conversation, since 
you are the one saying that you don't have to patch, it should be you that 
illustrates a level of patch management expertise

Coming up with some way of creating a dependency on new, additional security in 
depth requirements that on their own create additional administration in order 
to consciously stop patching is ridiculous Pete.  If your controls are good 
enough to obviate the need for patching, then they should ALREADY BE in place, 
and part of the model which includes patching.   This is why you are seeing the 
"wtf is new or different about this?" posts.  

<merge>
>Maybe you misunderstood this? If you need empirical evidence that patches
>change code then please do a diff yourself between two apps, one patched
>and one not. Here I was writing of the cost of functional testing and
>remediation of the operational security which scales exponentially as the
>operations scale. One doesn't need a server farm to prove as more servers
>are introduced into an operation that the number of connections between
>them grows. 2 servers each with 1 connection has 2. Add 2 more servers and
>now you have 4 servers but 8 connections to verify. And it goes on like that. 
>If
>you don't do any testing and don't care then you don't have that work or
>money to lose with patching. But I said that already.

The fact that patching changes code is a point so obvious that it doesn't need 
to made.  What I asked for is empirical supporting your claim that your Get Off 
The Patch model actually saves time and money, while ensuring that your 
security is strong enough so that you can decide purposefully not to patch.  
Having a server farm to perform an ongoing cost analysis of the two models is 
absolutely required if you are going to present this idea to even the most 
basic of management personnel.  

When you go to management with a paradigm shift that will require clearance 
from legal, policy, engineering and development teams, you will have to show 
them a clear and unambiguous reduction in costs and risks that will justify the 
organization assuming the overall risk of not patching.  When you make claims 
such as "patching is a waste of money" and that it causes costs to spiral 
exponentially, you are going to have to show that.  I submit in this case that 
you can't provide that because you don't have it, and haven't done it.  If the 
patching process truly is a budget-sucking, workflow blocking, administrative 
nightmare as you state, then the evidence of that fact should be trivial to 
illustrate.   And nowhere in the model do you address the costs of the new 
model.   You said, and I quote (which I probably don't have to say since I am 
actually using quotes), "We find that that the right balance of operational 
controls at each interactive point within a vector can provide p
 rotection against 100% of the threats including unknown threats."   How did 
your "we" find that?  You found it HOW?  This statement clearly states that YOU 
HAVE DONE THIS, but I'm confused as to why you would then respond with "I don't 
need a server farm to prove this."  You are stating that you have found a way 
to protect against 100% of threats, including unknown threats.  That statement 
alone wins you a spot on "The Wackiest Things Said on an ITSec List Show" but 
it also illustrates that you completely miss the point about illustrating risk. 
  Qualifying threats does no good if you have not quantified risks.  

How exactly is this going to be presented to management? "Hey, the million 
dollars we spent to whack the servers with a rubber chicken to scare away the 
vulnerabilities has been a complete waste of money, and though that was our 
idea in the first place, we now have a new idea where we are going to do "other 
things" and ignore the vulnerabilities altogether.  By doing so, we will take 
care of 100% of all threats known and unknown. However, we don't know how much 
that will cost, how much it will save, or what we will do for jobs once we set 
it up so that 100% of all threats known and unknown are protected against."

How is anyone supposed to actually consider this when you have no data to show 
that it works since you've not actually done it in production environment of 
consequence?  Is the expectation that management is going to OK this (as well 
as legal, engineering, etc) when you've already illustrated that you can't 
manage patches in the first place without costs spiraling out of control?

I know this is all a harsh response, but your continued dialog on the subject 
illustrates that you seem to actually believe this is viable in the absence of 
any examples of it working.

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/