If you went out shopping for a new burglar alarm today, what kind of features would you demand of it? I mean, would you purchase one that can be triggered off only when it detects a known burglar or felon in your house?

You know – the one with the spiffy feature that allows it to perform an automatic synchronization every week with the most up-to-date records of convicted individuals in the whole world. In fact, just for an additional fee, you can even get it to update on a daily basis as well.

Or, on the other hand, would you be like me and prefer it to sound the alarm whenever it detects someone it doesn’t know about?

If it sounds a tad sarcastic, yes, I meant it that way. This apparent conundrum is precisely the issue that is plaguing the current generation of anti-virus (or AV) products, as we known it. The current generation of AV products are broadly only capable of detecting known viruses.

Sounds like no big deal until you consider the fact that to be “known”, a virus first has to have created an outbreak severe enough to be noticed, followed by the “capturing” of samples, then dissected and analyzed by the AV vendor, then patched against. This patch will then have to be quality tested internally first, before finally being uploaded as a signature update – and that is pending you acquiring the update. Hopefully, you would not have been infected in the interim.

Multiply out the above scenario for the few dozen new viruses appearing on a daily basis. Then take the precedent of the SQL Slammer worm taking all of 10 minutes to infect 90 percent of the computers on the Internet and you get the big picture – and good luck to you sir.

Really, even that cool “heuristics” feature that you have diligently kept selected in the “Options” menu falls far short when you realize that virus writers would certainly have first tested them against your favorite AV products and sufficiently tweaked their creations that they would not trigger off an alarm. I mean, I am not even smart enough to write viruses, but that would be what I would have done if I am a virus writer. It is therefore no wonder that according to AusCERT, Australia’s Computer Emergency Response Team, two of the most deployed AV products were able to sieve out only 20% of new viruses.

Indeed, in a world where a malicious corporate hacker can guarantee that his original malware will not be detected by existing AV by testing it out first, the hardest aspect is not so much the coding but the delivery mechanism. But even so, he still has available a whole plethora of ways to penetrate his corporate target. One of the favorites – and I might add, probably a classic, among them is possibly a couple of spoofed email from a trusted person.

Yet a recent illustration of just how easy this could be as well was evidenced by an IT Security officer at a US company who recently bought a handful of memory sticks. He loaded some software on them and went ahead and scattered them around the company’s parking lot. To cut a long story short, several employees found the memory sticks, plugged them into their PCs and laptops and ran the software “just to see what it does”. How hard would it be to code a custom malware with an appropriate auto-run script and repeat the above procedure outside a competitor’s car park?

So why don’t AV products work, and what can be done about it? The reason why AV products in general don’t work is simple – if the AV scanner cannot recognize software as harmful, it lets it run. If that application that you just executed happened to be a new malware for which no signature has yet been made available, then depending on its payload, the result could be so many mangled or random bits under the hard disk’s drive head.

Sarcasm aside, given that the crux of the matter is really based upon recognition of the executable, intuitively, won’t a possible solution be that to trust no application at all unless they can be verified as safe? Yes, you are right here in this regard – indeed, “white-listing” is a concept that has been around for far longer than you would believe from its nascent uptake of just less than 1%.

Essentially, a detailed audit is initially done to determine the various executables and link libraries that is recognized and allowed under the system. Anything that does not fit the bill will not be allowed to run by the operating system, be it loaded from a USB memory stick or as a file named “open_me_now.doc .exe” that appears to come from your CEO.

There is a downside though; and the con is that periodic in-house revision of files allowed under the system’s white-list is necessary in between operating system updates or application patches. Still, this really is but a small price to pay for genuine immunity against custom-written or new viruses. Also, the ease of adding to the white-list has improved tremendously since.

It has been 25 years since the first computer virus appeared in 1982. Dismally, the only progress we seemed to have made thus far is in the maintaining of increasingly larger virus databases of virus signatures that is nowhere like the new and advanced menaces we see almost on a continuous basis.

The concept of maintaining a white-list has been around since 2000; and their ease-of-use and stability has only improved since then. Surely it is not too much to expect faster progress be made towards incorporation into mainstream AV products and from there, a more substantial market uptake?

Some might disagree, shrug, and then point out that even a flawed AV approach is still “better than nothing”. Still, I would opine that just how much better than “nothing” might prove a much thinner line than your AV vendor would have you think. A paradigm shift is necessary, and it needs to happen now.

Trackback URI | Comments RSS

You must be logged in to post a comment. Free Registration »