Full Disclosure mailing list archives

Re: Getting Off the Patch


From: "Thor (Hammer of God)" <thor () hammerofgod com>
Date: Mon, 17 Jan 2011 18:26:10 +0000

I will again merge fragmented threads.

Phocean,

I can't leave that one. Seriously and with all the respect I have for
you, have you ever worked for a large company ?

Of course.

Fortunately this isn't the type of list where people would challenge your "large company" experience by noting that in 
spite of this type of background, you chose for your Wikipedia page to highlight the fact that at 16 you were part of 
"sting operations" by setting up people who served beer to minors, and that you are an asshat for saying things like 
"they don't build fences for people like me."  Well, this may be that kind of list, but I certainly wouldn't stoop to 
that level. 

Now, what I did there was insulting, confrontational, and a general shitty thing to do.  I positioned myself as someone 
who doesn't indulge in trivialities while doing exactly what I said I wouldn't do.   I don't really think you are an 
asshat; for the most part I think that you are really trying to help the industry (though the SANS-like 
pay-for-training may confuse that).   

But with this approach, you are asking us to do the exact same thing when we go to management.  When you identify to 
management that you are qualified to make analyses regarding costs racing out of control and exponentially growing, you 
are basically calling them idiots for not beings able to identify that on their own.   And you do this while telling 
them that the failure to properly patch is not your fault even when you were hired to secure the environment.   This 
mindset is then backed up with the "management has no idea what we do, and they couldn't understand if they tried" 
stopgap which allows security to blame management for their ignorance without taking any responsibility for their lack 
of ability to educate them properly.   Management isn't going to go away because you can't patch.  You are, and you 
will be replaced by someone who can. 

I am aware one can find tons of counter examples of big companies
failing in having such processes, but it is an organization problem.
Not a patch management one.

Sorry if me trying to help find solutions for those companies bothers you so
much. Please feel free to ignore my future posts and future work then so as
not to waste your time.

You cannot use the "if you don't like my driving then stay off the sidewalk" defense in this space.  You are advocating 
for and actively lobbying for people to stop patching, and to use your method of securing an infrastructure while 
providing surface-level suggestions on how to do so, backing it up with a pay-for-training model.   I've noticed that 
you've backed off your position a bit by throwing in "in conjunction with" and such, which is what everyone has been 
doing for a decade if not more. 

I responded tot he previous example but I should have focused on this one.
There's some interesting things about slammer that I really didn't understand.
Why was the SQL service reachable over the Internet? Why hasn't server
access been limited to only packets within a TTL of 1 or locally only if so
required? Why hasn't the server been better managed to prevent
applications from running or connecting however they want?

I chose that example specifically because it represented an unpatched environment where deployment was based on 
business needs without considering the security implications.   It perfectly illustrates a failure to implement the 
most basic of access controls and affected a huge number of "typical" businesses.  

Since a patch was available at the time, it is the quintessential example of an asset that you claim could stay 
unpatched as long as your security measures were in place.  If the security measures you are talking about are nothing 
but "don't do that" recommendations then your argument is completely wasted.  You are suggesting that those responsible 
for not having simple ingress rules in place can somehow gain the experience to build controls that prevent 100% of 
vulnerabilities both known and unknown.  It also a perfect example of the universities that will not upgrade their 
systems or software, and won't do something as simple as AV.  I'm interested in how you actually expect your model to 
have any semblance of success. 

I asked you to give some examples of your controls where would have prevented this unknown threat.  I would like to see 
some, please. 

I know the OSSTMM isn't the easiest thing to read for some but it is about
trying to make a model that can be re-designed in more specific and more
eloquent ways to help more people understand some basic aspects to making
controls. But if it's not for you and you think that op-controls can't protect
where patches are needed then just feel free to do your own thing the way
you want to.

I didn't find it a challenge to read at all; it was quite easy.  However, you have stated that I am not your target 
audience as I don't have the dire problems you do.  Therefore, if your target is those who cannot figure out how to 
patch, I suggest that if you have an ease of readability concern, it is up to you clearly outline your process without 
making it hard to read.  If you can't expect the people who implement this to understand it, how can you expect them to 
present it to management?

Your stating that "you think that op-controls can't protect where patches are needed" is a complete fabrication on your 
part, and an obvious attempt to present my argument as something it is not in order to substantiate your claims by way 
of nullifying my opinions to validate yours without any other substance.

I have clearly stated that these controls should already be in place, and that patching is a required part of operating 
a business that relies on functioning software.  You somehow think that this is some "new model" or that it is some 
epiphany of security.  It is dangerously naïve for someone who represents themselves as the director of a security 
organization and as such, are qualified to suggest that people not patch.   

I know this is all a harsh response, but your continued dialog

I expected nothing less from you.

I'm glad I have operated with the parameters of your expectation.   I take security seriously, so you can always count 
on me to call Bull Shit first, and then to be all warm, fuzzy, and nice afterwards.  
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/


Current thread: