- Journal Archives
- Volume 16
- Volume 15
- Volume 14
- Volume 13
- Volume 12
- Volume 11
- Volume 10
- Volume 9
- Volume 8
- Volume 7
- Volume 6
- Volume 5
- Volume 4
- Volume 3
- Volume 2
- Volume 1
When an organization’s computer systems come under attack, it usually wants to minimize the damage as quickly as possible. For some types of attacks, like SQL injection or cross-site script injection, the clear path forward is to identify and close the vulnerability that allowed the attack in the first place, then clean up the other problems the attacker may have caused (backdoors, etc.). But this process does not work well for some other types of attacks.
For example, in a distributed denial-of-service (DDoS) attack, a large number of systems make (mostly) ordinary requests, for example asking for the main page of a website, that would not be troublesome individually. But since there are so many, they overwhelm the system’s ability to respond to legitimate requests, leaving real visitors unable to access the site or its services. The computers making the attack requests might be owned by the attackers, but they might not: they could be compromised themselves (black-market services rent “botnets” of virus infected machines to participate in these sorts of things), connecting to another innocent-but-compromised system to receive commands, and the actual attacker may be virtually untraceable.
In September a series of high-profile DDoS attacks were carried out against several banks, and in December a division of the U.S. Treasury Department issued a warning indicating that the attacks had multiple motives, including distracting bank personnel from monitoring fraudulent transactions and making it difficult or impossible for customers to report fraudulent transactions over using the bank’s website. Planning can help when responding to a DDoS incident, but there is usually no single hole or vulnerability to address, since the problem is simply one of finite available resources. The best protection against a DDoS attack is the ability to scale services up rapidly and handle all of the requests normally, but this only gives the attacker a reason to launch an even bigger attack next time. In many ways DDoS is an arms race between high-availability websites and their attackers.
So, what are the banks (and others in similar situations) to do? One possible answer is to swap defense for offense. This is sometimes called “hacking back,” “active defense,” “self-defense,” depending on your point of view (and on the scope of the activity). The idea is that if the organization under attack can cripple the attacker’s ability to launch and maintain a DDoS offensive, it can render the attack ineffective. But what can it legally do to achieve that goal? Gather information from its own logs, or from publicly available sources? Definitely yes. Reconfigure its systems to make DDoS more difficult? Certainly. Can it identify a vulnerability in the many systems carrying out the DDoS attack and configure its servers to send a special response to crash those systems? That’s much less certain. Remember, these might be malicious systems, but they also might be innocent systems infected with malware. Can it launch its own outbound attacks against the systems participating in the DDoS attack? Maybe, but probably not: that action likely constitutes a violation of anti-hacking laws in its own right. What about attacking the command-and-control servers DDoS attackers typically use to coordinate their activity? If the victim can identify the C&C, can they insert “good” malware to gain partial control, and monitor the malicious activity of the C&C? Can the “good” malware disable the program running the C&C service? (What if the “C&C” actually piggybacks on a legitimate service, like a website–or a blog?) Can it disable the host completely by corrupting its operating system? Traditional views of anti-hacking law again say none of this is allowed. But is that true? And is it socially desirable? Should the law of trespass or necessity apply here, granting a limited “right” to repel attackers? Should operators of critical infrastructure like hospitals and power plants have a broader right to engage in active defense? What happens if a critical-infrastructure system is one of the innocents caught in the crossfire–would they have a broader right than you I to sue “active defenders?”
In short, traditional defense is not always enough. When you are under attack, what rights do you have today, and what rights should you have tomorrow, to fight back in a such a way that may (or may not) affect possibly-innocent, infected, bystanders? Although there are not yet any cases that address the issue, it may only be a matter of time. There are start-ups already focused on (legal) active defense, and companies like the banks that experienced daylong outages last year may be more willing to engage in a new, untested tactic. A group of information security analysts and lawyers also recently formed a discussion group to address these questions (disclosure: I help manage the email list). Another group of law professors and practitioners recently had a lengthy discussion on the popular legal blog Volokh Conspiracy, analyzed at length (and all in one place) here. They debate the CFAA, with the traditional view broadly prohibiting active defense, and several different understandings that would permit some active defense based on the text of the CFAA, policy, common-law trespass, and common-law tort. Other cyberlaw, information security, and technology bloggers have analyzed the issues as well. Where should we go from here? What, if any, active defense–or was it hacking back?–should be allowed? And is that what is allowed today?
Recent Blog Posts
- $400 Million Settlement: E-book Price-Fixing May Cost Apple Big Time
- Kramer Sues Seinfeld Staff Writer for Defamation–and Loses
- Which “Duke” Will Reign?: Wayne Estate Seeks to Limit the Reach of Trademarks
- The Miss America Rule
- Possible Changes Coming to E-Discovery Rules
- “What Would Jesus Do” Trademark Win for Tyler Perry
Tagsadvertising antitrust Apple books career celebrities contracts copyright copyright infringement courts creative content criminal law entertainment Facebook FCC film/television financial First Amendment games Google government intellectual property internet JETLaw journalism lawsuits legislation media medicine Monday Morning JETLawg music NFL patents privacy progress publicity rights radio social networking sports Supreme Court of the United States (SCOTUS) technology telecommunications trademarks Twitter U.S. Constitution