How CISA’s Countermeasures Authorization Threatens Security

Written by Jake Laperruque

 

2015-07-28-CISA-countermeasure_narrow

The Cybersecurity Information Sharing Act (CISA, S. 754) authorizes operation of countermeasures, referred to as “defensive measures” in the legislation. These countermeasures could include deployment of hazardous software that can damage external systems, data, and devices.

CISA authorizes operation of countermeasures notwithstanding any other law, including the Computer Fraud and Abuse Act (CFAA) – the federal anti-hacking statute. The limitations on this authorization are insufficient to prevent harms. First, countermeasures must be “applied to” one’s own network, but can have extra-network effects. Second, countermeasures cannot “destroy, render unusable, or substantially harm” a third party’s information system or data on such a system, but they can cause “harm” to information or an information system so long it is not “substantial,” they can cause “substantial harm” to devices that store or process data, and they can be used to gain unauthorized access to information systems. These restrictions fail to effectively prohibit countermeasures with negative external effects, potentially opening a pandora’s box of reckless activities detrimental to computer security such as fork bombs, helpful worms, and ransomware, which we explain below. This is especially problematic given the high risk of misattribution and escalation associated with cyber attacks.

Misattribution means countermeasures could harm victims rather than cybercriminals.

Attributing a cyber attack to a particular attacker is difficult, and as a result, the risk of misattribution is high and countermeasures deployed may strike innocent third parties. Malicious hackers often obscure the source of their attack by leaving a “false trail” that will lead to misattribution. They route attacks and exfiltration of data through proxies, and use of botnets of infected computers. These “shields” propped up by attackers can be innocent online “bystanders” or even computers running critical infrastructure. A retaliatory countermeasure can strike a proxy victim rather than the malicious hacker.

Countermeasures Risk Escalation and Could Provoke International Incidents.

Countermeasures directed at state entities that are deployed by private entities can provoke international incidents. If a company’s countermeasure against a cyber attack seeking to steal trade secrets damaged or even just surveilled military networks of the government of China, the company could create a diplomatic crisis or prompt retaliation. The risk of misattribution heightens these concerns because the company deploying the countermeasure might not even know that it will affect a foreign government’s network. A cybercriminal – or a group deliberately seeking to create international discord – could attempt to use a foreign nation as a proxy. For example, a 2009 denial of service attack against American and South Korean websites originally thought to have been perpetrated by North Korea was eventually traced back to Miami – the hackers had merely routed their attack through North Korea.[1] If a countermeasure automatically acted against an attack, it could harm a state actor before there is any conclusive determination about the source of the attack.

Putting aside the risks of misattribution and of countermeasures provoking international incidents, the countermeasures that CISA would permit can cause harm. Examples of these countermeasures and the harms to innocent third parties, critical services, or foreign nations they can cause, follow:

  • A “Fork Bomb” Slows and Crashes Systems To Which Stolen Data Is Exfiltrated:

A “fork bomb” is software programmed to replicate repeatedly with the goal of depleting a system’s resources to the point of slowing or crashing it. As authorized by CISA, a fork bomb could be applied to one’s own network by attaching it to data – or even a “honeypot” designed as fake data to misdirect cybercriminals – and be designed to activate when moved to an external system in an unauthorized manner. This fork bomb could slow a system without rendering it fully “unusable;” thus its use could be authorized even if the software deployed against innocent victims in a botnet. A fork bomb could also crash a system – but only temporarily – and constitute less than the “substantial harm” that would make it impermissible under CISA. Moreover, if a malicious hacker routes his attack through information systems that support sensitive or critical infrastructure and those systems are hit with a fork bomb countermeasure, a momentary crash could have major ramifications for devices and services attached to those information systems. Malicious hackers may be incentivized by the defensive countermeasures authorized by CISA to stage their attacks from systems that are tripwired to cause external harms when countermeasures are launched.

  • A “Helpful Worm” Crashes Systems To Which Stolen Data Is Exfiltrated:

A “helpful worm” is software designed to automatically enter systems and remove malware. But, sometimes, “helpful” worms turn out to be harmful. Helpful worms such as Den_Zuko, CodeGreen, and, most notoriously, Welchia, all resulted in shut downs, glitches, and other negative effects to systems that strongly outweighed the intended benefits.[2] CISA could authorize applying a helpful worm to one’s own network by attaching the worm to data and setting it to activate if the data are stolen. This could occur with honest intentions of striking back at a botnet, but past examples demonstrate the strong risk of unintended consequences. Helpful worms often cause glitches and crashes that exceed the damage of the initial virus they were designed to stop, but may not meet the threshold of “substantial harm” that CISA excludes.

  • Ransomware Leaves Systems Intact But Inaccessible:

“Ransomware” is malware that restricts access to a system or data on it. CISA could authorize ransomware-like software that is applied to one’s own data or network that could activate further to perform other functions as soon as it is accessed by an unauthorized external system or if it is removed from the deployed network. This would block access to data and potentially perform other surveillance functions but would leave the system fully functional and intact, and therefore may not fall within CISA’s prohibition on countermeasures that cause substantial harm or render a system unusable. In contrast, the Protecting Cyber Networks Act passed in the House earlier this year (H.R. 1560) contains a more encompassing exclusion against countermeasures that render a system “unusable or inaccessible (in whole or in part).” CISA’s failure to similarly ban countermeasures that render a system inaccessible could be interpreted as authorizing measures such as ransomware that locks users out of an otherwise fully functional system. Permitting such a measure could have serious repercussions, especially if the attacker hit with a ransomware response was a nation-state, such as a scenario in which a hacked U.S. company were suddenly blocking access to North Korean government systems.

Countermeasures that Violate the CFAA Should Not Be Authorized

Given the risks and uncertainties, we strongly recommend against the authorization of countermeasures in CISA. Such an authorization is not only dangerous, but also unnecessary. Current law permits a variety of purely defensive measures such as use of firewalls and honeypots containing fake data caches, and no examples of desired defensive measures prohibited by current law have been provided in the ongoing debate. If any new authorization for countermeasures is provided, it is essential that this authorization not permit violations of the CFAA, or that it prohibits countermeasures that have adverse effect on external systems.

 

 

Footnotes:

[1] See, Jack Goldsmith, How Cyber Changes the Laws of War, EJIL (2013), Vol. 24 No. 1, 129–138, 132, available at http://ejil.oxfordjournals.org/content/24/1/129.full.pdf.

[2] See, Gene Bransfield, The Welchia Worm, SANS Institute (December 18, 2003), available at:https://www.giac.org/paper/gcih/517/welchia-worm/105720 (“Like every “good worm” before it, including Den_Zuko, Cheeze, CodeGreen and the Millenium worm, Welchia came in peace, but left the network in pieces. Whatever it’s intentions, the end could not justify the means”).

Share Post