Skip to main content


Dangerously Vague Cybersecurity Legislation Threatens Civil Liberties

March 20, 2012

There is a spate of proposed cybersecurity legislation working its way through the House and Senate. The bills are aimed primarily at facilitating cooperation regarding so-called “cybersecurity” issues among different branches of government as well as between government and the private sector. The bills range from being downright terrible to appropriately intentioned, yet they all suffer from the fundamental inability to clearly define the threats which are being defended against and the countermeasures that can be taken against those threats. Without good definitions and an emphasis on transparency, we cannot be certain that government entities and corporations will refrain from abusing their power, interpreting the definitions in the statute expansively, and infringing on civil liberties. Below we provide some pitfalls of broad definitions, with a separate legal analysis forthcoming.

Defining threats too broadly

How do the bills define cybersecurity threat? Each bill has its own nomenclature, but the core concepts are quite similar. In Senator Joseph Lieberman's Cybersecurity Act of 2012 (S. 2105), for example, a "cybersecurity threat" is what is being guarded against, and a  "cybersecurity threat indicator" is the activity of a possible cybersecurity threat that allows private or government entities to monitor and operate countermeasures. For technical readers, a cybersecurity threat could be stealing passwords from a secure government server, and the corresponding threat indicator could be a port scan to search for vulnerabilities. Senator John McCain's SECURE IT Act (S. 2151) does not use the term "cybersecurity threat indicator" but uses virtually identical language to define "cyber threat information." In all cases, the language of what constitutes the notion of a "threat" and "threat indicator" is just too vague. 

For example, one current provision of the Lieberman bill states:

The term “cybersecurity threat” means any action that may result in unauthorized access to, exfiltration of, manipulation of, or impairment to the integrity, confidentiality, or availability of an information system or information that is stored on, processed by, or transiting an information system. [text]

Moreover, a cybersecurity threat indicator is defined in the text as a huge disjunction of vaguely worded scenarios that include, for example: “a method of defeating a technical [or operational] control.” Such a broad definition implicates far more than what security experts would reasonably consider to be cybersecurity threat indicators --- things like port scans, DDoS traffic, and the like. Indeed, merely using a proxy or anonymization service to let you browse the web privately could be construed to be a cybersecurity threat indicator. Using cryptography to protect one's communications or access systems securely could similarly be taken as a way to defeat an operational control. Measuring the performance of one's Internet service provider, or analyzing whether packets are being modified maliciously could all be seen as cybersecurity threats under this definition. Finally, it is conceivable that violating intellectual property rights could be construed as a threat, in which threat indicators could be as innocuous as the use of the BitTorrent protocol.

This definition of threat indicators is troubling because § 701 of the Lieberman bill and § 102(a)(1) of the McCain bill would each authorize private sector entities to surveil any traffic that transits their own networks for cybersecurity threats or cyber threat information, without being bound by the Wiretap Act or other legal limits. Effectively, the broad definitions of threats could immunize a whole host of monitoring activities by a huge swath of different government and non-government actors.   

Defining countermeasures too broadly

In addition to defining threats, these bills also authorize private entities to operate “countermeasures.” Once again, the language varies from bill to bill, but for the most part, the strongest restriction on the countermeasures is that there be a “defensive intent” (language that appears in both the Lieberman and McCain bills). The Lieberman bill mentions "modify[ing] or block[ing] data packets," while the McCain bill is more vague. But without more restrictions on what sorts of countermeasures are allowed, the door is open to a host of abuses.

Let's consider one example scenario, where we examine a particular threat and the myriad possible mitigation techniques that an intermediary might employ. One straight forward cybersecurity threat is DDoS, in which many different IP addresses are used to send an incredible amount of traffic towards a target, knocking it offline and making the targeted service unavailable to legitimate users. No doubt this is a hazard that can be hugely detrimental to the service in question, and it is quite legitimate for a bill about cybersecurity to aim to defend against this threat. But how exactly do we defend against it? In this case, the devil is very much in the details.

One way to defend against DDoS attacks would be for the entity under attack to disclose a list of traffic sources to its ISP and ask the ISP to temporarily filter out traffic from these sources, effectively blocking them from accessing the resource during the blackout period, say, of a few hours. This seems like a pretty reasonable thing to do. But suppose instead of waiting for the DDoS victim to disclose the traffic sources, the ISP uses its own traffic inspection tools to detect the DDoS and stop it preemptively. Well that's nice, but are ISPs now inspecting everyone's traffic? Are they looking at content of data packets, or just the destination and volume of traffic? More ISP involvement in traffic analysis is an alarming trend that would raise many civil liberties concerns.

Our hypothetical DDoS-mitigating ISP could go even further. Tor is an extremely valuable privacy-enhancing technology that routes one's web traffic through a rigorous anonymization service. Our ISP could find that it is too hard in general to distinguish the legitimate Tor traffic from the illegitimate, and so either on purpose or by accident start blocking Tor traffic entirely under the guise of operating cybersecurity countermeasures.

And why stop with one pesky privacy-enchancing technology? Our ISP could block all traffic on certain ports, or filter at the DNS level or based on the content of packets. Cryptographic protocols could be crippled, all in the name of defensively “operating countermeasures” against the alleged threat of DDoS. Finally, our ISP could decide that your computer is part of a botnet, and so trick you into downloading software that gives the ISP or other agencies access to your computer so that it can root out the botnet. After all, the best defense in many cases is a strong offense. Furthermore, beyond the DDoS example, operating countermeasures could be taken to include intellectual property enforcement, for example by filtering at the DNS level.

The above scenarios are speculatory, and we have no idea what countermeasures actually will be employed. The important point is that beyond the phrase “defensive intent,” the bills give no guidance at all as to which countermeasures outlined above are reasonable. The real decisions will be made behind closed doors with no input from stakeholders outside of the intelligence community and the private sector, and with no transparency about what is actually being done.

Towards a better bill

In order to write a cybersecurity bill that appropriately safeguards civil liberties, specificity is of the utmost importance. The bill's authors have chosen to avoid using specific language (e.g. port scan, DDoS, intrusion detection system), presumably because they want the bill to stay relevant even as technology changes. While this is a laudable goal, it is unrealistic given how rapidly the technological landscape changes. A better approach is to use concrete language, and to be crystal clear about what information is being shared and how. The particulars should NOT be left to be decided via an opaque process, but rather debated openly and transparently right now. Being specific has the ostensible disadvantage that it makes the bill less relevant in the future as technology changes. We actually think this is an advantage, since it effectively limits the lifetime of the bill, and forces new legislation and a fresh look once the technology changes and we are facing a potentially very different set of issues.

We've so far discussed the pitfalls of vagueness without getting into what we think are the right answers are. While it is beyond the scope of this post to, say, propose an entire draft of a better cybersecurity bill, there are some guidelines we can give from the technical point of view when deciding upon the specifics.

  • Keep the Internet working and reliable. Giving ISPs and other entities the ability to operate countermeasures poses a serious threat to the reliability of Internet communications. Limiting countermeasures to "defensive intent" is not enough of a safeguard to ensure the reliability and availability of systems that we rely upon.
  • Cybersecurity for the 99%. The intelligence community within the government benefits from keeping attacks secret so that they can be deployed against our enemies, and very likely stockpiles zero-day exploits for this offensive purpose. There is then pressure to selectively harden sensitive targets while keeping the attack secret from everyone else and leaving popular software vulnerable. This is "security for the 1%," and it makes the rest of us less safe. A good cybersecurity bill serious about defending against security threats would address this issue directly and insist that any threats that are found are fixed for everyone, and explicitly disallow any clandestine operations that do not disclose vulnerabilities.
  • Privacy-enhancing technologies are not threats. Tools such as Tor are used every day by activists around the world in sensitive situations. These should be explicitly protected in a good cybersecurity bill.

Take action

As written, these bills could provide immunity to ISPs and other private and government actors for all of the egregious behavior outlined above involving the monitoring, blocking, and modification of data packets. Until a better bill emerges, we urge you to take action to oppose these bills in their current form.

JavaScript license information