[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 members. - 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. Sources: 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 computer programs"] 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 computer data" 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 computer data." 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 computer-related fraud. Article 11 encourages legislation against "Attempt and aiding and abetting" 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 "intent." 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 ------------------------------ Adam Shostack - 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. Stuart Staniford - "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] aren't." Steve Christey - criminalization of exploit code could affect CVE, since exploits often help you distinguish between two very similar bugs. Adam Shostack - treaty has a lack of clarity that "has a clear potential to chill research." Stuart Staniford - The Nessop [probably a reference to Nessus] freeware scanner contains exploit code that could be outlawed, despite its usefulness to white hats Russ Cooper - the "without right" text in Article 2 appears to allow legitimate parties to attack their own systems and/or others who have approved - there may be precedents in which something that *could* be used for malicious purposes isn't necessarily made illegal, e.g. fertilizer - 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" Stuart Staniford - 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 David LeBlanc - 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 Matt Bishop - 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 computer security - 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 precedent David LeBlanc - agrees with Stuart that the treaty should be changed in the early stages - could utilize political resources currently available to individual Board members to garner support Jim Magdych - 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 David LeBlanc - 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 Mike Prosser - vagueness is also a concern to him - the charter doesn't identify what the legal uses of the tools are Craig Ozancin - has sent the treaty onto his legal people for their consideration Russ Cooper - 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 purpose. - 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 Adam Shostack - since this is treaty language, we should ensure that the language "unambiguously supports" the right interpretation of "without right." - 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 new techniques - 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." Russ Cooper - 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 hats - some types of bombs can be made by anybody, but other types require licensing; some become illegal only when associated with terrorist materials - 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 expertise Mike Prosser - also sent to his lawyers for review Jim Magdych - the statement should be "presented as a guide to clearer language on the subject" Andy Balinsky - international treaties can be difficult to change once ratified, so modifications to this proposal should be made early Dave Mann - the Board should consult with lawyers or other experts in international treaties - 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 Stuart Staniford - presented an initial draft for the treaty EDITORIAL BOARD STATEMENT - THREAD SUMMARY ------------------------------------------ Adam Shostack - Advocates making a Board-level statement Stuart Staniford - Supports the Board making a statement Steve Christey - may be difficult to get consensus on a statement from the entire Board, as some Board members may disagree with the statement Adam Shostack - the Board may be able to agree that laws that should not stifle CVE and other information sharing efforts David LeBlanc - 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. Steve Christey - 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 Steve Christey - 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 Board itself Dave Mann - if there is a dissenting opinion, capture/include that with a statement Adam Shostack - 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 David LeBlanc - 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 ---------------------- Active Contributors ------------------- The following Board members have sent comments to the Editorial Board mailing list that are directly related to the issues at hand. Adam Shostack Scott Blake Andy Balinsky Dave Mann Stuart Staniford Russ Cooper Jim Magdych David LeBlanc Mike Prosser 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. Craig Ozancin Andre Frech Tom Stracener Steve Northcutt Anonymous Members ----------------- 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.