If you are not aware, please take note that the July 20, 2015 deadline is fast approaching for comments to the U.S. Department of Commerce’s Bureau of Industry and Security (BIS) proposed rule on the export control of certain intrusion and surveillance related software.  The proposed rule, which addresses changes to the U.S. Export Administration Regulations (EAR), is designed to align with agreements made in the December 2013 Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies, a multilateral export control regime with 41 participating states committed to promoting transparency and responsibility in cross-border transfers of arms and dual-use goods and technologies.  The wide-reaching rule proposes adding new controls in Category 4 of the EAR’s Commerce Control List (CCL) intended to address “intrusion software” used by hackers and other cybercriminals.  The difficulty is that, in the way the proposed rule is worded (and explained), it also subjects network penetration testing products, the type that use “intrusion software” to identify cyber-vulnerabilities, to the same export licensing requirements.  That is to say, the manner in which the controlled intrusion software would be defined includes the good as well as the bad, and – could have a chilling effect on beneficial research and development of defensive software.

Issued on May 20, 2015, the BIS notice proposes a new rule implementing a license requirement for the export, re-export, or in-country transfer of certain intrusion and surveillance items.  Specifically, the proposal addresses “network penetration testing products that use intrusion software to identify vulnerabilities of computers and network-capable devices” and “proprietary research on the vulnerabilities and exploitation of computers and network-capable devices.”  However, in its effort to protect the United States from malevolent software, BIS appears poised to catch in its dragnet beneficial software development intended to address the very same concerns.

The proposed rule would define “intrusion software” as “‘Software’ ‘specially designed’ or modified to avoid detection by ‘monitoring tools,’ or to defeat ‘protective countermeasures,’ of a computer or network-capable device, and performing:

(a) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or the

(b) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

(emphasis added).

In the FAQs published on the BIS website, the response to question No. 1, “Does the rule BIS is proposing control ‘intrusion software’, malware, exploits, etc.?”  confirms that the proposed rule would not create a license requirement for intrusion software itself.  The difficulty arises from the fact that (as confirmed in FAQ No. 1) the proposed rule would impose an export license requirement for “the command and delivery platforms for generating, operating, delivering, and communicating with ‘intrusion software’.”  The reason this ropes in the good with the bad is that the “good guys” whose software we all rely on to navigate the Internet safely need to export just this sort of software in order to test  and thus successfully develop the right defensive software to protect against the cyberattacks the new rule is trying to combat.  This seems quite plausible.  After all, to design the right defense you need to know what you’re defending against, and asking a global software team to design defensive software without seeing and deploying for test purposes the malicious software and delivery platforms they are contending with, is a bit like asking them to design it blindfolded.  U.S.-based companies need to employ international employees and subcontractors to better understand and defeat pending network threats globally.  The unfortunate part of the proposed rule is that it offers no relief for those wearing the “white hat.”  As such, should the proposed rule “go final,” U.S.-based software and cybersecurity companies may find they are not permitted to share their knowledge globally and in a timely manner to defeat new or pending cyber threats.  Rather, the new licensing control requirement could delay threat defense efforts by a month.  In today’s world, that delay can be mission critical.  New cyber threats emerge daily and are deployed worldwide instantaneously.  The “black hats” do not wait for export licenses to be issued.

The key take away here is that the proposed rule need not be so far overreaching and all encompassing.  For example, BIS actually has a precedent in the form of an important strong encryption license exception that it could consider using as a model for a license exception here.  Under 15 C.F.R. § 740.17 (a)(1) (the ENC exception), no licenses are required for companies to share even strong, restricted encryption (so-called (b)(2) encryption) with their global development teams for the purpose of developing new products.  A similar type of exception in the proposed rule could solve industry’s concern here about responding promptly and globally to new cyber threats by allowing companies to employ their entire global network to develop the right defenses.

Time is ticking away for companies to make their voices heard on this proposed rule.  While the intent of the proposed rule is clear (and noble), the proposed instrument strikes most in industry as too blunt and, indeed, dangerous.  We join industry in hoping that the final rule, when it comes, will not throw the baby out with the bathwater by impairing the defensive tools we all rely on – and need – to operate securely in cyberspace.