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

RE: CyberCrime Treaty Statement - draft text

A few proposed changes I want to comment on:

*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*

This may be true, but murky isn't going to fly in the current political
atmosphere. We may all realize the realities of this situation, but any
statement on our part that appears to be sympathetic to the black hats is
going to have a negative impact on acceptance.  IF you're going to go into
that at all, be aware that the outside world does NOT understand
black/grey/white hat.  I used those terms in a presentation and got back a
comment that implied I was being racist. I would avoid this whole area,
since we don't need it to make our point.  The point we want to make is that
we're the good guys, and we need these tools to keep your computers safe.

> *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*

I would also avoid this, as the treaty is about making laws, not guidelines
for people writing scanners.

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
> Sent: Monday, May 08, 2000 5:59 PM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: CyberCrime Treaty Statement - draft text
>
>
> All,
>
> 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
> with the "HIGH LEVEL SUMMARY OF BOARD DISCUSSIONS" section.  It
> 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
> possible.
>
>
> 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
> vulnerabilities.
>
> *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>.
>
>
> ** SIGNATURES **
>
> 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
>   affiliation.
>
>
> Signed,
>
> 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