-----BEGIN PGP SIGNED MESSAGE-----

hellNbak,

Thanks for giving me the opportunity to clarify the quote in the
eWeek article. In particular, the quote attributed to me;

"It's better for everyone if we keep [this data] to ourselves,"
Cooper said. "Why not keep it amongst the people who are considered
responsible security practitioners? Most attackers aren't smart
enough to write exploits themselves, so they rely on other people to
release them."

I am working to form what I term (for lack of a better one as yet)
the "Responsible Disclosure Forum". Its based on some of the
principles of the CARO model, used by the anti-virus industry today.
In the CARO model, responsible and trusted individuals are sponsored
by other members of the forum for inclusion. Individuals are included
based on their known methods of operation, trustworthiness to other
members, and understanding of the underlying principles of the
organization.

As it would be manifested in the Responsible Disclosure Forum,
individuals would be known to at least a couple of other members,
known to practice security disclosure responsibly, and be willing to
agree to the charter policy of the forum.

The charter policy would be based largely on my published disclosure
policy, a policy which pre-dates the RFPolicy and largely helped form
that policy.

http://ntbugtraq.ntadvice.com/policy.asp

The discussion I had with eWeek was not intended to create the
article which was published. It was a side comment I made that I was
working on such a forum which led the author to ask a few questions
about it. I told him it was a work-in-progress, but he choose to make
it the focus of the article. Unfortunately I haven't developed the
full charter for the forum as yet, so any comments I make about it
now are intended to simply clarify my quotes and not establish the
forum here and now.

What is Responsible Disclosure?
- ------------------------------

Responsible Disclosure definitely does not mean keeping information
from everyone, or keeping it solely in the hands of some clique.
There is, in my opinion and the opinion of others whom I've discussed
this issue with, a difference in the sensitivity of information
pertinent to a given vulnerability.

A product, known as StormWatch, protects your systems by looking for
abnormal behavior of applications, network services, or system
functions. Without knowing what attack is underway, the product is
capable of reducing your attack profile by prohibiting actions not
expected to be taken. Such a product demonstrates the fact that
without specific knowledge of an attack, its still possible to defend
against it (or be immune to it in the first place).

If the internal side of a corporation is "trusted", by whatever means
the corporation satisfies itself, and a vulnerability exposes a
machine to an attack which is then viewed as being "from the Internet
only", then simple router ACLs may be sufficient to reduce the threat
likelihood sufficiently to make fear over a given vulnerability
minimal. Such a reduction in threat likelihood means that
administrators might not need to rush in over the weekend to get a
patch on a box, but instead include it as part of regularly scheduled
maintenance. The difference can mean a significant savings in not
only money, but user confidence too.

The increase in threat likelihood, however, can often be solely the
availability of an attack tool or the disclosure of specific details
such as the byte offset of a buffer overrun. These details rarely if
ever accompany a Vendor advisory of a vulnerability, but now seem to
have become a "must have" in non-Vendor security advisories. Where
they're not included in advisories, say due to an attempt at
Responsible Disclosure, they are often crafted quickly by the public
and posted for anyone to use. Often the posting of such details
include new methods of attack, or explanations of what to do once the
attack has been successful. And of those, some even propose uses for
the attack which are clearly not in the interest of security.

Its that abuse of the collective knowledge of the Internet community
that puts many organizations at risk. Granted, had the vulnerability
not been left in the code by the Vendor, organizations wouldn't have
been at risk in the first place. However, the belief that more
disclosure leads to more secure code is one that hasn't been borne
out in more than 20 years of disclosure (yet its still a widely held
belief). There are more vulnerability disclosures on Bugtraq in the
last twelve months than there had been in the previous, and the
previous before that. Each disclosure has the potential of being
exploited, either against an individual corporation, or against the
net as a whole.

The number of individuals who read disclosures that actually do
anything with the details, such as an exploit tool or byte offset, is
extremely small. And of those, most have a provable interest, meaning
they work for a security company, Vendor, as an ISV, or for an
organization with a sophisticated enough security practice to make
use of such details. The average network administrator hasn't the
time to verify the veracity of a vulnerability claim by using a tool
or coding up an exploit to run against a buffer. They will, however,
have to make the time to get the patch installed as soon as its
available because such details have been published to the
world-at-large.

There-in lies the problem, and I believe, the solution.

For most people, they want to be sure that the following conditions
get met;

1. If a vulnerability is discovered in a Vendor's product, a fix must
be produced and given to them.

2. Vendors should not be allowed to feel free to leave
vulnerabilities in their code, the public demands more secure
software with fewer vulnerabilities. Ergo, Vendors need to be
adequately chastised for their mistakes. Some metric needs to be
established to rate the performance of Vendors so the public may see
whether a Vendor is getting better or not.

3. They must be able to have confidence in their software,
specifically that it can be secured if appropriate steps are taken to
do so. If an attack is possible against their systems they must be
informed as to what steps can be taken to mitigate the attack, or
prevent it outright.

4. That information about their vulnerability to a particular threat
not be transmitted to the world-at-large. They choose to have as few
people as possible know whether or not they are vulnerable. They're
not looking for an excuse not to patch, but they don't want attackers
given additional information (that the attacker themselves have not
discovered) that could be used to determine their vulnerability to a
given threat. They need time to get patches deployed, tested, etc...

Individual analysis cannot replace peer review. Many conditions must
be met before a public threat or cure is published responsibly. The
alternative is that the public trust in the system breaks down and
quacks rule.

This is pretty much the case today. Anyone can decry a collapse of
the net, the immediate loss of all of your private information or
files, or the debasing of the Internet economy. The media loves such
"expert analysis", promotes it, and sends it to the masses
embellished to get the greatest ratings. Security products Vendors
abuse this fact as part of their marketing, some even "creating" the
attack their new product is designed to protect against. Still others
apply their skill to "convincing" consumers they're using the wrong
products, attempting to coerce the public to their ideals.

Surely this isn't accomplishing the goals of the average consumer.

The basic idea of the Responsible Disclosure Forum is that a group of
experts and trusted researchers review and evaluate vulnerability
information. This includes all of the people mentioned above. The
group agrees essentially, amongst other things, not to disclose any
of the details prior to peer review.

Details is yet to be defined. Its often a subjective term when used
to describe elements of a vulnerability disclosure.

The public's need to know is balanced by what is actually known and
verified. The group, not I, make that decision. The public might be
informed at various stages. Should a workaround be possible and a
threat imminent, the public might be informed very early on (e.g.
within hours of disclosure). Otherwise the Vendor is expected to
provide a fix ASAP. As my policy has stated for years now, the time
that might elapse in such a situation varies and is dependent on many
factors. First and foremost, however, its the Vendor's obligation to
keep the Forum informed about progress, obstacles, and projected date
of completion.

There is absolutely no attempt to keep information from the public
that needed to keep them secure. The determination of what the public
needs, however, is made by the Forum as a collective and not by
individual discoverers.

The Forum would keep track of outstanding issues by all Vendors
participating, ensuring that less important (to some) vulnerabilities
don't fall through the cracks into obscurity.

Eventually, likely in all cases, the public would be informed about
the issue. The extent to which the general public receives details
would vary. Usually the information would come to the public via the
Vendor's security advisory mechanism, possibly with additional
unbiased commentary from the Forum about the scope and sensitivity of
the vulnerability. Vendors are already limited in what they can say
about a particular patch, the Forum would not be.

Many fields of research have benefited from the implementation of
some form of peer review prior to publication. Public trust has been
established and maintained as a result. With a relatively large group
of Forum members with varied backgrounds, all committed to the
public's security, nay-sayers should be hard pressed to dismiss or
condemn the effort.

Anyway, there's obviously much to work out still. My intention was to
more fully define the Forum, its method of operation, charter and
membership policy, and then put something out to the list for general
discussion. Discussions that I've had with Vendors thus far are
entirely in their infancy.

Any comments that you might have are welcome.

Meanwhile, I'd also like to address the comments about MSADC/RDS.

>Let us look at how Russ handled the MSADC/RDS issue a few years ago.
> Russ took this information that one of his sheep err I mean
>faithful posters gave him and kept it to himself for a day or so.
>Then, Mr. Cooper decided that he needed some media attention so he
>called his buddy at MSNBC then posted to his own list a high level
>vague rant about some new vuln he knows about. Lucky for us,
>someone else came along and discovered the issue and quickly posted
>it for all. Do we really want to hand Russ all of our 0-days and
>trust that he will do the right thing? I certainly do not.

When I received the information about the non-DSN method of attack
against RDS I immediately sent it to Microsoft. So its not true that
I kept the information to myself at all.

What I did do was attempt to practice what I described above. Since a
workaround was available (and already published by Microsoft a year
prior to the new attack method), I sought to try and get people
re-alerted to the issue. Microsoft re-released their bulletin, and an
attempt was made to get anyone concerned about the issue fixed prior
to the attack method being published.

Clearly my attempt failed somewhat. No doubt that the non-DSN RDS
attack method, discovered by Greg Gonzales and publicly described by
RFP, is the single most frequently used attack against IIS servers.
My message provoked some into exploring the potential attack more
deeply than they had previously. Its arguable as to whether or not
this would have happened had I not sent the message I did.

I'd be curious as to how you think it was "lucky" for you, or anyone
else for that matter, that someone else came along and described the
details I was vague about. Certainly many people have had their sites
compromised by attackers crafted out of the details disclosed, and
despite all of the talk and media hype over the issue many more
remain vulnerable to the attack method. So what purpose was served by
the details being published? How was the public more protected by
those details, given that the issue had already been published a year
earlier? The fix didn't change.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2

iQCVAwUBOzhbfxBh2Kw/l7p5AQE0EQQA3ar8GdYRL8oQRZVaAg9SwRILhDNs2ZlE
MU7ZYCULp/YT5eyBIIiM2jqtoMGENQBGVosFwrD8MY4Y2dVDN8oSkZINtTC9KdCr
Kgps3BV9Ynd1dI5dtmiZNabJMkFkvwyShvkzCEC2e56ki+hfqOBAb5CJ5LefEk9l
/x4YOEFtupU=
=Mhnq
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]