Fred Cohen
Computers & Security, Volume 10, Issue 3, pp.239-250
ISSN 0167-4048
May 1991
Download PDF (91.28Kb) (You need to be registered on forum)Search Terms: Computer Viruses, Computer Risk Analysis
Copyright © ASP, 1990 ASP Press, PO Box 81270, Pittsburgh, PA 15217
Various properties of computer viruses have been studied at length by many authors [1], but one of the areas where research results are relatively rare is evaluation of the costs of defenses. In this paper, we explore the costs of computer virus defenses in typical computing environments.
The major computer virus defenses in widespread use today are “scanners” [2], “monitors” [3], “cryptographic checksums” [4], and “integrity shells” [5]. Other practical techniques that are viable for this purpose, but have not been put into widespread use as virus defenses are limited function [6,7], limited sharing [6,7], and sound change control [8].
Virus scanners are programs that search for known computer viruses. They normally work by searching some of the files on a disk for known and easily detected viruses. Some scanners also use special indicators to detect harder to identify viruses. For example, some viruses force the seconds field in the file modification time under DOS to 61 seconds, and some scanners use this as an indicator of that virus. Most virus scanners only cover viruses in binary executable files and only cover viruses that have fixed locations relative to the start of a program. Viruses with more complex infection mechanisms (e.g. random placement within a program), complex evolutionary viruses, and viruses that infect interpreted files (e.g. “Basic” viruses), are rarely scanned for by modern scanners. This is because these types of scans require complete examination of files, and thus a lot of time.
Cryptographic checksums are hard to forge many-to-one transforms that typically take a user supplied key and file, and produce a number [4]. By summing files with this technique and subsequently checking them on a regular basis, we can usually detect unauthorized changes, even when an attacker is trying to avoid detection.
Integrity shells are command interpreters that look for changes in interpreted information before interpreting it. They normally use cryptographic checksums for detection, can detect all primary infection and prevent all secondary infection, and are optimal for virus defense in untrusted systems [5]. Integrity shells can check all interpreted information, not just binary executable files.
Virus monitors are programs that look for known viruses each time an executable program is run. This is a special case of the integrity shell technique, where instead of using a cryptographic checksum to detect change, we look only for known viruses. Like scanners, monitors typically look only for viruses with simple infection mechanisms at known locations.
We will abbreviate as follows:
 Total for scanner | s systems |
 Total for crypto checksum | c checks/year |
 Total for monitor | e employee cost/min |
 Total for integrity shell | u (d)(update-count) |
 minutes per scan |  minutes per check |
 license for scanner |  license crypto-checksum |
 license for monitor |  license integrity shell |
 new attacks |  old attacks |
 system cleanup costs |  file cleanup costs |
 distribution costs |  comm-rate[K/c] |
Most of these terms are self explanatory, but a few are a bit obscure. The licensing cost for crypto-checksums and integrity shells is normally a one-time cost, whereas for scanners and monitors, regular updates force licenses to be paid over time. To compensate, we use 10% per year of the total licensing cost for integrity shells and crypto-checksums as an equivalent to the yearly licensing cost for scanners and monitors. oi is a term that describes the rate of spread of a virus, and has experientially been about 2 for a typical PC in a typical environment, and about 10 for a typical PC in a LAN environment. The update count is the number of times per year we do updates of scanners and monitors (which require updates to stay effective), and the distribution cost is the cost of each distribution (or redistribution) and installation of a software package.
We will also assume, for comparison purposes, that all performance is measured relative to a 4 Mhz PC-XT with 65 msec hard disk drives. Many current processors are far faster. For example, it is not unusual to see a 32 Mhz PC with an 18msec hard disk, which would be from 20 to 30 times faster than our assumed performance levels. Performance variations will also be discussed later, so we hope to cover this difference at that time.
Another important assumption we make is that the number of attacks per year does not vary with the number of systems. This is clearly not a valid assumption in many cases. To compensate for this, we discuss the effect of making the number of attacks linear in the number of systems.
Most scanners and monitors are licensed on a per system per year basis. They require regular updates and must be used on a regular basis in order to be effective. They cover some viruses, and don’t cover others, and there is a significant delay between the initial release of a virus and its inclusion in scanners and monitors. For most organizations, there is a substantial cost associated with the cleanup of a virus once detected. The more often we scan, the less a virus spreads before detection, but at the same time, scanning takes a significant amount of time, and that time can be quite costly when spent on a large number of systems on a regular basis.
The yearly operating cost of performing checks, assuming that employees are relatively idle while the checks are being done, is the number of checks per year times the employee cost times the time required for each scan. The update cost is the cost of distribution and installation times the number of updates per unit time. The license fee is set contractually. All of these are linear in the number of systems being scanned, so the yearly operating cost of performing scans is calculated as follows:
![s[cet_s + l_s + u]](../img/cache/1ba3153a141789cdab4006d52d748fd4.gif)
Typical figures are; one check each working day (usually at bootup), US$20 per hour (1/3 of a dollar per minute) for idle employee costs, 3 minutes per bootup scan, US$10 per year for licensing fees, US$5 per update, and 4 updates per year. Thus the yearly operating cost per system of scanning comes to:
The most striking thing here is that licensing costs are the least important factor in the cost of scanning. Even the update cost, which tends to exceed licensing cost, is trivial compared to the cost of performing daily checks. By using weekly checks instead of daily checks, or by scheduling coffee breaks during checking times, the cost of checking can be dramatically reduced. Unfortunately, scanning is usually done at system startup, and employees tend to sit and wait for the system to become ready at startup.
If there are viruses in the environment, the situation changes considerably. For viruses that are not detected by the current version of the scanner, it is a reasonable assumption that they will spread throughout all of the systems in the environment over a period of days to months, depending on the communications methods in use. We also assume that eventually, a cleanup will be necessary or desired, and for the moment, we will assume that there are no side effects of the virus such as data diddling, file deletion, etc. [9] Cleanup costs are assumed to include all down-time of equipment, employee time spent on cleanup, and time wasted while awaiting cleanup. Thus we calculate the “new attack cost” as follows:
It is hard to assess a typical environment today because of poor reporting, poor detection, and a general lack of statistical data on the subject. According to the IBM high integrity research laboratory [10], they don’t find out about a virus until it has spread to about 10 major organizations. They were finding new viruses at a rate of more than one per week as of February, 1990. If a complete system cleanup costs $100, you would expect to spend $100 per system per year in cleanup costs from each new virus.
For known attacks that enter the environment, a regularly used scanning program can be quite effective in limiting damage. The spread of a virus in a computing environment is actually quite complex, and substantial work has been done to make an accurate model [11]. Another less accurate model that assumes an infinite population and homogeneous communications predicts (not surprisingly) exponential spread [12]. For simplicity, we will take the position that exponential spread occurs based on the communications rate, but is limited by the number of systems available for infection. Spread rate has been found to be 10 times larger in a networked environment than in an environment without networks [10], and clearly this should be taken into account. The old attack cost can then be calculated as:
![a_o r_s \min[s,o_i]](../img/cache/578501150fd06b78e2e91f7aee9c0035.gif)
In this model, as the checks per year goes down, the system tends towards increased cleanup costs. K can be calculated based on measured spread rates. Our observations have indicated that a virus in a non-networked environment spreads to 2 systems in the first day, 4 in the second day, etc. Thus, for a comm-rate of 2 for non-networked systems (20 for LANs), a check every business day, cleanup costs of $100 per system, 3 old viruses per year, and any number of systems over 2, we get a yearly cleanup cost as follows:
]=$600For a LAN environment with 20 old viruses per year, 20 or more systems, and all other factors being equal, we get:
]=$40,000If we try to reduce checking costs by only checking once per week, we find that the expected loss from attacks goes up exponentially. For example, in the LAN environment above, we get:
]=min[($2,000s),$200,000,000]Checking often is very important in terms of reduced cleanup costs when viruses appear, and this tends to dominate all other factors when checks are done infrequently.
The total cost, not including any side effects caused by viruses, is simply the sum of the costs we have given so far and a one-time initial distribution cost. The cost per system per year is then simply derived.
= yearly-operating-cost + new-attack-cost + old-attack-cost + d
There are some other time related factors in considering the future of virus scanners. For example, a typical scanner (circa 1/1/90) on a PC-XT, took 3 minutes per scan and reliably scanned for about 50 file viruses. As of 9/1/90, these figures were up to over 200 viruses, and scan times of about 15 minutes. If this trend continues, we will see 1 hour scan times within the next year or two! If virus designers continue to improve their techniques, as they have been doing lately, scanners will have to begin full searches in order to be effective against new strains of viruses. This will increase scanning times by at least an order of magnitude, and there is no reason to believe that other factors will compensate for this reduced performance.
Virus monitors are essentially the same as virus scanners except that they exploit the integrity shell concept to eliminate most of the cleanup costs and dramatically increase scanning rates without dramatically increasing scanning costs. Since a scan of each program is performed before it is run, like the integrity shell, a monitor detects primary infections and prevents secondary infection by known viruses. Some state-of-the-art monitors even have special purpose routines for removal of many known viruses, thus eliminating most of the costs of repair.
Because checking a single file for a known virus is currently very fast, there is no real penalty for the checking time. Thus we get the modified form of the scanner equation.
![s[l_m + u]](../img/cache/cdf5d9489c7904a310b5cd9088fb2fe3.gif)
Using the same basis as was used for scanners above and a $5 per year licensing cost, the cost per system for using monitors comes to only:
In this scenario, we can even afford to distribute new versions of the monitor every month and save money over the scanning program. At 12 distributions per year, we only get $65 per system per year, around 1/4 of the cost of scanning.
The cost of unmonitored attacks with a virus monitor are the same as the costs for a scanner, thus we get:
The cost for monitored attacks goes down considerably with a monitoring system because there is effectively no delay between the introduction of a virus and its detection. In essence, a known virus planted in a program is detected before it is ever used, and thus before it can spread at all. The cleanup costs for monitored attacks is also very low, since it involves only the replacement of a single file.
With an automated cleanup facility, this cost goes to very nearly zero, but since the cost is so low to start, it does not have a noticeable impact on overall attack costs unless the number of known attacks is very large and the number of unknown attacks is very small.
As in the case with scanners, monitors have total costs as follows:
= yearly-operating-cost + new-attack-cost + old-attack-cost + d
Cryptographic checksums can be used in a manner similar to scanners, in that they are periodically run to check for the presence of viruses, but there are significant differences between the two technologies.
The major disadvantage of cryptographic checksums is that they take longer than most current scanners because they have to perform analysis on the entire file instead of looking only in a few key places. Eventually, scanners will also have to do this to remain effective (even now, some viruses cannot be detected by scanners without a fill file scan), and when that time comes, cryptographic checksums will be faster because they perform simpler operations than the multiple string search operations required by full file scanners.
The major advantages of cryptographic checksums are that they detect (probabilistically) all modifications, and thus detect all viruses, whether previously known or previously unknown [4], and thus they don’t require updates. Current high speed cryptographic checksums operate at a rate of about 20 Kbytes per second on a standard PC-XT running at 4MHz. A 20Mbyte disk thus takes about 1,000 seconds to verify, or about 10-15 minutes depending on the file structure complexity. This is only 3 times the time required for a scanner circa 1/1/90, and comparable to the time for the most thorough scanners circa 9/1/90.
The yearly operating costs can be calculated as shown below. Notice that there are no update costs, but that for the time being is higher than by a factor of 1 to 3.
![s[cet_c + l_c]](../img/cache/50729dcd050110d654416169a3630906.gif)
There is a minor difficulty in calculating licensing costs because unlike scanners, checksum programs do not have to be periodically updated. As a result, they are usually purchased once, installed once, and paid for all at one time. To keep costs in yearly terms, we assume that the one-time cost of a checksum program is paid at a rate of 10% of the purchase cost per year. Thus, the yearly licensing cost of a checksum program is taken to be 1/10 of the one-time licensing cost.
Typical figures for a large number of systems are $50/system in licensing fees ($5/system/year). We can operate at 3 minutes/check if only executable files are checked (which is comparable to the case for scanners and monitors). Everything else remaining the same, so we come to a typical cost of:
As in the case of scanners, the dominant cost is the cost of using this technique every day. The cost of all attacks under a cryptographic checksum system are the same as the cost of known attacks for virus scanners, while the total costs are the sum of attack costs and checking costs.
![(a_o + a_n)r_s \min[s,o_i]](../img/cache/4ebd346da8d8715b474250cebbe3c0e3.gif)
= attack-cost + yearly-operating-cost + dIntegrity shells are similar to cryptographic checksums in that they don’t require updates, and similar to monitors in that they don’t have daily checking overhead and are optimal in their detection of attacks, thus preventing viral spread. Thus the yearly operating cost for integrity shells comes to only the licensing fee.
As with checksumming systems, integrity shells do not require periodic updates, so we will again treat the yearly licensing cost as 10% of the one-time licensing fee.
Attack related costs with integrity shells are the same as monitored attack costs for virus monitors. As with monitors, state-of-the-art integrity shells completely automate the repair process for known and unknown corruptions in most cases, but there is an overhead associated with this repair (this will be covered in detail later)
Thus we have the total cost of integrity shells as:
In large quantities, integrity shells cost about $50/system, which comes to a time deferred cost of $5/system/year. Assuming that there are 3 known and 2 unknown attacks per year, and that the cost for a single file cleanup is $10, the total yearly cost for integrity shells, including all costs of attack and defense, comes to only $[50+5s +5]! For an operation with 100 systems, this comes to a total of $555, or only $5.55/system/year.
We start by restating the total costs from the four techniques under consideration:
![T_s = s[cet_s + l_s + u] + a_n r_s s + a_o r_s \min[s, o_i] + d](../img/cache/2e84200f2e3286f1a663242fa62dc2c5.gif)
![T_c = s[cet_c + l_c] + [a_n + a_o]r_s \min[s, o_i] + d](../img/cache/b918c3999601905a4967bc5cebd503e0.gif)
![T_m = s[l_m + u] + a_n r_s s + a_o r_f + d](../img/cache/9eb91586908f4e136f8282a57d08645a.gif)
![T_i = sl_i + [a_n + a_o]r_f + d](../img/cache/4c5aef3f8081058d59565bbb3c9de5ea.gif)
The assumed values used for comparison above were:
 | 250 |  | 1/3 |
| 3 | | 3 |
| 5 | | 5 |
| 5 | | 5 |
| 2 | | 3 |
| 100 | | 10 |
| 5 | | 2 (no LAN) |
 | 20 | | 20 (LAN) |
We will assume for comparison purposes that 
(i.e. we always detect viruses before all systems are infected), and thus simplify ![\min[s, o_i]](../img/cache/cbf5c1a5e1e6fce8c2f00afa56836588.gif)
to .
To make comparisons, we will subtract equations. We begin by comparing to as follows:
![\begin{eqnarray}
\text{Term 1} & & \text{Term 2}\\
T_s = s[cet_s + l_s + u]&+& a_n r_s s + a_o r_s o_i + d\\
T_c = s[cet_c + l_c] &+& [a_n + a_o]r_s o_i + d\\
T_s - T_c = s(ce[t_s - t_c] + [l_s - l_c + u]) &+& a_n r_s[s - o_i]
\end{eqnarray}](../img/cache/3f7b074da99bdd5bed084dc7f2e799ab.gif)
Unless checking is so rare that all systems get infected before checking detects an infection, 
, and dividing by s, we get a per system cost difference of:
![ce[t_s - t_c] + u + [l_s - l_c] + a_n r_s](../img/cache/ce74776453ba62327dd95ec6d5dcc6e4.gif)
With daily scanning or checking, any reasonable difference in licensing fees 
are dominated by scanning and checking costs 
. Update costs (u) also tend to dominate licensing fee differences for this sort of system, so we can simplify in most cases to:
so scanners are less expensive if and only if:
In other words, if update costs and recovery costs from new attacks combine to exceed the checking cost difference between the two defenses, scanners are more expensive than cryptographic checksums. Using our previous numbers, we compute:
As we see, if scanning and checksumming times are equal, scanners are always more expensive (assuming that licensing fee differences are not extraordinary). Put another way, if scanning and checksumming times are equal, the update costs and new virus eradication costs must be less than the licensing fee difference in order for scanners to be less expensive. For 4 updates per year at $5 per update, and assuming no unscanned for attacks, a checksumming system would have to cost $200 per system more than a scanner in order to be less cost effective ($200 at 10% per year is the same as $20 per year licensing fees). The only advantage of scanners for large numbers of systems is faster scan times, and this advantage will probably not last long.
We now compare scanners to monitors:
![\begin{eqnarray}
\text{Term 1}& &\text{Term 2}\\
T_s = s[cet_s + l_s + u] &+& a_n r_s s + a_o r_s o_i + d\\
T_m = s[l_m + u] &+& a_n r_s s + a_o r_f + d\\
T_s - T_m = s[cet_s + (l_s - l_m)] &+& a_o[r_s o_i - r_f]
\end{eqnarray}](../img/cache/7fc9d226b914c039633cb5fd66bcfdfa.gif)
We assume that licensing fees for scanners and monitors are approximately the same relative to scanning costs (![[l_s - l_m] = 0](../img/cache/ac4a5d8f8f2b2248bfdb8d7ee9abefb7.gif)
). We also note that 
for any reasonable scenario, and the cost to clean a system is normally far greater than the cost to clean a single file (
). We then get:
Since all of the terms are positive, is always greater than , and thus scanning costs always exceed monitoring costs.
We now quickly look at the relative costs of checksums and integrity shells:
![\begin{eqnarray}
\text{Term 1}&&\text{Term 2}\\
T_c = s[cet_c + l_c] &+& [a_n + a_o]r_s o_i + d\\
T_i = sl_i &+& [a_n + a_o]r_f + d\\
T_c - T_i = s[(l_c - l_i) + cet_c] &+& [a_n + a_o](r_s o_i - r_f)
\end{eqnarray}](../img/cache/4a44ab257d94e6124500cb1ab52aeb0b.gif)
Assuming that licensing cost differences are not large, we can drop the (
) term. Since () for any reasonable system, and () as we discussed earlier, we simplify to:
![T_c - T_i = scet_c + [a_n + a_o]r_s o_i](../img/cache/4b23779554219227a97278c69d99aa1f.gif)
Since all of these terms are positive, is always greater than , and thus integrity shells are always more cost effective than cryptographic checksum programs.
Finally, we will compare integrity shells to monitors:
![\text{Term 1}&&\text{Term 2}\\
T_m = s[l_m + u] &+& a_n r_s s + a_o r_f + d\\
T_i = sl_i &+& [a_n + a_o]r_f + d\\
T_m - T_i = s[(l_m - l_i) + u] &+& a_n r_s s + a_o r_f - [a_n + a_o]r_f\\
= s[(l_m - l_i) + u] &+& a_n[r_s s - r_f]](../img/cache/82ebe06147a2555662078aa23b0b1135.gif)
The number of systems (s) is always at least 1, and as before, (
). If we assume that yearly licensing cost differences (
) are small compared to update costs (u), we get a per system cost difference of:
We conclude that integrity shells are always less expensive than virus monitors because all of these terms are positive. The cost difference comes from the added update cost required to keep monitors up to date (u), and the cost of cleanup for attacks that monitors don’t detect (
).
Another way to look at this, is that the yearly licensing cost of an integrity shell must exceed the yearly licensing cost of a monitor by the update cost and the undetected attack cleanup cost in order for a monitor to be more cost effective than an integrity shell.
For u = 20, free monitor licensing, and assuming no unmonitored attacks ever take place, integrity shell license costs would have to exceed $200 per system ($20 per system per year) to be less cost effective than monitors.
We assumed the time for monitors and integrity shells to check information at runtime to be negligible. The actual time (assuming PC-XT at 4Mhz, 62ms disk drive) is currently about 0.5 seconds for a typical monitor, and 20Kbytes per second for an integrity shell. The average DOS program is only about 17K bytes in length [13], so we would expect an integrity shell to take an average of 0.85 seconds, or about 0.35 seconds more than a monitor. Since a typical scanner takes 3 minutes and is used once per day, you would have to run about 211 programs per day, or one program every 2.5 minutes for integrity shell time costs to equal scanning costs. With monitors, this is one program every two minutes.
In typical secretarial environments, only 10 or 20 programs are run per day, and while programmers tend to run more programs, they tend to run smaller programs, and they tend not to wait for them to finish before going onto the next task. Furthermore, most environments now have much faster machines, and the programs being run have significant startup times that cause the relative costs of monitors and integrity shells to be far less important. For example, on a 32Mhz PC with an 18msec disk drive, integrity shells take under 1/10 of a second per program, while the most thorough scanner still takes over 1 minute to check the executables at startup.
Performance enhancements help cryptographic checksums and integrity shells a lot, but their impact on scanners and monitors is not as nice. As performance gets very high, scanning and monitor times are reduced, but periodic redistribution costs are not affected. We show the basic equations again:
![\begin{eqnarray}
T_s = s[cet_s + l_s + u] &+& a_n r_s s + a_o r_s o_i + d\\
T_c = s[cet_c + l_c] &+& [a_n + a_o]r_s o_i + d\\
T_m = s[l_m + u] &+& a_n r_s s + a_o r_f + d\\
T_i = sl_i &+& [a_n + a_o]r_f + d
\end{eqnarray}](../img/cache/a54fc04c225ec2a476aa5a335e2e83ca.gif)
For very fast systems, we assume that 
and 
, and get:
![\begin{eqnarray}
T_s = s[l_s + u] &+& a_n r_s s + a_o r_s o_i + d\\
T_m = s[l_m + u] &+& a_n r_s s + a_o r_f + d\\
T_c = sl_c &+& [a_n + a_o]r_s o_i + d\\
T_i = sl_i &+& [a_n + a_o]r_f + d
\end{eqnarray}](../img/cache/0eddef057780a2a4fdd9a1dd025a7828.gif)
If 
, and are about equal, and asusming that 
and , we then find differences as follows:
![T_s - Tm = s[l_s - l_m] + a_o[r_s o_i - rf] = 0 + a_o r_s o_i](../img/cache/58d0c99b943c3a09e705b36018e749a8.gif)
In other words, scanners and monitors differ only by repair costs from known viruses spreading to a relatively small number of systems ().
Since 
and and , we get:
![T_m - T_c = s[u + a_n r_s] - a_o r_s o_i](../img/cache/95431137951e2a53970768b7ddf8e5f8.gif)
In this case, the only circumstance where (
), and thus where monitors are cheaper than checksums, is the case where:
![s[u + a_n r_s] \lt a_o r_s o_i](../img/cache/3dac6f9b08336f8bf83416eb2d660419.gif)
In other words, in cases where update costs (u) and new virus cleanup costs () are less expensive than cleaning old viruses spreading to a small number of systems (
), monitors are more cost effective. With large numbers of systems, in order for monitors to be less expensive than checksums, the number of old viruses would have to out number the number of new viruses by a factor equal to the number of systems. For an environment with 1,000 systems, that would mean 1,000 entries of old viruses would have to take place for every entry of a new virus in order for monitors to be more cost effective than cryptographic checksums. Clearly, as performance goes up, cryptographic checksums are more cost effective in large organizations.
Since performance is not an issue, we could theoretically check for viruses quite often without significant penalty. In the extreme, we could perform checksums every few seconds, and thus limit the spread of viruses to a very small portion of a system. In the limit, this is what an integrity shell does, except that it only checks those files which have to be checked when they have to be checked.
Integrity shells again come out on top as follows:
![T_c - T_i = 0 + [a_n a_o][r_s o_i - r_f]](../img/cache/e48b1c72ce7e214ccd3adf6343b7cdc7.gif)
Since 
, and integrity shells beat out cryptographic checksums. Our high performance assumption has no effect on 
, except that it removes any minor advantage of monitors due to faster checking times at program invocation.
Another cost related to monitors, scanners, integrity shells, and cryptographic checksums is the cost of automated repair, on-line backups, and manual repair with off-line backups. We begin with automated repair, which is essentially free (except for licensing costs) if done properly. To do this properly, we must make certain that we only cure known strains of known viruses. Only one product currently on the market is reliable in this way, but we assume that diligent effort will improve this situation with time.
On-line backups have real costs in terms of the disk space required to keep redundant information. In their simplest form, on-line backups double the disk space for all covered files. In a sense, the comparison here is unfair, because on-line backups can be used to cover all information, including data files, interpreted files, and other non-binary non-executable information. On-line backups can also repair unknown and known viruses as well as any other corruptions to stored information whether intentional or not. Thus the cost of coverage must be deferred over all corruptions for integrity shells and cryptographic checksums (which detect all corruptions), but only deferred over known viruses for monitors and scanners (since they don’t detect any other corruptions). This enhances the case for cryptographic checksums and integrity shells still further.
The cost of on-line backups is directly related to the cost of disk space. Current retail costs of disk space for personal computers runs in the range of $20/Mbyte for small disks, and $10/Mbyte for large disks. Most systems have relatively small disks, so let’s use the $20 figure for the purpose of analysis. Assuming we are only covering binary executables with on-line backups, we only need to cover a small portion of the space on a typical system. A typical user PC has under 2Mbytes of its disk space taken by executable files (based on a very small survey of development systems). This would then come to a one-time cost of $40 per system for storage of on-line backups, or as we did with licensing fees, $4/year/system.
Unfortunately, this makes the assumption that you can buy disk space by the Mbyte, which you cannot. If you have extra disk space, on-line backups are essentially free, and if you don’t, they are quite expensive. A rational approach might be to use on-line backups when there is available disk space, and use off-line backups when there is inadequate disk space.
Regardless of the technique applied for virus eradications, it has no significant impact on other virus related costs, since any eradication technique can be used with any detection mechanism. There is a tendency in the market, however, for integrity shells to use on-line backups, and for monitor to use customized cures. Clearly, we can mix these techniques as we desire, and perhaps an approptiate mix will give us the best of both worlds.
We have also left out a major factor in the cleanup costs of monitors and scanners. If we are to do a thorough job of cleanup, we must not only remove viruses from on-line files, but also from backups. Otherwise, the backups will be infected, and when we try to restore from them, we will restore the viruses as well as the other information. With checksums and integrity shells, this is not a problem because no undetected changes occur, and thus backups don’t become corrupted over a significant period of time, but with monitors and scanners, any time we get an update and detect a new virus, we must clean the entire history of backups in order to fully eradicate it.
Another closely related problem is that evolutionary viruses may release known strains into the environment. When we detect the known strain, we may be able to cure it, but we will not necessarily ever trace down its source, because it evolved from an unknown strain. This makes cleaning backups nearly impossible once an evolutionary virus of unknown origin infects the system over an extended period.
The only negative point we are aware of for cryptographic checksums and integrity shells, relates to the need to maintain the checksums as the files on the system change legitimately. These costs might dominate if cryptographic checksums and integrity shells had no provisions to deal with change. There are two factors that enhance the integrity shell’s position in this arena.
One factor is that the binary executables covered by monitors and scanners change very rarely, while the non-executables not covered by monitors and scanners change more often. Thus, in order to be competitive with monitors and scanners, integrity shells must only be able to deal with the small rate of change in binary executables. In a typical system, binaries don’t change more than once per year, so an automatic procedural method can often be used to maintain this mechanism.
As an example, in several organizations, the strategy has been adopted to issue an automatic resumming order whenever distributing an update to a binary executable. Thus along with the other installation routines on each widely distributed disk, comes a command to resum the new executables. This takes an extra few seconds during the installation process, but relative to other distribution costs, is trivial.
The second factor is that integrity shells on the market today have automation for handling change in a manner consistent with the organizational policy. Thus, if the organization determines that no changes are allowed without explicit user permission, this policy will be enforced. If changes are only allowed under specific conditions, those conditions can be explicitly and automatically enforced as well.
As an example, with a policy that no binary executable is to be trusted unless it has been explicitly checksummed during a distribution, no untrusted program (e.g. the AIDS disk of 1989) can be executed by the user. In the other extreme, a commonly used word processor changes its own binary executable to reflect user customizations, and may change itself at any time. This too is handled by integrity shells which can be told of this case and automatically resum this program after each execution, without leaving the window of vulnerability that would be present if we only resummed changed information on a periodic basis.
The net effect is that in a well controlled environment, controlling cryptographic checksums is a normal part of the change control process, and is essentially free after it is integrated into the environment.
We have provided a mathematical analysis of the costs of viruses and defenses for the most common defensive strategies. The analysis clearly shows that integrity shells are the most cost effective technique today in almost every case, and that their advantage over other techniques becomes larger as time passes, as performance increases, as the number of viruses increases, and as the number of systems being covered increases. Of the other techniques, there is a short period of time over which virus monitors will be more cost effective than cryptographic checksums in many cases, but as performance increases and the number of viruses increases, cryptographic checksums become better than monitors. Scanners, the most popular technique in the market at this time, are the least cost effective.
The analysis makes many assumptions about environments and viral spread, and some of them will be more or less valid in any given environment. This analysis is also not particularly deep, and it may well be that more thorough analysis will reveal more relevant information on the costs of viruses and defenses. Nevertheless, for a broad range of environments, the conclusions drawn seem to be valid.
Significant further work is called for in the area of mixed strategies for defense and the costs of other defensive methods. In particular, prevention through limited sharing and limited function should be explored for cost effectiveness, and mixes of all of these strategies should be considered.