Simtel MSDOS 1992 June

home *** CD-ROM | disk | FTP | other *** search

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / trojanpr / ibmpaper.arc / IBMPAPER.TXT

Wrap

Internet Message Format | 1989-06-09 | 84.3 KB

Date: Mon, 27 Mar 89 15:56:48 EST From: CHESS@IBM.COM Coping with Computer Viruses and Related Problems Steve R. White David M. Chess IBM Thomas J. Watson Research Center Yorktown Heights, NY Chengi Jimmy Kuo IBM Los Angeles Scientific Center Los Angeles, CA Research Report (RC 14405) January 30, 1989 This research report is provided without restriction; we encourage its redistribution. Copies may be requested from: IBM Thomas J. Watson Research Center Distribution Services F-11 Stormytown Post Office Box 218 Yorktown Heights, New York 10598 (This report will be available from this address up to one year after the IBM publication date (up to Jan 1990)) This online version differs from the hardcopy report only in pagination, and in using *asterisks* for emphasis. It is formatted to print at 66 lines per page, and 80 or so characters per line (including a 10 character margin on either side). Coping with Computer Viruses and Related Problems Steve R. White David M. Chess IBM Thomas J. Watson Research Center Yorktown Heights, NY Chengi Jimmy Kuo IBM Los Angeles Scientific Center Los Angeles, CA Research Report Number RC 14405 January 30, 1989 ABSTRACT We discuss computer viruses and related problems. Our intent is to help both executive and technical managers understand the problems that viruses pose, and to suggest practical steps they can take to help protect their computing systems. Abstract ii CONTENTS 1.0 Executive Summary . . . . . . . . . . . . . . . . . 1 1.1 What Is a Computer Virus? . . . . . . . . . . . . . 1 1.2 How Can Computer Viruses Affect an Organization? . . 2 1.3 How Serious Is The Problem? . . . . . . . . . . . . 2 1.4 Summary and Recommendations . . . . . . . . . . . . 3 2.0 Coping with Computer Viruses: A Guide for Technical Management . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 How Viruses Infect Computing Systems . . . . . . . . 5 2.2 How Viruses Differ From Other Security Threats . . . 6 2.3 General Security Policies . . . . . . . . . . . . . 7 2.3.1 User Education . . . . . . . . . . . . . . . . . 7 2.3.2 Backups . . . . . . . . . . . . . . . . . . . . 7 2.4 Decreasing the Risk of Viral Infection . . . . . . . 8 2.4.1 Isolated Systems . . . . . . . . . . . . . . . . 8 2.4.2 Limited-Function Systems . . . . . . . . . . . . 9 2.4.3 Policies for Software Repositories . . . . . . 10 2.4.4 Policies for Production Systems . . . . . . . 11 2.5 Detecting Viral Infections . . . . . . . . . . . . 12 2.5.1 Watching for Unexpected Things Happening . . . 13 2.5.2 Some Symptoms of Known Viruses . . . . . . . . 13 2.5.3 Watching for Changes to Executable Objects . . 15 2.5.4 Using External Information Sources . . . . . . 17 2.6 Containing Viral Infections . . . . . . . . . . . 17 2.6.1 The Importance of Early Detection . . . . . . 17 2.6.2 The Importance of Rapid Action . . . . . . . . 18 2.7 Recovering from Viral Infections . . . . . . . . . 19 2.7.1 Restoration and Backups . . . . . . . . . . . 19 2.7.2 Virus-Removing Programs . . . . . . . . . . . 20 2.7.3 Watching for Re-Infection . . . . . . . . . . 20 2.8 Summary and Recommendations . . . . . . . . . . . 21 For Further Reading . . . . . . . . . . . . . . . . . . 23 Glossary . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix: Viral Infections in PC-DOS . . . . . . . . . 27 Contents iii PREFACE While this document has been widely reviewed, and many helpful suggestions have been incorporated, the authors are entirely responsible for its present content. It does not represent the opinions, policies, or recommendations of IBM or any other organization. Preface iv 1.0 EXECUTIVE SUMMARY Computer viruses present a relatively new kind of security problem in computing systems. The purpose of this section is to acquaint the senior management of an organization with the nature of the problem. It also outlines some of the steps that can be taken to reduce the organization's risk from computer viruses and other, similar, problems. Traditional computer security measures are helpful, but new measures are needed to deal with the problems effectively. The computer security management of the organization will play a key role in reducing the risk. But education and ongoing participation of the users are also vital. 1.1 WHAT IS A COMPUTER VIRUS? A computer virus is one kind of threat to the security and integrity of computer systems. Like other threats, a computer virus can cause the loss or alteration of programs or data, and can compromise their confidentiality. Unlike many other threats, a computer virus can spread from program to program, and from system to system, without direct human intervention. The essential component of a virus is a set of instructions which, when executed, spreads itself to other, previously unaffected, programs or files. A typical computer virus performs two functions. First, it copies itself into previously-uninfected programs or files. Second, (perhaps after a specific number of executions, or on a specific date) it executes whatever other instructions the virus author included in it. Depending on the motives of the virus author, these instructions can do anything at all, including displaying a message, erasing files or subtly altering stored data. In some cases, a virus may contain no intentionally harmful or disruptive instructions at all. Instead, it may cause damage by replicating itself and taking up scarce resources, such as disk space, CPU time, or network connections. There are several problems similar to computer viruses. They too have colorful names: worms, bacteria, rabbits, and so on. Definitions of them are given in the glossary. Each shares the property of replicating itself within the computing system. This is the property on which we will focus, using viruses as an example. There are also a variety of security issues other than viruses. Here, we Executive Summary 1 will deal only with viruses and related problems, since new measures are required to deal with them effectively. 1.2 HOW CAN COMPUTER VIRUSES AFFECT AN ORGANIZATION? Let us examine a particular sequence of events, by which a virus could enter an organization and spread within it. Suppose that the organization hires an outside person to come in and perform some work. Part of that person's work involves working on one of the organization's personal computers. The person brings in a few programs to aid in this work, such as a favorite text editor. Without the person having realized it, the text editor may be infected with a virus. Using that editor on one of the organization's machines causes the virus to spread from the editor to one of the programs stored on the organization's machine, perhaps to a spreadsheet program. The virus has now entered the organization. Even when the outside person leaves, the virus remains on the machine that it infected, in the spreadsheet program. When an employee uses that spreadsheet subsequently, the virus can spread to another program, perhaps to a directory listing program that the employee keeps on the same floppy disk as the spreadsheet data files. The listing program is then infected, and the infection can be spread to other computers to which this floppy disk is taken. If the employee's personal computer is connected to the organization's network, the employee may send the listing program to another user over the network. In either case, the virus can spread to more users, and more machines, via floppy disks or networks. Each copy of the virus can make multiple copies of itself, and can infect any program to which it has access. As a result, the virus may be able to spread throughout the organization in a relatively short time. Each of the infected programs in each of the infected machines can execute whatever other instructions the virus author intended. If these instructions are harmful or disruptive, the pervasiveness of the virus may cause the harm to be widespread. 1.3 HOW SERIOUS IS THE PROBLEM? Traditional security measures have attempted to limit the number of security incidents to an acceptable level. A Executive Summary 2 single incident of lost files in a year may be an acceptable loss, for instance. While this is important, it only addresses part of the problem of viruses. Since a single virus may be able to spread throughout an organization, the damage that it could cause may be much greater than what could be caused by any individual computer user. Limiting the number of initial viral infections of an organization is important, but it is often not feasible to prevent them entirely. As a result, it is important to be able to deal with them when they occur. Most actual viruses discovered to date have either been relatively benign, or spread rather slowly. The actual damage that they have caused has been limited accordingly. In some cases, though, thousands of machines have been affected. Viruses can easily be created which are much less benign. Their *potential* damage is indeed large. Organizations should evaluate their vulnerability to this new threat, and take actions to limit their risks. 1.4 SUMMARY AND RECOMMENDATIONS o A computer virus is a program that can infect other programs by modifying them to include a copy of itself. When the infected programs are executed, the virus spreads itself to still other programs. o Viruses can spread rapidly in a network or computing system and can cause widespread damage. o Unlike many other security threats, viruses can enter a given computing system without anyone intending them to. o There are no known ways to make a general computing system completely immune from viral attacks, but there are steps you can take to decrease the risks: - Use good general security practices. (For a more complete discussion of these points, and some examples of others, see reference (6).) -- Keep good backups of critical data and programs. -- Periodically review overall controls to determine weaknesses. -- Use access control facilities to limit access to information by users, consistent with their job duties and management policies. Audit accesses that do occur. Executive Summary 3 -- Do not use network connections to outside organizations without a mutual review of security practices. -- Consider limiting electronic mail communications to non-executable files. Separate communications that must move executable files from electronic mail, so that they can be separately controlled. -- Make security education a prerequisite to any computer use. - Put a knowledgeable group in place to deal with virus incidents. -- The group may be a formal part of the organization, or may be an informal collection of knowledgeable people. -- The group should be responsible for educating users about the threat of viruses, providing accurate information about viruses, responding to reports of viruses, and dealing with viral infections when they occur. -- Make sure each employee who works with a computer knows how to contact this group if they suspect a viral infection. - Develop a plan to deal with viruses *before* there is a problem. -- Decrease the risks of an initial infection, from internal and external sources. -- Put mechanisms in place to detect viral infections quickly. -- Develop procedures to contain an infection once one is detected. -- Know how to recover from a viral infection. - Test the plan periodically, as you would test a fire evacuation plan. -- But *do not* use a real virus to test the plan! Executive Summary 4 2.0 COPING WITH COMPUTER VIRUSES: A GUIDE FOR TECHNICAL MANAGEMENT Once an organization makes a commitment to deal with the problems of computer viruses, there are specific areas which should receive attention. The purpose of this section is to acquaint technical management with the problems and to indicate the actions that can be taken to limit the risks posed by viruses. 2.1 HOW VIRUSES INFECT COMPUTING SYSTEMS There are many ways in which a system can become infected with a virus. Any time a program is run which can alter one or more other programs, there is the possibility of viral infection. Any time a user executes a program which is written by anyone else, compiled by a compiler, or linked with run time libraries, all the resources to which that program has access are in the hands of every person who contributed to that program, that compiler, or those libraries. The initial introduction of an infected program can occur through a large variety of channels, including: o Software introduced into or used on the system by an outsider who had access to the system, o Software used at home by an employee whose home computer system is, unknown to the employee, itself infected, o Software purchased from a commercial software company whose production facilities are infected, o Software that turns out to be infected that has been down-loaded from public bulletin boards for business use, or by employees, o Software intentionally infected by a malicious or disgruntled employee, o *Any* other time that a piece of software (including programs, operating systems, and so on) is created within the organization, or brought in from *any* outside source. See the appendix for an example of sources and locations of possible infection for one operating system. Coping with Computer Viruses: A Guide for Technical Management 5 2.2 HOW VIRUSES DIFFER FROM OTHER SECURITY THREATS There are many kinds of threats to security. Threats traceable to dial-in systems are greatly reduced with the use of call-back systems. Simple threats created by disgruntled employees can often be traced to the person responsible. One important thing that makes the virus different from all the rest is its untraceability. Except in rare cases, the only way a virus' author becomes known is if the author admits to ownership. As a result, an author can create a virus with reasonable certainty that he will not be discovered. This allows great latitude in the design of the destructive portion of the virus. The only perfect ways to protect against viral infection are isolation and reduced functionality. A computer system cannot be infected if it runs only one fixed program, and cannot have new programs either loaded or created on it. But this is clearly not very useful in many circumstances. So there is almost always some exposure. As with other security concerns, it is a matter of weighing benefits, practicality, and potential risks, and then taking cost-effective action to help control those risks. Viruses exhibit elements of many other security threats. (See the Glossary for a summary of some of these threats.) There are important differences, though. Dr. Fred Cohen, who has done much of the original research on computer viruses, defines a virus as: a program that can "infect" other programs by modifying them to include a possibly evolved copy of itself. (See reference (1).) But a virus is more than the part that replicates itself. There is usually also a potentially damaging portion. This portion could be a "time bomb" (on November 11th, display a political message), a "logic bomb" (when it sees a certain write to disk, it also corrupts the file structure), or anything else the virus author can design. The variety of possible effects is part of the reason why the notion of a virus is so confusing to many people. The term "virus" is sometimes misused to refer to anything undesirable that can happen to a computer. This is incorrect. The thing that makes viruses and related threats different from other problems is that they spread. Coping with Computer Viruses: A Guide for Technical Management 6 2.3 GENERAL SECURITY POLICIES 2.3.1 User Education Good security policies depend on the knowledge and cooperation of the users. This is just as true of security against viruses as it is of policies about password management. Users should be aware of the dangers that exist, should know what to do if they suspect they have found a security problem. In particular, they should know whom to call if they have questions or suspicions, and should know what to do, and what not to do, to minimize security risks. Users should be encouraged to feel that security measures are things that they want to do for their own benefit, rather than things that are required for no rational reason. A strategy to detect and contain viruses is described below. An important part of that strategy is for users to know whom to call if they see a system problem that may be the result of a virus. Someone should always be available to work with the user in determining if a problem exists, and to report the problem to a central source of information if it is serious. This central source must have the ability to inform the necessary people of the problem quickly and reliably, and to set in motion the process of containing and solving the problem. More detailed suggestions for this mechanism will be given below, but each stage depends on education. It is important to educate the end users, the first-level support people, and management involved at all levels, since they must take the necessary actions quickly when a viral infection is detected. 2.3.2 Backups Even without the threat of viruses, good backups are an important part of system management. When a program or a data file is lost, a good set of backups can save many days or months of work. The potential harm caused by computer viruses only increases the need for backups. Although they are necessary for recovery, backups can also present a place for a virus to hide. When a virus attack has been stopped, and the virus removed from all software on the system, the obvious way to recover altered or lost files is by restoring them from backups. Great care must be taken not to reintroduce the virus into the system in the process! Coping with Computer Viruses: A Guide for Technical Management 7 All backups should be inspected to ensure that the virus is not present in any file on any backup. Until a backup has been certified "clean," it should not be used, unless certain files on it are not recoverable through other means. Even in this case, it is necessary to be very careful to restore only objects which the virus did not infect or otherwise change. The behavior of the virus should be well understood before any restoration from backup is attempted. 2.4 DECREASING THE RISK OF VIRAL INFECTION Viruses can spread from one user to another on a single system, and from one system to another. A virus can enter a company either by being written within the company, or by being brought in from the outside. Although a virus cannot be written accidentally, a virus may be brought in from the outside either intentionally or unintentionally. Viruses can enter a company because a program is brought in from outside which is infected, even though the person who brings it in does not know it. Because sharing of programs between people is so commonplace, it is difficult to prevent an initial infection from "outside." An employee may take a program home to use it for business purposes on his or her home computer, where it becomes infected. When the program is returned to the workplace, the infection can spread to the workplace. Similarly, an outside person can bring a set of programs into a company in order to perform work desired by the company. If these programs are infected, and they are executed on the company's systems, these systems may also become infected. There are two major ways to prevent infection in the first place, and to limit the spread of an existing infection: isolating systems, and limiting their function. 2.4.1 Isolated Systems Since viruses spread to new users and systems only when information is shared or communicated, you can prevent viruses from spreading by isolating users and systems. Systems that are connected to other systems by a network can spread a virus across that network. Isolating systems from the network will prevent their being infected by that network. If a company maintains connections with other companies (or universities, or other institutions) by a Coping with Computer Viruses: A Guide for Technical Management 8 network, a virus may be able to enter the company through that network. By isolating the company from such external networks, it cannot be infected by these networks. This is a reasonable policy to follow when possible, especially for those systems which contain especially sensitive programs and data. It is impractical in many cases, though. Networks are valuable components of a computing system. The easy sharing of programs and data that they make possible can add substantially to the productivity of a company. You should be aware, however, that this sharing also increases the risk of viral infection to these systems. This is especially true if the network security measures have not been designed with viruses and related threats in mind. Your organization may wish to limit the kinds of access to systems afforded to those outside the organization. In many cases, users of external systems may be less motivated to be benevolent to your systems than internal users are. This may make it worthwhile to limit the ability of external users to transmit executable files, or have full interactive access, to internal systems. Similarly, movement of programs between personal computers on floppy disks can result in one system infecting another. If an employee's home computer is infected, for instance, bringing a program (or even a bootable disk) from home to work could result in the work computer becoming infected. You may want to have a policy that employees should not bring programs or bootable disks between work and home. Or, you may want to have a policy that employees should use virus-detection tools on their home computers as well as their work computers. 2.4.2 Limited-Function Systems Since viruses must be able to infect other executable objects in order to spread, you can help prevent viruses from spreading by eliminating this ability from a computing system. This can be done in some circumstances by restricting the ability to add or change programs on a system. If general-purpose programming must be done on a system, as is the case with development systems, it is not possible to prevent users from creating or adding new programs. On these systems, it is not possible to prevent the introduction of viruses under every possible condition. Coping with Computer Viruses: A Guide for Technical Management 9 Many companies have computing systems, including workstations and personal computers, that are not used for general-purpose programming. A bank, for instance, may use personal computers as teller stations, to handle a fixed set of teller transactions. Since the tellers need not program these systems, it may be possible to strictly limit the introduction of new programs and thus greatly limit the introduction of viruses onto them. This is a prudent policy. Whenever practical, limit the ability of users to add or change programs on the systems they use. This ability should be restricted to authorized personnel, and these personnel should use every means available to them to check any new programs for viruses before they are installed in the limited-function systems. As long as no new programs are introduced, no new viruses can be introduced onto these systems. Remember, though, that the trend in personal workstations has been toward the empowerment of the individual user, including giving the user the ability to create programs to suit his or her own needs. Thus, it may not be practical and competitive in the long run to impose restrictions on many systems. The risk of viral infection must be weighed against the benefits of providing power and flexibility to the individual user. 2.4.3 Policies for Software Repositories Software repositories are places in which programs reside which may be used by a number of people. These may be disks on a mainframe, which can be accessed from a number of different users' accounts. They may also be disks on a local area network file server, from which many users get common programs. These repositories can pose more of a risk in the spread of viruses than most "private" program storage locations. If a commonly-accessed program becomes infected, such as a text editor used by an entire department, the entire department can become infected very quickly. So, extra care is required to prevent infection of repositories. A policy can be put into place that requires each program added to a repository to be checked thoroughly for possible infection. It is helpful, for instance, to use tools to ensure that it is not infected with any of the already-known viruses. Coping with Computer Viruses: A Guide for Technical Management 10 In cases in which users who access the repository deal with especially sensitive programs and data, it may be prudent to enforce even more stringent policies. Programs to be added may be tested first on isolated systems, to see if they show any signs of infecting other programs. Or, a repository team may inspect the source code of the program for viral code. If no viral code is found, the repository team can compile the program on an isolated system that has been certified to be free of viruses. In such a case, the only object code allowed on the repository would come directly from the team's compilation on its isolated system. Repositories can also be helpful in detecting and controlling viruses. Consider the situation in which most users run a significant amount of the software that they execute from a central server to which they do not have write access, rather than from individual writeable disks. Since the users do not regularly update this software, viruses will not be able to spread as quickly between these users. If a program on a central repository becomes infected, it may be comparatively simple to replace it with an uninfected version (or remove it entirely). It may be more difficult to screen all programs on hundreds of individual systems. It may also be easier to audit the usage of, and updates to, a single software repository, as opposed to a large number of individual systems. There are a variety of other areas in many organizations which could spread viruses rapidly, and hence which should be carefully controlled. Internal software distribution centers, for instance, could spread a virus widely if they were infected. Similarly, a software lending library, if infected, may transmit a virus to many other users before it is detected. Walk-in demo rooms and educational centers are also potential problems. In general, any place from which software is widely distributed, and which has uncontrolled software importation, needs special attention. 2.4.4 Policies for Production Systems Production systems are those systems which are used to prepare internally-developed programs for distribution either within a company, or for sale to external customers. If these systems were infected with a virus, the virus could spread to programs used widely within the company, or to programs used by the company's customers. In the former case, this could spread the virus widely throughout the company. In the latter case, it could damage the reputation of the company with its customers. There has been Coping with Computer Viruses: A Guide for Technical Management 11 documented cases of companies accidentally shipping virus-infected program products to customers. Since the infection of production systems could have serious consequences, you should be especially careful about protecting them. The key to this is the institution of stringent change control policies on production systems. They should be strongly isolated from non-production systems, so that only known, authorized files can be put onto the system. Each file should be checked for infection, to whatever extent possible. Installing object code on these systems should be avoided whenever possible. Rather, source code should be installed, and compiled locally with a trusted compiler. Where the impact of a viral infection would be particularly large, it may be important to inspect the source code before it is compiled, to avoid the introduction of a virus through the source code. If object code must be installed, its origin should be verified beforehand. For instance, object code for a personal computer could be installed only from an original, write-protected distribution disk, which has been found to be free of viruses. In addition, virus-checking programs (see below) should be run frequently on production systems. On a multitasking system, it may be possible to run a virus detector continuously in the background. Further, a policy can be instituted which ensures that a virus detector will be executed at least once between the time that new files are installed on the system, and the time that any files are exported from the system. 2.5 DETECTING VIRAL INFECTIONS With the possible exception of isolation, all of the methods outlined above for preventing viral infections are only somewhat reliable. Viruses can still reach some systems despite the implementation of preventative measures. Indeed, no perfect defense exists that still allows programming, and sharing of executable information. There is no "one time fix," as there is for many other computer security problems. This is a hole that cannot be plugged completely. Defenses will have to be improved with time to deal with new classes of viruses. Because of this, virus *detection* is an important component of system security. The two most important resources available for the detection of viruses are watchful users and watchful programs. The best approaches to virus detection include both. The users Coping with Computer Viruses: A Guide for Technical Management 12 should be aware of the possibility of viruses, just as they are aware of the need for backups, and to know what kinds of things to watch for. System programs and utilities should be available to help the users, and the computer center staff, to take advantage of this awareness. 2.5.1 Watching for Unexpected Things Happening If users are aware of the kinds of visible things that are known to happen in systems that are virus-infected, these users can serve as an important line of defense. Users should know that odd behavior in a computer system may be a symptom of penetration by a virus, and they should know to whom such odd behavior should be reported. On the other hand, it is a fact that odd behavior is usually *not* caused by viral penetration. Software bugs, user errors, and hardware failures are much more common. It is important to avoid unfounded rumors of viral infections, as dealing with such "false alarms" can be costly. An actual infection, however, may require rapid action. So the group to which users report oddities must have the skill to determine which reports are almost certainly due to one of these more common causes, and which merit closer investigation for possible viral infection. One obvious choice for such a group is within the computing center or "help desk," since the computing center staff probably already has a good idea of what sorts of oddities are "business as usual." 2.5.2 Some Symptoms of Known Viruses 2.5.2.1 Workstation Viruses This section lists specific oddities that are known to occur in workstations infected with particular viruses that have already occurred. Some of the things in these examples only occur once the virus is in place, and is triggered to perform its particular function. Others occur while the virus is still spreading. Some things users should know to watch for include: o Unexpected changes in the time stamps or length of files, particularly executable files, Coping with Computer Viruses: A Guide for Technical Management 13 o Programs taking longer to start, or running more slowly than usual, o Programs attempting to write to write-protected media for no apparent reason, o Unexplained decreases in the amount of available workstation memory, or increases in areas marked as "bad" on magnetic media, o Executable files unexpectedly vanishing, o Workstations unexpectedly "rebooting" when certain previously-correct programs are run, or a relatively constant amount of time after being turned on, o Unusual things appearing on displays, including "scrolling" of odd parts of the screen, or the unexpected appearance of "bouncing balls" or odd messages, o Unexpected changes to volume labels on disks and other media, o An unusual load on local networks or other communication links, especially when multiple copies of the same data are being sent at once. It is important to remember, though, that future viruses may do none of these things. Users should be alert to oddities in general and should have a place to report them, as recommended above. 2.5.2.2 Mainframe Viruses Viruses in multi-user computer systems share some of the typical behaviors of viruses in single-user workstations. In particular, lengths or time stamps of executable files may change, programs may load or execute more slowly, unusual errors (especially relating to disk-writes) may occur, files may vanish or proliferate, and odd things may appear on displays. If the virus is attempting to spread between users, users may also notice "outgoing mail" that they did not intend to send, "links" to other user's information that they did not intentionally establish, and similar phenomena. Generally, the same comments apply in this environment as in the single-user workstation environment. Future viruses may do none of these things, and users should be sensitive to suspicious oddities in general, and have a place to which to report them. Coping with Computer Viruses: A Guide for Technical Management 14 2.5.3 Watching for Changes to Executable Objects Users are not the only line of defense in the detection of viruses. It is comparatively simple to create programs that will detect the presence and the spread of the simpler classes of viruses. Such programs can go a long way in "raising the bar" against computer viruses. One effective approach to detecting simple viruses involves notifying the user of changes to the contents of executable objects (program files, "boot records" on magnetic media, and so forth). Users can be provided with a program to be run once a day which will examine the executable objects to be checked, and compare their characteristics with those found the last time the program was run. (This could be run at the same time as the backup program, for instance.) The user can then be presented with a list of objects that have changed. If things have changed that should not have, the user can contact the appropriate people to investigate. If certain objects that should seldom or never change (such as the operating system files themselves) are different, the user can be specially warned, and urged to contact the appropriate people. Often, a central system programming group has control over a large multi-user computing system. That group can execute this sort of program periodically, to check for changes to common operating system utilities, and to the operating system itself. Because viruses can often spread to privileged users, they are quite capable of infecting even those parts of the system that require the highest authority to access. The frequency with which virus detectors should be used depends upon the rate at which executables are transmitted, and the value of the information assets on the systems. Workstations that are not connected to networks can exchange information via floppy disks. The known computer viruses that propagate by way of floppy disks do so relatively slowly. It may take days, or weeks, or even months for such a virus to propagate across a large organization. In this case, running virus detectors once a day, or once a week, may be sufficient. For systems connected to networks, especially large-scale networks, the situation is much different. Experience has shown network viruses to be capable of spreading very rapidly across the network. In some cases, replicating programs have spread across nationwide networks in a matter of hours or days. In these cases, it may be important to run virus detectors hourly or daily. Coping with Computer Viruses: A Guide for Technical Management 15 Below is an outline of one possible implementation of a virus detecting program. It is for illustration only; many different structures would do the job as well or better. 1. The program obtains a list of files to be checked. For PC-DOS, for instance, this should include .COM and .EXE files, any files that are listed as device drivers in the CONFIG.SYS file, the CONFIG.SYS file itself, and any other executables such as batch files or BASIC programs. 2. For each of these files, the program o Determines the time/date and length of the file from the operating system. o If desired, actually reads the data in the file, and performs a calculation such as a CRC (cyclic redundancy check) on the data. (The number of files checked in such detail depends on the importance of the file, the speed of the program, and the amount of time the user is willing to spend.) o Compares this file information (time/date, length, and perhaps CRC or other code) with the database generated last time the program was run. o If the file was not present the last time the program was run, or if the information in the previous database was different from the information just obtained, the program records that the file is new or changed. 3. After checking all relevant files, the program reads all other known executable objects in the system(1), and compares their CRC or other codes with the values in the database, and records any changes. 4. When all the existing objects have been checked in this way, the program updates the database for next time and presents all its findings to the user. 5. On the basis of this information, the user can decide whether any of the reported changes are suspicious, and worth reporting. This method is by no means foolproof. A sophisticated virus could do a variety of things. It could change an executable object without altering the time, date, length, or CRC code. It could only alter objects that had been legitimately changed recently. It could act directly on the database itself and thus escape detection. More sophisticated versions of the program outlined here can provide significantly more foolproof detection. It is advantageous to have many different virus detectors in place at the same ---------------- (1) For PC-DOS, this would typically include the boot record on a floppy diskette, and the master and partition boot records on hard disks. For multi-user operating systems, this might include "shared system images," or "IPL datasets" or equivalent objects. Coping with Computer Viruses: A Guide for Technical Management 16 time. That way, a virus that can evade one detector may be caught by another. Nevertheless, user awareness, and procedures for recovery in the event of an infection that is not detected until too late, are both still vital. 2.5.4 Using External Information Sources Software viruses are able to spread because information flows so quickly in the modern world. That same information flow can help in the detection of viruses. Newspapers, magazines, journals, and network discussion groups have carried significant amounts of material dealing with computer viruses and other forms of malicious software. These sources of information can be valuable in maintaining awareness of what hazards exist, and what measures are available to detect or prevent specific viruses. This kind of information can be invaluable to the people in your organization charged with investigating suspicious events reported by users, and deciding which ones to follow up on. On the other hand, these channels also carry a certain amount of inevitable misinformation, and care should be taken not to react to, or spread, rumors that seem to have no likely basis in fact. 2.6 CONTAINING VIRAL INFECTIONS Having procedures in place to detect viral infection is very important. By itself, however, it is of little use. The individual who makes the first detection must have a procedure to follow to verify the problem and to make sure that appropriate action occurs. If the information supplied in the detection phase is allowed to "fall between the cracks," even for a relatively short time, the benefit of detection can easily be lost. 2.6.1 The Importance of Early Detection Computer viruses generally spread exponentially. If a virus has infected only one system in a network on Monday, and spread to four by Tuesday, sixteen systems could easily be infected by Wednesday, and over five hundred by Friday. (These numbers are just samples, of course, but they give an idea of the potential speed of spread. See reference (1) Coping with Computer Viruses: A Guide for Technical Management 17 for some experiments in which much faster spread was observed.) Because viruses can spread so fast, it is very important to detect them as early as possible after the first infection. The surest way of doing this is to have every vulnerable user run the best available virus-detection software as often as feasible. This solution may be too expensive and time-consuming for most environments. In most groups of users, it is possible to identify a number of "star" users who do a disproportionately large amount of information-exchange, who generally run new software before most people do, and who are the first to try out new things in general. In multi-user systems, some of these people often have special authorities and privileges. When a virus reaches one of these people, it can spread very rapidly to the rest of the community. In making cost/benefit decisions about which users should spend the most time or effort on virus-detection, these are the people to concentrate on. 2.6.2 The Importance of Rapid Action When a virus is detected, every moment spent deciding what to do next may give the virus another chance to spread. It is vital, therefore, to have action plans in place *before* an infection occurs. Such plans should include, for instance: o Designation of one particular group (whether formal or informal) as the "crisis team," o Procedures for identifying infected systems, by determining how and from where the infection reached each system known to be infected, o Procedures for isolating those systems until they can be rendered free of the virus, o Procedures for informing vulnerable users about the virus, and about how to avoid spreading it themselves, o Procedures for removing the virus from infected systems, o Procedures for identifying the virus involved, and for developing or obtaining specific software or procedures to combat the virus. These may remove the virus from infected systems and files, determine whether or not backups are infected, and so on. o Procedures for recording the characteristics of the virus and the effectiveness of the steps taken against it, in case of later re-infection with the same or a similar virus. Some suggestions for recovery are given in the next section. Coping with Computer Viruses: A Guide for Technical Management 18 2.7 RECOVERING FROM VIRAL INFECTIONS Once a virus has been detected and identified, and measures have been taken to stop it from spreading further, it is necessary to recover from the infection, and get back to business as usual. The main objective of this activity is to provide each affected user with a normal, uninfected computing environment. For individual workstations, this means ensuring that no infected objects remain on the workstation. For more complex environments, it means ensuring that no infected objects remain anywhere on the system where they might inadvertently be executed. The basic recovery activities are: o Replacing every infected object in the system with an uninfected version, and o Restoring any other objects that the virus' actions may have damaged. It is of critical importance during these activities to avoid re-introducing the virus into the system. This could be done, for instance, by restoring an infected executable file from a backup tape. 2.7.1 Restoration and Backups An obvious but incorrect approach to removing the infection from a system is simply to restore the infected objects from backups. This is *not* a wise thing to do, however, since the backups themselves may be infected. If the virus first entered the system sufficiently long ago, infected objects may well have been backed up in infected form. Once the virus has been well understood, in terms of what types of objects it spreads itself to, three different categories of objects may be considered for restoration: o Objects of the type that the virus infects. These should only be restored from backups if the backed-up versions are thoroughly and individually checked for infection by the virus. If it is possible, it is preferable to restore the objects from more "trusted" sources, such as original, unwriteable, copies supplied by the manufacturer, or by recompiling source code. Even in these cases, it is worthwhile to check once again for infection after restoration has been done. Coping with Computer Viruses: A Guide for Technical Management 19 o Objects of types that the virus does not infect, but which have been destroyed or altered by the virus' actions. These can generally be restored from backups safely, although again it is worth checking the integrity of the backed-up copies. If the virus has been in the system long enough, it may have damaged objects that were later backed up. o Objects of types that the virus neither infects, nor damages. If you are very sure that the virus does not infect or alter certain types of files, there may be no need to restore those files during the recovery process. 2.7.2 Virus-Removing Programs Once a virus has been studied, you can write or obtain programs to help remove that particular virus. One type of these programs checks for the presence of the virus in a executable objects. Another type tries to remove the infection by restoring the object to its previous uninfected form. "Checking" programs can be extremely valuable during the recovery process, to ensure that files that are being restored after infection or damage by the virus are now "clean." "Removal" programs are somewhat less useful, and should usually only be used when there is no other practical way to obtain an uninfected version of the object. Removing a virus from an executable object can be a complex and difficult process, and even a well-written program may fail to restore the object correctly. 2.7.3 Watching for Re-Infection Once recovery is complete, and all known infected and damaged objects have been restored to uninfected and correct states, it is necessary to remain watchful for some time. A system that has recently been infected by a certain virus runs an increased risk of re-infection by that same virus. The re-infection can occur through some obscure, infected object that was missed in the recovery process. It can also occur from the same outside source as the original infection. This is especially true if the original source of infection is not known. Vigilance in the use of general virus-detection programs, like those described above, continues to be important. In addition, it will often be possible to obtain or write programs designed to detect the specific virus from which Coping with Computer Viruses: A Guide for Technical Management 20 the system has just recovered. Specific virus-detection programs of this kind are particularly useful at this time. The same users who use the general virus-detection programs, and any users who would be specifically vulnerable to the virus just recovered from, can be given such programs to run. This increases the probability of detection, should an infection recur. The programs might also be incorporated into the backup system for a time, to scan files being backed up for infection, and even into appropriate places in networks and file-sharing systems. Because such checks will introduce extra overhead, there will be a trade-off between performance and added security in considering how long to leave them in place. 2.8 SUMMARY AND RECOMMENDATIONS Computer viruses can pose a threat to the security of programs and data on computing systems. We have suggested several means of limiting this threat. They are summarized below. o Viruses represent a new kind of threat to the security of computing systems. - They can be spread without the intent of the people who spread them. - They can spread widely and quickly within an organization, reaching systems and users well beyond the initial infection point. - They can perform virtually any action that their designer intends. o The risks posed by viruses can be limited by proper action. - Follow good security practices in general. -- Educate your users about security threats, including computer viruses. -- Make sure that good backups are kept of all important data. - Take steps to reduce the possibility of being infected. -- Where practical, isolate critical systems from sources of infection, such as networks and outside programs. Coping with Computer Viruses: A Guide for Technical Management 21 -- Where practical, limit the ability to create or install new programs on those systems which do not require this ability. -- Ensure that adequate controls exist on software repositories, production systems, and other important areas of your organization. These include careful change management and the use of virus detectors. - Take steps to ensure that virus infections will be detected quickly. -- Educate your users about possible warning signs. -- Use virus detectors, which will inform users of the unintended modification of programs and data. -- Make sure your users know to whom they can report a potential problem. - Take steps to contain virus infections that are detected. -- A plan to deal with an infection should be put into place *before* an infection occurs. -- A "crisis team" should be put into place, which can respond quickly to a potential problem. -- Isolate infected systems until they can be cleaned up, to avoid them infecting other systems, and to avoid their becoming reinfected. - Take steps to recover from viral infections that are contained. -- Be able to restore critical programs and data from virus-free backups. -- Know how to remove viruses from programs if virus-free backups are unavailable. -- Watch for a reinfection from that particular virus. Coping with Computer Viruses: A Guide for Technical Management 22 FOR FURTHER READING (1) Fred Cohen, "Computer Viruses: Theory and Experiment," Computers & Security, Vol. 6 (1987), pp. 22-35 (2) Fred Cohen, "On the Implications of Computer Viruses and Methods of Defense," Computers & Security, Vol. 7 (1988), pp. 167-184 (3) W.H. Murray, "Security Considerations for Personal Computers," IBM System Journal, Vol. 23, No. 3 (1984), pp. 297-304 (4) --, "Security Risk Assessment in Electronic Data Processing Systems," IBM Publication Number G320-9256-0 (1984) (5) --, "Good Security Practices for Information Systems Networks," IBM Publication Number G360-2715-0 (1987) (6) --, "An Executive Guide to Data Security," IBM Publication Number G320-5647-0 (1975) (7) --, "Security, Auditability, System Control Publications Bibliography," IBM Publication Number G320-9279-2 (1987) For Further Reading 23 GLOSSARY Computer viruses and the like are relatively new phenomena. The terms used to describe them do not have definitions that are universally agreed upon. In this glossary, we give definitions that try to clarify the differences between the various concepts. These terms may be used differently elsewhere. Availability: That aspect of security that deals with the timely delivery of information and services to the user. An attack on availability would seek to sever network connections, tie up accounts or systems, etc. Back Door: A feature built into a program by its designer, which allows the designer special privileges that are denied to the normal users of the program. A back door in a logon program, for instance, could enable the designer to log on to a system, even though he or she did not have an authorized account on that system. Bacterium (informal): A program which, when executed, spreads to other users and systems by sending copies of itself. (Though, since it does "infect" other programs, it may be thought of as a "system virus" as opposed to a "program virus.") It differs from a "rabbit" (see below) in that it is not necessarily designed to exhaust system resources. Bug: An error in the design or implementation of a program that causes it to do something that neither the user nor the program author had intended to be done. Confidentiality: That aspect of security which deals with the restriction of information to those who are authorized to use it. An attack on confidentiality would seek to view databases, print files, discover a password, etc., to which the attacker was not entitled. Integrity: That aspect of security that deals with the correctness of information or its processing. An attack on integrity would seek to erase a file that should not be erased, alter an element of a database improperly, corrupt the audit trail for a series of events, propagate a virus, etc. Glossary 24 Logic Bomb: A Trojan Horse (see below), which is left within a computing system with the intent of it executing when some condition occurs. The logic bomb could be triggered by a change in a file (e.g. the removal of the designer's userid from the list of employees of the organization), by a particular input sequence to the program, or at a particular time or date (see "Time Bomb" below). Logic bombs get their name from malicious actions that they can take when triggered. Rabbit (informal): A program is designed to exhaust some resource of a system (CPU time, disk space, spool space, etc.) by replicating itself without limit. It differs from a "bacterium" (see above) in that a rabbit is specifically designed to exhaust resources. It differs from a "virus" (see below) in that it is a complete program in itself; it does not "infect" other programs. Rogue Program: This term has been used in the popular press to denote any program intended to damage programs or data, or to breach the security of systems. As such, it encompasses malicious Trojan Horses, logic bombs, viruses, and so on. Security: When applied to computing systems, this denotes the authorized, correct, timely performance of computing tasks. It encompasses the areas of confidentiality, integrity, and availability. Time Bomb: A "logic bomb" (see above) activated at a certain time or date. Trojan Horse: Any program designed to do things that the user of the program did not intend to do. An example of this would be a program which simulates the logon sequence for a computer and, rather than logging the user on, simply records the user's userid and password in a file for later collection. Rather than logging the user on (which the user intended), it steals the user's password so that the Trojan Horse's designer can log on as the user (which the user did not intend). Virus (pl. viruses): a program that can "infect" other programs by modifying them to include a possibly evolved copy of itself. Note that a program need not perform malicious actions to be a virus; it need only "infect" other programs. Many viruses that have been encountered, however, do perform malicious actions. Worm: A program that spreads copies of itself through network-attached computers. The first use of the term Glossary 25 described a program that copied itself benignly around a network, using otherwise-unused resources on networked machines to perform distributed computation. Some worms are security threats, using networks to spread themselves against the wishes of the system owners, and disrupting networks by overloading them. Glossary 26 APPENDIX: VIRAL INFECTIONS IN PC-DOS This section is intended to give an example of the places in a typical computer system where a virus might enter. It is intended for a reader with some knowledge of the workings of PC-DOS, although it may be instructive to others as well. PC-DOS was chosen for convenience; many computer systems have similar vulnerabilities. Consider the process that is required for you to run a single program. What is happening? Which parts do you not bother checking since you have seen it a million times? For example, you turn on the power switch and then ... o You boot off the disk. What code ran to enable you to boot off the disk? o You boot off a diskette drive. Again ... o You run a program. It reads off a disk. What was actually read in? How was it read in? What did the reading? o You compile a program. Are you using any library files? What is in them? o When was the last time you looked at your CONFIG.SYS? AUTOEXEC.BAT? o You just bought a brand new program. You just brought it home from the store. What do you know about the program? About the company that produced it? This list is not meant to be all-inclusive nor thorough. It is meant to be a spark to start education. Let us continue by examining each of these cases. (Where found, the symbol "(!)" is used to designate a potential point of attack for viruses.) When you turn on the power switch Before we investigate the different cases above, we examine the steps that occur when you first flip the power switch of your IBM PC to the ON position. Appendix: Viral Infections in PC-DOS 27 Power is given to the system. A section of code known as POST (Power On Self Test) residing in ROM (Read Only Memory) starts running. It checks memory, devices, peripherals, and then transfers control to any "properly signatured" ROMs found in the I/O channels. Assuming those pieces run smoothly, control returns to POST. When POST completes, it searches for a diskette in the diskette drive. If unsuccessful, it tries to boot off a hard file. And finally, if neither works, it starts running the BASIC interpreter which is found in its ROM. The first place where programs are read into system RAM (Random Access Memory) is the hard file or diskette boot up process. Until then, all the code that is run has come from ROM. Since these ROMs are from trusted sources, we must assume that they have not been created with viruses installed. ROMs, by their nature, can only be written by special equipment, not found in your PC. Thus to tamper with them, they must be removed and/or replaced without your knowledge. For the purposes of this discussion, we will assume that this has not happened. Boot from hard file When the computer boots off the hard file, it relies on code which has been placed in two areas on the hard file. The first location is the master boot record(!). The master boot record contains code and information to designate which "system boot record"(!) to read and run. This is the "active partition." There are potentially many system boot records, one for each partition, while there is only one master boot record. Boot records on a fixed disk vary. But usually, up to a whole track is reserved. This is a large amount of space, most of which is not normally used. The large empty space provides a potential area for viruses to hide. Boot from diskette For a floppy disk, the boot record is a properly "signatured" sector at head 0 track 0 sector 1 of the disk(!). If the machine finds a proper signature, it takes the bytes stored in that sector and begins Appendix: Viral Infections in PC-DOS 28 executing them. This code is usually very short. Usually, one of the first things it does is to tell the machine where to get other sectors to form a complete boot up program. Viruses can hide parts of themselves on either hard or floppy disks, in sectors that they mark as "bad."(!) These sectors would require special commands to be read. This prevents the code from being accidentally overwritten. They also provide an obvious sign, should you be looking for them (CHKDSK will report bad sectors). PC-DOS, the operating system The purpose of the boot records is to load the operating system. This is done by loading files with the names IBMBIO.COM(!), IBMDOS.COM(!), and COMMAND.COM(!). These files contain the operating system. After the operating system is loaded, it becomes the integral portion of all system activities. This includes activities such as reading and writing files(!), allocating memory(!), and allocating all other system resources(!). Few applications exist that do not use the operating system to take advantage of the system resources. Thus, some viruses change COMMAND.COM or intercept attempts to request a system resource. The purpose of such action would be two-fold. The first purpose is to place the virus in a common code path, so that it is executed frequently so that it may have ample opportunity to spread. The second is to cause damage, intercepting the proper request and altering the request. Running a program What code runs when you run a program? (!) (The following list is not meant to be complete. It is to show you that any link could be a potential point of attack for a virus. Since the virus' purpose is to be executed frequently, it would find itself executed frequently enough if it resided in any of the following areas.) Appendix: Viral Infections in PC-DOS 29 o DOS accepts your keystrokes. - BIOS INT 9H, INT 16H, INT 15H, INT 1BH - DOS INT 21H keyboard functions, INT 28H - Any keyboard device driver or TSR (Terminate and Stay Resident) program. o DOS loads your program - BIOS INT 13H, INT 40H, INT 15H - DOS INT 21H file search functions, memory allocation, set DTA, disk read, CTRL-BREAK check, etc. - Any DOS extension driver or TSR (Terminate and Stay Resident) program. o General background functions - BIOS INT 8 (timer), INT 0FH (printer), INT 1CH (timer) - Any system driver or TSR (Terminate and Stay Resident) program. All these things happen and more, each time you run a program. CONFIG and AUTOEXEC Every time you boot your system, CONFIG.SYS(!) and AUTOEXEC.BAT(!) tell the system to load many files and options before you can start working on the computer. If a virus decided to attach an extra line of instruction to one of these files, it would result in the program being loaded each day. When was the last time you looked at CONFIG.SYS? AUTOEXEC.BAT? Do you remember the reason for the existence of each line in the two files? Compiling programs, using libraries When you compile a program, you use several programs. One is the compiler itself (!). If the compiler is infected with a virus, the virus may spread to other, unrelated programs. But it could also spread to the program being compiled. When a compiled program is linked to form an executable program, it is common to link in programs Appendix: Viral Infections in PC-DOS 30 from libraries(!). These library programs provide standard operating system interfaces, perform input and output, and so on. If one or more of the library programs are infected with a virus, then every program which is linked with it will be infected. Appendix: Viral Infections in PC-DOS 31