Summary of CyberCrime treaty discussions
Below is a summary of all Editorial Board discussions of the Council
of Europe's "Draft Convention on Cyber-Crime" treaty.
Response from Editorial Board members
There are currently 26 different organizations represented by Board
- 10 actively participated in creating a response
- 4 members have publicly or privately expressed support for
creating a response
- 3 members have expressed no opinion
- 9 members have not responded to my personal emails and/or email
sent to the entire list.
Since two of the 4 supporting members can only support this response
privately at this time, we can only be certain that 12 of the 26 might
be able to sign something. One of the non-public supporters suggested
that it may be easier to show public support if the Board statement is
focused entirely on the technical concerns.
However, given that even a majority has not been reached, it is
probably inappropriate to present a statement that has occurred from
the Board as a whole. I have discussed the issue of Board
representation with MITRE management. At this time, we believe that
it is not appropriate to make a statement "as the Board" without full
support (or a definite "no opinion") from all members. However, we
could present the position as "members of the Editorial Board." While
some Board members believe that a full statement by the Board itself
would lend additional legitimacy and strength to the statement, any
disclaimers in the statement could weaken its impact as well.
Relevant Extracts from the Treaty
Here is a short description of the relevant portions of the treaty, as
deemed relevant by one or more Board members.
Treaty - http://conventions.coe.int/treaty/en/projets/cybercrime.htm
Article - http://wired.com/news/politics/0,1283,36047,00.html
The "Council of Europe" released the draft treaty "for public
discussion in order to enhance the consultation process with
interested parties, whether public or private. Businesses and
associations are particularly encouraged to share their comments with
the experts involved in the negotiations."
Extracts from Article 1 - Definitions:
a. "computer system" means any device or a group of inter-connected
devices, which pursuant to a program performs automatic
processing of data [or any other function]
b. "computer data" means:
- any representation of facts, information or concepts in a
form suitable for processing in a computer system, or
- set of instructions suitable to cause a computer system to
perform a function
- [a footnote says: "The concept of computer data includes
Article 2 advocates defining legislation against illegal access: "the
access to the whole or any part of a computer system without
right. A Party may require that the offence be committed either by
infringing security measures or with the intent of obtaining
computer data or other dishonest intent."
Article 3 advocates legislation against illegal "interception without
right, made by technical means, of non-public (7) transmissions of
Article 4 advocates legislation against "data interference," and
Article 5 describes "system interference." Both of them describe
"the damaging, deletion, deterioration, alteration or suppression of
Article 6 is of greatest concern to the Board members who have
discussed the issue. It advocates legislation that prohibits "the
production... procurement... or distribution" of:
1. "a device, including a computer program, designed or
adapted... for the purpose of committing any of the
offences established in accordance with Article 2 - 5"
2. "a computer password, access code, or similar data by which
the whole or any part of a computer system is capable of
being accessed with intent that it be used for the purpose
of committing the offences established in Articles 2 - 5"
Article 6 also describes the following as a criminal offense: "the
possession of an item referred to in paragraphs (a)(1) and (2) above,
with intent that it be used for the purpose of committing the offenses
established in Articles 2 - 5."
Article 7 describes "Computer-related Forgery" and advocates
legislation against "the input, alteration, deletion, or suppression
of computer data, resulting in inauthentic data with the intent that
it be considered or acted upon for legal purposes as if it were
authentic." Article 8 uses similar language but applies it to
Article 11 encourages legislation against "Attempt and aiding and
a.attempt to commit any of the offences established in accordance
with Articles [garbled text]
b.aiding or abetting the commission of any of the offences
established in accordance with Articles 2 - 10 above.
Other articles describe child pornography (article 9), copyright
violations (article 10), corporate liability (article 12), and the
requirement of sanctions (article 13).
There are two more sections in the treaty which deal more with
procedural issues. Sections 2 and 3 (articles 14 - 19) are related to
procedural law and jurisdiction. Chapter III (articles 20 - 29)
relate to how the parties will cooperate, e.g. with respect to
extradition, data preservation, etc.
HIGH LEVEL SUMMARY OF BOARD DISCUSSIONS
The following is a summary of the discussion threads that have
occurred on the Editorial Board mailing list and in private email.
There are 2 primary subjects: specific issues with the treaty, and the
role of the Editorial Board in commenting on it.
At a high level, participating Board members agreed that article 6, as
written, is too vague; thus it could inadvertently limit legitimate
study. Participants also agreed that it is difficult or impossible to
be able to distinguish between legitimate tools and malicious ones,
and that often a tool that could be used maliciously is also an
important resource for legitimate uses such as research and auditing.
Members did not agree as to whether the treaty's language allowed
legitimate use of tools that could be tailored to malicious purposes;
legal counsel would be helpful in this regard. The phrase "without
right" used in articles 2 and 3 was particularly problematic. Some
members suggested that exploit code shouldn't be made illegal, but
rather how it is used, i.e. somehow associating it with the person's
All Board members who expressed an opinion, publicly on the list or
privately, agreed that this aspect of the treaty is an important issue
that needs to be addressed.
There is some disagreement regarding how the Board should present
their comments. While there hasn't been as much discussion on this
topic, it appears that most Board members believe that it is
appropriate for the Board to make a statement. However, one or two
Board members have expressed concerns that a statement could conflict
with the opinion of their own companies, who may be evaluating this
topic independently. Others have submitted this treaty to their
lawyers for review.
TREATY ISSUES - THREAD SUMMARY
- At Netect/Bindview, they created exploit code to show new
vulnerabilities, and occasionally distributed it to others. He
believes this could violate the treaty as proposed.
- "There is no practical way to distinguish exploit code used for
legitimate scanning, testing, and research, and that used for
crimes... we are obliged to follow the law and [crackers]
- criminalization of exploit code could affect CVE, since exploits
often help you distinguish between two very similar bugs.
- treaty has a lack of clarity that "has a clear potential to chill
- The Nessop [probably a reference to Nessus] freeware scanner
contains exploit code that could be outlawed, despite its
usefulness to white hats
- the "without right" text in Article 2 appears to allow legitimate
parties to attack their own systems and/or others who have
- there may be precedents in which something that *could* be used
for malicious purposes isn't necessarily made illegal,
- agrees that it's difficult to distinguish between intentionally
malicious and legitimate attacks/exploits, e.g. exempting
"research" from liability could make the treaty "ineffective
against a larger portion of potential attackers (e.g. students)."
- too many restrictions could cause the industry to lose "the assets
that the brilliant student minds bring to the business"
- because this is a treaty, each country will draft and implement
their own laws
- the treaty should exclude tools, because it "won't work and will
do far more harm than good."
- suggests making it a crime to distribute an exploit without
sufficient notice to vendors
- agrees that the treaty is overly vague
- this could ultimately result in registration/licensing of security
professionals, who would be the only ones legally allowed to
possess such tools - e.g. locksmiths
- this treaty may not apply to non-malicious tools, i.e. those that
identify vulnerabilities but don't exploit them. However,
sometimes the only reliable way to check for the presence of a
vulnerability is to actually exploit it
- so, don't make the code itself illegal, but how people use it
- agrees that this treaty would only constrict the white hats - "it
hobbles us without affecting the malevolent ones."
- the "possession [with malicious intent]" phrase in Article 6 could
make password crackers illegal
- he uses exploit tools in his classes, as a way of teaching
- believes that making exploit code illegal could be constitutional
(i.e. not prohibited by the U.S. Constitution), and observed that
the seizure of Iranian assets during the 1980's could be a
- agrees with Stuart that the treaty should be changed in the early
- could utilize political resources currently available to
individual Board members to garner support
- believes that there is legal precedent which defends source code
as free speech
- is this the Bernstein/Junger case alluded to by Adam Shostack?
- "needs to be a clear distinction between the distribution of
demonstration code and the distribution or use (with malicious
intent) of exploits."
- agrees with LeBlanc's locksmith analogy, but also uses gun
possession - the possession is not the crime, but rather the
misuse of the gun
- Article 6 is vague with respect to defining illegal devices.
Programs that intercept data may be used by system/network
administrators for normal administration duties.
- "a part of normal security administration involves using tools
which are designed to obtain unauthorized access to determine
which portions of your own network may be vulnerable. Making
these programs illegal would severely hinder our ability to test
our defenses against the activities defined in articles 2-5."
- believes that the clause regarding possession of passwords does
not require criminal intent
- vagueness is also a concern to him
- the charter doesn't identify what the legal uses of the tools are
- has sent the treaty onto his legal people for their consideration
- Articles 2-5 imply criminal intent, but legitimate tools such as
router mappers, or utilities that collect usage statistics or
stress testing, are forbidden if executed "without right."
- Article 6 effectively requires that a program/tool needs to
demonstrate a rightful purpose. A program which is hard-coded to
attack a particular system might be a violation, but if it takes
IP addresses as arguments, could be regarded as having a rightful
- any demonstration code could be defended as having a rightful
purpose if people can use it to test the vulnerabilities in their
own systems; e.g. the EICAR test file for anti-virus programs
- so, we must better articulate what "without right" means
- since this is treaty language, we should ensure that the language
"unambiguously supports" the right interpretation of "without
- even if a tool is created or executed "without right," Adam wants
to be able to legally analyze it, e.g. to determine if it uses any
- the openness helps the white hats to keep better track of black
hat trends; "we don't need to see the underground driven back to
silence by fear."
- the treaty will effectively drive the black hats back underground,
but some aspects of the underground should be criminalized to
discourage some activities
- a "special dispensation" clause could be added which effectively
allows some organizations/individuals to possess/use otherwise
prohibited tools, but this would make it attractive to the black
- some types of bombs can be made by anybody, but other types
require licensing; some become illegal only when associated with
- believes that "society is none-to-pleased with the idea that we
might be fostering, encouraging, or even accepting of the actions
of [underground elements]" despite their contributions to white
hats, e.g. Mudge.
- currently, some underground people can be in high demand by
security companies and other organizations, because of their
- also sent to his lawyers for review
- the statement should be "presented as a guide to clearer language
on the subject"
- international treaties can be difficult to change once ratified,
so modifications to this proposal should be made early
- the Board should consult with lawyers or other experts in
- what happens if one country makes exploit code illegal, while
another one doesn't? If the treaty is ambiguous, it could result
in countries having inconsistent approaches.
- suggests that we gain a broader international and governmental
perspective, e.g. with policy makers
- presented an initial draft for the treaty
EDITORIAL BOARD STATEMENT - THREAD SUMMARY
- Advocates making a Board-level statement
- Supports the Board making a statement
- may be difficult to get consensus on a statement from the entire
Board, as some Board members may disagree with the statement
- the Board may be able to agree that laws that should not stifle
CVE and other information sharing efforts
- Board representation: we should not require unanimous consent,
rather a quorum. Or, list the Board members who contributed to
the response. But should try to reach a consensus where possible.
- all or most Board members should be aware of this issue
- not all Board members will necessarily agree with a statement
- a general statement may be agreeable to contributing members
- some Board members have expressed concerns with making a statement
as the Board. We could adopt a statement that is signed and
advocated by Board members, but which is not a statement of the
- if there is a dissenting opinion, capture/include that with a
- a statement by the entire Board would be stronger than one that is
merely adopted by a portion
- suggests a disclaimer that further disassociates the individual
contributors from their organizations
- want to be able to allow the Board to "speak" in some ways even if
there isn't full consensus
- the Board probably cannot achieve full consensus on any issue
LEVEL OF PARTICIPATION
The following Board members have sent comments to the Editorial Board
mailing list that are directly related to the issues at hand.
Other Interested Members
These members have expressed an interest in the proceedings but due to
various reasons, they are not participating actively at this time.
Some members have sent correspondence directly to me, and not to the
Board list. I have recorded their positions below. Some of these
members may have made other comments to the Board list.
One Board member is reviewing the issue internally. Their current
interpretation is that it only affects the use of tools with intent to
commit a crime, so it is not necessarily a problem. They may ask
their own lawyers for an interpretation of the treaty.
One Board member has expressed a concern with the Editorial Board as a
whole making a statement. That member does not have the authority to
speak for their organization and is concerned that their organization
might appear to support the statement by virtue of their affiliation
with the Board.
One Board member does not see a problem with having their organization
support an item, but they would need to see the exact words. They
suggested that we could take the same approach as was taken with the
"DDoS Roadmap" in which various Board members contributed, but the
Board as a whole was not formally recognized.
Another Board member privately supports a unified Board effort, but
cannot speak for their company either. This member agreed that the
treaty needs to be changed to remove some of the vagueness.
Two Board members have confirmed that they are aware of the situation,
but they did not provide any additional feedback.