Second draft of CyberCrime Treaty Statement

[Adam Shostack <adam@HOMEPORT.ORG>]

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