NIST Special Publication 800-5 Guide to the Selection of Anti-Virus Tools and Techniques W. T. Polk L. E. Bassham Dec. 1992 National Institute of Standards and Technology Computer Security Division Ascii text version: No references or indices. Tables at end. Footnotes in text, following paragragh where they occur. Some references to documents or other sections within the text may be missing from ascii version! Abstract Computer viruses continue to pose a threat to the integrity and availability of computer systems. This is especially true for users of personal computers. A variety of anti-virus tools are now available to help manage this threat. These tools use a wide range of techniques to detect, identify, and remove viruses. This guide provides criteria for judging the functionality, practicality, and convenience of anti-virus tools. It furnishes information which readers can use to determine which tools are best suited to target environments, but it does not weigh the merits of specific tools. Table of Contents 1.0 Introduction 1.1 Audience and Scope 1.2 How to Use This Document 1.3 Definitions and Basic Concepts 2.0 Functionality 2.1 Detection Tools 2.1.1 Detection by Static Analysis 2.1.2 Detection by Interception 2.1.3 Detection of Modification 2.2 Identification Tools 2.3 Removal Tools 3.0 Selection Factors 3.1 Accuracy 3.1.1 Detection Tools 3.1.2 Identification Tools 3.1.3 Removal Tools 3.2 Ease of Use 3.3 Administrative Overhead 3.4 System Overhead 4.0 Tools and Techniques 4.1 Signature Scanning and Algorithmic Detection 4.1.1 Functionality 4.1.2 Selection Factors 4.1.3 Summary 4.2 General Purpose Monitors 4.2.1 Functionality 4.2.2 Selection Factors 4.2.3 Summary 4.3 Access Control Shells 4.3.1 Functionality 4.3.2 Selection Factors 4.3.3 Summary 4.4 Checksums for Change Detection 4.4.1 Functionality 4.4.2 Selection Factors 4.4.3 Summary 4.5 Knowledge-Based Virus Removal Tools 4.5.1 Functionality 4.5.2 Selection Factors 4.5.3 Summary 4.6 Research Efforts 4.6.1 Heuristic Binary Analysis 4.6.2 Precise Identification Tools 4.7 Other Tools 4.7.1 System Utilities 4.7.2 Inoculation 5.0 Selecting Anti-Virus Techniques 5.1 Selecting Detection Tools 5.1.1 Combining Detection Tools 5.2 Identification Tools 5.3 Removal Tools 5.4 Example Applications of Anti-Virus Tools 5.4.1 Average End-User 5.4.2 Power Users 5.4.3 Constrained User 5.4.4 Acceptance Testing 5.4.5 Multi-User Systems 5.4.6 Network Server 6.0 Selecting the Right Tool 6.1 Selecting a Scanner 6.2 Selecting a General Purpose Monitor 6.3 Selecting an Access Control Shell 6.4 Selecting a Change Detector 6.5 Selecting an Identification Tool 6.6 Selecting a Removal Tool 7.0 For Additional Information 1.0 Introduction This document provides guidance in the selection of security tools for protection against computer viruses. The strengths and limitations of various classes of anti-virus tools are discussed, as well as suggestions of appropriate applications for these tools. The technical guidance in this document is intended to supplement the guidance found in NIST Special Publication 500-166, "Computer Viruses and Related Threats: A Management Guide". This document concentrates on widely available tools and techniques as well as some emerging technologies. It provides general guidance for the selection of anti-virus tools, regardless of platform. However, some classes of tools, and most actual products, are only available for personal computers. Developers of anti-virus tools have focused on personal computers since these systems are currently at the greatest risk of infection. footnote: Certain commercial products are identified in this paper in order to adequately specify procedures being described. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the material identified is necessarily the best for the purpose. footnote 1.1 Audience and Scope This document is intended primarily for technical personnel selecting anti-virus tools for an organization. Additionally, this document is useful for personal computer end-users who wish to select appropriate solutions for their own system. This document begins with an overview of the types of functionality available in anti-virus products and follows with selection criteria which must be considered to ensure practicality and convenience. The body of the document describes specific classes of anti-virus tools (e.g., scanners) in terms of the selection criteria. This document closes with a summary comparing the different classes of tools and suggests possible applications. The guidance presented in this document is general in nature. The document makes no attempt to address specific computer systems or anti-virus tools. However, at this time the computer virus problem is most pressing in the personal computer arena. Consequently, most types of anti-virus tools are available as personal computer products. As a result, some information will address that specific environment. 1.2 How to Use This Document The remainder of this section is devoted to terminology and basic concepts. Section 2 describes the different types of functionality that are available in anti-virus tools. Several different types of detection tools are described, as well as identification and removal tools. This information should assist readers in identifying the classes of products appropriate for their environment. Section 3 describes some critical selection factors, including accuracy, ease of use, and efficiency. The description of each of these factors is dependent on the functional class of product in question. These selection factors are used to describe product classes in the sections that follow. Section 4 describes specific classes of tools, such as scanners or checksum programs, and the techniques they employ. This section provides the reader with detailed information regarding the functionality, accuracy, ease of use and efficiency of these classes of tools. Section 5 presents guidelines for the selection of the most appropriate class of anti-virus tools. It begins by outlining the important environmental aspects that should be considered. Next, the information from Section 4 is summarized and a variety of tables comparing and contrasting the various classes of tools are presented. The remainder of the section provides several hypothetical user scenarios. A battery of tools is suggested for each application. Section 6 presents guidelines for the selection of the best tool from within a particular class. Important features that may distinguish products from others within a particular class are highlighted. This document will be most useful if read in its entirety. However, the reader may wish to skip the details on different tools found in Section 4 on an initial reading. Section 5 may help the reader narrow the focus to specific classes of tools for a specific environment. Then the reader may return to Section 4 for details on those classes of tools. 1.3 Definitions and Basic Concepts This section presents informal definitions and basic concepts that will be used throughout the document. This is intended to clarify the meaning of certain terms which are used inconsistently in the virus field. However, this section is not intended as a primer on viruses. Additional background information and an extensive "Suggested Reading" list may be found in NIST Special Publication 500-166. A virus is a self-replicating code segment which must be attached to a host executable. (1) When the host is executed, the virus code also executes. If possible, the virus will replicate by attaching a copy of itself to another executable. The virus may include an additional "payload" that triggers when specific conditions are met. For example, some viruses display a message on a particular date. footnote (1): An executable is an abstraction for programs, command files and other objects on a computer system that can be executed. On a DOS PC, for example, this would include batch command files, COM files, EXE-format files and boot sectors of disks. A Trojan horse is a program that performs a desired task, but also includes unexpected (and undesirable) functions. In this respect, a Trojan horse is similar to a virus, except a Trojan horse does not replicate. An example of a Trojan horse would be an editing program for a multi-user system which has been modified to randomly delete one of the user's files each time that program is used. The program would perform its normal, expected function (editing), but the deletions are unexpected and undesired. A host program that has been infected by a virus is often described as a Trojan horse. However, for the purposes of this document, the term Trojan horse will exclude virus-infected programs. A worm is a self-replicating program. It is self-contained and does not require a host program. The program creates the copy and causes it to execute; no user intervention is required. Worms commonly utilize network services to propagate to other computer systems. A variant is a virus that is generated by modifying a known virus. Examples are modifications that add functionality or evade detection. The term variant is usually applied only when the modifications are minor in nature. An example would be changing the trigger date from Friday the 13th to Thursday the 12th. An overwriting virus will destroy code or data in the host program by replacing it with the virus code. It should be noted that most viruses attempt to retain the original host program's code and functionality after infection because the virus is more likely to be detected and deleted if the program ceases to work. A non-overwriting virus is designed to append the virus code to the physical end of the program or to move the original code to another location. A self-recognition procedure is a technique whereby a virus determines whether or not an executable is already infected. The procedure usually involves searching for a particular value at a known position in the executable. Self-recognition is required if the virus is to avoid multiple infections of a single executable. Multiple infections cause excessive growth in size of infected executables and corresponding excessive storage space, contributing to the detection of the virus. A resident virus installs itself as part of the operating system upon execution of an infected host program. The virus will remain resident until the system is shut down. Once installed in memory, a resident virus is available to infect all suitable hosts that are accessed. A stealth virus is a resident virus that attempts to evade detection by concealing its presence in infected files. To achieve this, the virus intercepts system calls which examine the contents or attributes of infected files. The results of these calls must be altered to correspond to the file's original state. For example, a stealth virus might remove the virus code from an executable when it is read (rather than executed) so that an anti-virus software package will examine the original, uninfected host program. An encrypted virus has two parts: a small decryptor and the encrypted virus body. When the virus is executed, the decryptor will execute first and decrypt the virus body. Then the virus body can execute, replicating or becoming resident. The virus body will include an encryptor to apply during replication. A variably encrypted virus will use different encryption keys or encryption algorithms. Encrypted viruses are more difficult to disassemble and study since the researcher must decrypt the code. A polymorphic virus creates copies during replication that are functionally equivalent but have distinctly different byte streams. To achieve this, the virus may randomly insert superfluous instructions, interchange the order of independent instructions, or choose from a number of different encryption schemes. This variable quality makes the virus difficult to locate, identify, or remove. A research virus is one that has been written, but has never been unleashed on the public. These include the samples that have been sent to researchers by virus writers. Viruses that have been seen outside the research community are termed "in the wild." It is difficult to determine how many viruses exist. Polymorphic viruses and minor variants complicate the equation. Researchers often cannot agree whether two infected samples are infected with the same virus or different viruses. We will consider two viruses to be different if they could not have evolved from the same sample without a hardware error or human modification. 2.0 Functionality Anti-virus tools perform three basic functions. Tools may be be used to detect, identify, or remove viruses.(2) Detection tools perform proactive detection, active detection, or reactive detection. That is, they detect a virus before it executes, during execution, or after execution. Identification and removal tools are more straightforward in their application; neither is of use until a virus has been detected. footnote (2): A few tools are designed to prevent infection by one or more viruses. The discussion of these tools is limited to Section 4.7.2, Inoculation, due to their limited application. 2.1 Detection Tools Detection tools detect the existence of a virus on a system. These tools perform detection at a variety of points in the system. The virus may be actively executing, residing in memory, or stored in executable code. The virus may be detected before execution, during execution, or after execution and replication. 2.1.1 Detection by Static Analysis Static analysis detection tools examine executables without executing them. Such tools can be used in proactive or reactive fashion. They can be used to detect infected code before it is introduced to a system by testing all diskettes before installing software on a system. They can also be used in a more reactive fashion, testing a system on a regular basis to detect any viruses acquired between detection phases. 2.1.2 Detection by Interception To propagate, a virus must infect other host programs. Some detection tools are intended to intercept attempts to perform such "illicit" activities. These tools halt the execution of virus-infected programs as the virus attempts to replicate or become resident. Note that the virus has been introduced to the system and attempts to replicate before detection can occur. 2.1.3 Detection of Modification All viruses cause modification of executables in their replication process. As a result, the presence of viruses can also be detected by searching for the unexpected modification of executables. This process is sometimes called integrity checking . Detection of modification may also identify other security problems, such as the installation of Trojan horses. Note that this type of detection tool works only after infected executables have been introduced to the system and the virus has replicated. 2.2 Identification Tools Identification tools are used to identify which virus has infected a particular executable. This allows the user to obtain additional information about the virus. This is a useful practice, since it may provide clues about other types of damage incurred and appropriate clean-up procedures. 2.3 Removal Tools In many cases, once a virus has been detected it is found on numerous systems or in numerous executables on a single system. Recovery from original diskettes or clean backups can be a tedious process. Removal tools attempt to efficiently restore the system to its uninfected state by removing the virus code from the infected executable. 3.0 Selection Factors Once the functional requirements have been determined, there will still be a large assortment of tools to choose from. There are several important selection factors that should be considered to ensure that the right tool is selected for a particular environment. There are four critical selection factors: Accuracy, Ease of Use, Administrative Overhead and System Overhead. Accuracy describes the tool's relative success rate and the types of errors it can make. Ease of use describes the typical user's ability to install and execute the tool and interpret the results. Administrative overhead is the measure of technical support and distribution effort required. System overhead describes the tool's impact on system performance. These factors are introduced below. In depth discussions of these factors are in subsequent subsections. Accuracy is the most important of the selection factors. Errors in detecting, identifying or removing viruses undermine user confidence in a tool, and often cause users to disregard virus warnings. Errors will at best result in loss of time; at worst they will result in damage to data and programs. Ease of use is concerned with matching the background and abilities of the system's user to the appropriate software. This is also important since computer users vary greatly in technical skills and ability. Administrative overhead can be very important as well. Distribution of updates can be a time-consuming task in a large organization. Certain tools require maintenance by the technical support staff rather than the end-user. End-users will require assistance to interpret results from some tools; this can place a large burden on an organization's support staff. It is important to choose tools that your organization has the resources to support. System overhead is inconsequential from a strict security point of view. Accurate detection, identification or removal of the virus is the important point. However, most of these tools are intended for end-users. If a tool is slow or causes other applications to stop working, end-users will disable it. Thus, attention needs to be paid to the tool's ability to work quickly and to co-exist with other applications on the computer. 3.1 Accuracy Accuracy is extremely important in the use of all anti-virus tools. Unfortunately, all anti-virus tools make errors. It is the type of errors and frequency with which they occur that is important. Different errors may be crucial in different user scenarios. Computer users are distributed over a wide spectrum of system knowledge. For those users with the system knowledge to independently verify the information supplied by an anti-virus tool, accuracy is not as great a concern. Unfortunately, many computer users are not prepared for such actions. For such users, a virus infection is somewhat frightening and very confusing. If the anti-virus tool is supplying false information, this will make a bad situation worse. For these users, the overall error rate is most critical. 3.1.1 Detection Tools Detection tools are expected to identify all executables on a system that have been infected by a virus. This task is complicated by the release of new viruses and the continuing invention of new infection techniques. As a result, the detection process can result in errors of two types: false positives and false negatives. When a detection tool identifies an uninfected executable as host to a virus, this is known as a false positive (this is also known as a Type I error.) In such cases, a user will waste time and effort in unnecessary cleanup procedures. A user may replace the executable with the original only to find that the executable continues to be identified as infected. This will confuse the user and result in a loss of confidence in either the detection procedures or the tool vendor. If a user attempts to "disinfect" the executable, the removal program may abort without changing the executable or will irreparably damage the program by removing useful code. Either scenario results once more in confusion for the user and lost confidence. When a detection tool examines an infected executable and incorrectly proclaims it to be free of viruses, this is known as a false negative, or Type II error. The detection tool has failed to alert the user to the problem. This kind of error leads to a false sense of security for the user and potential disaster. 3.1.2 Identification Tools Identification tools identify which virus has infected a particular executable. Defining failure in this process turns out to be easier than success. The identification tool has failed if it cannot assign a name to the virus or assigns the wrong name to the virus. Determining if a tool has correctly named a virus should be a simple task, but in fact it is not. There is disagreement even within the anti-virus research community as to what constitutes "different" viruses. As a result, the community has been unable to agree on the number of existing viruses, and the names attached to them have only vague significance. This leads to a question of precision. As an example, consider two PC virus identification tools. The first tool considers the set of PC viruses as 350 distinct viruses. The second considers the same set to have 900 members. This occurs because the first tool groups a large number of variants under a single name. The second tool will name viruses with greater precision (i.e., viruses grouped together by the first tool are uniquely named by the second). Such precision problems can occur even if the vendor attempts to name with high precision. A tool may misidentify a virus as another variant of that virus for a variety of reasons. The variant may be new, or analysis of samples may have been incomplete. The loss of precision occurs for different reasons, but the results are no different from the previous example. Any "successful" naming of a virus must be considered along with the degree of precision. 3.1.3 Removal Tools Removal tools attempt to restore the infected executables to their uninfected state. Removal is successful if the executable, after disinfection, matches the executable before infection on a byte-for-byte basis. The removal process can also produce two types of failures: hard failure and soft failure. A hard failure occurs if the disinfected program will no longer execute or the removal program terminates without removing the virus. Such a severe failure will be obvious to detect and can occur for a variety of reasons. Executables infected by overwriting viruses cannot be recovered in an automated fashion; too much information has been lost. Hard failures also occur if the removal program attempts to remove a different virus than the actual infector. Removal results in a soft failure if the process produces an executable, which is slightly modified from its original form, that can still execute. This modified executable may never have any problems, but the user cannot be certain of that. The soft failure is more insidious, since it cannot be detected by the user without performing an integrity check. 3.2 Ease of Use This factor focuses on the level of difficulty presented to the end-user in using the system with anti-virus tools installed. This is intended to gauge the difficulty for the system user to utilize and correctly interpret the feedback received from the tool. This also measures the increased difficulty (if any) in fulfilling the end-user's job requirements. Ease of Use is the combination of utilization and interpretation of results. This is a function of tool design and quality of documentation. Some classes of tools are inherently more difficult to use. For example, installation of the hardware component of a tool requires greater knowledge of the current hardware configuration than a comparable software-only tool. 3.3 Administrative Overhead This factor focuses on the difficulty of administration of anti-virus tools. It is intended to gauge the workload imposed upon the technical support team in an organization. This factor considers difficulty of installation, update requirements, and support levels required by end-users. These functions are often the responsibility of technical support staff or system administrators rather than the end-user. Note that an end-user without technical support must perform all of these functions himself. 3.4 System Overhead System overhead measures the overall impact of the tool upon system performance. The relevant factors will be the raw speed of the tool and the procedures required for effective use. That is, a program that is executed every week will have a lower overall impact than a program that runs in the background at all times. 4.0 Tools and Techniques There is a wide variety of tools and techniques which can be applied to the anti-virus effort. This section will address the following anti-virus techniques: o signature scanning and algorithmic detection o general purpose monitors o access control shells o checksums for change detection o knowledge-based removal tools o research efforts - heuristic binary analysis - precise identification o other tools - system utilities as removal tools - inoculation For detection of viruses, there are five classes of techniques: signature scanning and algorithmic detection; general purpose monitors; access control shells; checksums for change detection; and heuristic binary analysis. For identification of viruses, there are two techniques: scanning and algorithmic detection; and precise identification tools. Finally, removal tools are addressed. Removal tools come in three forms: general system utilities, single-virus disinfectors, and general disinfecting programs. 4.1 Signature Scanning and Algorithmic Detection A common class of anti-virus tools employs the complementary techniques of signature scanning and algorithmic detection. This class of tools is known as scanners , which are static analysis detection tools (i.e., they help detect the presence of a virus). Scanners also perform a more limited role as identification tools (i.e., they help determine the specific virus detected). They are primarily used to detect if an executable contains virus code, but they can also be used to detect resident viruses by scanning memory instead of executables. They may be employed proactively or reactively. Proactive application of scanners is achieved by scanning all executables introduced to the system. Reactive application requires scanning the system at regular intervals (e.g., weekly or monthly). 4.1.1 Functionality Scanners are limited intrinsically to the detection of known viruses. However, as a side effect of the basic technique, some new variants may also be detected. They are also identification tools, although the methodology is imprecise. Scanners examine executables (e.g., .EXE or .COM files on a DOS system) for indications of infection by known viruses. Detection of a virus produces a warning message. The warning message will identify the executable and name the virus or virus family with which it is infected. Detection is usually performed by signature matching; special cases may be checked by algorithmic methods. In signature scanning an executable is searched for selected binary code sequences, called a virus signature, which are unique to a particular virus, or a family of viruses. The virus signatures are generated by examining samples of the virus. Additionally, signature strings often contain wild cards to allow for maximum flexibility. Single-point scanners add the concept of relative position to the virus signature. Here the code sequence is expected at a particular position within the file. It may not even be detected if the position is wrong. By combining relative position with the signature string, the chances of false positives is greatly reduced. As a result, these scanners can be more accurate than blind scanning without position. Polymorphic viruses , such as those derived from the MtE (mutation engine) [Sku92] , do not have fixed signatures. These viruses are self-modifying or variably encrypted. While some scanners use multiple signatures to describe possible infections by these viruses, algorithmic detection is a more powerful and more comprehensive approach for these difficult viruses. 4.1.2 Selection Factors Accuracy Scanners are very reliable for identifying infections of viruses that have been around for some time. The vendor has had sufficient time to select a good signature or develop a detection algorithm for these well-known viruses. For such viruses, a detection failure is unlikely with a scanner. An up-to-date scanner tool should detect and to some extent identify any virus you are likely to encounter. Scanners have other problems, though. In the detection process, both false positives and false negatives can occur. False positives occur when an uninfected executable includes a byte string matching a virus signature in the scanner's database. Scanner developers test their signatures against libraries of commonly-used, uninfected software to reduce false positives. For additional assurance, some developers perform statistical analysis of the likelihood of code sequences appearing in legitimate programs. Still, it is impossible to rule out false positives. Signatures are simply program segments; therefore, the code could appear in an uninfected program. False negatives occur when an infected executable is encountered but no pattern match is detected. This usually results from procedural problems; if a stealth virus is memory-resident at the time the scanner executes, the virus may hide itself. False negatives can also occur when the system has been infected by a virus that was unknown at the time the scanner was built. Scanners are also prone to misidentification or may lack precision in naming. Misidentification will usually occur when a new variant of an older virus is encountered. As an example, a scanner may proclaim that Jerusalem-B has been detected, when in fact the Jerusalem-Groen Links virus is present. This can occur because these viruses are both Jerusalem variants and share much of their code. Another scanner might simply declare "Jerusalem variant found in filename." This is accurate, but rather imprecise. Ease of Use Scanners are very easy to use in general. You simply execute the scanner and it provides concise results. The scanner may have a few options describing which disk, files, or directories to scan, but the user does not have to be a computer expert to select the right parameters or comprehend the results. Administrative Overhead New viruses are discovered every week. As a result, virus scanners are immediately out of date. If an organization distributes scanners to its users for virus detection, procedures must be devised for distribution of updates. A scanner for a DOS PC that is more than a few months old will not detect most newly developed viruses. (It may detect, but misidentify, some new variants.) Timely updates are crucial to the effectiveness of any scanner-based anti-virus solution. This can present a distribution problem for a large organization. Installation is generally simple enough for any user to perform. Interpreting the results is very simple when viruses are correctly identified. Handling false positives will usually require some assistance from technical support. This level of support may be available from the vendor. Efficiency Scanners are very efficient. There is a large body of knowledge about searching algorithms, so the typical scanner executes very rapidly. Proactive application will generally result in higher system overhead. 4.1.3 Summary Scanners are extremely effective at detecting known viruses. Scanners are not intended to detect new viruses (i.e., any virus discovered after the program was released) and any such detection will result in misidentification. Scanners enjoy an especially high level of user acceptance because they name the virus or virus family. However, this can be undermined by the occurrence of false positives. The strength of a scanner is highly dependent upon the quality and timeliness of the signature database. For viruses requiring algorithmic methods, the quality of the algorithms used will be crucial. The major strengths of scanners are: Up-to-date scanners can be used to reliably detect more than 95 percent of all virus infections at any given time. Scanners identify both the infected executable and the virus that has infected it. This can speed the recovery process. Scanners are an established technology, utilizing highly efficient algorithms. Effective use of scanners usually does not require any special knowledge of the computer system. The major limitations of scanners are: A scanners only looks for viruses that were known at the time its database of signatures was developed. As a result, scanners are prone to false negatives. The user interprets "No virus detected" as "No virus exists.'' These are not equivalent statements. Scanners must be updated regularly to remain effective. Distribution of updates can be a difficult and time-consuming process. Scanners do not perform precise identification. As a result, they are prone to false positives and misidentification. 4.2 General Purpose Monitors General purpose monitors protect a system from the replication of viruses or execution of the payload of Trojan horses by actively intercepting malicious actions. 4.2.1 Functionality Monitoring programs are active tools for the real-time detection of viruses and Trojan horses. These tools are intended to intervene or sound an alarm every time a software package performs some suspicious action considered to be virus-like or otherwise malicious behavior. However, since a virus is a code stream, there is a very real possibility that legitimate programs will perform the same actions, causing the alarms to sound. The designer of such a system begins with a model of "malicious" behavior, then builds modules which intercept and halt attempts to perform those actions. Those modules operate as a part of the operating system. 4.2.2 Selection Factors Accuracy A monitoring program assumes that viruses perform actions that are in its model of suspicious behavior and in a way that it can detect. These are not always valid assumptions. New viruses may utilize new methods which may fall outside of the model. Such a virus would not be detected by the monitoring program. The techniques used by monitoring tools to detect virus-like behavior are also not fool-proof. Personal computers lack memory protection, so a program can usually circumvent any control feature of the operating system. As a part of the operating system, monitoring programs are vulnerable to this as well. There are some viruses which evade or turn off monitoring programs. Finally, legitimate programs may perform actions that the monitor deems suspicious (e.g., self-modifying programs). Ease of Use Monitoring software is not appropriate for the average user. The monitor may be difficult to configure properly. The rate of false alarms can be high, particularly false positives, if the configuration is not optimal. The average user may not be able to determine that program A should modify files, but program B should not. The high rate of false alarms can discourage such a user. At worst, the monitor will be turned off or ignored altogether. Administrative Overhead Monitoring programs can impose a fairly heavy administrative workload. They impose a moderate degree of overhead at installation time; this is especially true if several different systems are to be protected. The greatest amount of overhead will probably result from false positives, though. This will vary greatly according to the users' level of expertise. On the other hand, the monitoring software does not have to be updated frequently. It is not virus-specific, so it will not require updating until new virus techniques are devised. (It is still important to remain up-to-date; each time a new class of virus technology is developed, a number of variations emerge.) Efficiency Monitoring packages are integrated with the operating system so that additional security procedures are performed. This implies some amount of overhead when any program is executed. The overhead is usually minimal, though. 4.2.3 Summary Monitoring software may be difficult to use but may detect some new viruses that scanning does not detect, especially if they do not use new techniques. These monitors produce a high rate of false positives. The users of these programs should be equipped to sort out these false positives on their own. Otherwise, the support staff will be severely taxed. Monitors can also produce false negatives if the virus doesn't perform any activities the monitor deems suspicious. Worse yet, some viruses have succeeded in attacking monitored systems by turning off the monitors themselves. 4.3 Access Control Shells Access control shells function as part of the operating system, much like monitoring tools. Rather than monitoring for virus-like behavior, the shell attempts to enforce an access control policy for the system. This policy is described in terms of programs and the data files they may access. The access control shell will sound an alarm every time a user attempts to access or modify a file with an unauthorized software package. 4.3.1 Functionality To perform this process, the shell must have access to identification and authentication information. If the system does not provide that information, the access control shell may include it. The access control shell may also include encryption tools. These tools can be used to ensure that a user does not reboot from another version of the operating system to circumvent the controls. Note that may of these tools require additional hardware to accomplish these functions. Access control shells are policy enforcement tools. As a side benefit, they can perform real-time detection of viruses and Trojan horses. The administrator of such a system begins with a description of authorized system use, then converts that description into a set of critical files and the programs which may be used to modify them. The administrator must also select the files which require encryption. For instance, a shipping clerk might be authorized to access the inventory database with a particular program. However, that same clerk may not be allowed to access the database directly with the database management software. The clerk may not be authorized to access the audit records generated by the trusted application with any program. The administrator would supply appropriate access control statements as input to the monitor and might also encrypt the database. 4.3.2 Selection Factors Accuracy Access control shells, like monitoring tools, depend upon the virus or Trojan horse working in an expected manner. On personal computer systems, this is not always a valid assumption. If the virus uses methods that the access control shell does not monitor, the monitor will produce false negatives. Even with the access control shell, a well-behaved virus can modify any program that its host program is authorized to modify. To reduce the overhead, many programs will not be specifically constrained. This will allow a virus to replicate and is another source of false negatives. False positives can also occur with access control shells. The system administrator must have sufficient familiarity with the software to authorize access to every file the software needs. If not, legitimate accesses will cause false alarms. If the system is stable, such false positives should not occur after an initial debugging period. Ease of Use These tools are intended for highly constrained environments. They usually are not appropriate for the average user at home. They can also place a great deal of overhead on system administrators. The access control tables must be rebuilt each time software or hardware is added to a system, job descriptions are altered, or security policies are modified. If the organization tends to be dynamic, such a tool will be very difficult to maintain. Organizations with well-defined security policies and consistent operations may find maintenance quite tolerable. This software is easy for users, though. They simply log in and execute whatever programs they require against the required data. If the access control shell prevents the operation, they must go through the administrator to obtain additional privileges. Efficiency An access control shell modifies the operating system so that additional security procedures are performed. This implies some amount of overhead when any program is executed. That overhead may be substantial if large amounts of data must be decrypted and re-encrypted upon each access. Administrative Overhead An access control shell should not require frequent updates. The software is not specific to any particular threat, so the system will not require updates until new techniques are devised for malicious code. On the other hand, the access control tables which drive the software may require frequent updates. 4.3.3 Summary Access control shells may be difficult to administer, but are relatively easy for the end-user. This type of tool is primarily designed for policy enforcement, but can also detect the replication of a virus or activation of a Trojan horse. The tool may incur high overhead processing costs or be expensive due to hardware components. Both false positives and false negatives may occur. False positives will occur when the access tables do not accurately reflect system processing requirements. False negatives will occur when virus replication does not conflict with the user's access table entries. 4.4 Checksums for Change Detection Change detection is a powerful technique for the detection of viruses and Trojan horses. Change detection works on the theory that executables are static objects; therefore, modification of an executable implies a possible virus infection. The theory has a basic flaw: some executables are self-modifying. Additionally, in a software development environment, executables may be modified by recompilation. These are two examples where checksumming may be an inappropriate solution to the virus problem. 4.4.1 Functionality Change detection programs generally use an executable as the input to a mathematical function, producing a checksum. The change detection program is executed once on the (theoretically) clean system to provide a baseline(3) for testing. During subsequent executions, the program compares the computed checksum with the baseline checksum. A change in the checksum indicates a modification of the executable. footnote (3): The original file names and their corresponding checksums. Change detection tools are reactive virus detection tools. They can be used to detect any virus, since they look for modifications in executables. This is a requirement for any virus to replicate. As long as the change detector reviews every executable in its entirety on the system and is used in a proper manner, a virus cannot escape detection. Change detection tools employ two basic mathematical techniques: Cyclic Redundancy Checks (CRC) and cryptographic checksums . CRC-Codings CRC checksums are commonly used to verify integrity of packets in networks and other types of communications between computers. They are fairly efficient and well understood. CRC-based checksums are not extremely secure; they are based on a known set of algorithms. Therefore they can be broken (the particular algorithm can be guessed) by a program if it can find the checksum for a file. CRC checksum tools, like all change detection tools, can only detect that a virus has replicated. Additionally, the executable must be appear in the baseline. Cryptographic Checksums Cryptographic checksums are obtained by applying cryptographic algorithms to the data. Both public and private key algorithms can be used. In general, private key algorithms are used for efficiency. These techniques are sometimes used in conjunction with two other procedures to decrease system overhead. These techniques are message digesting and hashing.(4) footnote (4): Discussion of cryptographic terminology is beyond the scope of this document. Please see [Sim92]. In Message Digesting , hashing is used in conjunction with cryptographic checksums. The hash function, which is very fast, is applied directly to the executable. The result is much smaller than the original data. The checksum is computed by applying the cryptographic function to the hash result. The final result approaches the cryptographic checksum for security, but is much more efficient. 4.4.2 Selection Factors Accuracy Properly implemented and used, change detection programs should detect every virus. That is, there are no false negatives with change detection. Change detection can result in high numbers of false positives, however. Programs tend to store configuration information in files containing executable code. If these files are checksummed, as they should be, a change in configuration will trigger the change detector. Additionally, the system must be virus-free when the checksums are calculated; resident viruses may fool the change detection software. Ease of Use Change detection software is more challenging to use than some other anti-virus tools. It requires good security procedures and substantial knowledge of the computer system. Procedurally, it is important to protect the baseline. The checksums should be stored off-line or encrypted. Manipulation of the baseline will make the system appear to have been attacked. Analysis of the results of a checksumming procedure is also more difficult. The average user may not be able to determine that one executable is self-modifying but another is not. False positives due to self-modifying code can discourage such a user, until the output of the change detector is ignored altogether. Administrative Overhead Change detection software is easy to install and it requires no updates. The baseline must be established by a qualified staff member. This includes the initial baseline, as well as changes to the baseline as programs are added to the system. Once in operation, a high degree of support can be required for the average end-user, however. A qualified staff member must be available to determine whether or not a change to a particular executable is due to a virus or simply a result of self-modification. Efficiency Change detectors do not impose any overhead on general system use. There is, however, some storage overhead for the baseline checksums. These are best stored off-line with the checksum program. The calculation of checksums is computationally intensive; the mathematical functions must be calculated on at least a portion of the executable. To be exhaustive, the function should be calculated on the entire executable. 4.4.3 Summary If change is detected, there are several possibilities: a virus infection, self-modification, recompilation, or modification of the baseline. A knowledgeable user is required to determine the specific reason for change. The primary strength of change detection techniques is the ability to detect new viruses and Trojan horses. The limitation of change detection is the need for a knowledgeable user to interpret the output. 4.5 Knowledge-Based Virus Removal Tools The primary means of automated removal of virus infection is knowledge-based removal tools. These removal tools attempt to reverse the modifications a virus makes to a file. After analyzing a particular virus to determine its effects on an infected file, a suitable algorithm is developed for disinfecting files. Tools are available which address only a single virus. These single virus disinfectors are usually developed as the result of a particularly virulent outbreak of a virus. Others detectors are general virus removal programs, containing removal algorithms for several viruses. 4.5.1 Functionality Knowledge-based removal tools restore an executable to its pre-infection state. All modifications to the original executable must be known in order to accomplish this task. For example, if a file is infected with an overwritting virus, removal is not possible. The information that was overwritten cannot be restored. The most critical piece of information in the removal process is the identity of the virus itself. If the removal program is removing Jerusalem-DC, but the host is infected with Jerusalem-E2, the process could fail. Unfortunately, this information is often unavailable or imprecise. This is why precise identification tools are needed. 4.5.2 Selection Factors Disinfecting software is not very accurate, for a variety of reasons. The error rates are fairly high; however, most are soft errors. This is a result of incomplete information regarding the virus and the lack of quality assurance among virus writers. Additionally, removal techniques tend to fail when a system or file has been infected multiple times (i.e., by the same virus more than once, or by more than one virus). These programs are relatively easy to use and can disinfect large numbers of programs in a very short time. Any system overhead is inconsequential since the system should not be used until the virus is removed. 4.5.3 Summary Accurate removal may not be possible. Even if it is theoretically possible, precise identification of the virus is necessary to ensure that the correct removal algorithm is used. Certain viruses (e.g., overwriting viruses) always cause irreparable damage to an executable. Some extraordinarily well-behaved viruses can be disinfected every time. Most viruses fall somewhere in between. Disinfection will often work, but the results are unpredictable. Some executables cannot be recovered to the exact pre-infection state. In such a case, the file length or checksum of the disinfected executable may differ from the pre-infection state. In such a case, it is impossible to predict the behavior of the disinfected program. This is the reason virus researchers generally dislike removal programs and discourage their use. 4.6 Research Efforts The following subsections describe research areas in the anti-virus field. New tools, based on techniques developed in these and other areas, may be available in the near future. 4.6.1 Heuristic Binary Analysis Static analysis detection tools, based upon heuristic binary analysis, are a focus of research at this time. Heuristic binary analysis is a method whereby the analyzer traces through an executable looking for suspicious, virus-like behavior. If the program appears to perform virus-like actions, a warning is displayed. Functionality Binary analysis tools examine an executable for virus-like code. If the code utilizes techniques which are common to viruses, but odd for legitimate programs, the executable is flagged as "possibly infected." Examples include self-encrypted code or code that appears to have been appended to an existing program. Selection Factors Both false positives and negatives are sure to result with use of this type of software. False positives occur when an uninfected program uses techniques common to viruses but uncommon in legitimate programs. False negatives will occur when virus code avoids use of those techniques common to viruses. Binary analysis tools are fairly easy to use. The user simply specifies a program or directory to be analyzed. Analyzing the results is more difficult. Sorting out the false positives from real infections may require more knowledge and experience than the average user possesses. Heuristic analysis is more computationally intensive than other static analysis methods. This method would be inappropriate for daily use on a large number of files. It is more appropriate for one-time use on a small number of files, as in acceptance testing. A heuristic analysis program will require updates as new techniques are implemented by virus writers. Summary Early examples of this class of tool appear to have fairly high error rates as compared with commercial detection software. As with system monitors, it is difficult to define suspicious in a way that prevents false positives and false negatives. However, these types of tools have been used successfully to identify executables infected by "new" viruses in a few actual outbreaks. Heuristic binary analysis is still experimental in nature. Initial results have been sufficiently encouraging to suggest that software acceptance procedures could include these tools to augment more traditional technology. 4.6.2 Precise Identification Tools Precise identification tools are a means by which viruses are named with a much higher degree of assurance. These tools are intended to augment detection tools. Once a virus has been detected, a precise identification tool would be invoked in order to more accurately identify the virus. Functionality Virus scanners, currently the most common virus detection method, generally employ signature scanning to detect and identify viruses. This method, however, can lead to misidentifications. The signature that the scanner matched could appear in more than one variant of the virus. To avoid mis-identification the whole virus must match, not just a subset of the virus (i.e., the signature). It is neither feasible nor desirable for identification software to be distributed containing the code to all viruses it can detect. Therefore, prototype precise identification tools utilize a "virus map" to represent the contents of the virus. The virus map contains checksum values for all constant parts of the virus code. The map skips over sections of the virus that contain variable information such as text or system dependent data values. If the checksums generated by the corresponding portions of the program match, the program is almost certainly infected by the virus corresponding to the map. If none of the maps in the database correspond, the program is infected by a new virus (or is uninfected.) Selection Factors The quality of the results produced by a precise identification tool is dependent upon the quality of the virus map database. If that has been done well and kept current, these tools are extremely accurate and precise when identifying known viruses. Conversely, if the virus is new or has no corresponding entry in the database, the precise identification tool should always "fail" to identify the viruses. This type of tool is easy to use. The user simply specifies an executable, and the tool returns a name, if known. The results are straightforward; it is virus "X," or unknown. Precise identification tools are slow due to the intensive nature of the computations. These tools may be used to perform an identification pass after the use of a more efficient detection tool. Such a plan would provide the user with the benefits of precise identification without great overhead. Once a virus has been detected, the user wants to know exactly what virus he has and time is not a significant factor. Summary Users want to know more about the virus infecting their systems. Precise identification will help them obtain more complete information and can also facilitate automated removal. Researchers will also wish to use this type of tool. It will allow them to separate samples of known viruses from new ones without performing analysis. 4.7 Other Tools The remaining tools, system utilities and inoculation, are included for completeness. These tools can be used to provide some measure of functionality. In general, however, these tools are weaker than general anti-virus tools. 4.7.1 System Utilities Some viruses can be detected or removed with basic system utilities. (5) For example, most DOS boot sector infectors and some Macintosh viruses can be removed with system utilities. System utilities can also be used to detect viruses by searching for virus signatures. These tools have a rather limited focus, though. footnote (5): Two examples of these system utilities are Norton Utilities for the PC and ResEdit for the Macintosh. Viruses that can be disinfected "by hand" are generally the extremely well-behaved, highly predictable viruses that are well understood. Such viruses are the exception, not the rule. There are many more viruses that cannot be disinfected with these tools. Where possible, disinfection with system utilities will produce dependable results. A reasonable amount of knowledge is required about the computer system and the virus itself, though. This technique can also be very laborious if a large number of systems are infected. System utilities are an inefficient means of detection. Generally, only one signature can be handled at a time. This might be a useful technique if a specific virus is to be detected. Summary Accurate removal by system utilities is frequently impossible. Certain classes of viruses (e.g., overwriting viruses) always damage the executable beyond all hope of repair. Others modify the executable in rather complicated ways. Only viruses that are extremely well-behaved can be disinfected every time. Similarly, detection with system utilities has limited application. 4.7.2 Inoculation In some cases, an executable can be protected against a small number of viruses by "inoculation." This technique involves attaching the self-recognition code for the virus to the executable at the appropriate location. Since viruses may place their self-recognition codes in overlapping locations, the number of viruses that can be inoculated against simultaneously will be small. To make matters worse, a common way to create a new variant is to change the self-recognition code. Thus, this technique will often fail when tested by minor variants of the viruses inoculated against. Inoculation is no substitute for more robust anti-virus tools and procedures. It might be useful, though, if an organization has had recurring infections from a single virus. For example, after cleaning three or four outbreaks of a particular virus from a network of PCs, inoculation might be considered as a desperation measure. 5.0 Selecting Anti-Virus Techniques The selection of the appropriate class of anti-virus tools requires answers to the following set of questions: o What is the probability of a virus infection? o What are the consequences of a virus infection? o What is the skill level of the users in your organization? o What level of support is available to the end-user? The first two questions address risk; security should always be commensurate with need. The third and fourth questions address the limitations of the tools and personnel. The answers will be different for each person or organization. Every organization is at some risk of virus infection. Virus infections can occur whenever electronic information is shared. Every organization shares information in some way and is a potential victim of a virus infection. Most organizations should have some tools available to detect such an infection. Personal computer users may benefit from tools to identify viruses, since so many viruses exist. Identification tools are not necessary where viruses are few or only theoretically possible. The use of removal tools is generally not required.(6) It may be desirable in situations where a single person or a small team is tasked with cleaning up after an infection or where high connectivity can result in rapid spread of the virus (such as networks). footnote (6): Exceptions, such as the DIR-2 PC virus, may be extremely difficult to remove without appropriate tools. In this case, the only alternative to removal tools is to format the disk. 5.1 Selecting Detection Tools The first point to consider when selecting a detection product is the type of viruses likely to be encountered. Approximately 95 percent of all virus infections are accounted for by a small number of viruses. The viruses that constitute this small set can vary geographically. The common viruses can be distinct on different continents, due to the paths in which they travel. Of course, different hardware platforms will be at risk from different viruses. International organizations may be vulnerable to a larger set of viruses. This set may be obtained by merging the sets of viruses from different geographical regions where they do business. Organizations with contacts or installations in locations where virus writers are particularly active [Bon91] are also more likely to encounter new viruses. Risk from new viruses is an important consideration. Scanners are limited by their design to known viruses; other detection tools are designed to detect any virus. If your organization is at high risk from new viruses, scanners should not be the sole detection technique employed. Another important criteria to consider is the number and type of errors considered tolerable. The tolerance for a particular type of error in an organization will vary according to the application. Table 1 shows the types of errors which should be expected. An estimate of the frequency that this class of error is encountered (Infrequent, Frequent, or Never) is also given for each class of tools and error type. All anti-virus tools are subject to errors, but their relative frequencies vary widely. Scanners probably have the lowest overall error rate. Checksummers do not produce false negatives. The third and fourth items to consider when selecting anti-virus tools are the ease of use and administrative overhead required for each tool. Questions to consider are: What is the average skill level of your organization's end-user? Does your organization have a support staff to assist user with more technical problems? Table 2 includes a general evaluation of the ease of use and administrative overhead imposed by each class of tools. If several tools still appear to be candidates, consider the functionality of these tools beyond virus detection. Viruses are only one of the many threats to computer security. All detection tools except scanners have general security applications beyond viruses. Scanners are limited in application to viruses, but have the added functionality of virus identification. (7) Consider the added functionality which is most needed by your organization and choose accordingly. The alternatives are outlined in table 3. footnote (7) Some scanners can also detect known Trojan horses. The final selection criteria to be considered is when does the tool detect viruses. Proactive detection tools allow the user to keep viruses off a system by testing incoming software. These tools only allow one chance of detecting a virus (upon initial introduction to the system). Active detection tools intervene during the replication phase itself. Reactive detection tools can be used any time after a virus has entered the system. Additionally, reactive tools are not as rigorous in their demands on system performance. Table 4 shows when these different tools detect viruses. 5.1.1 Combining Detection Tools The most complete protection will be obtained by combining tools which perform in radically different fashion and protect against different classes of viruses. For instance, when used together a scanner and a checksum program will protect against both known and unknown viruses. The scanner can detect known viruses before software is installed on the system. A virus can be modified to elude the scanner, but it will be detected by the checksum program. The two tools should have different "additional functionality" (see table ) to form the most comprehensive security package. For instance, the combination of a checksum program and an access control shell would also detect Trojan horses and enforce organizational security policy in addition to virus detection. On the other hand, adding a binary analyzer to a system that already employs checksumming would not provide additional functionality. If you must use two scanners, be sure that they use different search strings. A number of tools are based on published search strings; shareware tools commonly utilize the same public domain signature databases. Two different scanner engines looking for the same strings do not provide any additional protection of information. (8) footnote (8): Algorithms for detection tend to be independently developed. 5.2 Identification Tools Currently, scanners are the only effective means of identifying viruses. As discussed in Section , the accuracy to which scanners identify viruses can vary. In the future, precise identification tools should offer greatly increased accuracy. 5.3 Removal Tools The most dependable technique for virus removal continues to be deletion of the infected executable and restoration from a clean backup. If backups are performed regularly and in a proper manner, virus removal tools may be neglected. In large organizations with high connectivity, automated removal tools should be obtained. Virus eradication through the removal of infected executables may require too much time and effort. Knowledge based tools will disinfect the largest number of different viruses, but proper identification of the virus prior to disinfection is critical. Even with knowledge based removal tools, disinfection of executables is not always reliable (see Sec. ). Test all disinfected executables to be sure they appear to execute properly. There is still a chance, however, that soft errors will occur. 5.4 Example Applications of Anti-Virus Tools This section provides hypothetical scenarios for the use of anti-virus tools. For each application, a battery of tools is suggested. There are several ways these tools can be applied to the same scenario; this text represents just one set of rational solutions. 5.4.1 Average End-User Detailed knowledge of the computer system is not required for the average end-user to perform one's job. Such a user should not be required to obtain detailed knowledge just to use anti-virus tools. This implies that scanners are probably most appropriate for the average end-users. Any other choice will require support from a technical support team or computer security incident response team. Of the remaining tools, the best option is a checksum program. By executing the checksum program regularly, for example weekly or monthly, infections will be detected within a limited timeframe. Another possibility is to relieve these users of the responsibility of detecting viruses entirely. If a technical support team is already providing other regular services (e.g., backup), the support team can use any combination of anti-virus tools deemed necessary. 5.4.2 Power Users Power users, those with detailed knowledge of their computer systems, will be better equipped to handle a larger variety of anti-virus tools. A power user is more able to determine whether a change detected by a checksum program is in fact legitimate. Additionally, a power user is going to be better equipped to configure some of the other tools, such as general purpose monitors and access control shells. 5.4.3 Constrained User If the user is constrained by policy to run a small set of programs against a known set of data files, an access control shell may be the appropriate choice. As an example, consider a data entry clerk who is permitted to run one particular database application and a basic set of utilities: mail, word processing, and a calendar program. An access control shell can be configured so that any changes to executable files by that user are deemed illegal operations. Additionally, if the set of executable files is restricted for the user, it is difficult to introduce a virus into the system. The virus is unable to spread if it can never be executed. 5.4.4 Acceptance Testing Acceptance testing is a means by which software is verified to be "virus-free" before it is put into daily use. This is usually accomplished by placing the software on an isolated system and performing tests that are intended to mimic every day use. A combination of anti-virus tools is required to adequately perform this function, which must detect both known and future viruses. In particular, a checksum program is most useful. Even if the trigger conditions for the payload are not met, the virus will still most likely attempt to replicate. It is the result of the replication process that a checksum program detects. 5.4.5 Multi-User Systems Although viruses found in the wild have been limited to personal computer systems, viruses for multi-user systems have been demonstrated in a number of laboratory experiments. Therefore, the potential exists for viruses on multi-user systems. As a result, it is prudent to ensure that the security measures taken on a multi-user system address viruses as well. Currently, administrators of multi-user systems have a limited number of options for virus protection. Administrators of these systems cannot use monitors or scanners. Since there are no known viruses, there are no signatures to search for or expected virus behavior to detect. An option that is available to administrators of multi-user systems is change detection. Many of these systems are already equipped with a checksum program. Access control shells are another possibility for many systems. Like access control, though, they are not usually designed for virus detection. 5.4.6 Network Server Network servers present an interesting problem. They can support a wide variety of machines, but may run an entirely different operating system. For instance, a UNIX server may support a network of PC and Macintosh workstations. The UNIX system cannot be infected by the Jerusalem-B or WDEF viruses, but infected files may be stored on its disk. Once the network server has infected files on it, the workstations it supports will rapidly become infected as well. Since the viruses never execute on the server, the administrator is limited to static detection techniques such as scanners or change detectors. The nature of network servers allows these tools to be run automatically during off-peak periods. 6.0 Selecting the Right Tool Once an anti-virus technique has been selected, an appropriate tool from that class must be selected. This section presents several features to be considered when selecting a specific product from a class of tools. 6.1 Selecting a Scanner Scanners are implemented in several forms. Hardware implementations, available as add-on boards, scan all bus transfers. Software implementations include both non-resident and resident software for the automatic scanning of diskettes. Non-resident software is sufficiently flexible to meet most needs; however, to be effective the user must execute the software regularly. Hardware or resident software are better choices for enforcing security policy compliance. Resident scanners may be susceptible to stealth viruses. Although most scanners use similar detection techniques, notable differences among products exist. Questions that potential users should consider when selecting a scanner include: o How frequently is the tool updated? A scanner must be updated regularly to remain effective. How frequently updates are needed depends on which platform the scanner is used. Update frequency should be proportional to the rate at which new viruses are discovered on that platform. o Can the user add new signatures? This can be very important if a particularly harmful virus emerges between updates. o Does the tool employ algorithmic detection? For which viruses does the tool use algorithmic detection? Algorithmic detection is preferable to the use of multiple signatures to detect polymorphic viruses. o How efficient is the tool? Users are less likely to use a slow scanner. There can be a significant difference in performance between different search algorithms. o Does the vendor develop their own virus signatures, or are the signatures based on published search strings? There is nothing particularly wrong with published search strings, but it indicates the level of resources the vendor has committed to the product. o What is the level of documentation? Some packages arrive with large fact-filled binders; other packages are a single floppy disk with a few ASCII files describing installation and parameters. 6.2 Selecting a General Purpose Monitor General purpose monitors are usually implemented in software; however, hardware implementations do exist. Hardware versions may be more difficult to circumvent, but they are not foolproof. The following questions should be considered when selecting a general purpose monitor: o How flexible are the configuration files? Can different parts of the monitor be disabled? Can the monitor be configured so that certain executables can perform suspect actions? For example, a self-modifying executable will still need to be able to modify itself. o What types of suspect behavior are monitored? The more types of behavior monitored, the better. A flexible configuration to select from the set of features is desirable. o Can the monitor be reconfigured to scan for additional virus techniques? Are updates provided as new virus techniques are discovered? 6.3 Selecting an Access Control Shell Access control shells may be implemented in software or as hybrid packages with both hardware and software components. If encryption modules are required, they can be designed as software or hardware. The following questions should be considered when selecting an access control shell: o What type of access control mechanism does the shell provide and does it fit your security policy? o If encryption is employed, what is the strength of the algorithms used? In general, publicly scrutinized algorithms are to be preferable to secret, proprietary algorithms where you are depending on the secrecy of the algorithm, rather than secrecy of the key. o How strong are the identification and authentication mechanisms? provides basic criteria for analyzing the strength of these mechanisms. o Are the passwords themselves adequately protected? Passwords should never be stored in cleartext. 6.4 Selecting a Change Detector Due to cost considerations, change detection tools are usually implemented in software. However, hardware implementations do speed the calculation of cryptographic checksums. The following questions should be considered when selecting a change detector: o What kind of checksum algorithm does the tool use - CRC or cryptographic? CRC algorithms are faster. Cryptographic checksums are more secure. o Can the tool be configured to skip executables that are known to be self-modifying? Consistent false positives will eventually cause the end-user to ignore the reports. o How are the checksums stored? Some tools create a checksum file for every executable, which tends to clutter the file system and wastes disk space. Other tools store all checksums in a single file. Not only is this technique a more efficient use of disk space, but it also allows the user to store the checksum file off-line (e.g., on a floppy). 6.5 Selecting an Identification Tool The following questions should be considered when selecting a scanner for identification: o How many viruses does it detect? How many different viruses are identified? The former asks how many different viruses are detected, whereas the latter asks how many different names are assigned to these different viruses. If a scanner is using signature strings, signatures can appear in variants. These questions will give some understanding regarding the level of precision provided by a particular tool. o What names are used by the identification tool? Many viruses have numerous "aliases," so different scanners will produce different names for the same infection. This is especially true with IBM PC viruses. The identification feature of the scanner is only useful if the scanner comes with a virus catalog or uses the same nameset as an available catalog. Precise identification tools will be more useful when they become available, although the same limitations regarding a virus information catalog will still apply. 6.6 Selecting a Removal Tool Removal tools are more difficult to evaluate, but the following items may be of assistance: o Ask for a list of viruses that can be removed, and the general level of accuracy. (For example, "75 of disinfections will result in a working executable.") Ask for a list of viruses that cannot be removed. Use the ratio for the basis of a rough comparison. o Get a scanner and removal tool that work from the same naming space. The removal tool works on the basis of the virus you name. You need to supply it with the name by which it knows the virus. Matched identification and removal tools are required to make it work. 7.0 For Additional Information The National Institute of Standards and Technology's Computer Security Division maintains an electronic bulletin board system (BBS) focusing on information systems security issues. It is intended to encourage sharing of information that will help users and managers better protect their data and systems. The BBS contains the following types of information specific to the virus field: o alerts regarding new viruses, Trojan horses, and other threats; o anti-virus product reviews (IBM PC and Macintosh); o technical papers on viruses, worms, and other threats; o anti-virus freeware and shareware; o and archives of the VIRUS-L forum. Occasionally, the alerts contain signature strings to update scanners. The anti-virus product reviews examine and evaluate specific tools. The papers provide an extensive body of basic knowledge regarding these threats. The VIRUS-L forum has served as a world-wide discussion forum for the exchange of information regarding viruses since April 1988. The past issues are available for download. Access Information The NIST Computer Security Resource Center BBS can be access via dial-up or through the Internet via telnet: Dial-up access: (301) 948-5717 (2400 baud or less) (301) 948-5140 (9600 baud) Internet: telnet cs-bbs.ncsl.nist.gov (129.6.54.30) References [BP92] Lawrence E. Bassham III and W. Timothy Polk. "Precise Identification of Computer Viruses", in the Proceedings of the 15th National Computer Security Conference, 1992. [Sku92] Fridrik Skulason. "The Mutation Engine - The Final Nail?", Virus Bulletin, pages 11-12, April 1992. [Rad91] Yisrael Radai. "Checksumming Techniques for Anti-viral Purposes", In "Proceedings of the First International Virus Bulletin Conference", 1991. [Bon91] Vesselin Bontchev. "The Bulgarian and Soviet Virus Factories", In "Proceedings of the First International Virus Bulletin Conference", 1991. [Coh92] Dr. Frederick Cohen. "Current Best Practices Against Computer Viruses With Examples From The DOS Operating System", In "Proceedings of the Fifth International Computer Virus & Security Conference", 1992. [Sol92] Dr. Alan Solomon. "Mechanisms of Stealth", In "Proceedings of the Fifth International Computer Virus & Security Conference", 1992. [FIPS112] Password Usage. Federal Information Processing Standard (FIPS PUB) 112, National Institute of Standards and Technology, May 1985. [WC89] John Wack and Lisa Carnahan. "Computer Viruses and Related Threats: A Management Guide", Special Publication 500-166. National Institute of Standards and Technology. August, 1989. Gustavus J. Simmons, editor. "Contemporary Cryptology: The Science of Information Integrity", IEEE Press, 1992. Index see hardcopy. Tables Error Scanner Binary Generic Access Type Checksum Analysis Monitor Shell ============================================================================= False I F F F F Positive False I N F F F Negative I= Infrequent F= Frequent N= Never Table 1 Scanner Binary Generic Access Criteria Checksum Analysis Monitor Shell ============================================================================= Ease of VG A P P A Use Admin. L L H H H Overhead VG = Very Good A = Average P = Poor L = Low H = High Table 2 Tool Add'l Functionality ============================================= Scanner Identification Checksum Detect known Trojan horses Binary Detect Trojan Horses Analysis Generic Detect Trojan horses Monitor Access Enforcing organizational Shell security policy Table 3 Point of Scanner Binary Generic Access Detection Checksum Analysis Monitor Shell ============================================================================= Static YES No Yes No No Executable Replication No No No Yes Yes Phase After Yes Yes Yes No Yes Infection Table 4