IBM Los Angeles Scientific Center
IBM Thomas J. Watson Research Center
Los Angeles, CA
Yorktown Heights, NY
Research Report Number RC 14405
January 30, 1989
By Steve R. White, Chengi Jimmy Kuo, David M. Chess
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.
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 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.
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.
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!
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 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.
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.
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 have been 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 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,
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.
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.
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
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.
----------------
(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.
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) 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.
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.
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 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.
No Copyright. Public Document.