Last updated at Fri, 31 Mar 2023 20:35:13 GMT

The U.S. Departments of Commerce and State will renegotiate an international agreement – called the Wassenaar Arrangement – that would place broad new export controls on cybersecurity-related software. An immediate question is how the Arrangement should be revised. Rapid7 drafted some initial revisions to the Arrangement language – described below and attached as a .pdf to this blog post. We welcome feedback on these suggestions, and we would be glad to see other proposals that are even more effective.

Background

When the U.S. Departments of Commerce and State agreed – with 40 other nations – to export controls related to "intrusion software" in 2013, their end goal was a noble one: to prevent malware and cyberweapons from falling into the hands of bad actors and repressive governments. As a result of the 2013 addition, the Wassenaar Arrangement requires restrictions on exports for "technology," "software," and "systems" that develop or operate "intrusion software." These items were added to the Wassenaar Arrangement's control list of "dual use" technologies – technologies that can be used maliciously or for legitimate purposes.

Yet the Arrangement's new cyber controls would impose burdensome new restrictions on much legitimate cybersecurity activity. Researchers and companies routinely develop proofs of concept to demonstrate a cybersecurity vulnerability, use software to refine and test exploits, and use penetration testing software – such as Rapid7's Metasploit Pro software to root out flaws by mimicking attackers. The Wassenaar Arrangement could (depending how each country implements it) either require new licenses for each international export of such software, or prohibit international export altogether. This would create significant unintended negative consequences for cybersecurity since cybersecurity is a global enterprise that routinely requires cross-border collaboration.

Rapid7 submitted detailed comments to the Dept. of Commerce describing this problem in July 2015, as did many other stakeholders. The Wassenaar Arrangement was also the subject of a Congressional hearing in January 2016.

Revising the Wassenaar Arrangement

To their credit, the Depts. of Commerce and State recognize the overbreadth of the Arrangement and are motivated to negotiate modifications to the core text. The agencies recently submitted agenda items for the next Wassenaar meeting – specifically, removal of the "technology" control, and then placeholders for other controls. A big question now is what should happen under those placeholders – a placeholder does not necessarily mean that the agencies will ultimately renegotiate those items.

To help address this problem, Rapid7 drafted initial suggestions on how to revise the Wassenaar Arrangement, incorporating feedback from numerous partners. Rapid7's proposal builds on the good work of Mara Tam of HackerOne and her colleagues, as well as that of Sergey Bratus, one of the most important contributions of which was to emphasize that authorization is a distinguishing feature of legitimate – as opposed to malicious – use of cybersecurity tools. Our suggested revisions are below, and an alternate (somewhat cleaner) version is available here.

Our recommendations can be broken down into three categories: 1) Exceptions to the controls, 2) Redefining "intrusion software," and 3) Exceptions to the definition of "intrusion software."

1) Exceptions to the Wassenaar Arrangement controls on "systems," "software," and "technology." These are the items on which the Wassenaar Arrangement puts export restrictions. We suggest creating exceptions for software and systems designed to be installed by administrators or users for security enhancement purposes. These changes should help exclude many cybersecurity products from the Arrangement's controls, since such products are typically used only with authorization for the purpose of enhancing security – as compared with (for example) FinFisher, which is not designed for cybersecurity protection. It's worth noting that our language is not based solely on the intent of the exporter, since the proposed language requires the software to be designed for security purposes, a more objective measure that is already used elsewhere in the original text. In addition, we agree with the Depts. of State and Commerce that the control on "technology" should be removed because it is especially overbroad - removal of this provision alone would be a major improvement.

Here is the Wassenaar Arrangement text with our suggested additions in bold and deletions in strikethrough:

  • 4.A.5.   Systems, equipment, and components therefor, specially designed or modified for the generation, operation or delivery of, or communication with, "intrusion software".

    Note:  4.A.5 does not apply to systems, equipment, or components specially designed to be installed or used with authorization by administrators, owners, or users for the purposes of asset protection, asset tracking, asset recovery, or ‘ICT security testing'.

  • 4.D.4.  "Software" specially designed or modified for the generation, operation or deliver of, or communication with, "intrusion software".

    Note:  4.D.4 does not apply to "software" specially designed to be installed or used with authorization by administrators, owners, or users for the purposes of asset protection, asset tracking, asset recovery, or ‘ICT security testing'. “Software” shall be deemed "specially designed" where it incorporates one or more features designed to confirm that the product is used for security enhancement purposes. Examples of such features include, but are not limited to:

    a. A disabling mechanism that permits an administrator or software creator to prevent an account from receiving updates; or

    b. The use of extensive logging within the product to ensure that significant actions taken by the user can be audited and verified at a later date, and a means to protect the integrity of the logs.

  • 4.E.1.a. "Technology" [...] for the "development," "production" or "use" of equipment or "software" specified by 4.A. or 4.D.

  • 4.E.1.c. "Technology" for the "development" of "intrusion software".

2) Redefining "intrusion software." Although the Wassenaar Arrangement does not directly control "intrusion software," the "intrusion software" definition underpins the Arrangement's controls on software, systems, and technology that operate or communicate with "intrusion software." Our goal here is to help narrow the definition of "intrusion software" to code that can be used for malicious purposes. To do this, we suggest redefining "intrusion software" as specially designed to be run or installed without authorization of the owner or administrator and extracting, modifying, or denying access to a system or data without authorization.

Here is the Wassenaar Arrangement text with our suggested additions in bold and deletions in strikethrough:

  • Cat 4 "Intrusion software"

  1. "Software"

    a. specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', or to be run or installed without the authorization of the user, owner, or ‘administrator' of a computer or network-capable device, and

    b. performing any of the following:

    a.1. The unauthorized extraction of or denial of access to data or information from a computer or network-capable device, or the modification of system or user data; or

    b.2. The unauthorized modification of the standard execution path or a program or process in order to allow the execution of externally provided instructions system or user data to facilitate access to data stored on a computer or network-capable device by parties other than parties authorized by the owner, user, or ‘administrator' of the computer or network-capable device.

3) Exceptions to the definition of "intrusion software."
The above modification to the Arrangement's definition of "intrusion software" is not adequate on its own because exploits – which are routinely shared for cybersecurity purposes – are designed to be used without authorization. Therefore, we suggest creating two exceptions to the definition of "intrusion software." The first is to confirm that "intrusion software" does not include software designed to be installed or used with authorization for security enhancement. The second is to exclude software that is distributed for the purpose of preventing its unauthorized execution to particular end users. Those end users include 1) organizations conducting research, education, or security testing, 2) computer emergency response teams (CERT), 3) creators or owners of products vulnerable to unauthorized execution of the software, or 4) among an entities subsidiaries or affiliates. So, an example: A German researcher discovers a vulnerability in a consumer software product, and she shares a proof-of-concept with 2) CERT, and 3) a UK company that owns the flawed product; the UK company then shares the proof-of-concept with 4) its Ireland-based subsidiary, and 1) a cybersecurity testing firm. The beneficial and commonsense information sharing outlined in this scenario would not require export licenses under our proposed language.

Here is the Wassenaar Arrangement text with our suggested additions in bold and deletions in strikethrough:

  1. "Intrusion software" does not include any of the following:

    a. Hypervisors, debuggers or Software Reverse Engineering (SRE) tools;

    b. Digital Rights Management (DRM) "software"; or

    c. "Software" designed to be installed or used with authorization by manufacturers, administrators, owners, or users, for the purposes of asset protection, asset tracking, or asset recovery . , or ‘ICT security testing'; or

    d. “Software” that is distributed, for the purposes of helping detect or prevent its unauthorized execution, 1) To organizations conducting or facilitating research, education, or 'ICT security testing', 2) To Computer Emergency Response Teams, 3) To the creators or owners of products vulnerable to unauthorized execution of the software, or 4) Among and between an entity's domestic and foreign affiliates or subsidiaries.

  1. Monitoring tools': "software" or hardware devices, that monitor system behaviours or processes running on a device. This includes antivirus (AV) products, end point security products, Personal Security Products (PSP), Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) or firewalls.

  2. 'Protective countermeasures': techniques designed to ensure the safe execution of code, such as Data Execution Prevention (DEP), Address Space Layout Randomisation (ASLR) or sandboxing.

  3. ‘Authorization' means the affirmative or implied consent of the owner, user, or administrator of the computer or network-capable device.

  4. ‘Administrator' means owner-authorized agent or user of a network, computer, or network-capable device

  5. 'Information and Communications Technology (ICT) security testing' means discovery and assessment of static or dynamic risk, vulnerability, error, or weakness affecting “software”, networks, computers, network-capable devices, and components or dependencies therefor, for the demonstrated purpose of mitigating factors detrimental to safe and secure operation, use, or deployment.

Complex Machinery

This is a complex issue on several fronts. For one, it is always difficult to clearly distinguish between software and code used for legitimately beneficial versus malicious purposes. For another, the Wassenaar Arrangement itself is a convoluted international legal document with its own language, style, and processes. Our suggestions are a work in progress, and we may ultimately throw our support behind other, more effective language. We don't presume these suggestions are foolproof, and constructive feedback is certainly welcome.

Time is relatively short, however, as meetings concerning the renegotiation of the Wassenaar Arrangement will begin again during the week of April 11th. It's also worth bearing in mind that even if many cybersecurity companies, researchers, and other stakeholders come to agreement on revisions, any final decisions will be made with the consensus of the 41 nations party to the Arrangement. Still, we hope suggesting this language helps inform the discussion. As written, the Arrangement could cause significant damage to legitimate cybersecurity activities, and it would be very unfortunate if that were not corrected.