Re: [Full-disclosure] Getting Off the Patch

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

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/