RE: Second draft of CyberCrime Treaty Statement

[David LeBlanc <dleblanc@microsoft.com>]

Looks like we're getting some convergence - comments on the draft:

> (Should we mention Stackguard here?  It wouldn't be available without
> exploit code.?)

I don't think so - too specific, and a lot of them won't understand what it
is or why it is important.

> 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.
>
> (I think that this language is counterproductive, and suggest:

Agreed - this is the NRA argument with guns, and a lot of people don't buy
it.

> If the treaty causes to be banned the creation or use of exploit
> tools,

This clause needs some wordsmithing.

>without recognition of their valuable role, then communication
> and research will be stifled,

>and many young security enthusiasts who
> today behave unethically will be made into criminals, and lose their
> opportunity to mature and grow into valuable members of the
> community.  We urge that appropriate laws criminalizing the misuse of
> such tools replace the ownership or creation clauses. )

I don't like this - there's a lot of truth in it, but it isn't going to fly.
"young security enthusiasts who behave unethically" == Satan as far as the
treaty writers are concerned. OTOH, sysadmins trying to protect their
networks from the barbarians will fly.

> More contraversial:

I find it less controversial.  YMMV.

> We urge that appropriate laws criminalizing the misuse of
> such tools replace the ownership or creation clauses, and further that
> the Council fund research into ways to encourage companies to produce
> more secure software,

We were doing really well up to here...

>such as, but not limited to, recinding warranty
> law exemptions, requiring recalls of bad software, etc.

Somehow, I doubt I can get blessings from on high for this part. 8-/
Something tells me that any of us who work for a software vendor can't go
with this.  What happens when your programmer screwed up, the check doesn't
work quite right, and the customer gets hacked? Your security vendors would
be litigated out of existance. Defining 'bad' is a nightmare all by itself.
Also, let's keep this narrowly scoped, else we'll argue forever.

How about:
We urge that appropriate laws criminalizing the misuse of such tools replace
the ownership or creation clauses, and that ownership, creation and
authorized use of these tools by security professionals and researchers be
explicitly allowed. Further, it is recommended that the Council fund
research into ways to improve the security of new software, protocols, and
network management.


> -----Original Message-----
> From: Adam Shostack [mailto:adam@HOMEPORT.ORG]
> Sent: Wednesday, May 10, 2000 7:59 AM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: Second draft of CyberCrime Treaty Statement
>
>
> On Tue, May 09, 2000 at 11:45:41AM -0400, Frech, Andre
> (ISSAtlanta) wrote:
> | Steve and Stuart,
> |
> | Excellent work. I appreciate your efforts in developing this draft.
>
> I do as well.  I have to say I'm very pleased with the willingness of
> so many people to move forward to address these issues.  Thanks
> especially to Stuart, Steve and Andre for stepping forward to draft
> language.
>
>
> Dear <treaty drafters>
>
> We are a group of security experts who participate in the Common
> Vulnerabilities and Exposures Initiative.  This project is a
> collaboration between a range of responsible computer security experts
> and companies 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.
>
> 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 violate
> the security of computer systems.  We note that it is critically
> important to the advancement of science and engineering techniques 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.  In addition, these
> exploits are often included in commercial tools used by systems
> administrators and security experts to test the security of their
> systems.  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.  Further,
> important tools and techniques are regularly revealed by previously
> unknown individuals or groups.  To criminalize their research and
> educational activities would be to slow the important progress of
> computer security research.  We do not intend to challenge the idea
> that breaking into computer systems is wrong, but to ensure that laws
> are not made driving underground new research.
>
> (Should we mention Stackguard here?  It wouldn't be available without
> exploit code.?)
>
> We are concerned that Article 6 may prevent, impede, or criminalize
> such responsible development and use of exploit tools.  This would
> greatly limit the ability of systems and security administrators to
> test and validate the security of their systems, either through the
> use of freely available research tools, or with commercial tools, as
> are sold by several of the organizations involved with CVE.
>
> We ask that the treaty drafters recognize the legitimate and important
> role that the creation of demonstration code plays in advancing the
> security field.  We ask that the treaty be re-worked so as to not
> chill or limit ethical and important research.
>
> 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.
>
> (I think that this language is counterproductive, and suggest:
>
> If the treaty causes to be banned the creation or use of exploit
> tools, without recognition of their valuable role, then communication
> and research will be stifled, and many young security enthusiasts who
> today behave unethically will be made into criminals, and lose their
> opportunity to mature and grow into valuable members of the
> community.  We urge that appropriate laws criminalizing the misuse of
> such tools replace the ownership or creation clauses. )
>
> More contraversial:
>
> We urge that appropriate laws criminalizing the misuse of
> such tools replace the ownership or creation clauses, and further that
> the Council fund research into ways to encourage companies to produce
> more secure software, such as, but not limited to, recinding warranty
> law exemptions, requiring recalls of bad software, etc.
>
>
> Adam
>
> "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]
> | >
>