Risk Assessment

Introduction

This chapter describes the basic security risks that you face. We cannot tell you how likely you are to face any of these risks, because your particular situation and your defenses against the risks affect their likelihood. But until you've seen an enumeration of the kinds of risks you face, you can't begin to mount a sensible defense.

The primary objective of information security is controlling access to information. Only properly authorized individuals should be able to review, create, delete, or modify information.

Controlling this access imposes four requirements on the security manager:

1. To keep personal, proprietary, or other sensitive data confidential

2. To maintain the integrity and accuracy of the stored information and the programs that manage it

3. To ensure that the systems, data, and services are nevertheless accessible by those who should have access

4. To ensure that all aspects of operation conform with applicable laws, regulations, licenses, contracts, and established ethical principles

Denying access to some users (requirement 1) while granting easy access to others (requirement 3) requires very careful, clever filtering.

Finding interesting stories to illustrate various risks is easy, but organizing the risks in a meaningful way is more difficult

Risks do not self-organize. Some risks, such as embezzlement, seem to be entitled to a separate category and discussion, even though they are really just instances of another category (embezzlement is a form of theft). Nearly every risk has some consequences, although you cannot always foresee them. For example, the consequences of engaging in piracy are sometimes negligible because few companies meter software; however, in some cases you find yourself embroiled in a lawsuit with the Software Publishers Association, and in other cases you find yourself with a virus in the office.

The other problem with risks is that their preventions are not particularly simple and neatly organizable. For example, few things that prevent piracy have any effect on the likelihood of preventing embezzlement -- although comprehensive audits can detect both. You can do some clever things that reduce several risks. (For example, password systems can reduce or eliminate bumbling, data diddling, embezzlement, and so forth, by unauthorized users, but not by authorized users.)

Furthermore, risks vary in both probability and severity. Chapter _3, which covers risk analysis, can help you sort through probability and severity issues so that you can determine where to begin.

This chapter briefly discusses a number of risks. The risks are in alphabetical order, as in an encyclopedia. Table 1-1 shows which risks threaten each of the major requirements for security.

Table 1-1 Threats to the Four Requirements

A few other risks merit consideration, despite the fact that they do not readily threaten confidentiality, integrity, or accessibility and do not seem to have legal or ethical effects. They include

• Failure to use, which threatens office productivity
• Occupational hazards, which threaten the user's health and safety
• Simulation and modeling (using the computer to plan other illegal activity)

In all the risks described in this chapter, a human is the agent of the wrongdoing, and a computer is the victim or the medium. After all, we do have control over computers (even though it sometimes seems it's the other way around).

Back/Trap Doors

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Very difficult

Frequency: Unknown

Severity: Potentially very high

A back door is another means into a system, often intentionally created by the system designer but sometimes existing by accident. A trap door is a form of back door, and the term normally refers to a testing aid that programmers use during construction, testing, or maintenance of a complex program. By pressing the correct keys at the correct time or providing the correct parameters when the program is run, you can bypass the normal security and error­trapping provided by the program.

Proving that a program does what its specifications claim it should do is indeed difficult. Proving that the program does not do anything else, under any other circumstances (in other words, that it contains no back doors or does not crash if the date is November 10, 2045 and the time is 12:46 pm. and so on), is far more difficult. Such certification requires either imagining and testing against all other specifications or studying the logic of the source code extensively.

The following stories provide examples of a back door that was created by a consultant who wanted to earn some extra money and a back door that was discovered by accident.

Ctrl-J Is Worth $500

The approach of studying the logic worked in one case we are aware of. A dBASE consultant provided a custom program to a client without including a menu option to reindex files. After the consultant delivered the program, the client called frequently with problems. The programmer would come in, run the program, and press Ctrl-J at the main menu, and then the program would perform the reindexing. The consultant would charge for the hour's time that the reindexing took. After the consultant was fired, another consultant who was called in to address the problem found the Ctrl-J option hidden in the code. She simply added it to the main menu so that the client could reindex the files.

Back doors are typically undocumented: You don't know about the back door, but someone else may know about it. Back doors are sometimes discovered by accident, and a complete understanding of the back door may never fully come to light. Consider this ripe story, datelined BLACKSBURG, VA (AP), which appeared in the November 11, 1990, Austin American-Statesman, under the title "911 Calls Are Ripe for Trouble."

Tomato Calls Police

These are hardly salad days for Montgomery County law officials. Last week, police were testing the county's 911 system, scheduled to begin operating next month, when the dispatcher received ten calls that were traced to the home of Linda and Danny Hurst. She tried to call the line, but it was busy. When she hung up, she received another call from the same line. And another.

Deputy sheriffs tracked down Linda Hurst. "I told them I'd locked my house and there shouldn't be anyone in there," she said. Police, concerned that someone had broken in, asked Hurst to meet them at her house. She parked in front of the house and walked up to the front door. "But they said, 'Ma'am, step back please.' I looked back and they had their guns drawn. They were serious," Linda Hurst said. "They went through the house, but they couldn't find anybody, so I went inside."

Finally, Linda Hurst's brother spotted the culprit -- an overripe tomato. The tomato was hanging over the telephone in a wire basket, dripping juice into the couple's answering machine.

Chief Deputy Milton Graham said the tomato juice apparently got into the telephone's dialing system and caused it to dial the sheriff's office. "We're not sure how. Maybe they had speed dialing and it shorted out," he said. "I didn't know the answering machine could even dial out," Linda Hurst said. "It's just supposed to take messages."

This story illustrates how risks from hidden, undocumented features of electronic products, as well as from back doors, can threaten security. The answering machine may have contained the full circuitry of a phone with the dial-out part disconnected. (Using a mass-produced intelligent device and disabling a portion of it can be cheaper than building another device from the ground up.) The inexpensive answering machine used by the Hursts may actually have been the same model as one having remote command capability. What if an intelligent tomato had tried to use the answering machine?

Bumbling

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Sometimes easy; sometimes very difficult

Frequency: Most common risk

Severity: Potentially very high

The most common source of disaster in any computer system are those inept fingers on the keyboard. Some experts estimate that between 50 and 60 percent of the annual dollar loss that computers sustain is the result of bumbling, otherwise known as human errors, accidents, errors of omission, and errors of commission. Very few security measures can prevent or recover from bumbling. Consider the user with access authorization but inadequate training who caused a multiple-head crash on three different 600MB drives. As a result, he wiped out two weeks of work and two generations of backup data. He cost his firm about $100,000.

Coping with bumbling requires minimizing vulnerability, emphasizing training, and providing easy access to competent technical support for all users.

Denial of Use

Threatens: Accessibility

Prevention: Very difficult

Detection: Very easy

Frequency: Unknown, probably rare

Severity: Potentially very high

Denial of use is a fairly new computer crime. It includes trashing a system, tying up ports, placing garbage on the screen, changing filenames, erasing key program files, or using system resources and slowing down the system.

If the information in your system becomes unavailable, for any reason, you have problems. If the information is important, or is time sensitive, you have big problems. Consider this following story, which was reported by staff writer Lynn Duke under the title, "Computer mishap forces shift in election coverage, Major Newspapers faced with delays in polling data," in the Washington Post on November 7, 1990:

Nobody Won

The Washington Post, New York Times, and USA Today had ordered national vote trend analyses from Voter Research and Surveys (VRS), a company set up to do exit poll surveys and have the results analyzed by 3:30 p.m. on Election Day, November 6, 1990. A computer glitch prevented the results from being available at all on that day. VRS had the data, but the weighting program did not work.

Emanations

Threatens: Confidentiality

Prevention: Very difficult; requires TEMPEST-like shielding. TEMPEST refers to the study and control of spurious electronic signals emitted from automatic data processing equipment.

Detection: Impossible

Frequency: Unknown

Severity: Potentially very high

Emanations are electromagnetic signal leaks, a weak spot in computer security. Both cabling and attached devices (computers, printers, modems, monitors, keyboards, connectors, amplifiers, and tap boxes) leak some signals. For someone with a good antenna, a modest leak can become readable data at some distance.

If you are not convinced that such emanations can be a threat, try holding a cheap AM radio, tuned to a low band, near a computer. You'll discover that the radio makes different sounds as the computer undergoes its power­on self test (POST) and other sounds when you give various commands. The radio can pick up signals when you place it near a poorly shielded printer cable, and it also can pick up signals from a monitor. S.A. McConnell reported this incident in Risks Digest, 13.76:

Walkie-Talkie Shuts Down Nuclear Power Plant

The Gazette in Cedar Rapids reported on Friday, Aug. 21, 1992, that "Spurious radio signals may again be the culprit in an automatic shutdown of the Palo nuclear power plant." The shutdown occurred on Monday. The Gazette also reported that "A similar incident occurred in June 1989." They believe a security guard walking by a control panel with his walkie-talkie caused the control panel to trigger a shutdown.

Lucky it didn't tell the system to pull the control rods!

Embezzling

Threatens: Integrity and resources

Prevention: Difficult

Detection: Can be difficult

Frequency: Unknown

Severity: Potentially very high

Embezzlement normally refers to an inside job, a theft of money or resources from an employer by an employee. It is one of the most common computer crimes and one of the oldest of crimes. Data diddling, the process of changing data before it is entered or during data entry, is an easy means of embezzlement. Through this very common, simple, safe technique, employees can increase the size of their paychecks, make deposits to their own bank accounts, ship inventory to their homes, and otherwise hide financial and inventory fraud.

You've all read stories about folks who used the computer to prepare false financial reports. Embezzlers have such a broad range of techniques to choose from that itemizing them is nearly impossible, but here are a few examples.

The Case of the Filed Disk Drives

Normally, disks are filed. Here is the story of some disk drives that were filed. The story is of embezzlement in a small IBM PC systems house that I ran from 1982 to 1984.

Discovering the theft was nearly easy. One day before Christmas, a sales clerk found nofloppy disk drives that had been advertised on the shelf and none in inventory. Purchasing was even more surprised because several dozen drives had been received a few days before. An examination of the sales records revealed that only a few of the drives had been sold.

Determining who had stolen the drives happened to be easy. Over in shipping, the UPS log showed that disk drives were shipped daily to two people whose last name was Dixon, the last name of the shipping clerk. One of these Dixons lived at the same address as the shipping clerk. The weight of each package suggested the number of drives in each shipment. A study of the shipping records revealed that dozens of additional items were shipped to these two people, who had never come into the store and never purchased any items.

The shipping clerk had completed the log; entries were in his handwriting. He also had resigned the week before. He was probably the culprit. Further evidence surfaced that night when a friend of the company told an employee that Mr. Dixon was offering disk drives for sale at the local PC user group meeting for about half of their normal wholesale cost. Catching the thief was harder. The police did not want to get involved in computer crime; it seemed too complicated. So the company sent a new employee to Mr. Dixon's home to buy a disk drive. Employees hoped that the serial number on the drive would match a serial number that was recorded in the log book when the drives were purchased from the supplier. Unfortunately, the serial number had been filed off.

The police finally obtained a search warrant, and they eventually raided Mr. Dixon's home. Even though he had aggressively marketed the stolen goods, some inventory remained in his basement -- inventory that matched the items noted in the shipping log. Mr. Dixon was placed under arrest for theft.

Punishing a thief is less likely than catching a thief, and restitution of damages is less likely than punishment. The company was able to document only $12,000 in stolen merchandise, although the sum may have been much greater. Mr. Dixon was found guilty, but because it was his first offense, he was placed on probation. Although the court ordered him to repay the debt at the rate of $100 per month, he made only two payments.

The simplest auditing scheme would likely have detected the theft, but in this case, it is not likely that it would have detected it any sooner than the salesperson did. And auditing cannot prevent a theft. To detect the theft sooner, daily independent audits of the shipping log may have been desirable. They may even have prevented Dixon from attempting to take the equipment.

The Case of Salami

A salami is normally sliced into many thin slices. A slice or two off a large salami is never noticed.

So it is with the salami technique in computer crime: Someone can shave a few cents from each of many bank accounts and transfer the results to another account. A common application of the salami technique is the round down technique, in which a bank programmer can take the fractions of a cent that are trimmed off after an amount (such as $12.123) is rounded down (to $12.12) and deposit the change in his or her own account. Normally, the bank distributes the shavings to accounts that are rounded up ($12.456 would be rounded to $12.46, and the extra would come from those accounts rounded down).

Such crime took place before banks began to use computers. A thorough examination of program code or careful watch over the bank accounts (comparing deposits and withdrawals) and lifestyles of bank programmers can lead to detection. Auditors often double­check any calculations that involve rounding.

Failure to Use

Threatens: Productivity

Prevention: Difficult

Detection: Can be difficult

Frequency: Unknown

Severity: Potentially high

Failing to use a computer system is hardly considered a computer crime by most people, but as computer systems become more far reaching, an employee's failure to use the computer and provide the expected inputs can significantly slow many projects. Failing to check for electronic mail messages, for example, spoils the entire e­mail system for other users. When even small numbers of users fail to use e­mail, the entire system collapses and must be supplanted by hard copy memos or telephone calls. Statutes requiring the timely use of e-mail are no more likely, however, than laws requiring people to answer the telephone.

Failure to use can be a by-product of a perceived security risk as in the case of "Virus Consumes Clerks at Sears," which follows.

Virus Consumes Clerks at Sears

Kurt Guntheroth writes in Risks Digest, 13.63:

My mother-in-law is a sales clerk at a Sears store in Everett, Washington. I saw 25 new CompuAdd point-of-sale terminals in the back room. They're super techie, with a small CRT, ASCII keyboard, fancy strip printer, and mag card stripe reader. They were supposed to be installed months ago, but apparently they have a dose of the Michelangelo virus.

"Michelangelo? On a terminal? Are you sure?" I asked. Needless to say, the answer was not too specific. She said it might also have been on a PC that configures the terminals, rather than the terminals themselves. Doesn't Michelangelo only strike on one day of the year? All she knew was that they were "full of viruses" and could not be installed.

Sears has its share of troubles these days, and apparently it is running so lean and mean that there is no one in the store with enough computer smarts to get things cleared up in the intervening months. So there they sit, depreciating.

In the past few years, the computer virus scare has resulted in increased attention to security issues, an increase in some budgets, and in some cases, an increase in staffing to deal with viruses and other threats. But given a lack of expert support, users will do whatever they think best to avoid problems with viruses, as the Sears story illustrates. In most offices, the threat of viruses has damaged productivity as much as viruses themselves have.

Fire and Natural Disasters

Threatens: Integrity, accessibility

Prevention: Difficult

Detection: Easy

Frequency: Unknown

Severity: Potentially very high

Fire and natural disasters account for significant financial loss. Even if fire does not directly damage a computer system, the resulting heat, smoke, or water can destroy the system. You can prepare for such catastrophes, but preparation is often incomplete.

For example, after automatic halon and sprinkler systems are installed, are the systems periodically tested? Are employees trained in using hand­held fire extinguishers? And remember, halon is not quite as safe as some people think it is:

• Halon is stored at high pressure, and when it is released, it blows everything all over the place. Many papers and floppy disks are likely to become hopelessly disorganized.
• Although halon may snuff out the fire in a room, the fire may reenter the computer room and cause damage after the halon has been used up.
• Unlike water, halon doesn't help with the main by­product of a fire -_ heat. You may lose as much of your system to the damaging effects of heat with halon as you would to actual flames without halon.

Forgery

Threatens: Integrity and other resources

Prevention: Can be difficult

Detection: Can be difficult

Frequency: Unknown

Severity: Potentially very high

Forgery is the illegal creation of documents or records that are intended to be construed as real, officially produced documents or records. Desktop publishing has made the computer a superb instrument of forgery, as illustrated by the following case reported in Information Security Monitor, June 1990.

A License to Drink and Drive

Student Kelvin Mao probably qualifies for some award in desktop publishing for his work in creating authentic­looking Pennsylvania driver's licenses for use by his fellow students in Virginia. Mao's work was so realistic that local police did not realize that the licenses were false until the names were checked in the computer. The licenses included the hologram that state police use to make the licenses harder to forge. Students who purchased the licenses may have found it easier to dodge traffic tickets, but they especially appreciated the boost the licenses gave to their age, granting them admission to Virginia bars.

The court fined Mao $1,000 and sentenced him to two years in jail, suspending half of the time, after finding him guilty of using desktop publishing systems to forge hundreds of Pennsylvania driver's licenses. Mao's conviction took place in the Montgomery County District Court of Virginia and was on two counts of manufacturing and selling false identification.

Ten students who had the licenses were given a lecture or community service time or were sentenced to a youth offender program.

Fraud

Threatens: Integrity

Prevention: Difficult

Detection: Difficult

Frequency: Unknown

Severity: Potentially very high

Fraud is any exploitation of an information system in an attempt to deceive an organization or take its resources. (You will note from this definition that organizations sometimes have rights that individuals do not. What is it called when the organization attempts to deceive one of its employees? Under what laws is this punished?) Fraud auditors look for implausible entries: those that are too low, too high, too rare, too frequent, or too irregular or made at odd times, by odd persons, or at odd places.

Computers can help detect fraud. After screening out users who are not authorized access, the machine can monitor authorized users against a predefined pattern of expected transaction characteristics: the transaction amount, timing, frequency, volume, and mathematical accuracy; the modification of programs, files, and logs; logging in as Sigmund Fraud; and so forth.

Hardware Failure

Threatens: Confidentiality, integrity, accessibility

Prevention: Cannot be prevented

Detection: Sometimes easy

Frequency: Common; MTBF (mean time between failure) estimates are available

Severity: Potentially very high

Everyone knows that Murphy lives and has been involved in nearly every system design. He works on the factory floor. He helps with packing, shipping, installation, and training.

Hardware failure can compromise confidentiality if it is failure of an access control device or if recovery requires removal of some protection. For example, if your hard disk won't spin up in the morning, what do you do? If you work for a three-letter government agency, you may need to call in the bouncers to disassemble it, torch it, and crush it. (Hardly what we learned about data recovery.) But if you are a mortal, you may call Joe's Computers where you have a service contract. Joe can come out, install a new hard disk, and honor the contract. Then Joe can fix the drive and see what you've got on it.

Hardware failure can compromise integrity. Without your hard disk, you have no information at all. Even something as simple as a failing memory chip can result in unknown errors during a copy process, causing the destination copy to differ from the source.

Hardware failure can compromise accessibility. When you come in Monday morning to find the message General Failure error reading drive C:, you know that you won't be accessing your hard disk until you've done some clever work at the keyboard. Many users know no data recovery tricks and will never see the contents of their hard disks again.

Here are a few stories of hardware failure and its consequences. The first one is from Risks Digest, 14.01.

Tandem Clock Outage

Most all the Tandem computers in the world stopped on the night of November 1, 1992. Unless Tandem owners do some upgrading, they may stop again on January 7, 1993. At 1500 on November 1, all Tandem CLX machines abended, causing the BASE24 Nucleus to dump with a Trap 2 (arithmetic overflow) in the procedure age-timers. A cold reload would get the system going again.

More details appeared in the following story in Computerworld New Zealand, November 9, 1992:

BANK SYSTEM IN CHAOS AS MICROCODE BUG STRIKES

By Randall Jackson

November 1, 3 p.m.: a date and time users of Tandem's CLX systems around the world won't forget in a hurry. That's when a microcode bug struck, sending system timers incoherent and causing chaos in applications such as EFTPOS and automatic telling machines. The bug was discovered first in New Zealand, which is the first country to greet the new day.

"Literally, a bit seemed to fall off the field, and the timers went incoherent and began talking to themselves," says Ken Hennessy, chief manager at Electronic Transfer Services (ETSL), which manages EFTPOS in New Zealand. "They took the date back to December 1983."

Hennessy says Australia was the next affected, then Asia. "I believe Japan was a hell of a mess. We had been in touch with Australia because ETSL operates contracts there, and they started to notice the problem. They contacted Tandem, and the Americans became involved. By midnight, Tandem had worked out a way of getting around the problem."

That was important, because Tandem was able to advise all its users in America and Europe and prevent systems from crashing there.

Hennessy says EFTPOS in Wellington was up and running again by 6:30 p.m. "We turned the clocks back two years to give us a clearance into 1990 at least. Then we had to raise each host and hope it didn't cause problems of irreconcilability. It didn't, because it was day-to-day, month-to-month. Our Auckland node came up at 9:40 p.m., and in the early hours of Monday morning we got back to 1992." Hennessy says that there were two fixes: rolling the clocks forward past 3 p.m. and then shifting them back so 3 p.m. wasn't hit or waiting until 3 p.m. rolled around and doing a cold start.

Tandem New Zealand manager John Simms says it took about four hours to work out an answer to the problem, then communicate it to customers. "There was a microcode defect that caused the internal clock to be read incorrectly. It affected different applications in different ways," he says. "It was a field where at rollover the bug caused the data to be interpreted wrongly. We got our customers to cold load and then reset correctly."

Simms says Tandem acted quickly to provide a fix. "It would happen again in 2001 if we hadn't fixed it," he says.

Impersonation

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Very difficult

Frequency: Unknown

Severity: Potentially very high

Impersonation is the use of someone else's access codes to gain access to the computer to examine data, use programs, or simply use computer time. Employing sophisticated biometric access control devices makes successful impersonation more difficult, but not always impossible.

Many reported breaches of computer systems occur as a result of successful impersonation. A caller must first locate the telephone number (from an underground BBS, an employee, the organization's phone book, or by randomly dialing numbers). From there, the caller must learn the access code (by asking disgruntled employees; by watching another employee log in; or by using the defaults, which are sometimes not changed after installation). Next the caller must learn a valid password (through trial and error, by using common passwords, by talking to an employee, or by searching the area around workstations). Finally in the system, the caller must figure out how the system works (through a study of existing documentation, by using the help functions, or through conversations with others). Usually an outside caller can call an organization's help desk and obtain assistance easily.

Even organizations that strive for high levels of security are at risk, as Jeffrey Smith reported in a December 3, 1988, Washington Post article, "Computer Security Center Had `Break­In'; 1986 Incident Demonstrated System's Vulnerability to Insider Violations, Experts Say."

Uninvited Visitors to Dockmaster

The National Computer Security Center (NCSC), established in the early 1980s by the National Security Agency (NSA) to help protect sensitive data stored in government and commercial databanks, was the victim of an electronic break­in on its Dockmaster network in October 1986.

NCSC created the Dockmaster network in 1985 to serve as a unique BBS and clearinghouse for computer security news and to transmit and receive proprietary corporate data about security systems under a confidentiality promise. The center uses the information to determine the vulnerability of various computer systems to penetration by unauthorized users and then certifies the security systems publicly to assist potential consumers in the government and private industry.

The person who engineered the unpublicized break-in used familiarity with the system and an authorized password to defeat protections against the infiltration of accounts. The break­in, which compromised some unclassified, commercially sensitive data, was discovered six days after the first known misuse of a password. The tap appears to have been a modification of the communications terminal software in a European terminal, which permitted the tapper to listen for passwords, account names, and other identifying information transmitted by numerous users as they contacted the network. The break­in was not discovered by NCSC, but by a user who found that one of his files had been consulted electronically since his last use of it. No prosecution resulted from the incident.

Inaccurate or Dated Information

Threatens: Integrity and legal/ethical

Prevention: Can be very difficult

Detection: Can be very difficult

Frequency: Common

Severity: Potentially very high

Much of the discussion of risks has ignored the issue of the quality of the information that is being protected. But a twist on the problem of protecting good information is that the need exists to fully destroy bad information, which is dated or has become inaccurate.

You're Under Arrest

The problem of bad information is evident from a look at arrest warrant databases. James E. Hanlon reported on this issue in Risks Digest, 13.79:

An attorney acquaintance has a number of clients who have been picked up and detained for various lengths of time, on the basis of warrants later shown to be incorrect. Reasons range from sloppy administrative work (clerical errors, name confusions), to accumulated delays in the record-keeping process.

Police officers in the U.S. need a few things in order to take a person into custody ("arrest" them): Chief among them is probable cause to believe that they have committed a crime. The fact that an arrest warrant exists is in itself probable cause. In practice, one can be taken into custody if the arresting officer believes that a warrant exists -- and someone on the radio telling him that "the computer" shows an outstanding warrant is reason enough.

Problems occur in areas where numerous law enforcement agencies overlap, that is, most urban areas in the U.S. Although there is normally a regional database of warrant information, any agency can keep a database of warrants its own officers have issued. Should a judge order a warrant killed ("quashed" is the legalism), and should the kill order not be properly accomplished, the stage is set: person leaves courtroom relieved, goes about his business, is stopped some months (or years) later, officer checks central database, finds warrant information, calls warrant-issuing police department, which checks its warrant database. Conclusion: you are under arrest. There follows a collection of more or less unpleasant and inconvenient experiences (for example, a weekend in the county lockup).

The problem might be addressed with relational databases, so that deleting a warrant in one agency deleted it in all.

Errors in databases can be significant. Normally, someone other than the database administrator suffers from the consequences, but as the following story illustrates, this need not be the case. (This story appeared in The Lawyers Weekly and was reported in Risks Digest, 13.081.)

Risks Digest, 13.83, included another story on the effects of bad information, as reported by Fernando Pereira.

Everyone's Dead in Hartford

Data entry errors can be the source of significant headaches. The Associated Press reported on September 29, 1992, that for the last three years Hartford, Connecticut residents, have been excluded from the federal grand jury pool. The problem was discovered in a lawsuit disputing the racial composition of the federal grand jury that indicted a minority defendant for bail-jumping. Apparently, the city name for Hartford residents had been typed in the wrong field in computer records, with the effect that the "d" in "Hartford" overflowed into a status field, indicating the named person as deceased.

With so many obvious, low-cost ways available to ensure that data in a database is accurate, you should be upset when significant errors occur. One of the best ways to achieve reasonable accuracy is to have information entered twice, once by each of two low-salaried data entry staff persons. The editor can then use software to compare the files to determine where they differ and make corrections manually using the original information.

Intentional Data or Program Damage

Threatens: Integrity

Prevention: Very difficult

Detection: Can be very difficult

Frequency: Unknown, probably rare

Severity: Potentially very high

Malicious destruction can be untraceable. A disgruntled employee can easily pass a magnet over a box or two of floppy disks, leaving no fingerprints. This section describes a classic case of intentional damage, the case of Donald Burleson.

Wipe 'em Out, Then Sue for Back Pay

Donald Gene Burleson was the computer security director and computer operations manager of USPA & IRA, a Fort Worth­based life insurance agency and securities trading firm. Burleson was, like many people, not happy about paying taxes. But his feelings ran deep, and he had fought unsuccessfully to get USPA & IRA to stop withholding income tax from his pay. On September 18, 1985, when using a USPA & IRA computer to prepare his suit against the company, he accidentally printed out the document he was working on. His supervisor found it, and he was fired.

Three nights later, Burleson returned to work. Using a new password in the system, he first printed 5,000 pages of information describing 168,000 sales commission records for the month, and then he deleted all 168,000 records. That night Burleson also activated several programs he had been working on, which would delete such records, produce new copies of themselves, and hide in the computer under different names. These worms would continue the damage he had done that night.

Investigators very quickly figured out who had deleted the records, caught the worms, and learned how they worked. But the courts took a while to act. What triggered that action was Burleson himself.

Not content with the damage he had caused, he then sued his former employer in a local small claims court for back pay. (Katherine Hafner, Geoff Lewis, Kevin Kelly, Maria Shao, Chuck Hawkins, & Paul Angiolillo reported the story in a Business Week article, "Is Your Computer Secure?," August 1, 1988.) USPA & IRA consented to the judgment against it and then appealed, taking the case to the county court. There it filed a counterclaim, suing Burleson for unauthorized entry into its premises and interfering with the use of the computer system. On July 4, 1986, a jury found Burleson guilty. He was fined $11,226.

Burleson appealed and made only one $100 payment on the fine. In September 1988, a Texas state court convicted Donald Gene Burleson of "harmful access to a computer," sentenced him to seven years of probation, and forced him to pay USPA & IRA, his former employer, $11,800 (the earlier fine of $11,226 plus interest). Considering what Burleson had done, the sentence was rather light. The potential in this trial was for a sentence of up to ten years in jail and a $5,000 fine if convicted (according to an Associated Press article, "Jury Selection in 1st `Virus' Trial Begins," which appeared in the Washington Post, September 7, 1988). In fact, the computer crime law only helped USPA & IRA's case in trying to overturn Burleson's appeal of its win at the county court level. But, as John Burgess reported in "Searching for a Better Computer Shield; Virus Incident Underscores Vulnerability of Companies as Role of Machines Widens," in the Washington Post, November 13, 1988, the civil suit was considered the first prosecution for malicious destruction of computer data.

Back at the ranch, USPA & IRA took some steps to tighten security. They moved to a new building, hired a guard to patrol the computer center during off hours, and warn all users with this sign­on message: The unauthorized use of this computer system or its contents and/or the attempt to gain unauthorized access thereto constitutes a violation of the Texas Penal Code.

Many elements of this case are repeated again and again, with small variations, in other crimes:

• A disgruntled employee committed the crime.
• The employer was unwise in investing so much power (operations and security) in the hands of a single employee, particularly one who was having such fevered disputes with the employer.
• The employee committed the crime under conditions that made his implication certain: He had just been fired and his boss had hard evidence that the employee was angry at the employer.
• The audit trail on the night of the attack was clear enough to implicate the employee.
• The employer was reluctant to prosecute.
• The court case took years, cost hundreds of thousands of dollars to prosecute, and resulted in hardly any punishment for the criminal. Nevertheless, the computer security community pronounced the boondoggle a victory.

Logic Bombs

Threatens: Integrity; can affect accessibility, confidentiality

Prevention: Nearly impossible

Detection: Can be difficult

Frequency: Unknown, probably rare

Severity: Potentially very high

A logic bomb is a modification of a computer program to make it execute in some different way, under some special circumstance. Testing under normal conditions does not reveal such a bomb, but should the special conditions occur, the program performs differently from what is expected.

Logic bombs can be used to embezzle. For example, a programmer might add this code to a payroll program to increase her paycheck a bit (this is pseudocode -_ not necessarily any particular programming language):

IF EMPLOYEE = ME THEN PAYCHECK_AMT = HOURS * RATE * 1.01 ELSE PAYCHECK_AMT = HOURS * RATE

Such subtle alterations to code might go undetected for years. Logic bombs can be used to destroy files, too. For example, a worksheet may contain an autoexecute macro that includes the following pseudocode:

@if(today>>@date(99,4,1),erase a worksheet,do nothing)

Such instructions would pick a worksheet to erase on or after April Fool's Day, 1999, and erase it. The macro would execute every day before then, but do nothing.

Logic bombs also can be created to simply alter some data in random ways that have no benefit to the author but damage the organization. For example, changing one cell in a large spreadsheet can have damaging effects on some forecast or analysis that affects the organization's future.

Programmers also can use logic bombs to ensure that they are paid for their work. A programmer in Waukesha, Wisconsin, wrote software for a client. When the client refused to pay for the software, the programmer pulled the pin. The programmer claims he was merely repossessing his own property -_ the copyright he held. The client makes the usual claims that the programmer's action damaged the business and that the code had bugs. The trial goes forward at this writing.

Writing logic bombs is no more difficult than any other aspect of programming. Detecting them, however, is very difficult. For in­house or custom software, check for logic bombs by using the following methods:

• Review source code. Have an independent programmer review submitted code for the possibility of such a bomb. The programmer should make a note of any code segments that are unclear and get a satisfactory explanation of the segments from the code's author.
• Compile the source code in-house and run the program. Make sure that the program which will be used was compiled from the source code that was reviewed.
• Do a string search and examine all text within the compiled program. This whole procedure is often, but not always, trivial.

Logic bombs are less likely in commercial software, but they are still possible. For example, Lotus 1-2­3 (TM) still has an arithmetic error that produces an incorrect result when a certain pair of numbers is used. You may remember the logic bombs or bugs in the early 8088 and 80486 chips that produced incorrect results when dividing by 0. To ensure against logic bombs and bugs in commercial software

• Audit results
• Perform multiple backups
• Remain forever vigilant

Misrepresentation

Threatens: Confidentiality, legal/ethical

Prevention: May be difficult

Detection: Can be difficult

Frequency: Unknown, probably rare

Severity: Potentially high

Misrepresentation is an odd sort of computer crime. Normally, computer crime involves the computer either as the object of an attack, the subject of an attack, or the instrument of an attack. Misrepresentation is the use of a computer to deceive or intimidate in order to obtain some end. For example, telling participants in a dating service that they will be matched by computer, and then actually using a punched card sorter, may constitute misrepresentation. If an insurance or real estate agent shows clients a stack of printouts, allegedly listing previously satisfied customers, and the printouts are not from that agent's computer, this may constitute misrepresentation. Deception, even when it produces profit, is not necessarily a crime, and misrepresentation is not yet, legislatively, a computer crime.

Misrouting

Threatens: Confidentiality

Prevention: Difficult

Detection: Can be easy

Frequency: Unknown, may be common

Severity: Potentially very high

If you intend to send a message to Bill, and you send the message to Sarah instead, you, Sarah, and Bill may be in for a big surprise. Equally surprising is the frequency with which things are misrouted. The other day, we heard that several friends had received faxed copies of complaints that a New York virus conference organizer had meant to send to his credit card company. Apparently, the complaints were at the bottom of a stack of papers he was faxing to them.

Your Output Is in Israel or Massachusetts

Hank Nussbacher of the Computer Center at Bar-Ilan University in Israel, reported this story in Risks Digest, 10.65:

Over the past few months I have noticed upon occasion files that appear in our system that arrive from a fellow Bitnet system named NCCIBM1. The files always remain in the RSCS print queue since they are destined for the system printer. I always purged them, since there was never any indication that they were intended for any user on our system -- BARILVM (Bar-Ilan University in Israel).

This past week I decided to track down the people at NCCIBM1 and find out why we are getting their job outputs. NCCIBM1 (the U.S. Environmental Protection Agency in North Carolina) determined that their JES system has BARILVM listed as node #178. They also have a remote printer listed as #178. Rather than typing R178 for the output JCL, the user made a mistake and typed N178 -- which sent the output to Israel rather than to some printer in North Carolina."

The problem of having output go to the wrong destination is not limited to Bitnet, matching node and printer numbers, and typing errors. It can occur because you read the documentation. Digital Equipment Corp. sells the LPS40, a Postscript printer you can add to your Ethernet. After you give the printer a DECnet node name, you can send output to it from anywhere on the network. The LPS40 documentation uses examples in which the printer is addressed as node LPS40. If your network happens to have a node named LPS40 (as Digital in Hudson, Massachusetts, has), and you choose to copy the example from the documentation, the output will not go to the LPS40 printer, but to node LPS40, which may be anywhere on the network. According to some accounts, at one time, new LPS40 sites all over the world found themselves printing files in Hudson, Massachusetts. (Following the documentation also results in passwords of password, or IBMPC, or SYSOP, . . . hardly creative. Perhaps I should say, Don't follow the documentation!)

Output isn't the only thing that can be misdirected in a network. How many machines out there are named VAX1? Pennsylvania State University has one (and it is no longer a VAX!). The University of Delaware has one. Digital had one at one time. Today such machines all have their names qualified so that they are unique, but if you happen to have a friendly terminal server that caches recently accessed hosts and also does name completion, then typing TELNET VAX1 may not get you where you expect to be.

Network Analyzers

Threatens: Confidentiality

Prevention: Impossible

Detection: Very difficult or impossible

Frequency: Unknown, but increasingly common

Severity: Potentially very high

Today, dozens of products called LAN Analyzers, Network Analyzers, Protocol Analyzers, and WAN Analyzers are available, some for as little as $400. A combination of hardware and software (in some cases, just software to run in existing workstations), most of these products can read any aspect of traffic on a cable, including any unencrypted text. Although you can defeat the (mis)use of analyzers to capture text by encrypting passwords, e-mail, and files, you cannot detect the analyzers. Any user of a token-ring network can use analyzer software to monitor all traffic. Because the user has not added a component to the network, you cannot detect any change in impedance or any other clue that an analyzer is at work. You'll doubtless be interested in reading the chapter on this topic.

Occupational Hazards

Threatens: User health and safety

Prevention: May be difficult

Detection: May be difficult

Frequency: Unknown, may be common

Severity: Potentially very high

Using workstations, microcomputers, and networks may threaten the health of the user. No, we're not nuts. Such a threat is probably as much the business of the network security manager as is piracy, which merely threatens the financial health of software houses. Two types of occupational hazards have received some attention: radiation risks and repetitive motion/carpal tunnel syndrome.

Radiation risks

According to the December 4, 1992, San Francisco Chronicle, a four-year study by the University of California at Davis reports that women who make computer chips have a 40 percent higher incidence of miscarriages than other workers in the same factories. The study covered 15,000 workers at 14 factories in seven states. A previous study by the University of Massachusetts reported a 70 percent increased risk among women in a particular Digital Equipment factory.

Researchers in Finland have identified a statistically significant incidence of miscarriages (triple the number expected) among women who use computer video display terminals that emit electromagnetic radiation of type ELF. A report on the study is being published in the American Journal of Epidemiology, according to the December 10, 1992, San Francisco Chronicle.

Paul Brodeur has an article on electromagnetic radiation effects in the December 7, 1992, New Yorker.

CBEMA, the Computer and Business Equipment Manufacturers Association, has worked hard to convince us that monitors and machines are safe and to debunk any claims to the contrary. We think this problem really demands greater attention, even if, as some say, the studies that have been done are not definitive.

Repetitive motion/carpal tunnel syndrome

Sitting at a keyboard and typing all day long would seem to be a harmless activity. Few workers fall out of their chairs and break their necks. You never hear of a typist whose tie got caught in the Caps Lock key, strangling him to death. But the mere repetition of a physical motion can cause genuine injury. Tennis players suffer from tennis elbow, which is surely a believable, real injury if you suffer from it. At the keyboard, both David and Sylvia have developed carpal tunnel syndrome, an inflammation of the nerves where they pass through a narrow channel in the bones in the wrist. David's has become so bad that he no longer enjoys driving his car because holding the steering wheel is uncomfortable.

You can take some measures to prevent carpal tunnel syndrome. Maintain good circulation in your arms by taking frequent breaks in which you walk around. If you have to type all day, try to avoid other repetitive activities with the wrist (such as painting the house). At night, sleep with wrist braces that keep the wrists straight and prevent stress on the joints by keeping you from sleeping on your wrist in a funny position.

The computer press does not discuss carpal tunnel syndrome much. Complaints about such problems are considered anticomputer and thus evil. Those of us who love computers want to see no evil in the press, and the press doesn't want to look anticomputer.

Overload

Threatens: Accessibility

Prevention: Very difficult

Detection: Easy

Frequency: Unknown; common in new systems that are heavily used

Severity: Potentially very high

Almost anything will break under enough load. Sure, 20 clowns can fit in a Volkswagen Beetle at the circus, but how many clowns can fit in your car before the springs collapse or a tire blows? Network security is at risk when the system becomes overloaded. For example, when network processing is slow, some programmers attempt to log in from two machines so that they can enter code on one machine while another job (a program compilation, for example) runs on another machine. To support such programmers, a network manager may permit them to log in from any workstation. Then no one can determine whether the programmer is logged in at station X or someone else using X's password is logged in there. A security breach occurs, stemming from a sluggish network.

Things which work under test conditions do not always work under heavy loads. You need to design for heavy loads, or at least design for failure under load. Consider the next story, which was reported in Risks Digest, 13.80, after it appeared in the Dutch national paper, De Volkskrant, September 3, 1992.

Stop the Presses, Call the Police!

On Saturday morning, August 29, the presses at the local newspaper De Gelderlander went down, causing delivery to be delayed. Many subscribers called the newspaper at its phone number, 650611. The telephone exchange at the newspaper got jammed. One of the consequences was, that when people tried to call the newspaper, often only the last four digits, 0611, came through. Now it happens that 0611 is the national emergency number in the Netherlands. So the police department was swamped with calls from people, informing about the delivery of their newspaper, jamming the emergency number. In a reaction, the PTT said that they would be careful with giving numbers ending in 0611 to large companies.

Overloading Compass

Much of our security concerns seem to focus on the attacker who gets into the system. What if the attacker merely tries to get in? In the case of some systems, trouble can result. Back in December 1990, Australia's Compass Airlines reported that the reservation system was being jammed. On one day alone, it received 25,713 calls. The CEO of Compass suspected that a computer was used to dial the reservation system telephone numbers repeatedly, keeping them busy to customers who were trying to book reservations.

An attacker can easily set communication software so that it repeatedly dials a number and hangs up when a connection is made. Preventing such an attack is more difficult. Having a large number of roll-over ports for incoming calls can reduce the effectiveness of an attack from a single computer -- and also make a number of operators wish they had called in sick.

Piggybacking

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Very difficult

Frequency: Probably common

Severity: Potentially very high

Every city dweller has tried piggybacking. You buzz a friend in an upstairs apartment, and while you are waiting for him to release the front door lock, another occupant of the building opens the front door and passes through. In you go, too.

In computer crime, physical piggybacking provides access to an area that is locked. Electronic piggybacking involves gaining access to a system after another user has entered a password, gained access, and then improperly terminated a session. Electronic piggybackers can gain access from a terminal where someone else is logged in or from a second, hidden terminal connected to the same cabling. They also can gain access after the authorized user ends the session but does not log out. You can prevent piggybacking by using turnstiles, traps, TV cameras, and guards.

Piracy

Threatens: Legal/ethical

Prevention: Very difficult

Detection: Can be difficult

Frequency: Extremely common

Severity: Potentially very high

Software piracy is the process of illegally copying software (and documentation) and repackaging it for sale. Even giving software away may be considered piracy.

• Piracy, on a small scale, is common in the United States, where many computer stores and computer rental firms place copies of DOS (without paying a fee to Microsoft) on machines to be sold or rented.
• Piracy claims have been leveled at U.S. and Canadian software rental firms. For a very low fee, the renter has access to the software for a week or two. Although renting software ias advertised as an opportunity to try before you buy, most users know what they want and make copies during the rental period. In this case, both the rental firm and the user making an illegal copy are pirates.

· Pirate BBSs are numerous in the U.S., although they are a small proportion of all BBSs. From such a BBS, a caller can download any amount of commercial software for the price of the phone call.

• Large­scale piracy requires a country with no laws against it. Taiwan and Brazil lead the list of countries where piracy is prevalent. Singapore, Mexico, Argentina, India, and Thailand are also on the list.
• The International Trade Commission (in its publication, Foreign Protection of International Property Rights) estimates that piracy in 1988 cost the software industry $480 million in profits, almost $4 billion in revenue, almost $7 billion in infringing sales, $67 million in enforcement costs, and 1,328 jobs. The Software Publisher's Association fights piracy in the U.S.

Programming Errors

Threatens: Confidentiality, integrity, accessibility

Prevention: Impossible

Detection: Sometimes difficult

Frequency: Common

Severity: Potentially very high

Programmers naturally create errors when they code, and such bugs are created at alarming rates. In buggy code, an error may occur every 50 to 100 lines. A programmer who creates 5,000 lines of code per year can create 50 to 100 bugs a year. The process of removing these bugs -- debugging -- catches some of these problems, but you can never be sure that you have caught all of them.

With so many programmers in the world creating bugs at such alarming rates, attempting to describe all of the bugs would be foolish. This section briefly covers a few of the bugs that may have consequences for you.

Software failure comes in all flavors. One difficulty occurs when software is correctly written for normal situations but contains an error that can be detected only in unusual conditions. Such errors are normally not the result of malice.

Say Wah?

Nick Rothwell reported in Risks Digest, 13.59, that a company in Edinburgh, Scotland, with a Gaelic name has been having trouble with the phone company. When callers ask for the number of the company, its Gaelic name (An Teallach) throws British Telecom's directory inquiry service for a loop, and they cannot find the firm. Operators working with the service listen to the name given by the caller and type in the name as they hear it or a close phonetic approximation. The SOUNDEX system in use works only for British sounds, so funny sounding words, such as the names of Gaelic companies and French restaurants, just don't process correctly.

Don't Call Me in 1997

Any application that does not allow for fifteen-digit international telephone numbers is a potential risk today and will become a real risk on January 1, 1997.

The following information from Stentor Canadian Network Management, the consortium of major Canadian telephone companies, was distributed through the Canadian Department of Communications' Terminal Attachment Program Advisory Committee as TAPAC bulletin 92­13. It was reported by Nigel Allen in Risks Digest, 14.11.

Advance Notice of Change in the Maximum Length of International Telephone Numbers

Beginning midnight December 31, 1996, CCITT Recommendation E.164 will be implemented. This recommendation allows the expansion of international telephone numbers from 12 to 15 digits. Although the North American Numbering Plan will not change, some foreign administrations may assign numbers up to 15 digits long to subscribers. Therefore, terminal equipment originating calls to these subscribers must be able to handle the additional digits.

For more information on this change, Canadians should contact: Marion Norman, Stentor Canadian Network Management, 410 Laurier Ave. West, 8th Floor, P.O. Box 2410, Station D, Ottawa, Ontario Canada K1P 6H5 telephone (613) 560­3420; fax (613) 560­3226. Readers in the United States should contact the North American Numbering Plan Administration at Bellcore.

If you sometimes have trouble counting words or claim forms, consider the sheep you will need to count as you near the end of the century and realize that your accounting package is sorting accounts on a two-digit year. The year 99 will occur far after the year 00. Sorry, sir, but your payment was received 100 years too soon!

You cannot know what errors your software is making today until you are alerted tomorrow. Perhaps you will never know.

Sabotage

Threatens: Integrity, accessibility

Prevention: Very difficult

Detection: Can be easy or very difficult

Frequency: Unknown, probably rare

Severity: Potentially very high

Sabotage comes most commonly from physical damage or logical damage. Physical damage is simple if the perpetrator can get close enough to the computer. Saboteurs have shot, blown up, burned, shorted out, and drowned computers. They've also turned the power off at critical moments during disk operations. Taking precautions to ensure the physical security of the system may help you avoid such physical sabotage.

Examples of logical damage include changing internal or external labels or using software to change the contents of a file.

The CANned Employee

You will recall Murphy's notion that if something can go wrong, it will. Here's a variation on Murphy's law: If something goes wrong, something else may already have gone wrong. Many systems collapse when one component fails. If the failure is not immediately noticed and corrected, failures of other components may occur.

Take the case reported in Risks Digest, 13.062, of the Chevron oil refinery in Richmond, Virginia, that was protected by the Community Alert Network (CAN). CAN is a system for notifying people who live near refineries about emergencies. CAN fired (CAN canned?) a disgruntled employee in New York, but prior to his departure, the employee reconfigured some software components of the system so that it would crash when used. Some time later, a spill occurred, and the refinery attempted to use the emergency warning system to alert residents to stay indoors. The warning system no longer worked.

The morals to be learned from this story are

• When a component of a system fails, its failure may not be immediately evident.
• Disgruntled employees can pose a substantial risk to system security.
• The enemy, today, need not work in your office. Your system's security can be compromised by those at a distance. Thus, local fixes to employee morale and other factors affecting security are not always sufficient to ensure network security.

Disgruntled employees aren't the only ones who threaten computer security, as you see in following story, which was edited by Peter G. Neumann for Risks Digest, 14.15, from articles in The Province of Vancouver, B.C., Canada, and the San Francisco Chronicle, on December 4, 1992.

He Couldn't Smack Her, So He Smacked Her Computer

SAN FRANCISCO. A man sent his ex-wife (who had apparently asked him to retrieve some inaccessible files) a computer diskette that destroyed her entire hard disk, including software and manuscripts, and then displayed a vengeful limerick. James Welsh, a 32-year-old accountant has pleaded not guilty to three counts of "introducing a virus" into the computer. He could face three years in prison if convicted. Welsh's ex-wife, writer Kathleen Shelton, said she had a problem with a computer they formerly owned together. Welsh apparently sent her a computer disk with instructions for correcting the trouble. Police said, "She followed Welsh's instructions, which resulted in the destruction of approximately $8,000 worth of software and manuscripts, leaving only a limerick explaining Welsh's actions against her.

A lying ***** named Kathleen,

Made in the courts quite a scene.

To have her ex, the hacker,

Enjoined not to smack her,

So I wiped her whole hard disk clean.

Detectives searched Welsh's home, seized $4,000 worth of computer hardware and allegedly found evidence of the "virus." Welsh's lawyer, Annette Lombardi, said: "There's not as much damage as charged. It's basically the cost of getting a guy to fix the computer and install new software." [Presumably a different guy this time . . . maybe someone who can write poetry that scans.]

The threat of sabotage can cause nearly as much havoc as sabotage itself. If your office building receives a bomb threat and employees vacate the premises for a few hours, you experience the loss of labor, missed deadlines, a reduction in employee morale, and more. How much more damage can a real bomb cause? The tenants of the World Trade Center in New York City were finding out as we wrote this chapter. When the World Trade Center was hit by a bomb, hundreds of companies had to struggle to salvage files and equipment critical to their operations. Two days after the blast, employees were given 45 minutes to enter the twin towers and retrieve whatever they could. No doubt, backup tapes were at the top of the list. Who knows how many of those companies had disaster prevention plans in place? Our prediction for 1993: the disaster planning and recovery service industry is going to take off.

Scavenging

Threatens: Confidentiality

Prevention: Very difficult

Detection: Very difficult

Frequency: Unknown

Severity: Potentially very high

Scavenging or browsing often involves dumpster diving: going through the dumpster or trash to find listings, tapes, disks, credit card information, carbon paper from multipart forms, and other information of potential use. On the micro, scavenging can include unerasing files from floppies or hard disks with an unerase utility. On a mainframe, scratch tapes are normally not erased by either the prior user or the system operator, and they may contain information of interest to folks involved in industrial espionage. Such theft is of information, rather than of goods or services. Here are a few examples of scavenging.

The Story Is on the Ribbon

For years, typewriters that use a carbon film ribbon have recorded every word typed on the ribbon. Letter quality printers that use daisy wheels or thimbles also may use a one-time film ribbon. All you have to do to find out what was typed on a typewriter is take out the ribbon cartridge, pull out the used ribbon, and read it. The more errors and corrections made during typing, the more garbled the words on the ribbon will be. The risk is at least as old as the IBM Selectric typewriter and is so well known that it has appeared in many cheap detective stories.

Scavenging with ribbons is straightforward on a dot-matrix printer too, if the user supplies new ribbons with adequate frequency. Dot-matrix ribbons rewind endlessly, so a considerable amount of overtyping occurs eventually. But new or recently reinked ribbons have just one character impression per position on the ribbon, and you can read whatever has been printed with the ribbon.

Solution: Take your ribbon with you.

The Story Is at Your Printer

You have a network printer down the hall. You send a report to the printer, go down the hall to get it, and find it isn't there. It must be in the queue. You print another copy and wait a bit. How many copies do you actually collect at the printer? On average, considerably fewer than you send to the printer. What happened to the other copies? Some may have been swallowed by the system. Others may have gone off with other users as they came for their output. Fact is, you've read other output as you stood at the printer waiting for yours. Of course everyone has read your work, too. Some may even have copies of it at home!

If it's worth printing, it may be too valuable to print down the hall.

Simulation and Modeling

Threatens: ?

Prevention: Not possible

Detection: Varies

Frequency: Unknown

Severity: Potentially very high

Simulation is an old standby in the world of crime. You may know the recent story of Miniscribe, which shipped bricks to bogus customers to simulate hard disk shipments to real customers, enabling all sorts of magic with accounting figures. The computer offers great capability to simulate any process and explore the outcome.

Off­the­shelf software is intended for benign purposes and, usually, it is used for benign purposes. But alternative uses are possible. For example, one graphics package enables the user to input rough data, observe the graph that it produces, and then manipulate the graph to change the data. An embezzler can readily use such a tool to make subtle changes in the graphs of expected performance to see how much can be removed without graphic detection.

A copy of an accounting system's software can be used to determine just what entries would need to be made to cover up some loss of funds. And a computer can be used to lay out the steps for a complex crime, where timing is critical. In London, a gang of a dozen thieves and a computer expert used a computer to determine what checks to write on what banks, and which banks to deposit them in, in the largest check-kiting scheme ever attempted.

Superzapping

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Very difficult

Frequency: Unknown

Severity: Potentially very high

SUPERZAP is a utility available on many large systems. It enables an operator to start, stop, or modify a procedure that has been misbehaving. On the micro, the equivalent is something like Norton Utilities™ or PC Tools™.

Superzapping is the unauthorized use of some utility program to modify, destroy, copy, disclose, insert, use, or deny use of computer data. Superzapping is not usually detected by any other software. Superzapping may not be evident from mainframe or mini or LAN logs -- because such logs are potentially edited with a superzapper -- and no evidence appears in a stand­alone micro.

Theft

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult

Detection: Very difficult

Frequency: Unknown

Severity: Potentially very high

(Note that integrity is challenged only if the theft removes the only copy of the information, as can occur with the theft of archive tapes, a server, or a non-backed-up PC.)

Security involves protecting hardware, software, and files from accidental destruction, malicious destruction, and malicious theft. Of the three, accidental destruction is the most likely catastrophe, yet malicious theft is the one most often feared. Outsiders are most often suspected as the enemy, but outsiders pose perhaps only 5 percent of typical risk. Employees do far more accidental and malicious damage.

Information theft can go undetected. An employee can easily copy a file to a disk, place the disk in a briefcase, and take it home.

Theft of equipment

Often the greatest fear is the possibility of stolen equipment. In one case, over a million dollars' worth of micros were stolen from a company's storefront offices during a five­month period. Many of these machines had been secured by locking them to the desks! About 140 of the micros were recovered, all stolen by a gang that had four levels of fencing for the stolen machines.

It is not clear that theft of computers should be considered a computer crime. But theft certainly represents a problem for the computer security specialist, regardless of what you call it.

Theft of information

When computers are stolen, information is stolen too. But there are many ways to steal information without removing the entire computer. Data leakage describes the covert copying of computer information and its removal from an organization. One nearly universal form of leakage is the copying of microcomputer programs purchased by the organization. No employee with a home computer is likely to be able to resist taking the software home -- and many employers ignore or abet the process, on the grounds that practice at home improves the employees' skills. But copying software owned or licensed by an employer is a form of piracy -- something everyone should avoid.

Getting information out of a secure site does not appear to be difficult if the employee can acquire it within the site. Any employee of nearly any organization can obtain data and exit with it. Even when security guards check and record everything, an employee can easily bring in a floppy disk or magnetic tape that is clearly and innocuously labeled, copy files to it, and exit at night. Carrying hard copy printouts out of the building is equally simple if the printouts have been inserted in a binder with one or two different cover pages.

Using micros for decision support exacerbates the problem of theft: Many decision makers may have data in their spreadsheets that is more valuable or confidential than the data that resides on the mainframe. Risks Digest, 13.066, reported on a Los Angeles Daily News item that appeared in the San Francisco Chronicle, July 17, 1992, which illustrates this point.

Residual Gulf War Battle Plans Provide Evidence of Stolen Computers

About $70,000 worth of computers used in the Persian Gulf operations turned up for sale in Ventura County, CA. An unidentified computer hobbyist reported observing "Welcome to Saudi Arabia" on the screen of one computer, along with a map and locations of unit deployments. He reported it to the Crime Stoppers hotline. Subsequent Army investigation has now led to the conviction of a serviceman for multiple counts of larceny and wrongful disposition of government property. [There was some residual military information in some of the computers, although no indication was given as to whether any of it was sensitive.]

Theft of service

Theft of service can range from playing Missile Command on a company computer to running a bookmaking operation on it. Innocuous theft of service is an everyday event; more extended theft of service, such as a bookmaking operation, is less common. Dave Powell gives an example of theft of service in "Network Abuse: Who's The Enemy?," which was published in the September 1990 issue of Networking Management.

The Entrepreneurial Spirit

The systems manager for a radio-based carrier reported that an employee illegally resold the firm's services in private transactions. "At first, we thought he was getting into our computer, but the audit trails showed no indication of break-ins," the manager explained. "We think that he was using account information that was, somehow, walking out the door." Outsiders who bought account data could then call customer service representatives, provide accurate account IDs, claim that they lost their passwords, get new ones, and use the company's services."

Trojan Horses

Threatens: Confidentiality, integrity, accessibility

Prevention: Very difficult or impossible

Detection: Can be very difficult

Frequency: Unknown

Severity: Potentially very high

A Trojan horse is any program that presents itself as performing one task while actually performing another. The Trojan horse can do anything that any software can do, including modifying databases, writing paychecks, sending electronic mail, or destroying files. In the microcomputer world, the Trojan horse is usually downloaded from a BBS. When it is run, it may destroy file allocation tables (FATs) and directories, effectively erasing files on the hard disk.

A clever Trojan need not do anything but write instructions that carry out the work. If someone finds these instructions and removes them, the Trojan can write them again when it is next run. Removing a well­written Trojan can amount to major detective work.

A delayed attack from a Trojan horse is uncommon with microcomputers. Most Trojans in the micro world detonate the moment they are run, usually destroying the Trojan itself. But the Trojan's code can include instructions that cause delayed effects. In fact, a number of computer viruses that are descendants of Trojans perform their work undetected at some point after the program that carried them has been run. For a more extensive discussion of Trojans, see Norman's Computer Virus Handbook.

Version Control

Threatens: Integrity

Prevention: Difficult

Detection: Difficult

Frequency: Common

Severity: Potentially very high

Can we talk about something unpleasant for a minute? How do you keep track of the version of something? In nearly every operating system, you can use a given filename only once in each directory. Yet you can use an infinite number of directories. So although you can have only one version of this thing here by this name, you also can have it here under another name or somewhere else under this name.

Don't tell us that you use BOS -- the Bafflegas Operating System that permits 2,000-character filenames. Even that system doesn't automatically keep track of which version is which. And the fact is that without something automatic to keep track of versions, anyone can use the wrong version of the software or edit the wrong version of the file.

You cannot always solve the problem of multiple versions by automatically deleting the old version whenever you create or install a new version. In the case of software, you are well advised not to remove the old version until you are sure that the new version is as good, can read your old files, doesn't have any gross bugs, and so forth. Programmers shouldn't want to have only one version of their code. If they find a bug in it, they may want to look at a previous version for reference or even to revert to an old version and start over. Writers may have a generic document that they want to revise one way for one publication and another way for another publication. Which version is the version? All are legitimate.

To solve this problem, consider version control software. One to investigate is Reference Point by Global Integrated Systems (800-374-9929). Or spend some time writing batch files that use the DIR /S command, which searches for files in subdirectories. Another utility to investigate is Whereis, a shareware program that searches for files at a blazing rate. Available from Computer Tyme (417-866-1222)

The Downdated Software

Everyone likes to keep up with the times. To have whatever is new and improved. If you live in Kansas, you can revel in the Rodgers and Hammerstein lyric, "Everything's up to date in Kansas City." Well, once upon a time, Carnegie-Mellon University (CMU) developed the Andrew system, which provided a variety of network file services. CMU used the system and then began distributing it to other universities. One university got the source code and began to do some modifications of its own. But the changes wouldn't last. Every morning when the programmers came in, they found that the system had mysteriously returned to its original condition.

Was this further proof of a corollary of the law of gravity: Whatever is updated must be downdated? Not quite. Within the mass of source code that the programmers had acquired from CMU were routines that checked the local files to ensure that they were the same as the files on a reference machine -- which happened to be at a site at CMU. Inserting hard code to keep the software as current as the reference files only works when the reference files are the ones that are updated!

The idea of self-updating software is actually a good one, if it is properly implemented. It can remove the work of vandals or viruses each night and keep all systems synchronized. But it should probably notify the manager that it is out of sync and ask permission before updating itself. It could report file dates of the two versions to assist the manager in making the decision. And it could offer the ability to turn off the self-updating feature whenever management decided to let the local version break away from the original reference version.

Viruses

Threatens: Integrity, accessibility

Prevention: Can be difficult

Detection: Usually straightforward

Frequency: 1 in 30 US machines will be infected in 1997.

Severity: Potentially very high, usually low

In the early years of viruses, only a few viruses sought out specific targets. (The Anticad virus, for example, tries to destroy ACAD.EXE, the name of the main AutoCAD program.) Today, with the exploration of the use of computer viruses for military purposes by the U.S. Army, the U.S. Air Force, NSA, and other agencies, and with the expected arrival of Mark Ludwig's third book (on military applications of computer viruses), you may wonder whether more targeted viruses will appear in the future.

The virus is a potential small nation's weapon. Viruses could become terrorist surrogates, disrupting an enemy nation without leaving direct fingerprints traceable back to the ultimate sponsor. And even if a virus is not targeted at specific users, any virus developed in the Third World may accomplish its general purpose of lowering the efficiency of the First and Second worlds. They are more computerized than the Third World and thus more vulnerable.

Several chapters of this book are devoted to the virus problem.

Wiretapping

Threatens: Confidentiality

Prevention: Easy with encryption; impossible otherwise

Detection: Difficult or impossible

Frequency: Unknown

Severity: Potentially very high

Wiretapping has gone beyond alligator clips to include microwave and satellite interception with dishes available at the local Radio Shack. Although wiretapping rarely surfaces in the news, it probably goes on undetected. Often tapping into one end of a wire is easier than climbing a pole and tapping the middle.

Passive tapping with induction can be done with a small cassette tape recorder, a microphone, an AM/FM portable radio, a modem, and a printer. The cassette recorder picks up the signal and amplifies it, the modem converts the telephone sounds to digital pulses, and the printer makes a hard copy of the signal. Data transmissions are, obviously, easier to understand from the hard copy than from a voice transmission.

Summary

• Access control requires that data be kept confidential, accurate, accessible to those who are authorized, and within applicable laws.
• The basic risks that threaten our systems every day have a wide range -- from those as simple as typographical errors to more sophisticated acts of sabotage, such as logic bombs or real bombs.
• The most difficult task of the security manager is to reduce the threat of these risks and simultaneously maintain a user-friendly atmosphere.

This chapter covers the first step of this task -- understanding the scope of the risks. If this chapter uncovered some risks that you didn't know about, the next chapter will encourage you to change your attitudes about risks and how your new outlook will help you deal with risks.