Wassenaar Export Controls on Surveillance Tools: New Exemptions for Vulnerability Research

The United States successfully negotiated research-use exceptions to export controls on surveillance tools at the December 2017 meeting of the Wassenaar Arrangement, a club of advanced economies that coordinates export controls. These export controls—requirements that organizations selling or sending technologies with potential military applications abroad obtain a license from the Commerce Department—affect key swaths of the cybersecurity industry. Although countries implement export controls at the national level, the United States and 40 other countries have agreed to coordinate their controlled items at the Wassenaar Arrangement, an international framework for creating a voluntary export control regime. At this year’s meeting, the U.S. aimed to correct what the cybersecurity industry portrays as overly-broad controls on intrusive surveillance software—controls that security experts say “criminalized” essential tools for stopping malware. After years of debate over the proper scope of export controls on surveillance products, the U.S. has finally made a beachhead on getting long-sought-after exemptions for security research and information sharing. In this post, I describe the original Wassenaar export controls, summarize the 2017 revisions, and forecast what we should expect to see next.

Background

The Arab Spring revealed how repressive regimes use Western commercially developed software surveillance tools to spy on dissidents and human rights activists. Human rights organizations sued a French company for giving to the Libyan government equipment that activists say enabled torture of dissidents. Privacy International and other civil-society groups pressured the British government to use existing legal mechanisms restrict repressive regimes’ access to network intrusion software that employed enabled governments to intercept email, instant messaging and webcam data. (Citizen Lab’s research explores this topic extensively.) In 2013, the British and French governments negotiated the addition of two types of dual-use technology—“intrusion software” and “IP network communications surveillance systems”—to the lists of dual-use technologies that the Wassenaar Arrangement governs

The Wassenaar Arrangement is an export control framework—not an international regulatory agency or treaty organization, but rather, a group of countries that meet regularly and agree to control certain technologies. An export control is a requirement that a company wishing to sell a product abroad get a government license to export the item; it is not a ban on that item’s export. Wassenaar has no way to make its controls legally binding on its members, who regulate controlled items through their domestic export control regimes. The arrangement’s 41 members include the U.S., near-all the European Union (Cyprus is the lone outlier), Russia, Turkey, Argentina and South Africa. Its goal is to prevent “destabilising accumulations” of conventional arms and dual-use goods and technologies—items with both civilian and military applications.

The Intrusion Software Controls

The “intrusion software” control took on the difficult task of regulating surveillance software based on computer code functionality. Wassenaar defined intrusion software as “software specially designed or modified to avoid detection by monitoring tools, or to defeat protective countermeasures” and that either extracted data from a computer or network device or modified the “standard execution path” of a program to allow “the execution of externally provided instructions.”

But rather than control intrusion software itself, the arrangement put export controls on software, systems or equipment that interacted with intrusion software. The provision would cover the software toolkits that companies sell to law enforcement and intelligence agencies to carry out intrusive surveillance—see for example Hacking Team’s notorious RCS package. It also controlled any type of technology involved in the development of intrusion software. “Technology” in the control’s context meant essentially any program, code or software tool that was connected to intrusion software. In one interpretation of the WA’s controls, “intrusion software” meant code that took advantage of an exploit. By controlling software that used software vulnerabilities to carry out surveillance, the WA control targeted a limited subset of items that related to software exploits.

When the United States tried to implement the intrusion software controls, Symantec, FireEye, independent security researchers and the EFF raised serious concerns about their effect on security software and research. First, the Commerce Department’s implementation through the Commerce Department’s Bureau of Industry and Security (BIS) expanded its scope to cover a broad range of cybersecurity items. Mailyn Fidler detailed for Lawfare how the controls ratcheted up efforts to control trade in software that used zero-day vulnerabilities. BIS said the controls would require export licenses for commercially available penetration testing products and that potentially any exploit sent abroad or even to a national of a foreign country would require a license. BIS published an extensive FAQ that attempted to clarify how the controls affected security research involving exploits. The EFF criticized the FAQ for creating more confusion than clarity on the controls’ scope. In addition, the Commerce Department revoked exemptions for commercially available software products that would have applied to many of the newly controlled security products. It also failed to provide license exceptions for security research. The security industry identified all of these actions as harmful to business and research activities.

But the cybersecurity industry also had problems with the substance of the Wassenaar language itself. Symantec, FireEye and other security software vendors said the intrusion software definition was too broad and it encompassed legitimate products like endpoint security systems and other tools that “hook” into a system to modify its code. They said further that the controls would also make it much more difficult for security research and vulnerability information sharing. The control on “technology for the development” of intrusion software would have covered many essential tools for the security research community such as exploit proofs-of-concept and automated vulnerability generators.

In response to a deluge of comments opposing the rule, the Commerce Department withdrew the proposal. After escalating criticism and a dressing down from the House oversight committee, the Commerce Department convened with its interagency partners to revise the U.S. approach. In March 2016, Commerce Secretary Penny Pritzker said in a letter that the United States would attempt to remove the intrusion software controls at that year’s Wassenaar meetings. In December 2016, the U.S. negotiating team (with added technical experts from the cybersecurity community) failed to convince the other 40 Wassenaar members to agree on narrower language. Bipartisan groups of lawmakers in the House and Senate urged the Trump administration to continue the push to alter the Wassenaar language at the 2017 meeting.

2017 Revisions to the Wassenaar Controls

At the December 2017 Wassenaar meeting, the members agreed on a set of changes to the intrusion software controls. It received limited media coverage. The revised control list included several additions and alterations that Katie Moussouris, a security professional and technical adviser to the U.S. Wassenaar delegation, hailed as fixes for the problems the cyber industry had complained about. The changes are:

● Replacing language that controlled software “specially designed” to operate or communicate with intrusion software with the terms “software specially designed for command and control” of intrusion software.

● Adding an exception for software that carries out updates authorized by the the owner or operator of the system.

● Adding exemptions for controls on technology either involved in the development of intrusion software or the development of software that operates, controls or delivers intrusion software. These exemptions said the controls do not apply for vulnerability disclosure or cyber incident response activities. The list defines vulnerability disclosure and cyber incident response as processes for sharing information about vulnerabilities and cyber incidents but does not explain how these exemptions apply to specific categories of items.

● Adding a clarifying note saying that the above-described exemptions “do not diminish national authorities’ rights to ascertain compliance” with existing controls.

The alterations appear to address the some of the concerns associated with the Wassenaar language, notably the concerns from the security research community about vulnerability information sharing. But it is not yet clear how the new language mitigates concerns about the broad definition of intrusion software that may encompass legitimate security tools not used for “vulnerability disclosure” or “cyber incident response.” Rob Joyce, White House cybersecurity coordinator, has praised the changes, as has Rep. Jim Langevin, a leading congressional voice on this issue.

What Comes Next?

The path forward is not clear. The Commerce Department could use the new language to craft a new proposed rule, to be followed by yet another public comment period. It would have to decide whether to add more exceptions and how to define how the new exemptions apply. Alternatively, Commerce could delay implementing the revised list and wait for the next meeting’s negotiations. In that scenario, Commerce could push for the U.S. delegation to demand more substantial changes to Wassenaar’s definition of intrusion software. But the human rights and internet freedom communities united with industry to oppose the 2015 proposed rule, and it is not clear whether the new changes will satisfy their concerns.

The Wassenaar changes could cause confusion for other countries as well. The EU has had intrusion software on its export control list since 2015. But as revelations that European companies sold surveillance toolkits to Middle Eastern dictators continued, the EU has sought to revamp its dual-use export control legislation in the interest of human rights. Separately, Israel (which is not a Wassenaar member but has a domestic law that adopts all Wassenaar controls automatically) attempted to more rigorously define intrusion software in early 2016. Doron Hindin detailed this effort for Lawfare. But a few months later, Israel shifted its policy on export controls, substantially reducing the scope and strength of the license requirements. It is unclear how the newest Wassenaar shift will play into both the EU export control reform initiative and the liberalized Israeli approach.

***

The Trump administration has until March to submit any proposals for changes to the Wassenaar control list to be negotiated this year. For now, the security community will be waiting for the administration’s next move. This debate, which has shown the difficulty of defining the appropriate regulations for hacking tools, is far from over.