Surfing with the sharks An exposé of the legal liabilities and responsibilities of system administrators

March  1996

A list of seven scenarios illustrates the legal ramifications and responsibilities of being a system administrator. Are you liable for information contained within your company's Web server? Does its (mis)behavior make you a criminal?

Mail this article to a friend

Most of us would use "system managers" and "lawyers" in the same sentence about as frequently as the words "spumoni" and "zamboni." System administrators deal with "briefs" by wearing shorts to work. Lawyers deal with computers by duly noting that Lance Ito had a laptop on his bench, calling into question the use of the word "lap." Recent trends, however, make it not only interesting but downright necessary to learn to surf with and around the sharks:

• The explosion of Internet access places a greater responsibility on you for keeping your data and users safe. Legislation such as the Communications Decency Act and the longer-standing International Treaty on Armament Regulation (ITAR) impose serious penalties for letting the wrong person access the wrong data.

• As keeper of security, encryption, privacy, and valid use policies, you inherently acquire authority that carries an equal measure of liability. Someone will be held accountable when there's a mishap, and it's likely to be you.

• Computer systems law is a remarkably gray area in which there are few precedents. When there's a crisis, your employer is more likely to wash its hands of the problem -- and you -- rather than spend the time and effort needed to mount a valiant defense.

This month, we'll do our annual departure from the command line interface and explore the legal implications of system management. Some of this material is taken from Dan Appelman's "Legal Issues for System Administrators" tutorial (more on this later). Let's start with a pop quiz (tabulated answers will be available for your perusal next month), and then discuss each situation posed in a bit more detail. Pointers to relevant books and on-line sources will provide additional background and food for thought. Our goal is not to make you rush out and profess love for your local counsel. Instead, we're trying to raise awareness of issues and public policy topics around which to rally your peers and your organization, using a minimal quantity of Latin in the process.

Gray matters: A pop quiz

Forget your #2 pencils. Grab your mouse, read the following scenarios, and then rank your exposure on legal grounds from 0 (obviously not a problem) to 10 (inquire about ISDN tariffs at the nearest federal penitentiary). A middle-of-the-road ranking of 5 means you're not sure. No peeking at others' answers until after you've submitted your own.

If at any time you thought, "If this happens to me, the company will stand by me," think again. Most technology companies will terminate you if you are indicted for a computer-related crime, leaving you to fend for yourself during your defense and subsequent legal actions. With that warning, let's look at some of the issues exposed by the sample scenarios above.

Secret Agent Man: Protecting the unknown

The first case, in which design documents for a future product are siphoned through a leaky firewall, raises the question of responsibility for content. To be considered a trade secret, the content in question must have commercial value and must be reasonably protected. You can't claim that a clever observation posted on someone's Web page is a trade secret if it has no value to you and your company, or if your company had taken no precautions against its exposure. If the documents were marked "Proprietary and Confidential," employees were aware of their value to the company, and the company was actively developing the product, then they most probably constituted a trade secret.

Were you guilty of letting them slip through the firewall? The answer depends in part on the level of effort you put into verifying the firewall, ensuring that it provided adequate protection for the data on the other side. While allowing http accesses through the firewall is obviously a less-than-secure configuration, consider variations on this theme: What if you ran NFS through the firewall, and an attacker guessed the root file handle and then walked through the filesystem looking for something of value? What happens if portions of the design documents are mailed to a contractor, in clear text, only to be copied from a network along the way? Almost all of these situations can be resolved using file-oriented encryption tools such as PGP, adding a second layer of protection to the data in addtiion to the environmental protection offered by a firewall. Failure to provide appropriate protection is most likely to send you packing your bags to a new job, rather than a cot and three hots.

Operational data including company performance and future investment or financing activities also requires careful protection. In the second example, you may reasonably guess that your co-worker intercepted mail between your investor relations group and some industry analysts, possibly containing a change in expected earnings. There's a two-part liability question associated with this case: Is your co-worker guilty of illegally monitoring private communications, and are you on the hook for letting the mail go by in the first place? The second part is fairly easy. If you have made it clear to all employees that any mail sent in clear text may be monitored, intercepted or copied onto a backup tape, within or outside of your company, then investor relations shoulders the blame for not using a more appropriate communications channel.

Your Lexus-enabled co-worker is probably guilty of trading on insider information, a charge to be handled by the Securities and Exchange Commission. Proving a violation of the Electronic Communications Privacy Act of 1988 is more challenging, because it covers boss-employee monitoring. Collecting and presenting appropriate evidence is difficult. Even if the messages had been encrypted, the pattern of mail going to an assortment of banks indicates that something newsworthy is happening at your company. Simple traffic analysis may be enough to disclose this information; this is one area better handled via direct phone calls.

Darkness on the edge of town: Propriety on the net

The latest Internet rage swirls around the signing of the Communications Decency Act, a law prohibiting the distribution of "indecent" material to minors, or making such material accessible where minors can access it. The law is new, quite vague, and poses difficult questions about the act of distribution. One thing is fairly clear -- if you maintain a site that is deemed in violation of the law, you (personally) are liable for the offense. Various civil-liberties groups are challenging the law, including the Electronic Frontier Foundation through its Blue Ribbon Campaign. A protest in the form of black or darkened Web pages congealed in the "Thousand Points of Darkness".

Are you guilty of distributing indecent material by giving a minor unintentional access to your news feed, as in the third example? Are you free of liability, because the minor was illegally accessing your host, or have you failed to take proper precautions with your remote access points? The CDA requires that you show intent to distribute, so you're probably safe on legal grounds but in political quicksand in the office. Equipping remote users to use a digital token card, requiring them to have physical possession of the card and its password at login time, would virtually eliminate password guessing attacks leading to unauthorized access and create fewer potential headches for you down the road.

What about the more blatant case of appropriating the title of a published work for your own Web site? Have you done anything wrong by allowing a page named for a Rolling Stones album? For the most part, titles can't be copyrighted -- only the content of a song or book can be protected. Re-using a song title is fair game; what you do on the rest of the Web page is open to interpretation. The exception to the blind use of titles occurs when the title has been turned into a trademark, for example, the Rolling Stones acquire a corporate sponsor for their "Voodoo Lounge" tour, selling the title as a trademark to a corporate sponsor.

Assuming you're free of guilt in the fourth scenario, paint the fifth example like this: Your Stones-focused user lists all of the "devils" he can think of, including executives of competing firms and public officials. Add some inflammatory comments and you have the recipe for a libel or defamation of character suit. The person making the comments is obviously responsible, but what about you, in your role as pseudo-publisher? If your webmaster duties dictate that you review content accessible to the outside world, you can also be charged with libel because you exercise some notion of editorial control. If you manage the site, you are also in effect a publisher of its materials.

Back from the crypt: Safe uses of safe computing

System administrators have an obvious role at the boundary between the public and internal networks, where data and users must be protected from the unseen and unknown attacks. But what are your duties internally, in your capacity as data steward and keeper of the secure bits? Strong cryptography is not like a strong box used for negotiable securities -- there is no physical force strong enough to break it in a reasonable time. If you lose the passphrase used to encrypt a file or to unlock your private PGP key, you are essentially out of luck. Files encrypted with your public key cannot be decrypted, because you will not have access to the private key needed to unwind the encryption. Similarly, a file secured through conventional (secret key) cryptography requires that the key be memorized, permanently, or the data is lost, permanently.

Part and parcel with the deployment of strong cryptographic tools like PGP is user education about the long-term data health hazards posed by their improper use. If your lead architect is encrypting everything from design documents to social e-mails, as in the sixth scenario, life is wonderful until she (a) quits (b) becomes incapacitated and cannot return to work (c) forgets the passphrases she used after a sudden head impact or bizarre gardening accident. It is quite possible for a terminated employee to hold a company hostage with the possession of the right passphrases.

There is a fairly straightforward solution, called key escrow. Various government proposals for key escrow have leant a derogatory image to the concept, but it remains the only safe way of recovering an encrypted file after the person possessing the secret key (or passphrase for it) is injured or dissociated from the company. Simson Garfinkel describes a simple key escrow system in PGP: Pretty Good Privacy (O'Reilly, 1994). The secret key used to encrypt a file is extracted from a key ring, stored in a new key ring with a new passphrase, both the key (on floppy) and the passphrase (on paper) are stuffed into an envelope for safekeeping. In a split key escrow scheme, the passphrase is given to one person while the floppy with the secret key is given to another, and both parties have to be brought together to retrieve the lost key. Use either approach and have your heavy PGP users create escrowed keys to be taken offsite with your full backups or long-term financial records. In the worst case, rent a safety deposit box and toss the floppies inside, being sure that any officer of the corporation can open the box. If all of your corporate officers vanish, your crisis probably extends beyond a few lost cryptographic keys.

What's your actual liability for a lost key? It depends upon how you are viewed as a professional, that is, a person who must adhere to a higher code of standards and ethics in this area than an ordinary person. When a doctor prescribes medication, she also describes the possible side effects and recommends planning to deal with their consequences, if any. If cryptography is the opiate your security-conscious users crave, then you shoulder the professional responsibility of dispensing it safely with proper warning labels and inserts.

Jumping on the cryptography bandwagon exposes you to the final risk example, that of accidentally exporting strong cryptographic code outside the U.S. The ITAR regulations are clear on the issue: Anything using a key length over 40 bits is considered "strong" cryptography. Note that in the latest Notes release, IBM uses a 64-bit key length, but 24 of the bits are escrowed so the unique key length is still an exportable 40 bits. Punishments can include 48 to 51 months in jail.

In our seventh case, you are directly liable for the export of an embargoed item. While the government recently dropped its case against Phil Zimmermann, the author of PGP, this should not be construed as a relaxation of export laws. Strong cryptography will remain a hot topic; vendors of systems that utilize it will not be able to change the status quo by themselves without appearing too self-serving. When US-based corporations can identify lost deals, missed opportunities, and business sent to foreign companies due to the cryptographic code embargo, then the potential to revisit the laws should increase. To learn more about the state of export control, check out the policy section of the EFF's Web site, and read the white paper on security endorsed by the 13 CEOs of major U.S. computer corporations comprising the Computer Systems Policy Project (CSPP).

Closing arguments

What else can you do, short of watching re-runs of "The Paper Chase" and "LA Law" on cable? Here's a quick guide to sounding legal and responsible:

• Outline the scope of your duties, responsibilities, and authority with your management. As we've said in this space many times before, marry responsibility and authority, to be sure you can clean up any mess created by just doing your job.

• Communicate policies and procedures to users on a regular basis. Make sure everyone knows what they can and cannot do. Enforce the policies that affect the public interfaces of your company such as its Web site.

• Become familiar with the type of risks and problems you face in the legal arena. If you have the opportunity to attend one of Dan Appelman's tutorials at a USENIX conference do so, or contact Dan at dan@hewm.com. Dan is with a Bay Area law firm, and his tutorial mixes case studies with practical advice in a way that will make you think you understand legal writings.

• Decide what risks you want to worry about, focus on those, but don't lose sight of changes in technology, policy, or public opinion. Few people worried about cryptography export a few years ago, now Java applets make export violations as trivial as Web surfing.

Your easiest first steps also include rabid reading on the topic. Peter Neumann's Computer Related Risks (Addison-Wesley) is a good starting point, along with Icove, Seger, and VonStorch's Computer Crime book from O'Reilly. Originally written as a training manual for the FBI, the book covers a wide range of topics. If you were wondering what a Section 1029 violation includes (perhaps from reading Jonathan Littman's recently published book on Kevin Mitnick), this is the volume for you.

The rising interest in the legal aspects of system administration mirrors the increase in the number of employers who (correctly) view system administration as a profession, and not as an overhead or janitorial function. Professionalism brings austere responsibility; the more you should know about a problem, the more you are expected to do to prevent it or minimize your exposure to it. It's a steep challenge, but it beats having to don a powdered wig in order to surf clear of the sharks.

Resources

• EFF's Blue Ribbon Campaign
  http://www.eff.org/blueribbon.html
• "Thousand Points of Darkness"
  http://www.vtw.org/speech PGP: Pretty Good Privacy by Simson Garfinkel http://www.ora.com/www/item/pgp.author.html
• policy section of the EFF's Web site
  http://www.eff.org/pub/EFF/Policy/Crypto
• Computer Systems Policy Project white paper on security
  http://www.podesta.com/cspp
• USENIX
  http://www.usenix.org/ Computer Crime by Icove, Seger, and VonStorch http://www.ora.com/www/item/crime.author.html
• A list of Hal Stern's other Sysadmin
  /sunworldonline/common/swol-backissues-columns.html#sysadmin

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1996/swol-03-sysadmin.html
Last modified: