The cybersecurity control debates are not new. They have been around (at least in the US) since the early 90's, when the computer industry began the task of trying to move encryption technology controls from the International Traffic in Arms Regulations (ITAR) to the Commerce Control List (CCL). Movement of encryption technology from ITAR to CCL represented a relaxation of controls for products with embedded encryption technology. Up until that point encryption was viewed as a tool used only by governments. The act of moving encryption technology was perhaps the biggest factor in the explosive growth of the Internet. Today, encryption is a necessity for the protection of everything we do - from buying an item on the Internet to downloading purchased music or books, to protecting your bank transactions. In short, encryption has become ubiquitous. The major concern with encryption is that it can be used by terrorists and criminals to hide their plans and activities. Last year, the encryption debate expanded to include cybersecurity tools.
Proposed Cybersecurity controls:
Systems, equipment, components and software specially designed for the generation, operation or delivery of, or communication with, intrusion software include network penetration testing products that use intrusion software to identify vulnerabilities of computers and network-capable devices. Certain penetration testing products are currently classified as encryption items due to their cryptographic and/or cryptanalytic functionality. Technology for the development of intrusion software includes proprietary research on the vulnerabilities and exploitation of computers and network-capable devices. The new entry on the CCL that would control Internet Protocol (IP) network communications surveillance systems or equipment is restricted to products that perform all of the functions listed; however, the Export Administration Regulations (EAR) also prohibits the export of equipment if the exporter intends it will be combined with other equipment to comprise a system described in the new entry.
At first look, the proposed controls appear to be not that bad. They appear to say 'you need a license to export malware tools'. But, on closer examination, they cover much more than just malware tools. We all know malware tools are bad (after all, only criminals use them), but what is meant by 'technology required for the development of intrusion software'? Could this include compilers? Hence the logic might be:
Compilers are used in the creation of Malware tools.
If you now needed a license to export compilers, how would this impact industry? Never mind, as compilers would be exempted, but you get the point. Things can get very confusing, and even scary, very fast. Okay, so we can forget about compilers.
The next question becomes one of 'Do you use malware tools?' The answer is probably yes, depending on your job. For example, in preparing to make changes to your infrastructures you might analyze the changes and look to see if there are any issues. Once this is done, you would normally re-examine the change with automated penetration testing tools. Would these tools require an export classification request? The answer is probably yes.
But then again, how many of us would export these products? Of course it depends on what we mean by exports. In the US, we have two different types of exports -- the first one deals with the transfer of technology across physical boundaries; the second one deals with the communication of information to someone who is not a citizen (this is called a deemed export). So, if you put software on your corporate network you might be okay - if it is not global (and usually there is an exemption for intra corporate transfers). The deemed export rule is more tricky. You may be very careful with exposing export controlled technology on your network, but what about handing a copy to a co-worker - remember a deemed export is the transfer of information to a third party that is not a citizen. So letting a co-worker have access to some software could be considered an export in some circumstances - again this is probably not an issue due to exemptions.
Consider another scenario, you have discovered malware on your system. You look into it, and package your findings up. You post a copy of the malware and your analysis to a company that provides malware protection. The company is not in the US. Is this an export?
The good news is that this regulation was proposed and was not adopted. The bad news is that it was proposed and signals a requirement that we need to maintain our diligence as things are changing.
This having been said, earlier we were only talking about export controls. What about import controls? For example you have a subsidiary in China. Copying code across your network for work, might be okay from a US export perspective, but what about from a China Import perspective? What about when you copy it back from China to your local machine? This would be considered an export from China. In considering export and import you shouldn't forget the perspective of other countries, and the subsequent re-export.
The final issue you should probably know about is that security technology used to be found in one part of the regulations - Category 5 Part 2. Category 5 Part 2 deals with Information Security (encryption controls are included in this section). Over the past few years, we see security technology being placed in Categories 3 (Electronics Design, Development, and Production) and 4 as well as 5.
As much as these regulations are changing we have a lot of work ahead of us. If you are interested in this topic, check out the 6th Advanced Industry Forum on Global Encryption, Cloud & Cybersecurity Controls taking place on March 30 - 31 at the Sheraton Fisherman's Wharf in San Francisco, CA. Additional information can be found here: http://www.americanconference.com/2016/885/global-encryption-controls.