Table of Contents
Introduction
It's hard to believe that the first IBM personal computer ( PC) was
introduced in August, 1981. In the beginning they were used by a small
group of people. Only fifteen years later, however, we can't imagine life
without them, both at work and at home. Look around your office when the
electricity goes out, and you'll see people standing around talking because
they feel they can't get any work done without their computers.
We have become dependent on these machines and the information stored
within. As the importance of a "thing" rises, it becomes equally
as important, if not more, to secure it. (How many of you have alarm systems
in your cars?)
A large portion of modern computing life is to secure the information
that we are creating and processing. There are many aspects of information
security, ranging from physical access to ensuring that the information
has not been changed in any way.
One of the most high-profile threats to information integrity is the
computer virus. Surprisingly, PC viruses have been around for two-thirds
of the IBM PC's lifetime, appearing in 1986. With global computing on the
rise, computer viruses have had more visibility in the past two years.
In fact, the entertainment industry has helped by illustrating the effects
of viruses in movies such as "Independence Day", "The Net"
and "Sneakers".
Please note that computer viruses are also found on Macintoshes, but
in this book, we will focus on PC viruses. The topics we will cover are:
- what a virus is
- the evolution of the virus problem
- viruses on different operating systems
- solutions to the virus problem
- how Norman Virus Control products help
What is a Virus?
The terms " computer virus" and " virus" are used
very loosely in everyday conversation and have become synonymous with "trouble".
Viruses, worms, Trojan horses, and logic bombs are all unwanted, uninvited,
potentially dangerous software, but there are important distinctions among
them. The differences lie in whether the category requires a host program
and whether it makes copies of itself. All four may cause damage, but this
is not integral to the definitions. The following table defines each one:
|
TERM
|
REQUIRES HOST? |
REPLICATES |
| Virus |
Yes. Viruses require a host, and their goal is to infect other files
so that the virus can "live" longer. Some viruses perform destructive
actions although this is not necessarily the case. Many viruses attempt
to hide from being discovered.
Note: viruses are simply software programs.
|
Yes. All viruses make copies of themselves, infecting system boot sectors,
master boot sectors, programs, or data files as the opportunity arises. |
| Worm |
No. A host is not required, because worms are
typically a mainframe problem and do not need to hide from most users. |
Yes. A worm makes copies of itself as it finds
the opportunity. |
| Trojan horse |
No. While the term "Trojan horse"
sometimes refers to the program containing destructive code, the term is
more often used to refer to the entire . COM or . EXE. |
No. Most Trojan horses activate when they are
run and often destroy the structure of the current drive ( FATs, directory,
etc.), obliterating themselves in the process. |
| Bug,
Logic bomb,
Time bomb
|
Yes. Programmers cannot write a bug without
also writing other code -- although it's fair to say that most programmers
do not intentionally write bugs. Logic bombs and time bombs are intentionally
inserted in otherwise "good" code. |
No. This code generally has better things to
do than making copies of itself. Logic bombs and time bombs wish to remain
hidden, with only their effects being visible. Bugs do just about everything
except make more bugs. |
When speaking about viruses, we normally speak about four different
types:
|
What they are called
|
What they infect
|
| File virus |
Executables (program files). These are able to infect over networks. |
| Macro virus |
Data files. These are able to infect over networks. |
| Boot virus |
Boot sectors of hard drives and floppy disks.
These are not able to infect over networks. |
| Multipartite virus |
Both executable files and boot sectors. These
are able to infect over networks. |
Because a macro virus infects files, it technically is a file virus.
However, unlike traditional file viruses, it targets data files instead.
Macro viruses are becoming increasingly common, and therefore they deserve
to be treated as a separate category.
You have probably also heard other terms such as " polymorphic",
" stealth", and " encrypted". These are not types of
viruses, per se, but rather are methods that viruses use to disguise themselves
from anti-virus products.
The next sections describe file, macro, and boot viruses more thoroughly.
Multipartite viruses are not common, and therefore will not be covered
in this book.
File Virus
A file virus attaches itself to a program file (the host) and uses different
techniques in order to infect other program files.
There are three basic techniques for infecting an executable file: overwrite,
prepend, and append.
An overwriting virus places itself at the beginning of the program,
directly over the original program code, so the program is now damaged.
When you try to run this program, nothing happens except for the virus
infecting another file.
Such viruses are easily apprehended and destroyed by users and user
support staff, so they actually spread very poorly in the wild. You have
almost no chance of ever getting an overwriting virus in your machine.
The pure prepending virus may simply place all of its code at the top
of your original program. When you run a program infected by a prepending
file virus, the virus code runs first, and then your original program runs.
An appending virus places a " jump" at the beginning of the
program file, moves the original beginning of the file to the end of the
file, and places itself between what was originally the end of the file
and what was originally at the beginning of the file. When you try to run
this program, the "jump" calls the virus, and the virus runs.
The virus then moves the original beginning of the file back to its normal
position and then lets your program run.
That was a brief overview of how a virus attaches itself to a program
file. It uses different techniques in order to infect. Most file viruses
go memory-resident so that they can monitor all actions and infect other
program files. Other file viruses infect by "direct action",
which means that they infect a program file when that program file is accessed.
Several other methods exist, but for the most part, file viruses like
to go memory resident. If a file virus is memory resident, then it can
be extremely easy to infect another program file by waiting until that
program file is run and then attaching to that file. That file will then
become infected (i.e., become a " carrier"), and it will go on
to infect other program files.
Boot Virus
Boot viruses infect System Boot Sectors ( SBS) an d Master Boot Sectors
( MBS).
The MBS is located on all physical hard drives. It contains, among other
data, information about the partition table (information about how a physical
disk is divided into logical disks), and a short program that can interpret
the partition information to find out where the SBS is located. The MBS
is operating system. The SBS contains, among other data, a program whose
purpose is to find and run an operating system.
Because these system areas are read during the booting process on all
IBM-compatibles, boot viruses are operating system-independent and are
therefore able to propagate more effectively than file viruses.
Refer to See Also: Viruses on
Different Operating Systems for more information.
The Booting Process
To understand boot viruses, it is necessary to understand the booting
process.
The BIOS (Basic Input/Output System), which controls the booting process,
is initiated as soon as the power is switched on.
The next process that runs is called POST (Power On Self Test). It ensures
that the computer is in working order. One POST function that all users
will recognize is the display that counts the amount of RAM (Random Access
Memory) in the machine.
POST's final act is to kick off the booting process. The first task
is to determine whether or not there is a diskette in the floppy drive.
If there is, the System Boot Sector on the floppy is read, and the machine
attempts to boot from it.
If the diskette is not bootable (see below for more details), then you
will see the following message on the screen :
Non system-disk or disk error.
Replace and strike any key when ready.
Normally, however, no diskette is present, and the Master Boot Sector
on the hard drive is read. Then the System Boot Sector of the hard drive
is read, and it will start the operating system.
This process remains the same on machines running DOS, Windows, Windows
95, Windows NT, and OS/2. The differences appear when the operating systems
themselves are loaded.
A Bootable Diskette
When a floppy disk is formatted, a System Boot Sector is created. The
diskette can have two functions: contain program files and data files and/or
be a bootable diskette.
A bootable diskette is one that can be used to bypass the booting process
on the hard drive. Instead, the boot process runs from the diskette.
To create a bootable diskette, you must either format the diskette with
the " system" option (/S) or you must use DOS's SYS command on
the diskette.
A formatted diskette always has a System Boot Sector regardless of whether
or not the diskette is bootable. The SBS happens to be the place that a
boot virus calls home, so any formatted diskette that you have can potentially
be infected with a boot virus.
How a Boot Virus Infects
If a diskette is left in drive A: of a machine, and CMOS is set up to
first boot from drive A: and then drive C:, then the SBS of the diskette
will be read. If the SBS contains a boot virus, the boot virus will become
active, go memory resident, infect the system areas of the hard drive,
and attempt to infect other write-enabled diskettes that are accessed.
People tend to leave floppies in the drive when they turn their machines
off for the day and then forget about them when they turn their machine
on in the morning. Consequently, boot viruses are the majority of the most
common viruses seen today.
Macro Virus
Between August and November 1995, four macro viruses and one macro Trojan
horse were discovered, and the numbers continue to rise. Norman believes
that as of December, 1996, there are 100 macro viruses. The differences
between macro viruses and traditional file viruses lie in the host (data
files) and the method of replication (use of macro programming languages
inherent to applications). These differences add up to a new, formidable
data security threat. Throw in the increased use of OLE (Object Linking
and Embedding) as well as the explosive use of networks, e-mail, and the
Internet as exchange media, and the outlook is grim.
How It Works
Traditional file viruses do not attempt to infect data files, for data
files are not an ideal ground for replication. That is, one does not "run"
a data file æ one "reads" and "edits" a data
file. However, in the past few years, organizations have been building
upon open systems, in which data is shared more readily. This in turn means
that there is little security. Macro viruses take advantage of the fact
that many applications now contain macro programming languages. These languages
allow users (and virus authors) more flexibility and power within the application
than ever before. Often macro viruses are not detected early enough because
many users are not familiar with the nuances of macros. As a result, macro
viruses have an infection rate much higher than traditional file and boot
viruses.
To date, the most targeted macro programming language is WordBasic,
the language within Microsoft Word.
Why It's Such a Risk
Since data files are shared more frequently than executable (program)
files, the security threat posed by macro viruses is very real. The open
systems in many of Microsoft's applications utilize OLE in order to combine
different data types. You can embed an object such as a bitmap within a
Word document. Embedding an object means that any edits to the object will
not be reflected in any other copies of the object. You can also link an
object such as a Excel spreadsheet to a Word document. Linking an object
means that you may edit the object in either its source application or
from within the application to which it is linked, and all copies of the
object will be updated.

Microsoft Word has the ability to embed and link objects. In addition,
Word documents have the ability to be embedded and linked in other applications.
The risk, therefore, results in the ability to run a Word macro virus from
another application. For example, Microsoft's MSMail messages can contain
attachments such as Word documents. If the correct association exists,
then the MSMail user can simply double-click on the Word document, Word
will start, and the specified document will be loaded. This is only one
example of OLE in action. There are other uses of OLE in conjunction with
Word documents, and it is the frequency of such use that drives the scope
of the Word macro security threat.
Some macro viruses contain destructive code and some even create and
execute traditional file and boot viruses. While traditional file and boot
viruses affect the operation of a machine, macro viruses affect the quality
and reliability of information contained within data files.
Predictions for the Future
Norman Data Defense Systems expects an explosion in the development
of macro viruses and in the number of infections both locally and globally.
We also expect to see viruses taking advantage of common macro languages,
enabling the macro virus to become application-independent. (Remember that
currently, Microsoft Word is the application most afflicted with macro
virus infections because most macro viruses are written in WordBasic.)
In addition, we expect macro viruses to utilize polymorphic and stealth
techniques. Norman will continue to keep abreast of the macro virus problem,
along with traditional file and boot viruses, by looking towards scanning
for and removing macro viruses on the application level as well as on the
binary level.
How Many Viruses Are There?
Anti-virus vendors are asked this question all the time. The answer
is difficult for several reasons:
- There is no central organization that counts the number of viruses.
- New viruses appear every day. Some experts say that the growth of new
viruses is exponential and others say that it's quadratic. If we were able
to count them all, then the count would be valid only for a short period
of time such as a day.
- Often we find that many variants are made based upon one virus, and
often times there is disagreement among the virus research community on
the definition of " variant".
- There is no standard naming convention for viruses, and as a result
it is possible to have several different names for the same virus.
This brings up the question of how viruses get their names. Sometimes
the virus author puts text into the virus that indicates a name for the
virus or for him/herself (e.g., The xxx virus is here; Greetings from yyy).
But most of the time, names are given by people who discover them. Different
methods are used, such as: estimates of place of origin or place of detection
(e.g., the Lehigh virus), number of bytes that the virus adds to files,
what the virus does, and so on.
With those caveats in mind, Norman Virus Control products detect over
10,000 virus variants as of this writing (December, 1996).
In the Wild Viruses
Although virus researchers know of thousands of viruses, you need not
worry about all of them. Of those thousands, most of them exist only in
research labs, and the remaining handful are actually seen in homes and
organizations around the world.
As a result, virus researchers group viruses into two categories: "in
the wild" and " in the zoo", sometimes referred to as "
ITW" and " ITZ" respectively.
Viruses that are "in the wild" have been seen outside the
research labs. In the wild viruses comprise about 10% of the viruses that
we know about, and it is these viruses that you and your organization should
concern yourselves with.
If you are interested in more details, contact your nearest dealer or
Norman Data Defense Systems directly.
The Evolution of the
Virus Problem
In the beginning, computers were not connected together very well, and
computer viruses spread extremely slowly. Files were transmitted via BBSs
(bulletin board systems) or on diskette. As a result, the transmission
of infected files and boot sectors was geographically limited.
However, as soon as connectivity increased, mostly by the use of computers
in the workplace, the boundaries of computer viruses widened. First there
was the local area network ( LAN), then there was the wide area network
( WAN), and now there is the Internet. The extensive use of e-mail has
also contributed to the meteoric rise in the number of macro virus incidents.
We are now living in a society in which global technology has taken
the forefront, and global commerce is driven by communication pathways.
Computers are an integral part of this technology and so the information
they contain (as well as the malicious code they unwittingly contain) also
becomes global.
Consequently, it is much easier to get a virus today than it was two
years ago. However, the types of viruses that are common today are different
than those that were common two years ago.
Steve White, Jeff Kephart, and David Chess of the IBM Thomas J. Watson
Research Center have been following the evolution of viruses, and (among
other things) they have concluded that the prevalence of certain types
of viruses have been in part determined by changes in operating systems.
1
Briefly, the trend has been as follows:
In the following sections, we will discuss how viruses operate in different
operating systems.
Viruses on Different Operating
Systems
When viruses first appeared, the only operating system of note was MS-DOS.
It took some years for Windows to stabilize and become popular, so viruses
flourished in MS-DOS. In fact, almost all file viruses (excluding macro
viruses) are MS-DOS based.
Although OS/2 came on the scene shortly after viruses did, OS/2 is not
as mainstream an operating system as DOS. Therefore, virus writers were
-- and still are -- less likely to be running OS/2 themselves, and even
if OS/2 viruses were written frequently, they would not be as widespread
as MS-DOS viruses. As a result, there are only two known OS/2 viruses today.
Both Windows 95 and Windows NT are becoming increasingly common, and
both are backwards compatible with MS-DOS, which means that they are backwards
compatible with MS-DOS viruses. However, the architechture of the new operating
systems pose interesting challenges to viruses.
Let's take a look at viruses on MS-DOS, Windows, OS/2, Windows 95, and
Windows NT.
MS-DOS
Since the macro viruses that we have seen to date infect data files
generated from and read by Windows applications, macro viruses are not
a problem on MS-DOS-only machines.
Traditional file viruses and boot viruses prosper in MS-DOS machines
because MS-DOS has no inherent security features. Viruses, therefore, have
free rein to infect memory, and program files as described in See
Also: File Virus .
Windows
When Windows was introduced, users had to change the way they interacted
with their computers. The images on the screen were more colorful, navigating
around in a program was more intuitive, and the prospect of being able
to switch tasks without exiting an application was very enticing.
Since DOS runs "underneath" Windows, file viruses are able
to infect machines that run Windows, but their lifespans are cut short.
In general, file viruses are able to infect Windows executables, but the
executables then do not generally work properly. Impatient users would
either replace the executables, or if they were frustrated enough, reinstall
Windows. This was enough to cause the demise of the traditional file virus.
Macro viruses and boot viruses, however, have not suffered the same
fate. To date, macro viruses have been written to target Windows applications,
and therefore the presence of Windows is required. Combining the wide acceptance
of Windows with the fact that macro viruses infect data files rather than
program files (see See Also: Macro Virus ) has
led to one macro virus, Macro.Word.Concept, becoming one of the ten most
common viruses.
The actual booting process on a Windows machine is no different than
on a DOS-only machine. Therefore, boot viruses have not been hindered by
Windows, and they continue to propagate by infecting hard drives, going
memory resident, and then infecting floppy disks.
OS/2
As mentioned above, OS/2 is not as widely used as Windows and other
Microsoft operating systems. Because of the way that OS/2 was designed,
however, it is still susceptible to non-OS/2-specific viruses.
Unlike Windows, MS-DOS does not run "underneath" OS/2. OS/2
is a powerful 32-bit operating system that supports DOS applications, Windows
applications, and native OS/2 applications. In order to run DOS applications,
OS/2 furnishes VDMs (virtual DOS machines). As the name suggests, VDMs
"look" like DOS to DOS programs. Therefore, an infected DOS program
can infect other DOS program files within that VDM, but not DOS programs
in other VDMs. The newly infected DOS program file can then continue infecting
other program files which might be started in VDMs in the future. So the
infection path continues.
If Windows applications which include macro programming languages are
run on an OS/2 machine, then the OS/2 machine is equally as susceptible
to macro viruses as a Windows machine.
Again, since the booting process is the same on IBM-compatible machines
prior to the operating system being loaded, boot viruses can infect OS/2
machines. OS/2 handles diskettes differently than DOS and Windows so the
likelihood that the boot virus will propagate after it has infected the
hard drive is lower on an OS/2 machine than on a Windows or DOS-only machine.
The risk involved is rather one of the boot virus's action on the hard
drive. If the boot virus was designed to have a payload, then we can expect
it to be delivered, regardless of whether it was able to infect any floppies.
OS/2 supports two file systems: FAT (file allocation table) and HPFS
(high performance file system), and you may use just one or both. HPFS
is more advanced and stores information in different places, so you can
expect serious effects on an HPFS system from a boot virus that expected
to only see FAT.
Windows 95
Unlike Windows and DOS, Windows 95 is marketed as having built-in security
features. Unfortunately, such features are not robust enough to safeguard
Windows 95 against viruses. In fact, to date there has been one virus written
especially to target Windows 95 (the Boza virus). Furthermore, Windows
95's workgroup networking environment has no file-level protection and
therefore can potentially lead to increases in virus spreading.
Windows 95 shares many characteristics with OS/2 with respect to system
architecture and interaction with viruses:
Like OS/2, Windows 95 is a 32-bit operating system that supports DOS
applications, Windows applications, and native Windows 95 applications.
Similar to OS/2's VDMs, Windows 95 has VMs (virtual machines) -- a System
Virtual Machine with separate address spaces for Win32 applications and
a shared address space for all Win16 applications; and separate virtual
machines for individual DOS applications.
File viruses can easily spread on a Windows 95 machine because DOS program
files' only limitation under Windows 95 is that they cannot write directly
to the hard drive.
Each DOS VM takes on the characteristics of the system from the point
at which the machine was started. Since Windows 95 first starts up by running
the same programs as a DOS-only machine does, it is possible that an infected
program running during the startup process could could go on to infect
other program files within that VM. In addition, if that infected program
originated from the startup process, it would become active in all VMs
that were started in the future. Although program files from one VM cannot
infect program files in another VM, it is possible for an infected program
file to be loaded into a separate VM in the future, thereby continuing
the infection path.
The macro viruses that have been written to date target data files generated
from and read by Win16 and Win32 applications that are frequently run on
Windows 95. As a result, macro virus infections abound on Windows 95.
Since the Windows 95 boot process is the same as a DOS-only or Windows
machine (up to a certain point), boot viruses are able to infect hard drives
of Windows 95 machines. When Windows 95 loads, however, boot viruses are
often disabled and not allowed to propagate. On the other hand, if the
boot virus has a payload, it may deliver it without requiring the virus
to replicate beforehand.
Windows NT
As discussed in the sections on OS/2 and Windows 95, Windows NT supports
DOS applications, Windows applications, and native Windows NT applications.
Like Windows 95, Windows NT is backwards compatible with DOS and Windows.
Despite the fact that NT's security features are more robust than Windows
95's, file viruses can still infect and propagate within Windows NT. DOS
applications run in separate VDMs (virtual DOS machines), and file viruses
can function within the VDM. Some DOS file viruses might not work in the
intended fashion under NT, but there is nothing about NT's security that
prevents file viruses from infecting.
As with Windows 95, Windows NT supports applications that contain macro
programming languages, making NT as vulnerable to macro viruses as Windows-only
machines.
Because Windows NT machines boot the same way that DOS machines do (up
to the point at which NT takes over), boot viruses are able to infect NT
hard drives. However, when these boot viruses attempt to go memory resident,
they will be stopped by NT and therefore be unable to infect floppies.
In effect, this stops the infection path, but the user must still deal
with any side effects that the boot virus may have on the system -- destructive
payloads or manhandling NT's boot area in such a way that NT refuses to
load.
Solutions to the Virus Problem
When people think of anti-virus solutions, they normally think of scanners.
Scanners are the most readily available type of anti-virus solution, but
they are not the only type.
It's perhaps best to think of anti-virus solutions in terms of:
- what is required to detect the virus
- generic methods
- specific methods
and
- when the virus is detected
- prior to the attempted infection
- after the infection
A virus can be detected using either generic methods or specific methods.
Generic methods look for virus-like behavior rather than specific viruses.
As a result, even new viruses can be detected, and there is little need
for frequent updates to the tool that is being used. Because generic methods
look for behavior rather than specific viruses, the name of the virus is
normally not given. Instead users are simply warned that a virus is likely
to be present. Some shy away from this method because it can give false
alarms --either by detecting a virus that is not there or not detecting
a virus that is there.
Examples of generic detection methods are:
- checksumming and integrity checking
- heuristics
- decoys
- behavior blocking
Specific methods, on the other hand, rely on having prior knowledge
of the virus. In this case the tool is able to both detect that the virus
is present as well as identify it. As a result, frequent updates to the
tool are necessary. Most users like to know what they're "up against"
if a virus is found, and the best way to do that is to determine the exact
nature of the beast. For this reason, many users prefer this method, but
they do not ultimately appreciate how often the tool must be updated.
Examples of specific detection methods are:
- on-demand and scheduled scanning
- real-time scanning
An equally important consideration is when the virus is detected. All
users would probably agree that the ideal situation would be to prevent
viruses from continuing to infect, and the next most ideal would be to
identify those areas that have already been infected.
Let's examine where the above-mentioned methods fall:
Method Detection discussion
| Check-summing and integrity checking |
Both methods store information about (hopefully)
uninfected files in a certain place. Checks against the current status
of the files and the stored information are performed periodically. If
any change is detected, then a warning is issued. This method provides
after-the-fact detection. |
| Heuristics |
This is a method of analyzing files and boot
areas in a general sense to determine if the code appears virus-like. Heuristics
perform after-the-fact detection. |
| Decoys |
This is a method of lying in wait for viruses,
allowing certain files to become infected if a virus is present. Decoys
detect viruses as they are infecting and are helpful in raising the warning
flag. |
| Behavior blocking |
This is a method of analyzing the behavior
of all computing actions to determine if the sum of the parts adds up to
a virus-like action. If so, then the action is stopped before infection
can occur. Behavior blocking performs before-the-fact detection. |
| On-demand and scheduled scanning |
This is a method of scanning for specific viruses
at certain times. This is always an after-the-fact detection. |
| Real-time scanning |
This method also uses scanning, but the detection
process occurs while other computer processes occur, such as copying a
file. As a result, users are notified of existing viruses before they can
be triggered. |
As you can see, there is no single solution that meets all your virus
detection needs. We therefore suggest that you combine these methods to
best suit your needs, and follow them up with removal routines.
The subject of removal is similarly complex. Some people have a narrow
definition of virus removal -- if you delete the file or format the hard
drive, the virus is no longer there. Please note, however, that such drastic
measures are not often necessary, and that it is much healthier to define
removal as removing the virus code and leaving behind a usable file and/or
boot area.
Some of the detection methods listed above can also perform removal
(as defined the "healthy" way):
Method Removal discussion
| Checksumming and integrity checking |
Can remove viruses. |
| Heuristics |
Sometimes can remove boot viruses. |
| Decoys |
Cannot remove viruses. |
| Behavior blocking |
Can remove viruses from memory and boot viruses
from floppies. |
| On-demand and scheduled scanning |
Sometimes can remove viruses. |
| Real-time scanning |
Sometimes can remove viruses. |
Please read on for an overview of what Norman Virus Control products
can do.
Norman Virus Control Products
Because Norman Data Defense Systems realizes that no single anti-virus
detection method addresses all your needs, our anti-virus products provide
a wide range of solutions that are available for DOS, Windows, Windows
95, Windows NT, OS/2, and NetWare.
We know that the hardware and software combination in organizations
is mostly heterogeneous, and therefore we have designed our anti-virus
products to coexist on these platforms and to send virus alert messages
over the network, both via SNMP traps and NetWare messaging.
Product name Solutions provided
| NVC for DOS/Windows |
Smart behavior blocking
Integrity checking of system areas
Decoys
On-demand and scheduled scanning
Removal
SNMP trap messaging
NetWare messaging |
NVC for
Windows 95 |
Smart behavior blocking
On-demand and scheduled scanning
Removal
SNMP trap messaging
NetWare messaging
|
NVC for
Windows NT |
On-demand and scheduled scanning
Removal
SNMP trap messaging
NetWare messaging
|
| NVC for OS/2 |
On-demand and scheduled scanning
Removal
SNMP trap messaging
NetWare messaging
|
| NVC for Word |
On-demand scanning and removal of Word macro
viruses |
| NVC for NetWare |
On-demand, scheduled, and real-time scanningon
NetWare file servers
SNMP trap messaging
NetWare messaging
|
For more information, please contact your nearest Norman dealer or Norman
Data Defense Systems directly.
1
Steve R White, Jeffrey O Kephart and David M Chess, `The Changing Ecology
of Computer
Viruses' Proceedings of the Fifth International Virus Bulletin Conference,
Brighton, UK, 1996.
|