In the summer of 2005, systems administrators and security researchers from all over the world gathered in Las Vegas, Nevada for Black Hat, one of the largest computer security conferences in the world. On the morning of the first day, Michael Lynn, one of the authors of this book, was scheduled to speak about vulnerabilities in Cisco routers. These vulnerabilities were serious: an attacker could take over the machines and force them to run whatever program the attacker wanted.
Cisco did not want Lynn to give the presentation. After last-minute negotiations with Lynn's employer, ISS, the companies agreed that Lynn would have to change his talk. A small battalion of legal interns converged on the convention floor the night before the speech and seized the CDs that contained Lynn's presentation slides for the talk and removed the printed materials out of the conference program.
Lynn, however, still wanted to give the original speech. He thought it was critical that system administrators know about the router flaw. A simple software upgrade could fix the problem, but few, if any, knew about the vulnerability. Lynn thought disclosure would make the Internet more secure. So, he quit his job at ISS and gave the talk he originally planned.
That evening, Cisco and ISS slapped Lynn, and the Black Hat conference, with a lawsuit.
We live in the Information Age, which means that information is money. There are more laws protecting information now than there were 25 years ago, and more information than ever before is protected by law. Cisco and ISS alleged that Lynn had violated several of these laws, infringing copyrights, disclosing trade secrets, and breaching his employment contract with ISS.
Lynn came to me because I've spent the last 10 years studying the law as it relates to computer security. I've advised coders, hackers, and researchers about staying out of trouble, and I've represented clients when trouble found them anyway. I've given speeches on computer trespass laws, vulnerability disclosure, and intellectual property protection at Black Hat, to the National Security Agency, at the Naval Postgraduate School, to the International Security Forum, and at Australia's Computer Emergency Response Team conference. I've been a criminal defense attorney for nine years and have taught full time at Stanford Law School for the last six years.
I believe in the free flow of information and generally disapprove of rules that stop people from telling the truth, for whatever reason. But I understand that exploit code can also put a dangerous tool in the hands of a malicious, but otherwise inept, attacker. I believe companies need to protect their trade secrets, but also that the public has a right to know when products or services put them at risk.
Lynn told me that Cisco employees who had vetted the information were themselves unable to create a usable exploit from the information he gave them. But Lynn wanted to show people that he knew what he was talking about and that he could do what he said could be done. He included just enough information to make those points.
I know a lot about computer security for a lawyer, but not as much as a real security engineer, so I asked a couple of Black Hat attendees about the substance of Lynn's presentation. They confirmed that Lynn's presentation did not give away exploit code, or even enough information for listeners to readily create any exploit code. After a marathon weekend of negotiating, we were able to settle the case in a manner that protected my client from the stress and expense of being sued by a huge company.
I began this exploration of security ethics and issues with Michael Lynn and the Black Hat affair, not because of its notoriety in security circles, and certainly not to embarrass or promote him or the companies that filed suit, but because the case really does raise fascinating legal issues that the security marketplace is going to see again and again. You can substitute one company's name for another, or one defendant for another, and the issues remain just as current. This chapter is going to review these legal issues in an open-minded way. Let's begin with a few simple items from the Lynn case.
One of the allegations was the misappropriation of trade secrets. A trade secret is information that:
(1) Derives independent economic value, actual or potential, from not being generally known to the public or to other persons who can obtain economic value from its disclosure or use; and (2) Is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.
What was the secret? Lynn did not have access to Cisco source code. He had the binary code, which he decompiled. Decompiling publicly distributed code doesn't violate trade secret law.
Could the product flaw itself be a protected trade secret? In the past, attorneys for vendors with flawed products have argued that researchers would be violating trade secret law by disclosing the problems. For example, in 2003, the door access control company Blackboard claimed a trade secret violation and obtained a temporary restraining order preventing two researchers from disclosing security flaws in the company's locks at the Interz0ne II conference in Atlanta, Georgia. What if we had the same rule with cars? Imagine arguing that the fact that a car blows up if someone rear ends you is a protected secret, because the market value drops when the public knows the vehicle is dangerous. No thoughtful judge would accept this argument (but judges don't always think more clearly than zealous attorneys do).
Even if there is some kind of trade secret, did Lynn misappropriate it? Misappropriation means acquisition by improper means, or disclosure without consent by a person who used improper means to acquire the knowledge.
As used in this title, unless the context requires otherwise: (a) Improper means includes theft, bribery, misrepresentation, breach or inducement of a breach of a duty to maintain secrecy, or espionage through electronic or other means. Reverse engineering or independent derivation alone shall not be considered improper means.
The law specifically says that reverse engineering "alone," which includes decompiling, is a proper, not improper, means of obtaining a trade secret.
What does it mean to use reverse engineering or independent derivation alone? Lynn reverse-engineered, but the complaint suggested that Cisco thought decompiling was improper because the company distributes the router binary with an End User License Agreement (EULA). that prohibits reverse engineering
What legal effect does such a EULA term have? Probably 99.9 percent of people in the world who purchase software do not care to reverse engineer it. But I maintain that society is better off because of the .1 percent of people who do. Reverse engineering improves customer information about how a product really works, promotes security, allows the creation of interoperable products and services, and enables market competition that drives down prices while providing, in theory, better protects. Lawmakers recognize the importance of reverse engineering, which is why the practice is a fair use under the copyright law, and why statutes go out of their way to state that reverse engineering does not violate trade secret law. Yet, despite these market forces, the trade secret owner has little or no incentive to allow reverse engineering. Indeed, customers generally do not demand the right. Increasingly, EULAs cite no reverse engineering. Should vendors be allowed to bypass the public interest with a EULA? It's a serious issue.
The Lynn case illustrates that a simple decision by a researcher to tell what he knows can be very complicated both legally and ethically. The applicable legal rules are complicated, there isn't necessarily any precedent, and what rules there are may be in flux. One answer might be simply to do what you think is right and hope that the law agrees. This, obviously, is easier said than done. I was persuaded that Lynn did the right thing because a patch was available, the company was dragging its feet, the flaw was important, and he took pains to minimize the risk that another person would misuse what he had found. But making ethical choices about security testing and disclosure can be subtle and context-specific. Reasonable people will sometimes disagree about what is right.
In this chapter, I talk about a few of the major legal doctrines that regulate security research and disclosure. I will give you some practical tips for protecting yourself from claims of illegal activity. Many of these tips may be overcautious. My fervent hope is not to scare you but to show you how to steer a clean, legal path. Inevitably, you will be confronted by a situation that you cannot be sure is 100 percent legal. The uncertainty of the legal doctrines and the complexity of computer technology, especially for judges and juries, mean that there will be times when the legal choice is not clear, or the clear choice is simply impractical. In these situations, consult a lawyer. This chapter is meant to help you spot those instances, not to give you legal advice.
Furthermore, this chapter discusses ethical issues that will arise for security practitioners. Ethics is related to but is not the same as the law. Ideally, the law imposes rules that society generally agrees are ethical. In this field, rules that were meant to stop computer attacks also impact active defense choices, shopping bots, using open wireless networks, and other common or commonly accepted practices. Where the laws are fuzzy and untested as in the area of computer security, then prosecutors, judges, and juries will be influenced by their perceptions of whether the defendant acted ethically.
That having been said, frequently ethics is a matter of personal choice, a desire to act for the betterment of security, as opposed to the private interests of oneself or one's employer. Some readers may disagree with me about what is ethical, just as some lawyers might disagree with me about what is legal. My hope is that by reasoning through and highlighting legal and ethical considerations, readers will be better equipped to make a decision for themselves when the time arises, regardless of whether they arrive at the same conclusions I do. Now, I must give you once last disclaimer. This chapter is a general overview. It does not constitute legal advice, and it could never serve as a replacement for informed legal assistance about your specific situation.
You should be better able to identify when your security practices may implicate the following legal topics:
Computer trespass and unauthorized access
Reverse engineering, copyright law, EULAs and NDAs, and trade secret law
Anti-circumvention under the Digital Millennium Copyright Act (DMCA)
Vulnerability reporting and regulation of code publication
Because these concepts are complicated and the law is untested and ill-formed, readers will not find all the answers they need for how to be responsible security practitioners within the law. Sometimes the law over-regulates, sometimes it permits practices that are ill-advised. There will almost certainly be times when you do not know whether what you are about to do is legal. If you aren't sure, you should ask a lawyer. (If you are sure, perhaps you haven't been paying attention.)
Let's investigate these four areas, beginning with trespass.