[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CyberCrime Treaty Statement - draft text


Below is an adaptation of the draft text that Stuart Staniford wrote
up.  Stuart, great job on the first draft - it looks almost exactly
like the discussion summary I just wrote up :-)

We cannot resolve the issue of whether the Board should make a unified
statement within this week.  At MITRE, we believe that we should
ensure that the Board represents all opinions, and/or be certain that
there is a clear way to disassociate Board opinions from a member's
organization's opinions.  That's especially important given that only
about half of the Board members have directly expressed support for
such a statement, and a third of the Board hasn't even acknowledged to
me that they are aware of the issue.  It will take more than this week
to decide how to handle non-unanimous statements properly.

However, there is David LeBlanc's proposal that we provide something
to Howard Schmidt for this week's cyber-security summit.  David -
since the summary I just posted will be publicly available on the CVE
web site in the next day or two, I suggest that you can provide Howard
doesn't carry the weight of an official statement, but it does show
where the vocal Board members are leaning.

Since the timeline for this treaty is December 2000, I suggest that we
have more than a week to refine this statement, so we should proceed
deliberately but carefully.  Perhaps in the meantime we can determine
how to present the statement in a way that addresses the concerns of
the people who cannot support a statement at this time.  This will
also provide additional time to obtain further support (or a
dissenting opinion) from the Board members who haven't registered an
opinion yet.  It would also provide time for active Board members to
escalate the power of statement, e.g. by getting their
CEO's/CTO's/etc. to support it.

My modification to the statement does not name the Editorial Board
specifically; rather, it states that we participate in the CVE
Initiative.  I view this as a way to give the statement some
legitimacy, while giving non-signing members a way of disassociating
themselves from this activity if they need to.

- Steve

Changes from Stuart's proposal are marked with *CHANGE* and *END*.  I
have two suggestions for adding text: (1) include a short statement
that mentions how black/gray hat tools help white hats; and (2) a
suggestion that exploit code should minimize damage as much as

Dear <treaty drafters>

We *CHANGE* are a group of security experts who participate in *END*
the Common Vulnerabilities and Exposures *CHANGE* Initiative *END*.
This project is a collaborative project by a range of responsible
computer security companies and experts to develop a common
industry-wide set of names for the many different vulnerabilities
known in computer systems.  As such, we represent a cross-section of
the technical community which works on computer security

*CHANGE* As security experts, we have some technical concerns with
respect to Article 6, which appears to be vague with respect to the
use, distribution, or possession of software that could be used to
break into computer systems *END*.  We note that it is critically
important for computer security professionals to be able to test
software looking for new vulnerabilitities, determine the presence of
known vulnerabilities in existing systems, and exchange information
about such vulnerabilities with each other.  Therefore, most
professionals and companies in this field routinely develop, use, and
share scripts and programs designed to exploit vulnerabilities.  It is
technically very difficult or impossible to distinguish the tools used
for this purpose from the tools used by computer criminals to commit
unauthorized break-ins.  *CHANGE* [I'd like to make a statement here
that black-hat/gray hat tools often represent innovative research
and/or are the only detailed sources of information that enable us to
build white hat tools.  This would further highlight the murkiness
between the white hat and black hat worlds.] *END*

We are concerned that Article 6 may prevent, *CHANGE* or at least
impede *END*, such responsible development and use of exploit tools.
We ask that the treaty be reworded such that this is clearly allowed.
*CHANGE* [Perhaps we should suggest that exploits/etc. should only
contain the minimal amount of coding to reliably demonstrate the
problem, while minimizing the amount of damage that could be done to
the system; this could omit most truly malicious code (except for
certain blue-screen-of-death DoSes), but it could stifle "aggressive"
probes made by legitimate tool developers.  This approach would also
go against the "punish-the-hackers-not-the-tools" opinion.] *END*

If, instead, the treaty is used to ban any use of exploit tools, we
fear that this will be very counter-productive.  Since computer
criminals are currently largely beyond the reach of effective law
enforcement, they will not be much impacted by new laws banning their
tools.  However, since legitimate companies and professionals will
follow any laws that are put in place as a result of this treaty, our
ability to do our jobs will be severely compromised.

If we can be of further help in drafting appropriate language, please
contact us via <Steve>.


Include text: "Organizational affiliations are listed for
identification purposes only, and do not necessarily reflect the
official opinion of the affiliated organization."

- I suggest that Board members should be able to decide whether to
  list themselves individually, i.e. without their organizational


Adam Shostack, Zero-Knowledge
Scott Blake, BindView
Steve Christey, MITRE

MemberN, OrganizationN
MemberN2, OrganizationN2
Member N+m, [no organization listed]

... and X other members of the CVE Editorial Board [names withheld]

Page Last Updated or Reviewed: May 22, 2007