"Generic" Defense Products

Courtesy of the alt.comp.virus newsgroup participants.
(These "anti-malware" pages are the result of a continuing cooperative effort.)


Main Menu

Generic Defense Products - How they work / Pros and Cons
by Nick FitzGerald
Computer Virus Consulting Ltd.

Without naming any specific products, the main idea of "generic" (or "non-virus-specific") anti-virus products is that they monitor for "signs of a virus" rather than for code known to be (part of) a known virus. The simplest approach, which is not really an anti-virus method at all, is the "before and after" file integrity check and depends on the truism that if a virus is to infect you, it has to alter something on your system and something should be able to be detected with a "change detector". The pros are, no on-access overhead and it will never interfere with something that may seem dodgy, but that you really do want to happen. Cons are the hassle of the before and after method (what tends to happen is the regular "after" scans to detect if anything has changed, become few and far between), and the extreme hassle value of having to boot from diskette (or having some other method of guaranteed clean boot) to be sure you are not being spoofed by a stealth virus.

Other "more aggressive" forms of generic anti-virus approaches are "after the event application sandboxing" (as seen in the eSafe product) and various forms of behaviour monitors and/or blockers (in fact, this part of the eSafe product is really just a very fancy kind of tunable behaviour blocker). The theory here is that you can actively prevent certain kinds of "bad things" from happening by installing suitable hooks into the OS (and/or via application runtime emulation) and simply not letting the "bad things" happen amongst all the other behaviours of the application. To be more specific, you can prevent the hard drive being formatted (say) by intercepting all the low-level functions that can be used to implement hard-drive formatting and then prevent any calls to such interfaces from being passed on to the code that would normally handle those calls (or you can be selective and only allow certain users and/or applications make those calls and have them succeed, blocking such calls from any non-approved application). In general, although these approaches can catch/stop many, many "bad things" before they are known to (updated) known-virus scanners, they also tend to have rather high annoyance value and often require the user to make judgement calls about complex, technical mumbo-jumbo stuff that most of them are not suitably qualified (nor employed) to make decisions about.

The main argument in favour of generics is they allow interception of many new, previously unknown viruses. The cons are that they tend to have a high false positive ("false alarm") rate and the virus usually has to be allowed to run (or at least part of it has to run) to be detected. A big problem with high FP rates is users become "numbed" to the alarms, raising the risk of the "boy who cried 'wolf' " effect and seeing the product ignored (and often eventually disabled/uninstalled). The obvious problem with malware code having had to (at least partly) run is that it will have the chance for at least part of its damage to be done. A partial solution to that problem is to employ resident (on-access) behaviour blockers as part of the generic product.

(There were those) who were vehemently "anti-scanners" for many reasons, due to the "terrible overhead" of the on-access component, which you pretty much needed to have active by the mid-90s, and the instability problems on-access scanners introduced (from much experience with most AV products -- especially if they have large-ish corporate clients -- the latter is almost always entirely due to running other misbehaving software and/or running it on misbehaving hardware with the on-access AV just being the "final straw" that triggered whatever...). Anyway, quite some time back now, (this view changed, and it was "decided") that on-access components were crucial if you were going to take a generic approach such as behaviour and change monitoring.

Another approach again -- what is sometimes referred to as the integrity management approach -- is not correctly, "generic" although it is also not "virus-specific". Such an approach (there are no products with a sufficiently advanced implementation of this yet for me to be able to point to and say "...as seen in ProductX...") takes the view "the admin should know what software is allowed to be run, by whom, and where, and will provide a mechanism to enforce such usage policies on the users." This is, more or less, Fred Cohen's "integrity shell" idea and although it did not find favour 15 years ago when he first talked about it, I think that much of corporate IT has evolved to a point where it needs such a capability. Note that this is not just a generic AV approach as apart from stopping viruses, it stops Trojans, standalone executable worms (as opposed to "real worms" such as the original Morris worm), time-wasting games, non-licensed software, software whose use is not part of your job description. Such an integrity management approach can also be used to control access to non-executable files too, such as, say, enforcing the company ban on downloading MP3 files. This is because system integrity management is about much more than just who has what access to what parts of the file system (and other "devices"), which is all that traditional computer security concerns have focussed on. System integrity management is also about what code is on a system and who can do what with it and can be extended to concerns about what content is on a system if desired.