Protection plans with computer virus

=================================

D1) What is the best antivirus program?

None! Different products are more or less appropriate in different
situations, but in general you should build a cost-effective *strategy*
based on multiple layers of defense. There are three main kinds of
antivirus software, plus several other means of protection, such as
hardware write-protect methods (see D4). When planning your antivirus
strategy you should also look closely at your backup policies and
procedures (see 10).

1. ACTIVITY MONITORING programs. These try to prevent infection
before it happens by looking for virus-like activity, such as
attempts to write to another executable, reformat the disk,
etc. An alternative term is BEHAVIOR BLOCKER.

Examples: SECURE and FluShot+ (PC), and GateKeeper
(Macintosh).

These programs are considered the weakest line of defense
against viruses on a system that does not have memory
protection, because in such an environment it is possible for
a tunnelling virus (see B12) to bypass or disable them.

2. SCANNERS. Most look for known viruses by searching your
disks and files for "scan strings" or patterns, but a few use
heuristic techniques to recognize viral code. Most now also
include some form of "algorithmic scanning" in order to
detect known polymorphic viruses. A scanner may be designed
to examine specified disks or files on demand, or it may be
resident, examining each program which is about to be
executed. Most scanners also include virus removers.

Examples: FindViru in Dr Solomon's AntiVirus ToolKit, Frisk
Software's F-PROT, McAfee's VirusScan (all PC), Disinfectant
(Macintosh).

Resident scanners: McAfee's V-Shield, and F-PROT's VIRSTOP.

Heuristic scanners: the Analyse option in F-PROT, TBAV's
TbScan and ChkBoot (from Padgett Peterson's FixUtils).

Scanners are the most convenient and the most widely used
kind of antivirus programs. They are a relatively weak line
of defense because even the simplest virus can bypass them if
it is new and unknown to the scanner. Therefore, your virus
protection system should not rely on a scanner alone.

3. INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute
a small "checksum" or "hash value" (usually CRC or
cryptographic) for files when they are presumably uninfected,
and later compare newly calculated values with the original
ones to see if the files have been modified. This catches
unknown viruses as well as known ones and thus provides
*generic* detection. On the other hand, modifications can
also be due to reasons other than viruses. Usually, it is up
to the user to decide which modifications are intentional and
which might be due to viruses, although a few products give
the user help in making this decision. As in the case of
scanners, integrity checkers may be called to checksum entire
disks or specified files on demand, or they may be resident,
checking each program which is about to be executed (the
latter is sometimes called an INTEGRITY SHELL). A third
implementation is as a SELF-TEST, where the checksumming code
is attached to each executable file so they check themselves
just before execution. It is generally considered a bad idea
to add such code to existing executables (see F8).

Examples: ASP Integrity Toolkit (commercial), and Integrity
Master and VDS (shareware), all for the PC.

Integrity checkers are considered to be the strongest line of
defense against computer viruses, because they are not virus-
specific and can detect new viruses without being constantly
updated. However, they should not be considered as an
absolute protection--they have several drawbacks, cannot
identify the particular virus that has attacked the system,
and there are successful methods of attack against them too.

3a. Some modification detectors provide HEURISTIC DISINFECTION.
Sufficient information is saved for each file so that it can
be restored to its original state in the case of the great
majority of viral infections, even if the virus is unknown.

Examples: V-Analyst 3 (BRM Technologies, Israel), the VGUARD
module of V-Care and ThunderByte's TbClean.

Note that behavior blockers and scanners are virus *prevention* tools,
while integrity checkers are virus *detection* tools.

Of course, only a few examples of each type have been given. All of
these types of antivirus program have a place in protecting against
computer viruses, but you should appreciate the limitations of each
method, along with system-supplied security measures that may or may not
be helpful in defeating viruses. Ideally, you should arrange a
combination of methods that cover each others' weaknesses.

A typical PC installation might include a protection system on the hard
disk's MBR to protect against viruses at load time (ideally this would
be hardware or in BIOS, but software methods such as DiskSecure and
Henrik Stroem's HS are pretty good). This would be followed by resident
virus detectors loaded as part of the machine's startup (CONFIG.SYS or
AUTOEXEC.BAT), such as FluShot+ and/or VirStop and/or ChkBoot. A
scanner such as F-PROT or McAfee's VirusScan and an integrity checker,
such as Integrity Master, could be put into AUTOEXEC.BAT, but this may
be a problem if you have a large disk to check, or don't reboot often
enough. Most importantly, new files and diskettes should be scanned as
they arrive *regardless* of their source. If your system has DR DOS
installed, you should use the PASSWORD command to write-protect all
system executables and utilities. If you have Stacker or SuperStor, you
can get some improved security from these compressed drives, but also a
risk that those viruses stupid enough to directly write to the disk
could do much more damage than normal. In this case a software write-
protect system (such as provided with Disk Manager or The Norton
Utilities) may help. Possibly the best solution is to put all
executables on a disk of their own, with a hardware write-protect system
that sounds an alarm if a write is attempted.

If you do use a resident BSI detector or a scan-while-you-copy detector,
it is important to trace back any infected diskette to its source. The
reason viruses survive so well is that usually you cannot do this,
because the infection is found long after the infecting diskette has
been forgotten due to most people's lax scanning policies.

Organizations should devise and implement a careful policy that may
include a system of vetting new software brought into the building and
free virus detectors for home machines of employees/students/etc who
take work home with them.

Other antivirus techniques include:

1. Creation of a special MBR to make the hard disk inaccessible
when booting from a diskette (the latter is useful since
booting from a diskette will normally bypass any protection
measures loaded in the CONFIG.SYS and/or AUTOEXEC.BAT files
on the hard disk).

Some of these systems won't prevent attack by some MBR virus
infections if booting from an infected floppy. This approach
is less important now, as most newer PCs allow you to change
the boot order so the first hard drive is tried *before* any
of the floppy drives.

2. Use of Artificial Intelligence to learn about new viruses and
extract scan patterns for them.

Examples: V-Care (CSA Interprint, Israel; distributed in the
US by Sela Consultants Corp.), Victor Charlie (Bangkok
Security Associates, Thailand; distributed in the US by
Computer Security Associates).

3. Encryption of files (with decryption before execution).

4. Diskette "fences". There are three different approaches to
this. One prevents executables from being accessed from
floppy drives while another prohibits the use of unscanned
(possibly "unclean") files or diskettes. A third method uses
a non-standard diskette format so diskettes can only be used
on (and therefore shared among) machines using the
appropriate antivirus software (usually all those within a
site or company). This last method is probably the most
common diskette fence and provides better protection against
boot sector viruses than the other "fence" types.

The workings of the first and third are probably fairly clear
from these brief descriptions. The second approach works by
writing special information to normally unused areas of the
diskette as part of the scanning process and employing a
driver in the users' machines prevents access to files that
aren't marked as scanned (or to any part of a diskette that
contains unscanned files). Alternatives include encrypting
scanned files and drivers that only allow access to encrypted
files, and so on. One advantage of this second type of
system is that you only need scanners for "perimeter
checking" machines, reducing the overhead and cost of keeping
your scanners up to date.

Examples: D-Fence, Virus Fence, TbFence, DiskNet.


D2) Is it possible to protect a computer system with only software?

Not perfectly; although software defenses can significantly reduce your
risk of being affected by viruses *when applied appropriately*. All
virus defense systems are tools--each with its own capabilities and
shortcomings. Learn how your system works and be sure to work within
its limitations.

Using a layered approach, a very high level of protection/detection can
be achieved with software only.

1. ROM BIOS--password (access control) and selecting to boot
from the hard drive rather than from diskette. (Some may
consider this hardware.)
2. Boot sectors--integrity management and change detection.
3. OS programs--integrity management of existing programs,
scanning of unknown programs. Requirement of authentication
values for any new or transmitted software.
4. Locks that prevent writing to a fixed or floppy disk.

As each layer is added, undetected invasion becomes more difficult.
Nevertheless, complete protection against any possible attack cannot be
provided without dedicating the computer to pre-existing or unique
tasks. International standardization on the IBM PC architecture is both
its greatest asset and its greatest vulnerability.


D3) Is it possible to write-protect the hard disk with software only?

The answer is no. There are several programs that claim to do this, but
*all* of them can be bypassed with techniques already used by some
viruses. Therefore you should never rely on such programs *alone*,
although they can be useful in combination with other antivirus
measures.


D4) What can be done with hardware protection?

Hardware protection can accomplish various things, including: write
protection for hard disk drives, memory protection, monitoring and
trapping unauthorized system calls, etc. Again, no single tool will be
foolproof and the "stronger" hardware-based protection is, the more
likely it will interfere with the "normal" operation of your computer.

The popular idea of write-protection (see D3) may stop viruses
*spreading* to the disk that is protected, but doesn't, in itself,
prevent a virus from *running*.

Also, some existing hardware protection schemes can be easily bypassed,
fooled, or disconnected, if the virus writer knows them well and designs
a virus that is aware of the particular defense.

The big problem with hardware protection is that there are few (if any)
operations that a general-purpose computer can perform that are used by
viruses *only*. Therefore, making a hardware protection system for such
a computer typically involves deciding on some (small) set of operations
that are "valid but not normally performed except by viruses", and
designing the system to prevent these operations. Unfortunately, this
means either designing limitations into the level of protection the
hardware system provides or adding limitations to the computer's
functionality by installing the hardware protection system. Much can be
achieved, however, by making the hardware "smarter". This is double-
edged: while it provides more security, it usually means adding a
program in an EPROM to control it. This allows a virus to locate the
program and to call it directly after the point that allows access. It
is still possible to implement this correctly though--if this program is
not in the address space of the main CPU, has its own CPU and is
connected directly to the hard disk and the keyboard. As an example,
there is a PC-based product called ExVira which does this and seems
fairly secure, but it is a whole computer on an add-on board and is
quite expensive.


D5) Does setting a file's attributes to READ ONLY protect it from
viruses?

Generally, no. While the Read Only attribute will protect your files
from a few viruses, most simply override it, and infect normally. So,
while setting executable files to Read Only a good idea (it protects
against accidental deletion), it is certainly not a thorough protection
against viruses!

In some environments the Read Only attribute does provide some
additional protection. For instance, under Novell Netware a user can be
denied the right to modify file attributes in directories on the server.
This means that a virus that infects such a user's machine will be
unable to infect files in those server directories if the files have
their Read Only attribute set.


D6) Do password/access control systems protect my files from viruses?

All password and other access control systems are designed to protect
the user's data from other users and/or their programs. Remember,
however, that when you execute an infected program the virus in it will
gain your current rights/privileges. Therefore, if the access control
system provides *you* the right to modify some files, it will provide it
to the virus too. Note that this does not depend on the operating
system used--DOS, Unix, or whatever. Therefore, an access control
system will protect your files from viruses no better than it protects
them from you.

Under DOS, there is no memory protection, so a virus could disable the
access control system in memory, or even patch the operating system
itself. On more advanced operating systems (Unix, OS/2, Windows NT)
this is much harder or impossible, so there is much less risk that such
protection measures could be disabled by a virus. Even so, viruses will
still be able to spread, for the reasons noted above. In general,
access control systems (if implemented correctly) are only able to slow
down virus spread, not to eliminate viruses entirely.

Of course, it's better to have access control than not to have it at
all. Just be sure to not develop a false sense of security or come to
rely *entirely* on your access control system to protect you.


D7) Do the protection systems in DR DOS work against viruses?

Partially. Neither the password file/directory protection available
from DR DOS version 5 onwards, nor the secure disk partitions from DR
DOS 6 were intended to combat viruses, but they do so to some extent.
If you have DR DOS, it is very wise to password-protect your files (to
stop accidental damage too), but don't depend on it as your only means
of defense.

The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will
stop more viruses than the plain DOS attribute facility (see D5), but
that isn't saying much! The combination of the password system plus a
disk compression system may be more secure, because to bypass the
password system a virus must access the disk directly, but under
SuperStor or Stacker the physical disk will be meaningless to a virus.
There may be some viruses that, rather than invisibly infecting files on
compressed disks, very visibly corrupt such disks.

The main use of the "secure disk partitions" system, introduced in
DR DOS 6, is to stop people from fiddling with your hard disk while you
are away from the PC. The way this is implemented, however, may also
help against a few viruses that look for DOS partitions on a disk.

Furthermore, DR DOS is not fully compatible with MS/PC-DOS, especially
when you get down to the low-level tricks that some viruses use. For
instance, some internal memory structures are "read-only" in the sense
that they are constantly updated (for MS/PC-DOS compatibility) but not
really used by DR DOS, so even if a sophisticated virus modifies them,
it will not have any effect, or at least not that intended by the
virus's author.

In general, using a less compatible system diminishes the number of
existing viruses that can infect it. For instance, the introduction of
hard disks made the Brain virus almost disappear; the introduction of
the 80286 and DOS 4.0+ made the Yale and Ping Pong viruses next to
extinct, and so on.


D8) Does a write-protect tab on a floppy disk stop viruses?

In general, yes. The write-protection on IBM PC (and compatible) and
Macintosh floppy disk drives is implemented in hardware, not software,
so viruses cannot infect a diskette when the write-protection mechanism
is functioning properly (though many "friend of a friend" stories abound
contesting this).

But remember:

1. A computer may have a faulty write-protect system (this
happens!)--you can test it by trying to copy a file to a
diskette that is apparently write-protected.
2. Someone may have removed the tab for a while, allowing a
virus on.
3. The files may have been infected before the disk was
protected. Even some diskettes "straight from the factory"
have been known to be infected during the production process.

Thus, you should scan even new, write-protected disks for viruses. You
should also scan new, pre-formatted diskettes, as there have been cases
of infected, shrink-wrapped new diskettes.


D9) Do local area networks (LANs) help to stop viruses or do they
facilitate their spread?

Both. A set of computers connected in a well managed LAN, with
carefully established security settings, with minimal privileges for
each user, and without a transitive path of information flow between the
users (i.e., the objects writable by any of the users are not readable
by any of the others) is more virus-resistant than the same set of
computers if they are not interconnected. The reason is that when all
computers have (read-only) access to a common pool of executable
programs, there is usually less need for diskette swapping and software
exchange between them, and therefore less chances for a virus to spread.

However, if the LAN has lax security and is not well managed, it could
help a virus to spread like wildfire. It might even be impossible to
remove the infection without shutting down the entire LAN. Stories of
LAN login programs, shared copies of which are run on every workstation,
becoming infected are, unfortunately, not uncommon.

A network that supports login scripting is inherently more resistant to
viruses than one that does not *if* this is used to validate the client
before allowing access to the network.


D10) What is the proper way to make backups?

A good backup regime is at the heart of any comprehensive virus defense
scheme. No matter what combination of software and hardware defenses
you install, nor what "policy" you implement, there is always the
possibility that some new virus will be devised that can beat your
defenses *or* that someone will fail to follow "proper protocol" with
"foreign" media or file sources. In corporate settings, the possibility
of the latter as a form of directed attack by disgruntled employees
cannot be overlooked.

Planning to minimize the impact of a virus infection on your computing
is much like planning to minimize the effect of an earthquake or fire.
You cannot be sure where, when or even *if* you will ever be "hit"; the
potential impact could fall anywhere in a very wide range of possible
damage; being "completely safe" can involve enormous expense; and you
cannot adequately test your preparations without exposing yourself to
serious risk of damage. Therefore, finalizing on the defense scheme
that suits you involves deciding on the level of loss you can afford to
stand and probably settling on a system that, while not "perfectly
watertight," is "good enough".

Despite the importance of a good backup scheme, it is really beyond the
scope of this FAQ sheet to provide a definitive guide to planning your
backup procedure--that could easily take another document the size of
this! All this said however, we provide the following advice as, we
hope, a good starting point.

Planning an effective backup scheme really starts with answering some
important questions. Consider:

1. Who is dependent on the files on this system? Is it a home
computer mostly used by the kids for games, a standalone
workstation running a small business, a networked workstation
in a medium-sized company or the same in a large corporate
environment, or a server with many (hundreds) of users?
2. How long can the most important user be without access to
these files? One hour, 2, 4, 8, a day, a week? Remember to
assume that your problems will arise at the worst possible
moment (like 24 hours before a tax audit is due to start!).
3. What proportion (and volume!) of files are "fixed" (in the
sense that they seldom change) versus those that change? Do
all changes have to be backed-up, or is a "once-some-given-
time-period" backup acceptable?
4. What type of information is in the regularly changing files?

The answers to these (and other) questions help shape backup and
recovery plans and are fairly well understood issues amongst computer
systems professionals. Highly critical systems containing crucial data
will be designed from the outset to have high redundancy (disk
mirroring, disk arrays, UPSes, maybe even redundant servers), though
such system options *alone* provide no real protection from virus
attacks. You may opt for a backup system that records every change to
any files on your system (server-only or clients and servers) or regular
(often nightly) backup of changed data files, and so on.

When it comes to planning backup regimes with an eye to the possibility
of recovering from a virus attack, you also have to consider that
regularly backing-up executables (loosely, "programs") can cause
problems. If you do and are infected by a virus, unless you can be
*absolutely sure* of the date of first infection (despite sounding
simple, this is not something that can commonly be done!), you may have
quite a few problems finding the best backup set to restore from, as you
will probably have several sets including infected executables.

For home or small business use, it may be best to maintain two kinds of
backups. One would contain only your data files and one your operating
system and program files (issues to consider are covered in the next two
paragraphs). This may be facilitated by maintaining a strict separation
of the two kinds of files, perhaps by putting the operating system and
programs on one drive or partition and your data files on another.
While this is probably not practical for many existing machines,
enforcing adherence to the "rule" that data files should only be placed
in appropriate sub-directories (folders) within a prescribed data
directory may not be a bad thing.

The best way to manage backup of data files depends on the answers to
too many of the questions listed above for us to give definitive advice
here. While planning your backup regime, bear in mind that some viruses
damage some kinds of data files, while others make small, occasional,
random modifications as files are written to disk. While viruses with
either of these "features" are quite rare, both of these possibilities
mean that vital data files should probably be backed-up to long-cycle
media sets as well as to shorter cycle sets and other steps taken to
ensure you can recreate the sequence of changes. (For example, retain
all transaction records so they can be re-entered.)

You should probably backup executables once after installing them and
only *after* you are sure they are virus-free according to your current
antivirus screening procedures. *Never* make a backup containing
executables over media that hold *any* of your current backups. The
more cautious of us maintain several cycles of executable backups.
These precautions should ensure you don't face the problem outlined
several paragraphs ago, and mean that should a newly installed program
be infected with a virus your current defenses don't detect, you can
easily restore your system and installed software to how it was before
the infected software was installed, when you do become aware of its
presence. You will probably have to manually reinstall any programs you
installed subsequent to installing the infected program.

Having referred to this second kind of backup as "executables only", we
should point out that a complete system backup is also acceptable for
this type of backup. However, note that a sequence of full system
backups with interim "incremental" backups (when only those files that
have changed since the last complete backup are saved) is *not* what we
are advocating. Such systems tend to be too "broad brush" to be truly
useful for recovering from an unknown, future virus attack.
Unfortunately, this tends to be the preferred/recommended backup scheme
for small-to-medium sized systems (including most personal computers),
and is typically what most popular backup software for such systems is
designed to do. This doesn't mean that popular backup systems and
software aren't useful, just that you have to exercise some care in
using them (like excluding executable files from your incremental
backups).

Having said all this, there are still a few other problems to consider,
especially: Which files should you count as "data" files? This can be
problematic as most people immediately think of their word-processor and
spreadsheet files, and the like, as data, and that's about it. What
about the files in which your programs store their configuration
information? In a sense, these are as much "your data" as they are
program files, because they reflect your preferred screen colors and
layouts, default fonts, personalized button bars and so on. When you
look at the time people spend finding the (often obscure) options
settings in their programs and making them work "just right", and how
upset they can be if they lose these settings, it makes sense to treat
such configuration files as you treat other "personal data files" in
your backup regimes. Similarly, people tend to treat system
configuration files (in DOS/Windows PCs CONFIG.SYS, AUTOEXEC.BAT,
WIN.INI, SYSTEM.INI at a minimum!) as part of the system, often ignoring
the (sometimes considerable) fine-tuning these configuration files go
through *between* system and executable backups.

One last point--it cannot be stressed enough that you *MUST* have a
full, working copy of the software you need to restore your backups in a
safe place. You must be able to guarantee that this software is not
virus infected should you ever have to use it, *AND* that it is fully
usable should you be facing a machine that has had its entire hard drive
"wiped clean".