[Hardware] Cybersecurity Community Beware: US Finally Enacts “Intrusion Software” Rule

[Angel of Death]

They have been almost a decade in the making, but have finally arrived: new U.S. export controls on “cybersecurity items,” including products and technology involving “intrusion software” and IP network communications surveillance. Published today but effective January 19, 2022, the interim final rule from the U.S. Commerce Department’s Bureau of Industry and Security (“BIS”) amends the Export Administration Regulations (“EAR”) to add these new cybersecurity export controls. The interim final rule is highly technical and complex, but ultimately contains a mix of good news and bad for the cybersecurity community. BIS states in its press announcement that the rule is only intended to restrict “malicious cyber activities,” but it nonetheless imposes compliance obligations and costs even when activities ultimately are not restricted. At least in this sense, the rule will impact the entire cybersecurity sector. Similar export controls have been in place for years in the EU and other jurisdictions, as this has been driven by an agreement reached several years ago by a multilateral export controls body, the Wassenaar Arrangement. The U.S. for its part has delayed implementation of this rule due to the controversy that has surrounded it. Many stakeholders, including some U.S. and non-U.S. government officials, have viewed this effort to impose export controls on “intrusion software” items as fundamentally misguided or at least improperly scoped, as the same cyber tools can be used either for positive (security) purposes or for nefarious (hacking or surveillance) purposes. Therefore, the critics say, it is like putting a round peg in a square hole to try to use export controls in this context. Moreover, some have questioned the potential of these rules to deter nefarious activities. Having taken account of these criticisms, BIS has tailored the interim final rule relatively narrowly. Still, it imposes new regulatory burdens on the vast majority of impacted parties that are engaged in critical security work, and ultimately in effect only restricts a small sliver of cyber activity that may be more controversial or malicious. BIS has invited industry and other stakeholders to (re)engage, and will be accepting comments over the course of the next 45 days on the expected impacts of the rule, including how it may deter, restrict or overburden legitimate cybersecurity research, defensive activity, and incident response. Comments must be submitted by December 6, 2021. BIS is expected to review constructive comments with an open mind, and changes to the rule are still possible. Below is a more detailed discussion of the new rule, starting with the background, which may be of particular interest for those considering (re)engaging on these issues with the government, and then going into the nuts and bolts of the new controls that are being imposed along with the key exceptions. Background and Context for (Re)engagement While advocacy groups have been raising concerns for well over a decade about nefarious uses of cyber technologies that have been implicated in violations of human rights, the key event in the history of the development of these cybersecurity export controls was the December 2013 plenary meeting of the Wassenaar Arrangement, where the U.S. government and other participants agreed to implement within their national laws new export controls on products and technologies involving “intrusion software” and IP network communications surveillance. This agreement at the 2013 Wassenaar Arrangement plenary was preceded by years of discussion, primarily within the EU, about how an expansion of export controls in this area could help address the increasing problem of malicious uses of cyber tools. The EU had begun a consultation process on this in 2011, and, at the time, had ambitions to enact a sweeping recast of its own EU export control regime to include a new “human security” element, which would have included even broader controls on cybersecurity items. See our previous advisories (here and here) on those historical developments in the EU. Ultimately, after intense backlash from industry and even many government stakeholders and others (including civil society security advocates), and following an arduous and protracted legislative process, the EU just last month enacted a much watered-down version of that initial regulatory concept. See our blog post for more on those EU developments. But the EU had already amended its dual-use control list soon after the December 2013 Wassenaar Arrangement plenary to add the basic list-based controls on “intrusion software” items and IP network communications surveillance items. The U.S. government did not follow the EU in promptly implementing these new Wassenaar Arrangement controls on cybersecurity items. The Wassenaar Arrangement does not operate pursuant to a binding international treaty, but rather relies on essentially political commitments by participating states to implement the agreed restrictions. The U.S. government is typically a leader of the Wassenaar Arrangement’s initiatives, normally implementing the controls adopted at each year’s plenary within just a few months. So this delay involving cybersecurity controls was exceptional in this respect. The U.S. government, through BIS, eventually published a proposed implementation of these controls in 2015. See our previous advisory for more on that BIS proposed rule, along with the accompanying FAQs from BIS, many of which are also informative in helping to interpret and understand the current interim final rule. This 2015 proposal by BIS was met with a great deal of concern from the cybersecurity community, particularly as it related to “intrusion software” items. (The proposed controls on IP network surveillance products were less controversial and are also being implemented now in the interim final rule.) The U.S. Congress also became involved, requiring senior administration officials to testify following the publication of BIS’s 2015 proposed rule and pressuring the administration to try to renegotiate the Wassenaar Arrangement agreement from 2013. Following an interagency debate, the Secretary of Commerce took the unusual step of writing a public letter to major industry associations in March of 2016, informing them that “the United States has proposed in this year’s Wassenaar Arrangement to eliminate the controls” on certain intrusion software items, while continuing discussions “aimed at resolving the serious scope and implementation issues raised by the cybersecurity community concerning remaining controls” other such items. The Secretary closed by stating that “President Obama has identified cybersecurity as one of the greatest national security challenges we face as a Nation. Cognizant of this, we commit to ensuring that the benefits of controlling the export of the purpose-built tools at issue outweigh the harm to effective U.S. cybersecurity operations and research.” After a failed attempt in 2016, the U.S. and other countries succeeded in implementing some fairly significant changes to these controls in the 2017 Wassenaar Arrangement plenary. These changes are detailed in the preamble to the current interim final rule and are reflected in the rule. While these 2017 changes were helpful, many observers continued to have concerns regarding the potential impact of the controls on cybersecurity, and the U.S. government delayed implementing these regulations for the next several years while the debate continued. However, in recent years the protection of human rights has become an increasingly prominent element of U.S. export control policy. See our blog post from last year for a more detailed discussion of these important policy shifts around human rights in the export controls arena. BIS’s press announcement for the interim final rule itself “encourages” regulated parties to consult the State Department’s human rights-focused due diligence guidance from last year for exports of surveillance products as a compliance aid in this context. The Biden administration has been particularly vocal about its goal of elevating human rights as a driver of U.S. foreign policy, including pushing in recent months for a revision of the U.S. Conventional Arms Transfer (“CAT”) policy with this in mind. BIS is also under a statutory mandate to impose new and expanded export controls on “emerging and foundational technologies,” as discussed in more detail in our previous blog post, and has been on the receiving end of considerable pressure from members of Congress to move more quickly and aggressively in those efforts. We have also seen a shift in recent enforcement actions toward more of a focus on human rights issues, including an unprecedented criminal case last month under the U.S. International Traffic in Arms Regulations (“ITAR”) against former U.S. intelligence community personnel for helping the government of the UAE to develop its own hacking capabilities, including through the use of “intrusion software” tools. In this context, the interim final rule from BIS is now emerging after a years-long debate both within the U.S. government and among other stakeholders about how export controls should be applied to restrict unwanted or malicious uses of cyber tools, including trying to avoid the grave human rights impacts that these technologies can have. Industry and others now have the opportunity to (re) engage in the comment process to raise questions or concerns regarding the imposition of any regulatory restrictions that they believe would unduly impact legitimate security work or negatively impact U.S. cybersecurity policy objectives. The Interim Final Rule In drafting the interim final rule, BIS has made efforts to achieve a policy balance between regulating malign uses of cyber tools and trying to avoid undue licensing burdens on the cybersecurity community. The new rule builds on the changes implemented at the Wassenaar Arrangement in 2017, and narrows the scope of the restrictions even further through a broad license exception. The rule will nonetheless impose additional compliance obligations on legitimate security work, as is inevitable when export controls intrude into a new area, particularly one as dynamic and fundamentally international as cybersecurity. In particular, the rule will require a detailed analysis to be undertaken for compliance assessments. In the multiple layers of control and de-control that BIS has built into this rule, the agency has created a sharp scalpel that is designed to focus in on the most controversial uses of “intrusion software” items, while trying to avoid restrictions on beneficial activity. The preamble to the interim final rule states that, “because of the limited scope of this rule, BIS believes the impact would be minimal.” Stakeholders may have real questions regarding the scope and costs of the rule. The government has estimated the cost to be $2,250.00 per year, which may strike affected companies as an underestimation Below we set out the two-step process for understanding the interim final rule, starting with what is subject to control in the first instance, and then assessing whether export activity for covered items is nonetheless authorized under new License Exception Authorized Cybersecurity Exports (“ACE”) or another carve-out from the EAR. In rare cases when a covered item cannot take advantage of one of these carve-outs, the licensing requirements are broad. The “intrusion software” items are to be controlled under the EAR for National Security (“NS Column 1”) reasons, which applies an authorization requirement for all countries in the world (and their nationals) except Canada. The IP network communications surveillance items are subject to less comprehensive but still broad NS Column 2 controls, which apply to all but the least sensitive countries (and their nationals). Step 1: What is a covered “cybersecurity item”? Covered “cybersecurity items” are described in the following new or expanded Export Control Classification Numbers (“ECCNs”) in the EAR’s Commerce Control List (“CCL”). (See also the 2015 FAQs from BIS, which provide some detailed and practical guidance on the intended scope of these controls.) ECCN 4A005: “Systems,” “equipment,” and “components” therefor, “specially designed” or modified for the generation, command and control, or delivery of “intrusion software” Note that “intrusion software” itself is not controlled. The definition of “intrusion software” (which already exists in Part 772 of the EAR) is “software” specially designed or modified to avoid detection by “monitoring tools,” or to defeat “protective countermeasures,” of a computer or network-capable device (including mobile devices and smart meters), and performing any of the following: (1) The extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or (2) The modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions. Excluded from this definition are: Hypervisors, debuggers and Software Reverse Engineering (SRE) tools; Digital Rights Management (DRM) “software”; and “software” designed to be installed by manufacturers, administrators or users, for the purposes of asset tracking or recovery. The term “monitoring tools” means “software” or hardware devices, that monitor system behaviors 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) and firewalls. The term “protective countermeasures” means techniques designed to ensure the safe execution of code, such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) and sandboxing. The EAR also includes a complex definition of the term “specially designed,” which is often not intuitive. ECCN 4D004: “Software” “specially designed” or modified for the generation, command and control, or delivery of “intrusion software.” ECCN 4D004 does not apply to “software” specially designed and limited to provide “software” updates or upgrades if: a. The update or upgrade operates only with the authorization of the owner or administrator of the system receiving it; and b. After the update or upgrade, the “software” updated or upgraded is neither “software” specified by 4D004 nor “intrusion software.” ECCN 4D001.a: “Software” “specially designed” or modified for the “development” or “production” of equipment controlled by (among other pre-existing ECCNs) 4A005 or “software” controlled by (among other pre-existing ECCNs) 4D004 ECCN 4E001 a: “Technology” for the “development”, “production”, or “use” of equipment controlled by (among other pre-existing ECCNs) 4A005 or “software” controlled by (among other pre-existing ECCNs) 4D004; and 😄 “Technology” for the “development” of “intrusion software.” Note 1 is an important exclusion stating that ECCNs 4E001.a and 4E001.c do not apply when otherwise controlled “technology” under these ECCNs is exchanged for the purpose of “vulnerability disclosure” or “cyber incident response”. “Vulnerability disclosure” means “the process of identifying, reporting, or communicating a vulnerability to, or analyzing a vulnerability with, individuals or organizations responsible for conducting or coordinating remediation for the purpose of resolving the vulnerability.” “Cyber incident response” means “the process of exchanging necessary information on a cybersecurity incident with individuals or organizations responsible for conducting or coordinating remediation to address the cybersecurity incident.” Note that there is not a similar carve-out for the related hardware and software controls. Note 2 emphasizes the regulatory burden of these controls even when not applicable, stating that “Note 1 does not diminish national authorities’ rights to ascertain compliance with 4E001.a and 4E001.c.” BIS explains in the preamble to the interim final rule that this Note 2 is intended “to clarify that BIS can request information on items decontrolled by Note 1 to ensure compliance with the controls. BIS does not intend this note to require any additional compliance measures beyond what is otherwise required by the EAR.” In particular, this is a reminder about the EAR’s broad recordkeeping requirements (along with subpoena authorities, etc.). Regulated parties should be aware that the EAR imposes compliance obligations even when no licensing requirements apply. ECCN 5A001.j:. IP network communications surveillance systems or equipment, and “specially designed” components therefor, having all of the following [along with related software, technology, and test, inspection and production equipment]: j.1. Performing all of the following on a carrier class IP network (e.g., national grade IP backbone): j.1.a. Analysis at the application layer (e.g., Layer 7 of Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)); j.1.b. Extraction of selected metadata and application content (e.g., voice, video, messages, attachments); and j.1.c. Indexing of extracted data; and j.2. Being “specially designed” to carry out all of the following: j.2.a. Execution of searches on the basis of “hard selectors”; and j.2.b. Mapping of the relational network of an individual or of a group of people. Note: ECCN 5A001.j does not apply to “systems” or “equipment”, “specially designed” for any of the following: Marketing purpose; Network Quality of Service (QoS); or Quality of Experience (QoE). BIS explains the interactions between these cybersecurity controls and other potentially related controls under the EAR as follows: Notes 3 to Categories 4 and 5 Part 1 of the CCL state that the EAR’s encryption controls generally trump these cybersecurity controls. However, these notes also caution that both the encryption controls and the cybersecurity controls may apply to source code (and, according to the preamble, also technology) that includes elements of each. Notes 4 to Categories 4 and 5 Part 1 state that the EAR’s Surreptitious Listening (“SL”) controls also trump these cybersecurity controls, as the SL controls are subject to broader (worldwide) restrictions. Step 2: Does License Exception ACE apply? Even when an item is in the first instance subject to the cybersecurity controls discussed above, License Exception ACE may still apply, in which case no specific license from BIS would be required. License Exception ACE generally authorizes exports, reexports, and transfers (in-country), including “deemed” exports and reexports to foreign nationals, of covered “cybersecurity items,” except as follows: Sanctioned countries: License Exception ACE does not apply to activity involving Cuba, Iran, North Korea or Syria (or their nationals). Restricted “government end users”: License Exception ACE does not apply to a “government end user” of any country listed in EAR Country Groups D:1, D:2, D:3, D:4 or D:5, except for such “government end users” whose country is also listed in EAR Country Group A:6 (e.g., Cyprus, Israel and Taiwan) and when the export is either of the following: Of “digital artifacts” that are related to a cybersecurity incident involving information systems owned or operated by a “favorable treatment cybersecurity end user,” or to police or judicial bodies of such governments “for purposes of criminal or civil investigations or prosecutions of such cybersecurity incidents.” (We note that it is not entirely clear whether authorized exports to police or judicial bodies are limited to “digital artifacts,” and it would be helpful if BIS could clarify this point.) “Digital artifacts” are items (e.g., “software” or “technology”) found or discovered on an information system that show past or present activity pertaining to the use or compromise of, or other effects on, that information system. A “favorable treatment cybersecurity end user” is any of the following: (i) A “U.S. subsidiary”; (ii) Providers of banking and other financial services; (iii) Insurance companies; or (iv) Civil health and medical institutions providing medical treatment or otherwise conducting the practice of medicine, including medical research. To “national computer security incident response teams” (an undefined and not entirely clear term) “for purposes of responding to cybersecurity incidents, for purposes of ‘vulnerability disclosure’, or for purposes of criminal or civil investigations or prosecutions of such cybersecurity incidents.” A “government end user” includes international governmental organizations, government operated research institutions, and parties acting on behalf of such organizations. The regulations also state that “[t]his term includes retail or wholesale firms engaged in the manufacture, distribution, or provision of items or services, controlled on the Wassenaar Arrangement Munitions List.” Clarification regarding how BIS will interpret the scope of a “government end user” would be helpful to industry, as the current definition allows for gray areas in interpretation. The interim final rule states explicitly that this “government end user” restriction applies to deemed exports, although it presumably applies to actual export activity as well, a point which BIS should clarify. Other restricted end users: License Exception ACE does not apply to actual exports (i.e., deemed exports are still allowed) for purposes other than “vulnerability disclosure” or “cyber incident response” (which are still allowed) to non-government end users located in any country listed in EAR Country Groups D:1 or D:5, except for “favorable treatment cybersecurity end users” in such countries (to which such exports are allowed). Restricted end uses: Finally, License Exception ACE does not apply if the exporter has reason to know at the time that the “cybersecurity item” will be “used to affect the confidentiality, integrity or availability of information or information systems, without authorization by the owner, operator or administrator of the information system (including the information and processes within such systems).” Even when License Exception ACE does not apply, other exclusions or license exceptions under the EAR could potentially apply, such as for “published” software and technology. One important limitation that BIS has implemented in the interim final rule is generally excluding the availability of License Exception Strategic Trade Authorization (“STA”) for these cybersecurity items. Conclusion The publication by BIS of the interim final rule shows the U.S. government’s willingness to move forward with these export controls on cybersecurity items following the active debate around these policies over the past several years. The narrower scope of the rule compared to its predecessors demonstrates the challenge the government faces in striking the appropriate policy balance. Industry and other affected stakeholders may wish to take advantage of the 45 day comment period and communicate to BIS any concerns about the interim final rule to help the government understand its impacts and ambiguities, and how it can be improved to achieve the desired policy objectives. While it seems likely that export controls in some form will be enacted in this space, by publishing this as an interim final rule, BIS has signaled that there is still time for these regulations to be made more clear and potentially even more narrowly tailored to hone in only on the targeted malicious or otherwise controversial uses of these tools without imposing undue burdens on the cybersecurity community.