informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/virus/ibmpaper.vir

2377 lines
85 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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

Reference in New Issue View Git Blame Copy Permalink