CHAPTER 41
ANTIVIRUS TECHNOLOGY
Chey Cobb and Allysa Myers
41.3.1 Early Days of AV Scanners
41.3.4 Antivirus Engines and Antivirus Databases
41.4.4 Intrusion Detection and Prevention
41.5.1 How Content Filters Work
41.5.2 Efficiency and Efficacy
41.1 INTRODUCTION.
For over two decades, computer viruses have been a persistent, annoying, and costly threat, and there is no end in sight to the problem. There are many vendors offering to provide a cure for viruses and malware, but the mere existence of these software pests is understandably vexing to those charged with system security.
Initially, most viruses were not designed to cause harm but were created more to gain notoriety for the creator or as a prank. Because these early viruses were designed to subvert legitimate program operations across multiple systems, they were more likely to cause unexpected problems. These viruses, and later some Trojans, often damaged data and caused system downtime. The cleanup required to recover from even a minor virus infection was expensive in terms of lost productivity and unbudgeted labor costs.
Viruses and Trojan behavior have merged, and now both are considered as part of the larger family referred to as malware. No longer is malware just written for a virus writer's 15 minutes of fame; today, malware is created primarily for financial gain. Malware can still cause damage, but now it is more likely to have been created to steal valuable information or the resources of an infected computer. Malware can steal passwords, send spam from a compromised machine, or install software designed to display ads (with programs known as adware), to name a few examples. Some malware programs can give full access to a hacker to control infected machines, and a new trend has been the creation of “zombie nets.” These hijack the computers of unsuspecting users, in order to launch an attack. A zombie net makes use of the increased power of networked computers, while making it more difficult to trace a suspected attacker. For more information about malware, see Chapter 16 in this Handbook.
Because of this shift to a financial motivation for malware writing, something of an open source community has sprung up to develop new malware. There have been two major areas where development has been most notable: evasion of traditional antivirus defenses and distribution by exploiting vulnerabilities in common software. In their efforts to evade traditional antivirus defenses, viruses are often slightly modified and compressed with “packers,” which frequently use sophisticated obfuscation or anti–reverse-engineering techniques. The primary focus of malware writers is to avoid the newsworthy outbreaks of the past, staying under the radar to accomplish targeted attacks. Some of the most common malware families now have as many as tens of thousands of variants with hundreds of variants being released each day. Once they are in a system, they often employ stealthing techniques such as kernel-mode rootkits to hide themselves from the operating system and from many antivirus (AV) products.
New malware programs are being developed every day because vulnerabilities in software programs are so numerous, and it is often months between the time a vulnerability is discovered and the time that the vendor issues a security patch. Even more often, patches are announced but not implemented. Malware writers take advantage of these vulnerabilities and time lags, so research into vulnerabilities is imperative in order to create effective defenses with antivirus programs. A layered defense against malware infection is essential and should employ a traditional string-based antivirus scanner as well as a firewall and behavioral scanners.
Although the threat of new malware remains, and its growth has become exponential, the technology deployed to defend computers against viruses and malware is one of the least understood aspects of security architecture. As a result, antivirus defenses are often set up improperly. This chapter describes available antivirus technologies and how they work. Their effective application within a comprehensive program of computer security is outlined.
41.1.1 Antivirus Terminology.
The acronym “AV” is widely used to describe the industry, the products, and the programs that have been developed to defeat computer viruses. Early AV programs used simple hard drive scans to search for a specific text string hidden within a specific file. This is the origin of the term “AV scanner,” which is now widely used as a generic term for all AV programs. That is how the term is used in this chapter, although it should be pointed out that many of today's AV scanners do much more than merely scan, and detection now includes Trojans and unwanted programs such as adware and malware.
When exploring AV product literature, it is common to see statements about the number of viruses and Trojans that exist. It is not unusual to see six-digit estimates of the total number of malware variants and four-digit estimates of the number of new malware added every month. However, it is important to bear in mind that not all numbers are created equal. For a start, there is a difference between threats that exist only in a research setting (in the zoo) and those that are actively infecting users' computers (in the wild). Viruses held in the zoo are used to help create new AV technology, and they are well secured against inadvertent release. These viruses and malware come from samples that are sometimes sent directly to virus researchers by virus writers, while others are sent by researchers who have created a proof-of-concept virus.
The term “in the wild” is applied to viruses that are active, as tracked by virus researchers. In the early 1990s, Joe Wells developed a coordinated reporting procedure that synchronized the work of responsible AV researchers around the world, resulting in a reliable and consistent monthly accounting of virus activity. This pioneering move was called the WildList.1
41.1.2 Antivirus Issues.
In the early days of viruses, aside from having the ability to spread to other machines, there was little benefit in keeping a virus on a machine for any length of time. During the early days, viruses were relatively easy to find, because a virus usually caused noticeable damage that made users aware that their systems were infected. At other times, an unmistakable message or image appeared on the screen, alerting users to the infection. As virus writers discovered a monetary benefit to remaining on a system as long as possible, the number of infected machines increased tremendously. Viruses and malware have become complex, are adept at disguising themselves, and are not as easy to find and eradicate. To counter this problem, AV scanners have become sophisticated logic machines. This new level of complexity, of both the problem and the solution, has made it even more confusing for users. Too many people fail to understand the importance of having up-to-date AV products. Users do not know what to look for, and do not understand that viruses and malware do not necessarily announce their existence. This is probably why reports of Netsky virus variants are still appearing years after they were initially released and why Robot Network (botnet) infections number more than 2,000 a day.
Most AV software has an automatic update capability, which has made updating a less labor-intensive process. Updates are the key to keeping systems virus and malware free because updates give the AV program the information necessary to find the newest viruses and malware. Unfortunately, because viruses and Trojans are released at such a prodigious pace, even daily updates of a traditional string-based scanner may not be enough to keep systems totally clear of viruses. Most AV scanners look at what has happened before (i.e., known behavior of known viruses), in order to detect infections. Although AV products now attempt to anticipate new viruses, that is not their strong point. Additionally, many consumers who buy a new computer receive a working AV product with their purchase, but they do not choose to buy a subscription for AV updates once their free use period expires. They do not understand why they have to pay for something that seems to be working, and they are lulled into a false sense of security by thinking that their AV product is doing its job. The vendors have not done a good job educating the public that an AV scanner without current updates is useless. Consumers who bring work from home into the office can quickly infect an entire network.
Security products historically have suffered from a lack of upper management support because they are often viewed as high-cost/low-return items, and they are given a low priority in the security budget. The information technology (IT) team of an organization needs resources for things like identifying and patching vulnerable systems, monitoring and managing machines entering their network, monitoring suspicious behavior identified by firewalls, AV products, and security scanners. Considering the plethora of AV products from which to choose, and the large number of patches introduced each day, many system administrators despair. They will install and patch just what they have time for, and consider it good enough.
41.2 HISTORY OF VIRAL CHANGES.
Early viruses were usually distributed via floppy disks in the 1980s because PCs were not normally networked, and the Internet was not yet widely used. However, shortly after the first viruses began appearing on PCs, AV scanners made their debut. The first scanners only detected the presence of a virus but did nothing to disinfect the system. Users often had to search message boards to find information for the removal of a particular virus or to obtain specific removal programs from vendors. The virus problem was not considered a priority at that time because there were a limited number of viruses, and most were only a nuisance.
Changes in the computing environment are responsible for both the type of viruses and the rate at which they infect. For example, until 1992, the number of boot sector viruses and file-infecting viruses was roughly equivalent. In 1992, the number of file-infecting viruses began to decrease and boot sector viruses began to increase. This trend continued through 1995, when the change from DOS-based computing to Windows-based computing tipped the scales in favor of boot-sector viruses. Most PCs were still diskette based, and boot disks were standard equipment. Users frequently swapped information between computers via floppies on the “sneaker net” because interconnected computers were rare. Infected floppies that were left in the drive during the boot process allowed the virus to take up residence in the computer's memory, and would subsequently infect every disk used on that machine. Because boot sector viruses did not cause Windows to crash, many users did not realize that they had been infected until the virus caused problems on the system or until someone decided to check the system on suspicion that it might be infected.
Another factor favoring boot sector viruses for a time was the complexity of Windows 3.1 relative to earlier operating systems. When Windows was first introduced, virus writers did not have much experience in writing viruses for Windows systems. Because most file-infecting viruses of that period caused Windows to crash, and because Windows 3.1 was itself notoriously unstable, users frequently reformatted hard drives and reinstalled the operating system as a matter of course. As a result, whether the users were aware of the fact that a virus was resident or not, reformatting and reinstalling the hard drive quickly eliminated the file-infecting viruses.
The introduction of Windows 95 again changed the course of viruses. Once more, the virus writers had a new operating system with which to contend, and they quickly discovered that Windows 95 included an enhancement that warned users when changes were made to the boot sectors. These warnings would alert users that a virus might be present. Boot sector viruses stalled at this point, and the rate of file infections slowed to a near halt. Eventually, it was the power of sharing data files between applications that led to the next stage in virus evolution: the macro virus.
Microsoft's dominance of the office suite market through its MS Office products (Word, Excel, PowerPoint, and Access) provided a uniform platform for the spread of macro viruses, based on its proprietary Visual BASIC (VB) programming language. Because VB macros are easy to develop and can be quickly exchanged among users through file sharing, it is natural that macro viruses quickly became the most prevalent type of virus. These facts, combined with increased connectivity between systems and networks, made macro viruses able to spread faster than the traditional boot sector or file-infecting viruses.
Early viruses also required the interaction of a human being to assist it in spreading. The user had to (unknowingly) execute the infected program, copy it from a hard disk to a floppy, and physically move it to another machine. However, with code and application sharing in browser, media, and operating system software, viruses no longer require human interaction to execute. They spread as executables or data files, from one vulnerable system to the next, without a user ever being aware that code had been run. Many people sitting at home, connected to the Internet, did not realize that, by simply going to an infected Web site or viewing an infected ad on an otherwise benign site, a program had been silently executed and had installed a virus or malware on their system.
In recent years, instant messaging (IM) and peer-to-peer (P2P) file-sharing clients have gained a great deal of popularity, and viruses have changed to take advantage of the ease of sharing. In the case of IM, this is accomplished primarily through links sent to people on an infected user's contact list. In the case of P2P clients, this is accomplished by copying the malicious files to “shared” directories with enticing names. Both methods rely heavily on social engineering to get people to click on a file that will then install infected files.
41.3 ANTIVIRUS BASICS.
AV scanners are abit like police officers walking the beat. They try to watch everything that is going on around them, look out for suspicious behavior, and attempt to intercede when they think something bad is happening or about to happen. Both the police and AV scanners look for certain patterns and behaviors, and they leap into action when a suspect crosses a predetermined threshold of acceptability. Like the police, however, AV scanners sometimes reach the wrong conclusions. This is usually caused by insufficient data or by new and unexpected behavioral patterns.
Virus detection is an inexact science, and it is impossible to create an AV scanner with a 100 percent success rate. It is simply not possible to know the intent of every bit of code that enters a computer, and it is not feasible to test every bit of code before it executes. To do so would require that the AV scanner demand so much of the processing power of the CPU that valid programs would not be able to execute. Viral behaviors are subject to broad variations, and many use stealthing or cloaking techniques to hide from the operating system and even from the AV scanner itself. There are no longer hard-and-fast rules that a user can apply to determine if a system harbors a virus.
41.3.1 Early Days of AV Scanners.
When viruses first started appearing with regularity in the late 1980s, their detection and eradication was relatively straightforward, but not necessarily easy. The viruses were quite simple and normally did not spread very quickly. The AV community quickly researched them, determined what made them work, and published effective fixes in short order. These fixes tended to be written for a specific virus and could not disinfect other viruses, even if they were of similar types. Most of the work fell on users to identify which virus (or type of virus) they thought they had and then search for a program that would fix it. Because Internet connectivity was not as prevalent as it is now, users frequently spent much time calling friends and associates in the hope that they could forward a disk copy of the necessary AV program. Additionally, there were no naming conventions for viruses, and it was difficult to determine with any conviction that the fix obtained would actually work.
Viruses of that period generally inserted their code in predictable sections of a program. The early scanners ran a search for a specific string of characters. If they found it, they would delete the virus code and attempt to restore the host program to its original uninfected form. Failing that, the scanner would usually advise the user that disinfection was incomplete and that they should delete the infected application and reinstall it.
As the number of viruses began to climb, software companies that had ventured into the AV market began to realize that creating and distributing individual fixes was no longer feasible. Instead, they began to develop more comprehensive scanners that could look for more viruses, both old and new. The new generations of scanners were comprised of two components: the scanning engine and the signature files. Each component was entirely dependent on the other to work. The engine consisted of the user interface and the application that scanned the system for viruses. The signature files were a database of the fingerprints (unique segments of code) of known viruses. Although some of these early scanners did a good job, many did not. None of the early AV scanners was able to catch all known viruses.
41.3.2 Validity of Scanners.
The vendors of software scanners in the late 1980s and early 1990s faced a number of obstacles. It seemed there was a new AV vendor appearing every month, and the market became highly competitive as user awareness of the virus problem grew. Given this competitive state, there was vast dissension among the AV community as to how viruses for research should be stored and tested. Many AV vendors kept a library of viruses for their own use, and this fact was used in their marketing. Claims that one program worked better than another because it checked for more viruses were misleading because no one knew how many viruses existed. There was simply no method of commercial or independent testing to check the validity of claims made by the AV product vendors. Additionally, there was a problem of naming the viruses. Each vendor created its own names for viruses, and it was not uncommon for one virus to be known by several names.
The AV vendors also disagreed on how AV scanners should operate in principle. Some vendors felt that AV scanners should only look for new viruses, and others felt that a good product should search for both old and new viruses. While this argument raged, viruses looked as though they would eventually gain the upper hand, especially as virus writers began to use underground bulletin boards, and later the Internet, to share and distribute virus code.
With no standards for the AV products, the public had little to go by other than the vendors' marketing copy and the advice of other users. However, if a recommendation was made by a friend for Brand X Antivirus because no viruses were found on the friend's system, it was possible that no viruses had ever been introduced in the friend's system at all, and Brand X could not find old viruses, new viruses, or any viruses at all.
Two things happened that revolutionized the AV scanner market. In 1993, Joe Wells, a research editor with a business magazine, began collecting viruses and virus reports from experts around the world and began assembling a library of these viruses. As was noted earlier, he named this library of viruses the “WildList” and made it available to legitimate AV researchers. His list divided viruses into those known to have infected systems (in the wild) and those that had been written but were not actively infecting (in the zoo). A naming convention of viruses also began to emerge in order to maintain an efficient and searchable database. The other notable event was the development of commercial AV testing and certification by a company known as the National Computer Security Association (NCSA), which is now known as ICSA Labs. The NCSA started a consortium of AV vendors that, for a fee, submitted their products to be tested. NCSA and Joe Wells began collaboration for the use of his WildList, and Dr. Richard Ford, a noted virus expert, created a virus testing laboratory for NCSA. Dr. Ford fashioned an environment in which AV scanners were put through their paces to see if they could detect all of the viruses in the WildList. AV vendors submitted their products every time a new version of their product was about to be released. Although the original test results were dismal (many scanners could not detect more than 80 percent of the viruses in the list), an environment had been created in which measurable improvements in the effectiveness of AV technology could be achieved. Naturally, the public and the press began to look for AV products that had been certified by NCSA. Eventually other commercial and independent test laboratories independently developed their own certification schemes to help users find reliable AV products.
41.3.3 Scanner Internals.
As was noted earlier, an AV scanner cannot simply put each program into a computer's RAM and test it for viruses before the program is allowed to execute. To do that would require almost all the resources of the CPU, and users would have a system that operated at a snail's pace.
In order to operate efficiently, and in harmony with the other programs on a computer, AV scanners have had to resort to numerous tricks to prevent virus infections, find infections, disinfect programs, and still operate at a reasonably high speed, without bringing the entire system to a halt. They can use some or all of these four basic methods of operation:
- Specific detection. Looking for infections by known viruses
- Generic detection. Looking for infections by variants of known viruses
- Heuristics. Scanning for previously unknown viruses by noting suspicious behavior or file structures, as described more fully in Section 41.4.3
- Intrusion prevention. Monitoring known-suspicious system changes and behaviors to prevent unknown infections
41.3.4 Antivirus Engines and Antivirus Databases.
The AV engine and its signature database work in concert to prevent and detect viruses entering a system. The engine generally provides a library of commonly used functions. It consists of dozens of complex searching algorithms, CPU emulators, and various forms of programming logic. The engine determines which files to scan, which functions to run, and how to react when a suspected virus is found. However, the engine knows absolutely nothing about the viruses themselves and is almost useless without the signature database.
The signature database (also known as the dat file by some vendors) contains the fingerprints (snippets of distinctive code) of hundreds of thousands of viruses. As new viruses and variants appear at an accelerating rate, it is imperative that the signature database be updated often. In 1995, the experts advised updating the database files at least once a month, but with so many viruses appearing each day, users today are advised to update daily. AV manufacturers now provide products that check for updates automatically and download changes whenever a user is connected to the Internet.
The database also contains the rule sets used in the heuristic scans. These types of scans can be slower and more intrusive than simple signature scans, and their design and implementation vary greatly between products. Most products now give users configurable options to lessen or increase heuristics as desired. Although signature scans can be considered a heuristic in themselves, the term is more commonly used to identify the more complex AV functions that attempt to locate viruses by identifying suspicious behavior and/or file structure.
Because the distinction between a scanning engine and a signature database is not obvious to many system administrators, many religiously update the database but are unaware that the engine also may need updating. This is a poor strategy that can result in many viruses slipping by the scanner undetected.
41.4 SCANNING METHODOLOGIES.
AV products are configurable by the user or the system administrator to scan upon startup, constantly, or on demand. They can also be host-based scans or individual workstation scans. To be at its most effective, a scanner should be set to a continuous or “on access” scan, with a periodic, scheduled scan set to occur when the system is on but not in use. Users running older, slower AV programs will find that this degrades the system performance. Some scanners need to use much of the system's memory on continuous scans in order to be able to test sections of code, which may make the applications noticeably slower when they first run. Therefore, a happy medium must be found—the AV scanner must be able to protect the system, while the user must be able to have full use of the system.
There is no one scanning method that is superior to the others. All of the scanning methods have their advantages and disadvantages, but none is able to detect viruses with unfailing accuracy. A scan is looking for code and behaviors that have been noticed in other viruses, and if a new virus exhibits new, previously unknown behaviors, it can pass by undetected. Therefore, most AV scanners do not rely on only one scanning method to detect viruses, but have several included in their design.
41.4.1 Specific Detection.
Each virus uses different code to perform its functions, such as copying itself from one executable file or host system to another. The sequence of code that is specific to each virus is referred to as the fingerprint, or signature of that virus. To detect the presence of a virus, the scanner looks for the signature, removes its code from the host file or system, and attempts to restore the infected program or system to an uninfected state. In early viruses, it was discovered that the signatures were usually found within specific areas of a program, specific to each virus. The scanners set out to inspect only those areas of a file rather than scanning an entire program from top to bottom. This saved vast amounts of time and processing power.
Every vendor's AV product has a different implementation of scanner and database, although the signature scanning technique is the most common. Signature scans can identify whether a program contains one of the many signatures contained in the database, but it cannot say for certain whether a system has actually been infected by a virus (e.g., the virus may be present but not yet executed). Users can only trust the guess of the AV scanner, because the odds are in the scanner's favor. It is possible, however, that a program that is suspected of being infected actually contains random data that only coincidentally looks like a virus signature. The legitimate program could contain instructions that by sheer chance matched the search string in the virus database. However, when there is a possibility that the code is actually from a virus, the scanner reports it as a positive hit.
False-positive reports are a possible problem of signature scanners. If users notice that their scanner falsely reports the presence of viruses too often, they view this as an annoyance, and will likely seek to disable the software or find ways of circumventing the scans.
41.4.2 Generic Detection.
As was discussed earlier, malware is now often created for financial purposes, and it makes fiscal sense for its authors to get as much use as possible out of successful creations. They often make open-source code that is shared widely in the malware-author's community, so that it is often updated with new functionality such as exploit-code or password-stealing capabilities, to target new games, applications, or online banking sites.
Likewise, it makes sense for AV scanners to look for common properties of popular virus and Trojan families, in order to proactively detect variants based on those codebases. These generic detections can vary from being more heuristic in nature, to being fairly specific, depending on the complexity of the codebase or on the number of variants that have been distributed.
Generic detection is one of the newer techniques used by AV scanners, and it caused a great deal of controversy in the early days of AV products. There was concern, when most viruses spread by infecting clean files parasitically, that generic detection would require generic cleaning, which could leave host files mangled beyond repair or usability. As the vast majority of malware now infects systems rather than host files, simple deletion of malicious files and cleaning of registry entries are often all that is required to return a system to its original state. Generic cleaning routines are now quite common and are very effectively used to repair infected machines.
41.4.3 Heuristics.
By adding heuristics to their AV scanners, vendors looked to increase the efficacy of their products. The scanners could now look for viruses that were new and unknown and not contained within the signature database.
The word “heuristic” comes from a Greek word meaning “to discover.” The term is used today in computer science to describe algorithms that are effective in solving complex questions quickly. A heuristic algorithm makes certain assumptions about the problem it is trying to solve. In the case of an AV scanner, it analyzes a program's structure, its attributes, and its behavior to see if these meet the rules that have been established for identifying a virus, even without its specific signature being known. Basically, a heuristic algorithm works on the assumption that if it “looks like a duck, walks like a duck, and sounds like a duck, it must be a duck.”
The drawback to heuristic scanning is that it makes intelligent assumptions but is nevertheless bound to make mistakes. Another problem with heuristic scanning is that, on slower systems, it may take longer to run and may require user interaction. Some users consider this intrusive and may turn off the feature. By combining both signature scanning and heuristic scanning in their products, AV vendors have increased their effectiveness and speed.
Heuristic scanners use a rule-based system to verify the existence of a virus. It applies all the rules to a given program and gives the program an overall score. If the score is high, there is a good likelihood that a virus is present. Generally, the scanner looks for the most likely location for a virus to attach itself to a program. This is a crucial step because program files can be tens of megabytes in size. A well-designed heuristic scanner will limit the regions of the program to be examined in order to scan the highest number of suspects in the shortest possible time. The scanner then examines the logic of the suspected program to determine if it might be a virus. This is considered to be a static scan. The static method applies the rules and gives a pass/fail score to the program—whether the program has actually executed or not.
The other type of heuristic scanning is called the dynamic method. This method applies basically the same rules as the static method, and if the score is high, it attempts to emulate the program. Rather than examining the logic of the suspected code, the dynamic scanner runs a simulation of the virus in a virtual environment. This technique has come to be known as sandbox emulation, and is effective for attempting to identify new viruses that do not appear in the signature database.
Neither of these heuristic scanning methods is necessarily better than the other, but in concert they give fairly good results. Although a static heuristic scan may miss some viruses because they have not yet executed and started an infection, the dynamic heuristic scan can catch previously unknown viruses before they execute. Between heuristic and generic detections, it is becoming increasingly frequent for at least one AV vendor to identify any new virus as soon as it is released.
41.4.4 Intrusion Detection and Prevention.
As more complex viruses appear at an increasingly prodigious pace, scanning programs solely for signatures has become less effective at finding viruses. Virus authors use encryption or obfuscation techniques, or release a large number of individual variants in the hopes that the AV scanner will not find them. Today's operating systems and legitimate programs have bloated to millions of lines of code, so that finding a virus signature may be resource intensive. Because viruses and Trojans are malicious and may steal valuable data or damage systems, it is not a good strategy to let them infect and then attempt to clean up the mess. A better strategy is to try to find malware before it has had a chance to infect a system and to prevent it from doing harm.
The use of a cyclical redundancy check (CRC), or checksums, was added to some security products, including AV suites, to aid in the detection and prevention of virus infections. This method tracks unauthorized file and system changes, as when a virus or a hacker enters and alters a system. To track those changes, a fingerprint of each executable program and data file is computed and stored in a database when the AV product is first installed. These fingerprints are quite small, usually consisting of less than 100 bytes of information—this is the “sum” or checksum. Because viruses must add or change files on the system in order to infect them, the checksums of the fingerprints are compared with any newer version. If the checksums vary, then the AV scanner runs other routines to investigate further. If the change in the size of the program cannot be attributed to a known virus in the signature files or to a legitimate operation, then a generic disinfection routine is run to see if it can restore the program to its original state.
In the case of intrusion prevention systems, a behavior-based scan is executed on each new file when it is run. If certain suspicious behaviors are observed, a user may be asked whether the behavior should be allowed to continue. If a sequence of behaviors is observed that is sufficiently malicious, the program may be halted entirely. This technique has been found to be remarkably effective in preventing execution of new, unknown viruses, although it shares the same sort of difficulties found with using heuristic scans. Again, as part of a complete security arsenal, it can be a valuable tool. For more information on intrusion detection and intrusion prevention, see Chapter 27 in this Handbook.
41.5 CONTENT FILTERING.
In the early days of virus infections, computer security experts often allayed the fears of computer users by telling them that they could never catch a computer virus from e-mail. This assurance was based on the fact that e-mail was almost exclusively composed of ASCII text documents, with no ability to execute program code. At the same time, the skeptics were saying “never say never.” The skeptics won. First, there were several waves of macro virus–infected documents sent as file attachments to e-mail. This led to the modified assurance from security experts that no one could ever catch a computer virus from an e-mail message attachment, if the attachment was not opened. Then virus writers started embedding commands that use HTML and the scripting capability of e-mail programs. This led to the further modified assurance from experts that a computer virus could not be caught from unopened e-mail. This assurance in turn proved unwarranted, because e-mail preview capabilities were exploited to trigger malicious code even without user intervention. At one point, merely highlighting a message subject in MS Outlook was enough to execute an attachment, although this default was later changed.
Virus writers also began to exploit the user's e-mail facility by forwarding copies of the virus to entries in the user's e-mail address book. The Melissa virus was the first virus that really leveraged e-mail to spread rapidly. Since the Melissa virus, users have be advised to suspect just about any unsolicited e-mail. Virus writers are always looking for new delivery methods, and they were richly rewarded when e-mail programs began to allow executable code within the e-mail. Although users enjoy the point-and-click convenience of this feature, it is allowing new viruses to proliferate at a rate not seen before.
The Web also has seen an explosion in malicious code distribution, particularly since the advent of “Web 2.0”—social networking and collaboration sites. Through JavaScript and ActiveX controls that exploit vulnerabilities in Internet browsers or media-viewer software, malware and adware can be automatically downloaded and installed on users' machine without their being aware. This is commonly referred to as a drive-by download. Most recently, comments on forum or journal sites frequently try to entice users into going to those sites that contain malicious scripts for drive-by downloads.
Content filtering is an effective way of controlling Web and e-mail threats. It consists of a server-based application that interrogates all incoming and outgoing traffic, according to its configuration and rule sets. Early versions were cumbersome to configure, due to a text-based interface that required all rules to be composed in a laborious text editor. Misconfigurations were commonplace because administrators often were not sure which of the text files was causing a failure.
The new generation of content filters has increased user friendliness, using interactive graphic user interfaces to set and adjust policies. Administrators are able to fine-tune policies so that they meet the specific needs of their organizations. For example, all e-mail containing executable attachments may be blocked, quarantined, or simply deleted. This may be established as a rule, for some users or all users. The policy also may be set to strip macros out of all incoming e-mail, thus preventing any macro viruses from entering the system via this route.
Content filters have been used effectively in preventing infections of e-mail–borne viruses, even before the specific virus signature was even released. For example, when the security officer of one government office heard of the Love Bug virus on the morning news, that person set the content filters to block all e-mail attachments containing the extension “.vbs,” thus averting infection of a large network. No user interaction was required, and most users were not aware that the block had been placed. The costs and downtime of a virus attack were prevented.
41.5.1 How Content Filters Work.
These applications work in the same general manner that AV scanners do. They scan all incoming data on specific ports on the server, and they compare the traffic to rules and strings in the database. Because content filters are capable of blocking more than one type of file or program, they have the ability to scan text files, graphics, zipped files, self-extractors, and various executables. At this point many content filters contain AV scanners in the program, so if an e-mail does contain a virus, it can be intercepted and disinfected before it is sent to the recipient.
The standards for formatting e-mail for transmission using standard protocols have long been in place and detail the type of information in every section. It is easy for a program to look for particular information within these sections to determine what is included in the message—attachments, for example. Content filters first begin by disassembling a message to look at its various parts before scanning the message for the items to be allowed or denied into the system. Before sending the message onward, it is reassembled and checked for the conditions specified in the configurations. For example, a condition may state that any attachments be stripped and deleted, that the message body be sent to the recipient, and that an outward e-mail be sent to the sender stating that attachments are not allowed in e-mail.
In terms of computer security, a content filter adds several elements that are beyond the traditional AV scanner. For example, message and attachment content can be scanned for inappropriate material. This might be proprietary company information that employees should not be sending out via e-mail, or it could be offensive material, such as pornography, that should not be coming into the company's e-mail system. Content filtering also can stop the spread of common forms of spam mail, such as chain letters and get-rich-quick schemes.
41.5.2 Efficiency and Efficacy.
Speed of operations is a concern with content-filtering mechanisms, given the large volume of e-mail traffic in some organizations. However, because the operations are all contained within the server, the users will not notice any change in performance of their desktop systems; that is, the e-mail processing will be completed before the messages are received by the client systems. When the filters are examining large attachments, waiting mail will queue up, and delivery of mail may suffer for a period. Putting a limit on the size of attachments is one method of reducing these lags.
Content filters are also subject to the same failures as traditional AV scanners. New viruses can be missed if the data are not present in the scanning database. Additionally, the configuration of the product and the application of patches and updates are crucial to its successful operation. False positives are also a problem, where a legitimate message inadvertently includes content that triggers a block. It is possible to quarantine questionable messages and have a system administrator follow up with the sender. This can lead to refinement of the filters or to the detection of serious offenses. Before a content-filtering system is deployed, it is important to put in place the response mechanisms, so that abuses of e-mail policy can be addressed appropriately. This may well involve several departments besides security, including legal and human resources.
41.6 ANTIVIRUS DEPLOYMENT.
AV scanners can be installed on the desktop or on servers. Each strategy has its advantages and disadvantages. For example, if the system is server based, viruses on USB thumb drives, floppy disks, DVDs, and CDs on the desktop will not be scanned. The consensus of most experts, however, is to use both. With the advances in AV products and network management systems, it is entirely possible to install scanners on both the desktop and on servers while still maintaining an acceptable level of control and performance.
41.6.1 Desktops Alone.
If an organization's computer security policy allows unrestricted use of thumb drives, floppies, DVDs, and CDs, it imperative that AV scanners be deployed to the desktop. Unless these drives are locked or disabled, there is no way, other than scanning, to prevent users from accidentally introducing viruses. The preferences of a desktop AV scanner can be set to automatically scan external media.
Updates to desktop AV scanners can now be distributed via a central server. This is particularly effective when new signature files are needed to prevent infection by a newly discovered virus. The updates can be pushed to the desktop, and the users need not be present at the workstation, although the desktop system must be on and connected to the network at the time. If the updates are scheduled after working hours, it is important to verify that systems have updates pushed to them as soon as they log back into the network. Some AV products have management consoles that will allow this to occur automatically, rather than having someone check each system individually.
In order to prevent unauthorized AV-setup changes, it is possible to prevent the users from changing the configuration of their desktop AV scanners. Since that may not be the default installation, it must be checked. Again, with the use of a management console, it is possible to enforce security-software policies remotely.
41.6.2 Server-Based Antivirus.
Many companies have sought to bolster the defenses at the perimeter of their network by installing AV products on the server where downloads are frequently stored and traffic is high. A server-based AV scanner can be configured to send alerts to administrators when a suspected virus is detected. Like the desktop-based scanners, the response to a virus detection can be predetermined. Many system administrators set the program to erase all infected files rather than to send them to quarantine. This strategy works to lessen the possibility that a quarantined virus can be “released” by mistake.
41.7 POLICIES AND STRATEGIES.
In the battle against viruses, the promulgation of appropriate policies and the implementation of realistic plans of action are equally as important as the installation of an AV scanner. The policies should spell out in detail what actions are allowed or denied, and they should also be specific about the users' responsibilities. The policies and responsibilities should be updated whenever major changes occur in the organization or in the pattern of virus infections.
End user AV awareness training should be high on the list of priorities in every organization. Users are more likely to cooperate in preventing and quarantining infections if they are aware of the types of viruses that may infect the system and of the damage they can cause. A simple security-incident bulletin board in a central location is an easy and effective way to communicate with users. E-mail is probably not an effective method of distributing virus awareness because users become confused between the education effort, actual and legitimate virus alerts, and bogus virus alerts.
The roles and responsibilities of each person within an organization should be clearly defined and communicated to the general populace. For example, the responsibilities of an average user will be different from those of a system administrator, and the responsibilities should be reflected in their roles. An individual user's role may describe the actions required of the user if a virus is detected on a workstation, while the system administrator's role may describe how to handle the report from the user and prepare for disinfection.
Problems and catastrophes will usually occur when they are least expected, so every organization should have an emergency response plan in its policies. The emergency plan should detail the list of persons to be called in an emergency and the priority order in which they should be called.
For every major virus infection event within an organization, care must be taken that a “lessons learned” session be undertaken as soon after the event as possible. No matter how well written a policy may be, it cannot be proven effective until it is put into use. An actual infection will highlight the failures of a policy in action, which should be rectified before the next attack. For more on security policy guidelines see Chapter 4 in this Handbook.
For more details of computer security incident response team management, see Chapter 56 in this Handbook.
Management's support for such policies is vital. Support is required not only to approve the AV budget and the policies, but also to ensure that everyone abides by the policies. It is highly unlikely that users will follow a policy that upper management routinely flouts.
41.8 CONCLUDING REMARKS.
Both AV technology and malware technology have progressed rapidly over time, and AV technology largely remains in step with malware technology. The success of malware is now primarily due to financial motivation, but a large part of the reason it is such a lucrative business is that people continue to dismiss the threat of malware. However good AV technology gets, it will not make a serious dent in the malware problem unless it is appropriately implemented by organizations and properly employed by users who act responsibly. As AV technology continues to improve and becomes better understood, we hope that it will continue to be used more widely and more wisely.
41.9 FURTHER READING
Antiviral Software Evaluation: www.claws-and-paws.com/virus/faqs/evaluation.html.
Aycock, J. D. Computer Viruses and Malware. New York: Springer, 2006.
Grimes, R. A. Malicious Mobile Code: Virus Protection for Windows. Sebastopol, CA: O'Reilly, 2001.
IBM Research—Antivirus Research Papers: www.research.ibm.com/antivirus/SciPapers.htm.
Johnston, J. R. Technological Turf Wars: A Case Study of the Antivirus Industry. Philadelphia: Temple University Press, 2008.
Nazario, J. Defense and Detection Strategies against Internet Worms. Artech House, 2003.
Skoudis, E., and L. Zeltser Malware: Fighting Malicious Code. Prentice Hall, 2003. Spyware/AdWare/Malware FAQ: www.io.com/~cwagner/spyware/.
Szor, P. The Art of Computer Virus Research and Defense. Addison-Wesley, 2005. Virus Bulletin: www.virusbtn.com/index.
41.10 NOTE
1. WildList Organization: www.wildlist.org/faq.htm.