Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Getting Off the Patch
From: Zach C <fxchip () gmail com>
Date: Fri, 14 Jan 2011 12:31:21 -0800

Just on top of this, I would like to ask a question of Pete in the form of an example.

Pete, let's say one of the assets I want to protect is the code for my site running on the web server. Now, let's say 
my web server has a serious bug that allows a given attacker to read the raw contents (i.e. code) of *any* file the web 
server has access to. In this circumstance, the web server still must be able to interact with these assets by reading 
and subsequently executing them for continued operations, but it is this very same vector that is being exploited by 
the attacker. Are there any controls, besides patching, that can be applied here without inhibiting current operations 
in any way? (Switching web servers not being an option for various reasons, even though that's where I would go first).


On Jan 14, 2011, at 11:08 AM, "Thor (Hammer of God)" <thor () hammerofgod com> wrote:

[Combining Threads]

-----Original Message-----
From: Pete Herzog [mailto:lists () isecom org]
Sent: Friday, January 14, 2011 10:19 AM
To: Thor (Hammer of God)
Cc: Valdis.Kletnieks () vt edu; phocean; full-disclosure () lists grok org uk; Zach
Subject: Re: [Full-disclosure] Getting Off the Patch

It's brilliant!  Where do I sign up?


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

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.  

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
  protection 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.


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]