Copyright Robert M. Slade, 1990, 1991, 1992, 1993, 1994, 1995
ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 RSlade@cyberstore.ca
The following articles and recent antiviral product reviews are
included here:
I am quite certain that the first question to do with "anti-viral" or other
data security packages will be "which one is best?" This ignores two vitally
important points. The first is that "the best" may not be good enough by
itself. No security force would ever pick "the best" guard, and then leave him
to guard an entire refinery by himself.
The second point is that, even within the limited realm of anti-viral programs, data security software operates in many different ways. Thus, one type of security may be better in one situation, while another variety may be better in a different environment. (Which make better guards, dogs or men? Wise security firms use both.) There are basically five "classes" of anti-viral packages; activity monitors, change detection software, operation restricting software, encrypting software and scanners. Each type has it's own strengths and weaknesses.
Before going into detail on the specific types of programs, I would like to address some issues which can be applied to reviewing any antiviral software. Aside from the specific efficacy against large numbers, and certain types, of viral programs, there are considerations of "user" aspects of the system in question. This does not relate solely to the chimera of "user-friendliness", but to the fact that a given system is intended not only to be somehow effective against viral programs, and must be used by a "user population" in a given work, social and technical environment.
It is very easy to "rank" antiviral software on the basis of how many viral programs or strains that it will identify. It is not quite as easy to assess many other, more important, features. Although there may be more than 2000 different strains of viral programs in the MS-DOS "world" (fewer in the other environments), one percent of that number are likely responsible for ninety nine percent of infections. Thus it is of far greater importance that, for example, one particular antiviral program does not prevent infection by the "Stoned" virus (as of this writing the most common virus), than that it "protects" against literally thousands of others.
Also of very high importance is the fact that the proportion of computer users who have a thorough understanding of viral operations in comparison to the total user population is so small that it is statistically insignificant. Therefore, it is vital that any antiviral program be judged on the basis of installation and use by "naive" users. A "naive" user in this case may be one with significant technical skills, but little background in regard to viral programs.
(I realize that my statement regarding the naivete of computer users may be extremely controversial. Recall, however, that there are about one hundred million users of MS-DOS, and then compare that with the number of people who take an active interest in prevention of computer viral programs. Note that less than a quarter of computers have any defense against viral attack. Note a "clipping file" covering 30 general computer industry periodicals over a period of two years with only eleven articles on computer viral programs. Note also the very high sales of some highly publicized programs known by the virus research community to have very definite shortcomings.)
It is critical, therefore, to judge the interaction of the program with the user. Again, this interaction is not simply the presence or absence of a menu, but the total intercourse between the program and the user, by way of the documentation, installation, and user interface and messages. It is important to note how the total package "comes to" the user. Given that the user's system may already be infected, what can the package do to remedy the situation? Also, while the package may have significant strengths if installed correctly, is the "normal" user likely to be able to do the setup and installation properly?
Part of the assessment of the user is the user environment. This aspect covers not only the "corporate culture" (eg. home user, user in a large corporation with internal support staff, etc.) but also the operating system environment. For example, the MS-DOS environment has a very large number of viral strains, with more being produced every day. The Macintosh environment has relatively few viral programs. Therefore, "generic" identification of "new and unknown" viral programs is more important to MS-DOS users than to Macintosh. (Interestingly, while Macintosh antivirals are quite mature, and protected Macintosh systems have a negligible infection rate, the infection rate on unprotected Macs is astronomical. This, too, should be taken into account.)
Related to the interaction of the user and the program is the potential negative impact of the security program. Antiviral programs consume time and disk space, and may also interfere with the normal operation of the computer system. As Jeff Richards' first law of data security has it, you can guarantee security if you don't buy a computer. It's just not a very useful alternative. Computer systems can be secured more and more by restricting the operations more and more, but restriction of "dangerous" operations also restricts useful ones. There comes a point at which the trade-off for greater security becomes more than users want to pay.
There are other factors that contribute to the value of antiviral software that can be judged on the same basis as any other software. To turn, however, to the specifics of antiviral software, there are :
It is, however, very hard to tell the difference between a word processor updating a file and a virus infecting a file. Activity monitoring programs may be more trouble than they are worth by continually asking for confirmation of valid activities. They also may be bypassed by viri that do "low level" programming rather than using the standard operating system "calls".
It is very difficult to specify, in advance, what you should check for in activity monitoring software, since the developers are loath to state, in specific detail, exactly what the program will be checking for. (This reluctance is understandable: if a developer "advertises" exactly what the product checks for, virus or "trojan" writers will simply use another route.) Activity monitoring software should be thoroughly tested in a "real" working environment (one that uses all the programs you normally do, in the ways you normally use them) for some time in order to ensure that the vaccine does not conflict with "normal" operation.
While activity monitors have a good chance to detect viral activity of "new" and unknown viral strains, it would be very difficult to agree with those that claim to be able to detect "all current and future" viral programs. While it might generally be held to be a "good thing" to prevent changes to the file allocation table, it is unlikely that FAT or "system" viri could have been foreseen prior to the existence of the "DIR" family. Activity monitors are also unlikely to work well against "companion" type viral programs without specific safeguards in place.
The disadvantages of this system are 1) it provides no protection, but only notification after the fact, 2) some change detection software is limited to operating system software only, 3) you must "inform" the software of any changes you make in the system and 4) change detection software may not "see" changes made by "stealth" viri. Some versions of this software run only at "boot time", others check each program as it is run. Some of these programs attach a small piece of code to the programs they are "protecting", and this may cause programs which have their own change detection features, or non-standard internal structures, to fail.
A major factor in judging change detection systems is that of installation and operation time. Since the system will be calculating "signatures" of all (or all selected) programs on your system (sometimes with very sophisticated algorithms), it may take some time to install, and to "re- install" each time you make a change to your system. It may also take an unacceptable amount of time to check out a program before it will allow it to run.
You should also find out how and where the security system will "store" the necessary program signatures, particularly if you run programs from diskette. Also, since these types of systems are heavily influenced by the mini- and mainframe data security community, it is important to query whether they have made provisions for checking for boot sector viri, or other viri that may not show up as changes to program files.
A sufficiently advanced change detection system, which takes all factors including "system" areas of the disk and the computer memory into account, has the best chance of detecting "all current and future" viral strains. However, change detection also has the highest probability of "false alarms" since it will not know whether a change is viral or valid. Addition of "intelligent" analysis of the changes detected may assist with this failing.
However, the more options these programs allow, the more time they will take to set up. Again, the program must be modified each time you make a valid change to the system, and, as with activity monitors, some viri may be able to evade the protection by using low level programming.
It is important, with this software, that the operator is given the option of "allowing" an operation. It is also important that the operator be informed, not only that a particular program or operation should be halted, but also why. There should not be too many "false alarms" generated by the software, and it would be helpful to have the option of "tuning" the software to be less, or more, sensitive to a given type of activity.
Again, there is the need to do a lot of work in setting up the protection system, and keeping it up to date when you make changes. (It is also possible, if the system is not configured properly to begin with, to end up with a system that you cannot use and cannot repair.) There are two major "holes" in the security of the system, 1) some part of the system must remain "unencrypted" and is therefore vulnerable to "attack" and 2) if you start with already infected files, the system will quite happily encrypt the virus and allow it to operate.
One vitally important feature to consider in encrypting software, particularly if it is coupled with operation restricting software, is the ability to recover if anything goes wrong. Do you have a recoverable backup, or are all your backup files encrypted, and useless without the proper code? Can you boot off a floppy to recover if your "security" program dies? If you can boot off a floppy, what provisions guard against boot sector viri?
Why then, with all the disadvantages of scanning software, are they the most successful of anti-viral packages? Generally speaking, it is because they force the user to pay attention to the system. Again, when a user relies on one particular method of protection they are most vulnerable.
Scanning software should be able to identify the largest possible number of viri, and should be able to identify variations on the more important sections of code (that is, it should be able to "accept" the removal of text strings and other simple modifications that "bush league hackers" might make.) (Note, however, the proviso that it is more important to identify some viral programs than others.) For ease and speed of updating, the "signatures" should be stored in a separate file and there should be a means for the addition of new viral signatures to the file. For security, both scanning software program and signature files should be renameable.
Areas scanned should include not only the identifiable program files, but all files, if necessary. Scanners should have the ability to search the more common archiving formats as well, particularly those that support "self extraction" functions. Disk boot sector and hard disk partition boot records should be scanned, as well (in this day of stealth viri) as memory.
A recent addition to scanners is intelligent analysis of unknown code, currently referred to as "heuristic" scanning. More closely akin to activity monitoring functions than traditional signature scanning, this looks for "suspicious" sections of code that are generally found in viral programs. While it is possible for normal programs to want to "go resident", look for other program files, or modify their own code, these are tell-tale signs that would help an informed user to come to some decision about the advisability of running or installing a given "new and unknown" program. "Heuristics", however, generate a lot of false alarms, and may either scare novice users, or give them a false sense of security after "wolf" has been cried too often.
Scanners, as noted above, are the easiest of antiviral programs to "rank".
It is much more difficult to determine the utility of those types of programs
which purport to protect against unknown and "future" viral programs. It is,
indeed, impossible to judge these programs against any "absolute" standard:
they will be judged by future events, and the future isn't here yet.
Many future viral programs will follow the patterns of those from the past. Most "new" viral programs are very simple modifications of existing ones. However, while it may be possible to foresee some of the potential "loopholes" that viral programs might use, it is impossible to know which ones actually will be used. It would also be excessively difficult to protect against all of the myriad potential means of attack.
(When all the viral programs we had seen were either boot sector infectors, or prepending, appending or overwriting file infectors, "companion" and "system" viri came as quite a shock to most. While I have some nifty ideas for new "hiding places", I will undoubtedly be surprised by the new ones that, in reality, get released "into the wild". Fortunately, many of the virus authors must also be surprised at how poorly their "new creations" do, but this doesn't make the assessment of "generic" antiviral software any easier.)
Antiviral software should be tested against a suite of current viral programs. It is useful to know how well programs may rank in "numbers" tests, but it is likely more important to choose "representative" viral programs. Choose the most common viral infectors (which tend to vary somewhat, geographically), as well as representatives of viral "types": boot sector infectors, MBR infectors, "stealth", multipartite, polymorphic, resident and non-resident and so forth. However, since this does not include any representation from "future" viral programs, it is also very useful to try to do "odd" things with utility programs, to try to "simulate" attacks that have not yet been incorporated into existing viral programs.
Evaluation of antiviral software requires at once the most complex of technical assessments, and at the same time the greatest attention to human factors engineering. While the interactions of viral and antiviral at the lowest levels of the operating system is fascinating, always remember that what is really being protected here is the user. Any antiviral program, in order to be considered at all successful, must primarily inform the user accurately and realistically about any threat to the system. It must also be sufficiently easy for the user to install and maintain. The most technically advanced security system is of absolutely no use if the user cannot run or understand it.
I have recommended the manual installation. The installation program provided is simple and quick, and I can see no problem with using it. However, the full advantage of this product is not, and probably cannot be, provided with an automated installation.
There are a number of command line options for use with the various programs when not using the TOOLKIT interface. The defaults are well chosen, and should be appropriate for most situations, and for novice users.
For situations where client support is available, the message generated by VirusGuard on detection of a virus can be customized to direct the user to the local security support person.
The package now has the ability to scan "inside" archived and compressed files, although this is not enabled by default.
NetWare and OS/2 versions are also available. Mac, NT and Windows 95 versions are in development.
The TKUTIL program can remove references to CPAV, MSAV and NAV in startup files. Normally I would deplore a hostile action against a competing antiviral product, but I'm not sure that principle applies here. The action is not taken by default, and the user must find the refernce in the manual and specifically request the action. Also, these products have given such a high rate of false alerts that many antiviral researchers recommend against their use.
The ongoing upgrade programs provided should be very strongly considered in the case of this package.
Therefore, this package is highly recommended for use by advanced users, who are willing to make the commitment to study the material provided. The package is recommended for novice users where local support is available.
The user is in charge of the operation at every point, but not always given much information. There is, for example, the option to install for either DOS only or DOS and Windows operation. It is not clear from the documentation whether the Windows installation also installs the DOS files (it does).
The earlier VIRSCAN did not suggest installation on the hard drive at all. In opposition, Antivirus/DOS must be installed on a hard disk, and only one operation is stated to work in the absence of a hard disk. This does allow for "offline" signature scanning. There is also a set of files for a "stand alone" scanner.
While the documentation talks of "fuzzy" and "heuristic" systems, details of operation and options are not given. This does prevent "false alarms" being presented to the user, but may allow viral changes as well. This is good in that is does not require much in the way of knowledge from the user, but there is no option to provide the information for those more capable.
Whether from faulty diskettes or damage in shipping, my own copy had defective gates on two of the three 720K disks. This was not evident until I tried to remove the diskettes from the drive, when they jammed. This could cause a trip to the shop to get the diskette removed, or, at worst, damage to the disk drive.
The material provided is generally accurate, and very well written. New contents provide better general background to the virus situation, but still show some minor errors, such as the date of the first known virus.
The package will now scan PKZip and LZEXE format compressed files.
In the automated installation, VIRSTOP is installed to be invoked from AUTOEXEC.BAT. Those wishing to invoke it from CONFIG.SYS must do the installation manually.
Because of an external language file, F-PROT is available in at least eighteen languages, and can be readily translated into others. (The additional language versions are primarily available from Data Fellows.)
The heuristic analysis portion of the program occasionally generates a "false positive" alert about a program that is not, in fact, infected. This is to be expected from this type of scanning, and the incidence is much reduced from when this function was first included with the program. The heuristic analysis feature has been generally effective in identifying new and "unknown" viral strains, but is not perfect. (Perfection is, of course, inherently unattainable in this type of program.) Indeed, the documentation for this feature states that it is still to be considered experimental, and is very conservative in its claims. Programs known to cause false positives are listed.
The program now has a specific Windows interface, as well as a resident scanner specifically built for the Windows environment (to address problems of scanning for polymorphic viral programs in that environment).
The user is in control of F-PROT at all times, with the exception that VIRSTOP will not allow the boot sequence to continue in the case of a boot sector infection at startup.
F-PROT, in six years of my testing, has not given a false positive alarm on any normal program, nor has it interfered with any normal program operation. This is not to say that it doesn't: there are many reports of false positives and Fridrik Skulason usually puts out a notice as soon as he confirms such reports. These reports, and those from users, have significantly reduced over the past year, indicating a very stable and reliable product.
The change detection file is now renameable: a minor security weakness in previous versions. Additional strength may be obtained by running the program from a locked floppy disk.
Network installation assistance is provided in the installation program.
The "Advanced scan" and "Auto-inoculate" features of the system are simply variations on checksumming and change detection, but are set up and explained in a manner which appears to be unnecessarily confusing. The options available in the "Options/Configuration" menu allow for a considerable degree of customization, but reasons for choosing certain options are not clearly explained in the initial installation section of the manual. Some options do not appear to work: I did not chose to "Disable scan Cancel button" (b being the letter used to access this option), but the "cancel scan" option was disabled on my program anyway.
If a virus is detected in memory at the beginning of a scan, the program will refuse to scan further. This is an advantage in that it prevents infection by viri which infect each file as it is open, but there is no "discretion" on this feature, and it activates even when boot sector viri are found. The program does not terminate, but will not perform (in terms of scanning). No help is given at this point: the user is referred to a section of the manual.
The distribution of updated signature files has been problematic. Initially they were available only from the Symantec BBS or on CompuServe, where Symantec runs a support forum. Offers of space on other systems were turned down. Subsequently, a Symantec representative stated that update files could be distributed via BBSes, at the same time that other agents were saying that this was a violation of copyright. At one point a demo version of the program was stated to be available on "hundreds of bulletin boards worldwide." This was later found to refer to the Symantec BBS and CompuServe only. Most recently permission has been granted to distribute the update files from ftp sites on the Internet. However, no announcements of availability were made and the future of this distribution is completely unknown.
It should be noted that although the initial program was promised to the reviewer, that it required eleven return phone calls to five different offices to finally have it delivered over three months later. Other shipping was similar, although most recently the package was the fourth to arrive after a general call for review materials.
The series of acquisitions by both Symantec and Central Point means the company has absorbed a significant group of antiviral software vendors. This represents more than a dozen products which have been removed from the market or had support withdrawn. The buyouts appear to have been done soley to gain market share. Less than a month after the company had been purchased, callers were being told that the product support for Fifth Generation products had been discontinued, and were offered "upgrades" to NAV. To date, only one of the technologies of the "orphaned" products has been added to the Norton AntiVirus.
Repair of viral programs appeared to be effective on those few for which this is an option. However, the major option tends to be deletion.
Two features deserve special note. The changes made to the AUTOEXEC.BAT file are stored in a file called AVAST!.NEW. This requires that the file be renamed in order to replace the original, but it shows a welcome respect for the user. The other is a de-installation procedure for removing the Windows programs.
A query regarding installation of the Windows components of the package is possibly misleading: you still have to run AVINST in order to have the Windows portion of the program run properly. The only change made to my AUTOEXEC.BAT file was to add the AVAST directory to my PATH. (Twice.) The resident programs were neither added to the AUTOEXEC file nor to any Windows groups, including "Start Up". Initialization of the Windows portions seemed to create some difficulty with invoking Windows in enhanced mode, and the Windows programs would not load and execute, requesting more memory on an 8 meg system. (According to the authors, this should not be the case.) The "de-installation" function of AVINST appeared to work perfectly.
Scanning detection does not rank with the best available software (although is not far behind) and disinfection is limited to the most commonly found viral programs. The scanner can detect internally infected compressed executables, but does not check inside archives.
Having said that, technical support staff will find a number of helpful functions for customizing installation, and for aiding installation in sites with many PCs. Both "Master" and "Network" options assist in initiating the program on mulitple PCs in a corporate environment.
The installation process is very "careful" and should ensure that no virus contaminates the program.
Installation is possible on systems with no hard drive, but some of the installation functions, such as modification of AUTOEXEC.BAT, are not performed.
Scanning is among the fastest reviewed, and ranks with Thunderbyte and Virex-PC.
Unfortunately, the program has not been included in many of the most widely distributed independent scanner trials. My own tests do not indicate any shortcomings in the scanning coverage of the program.
I received also a version on disk from the developer on a 1.44M unwritable diskette. If a shareware author can do this, there is no excuse for the commercial operations.
Calling SETUPIM an installation program is misleading. It is less than an installation program -- and much, much more. For the novice user, SETUPIM has some of the most "user-friendly" features of any product yet reviewed. It certainly has the best explanations of the antiviral process and the options for security of any installation program.
Although the program and system, overall, is well designed and has advanced in respect of virus detection technology I was quite surprised to note that the installation procedure has not fixed some earlier bugs.
While there is provision for installation to a drive other than C:, there is no option to change the default installation directory.
The programs (both IM and SETUPIM) have a command line switch that "forces" monochrome mode with a monochrome monitor on a "colour" adapter. This is important, since some of the menu "highlighting" is invisible on a monochrome monitor. The programs can change to monochrome in "mid-session", so it should not be difficult to add a short "screen test" for the completely novice user, rather than making them use the command line option. (This applies only to SETUPIM: a proper installation will tell IM which video mode to use.)
(If IM is invoked before SETUPIM is run to create the parameter file, IM will refuse to run. Three options are presented, including "Abort" which is described, with an unusual lack of clarity, as "Quit and return".)
The SETUPIM program prepares a parameter file for use by IM (which sets up the various options for running the integrity checks), and produces a suggested procedure for completing the installation, but it does not actually do the copying and placement of files, or the invocation of the initial "signature" calculations. While readily admitting the value of having a "cold boot" before this is done, it should be possible to do some more of this for the novice user before turning him loose with a (softcopy) instruction set. Alternately, the installation program could strongly suggest that a "cold boot" and other security measures are desirable, but offer to proceed with installation if the user desired, on the clear understanding that this is "second best". (This approach is taken with some of the options during the setup.)
This is not to say that the instructions in the IMPROC.TXT (the suggested installation procedure document file produced by SETUPIM) are in any way inadequate. The instructions are clear and straightforward. The file is displayed to the user at the end of the SETUPIM part of the installation process, and the user is given the command to invoke the IMVIEW file viewer in order to review the file later, or the IMPRINT batch file in order to print it in hardcopy. (The IMPROC.TXT is unclear at one point, the one where almost everyone seems to fall down. The document contains the injunction to "cold boot" the computer, and it is probably not clear to the novice user that this does not mean to do it "right now".)
The SETUPIM program also contains a tutorial. Both the operation of the program, and the conceptual aspects of virus protection, data loss and security measures are covered. This is extremely useful, and the only problem I have with it is to wish that some more of the material from the documentation could be included.
The installation procedure does not address installation of IM in the AUTOEXEC.BAT file, although use of scheduling software is mentioned in places. The installation process does, however, suggest the preparation of a bootable disk with IM files on it for recovery purposes. If the installation process is interrupted, a screen message suggests the option of installing via the Windows program, IMWIN. While this does set up a Windows program group, one of the items in the group must then be chosen in order to complete installation.
At a couple of points during installation the user can be left staring at a screen and possibly wondering if he did something wrong. (The amount of time this takes, however, varies widely depending upon the speed of the machine.) The program noted that there was no boot sector on my boot drive since it reads the sector with an interrupt which conflicts with LANtastic server software. At times, the program is stepped (or "timed") through a sequence which begins to suggest the possibility of an infinite loop. (The "timed" stepping is probably a good idea here; some users may give up before it reaches the conclusion.) The tutorial, at certain points, requests specific keystrokes but accepts anything, not a pedagogically sound design. Some minor keystroke "trapping" and a "please press the arrow key, you can practice later" message would improve it.
The GUI, windows and menus are here used as they are meant to be in order to make the program useful and quick to operate. Not only is the label and option wording well chosen, but each item, as it is selected, pops out a window with extra explanation about what it does. Often the window will contain a brief, but clear, discussion of the pros and cons of using this particular option.
However, the explanatory "window" beside each selected item seems to largely obviate the need for any kind of help system. (On items where the explanation could be confusing, for example the "Files to iNitialize" options, the help index is of little assistance, and one would need recourse to the manual. The index is, however, very extensive, even covering what the AUTOEXEC.BAT file is, although with less detail than a novice would need in order to automate checking.)
(Note that ASG, the pay-per-callnumber, is completely independent of Stiller Research. Stiller Research does not receive any of the charges for support provided through ASG.)
The documentation as a whole has a "technical" flavour, but is clear and unambiguous. The intermediate user should have no problem with the first section, but might be well advised to read section two first, in order to have a clear grasp of the reasons for the various options IM offers.
Section two's overview of viral programs and other risks to data contains excellent information. It could form the basis of a very useful primer on data integrity as a whole.
(With all the information presented onscreen each time an option is selected, it is remarkable that IM is extremely responsive.)
The storage of "signatures" is a matter of much debate. IM stores them in each directory checked. There is, however, provision for storage of the signature files on an "offline" diskette, which adds a security factor.
IM's virus scanning picked up all common viral programs tested against it, and a good many that were less so. Some new viri were detected on the basis of similarity to known code.