lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Jan 2011 18:26:10 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "lists@...com.org" <lists@...com.org>
Cc: Zach C <fxchip@...il.com>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Getting Off the Patch

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ