On Wassenaar

My comments to the Bureau of Industry and Security (BIS), which had requested comments on the proposed Wassenaar Arrangement 2013 Plenary Agreements Implementation: Intrusion and Surveillance Items.

I am the director of the research and development branch of root9B, a US cyber security company. Prior to this, I was an officer in the US Air Force, where I led the Air Force Computer Emergency Response Team (AFCERT)’s Intrusion Forensics unit and Defensive Counter Cyber forces. It was our job to prevent, detect, and respond to cyber security breaches, and I now lead the research and development of software to do the same. Prior to those positions, as an individual, I have found and sold zero-day exploit information to defensive security companies who created products to stop those attacks, although I am not currently in the zero-day exploit business.

Our goal is to increase security, but unfortunately, the proposed rules are too broad and will have negative effects on our legitimate vulnerability and intrusion software research, limiting our ability to defend against cyber intrusions. For example:

  1. While I do not believe I am allowed to list specific details, many security companies depend on a robust economy of vulnerability research and threat intelligence. Numerous small businesses focus on finding vulnerability research, exploitation techniques, and intrusion software techniques, and market the results of their research to security firms like ours and anti-virus companies, as well as many in-house security teams at large corporations, who can act on it to secure their customers and employees. This information all falls under the larger umbrella of threat intelligence, which security companies both purchase and sell in a growing market. Such dedicated research firms and full-service security companies are located all over the world. Many people including myself currently have defenses against certain zero-day exploits as a direct result of this market.
    • A “policy of presumptive denial for items that have or support rootkit or zero-day exploit capabilities” http://www.federalregister.gov/a/2015-11642/p-22 would be devastating to this industry. We would lose this ability to defend against such attacks since no researcher or small research team could find such attacks and legitimately sell them to security companies. This means that the only outlet for such information would be illegal or government-controlled.
    • Even if the policy of presumptive denial was overturned, many companies, like Exodus Intelligence, are recognized as world leaders in such research, yet are very small businesses, with fewer than 10 employees, and sometimes zero-day research is performed by individuals like myself. As research firms, they are identifying new vulnerabilities and exploitation techniques every month. These solidly fall under the description of items to require an export license. To obtain a license for each of these items will consume at least as much effort as developing the items themselves. This is a very different situation than selling physical items or even traditional software, in which you can obtain an export license once, and continue to sell. Because of the nature of vulnerability research, it must be completely new every time.
    • This also poses a significant entry barrier for independent technical researchers working on spare time, as I once was when I was a student at a university; if a license was required, I would not have had any budget, time, or regulatory know-how for the legal application process. I would not have found or sold my zero-day exploits, and millions of users who ran software that was affected would not have been defended. The entry barrier is a large issue, since many researchers have similarly few resources. Such research will not continue for free.
    • As a result, research-focused companies will only be able to produce and obtain a license for about half their current output, if at all, either dramatically limiting their productivity or forcing them out of business altogether. Without access to this information, our ability to build defenses to these threats and stay ahead of attackers will be significantly reduced.
  2. The proposed regulations (http://www.federalregister.gov/a/2015-11642/p-21) also include the statement “that upon request from BIS, the applicant must 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.” This poses a devastating risk for two reasons:
    • A large portion of the income of many of these research and security firms comes from sales to government security agencies, such as FBI. Compelling us to turn over our source; which is our primary product, for free, is absolutely unacceptable and will prevent us from continuing to do much business.
    • Transferring such information to the BIS will invariably expose this information to foreign intelligence services (FIS’s) and cyber criminals, unless BIS is willing to handle all such information with the same protections as highly classified information. Since FIS’s and other hostile actors place a high value on vulnerability information, research organizations operate under very similar data security measures. Like almost all organizations, we don’t believe BIS or the majority of the US government has the expensive facilities, operation security processes, culture, and equipment necessary to protect this information against advanced cyber adversaries, and we have the experience responding to such breaches to prove it. This is an unnecessary exposure of critically confidential information.
  3. The categories of regulated software are also much too broad, and based on a mistaken assumption that there is a clear difference between “intrusion software” and normal software.
    • In reality, to better avoid detection, intrusion software makes every effort to blend in with normal traffic. Communication with malware to steal information goes across the same protocols and uses the same networking tools as normal web, email, file-sharing, and management software. Much of this does not require or use encryption (I dispute that “…most of the items impacted by this rule have encryption capabilities, BIS believes they are already being controlled under Category 5 part 2 of the EAR.” http://www.federalregister.gov/a/2015-11642/p-36) Intruders use many programs to obtain information, remotely control systems, which are the same as I have to investigate systems and administrators use to manage systems. The wording throughout this proposal could apply to the majority of network-communicating software and network management software sold by US companies. As a result, it has the potential to expose most US software companies to arbitrary prosecution and/or extensive go-to-market delays and competitive impact obtaining licenses.
    • Security software to monitor system activity for malicious attacks works the same way as “rootkit” software that monitors system activity to steal information. I developed the Ambush Host Intrusion Prevention System (Ambush HIPS), which like all HIPS software uses the same kind of hooks and other techniques as rootkits to monitor system activity. Malicious use could be obtained as just a matter of configuration, as with most software.
    • All bug-finding software falls under the definition of software specially designed for the discovery of zero-day vulnerabilities, yet this class of software is essential for the entire technology industry to find and fix software flaws.

Unless the proposed regulations can be overhauled to avoid handicapping legitimate security operations and research, they will reduce our security instead of improving it.

I fear the primary result of the proposed regulations is to enable federal regulators to arbitrarily fine and prosecute anyone in security or software development on whim, simultaneously the biggest reason to oppose these regulations and the biggest reason regulators may push them through anyway.

Comments are closed.