An open letter to the Security Community:

SBS Podcast - listen to the SBS support team

TrackBack — Sun, 16 Oct 2005 02:31:00 GMT

re: An open letter to the Security Community:

bradley — Sun, 23 Jan 2005 15:58:00 GMT

At the risk of throwing more fuel on the fire of this thread, it should be noted that all parties to evaluation of exploits be aware of the perspective and position of all other parties...

- Some parties only want assurance that they are secure. They don't want to know the details, they only want to be assured that when they deploy it won't be compromised.

- Some parties wish to know when they are not secure. They might assume that no single Vendor can provide a complete Security solution so they might want to know details so that they can fill in the gaps current solutions may not address.

- Some parties believe the standard at which a vulnerability should be addressed is if it can be described theoretically in detail. This description must be based on known, provable methods and describe how an exploit can be constructed even if a working example is not created. Note though that without a working example this leaves the analysis open to criticism.

- Some parties believe the standard at which a vulnerability should be addressed is if a working example can be created. This is certainly proof positive, but is akin to locking the barn door after the animals have escaped. By the time this stage is attained, it should be assumed that <many> people across the world have done the same thing whether the vulnerabilty or exploit is publicized or not because all the ingredients for the exploit will be widely known and discussed by then. In other words, if this is the standard it should be assumed that a very large number of computers have been compromised by the time a patch is released although the true number may never be made public.

Security is never an easy topic to discuss whether you're talking about computing security, Homeland Defense security and is even fundamental to the arguement whether Open Source or Closed Source is more secure. There is probably no simple answer what standard should be set in any situation which protects the interests of all or even if it's not possible and only compromises are possible.

Then, it should be noted that it is never in the interest of any Vendor to say their products are not secure, so it is proper business to set policies and standards which are reasonable to the business evaluating security which make good business sense... but note that the self-interest of the vendor may not always be completely consistent with the interests of any other party.

I want to close by emphasizing that I'm not criticizing any Vendor at all but am pointing out that every person or party must determine for itself/himself what they need to do to feel comfortable about security.

Tony

re: An open letter to the Security Community:

bradley — Thu, 20 Jan 2005 11:33:00 GMT

As someone who has worked in this industry for (close to) 30 years and who is charged with the IT operations for a midsize organization I have to say I disagree totally with you. Your attitude amounts to ignorance is bliss and does your clients an absolute disservice.

I f you are that tired and annoyed with having to deal with these issues perhaps it's time for a career change.

(Mn I need new glasses... I can't pick out your verification image at all... at least not yet)

re: An open letter to the Security Community:

bradley — Mon, 13 Dec 2004 23:08:00 GMT

The facts of Tony's 3-yr-old complaint are as follows:
No less than three teams (MSRC, SBS and ISA) have examined Tony's claims multiple times over the last three years.
Each time he made formal notice as opposed to posting in a newsgroup or other public forum, it was taken seriously and examined in the context of the issue as described.
Fortunately for the SBS / ISA users, no actual vulnerability was either demonstrated or found. Had there been any such vulnerability, it would have been addressed in accordance with Microsoft Security directives.
since no vulnerability was demonstrated then or since, no response from Microsoft is to be reasonably expected.

HTH,
Jim

re: An open letter to the Security Community:

bradley — Mon, 13 Dec 2004 18:11:00 GMT

Keep in mind that when "I" define targeted, I mean that Dr. J [aka Jesper Johansson] is not sitting on the other side of my RJ45 connection specifically doing pen testing on my SBS box. That's being targeted.

I define "targeted" like the big guys.. Ford, Microsoft, Gap, The Whitehouse.gov web site, military. That's targeted. We're hit along with others, the Code Red/Nimda/Blaster attacks, the SMTP auth attacks but I would argue we're "bot-ed" down here, we don't have one human being on the other side of our RJ45 thinking to themselves "hmmmm.....I'm going to hack into that SBS box".

re: An open letter to the Security Community:

bradley — Mon, 13 Dec 2004 16:21:00 GMT

The one point that you seem to keep making, and I totally disagree with is the "Down here, my community is not specifically targeted. We're road kill." Hardly ANYONE gets specifically targeted. When I can just point a vulnerability scanner at a class B network, and come back with all the machines that will be "hackable", there's no need to target specific businesses. And think of how many small law firms are running SBS. Just because you think your network is below the radar, doesn't mean all SBS networks are.

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 20:23:00 GMT

1) The release of an exploit often encourages people to patch. (hmmm)

I would argue that the community is getting better on this

2) An exploit is usually easily reverse engineered from the patch.

True, and I acknowledged that. But there is no need for folks like eEye.com to publish such DETAILED disclosure statements to effectively give the map, the keys to the MACK truck and make sure the tank is filled to the brim with diesel before sending the community on it's way.

The disclosure argument (again and again)

TrackBack — Sun, 12 Dec 2004 19:42:00 GMT

I know this argument has been going on for years and years, but the debate about God existing has been going on for longer so don't complain :)I would love to see if I am going completely wrong. This time the staging ground is Susan Bradley's blog. A quic

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 19:35:00 GMT

Oh I also forgot to mention the obligatory:
1) The release of an exploit often encourages people to patch. (hmmm)
2) An exploit is usually easily reverse engineered from the patch.

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 19:32:00 GMT

...and until we get the corporations to kill off NT and 9x... we're stuck with architecture that's 10 years old.

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 19:30:00 GMT

But put together a Windows kind of OpenBSD that has features over security and you get..... Windows and you are patching.

As even Dr. J has said, the most secure system [beside the server encased in concrete at the bottom of a trench] is OpenBSD with a command line.

Course I'd be sitting in front of it going... okay nice...but where's the GUI and the wizards folks!
:-)

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 19:25:00 GMT

This is a thorny issue that has been discussed for more years that I have been alive (I think). Whatever view you take the, unfortunate, reality is that it won't stop. Education may mitigate some of it but there are some benefits to disclosure, for example, nessus, snort, oval and virus signatures, which on some occasions (not enough) provide the temporary barrier required to roll out the patch. I do think Tony has a point about core architecture however. I don't want to start an OS war, but have a look at the number of vulnerabilities and patches for FreeBSD and Debian stable. Then have a look at their excellent patching systems (ports and apt for example). Makes one think.

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 15:06:00 GMT

Tony, I"m assuming you are referring to the issue where you claimed that the default install of SBS caused it to be a mail relayer? You and I know that this was not then nor is it now a security issue.

Your claims that the standard way that SBS was set up was a relayer just was not of merit.

During those three years you could have submitted your findings to secure@microsoft.com at any time if you felt that it was not getting the attention it should have, but you did not.

Even now you recommend a methodology to server publish Exchange that is highly dangerous, unsupported and untested.

We regularly question Microsoft on their rankings on the bulletins and as they say they give a "consensus" view. There are times I personally rank something higher than they do because of my network.

Again, if you disagree with the bulletin information, the email address of secure@microsoft.com is the place to communicate.

re: An open letter to the Security Community:

bradley — Sun, 12 Dec 2004 09:44:00 GMT

Well Susan,
I could almost agree with you, but there's plenty of blame to spread around.

You're aware of a recent blowup involving me on a List involving a Security Issue which I had periodically submitted to Microsoft for over 3 years without any kind of response or acknowledgement that someone would look at it or that something would be done.

Just silence. For 3 years. And, probably for the very reason the blowup on the List happened, because very knowlegeable people in their minds felt it was an impossibility and didn't have the imagination to believe the impossible was possible.

I can also point out that it may be a matter of opinion how serious vulnerabilities are when they exist. A pet example I feel stands out is the possible Man in the Middle attack on a standard TS session. It's highly unlikely. It's extremely difficult to pull off. The circumstances for an attack to be successful shouldn't exist. But, it's only highly improbable and not anywhere close to impossible. And, it should not be overlooked that the consequence is <full system compromise>. And this all adds up to a stretch how Microsoft officially classifies this vulnerabiltiy, as "Medium."

Personally, I feel that anything that means total system compromise no matter if the attack is difficult has to rate higher than "Medium." I also don't like the fact that I have not seen Microsoft recommend how it's possible to configure to address this issue, MS just acknowleges the issue and leaves it at that.

I feel comfortable discussing this latter issue publicly in some detail because it's been discussed publicly aplenty already and it's no mystery but I won't detail the other because I don't think it has been discussed as much publicly yet.

As for Microsoft's responsibility, I won't give MS as quick a pass as you might but I do temper criticism because IMO it's important to balance "What the Consumer Wants" because if nothing else MS is doing exactly that... delivering a product based on Marketplace Consumer demand for a wide array of functionality a non-technical User can manipulate for a certain price. When the Marketplace changes, demands better security and either pricing, competition or regulation changes, then MS will have to adjust or face the consequences.

There is no doubt that if the architecture was fundamentally sound we would see fewer problems and for that reason like many other analysts I eagerly await Longhorn and fuller integration of dotNET, leaving behind COM and its issues.

I frankly also disagree that a multitude of threats is an excuse for being a perpetual victim, and I hope that Longhorn will deliver on its promise in better internal validation of processes and data, modularization and decreasing the attack surface to something manageable. Surrenduring to failure is simply lack of imagination and poor design and should not be acceptable.

IMO, but that's just me.

Tony