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.
I can't leave that one. Seriously and with all the respect I have for
you, have you ever worked for a large company ?
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
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
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.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/