Message-ID: <58DB1B68E62B9F448DF1A276B0886DF16EBD5214@EX2010.hammerofgod.com>
Date: Mon, 17 Jan 2011 17:24:33 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "lists@...com.org" <lists@...com.org>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
Subject: Re: Getting Off the Patch

(top posting)

So, you have no data to support your claim other than "I think that sucks, so this must be better."  Thanks. 

t
>-----Original Message-----
>From: Pete Herzog [mailto:lists@...com.org]
>Sent: Monday, January 17, 2011 9:02 AM
>To: Thor (Hammer of God)
>Cc: Valdis.Kletnieks@...edu; full-disclosure@...ts.grok.org.uk
>Subject: Re: [Full-disclosure] Getting Off the Patch
>
>
>> No, I do not run a patch management company, but despite that,
>
>I don't feel I scrutinized patch management in any way other than to say doing
>patch management costs something and not doing it does not cost that
>something. I think that's a fair assessment regardless of my patch
>management experience.
>
>> Coming up with some way of creating a dependency on new, additional
>
>I see examples out there of those less successful than you at implementing
>controls properly and in the right places. One of the things about the model of
>patching I don't like is how it requires constant administration and one that I'm
>hoping to avoid by either combining it with existing change control or, where
>there is none, to bring a bit of order to a stochastic environment. You're
>apparently not my target audience then.
>
>> The fact that patching changes code is a point so obvious that it
>
>When we create models we do it on the prospect of improving something.
>We don't expect much to shift right away but we will see the shift in
>5 to 10 years time. This no-patching we tried on a small scale (few servers and
>a few desktops) and there's ever more people implementing it that I hear
>about on ever growing scales. I have heard of a university looking to
>implement this for their computer labs which suffer many infections during
>the school year. They also won't upgrade their systems and are worried about
>when support ends and the patches stop. But that's just one example and
>one reason why and really I haven't seen this yet on the scale you're looking
>for. ISECOM certainly doesn't have the funding to afford a server farm to try it
>out.
>
>I know this isn't something you find particularly useful. You made that clear.
>It's not for you, and then again, why would you change if you're happy with
>the way things are going for you? New models exist for people who have a
>problem that they haven't been able to solve under the existing means.
>Apparently you have. So this is research into new models for those who the
>old model doesn't work for.
>
>>
>> When you go to management with a paradigm shift that will require
>
>Organizations who are looking for better security have come to us and begun
>implementing this piece by piece in their problem areas. I don't think anyone
>anywhere would completely change on the spot. That makes no sense. It's a
>gradual thing. People use new models, like this, in their problem areas first. As
>it works for them and they adapt to it, then they move forward applying it in
>other places. Many times, they have an emotional attachment to a process or
>are so deeply integrated into another model that anything else sounds crazy. I
>understand that and I'm not looking for those people to just jump on board.
>
>Just to be clear, one doesn't need a server farm to prove something.
>There's many other ways besides a server farm. Yes, a server farm is a good
>test environment but not one we can afford. In this case we did get it to work
>consistently on various servers and desktops, in the real world, over the
>Internet, for over 5 years. We began to share this with others who slowly
>adopted it in places where they needed it or where it wouldn't hurt to try it.
>Some it took years to get over the feeling that they should be patching or
>running anti-virus just because. The money that was saved was not just from
>patching alone but from licenses and new software, specifically those who
>had to buy the newer OS versions to keep getting support patches, new
>updated app licenses, sometimes new hardware, and all the auxiliary costs
>from having newer, untested stuff in house still administered at the same
>level as before.
>
>Now, my goal is not to get you to turn over your business to the model but
>instead, to get more people to try it and learn about op controls and OpSec.
>Clearly it makes you uncomfortable and even find it "wacky". So don't do it.
>
>>
>> How exactly is this going to be presented to management? "Hey,
>
>Just change as quickly as you are comfortable with. From what I know is that
>many businesses don't like to change things that work. Even me. However
>most people are more than happy to attack problems that never seem to go
>away. That's how you try it. You first approach the problem areas that defied
>other solutions or are absorbing too much of your time.
>
>>
>> How is anyone supposed to actually consider this when you have
>
>People will consider this if they have a problem where the old model of
>patching as security and other black-list approaches is not helping them.
>People will consider this who need perfectly balanced security with their
>operations. Then they will try it somewhere small first and grow it as they
>need it.
>
>>
>> I know this is all a harsh response, but your continued dialog
>
>I expected nothing less from you.
>
>Sincerely,
>-pete.
>
>--
>Pete Herzog - Managing Director - pete@...com.org ISECOM - Institute for
>Security and Open Methodologies www.isecom.org - www.osstmm.org
>www.hackerhighschool.org - www.badpeopleproject.org

_______________________________________________
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