                       Intrusion and Surveillance Items
   1. Does the rule BIS is proposing control "intrusion software", malware, exploits, etc.? 
      No, the proposed rule would not control any "intrusion software," which may also be referred to as malware or exploits. The Category 4 control entries would control the command and delivery platforms for generating, operating, delivering, and communicating with "intrusion software". It would also control the technology for developing "intrusion software," but it does not control the "intrusion software" itself.
      Thus, transferring or exporting exploit samples, exploit proof of concepts, or other forms of malware would not be included in the new control list entries and would not require a license under the proposed rule.
   2. Doesn't the rule potentially criminalize hacking? 
      No. The rule would control the export of hardware and software delivery tools, as well as the export of technical data for developing exploits ("intrusion software"). The rule as proposed would not control the export of exploits to a target system since "intrusion software" would not be controlled. Also, the Export Administration Regulations (EAR) do not control services, only the export of commodities, software and technology. Thus, "hacking", as that term is generally understood, does not fall under the jurisdiction of the EAR, except to the extent there is an associated export of hardware, software, or technical data. 
   3. Does the rule inadvertently capture defensive products as well as offensive products? 
      The proposed rule would control the command and delivery platforms "specially designed" or modified for generating, operating, delivering, or communicating with "intrusion software" as defined in the EAR. As noted in the preamble to the proposed rule, some penetration testing products marketed as defensive products meet the technical description of such command and delivery platforms in the new control list entries. BIS is not aware of other defensive products that would be caught by the proposed rule, but would welcome comments on this. If penetration testing products are determined to be described in the Category 4 control list entries, they will be deleted from the list of products eligible for export under License Exception ENC (section 740.17(b)(2)(i)(F)). 
   4. Will the rule control vulnerability research as well as research on exploits? 
      The rule would control the export of technology for the "development" of "intrusion software", as well as the technology for the "development" or "production" of the command and delivery platforms themselves. A license would not be required simply to conduct research or analyze code, unless there was an associated transfer or deemed export of controlled technology, executable software, or source code.
      As a clarification, the proposed rule would control the following, among other things:
         1.                   Information "required for" developing, testing, refining, and evaluating "intrusion software", in order, for example, technical data to create a controllable exploit that can reliably and predictably defeat protective countermeasures and extract information.
         2.                   Information on how to prepare the exploit for delivery or integrate it into a command and delivery platform.
         3.                   The development or production of the command and delivery platform itself.
      The proposed rule would not control the following:
         1.                   Information on how to search for, discover or identify a vulnerability in a system, including vulnerability scanning;
         2.                   Information about the vulnerability, including causes of the vulnerability; and
         3.                   Information on testing the vulnerability, including `fuzzing' or otherwise trying different inputs to determine what happens; and
         4.                   Information on analyzing the execution or functionality of programs and processes running on a computer, including decompiling or disassembling code and dumping memory.
      In addition, there are two further limitations to controls on technology:
      First, not all malware and exploits meet the definition of "intrusion software". The definition specifies only intrusion software that is capable of extracting or modifying data or modifying the standard execution path of software in order to allow the execution of externally provided instructions. Thus, technology for the development of malware that is designed to do other things, such as damage or destroy systems or infrastructure, would not be controlled under the proposed rule.
      Second, the only technology controlled is the technology that is "required for" and peculiarly responsible for achieving or exceeding the control level. See BIS's 3/25/14 advisory opinion at http://www.bis.doc.gov/index.php/policy-guidance/advisory-opinions. 
      Third, export controls do not apply to any technology or software that is "published" or otherwise made publicly available.
      Thus, only that part of the technology that is peculiarly responsible for meeting the definition of "intrusion software" , and is not publicly available, would be controlled.
      As part of the request for comments, BIS is seeking comments from the public on further clarifications that may be needed on this subject.
   5. Doesn't the rule expose researchers to criminal prosecution if they carry information on exploits to a public conference, unless they publish it before the conference? 
      Under Section 734.7 of the EAR, information that is published, or released at an open conference, is not subject to the EAR. That section also specifies that it would not be an export to transfer the technical data to conference organizers with the intent that it will be published at the conference.
      BIS welcomes comments on whether further clarification is needed on when information potentially subject to these rules would be considered "publicly available" and not subject to the EAR.
   6. Doesn't the rule make it easier for researchers to provide exploitable bugs to their government then to publish an exploit in order to fix and alert the world of the problem? 
      Under Section 734.7, there are no restraints on publishing information otherwise subject to control, and no prior authorization from BIS is required. Once the information is published it is not subject to the EAR. Thus any information that is published is completely outside the scope of the EAR and the provisions of the proposed rule.
   7. Will companies be required to share their zero-day exploits with the government in order to get a license? 
      The rule states that when an export license application is filed, BIS can request a copy of the part of the software or source code that implements the controlled cybersecurity functionality. Exploits that meet the definition of "intrusion software" are not controlled. Therefore, BIS would not request a company to share a zero-day exploit. Please see FAQ #15.
   8. Does the rule capture auto-updaters and anti-virus software? 
      No. Software that permits automatic updates and anti-virus tools are not described in proposed ECCN 4D004. ECCN 4D004 software must be specially designed or modified for the generation, operation or delivery of, of communication with, "intrusion software," which is separately defined. Anti-virus software is a `monitoring tool' that is explicitly excluded from the definition of "intrusion software. Further, software that automatically updates itself may need to interact with installed `monitoring tools" and protective countermeasures in order to properly execute, but they are not defeating (or otherwise subverting) the system or generating, operating, delivering, or communicating with "intrusion software".
   9. Would ECCN 4E001.c be covered by the General Technology Note? 
      Yes. Per the advisory opinion issued by BIS on 3/25/14, the GTN applies to all ECCNs controlling ''technology," regardless of whether the ECCN specifically refers to the GTN or uses the term "required."
   10. If an IT security researcher had done an analysis on a software application to find a vulnerability in the code, had written up code to then take advantage of the vulnerability and then sent that code to an anti-virus company or the software manufacturer, would that code require an export license? 
      No, what is described is the creation of an "exploit." Exploits are not described in the text of the proposed control list entries. The code that takes advantage of the vulnerability would not require a license. As stated above, "intrusion software" itself would not be controlled by the proposed rule.
      For any associated technology for the "development" of "intrusion software", under section 734.7 of the EAR, any technical data sent to an anti-virus company or software manufacturer with the understanding that the information will be made publicly available, would not be subject to the EAR. However, "technology" that is not intended to be published would be subject to the control  -  see question #4.
   11. The first FAQ basically equates "intrusion software" with malware and exploits. Is this the intent? 
      The definition of "intrusion software" is meant to include a subset of all the malware (exploits, viruses, etc.) that are out there. The definition describes only "intrusion software" that is specially designed to extract or modify data or modify the standard execution path of software in order to allow the execution of externally provided instructions. Other types of malware, including software that only leaves evidence of a successful security breach without further compromising or controlled the system, or is designed to destroy data or systems would not be included in the definition of "intrusion software."
   12. There is a reference to penetration testing products in another FAQ. Is that to say that all penetration testing products would fit the definition of "intrusion software"? 
      Some penetration testing products meet the description of systems, equipment or software "specially designed" or modified for the generation, operation or delivery of, or communication with, "intrusion software" set forth in proposed ECCNs 4A005 and 4D004. The tools that meet the entry are ones that are "specially designed" or modified to launch exploits or other malware that meet the definition of "intrusion software"  -  including extracting or modifying data on the system.
      However, there are some tools that are used in penetration testing that are not caught by the entries because they do not do the things described in the definition. For example, tools such as port scanners, packet sniffers and protocol analyzers would not be controlled. A penetration testing tool not designed to avoid detection by `monitoring tools' would not be controlled. Also, a vulnerability scanner, which just finds vulnerabilities in a system without actually exploiting them and extracting data, would not be captured by the proposed rule.
   13. There are defensive products on the market that would probe a network for vulnerabilities (while avoiding the monitoring tools) and would then extract some sample data from the target system to prove that the vulnerability is real. However, that data extraction is benign and merely done as a proof of the vulnerability. The entire process - from the product's capabilities on what it extracts to the act of using it - is done as a defensive act. Would this be considered meet the definition of "intrusion software?" 
      Such products would meet the technical description of systems, equipment or software "specially designed" or modified for the generation, operation or delivery of, or communication with, "intrusion software" set forth in proposed ECCNs 4A005 and 4D004. It is BIS's understanding that there is no technical basis to distinguish defensive products from offensive products (i.e., a defensive product may be used offensively).
   14. Is there a definition of "carrier class IP network" (for ECCN 5A001.j)? 
      The term "carrier class IP network" is meant to specify systems that sit at a national level (or large regional) IP backbone and handle data from an entire city or country. In terms of IP network surveillance systems, this is meant to exclude systems that can only handle smaller data streams or networks, such as those for a campus or a neighborhood. This control does not capture systems that can only analyze data from one person or a small group of people at a time. The term "carrier class IP network" was not defined because it was difficult to put precise technical parameters around this concept.
   15. The answer to FAQ #1 says "exploit samples, exploit proof of concepts, or other forms of malware would not be included" yet the answer to FAQ #7 appears to keep the door open for "zero-day exploits". Can you please clarify your definition of "zero-day exploit" and provide discriminating characteristics to differentiate it from the "exploit samples, exploit proof of concepts" that are explicitly excluded by question 1? 
      This is a two-part answer. First, the answer to FAQ #1 states that the proposed rule does not control the export of exploits and other forms of malware. Zero-day exploits are included in this answer. The export of zero-day exploits, however the term "zero-day" is defined, is not subject to any requirements under the proposed rule.
      Second, FAQ #7 asks whether companies will be required to share their zero-day exploits with the government in order to get a license. The answer to FAQ #7 states that when an export license application is filed, BIS can request a copy of the part of the software or source code that implements the controlled functionality. To expand this answer, the export license requirement applies to the system, equipment, component or software that would generate, operate, deliver or communicate with an exploit. The only regulatory distinction involving zero- day exploits in the proposed rule regards the possibility that a delivery tool could either have (e.g., incorporate) or support (e.g., be `specially designed" or modified to operate, deliver or communicate with) zero-day exploits. If the system, equipment component or software at issue has or supports zero-day or rootkit capabilities, then BIS could request the part of the software or source code that implements that capability. BIS does not anticipate receiving many, or any, export license applications for products having or supporting zero-day capabilities.
   16. Is the United States legally bound to implement the December 2013 Wassenaar Arrangement changes to its control list, or does BIS have discretion? 
      The United States, as a Participating State in the Wassenaar Arrangement, has agreed to maintain national export controls on items included in the Wassenaar Arrangement's control lists, implemented via national legislation and/or regulation. The U.S. implementation process includes determining reason(s) for control, which carry with them license requirements by destination, licensing policy, and license exceptions.
   17. How would the proposed rule affect software used by multinational companies that monitor their overseas networks? 
      Under the proposed rule, all exports of specified systems, equipment, components or software that would generate, operate, deliver or communicate with "intrusion software" would require an export license. There is no license exception for intra-company transfers or internal use by a company headquartered in the United States under the proposed rule.
   18. Security professionals use exploit toolkits (e.g. Neosploit, Blackhole, Phoenix, Crimepack &c.) to test patches and harden systems employing the same tools as a potential criminal adversary. Distribution and licensing of such toolkits is tightly controlled in order to preserve their offensive edge. When security professionals succeed in accessing or acquiring these toolkits, they often share with one another across corporate and international boundaries; would such sharing of exploit toolkits be subject to control? 
      Exploit toolkits would be described in proposed ECCN 4D004 if they are "specially designed" or modified for the generation of "intrusion software." There are no end user or end use license exceptions in the proposed rule.
   19. Security research is intellectually demanding, skilled work. Corporate entities recognize this both by compensating their contracted security professionals accordingly, and by compensating independent researchers who find and report vulnerabilities in their digital infrastructure. These 'bug bounties' are not generally awarded in the absence of a fully-elaborated proof of concept, which is functionally identical to an `exploit'; the vulnerability must be shown to be exploitable and its severity level should be made known to the vendor. What, if any, implications does the proposed rule hold for: i. `Silent' disclosures, in which the researcher may be compensated, but neither the vendor nor the researcher publicly disclose (`publish') the vulnerability? (Most often a vendor choice.); ii. Disclosures in which a vulnerability is made public, but its proof of concept is not; iii. Disclosure of any stripe made through an intermediary (i.e. to HackerOne or via a legal representative)? 
      First, the proposed rule would only apply to exports and reexports of software described in the new control list entries. Domestic commerce in exploits is not subject to the requirements of the Export Administration Regulations.
      Second, in none of the scenarios above would the exploit or proof of concept be considered to be software described in the new control list entries. See questions 4 and 10.
      Finally, if an export is at issue, it is possible that certain technology associated with the exploit would be "technology required for the development or production of intrusion software" under proposed ECCN 4E001.c. As stated in the answer to FAQ #10, any technical data that is transferred with the intent that it be published would not be controlled. However, as the
      question recognizes, not all technical data is intended to be made public, and some of it may be controlled.
   20. When vulnerabilities are found and proofs of concept developed from flaws in proprietary systems, does this have bearing on the classification of security research as `fundamental'? What about when access to that proprietary system is neither specifically authorized, nor unauthorized by the vendor? 
      No, whether the system is proprietary or open source, and whether the access to the system is authorized by the vendor, does not affect whether the security research is "fundamental research." If the research is ordinarily published and shared broadly within the scientific community, it is "fundamental research." If the results of the research ordinarily are restricted for proprietary reasons, it is not. The answer to question 19 above describes a situation when such research would not be "fundamental research."
   21. Could BIS explain the regulatory difference between an open-source security tools (e.g. Metasploit, Kali Linux), and a proprietary surveillance platform (e.g. FinFisher) which may come packaged with open-source tools? 
      Open source security tools such as those referenced that can be downloaded by anyone are not subject to the Export Administration Regulations . Proprietary tools that package and control such open source tools are subject to the regulations and may be described in the new control list entries.
   22. BIS has adopted the definition of `intrusion software' from the Wassenaar Arrangement language, but has elsewhere indicated a policy of `presumptive denial' for cybersecurity items `that incorporate or otherwise support rootkit or zero-day exploit functionality'. Could BIS explain what threshold of severity is meant to be indicated by `rootkit or zero-day exploit functionality', and could BIS make clear their understanding of those terms? 
      Rootkit and zero-day exploit functionality are features more likely to be found in offensive systems or products. A zero-day exploit is not itself controlled. However, when a rootkit or a zero-day exploit is incorporated into a product or system that is described in the new Category 4 control list entries, or if an exploit delivery tool is specially programmed to deliver or command this specialized malware, that product or system is presumed to be offensive by design.
   23. In FAQ #9, BIS stated that the Wassenaar General Technology Note was incorporated into the BIS proposal. Does the Wassenaar General Software Note also apply? 
      The "public domain" provisions (paragraph 2) of the Wassenaar General Software Note (GSN) apply, but the "mass market' provisions (paragraph 1), do not.
      Paragraph 1 of the General Software Note is implemented in the Export Administration Regulations in License Exception TSU (section 740.13(d)). The proposed rule excludes software described in the new control list entries from eligibility under this provision. This exclusion was added to the proposed rule because a similar exclusion applies to encryption software classified under ECCN 5D002, and software described in the new control list entries may incorporate encryption functionality. Software classified under ECCN 5D002 is separately eligible for decontrol to ECCN 5D992 pursuant to the provisions of section 742.15(b) for mass market encryption items. The proposed rule does not provide for any license exception eligibility for products under the new control list entries, except under License Exception GOV.
   24. Would prior BIS authorization be required for a researcher to privately disclose an exploit to a vendor outside the US with the understanding that the information would NOT be published? 
      No. The exploit itself is not described in the new control list entries. Please see the answer to question #1. For this question, a vulnerability is a weakness in a vendor's software or hardware. Exploit code could be written to take advantage of the vulnerability or to prove that the vulnerability can be exploited. The exploit code itself may be considered "intrusion software." Neither the disclosure of the vulnerability nor the disclosure of the exploit code would be controlled under the proposed rule. However, information for the development of "intrusion software" that may accompany the disclosure of the exploit may be described in proposed new ECCN 4E001.c.
   25. In FAQ #10, BIS states that the new implementation would not control "code that takes advantage of [a] vulnerability." However, FAQ 4 states that "information on how to prepare the exploit for delivery" is controlled. We're confused as to how a researcher could submit to a vendor a functional proof of concept and accompanying explanatory material that according to FAQ 10 would not be controlled without violating the restriction from FAQ 4. This assumes that the disclosure to the vendor is not intended for publication. 
      The functional proof of concept may be "intrusion software." The intrusion software itself is not described in the new control list entries (per FAQ #10). However, if technology "required for the development of intrusion software" (as described in the proposed control list entry ECCN 4E001.c.) exported with the functional proof of concept/"intrusion software" would be described in new control list entry ECCN 4E001.c and would, under the proposed rule, require a license to all destinations except Canada. This is what is addressed in the answer to Question #4.
   26. Mobile phone jailbreaking tools include platforms for delivering intrusion software to the phone. These generally include fully operational exploits including the delivery code. Are such tools subject to control? 
      This response divides the question into two parts:
      i) Does this regulation make it illegal to jailbreak a phone?
      No. The Commerce regulation controls exports of certain software, and downloading jailbreaking software to a computer within the United States and using it to jailbreak a phone does not involve an export of software. The proposed rule does not limit the ability of owners to modify their devices.
      ii) What if the jailbreak software includes a platform for delivering intrusion software to the phone--is the jailbreak software subject to control?
      If particular jailbreak software did meet all the requirements for classification under ECCN 4D004 (such as a commercially sold delivery tool "specially designed" to deliver jailbreaking exploits) then it would be subject to control and a license would be required to export it from the United States. Note that if such software were "publicly available," it would not be subject to the Export Administration Regulations.
   27. In FAQ 7, BIS states companies are already required to share source code for exploits that include encryption or cryptanalysis. What about software tools that implement exploits that aren't already subject to encryption controls? 
      The provision referred to is specific to requests to make encryption source code eligible for export under License Exception ENC. Supplement No. 6 to part 742, a questionnaire required to be submitted with requests for License Exception ENC authorization, provides that a copy of the sections of the source code that contain the encryption algorithm, key management routines and their related calls is to be included upon request. (Supp. No 6, paragraph (d)(3)). The proposed rule includes a similar provision for license applications for products that are described in the new control list entries in Supplement No. 2 to part 748, paragraph (z)(2): "Upon request, include a copy of the sections of source code and other software (e.g., libraries and header files) that implement or invoke the controlled cybersecurity functionality."
   28. Does "publicly available" as understood by BIS include a posting on the Internet? 
      Yes, technology or software that is generally accessible to the interested public in any form, including by Internet post, is "publicly available."
   29. Most intrusion software is designed, written, and generated in general purpose programming environments (such as IDEs [integrated design environments]). We presume that BIS has no desire to control those types of tools. However, under the proposed rules, such environments are at least potentially within the controls. What does BIS mean when it says that "the development or production of the command and delivery platform itself" (FAQ 1) is controlled? 
      General purpose tools, such as IDEs, are not described under proposed ECCN 4D004 because they are not "specially designed" for the generation of "intrusion software." Some penetration testing tools (FAQ #12) and exploit toolkits (FAQ #18) are described in proposed ECCN 4D004, as they are command and delivery platforms for "intrusion software."
   30. What does BIS mean by "modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions"? 
      This language is part of the definition of "intrusion software" and refers to a variety of techniques to hijack, or otherwise corrupt, a legitimate (or otherwise trusted) application or process running on the computer, mobile phone or other device. This can be done to create persistence or for other purposes. Through these modifications, a remote operator (or remote command and control software) can execute commands or perform other tasks that further compromise or exploit the hacked (penetrated) device.
   31. When the 2013 Wassenaar update added controls 4.A.5, 4.D.4, 4.E.1.c, and 5.A.1.j, it subjected all these categories to the exemptions available under the "General Software Note", ensuring that software and systems "generally available to the public" were not included in the new controlled classes. Yet the proposed BIS implementation of these controls excludes "cybersecurity software" from the BIS "General Software Note" (740.13.d) by adding paragraph 740.13.d.2.ii. Why has BIS chosen to depart from the 2013 Wassenaar language and exclude software covered by the new controls from the "General Software Note"? 
      Please refer to the answer to FAQ #23. The exclusion of software described in the new control list entries from License Exception TSU (the implementation of paragraph 1 of the General Software Note in the Export Administration Regulations) was added for consistency with the treatment of encryption software classified under ECCN 5D002, as it is anticipated that many items that will be classified under the new control list entries have encryption functionality and are currently classified under ECCN 5D002. However, under the proposed rule, items classified under the new control list entries will not be eligible for decontrol in the same way that ECCN 5D002 products are if they are mass marketed (pursuant to Note 3 to Category 5 part 2 of the Commerce Control List and section 742.15(b) of the Export Administration Regulations).
   32. Will technology and source code classified under the new control list entries be subject to deemed export requirements? 
      Yes, the proposed rule does not provide for any exceptions to deemed export license requirements for release of technology and source code that will be classified under ECCNs 4D004, 4E001.a or .c, 5D001 or 5E001.

