Last updated at Tue, 29 Aug 2017 23:03:28 GMT

On May 20th 2015, the Bureau of Industry and Security (BIS) published its proposal for implementing new export controls under the Wassenaar Arrangement. These controls would apply to:

  • systems, equipment or components specially designed for the generation, operation or delivery of, or communication with, intrusion software;
  • software specially designed or modified for the development or production of such systems, equipment or components; software specially designed for the generation, operation or delivery of, or communication with, intrusion software;
  • technology required for the development of intrusion software.

The controls also apply to surveillance software; however, in this post I will be focusing on the category above as this relates more closely to Rapid7, our customers, and our community.

The background

The Wassenaar Arrangement is not a new thing; it has been around since 1996. It's an export control understanding between 41 nation states and was originally devised to control the export of weapons and dual-use technologies (which is a broad term that seems to mean technology that can have both military and non-military uses).

The Wassenaar's decision-making body – the Plenary – meets annually in December to discuss changes and implementations. During the December 2013 meeting, the group agreed the Arrangement should also cover the intrusion and surveillance technologies. Since then, many of the 41 member nations have implemented the rules.

This post will focus on the US implementation as we are a US company, and it is the US implementation which is currently open for consultation. We may update our accompanying FAQ with information on other international implementations in the future.

The US Government has not yet implemented this addition to the Wassenaar. In May, it published a proposal outlining the way the new rules would be implemented in the US, and invited feedback. The community has until Monday, July 20th 2015 to submit comments in response.

Rapid7 intends to participate in the consultation process and will submit comments. We encourage you to do likewise if you have concerns with the proposal.

Rapid7's take

In some ways the proposal raises more questions than it answers, and in seeming recognition of this, BIS recently published a supplemental FAQ. This does seem to have answered some of our questions, but not all. I've reproduced below some of the key questions we asked ourselves as we reviewed the proposal.

How will Wassenaar relate to Metasploit exports?

Since the BIS proposal came out, we have received many questions from customers and community members about how it will relate to the export of our penetration testing platform, Metasploit. We have been cautious in answering this question. It's clear from the way BIS defines the technology covered by the Proposed Rule that it WILL apply to Metasploit; however, it's currently unclear to what extent. It should be noted here that the proprietary versions of Metasploit (namely Metasploit Community and Metasploit Pro) are already subject to US export controls, and the Wassenaar Arrangement will extend, rather than replace those controls.

  • Will it apply to the open source Metasploit Framework?
    BIS's Wassenaar proposal doesn't explicitly tackle this as the US plans to maintain the current status quo of how open source projects are addressed. Under the current US export controls – the Export Administration Regulation (EAR) – the Metasploit Framework is exempt from the export control due to its open source status. The exemptions for open source are nuanced, so if you run a related open source project, please don't assume you will be exempt – you should seek legal counsel.

  • Can we export the commercial editions of Metasploit?
    We can export commercial editions of Metasploit to Canada without complication. For any other exports, it is a question of whether we would require a license or would be subject to a blanket denial, which would mean we could not sell Metasploit internationally at all. The blanket denials will be applied to technologies that include “zero day exploits” and “rootkits.” The proposal does not offer definitions for either term, leaving them open to multiple interpretations, which would create a murky regulatory environment for exporters attempting to comply with the new regulations.

    There is some discussion in the community around whether these categories should be included in the Proposed Rule at all, particularly with an emphasis on the impact on security research (more on that below). I expect/hope we will see a lot of comments submitted that make a case against the inclusion of these elements.

    In case these submissions are unsuccessful, our comments to BIS will include the following recommendations for definitions. As you'll see, we focused on whether exploits have been publicly disclosed:

    Zero-Day Exploit:  A software tool that takes advantage of a security vulnerability that is not publicly known.  Security vulnerabilities will be deemed publicly known if: (1) they are the subject of a published notice or advisory that is generally available to the public, or (2) [45] days have passed since the vulnerability was reported to a software developer or a vulnerability reporting organization.

    Rootkit: A non-public, post-exploit software tool that is primarily useful for maintaining control of a computer system without being detected, in a manner that is not authorized by the owner or system administrator of the computer system, after the computer system has been compromised.

  • If we can export the commercial editions under licenses, how will that work?
    According to the proposal, vendors can apply for “broad authorizations to certain types of end users and destinations.” As yet, there is little information on how these licenses will work in practice. It is likely to place a hefty burden on companies like Rapid7. We will be forced to devote increased resources to prepare license requests, and to comply with other potential regulatory requirements, such as enhanced reporting and pre-shipment notifications.  The costs associated with these compliance efforts will inevitably be passed on to consumers in the form of higher prices. In addition, customers will face delays while the Government processes license applications.

    The licensing burden will also put Rapid7 and other US companies at a disadvantage when compared to non-American and non-Wassenaar-state competitors who rely on Metasploit Framework, but have none of the regulatory obligations that American companies will have.

How will Wassenaar impact Metasploit contributors?

The commercial editions of Metasploit (and several other security testing solutions) are built on top of the open source Metasploit Framework. We have a fantastic community that contributes exploits to this from all around the world. We wanted to understand how the Wassenaar Arrangement would impact our international contributors given that in 2014 alone, a third of the Top 25 Metasploit contributors were based outside the US.

There's no quick answer to this. According to BIS' FAQ, you can export the exploits themselves without issue. However, every participating nation state implements Wassenaar in their own way, consistent with their broader export approach. If you are a Metasploit contributor outside the US, we recommend you look into the export rules in your own country.

How will Wassenaar impact our Metasploit customers?

As noted above, penetration testing and other cybersecurity products that utilize encryption are currently subject to export restrictions under the EAR. This rule currently grants a license exception to US companies, authorizing them to transfer technologies like Metasploit for use in their overseas subsidiaries and facilities. Wassenaar will eliminate this license exception and US companies will need to obtain export licenses to send cybersecurity products to their overseas facilities for internal use.

Rapid7 believes that the removal of this license exception unnecessarily interferes with the legitimate security activities of US companies. Imposing a licensing requirement on the internal deployment of products will lead to delays, and will chill the widespread use of new and effective products.  The Proposed Rule should be revised to authorize exports of cybersecurity products to US companies and their overseas subsidiaries for their own internal use.

How will Wassenaar impact penetration testers?

Penetration testers rely on intrusion technologies to do their job, and many travel internationally in the course of their work. The hand carriage of a computer and/or software outside of the US constitutes an export. Currently, there are several license exceptions under the EAR that authorize individuals to hand carry a computer and/or software outside the US, provided that the conditions and limitations associated with the license exceptions are followed. Under the Proposed Rule, however, individuals would NOT be able to rely on these license exceptions when traveling outside of the United States with intrusion or surveillance items. In these cases, penetration testers (and other individuals) would be required to obtain a specific license in advance of their trip.

How will Wassenaar impact security researchers?

The regulatory and legislative pressures placed on security researchers is a major area of concern for Rapid7. It should be a concern for everyone as research drives awareness of risks, enables consumers to make informed choices to protect themselves, and facilitates remediation efforts.

Research is not specifically addressed in the Proposed Rule, although BIS has stated that its intent is not to interfere with “non-proprietary research.” While undefined by BIS, we interpret this to mean research activities that are intended to lead to the public identification and reporting of vulnerabilities and exploits (in contrast to bug bounties, or research relating to exploits that will be sold commercially). In the Federal Register notice announcing the Proposed Rule, BIS explained that the proposed controls on technology for the development of intrusion software would include proprietary research on the vulnerabilities and exploitation of computers and network-capable devices. BIS has since elaborated that these proposed controls would regulate, among other things, proprietary (i.e., non-public) technology relating to the development, testing, evaluating, and productizing of exploits, zero days and intrusion software.

Notably, research regarding exploits that incorporate encryption is currently (and will continue to be) regulated pursuant to the encryption controls under the EAR.  These controls restrict the ability of researchers to transmit or publish exploits that utilize encryption if those exploits are not in the public domain.  Under the EAR, the only way to report and publish exploits that utilize encryption without an export license is to make the exploit publicly available pursuant to License Exception Technology Software Unrestricted (TSU), whereby the exporter provides the U.S. Government with a "one-time" notification of the location of the publicly available encryption code prior to or at the time the code is placed in the public domain.

The way I read all this does not look positive for researchers participating in international bug bounties, or those selling exploits. We hope BIS will revisit this and consider the impact on the general level of security for the internet, and for US and international organizations alike. Many US businesses rely on software made outside the US, which will suffer if US researchers are discouraged from testing and validating their technologies.

Next steps

In the current political and technological climate, export controls for intrusion technologies feel inevitable to me. The proposed US implementation does raise some very serious concerns though, and security professionals should pay attention. Whatever your area of focus, as a security professional, the likelihood is that the Proposed Rule will impact you or your organization in some way.

As stated above, we're working on a comment submission for BIS that will cover the points outlined in this post. We encourage you to do likewise, and if there is anything we can do to help, please email us, or you can post a comment below. We have an accompanying FAQ that we will add to as questions arise – please do let us know if you have a question you would be interested in us addressing.

- @infosecjen