the decline of anti-malware protocols

if you've read this blog for any amount of time you've probably encountered posts where i try to debunk the idea that anti-virus is dead or falling behind or something similar... those generally have to do with anti-virus technology or the anti-virus industry, but there is one aspect of av that seems to be doing more than a little poorly these days and that is the application of proper anti-malware protocols - in other words, the practice of AV...

my interest in malware has lead me along many seemingly tangential paths in security over the years, and although i won't pretend to have any great insight in most of them i did pick up a few gems along the way... one of the gems i picked up as a result of following sci.crypt for a decade or so was the idea that no matter how secure an encryption algorithm is a cryptosystem that uses it is not secure unless it uses the algorithm in the proper way... in part that means using best practices for the algorithm (such as not using a one-time pad more than one time, or sanitizing an rc4 keystream), but it also means following a secure cryptographic protocol...

i propose that a similar principle is true for anti-virus or more generally anti-malware: you cannot gain the full benefits from a particular anti-malware technology unless you use it properly... again, sometimes this means best practices like keeping all your software up-to-date, and sometimes it means following correct procedures (implementing an anti-malware protocol)... this is one of the things i had in mind way back when when i wrote my anti-virus cook book but unfortunately protocols have seen little if any attention in the intervening years (and my cook book is way out of date these days, though some of the underlying principles remain unchanged)...

i understand why there hasn't been much focus on it... there is a pervasive opinion that anti-malware technology should stand on it's own, it shouldn't need informed users to act in a particular way because you can't depend on users in general to be informed or act the way you think they should... this has lead to the unfortunate consequence of making people think there is a purely technological solution to the malware problem when there isn't... it also ignores the fact that not only are some people actually capable of following proper anti-malware protocols, the population in general is at least capable of improving even if we'll never see complete uniform adherence to a particular code of conduct...

with that in mind, however, i was disappointed to discover that not only have protocols not advanced much in their adoption outside the anti-malware community but they're even being dropped within the anti-malware community... 10 years ago you would not have encountered a well respected 3rd party tester testing known-malware scanners against active stealth-capable malware so imagine my dismay at discovering that av-test.org did precisely that as described in a paper linked to by this darkreading article... the paper describes 2 separate tests, one on XP using anti-malware suites that claim some measure of stealthkit detection, and one on vista using so-called "pure anti-virus" products (ie. known-malware scanners only)...

the issue here is primarily the second test... known-malware scanning is primarily a preventative technological control... it is quite effective at filtering known-malware out of incoming materials... to their credit, anti-malware vendors have also made their scanner products useful in the contexts of detection and correction as well, but with the caveat that the user should use them from a clean environment (by booting from known-clean bootable non-writable media or by slaving the suspect drive in a known clean computer)... outside-the-box analysis is the only reliable countermeasure to whatever active offensive and defensive capabilities a particular piece of malware might have - it is a well known principle that you cannot trust a compromised system to accurately report it's state...

while there are technological shortcuts that can prove moderately successful (as demonstrated by av-test.org's XP test), those shortcuts are not reliable enough to completely obviate the need for the formal outside-the-box analysis... the benefits of shortcuts is that they allow one to extend the time between performing otherwise costly formal methods like outside-the-box analysis (up to a point) without increasing the risk of something getting through... in that respect, the XP test wasn't so bad since the products tested actually claimed to perform such shortcuts, but the vista test was methodologically unsound because it misused the technology it purported to test by testing it in a compromised environment...

now there have long been proponents of this sort of testing... they would often cite such methodologies as reflecting actual usage conditions because that's the way people use the products in real life... but the fact of the matter is that that's the way most people misuse the products in real life... when you're developing a benchmark the metric that is more interesting is the one that shows what a product is capable of when used properly, not the one that shows what happens when people don't know what they're doing...

when a respected testing body performs tests like this it reinforces worst-practices and the mismatched expectation that anti-malware software should just protect us automagically... i can't accept as valid any testing methodology that misuses the technology it purports to test and i can't believe andreas marx didn't know better since he referenced 2 of his own previous papers on the use of recovery disks and made a feeble mention in his conclusion that maybe their use is a better way to go... they are absolutely the better way to go when you suspect a system might be compromised and this has been known in the anti-malware community for a long, long time... when the anti-malware community itself starts dropping best practices and proper protocols, the practice of AV doesn't just fall behind, it regresses...

what is outside-the-box analysis?

outside-the-box analysis refers to the practice of examining a suspect system from the outside using a trusted external environment while the suspect system's OS (and everything else installed on it) is inactive...

the primary benefit of this practice is that any malware on the suspect system will be unable to actively hide (using stealth) or actively defend itself against the tools used to perform the analysis because they won't be active in the first place... it is a long held axiom that you cannot trust a suspect system to accurately report it's own integrity because any active malware can force the system to lie or can even attack the software asking the questions... operating in an environment where this can't happen gives you an advantage over such malware...

in common practice there are two main ways of providing a trusted external environment in which to examine a suspect machine... the first is to use a second physical computer which you connect the suspect machine's hard disk to as a so-called 'slave' drive... this is a relatively straight-forward method that most people are able to do assuming they have a second machine available and can be talked through taking the hard disk out of the suspect machine and putting it in the second machine...

the second method is to boot the suspect system from an operating system on a known-clean removable medium like a floppy disk, CD, or USB flash drive... LiveCD's are a familiar concept to linux users, and old-timers will probably remember using known-clean bootable floppies on their old dos machines... for windows there is something similar called a pre-installation environment that provides much the same kind of functionality, but microsoft has been slow in recognizing the need to put that functionality in the hands of users which lead to the development of the BartPE disk (which has been mentioned many times on this blog before both by myself, and recently in a comment by vesselin, but is discussed even more by chris quirke in relation to the utility of a maintenance OS)...

back to index