This list of questions is intended to provide a framework and background
information for review, evaluation and decisions regarding antiviral
protection software and systems. The latest version of this file may be
accessed online via the Web at Victoria Freenet. The companion files
Antiviral contacts listing (CONTACTS.LST) and Quick reference antiviral
review chart (QUICKREF.RVW) provide additional related information. All
three files are available in the Computer Virus SIG of the Victoria (BC,
Canada) Freenet (telnet://guest@freenet.victoria.bc.ca and give the command
"go virus"). (This file is prepared from Chapter Six of "Robert Slade's
Guide to Computer Viruses".)
This document is not intended to be an introduction to the study of computer viral programs. It is expected that you already know the relevant concepts and terminology. For general background information on computer viruses, please see the VIRUS-L/comp.virus FAQ (ftp://ftp.cs.ucr.edu/pub/virus-l/vlfaq200.txt) which is also available at the Victoria Freenet site.
This document is now maintained in minimal HTML format.
A more rigorous explanation is found in Fred Cohen's ground breaking work on the theoretical study of computer viruses between 1983 and 1986. Using mathematical and logical models of the nature of computers and computation he determined that the problem of accurately identifying a viral program, as opposed to one which is not viral, is "undecidable". A program to identify computer viruses will always have the possibility of making errors either in failing to identify viral programs (false negative), or in falsely accusing a valid program of being viral (false positive), or both.
However, if you do your homework, you can get very solid protection.
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. There are basically three "classes" of anti-viral packages: activity monitors, authentication or change-detection software, and scanners. Each type has its own strengths and weaknesses. (Note that most commercial antiviral programs have a combination of functions.)
The final point is that security, of every type, is always a "moving target," and the virus world moves faster than most. Not only are new viral programs being written every day, but new types of viral functions are being coded all the time (albeit at a much slower rate than the run-of-the-mill copycat virals). Any antiviral program developer who purports to "guarantee" protection against "all known and unknown" viral programs simply does not comprehend the reality of the situation.
A minor variation on activity-monitoring software is operation-restricting software. Instead of watching for suspicious activities, it automatically prevents them. The difference between a "monitor" and a "restrictor" is really only one of degree in the information given to the user. Most general microcomputer security programs use operation restriction.
Heuristic scanning, despite the name, has much in common with activity- monitoring. A heuristic scanner looks not for signatures of a specific virus, but for code which performs suspect activities.
Activity monitors represent some of the oldest examples of antiviral software. Generally speaking, such programs followed in the footsteps of the earlier anti-trojan software, such as BOMBSQAD and WORMCHEK in the MS-DOS arena, which used the same "check what the program tries to do" approach. This tactic can be startling effective, particularly given the fact that so much malware is slavishly derivative and tends to use the same functions over and over again.
Activity monitors may also be bypassed by viral programs that do low-level programming rather than using the standard operating system calls, or those that actually replace the standard system calls with viral triggers. In addition, while new viral technologies, such as stealth and polymorphism, have little effect on activity monitoring, new concepts in viral spread, such as companion or spawning viruses require new checks to be added to monitors.
Activity monitors have a good chance to detect viral activity of new and unknown viral strains, but it would be very difficult to agree with those that claim to be able to detect "all current and future" viral programs. Unfortunately, activity monitors tend to encourage a set-and-forget mentality toward viral protection. This attitude should be avoided at all costs. If activity-monitoring software is your protection method of choice, continue to keep up-to-date with viral methods and to test your software regularly.
As with mainframe security "permission" systems, operation-restricting packages allow you to restrict the activities that programs can perform, sometimes on a file-by-file basis. However, the more options these programs allow, the more time they will take to set up. The program must be modified each time you make a valid change to the system, and, as with activity monitors, some viral programs may be able to evade the protection by using low-level programming.
Activity monitors do not provide disinfection functions. (A possible exception is "heuristic generic" disinfection.)
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 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.) In addition, the work or computing environment must be considered, as well as, in certain cases, the corporate climate. Activity monitors, more than scanners or change detectors, are subject to review on the basis of political rather than technical grounds.
Activity-monitoring software should be thoroughly tested in a real working environment (one that uses all the programs you normally use, in the ways you normally use them) for some time in order to ensure that the vaccine does not conflict with normal operation. This "real" environment includes the "real" people who will be using the software: choose your sample population carefully and avoid simply giving it to the tech support office to test. Two important factors to check for are the number of false positives (or false alarms) that the software generates and the level of information given to the user when an anomalous condition is detected. This last is difficult to judge: user populations that tend to remain at the novice level will not have more confidence in the system, regardless of how much information it gives them.
Monitoring programs should be tested against a battery of viral programs, but the test suite should be collected on the basis of function rather than simply diversity. If the activity monitor is effective against Stoned, then Empire, Michelangelo, and Monkey variants are unlikely to trouble it.
Change-detection software is also often referred to as integrity-checking software. It does check the integrity of the program in terms of alterations, but shouldn't imply that the program will be functional or useful. Authentication properly refers to strong encryption systems which both guarantee that a program is unaltered and identify its source. Change detection can be seen as a weaker version of authentication.
Change-detection software provides no protection, but only after-the-fact notification of an infection. It is, therefore, quite possible to install an infected program on your system and have it continue to infect other programs. The subsequent infections will (or should) be detected, but the change-detection software will not identify the original culprit. (Deductive reasoning, along with the software's assistance, though, may.)
You must inform the software of any changes you make in the system, otherwise the change detection software will generate a false alarm. This means you must have sufficient knowledge of the system to know when you are making changes. Each invocation of SETVER, for example, changes the program file, whereas setup changes made to WordPerfect sometimes alter the program file and/or change an external data file.
As with scanning software, change-detection software may not see changes made, and hidden, by stealth viral programs.
A major factor in judging change-detection systems is 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 update each time you make a change to your system. It may also take an unacceptable amount of time to boot or to check out a program before allowing software to run. You may find that a change-detection system with a "weaker" calculation algorithm is more effective for your situation given the time savings.
The answers to these questions should actually be available to you in the documentation. You shouldn't need to run the program to test it out. Unlike activity-monitoring software, there is no need for the producer of change detection-software to hide anything from either you or virus writers. A truly complete change-detection package is unbeatable (dependent, of course, on a "clean start") and does not require any hidden "tricks." A package with documentation that does not answer all of your questions suggests lack of confidence on the part of the author, and possible weakness in the program.
Note that the above is presuming that you are protecting a single computer or a local office. Change detection has other uses, including authentication of material sent via email or retrieved from an archive site. The calculation algorithms used in those situations must be much stronger. Delays of mere seconds caused by trying to "crack" protection will be detectable locally: it would be no problem to spend weeks or months cracking the security of an archived file.
Scanners can only find infections after they occur, but that does not mean that scanners cannot play a preventative role in protecting the system. If scanning software is used consistently to check each disk or file that enters a system (and kept up to date), the chance of a viral infection being allowed to enter is greatly reduced.
Areas scanned should include not only the identifiable program files, but all files, if necessary. (This has become much more important recently with the advent of successful Windows viral programs coincident with the Windows "embedding" function, and also "macro" viruses.) 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 as (in this day of stealth viruses) memory.
Identification and naming of viruses can be important when you want to ask for help or use one of the various computer virus references. A scanner should use the CARO naming conventions as far as possible.
Speed of operation is a consideration when running scans manually or at boot time every day. However, while speed can vary greatly, this is less of a concern with modern higher speed computers. Even relatively slow scanners may take less than a minute to complete a full scan.
The term resident refers only to this background mode of operation. All three types of antiviral software may be run in this fashion. Classic activity monitors always run resident, since they must always be operating while other programs are, in order to check on different activities. Change detection software may be run resident so that it can check programs being started against the initial data base. Scanners may be run resident in order to quickly check each program for virus signatures as the software is started. Resident antivirals may combine two, or all three, types of antiviral checking.
This field is really the application of "expert systems" to antiviral software: an "expert" antiviral disassembler is checking the code for you. Along with hoped-for advances in change detection, this bodes well for the future of antiviral software. Indeed, not only will it identify suspect viral programs, but, with only minor additions, trojans and other malware as well.
Heuristic scanners are currently tools best used by those with some background in virus identification and prevention, but they hold promise to become very useful tools, even for the novice, with future development.
Failing that, disinfecting software will contain a description of the specific viral operation of a given viral program, so that the infection process can be reversed. You have to know what a virus changes, and how, in order to change the object back to the way it was. Scanner developers have to examine the virus code, so they have an advantage in knowing how the virus works, and it is scanners which usually have disinfection modules.
In some cases the file or disk sector cannot be returned to its original state by this method. Viruses that overwrite sections of code leave no means of recovering the original material.
There are a number of cards which act as write protection for the hard disk. It would be nice (as well as a lot cheaper) to have a hard disk controller card with an external write protect switch. (Those who have removable media drives have an advantage: the cartridges usually have write protect tabs or toggles.)
Some cards, or chips for LAN cards, provide extensions to the ROM BIOS. These extensions generally prevent booting from the floppy drive, and usually do some checking of the memory and interrupts. Some of them may also call software antivirals at boot time.
There was an activity monitoring and operation restricting system built on the Western Digital 7855 system controller chip. A number of computer vendors announced plans to build computers built around the system. To date I have not seen any that were actually produced.
In addition, antiviral programs which have loopholes may themselves become sources of antiviral spread. Antiviral programs are programs like any other, and must have special protection built in to ensure that they don't become infected. Antiviral scanners also must "open" the files they are checking. Viruses often infect "on file open", and if such as virus is active in memory and remains undetected when a scanner sweeps the disk, it is possible that all files on the disk may become infected.
Finally, any weaknesses in a particular piece of antiviral software tend to be subject to attack from the virus writing community. In the case of one particularly widely distributed antiviral program, it was found that only a few bytes of machine code would turn off the resident module. This code quickly became a standard feature of new viruses.
Also of very high importance in testing antiviral systems 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.
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 or GUI (graphical user interface), but the total communication between the program and the user, by way of the documentation, installation, 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?
Remember that for the seeming simplicity of some programs, antiviral software is still a part of computer security. Security is not now, has never been, and never will be obvious to the majority of the population.
Part of the assessment of the user is the user environment. This aspect covers not only the "corporate culture" (for example, is this computer being used in the home, a small business office, by a 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.)
An antiviral program, therefore, must be matched to the environment in which it is to be used. In a "low risk, low change" situation, such as a word-processing office, change-detection software provides very effective protection, without too much interference with operations. In a "high change" milieu, such as a software development team, change-detection software is less useful against viral programs, although it has other helpful features. In a "high risk, multi-risk" environment such as a college computer lab, operation-restricting software may prevent not only viral infection, but may help to "idiot-proof" the computers as well.
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. You can guarantee security only if you don't buy a computer. 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.
However, strange as it may seem, antiviral and security software may actually do as much damage as viruses themselves. Some systems fail to prevent infections but prevent the user from getting rid of the virus. Some systems actually delete files without informing the user. Disinfection has been known to leave the computer in a worse state than the infection did. Perhaps, then, this should be the ultimate decider: first, do no harm.
The LAN antiviral seems to be something of a growth market with almost everyone bringing out an NLM version of their product. NLM stands for NetWare Loadable Module, and will only work with Novell NetWare. Network management is always a problem, particularly with antiviral software which requires constant updating. However, these advanced network systems really only provide a simple set of functions. Email is used by some of the specialized LAN antivirals to alert the administrator to a security breach or possible infection. This can be duplicated on almost any network. The same can be said of "centralised" logging of scanning and audit reports, updating of scanners, enforcement of virus checking, and a number of other supposedly advanced features. One need not accept an inferior antiviral product simply because it has LAN capabilities. Because LAN systems are more complex, it is also harder to determine the effectiveness and accuracy of such antivirals. A simple and effective antiviral which is known to work well may be more effective than a specialized LAN product, particularly when enhanced by some simple scripted functions. The same applies to Web and Internet scanners.
In a similar way, the new Windows 95/VxD products may not be as effective as more mature DOS programs. The new internal features of Windows 95 make it a more complex environment, and therefore make it much more difficult to assess the total effectiveness of security systems.
Although there may be more than 10,000 different strains of viral programs in the MS-DOS world (fewer in the other environments), it is likely that only 1 percent of that number is responsible for 99 percent of infections. Thus the choice of a "test suite," sometimes called a "zoo," is made more difficult than it might be otherwise. Certain programs are very significant in terms of danger of attack, and therefore must hold higher ranking than others.
The test suite should, however, contain a range of viral programs that are functionally distinct. A good test suite should contain programs from different categories of viruses, such as BSIs versus file infectors and MBR infectors versus BSIs. Self-encrypting, polymorphic, stealth, tunneling, multipartite, and companion viral programs should all be represented. Kami's Anti-Viral Toolkit Pro (AVP) gained a good reputation for itself by accurate detection of polymorphic viruses at a time when other antivirals were having some difficulty in that field. On the other hand, the otherwise excellent Disinfectant (for the Macintosh) has never been able to detect HyperCard or Word Macro viruses.
If at all possible, some rare, or even unknown viral programs should be included in the test suite. The assertion by some software producers that they can catch all "known and unknown" viral programs should never be left unchallenged. The only way to get completely unknown viral programs is to make them up. This is beyond the scope of most users, of course, and so it is not a realistic suggestion in most cases. In addition there is the danger of letting another beast loose in an already overcrowded environment.
The analysis of virus type and function may even be beyond the capabilities of some reviewers. Many of the problems of "numbers" reviews are much more basic than that.
The test suites for most numeric reviews now generally contain in excess of 1,000 items. Even granting that this is only a fraction of the known viruses, each of those items should have gone through a screening process. At a minimum, one should know certain things about it, such as, is it actually a virus? Does it reproduce? Under what conditions does it reproduce? Is it the same for each type of object it infects? Is it the same for each succeeding copy? When invoked, does it infect memory? It is unlikely that each of the 1,000 or more items has been tested for all these criteria.
In many cases, disinfection is simply not possible. An overwriting virus, for example, will not keep any track of the material it destroys when it dumps itself into a file. Many viruses contain bugs that prevent the recovery of the original file. Also, disinfection software has been known to contain bugs that left the situation worse after the attempted cleanup than after the infection.
The current situation with regard to computer "hygiene" is terrible. Thousands of people are "carriers" of computer viral infections--and don't know it. This is not through any malice on their part, it is simply that too few people understand the problem. During the months leading up to March 1992, no less than 15 different companies, all reputable (some major), sent out products infected with the Michelangelo virus. Computer retail and repair stores are, as of this writing, a major vector for the spread of computer viral programs. Anything, therefore, that helps to eliminate any viral programs will help the "hygiene" of the computer environment as a whole. If a company, or individual, provides materials that help keep the numbers of viral infections down, then regardless of whether you or your company actually use that service or product, that company, or individual, is helping to keep you safe. It is, therefore, in your own interest to support all such services.
The shareware version of F-PROT, in the MS-DOS world, is currently free for individual, noncommercial use. This means that you can legitimately give it to all employees for their home computers. For the Macintosh, Disinfectant always has been free. DISKSECURE and FixUTIL are both freeware, although customized versions of DISKSECURE can be ordered.
Let the buyer beware. Four major sources of antiviral reviews have all had business relationships with antiviral vendors in the past. On the face of it, this would present the possibility of a conflict of interest. (To be fair, in two cases this does not appear to have materially affected the quality of reviews.) A major computer periodical regularly prints reviews of antivirals, and those in the know realize that mediocre products with large advertising budgets regularly win.
The "Reader's Guide to Antiviral Reviews," an article by Dr. Alan Solomon (for some reason credited to Sarah Tanner) in the November 1993 issue of the Virus News International (now Secure Computing), is an excellent eye-opener. Each of the 28 points discussed is a way to skew the results to favour one product or denigrate another. Some of them strain credulity, but each is known to have been used in major published antiviral reviews. It can be read online at http://www.drsolomon.com/vircen/choose.html#7
Reviews can be found in:
"Robert Slade's Guide to Computer Viruses", Slade, 1996, Springer-Verlag (1 Amiga, 4 Atari, 34 DOS)
"Secure Computing"
ftp://cs.ucr.edu/pub/virus-l/docs/reviews/pc
telnet://guest@freenet.victoria.bc.ca (command "go virus")
http://www.freenet.victoria.bc.ca/techrev/mnvr.html
http://csrc.ncsl.nist.gov/virus/virrevws/
http://www.drsolomon.com/avtk/reviews
(This last site also has reviews from a number of computer magazines.)
The second type of virus simulator purports to demonstrate and test the effectiveness of antiviral software. In order to determine whether or not this type of simulator is of any use, you have to know both how the antiviral software works, and how the virus simulator is doing its "simulation".
To test an activity monitor, the simulator has to perform activities that a virus would. However, if the program does not perform all the activities of all possible viruses, then it doesn't really do a valid test. (You can perform virus like activities with ordinary computer utilities, if you want to do partial tests. If you do not know how to perform these tests, then you do not have the background to judge whether or not the simulator is doing a valid test.)
If the simulator does perform all the activities, even of known viruses, then it must be a virus. Letting a virus loose on your system, in the name of testing antiviral defenses, is not a smart idea. (If the virus simulator is some kind of "crippled" virus, in order to prevent spread and damage, then the simulator is not testing for true viral function, and the test is invalid.) In addition, even if the virus simulator truly is a functional virus, it is only one virus. Antiviral software that can detect it will do so on the basis of a detection of the one form of viral function used by that virus, or the one specific change that the virus makes in the system, or a string specific to that virus. This indicates nothing about the ability of the antiviral software to detect any other virus. Use of this type of simulator to test a piece of antiviral software is about as effective as diagnosing chicken pox based simply on the presence or absence of red spots.
To test change detection software, you need to be able to make changes to programs and other viral infection targets. You can do this with ordinary computer utility software. (Again, if you do not know how to do this, then you do not have the background to assess the effectiveness of a test of antiviral software.)
The most common test of scanning software is to create a file that contains a database of viral signature strings, and then to see if viral scanners detect the file as being infected. There are, however, two very major flaws with this idea. The first is that not all scanners sue the same signature strings. (Nor should they.) The second, and more important, is that if the file only contains snippets of code, then it is not a truly infected file. Therefore, scanners that detect viral infections in these simulated test files are, in fact, giving a false positive result, and therefore are demonstrating themselves to be inferior products.
Some antiviral scanners provide a test file, in order to check basic operation. These test files do not contain viral code, but do contain a string that is listed in the scanner database. When the scanner is run, or if the test file is invoked while a resident scanner is running, then the scanner will generate an alert. This is intended primarily to check for the operation of resident scanners either on a standalone computer or when access is requested for network logon (it may also be used to check for gross functioning of a non-resident scanner), and is not intended for any valuative function. A number of antiviral developers now support the use of the EICAR test file, which is a standard test file intended for the same purpose.
To make use of the EICAR test string, create a file with a .COM extension containing the following text:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*Running the file displays the text "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!".
Copyright Robert M. Slade, 1996 avrevfaq.html 961113
http://www.freenet.victoria.bc.ca/techrev/rms.html