Copyright Robert M. Slade, 1992
This article will outline, and explain, a checklist of steps that any
computer user can take to reduce the risk of computer viral program infection,
and increase the chances of detecting an infection early -- hopefully before it
has much chance to do any damage.
For the MSDOS world, this list can be obtained simply by printing a copy of the CONFIG.SYS and AUTOEXEC.BAT files. It may be felt that, because these files are present on the computer anyway, it is redundant to print them out. A fair point, but a booklet of this information at each computer will save time and trouble all round.
This, however, is not an insurmountable objection. The user does not have to understand what the listing means, only that a change occurs. As for generating the listing, that can be done by the qualified people who install the system. With DEBUG on the system, batch files can be written to show the user the first few lines of the current boot sector. It might also be a good idea to have printouts (of the most common) and batch files to check the boot sectors of floppy disks.
As will be noted in future columns, I recommend that all software be installed from "backup originals". These disks, or copies made after installation, should there be any customization involved, should be kept with the computer. This serves two purposes. It allows for quick access to "known clean" software for re-installation, if necessary. (These "originals" may reduce or eliminate the need for "full" backups of the system, as the software is often the larger portion of material on the user's disk, and generally the most stable.) It also provides a "baseline" for a quick check for any changes to the software.
Keeping a copy of the directory may help in other ways. Some malware, the "AIDS Information" trojan being a notable example, build extra directories in order to escape detection. Having a baseline copy of the valid directories gives one another means of detecting viral programs, rather than another place for them to hide.
For the purposes of this checklist, an office is defined as a group of people who interact on a regular basis. "Regular", for this purpose, need be no more than once per week.
An office is, therefore, defined less in terms of locale and walls than in terms of communication. For this definition an office may consist more of those working on a common project in far-flung cities than of those in the next cubicle whom we never speak to. However, it need not follow "official" reporting lines either. An office is defined more in terms of how fast you can find information when you need it. The items in this next section of the checklist are those which may not be referred to for long periods of time while things are going well, but which may need to be found quickly once an anomaly has been identified.
In the MS-DOS world, another possible source is the shareware summary list collated by Patricia Hoffman. While this list is more complete in covering the 1200 (1300? 1500? by the time you read this, who knows?) MS-DOS viri, it is, of necessity, less accurate at times.
Antiviral software, especially that which incorporates scanning, often includes listings of viri, their symptoms and features. Some of these are good, some less so.
All of these lists must be kept up to date, and it is probably an idea to have someone within the organization who is supporting the prepared lists with additional information from sources such as VIRUS-L.
This is a very difficult section to advise on. For my part, I can think of perhaps twenty people in the world of whom I could state, with confidence, that they were competent in the field. This is not to say that there are not more, but it is an esoteric field, with few standards to judge by.
The information is hard to come by, for one thing. The popular, and even the technology trade media, has very little appreciation for the difficulties and traps of virus hunting. The recent experience with Michelangelo points this out sharply. Almost all the articles in advance of the March 6 date stressed that the virus could be defeated by making backups or resetting the date. None mentioned that a BSI could corrupt non-standard disk formats used by many backup programs, and none pointed out the difference between the "DOS" date and the "system" or "clock" date.
Virus "experts", in common with most system level hackers, tend to be charter members of "Egos-R-Us". This is bad enough. However, what is worse is that everyone with an outdated copy of SCAN thinks he or she is a virus expert, and assumes the arrogance without necessarily having the expertise to back it up. (Given that the general population, even of advanced computer users, has very little background in the subject, the problem of proving credentials is often moot.)
So, how can you find a local expert? Some indications:
Points for:
This appears to be based in the deeply rooted prejudice which says that the only important part of a computer system is the part you can see, feel and throw through windows at times of stress. Let's look at the picture in real financial terms. If you buy two copies of a commercial antiviral program (for an "office" of, say, twenty computers), plus the "upgrade fees" for a year, you've spent about $400. $300 will get you a bare bones PC for testing, and, in addition to antiviral testing you can also detect trojans, which relatively few antiviral programs do. (An AT level machine should only be $500, even low end Macs can now be had for about $1500.) A designated machine also allows you "pro-active" rather than reactive protection.
Besides, very likely you already have a computer that no one in the office will use because of its age and "obsolescence". However, a word of warning is in order here: we have seen cases, most recently with Michelangelo, where older machines will not detect the full range of functions of the viral program. There are also a number of viri which are "version specific" in terms of the operating system; but it is relatively easy to set up a situation which allows for quick changing of the operating system.
One point I also stress in regard to testing is to make sure that the hard disk is not empty. There are some "prima donna" viri which refuse to operate unless it is "worth their while" in terms of the amount of file space used. Keep the drive about 80 percent full.
Corporations, both large and small, and government departments, often have policies restricting the use of software. Usually these schemes make some statement regarding bringing disks and software into the office. These policies are, of course, universally disregarded, even by those who drafted them. Such procedures are unnecessarily restrictive, unworkable, and fail to address the issues that prompted them in the first place.
The intent is good. The institution wishes to protect the copyright of authors and other companies (or at least wishes to avoid being sued for failing to do so). The policy is also supposed to prevent the intrusion of viral and trojan software into the company, and, in some cases, the extraction of sensitive data from company files.
Unfortunately, I have yet to see such a policy which actually does so. In most cases, the procedures are both insufficient to the intended outcome, and damaging to normal business practice. I will use some examples from the government of Canada. (Anyone gloating over the foolishness of this institution does not know the policies within their own company.)
The Treasury Board is the governing body in financial matters, and therefore publishes directives covering pretty much all aspects of federal government practice. Several years ago, it published a circular stating that all computer related software or hardware had to have an associated purchase order before it entered government premises. At first glance, this would appear to be sound, and even an advantage for software companies. Not so. If you are reviewing software, a local government office cannot afford to purchase the necessary variety of software and still keep within its budget. Of course, it is possible to cut a P.O. for the software for no money. This takes about as long as the review process itself, as well as potentially putting the software company at risk (there being other policies regarding minimum and maximum pricing). Even if you intend to purchase the software next fiscal year, you cannot review it in this fiscal year if you have no funding left for that line item, or cannot afford to "lose" that funding this year.
Federal government policy also provides for tracking of all inventory through accession numbers. The system works well for desks and cars, but not so well for computers and software. (I had a hard time convincing the "materiel [sic] management" people in one office that it did not make sense to issue one accession number to twelve video cards, but it did make sense to issue one number to one card, three disks of setup software and one manual -- for the same card.) Because of the difficulty in putting items into inventory (obtain the inventory coding for the item, obtain an accession number, affix a label -- you ever try to find space for a 2cm by 6cm label on a video card? -- and enter up to 46 fields of data into the inventory data base - by paper form, since only two people in the local office have access to the data base itself) very few software related items were ever entered into inventory. Data disks were never labelled: after all, what do you do with a carton of 100 blank disks, which are probably headed for thirty different offices?
In order to effectively track infections, however, even data diskettes and customer data diskettes have to be identifiable. The system for doing so must be easy, must not interfere with normal work, and must be rigorously enforced -- by the users.
The trouble with most policies of this type is that these considerations are not "designed in" from the beginning. Trying to make transitory computer materials fit an inventory system designed for permanent fixtures, or forbidding the entry of disks into the company, simply means that people will ignore the policies in favour of greater productivity. The specifics of recording and tracking will have to vary with the corporate climate and culture. If an intent, and some relevant background, is presented to employees (rather than a mandated procedure), the users will come up with a solution ... and one that is far more effective than those imposed by head office.
Having said that, many of the utilities needed are already a part of the operating system. In the MS-DOS world, CHKDSK, while it will not show you a graphical map of the disk, will provide information on the number of bad sectors or hidden files. With MS-DOS 5, the MEM program provides needed information regarding memory and interrupt usage. The Mac world, and the GUI OSes in general, tend to provide less of these tools, but I believe that ResEdit is now part of the Mac OS.
In any case, these utilities are widely available both commercially and as shareware. Commercial utility packages often do "double duty": PCTOOLS probably is sold most often for its backup capability, but can provide helpful information for other areas as well. Shareware tools sometimes lack the interface of the commercial tools, and more often are dedicated to a single task, but frequently have useful features not found in their commercial counterparts. (Neither PCTOOLS nor Norton have the ease of access to specific sectors that the shareware SHOWFAT has.)
I would also like, at this point, to bring up a related issue. I have been receiving feedback, from many sources, all tending to the same theme: "why not just scan the computer and have done with it." It has, perhaps, escaped the attention of these readers that at no point in this checklist have I required the purchase of any specific antiviral software. This is deliberate for three reasons. First, this checklist is intended as a conceptual guide and is, as far as possible, intended for the non-specialist user of any system. Second, it is intended to show that virus protection is possible without specialized software (although antiviral software can ease the burden tremendously.) Third, the most important aspect of virus protection is that the user know the system. That cannot happen if the user is relying on some "magic bullet": there never will be a magic bullet that will give 100% protection.
Unfortunately, software manufacturers still insist on various types of copy protection schemes. Recently, the most popular have involved writing changes to the program based on a "registration" of your name and company -- on the original disk. The practice of using a "backup" original will allow you, in this case, to keep the manufacturer's software disk protected. However, there are still some schemes that require reading from and writing to the manufacturer's disk. Whenever possible this practice should be avoided.
As in a previous column, I am sure that some will object that it is far easier to simply scan the disks for viri and "have done with it". I do, in fact, recommend scanning all disks. Note that both original and "backup" original should be scanned after they have been protected. Also to my previous reasons regarding not stressing the use of scanners, may I add the fact that scanners, by their nature, will never be able to protect you against all viri, although they should protect you against most.
There will be, of course, complaints that this measure is too expensive for the normal office. However, one might compare the cost of a commercial virus detection program (or even, say, a full set of the VIRUSCAN suite) against the cost of a "vanilla" XT clone: about $300 or less. The test machine need not be sophisticated, although there will undoubtedly eventually be viral programs which will require a higher level processor to run. The majority, however, of "successful" viri will target the widest possible set of platforms, and will therefore work as well, or better, on low end machines. One should also consider that the majority of "mutated strains" will be put together very crudely by "teenage mutant basement hackers", and that these will undoubtedly be put together on cheaper machines.
One caveat: we have seen a number of instances of malicious programs which will not trigger until the hard disk is "filled" to a certain level. Keep the test machine loaded, not with a minimal set of files, but about 80% full.
First thing is, don't panic. Remember that a lot of viral programs don't do any damage -- at least not intentionally. While you should not go blithely on as if nothing had happened when you find a virus, don't overreact, either. And, instead of focussing on the immediately obvious problem of the infection itself, try to take a few steps for future protection.
And. No one. Ever, yet. Has found a virus which requires a low level format. No LLFs. Got that?
However, do perform a thorough disinfection. Many people, while going far too far in gouging an infection out of their workstation, will fail to check out their floppy diskettes and backups. One of the most Frequently Asked Questions on VIRUS-L is "I cleaned off Stoned but now it's back, how come?" Easy answer. You didn't check your disks.
Also, with few exceptions, when disinfecting power down cold and start fresh. If you have a virus in memory, none of your disinfection methods can be guaranteed, and some may even harm.
Once again, note that this checklist does not require any specific antiviral software. Antivirals will be dealt with in due course.