COMMENTS
Not all protection software was reported as being vunereble to this attack. This "hook" method is not used by Immunet "Cloud" Protect or by Microsoft Security Essentials... Not all hope is lost. Maybe some of these others will adapt and change. The spammers and malware creators sure are...
History has shown that people tolerate being infected even though they have up-to-date Antivirus Software. This vulnerability only shows there is yet another vector for Antivirus software not to work using current approaches to threat response technology. It is time for end users to think about additional and alternative technologies when considering how to deal with today’s Malware threats.
so let me see if i have this straight. an attack that requires the malware to already be running supposedly bypasses a bunch of av products (even though what's getting bypassed isn't what most people think of as av technology) and you're going to call it the final nail in av's coffin?
i wonder, how well does application whitelisting fair in the same situation - you know,
after the malware is already running.
>> after the malware is already running
That's the problem with security solutions that are only reactive: You need to know something is "bad" in advance in order to stop it from running.
Application whitelisting is a proactive approach. It does not depend on such foresight. If the code is not marked as "good", then it is not allowed to run in the first place.
Harry Sverdlove, CTO, Bit9
@Harry Sverdlove:
"If the code is not marked as "good", then it is not allowed to run in the first place."
but you need to know not to mark it as good. how does an end user come upon this knowledge? how does bit9? certainly not be reverse engineering billions of programs and verifying each one as safe.
the problem av has in keeping bad things from executing is the same problem whitelisting has in keeping bad things off the whitelist. without knowledge of what is bad you can't make good decisions in either circumstance.
Indeed that is the challenge and purpose of an advanced whitelisting solution.
Bir9 Parity offers many techniques for marking programs as "good", including approving by publisher (digital certificates), trusted user, trusted source, approved distribution methods (e.g. SMS, Altiris, ...), trusted updaters and processes, hash values, and more.
In addition, we have one of the largest catalogs of known software (Global Software Registry), providing both trust and threat information to Parity to help make these approval decisions.
It is true that maintaining a whitelist is conceptually a similar challenge as maintaining a blacklist. But in practice, the list of things you dont want on your endpoint is a siginificantly larger set than the things you do want. With our advanced policies, in almost all deployment scenarios, only a few dozen rules is enough to cover the "whitelist".
For the exception case, where something is not on the list, which is the preferred security posture: let it run and worry about whether it is malicious after, or prevent it from running until you can make that determination? You can choose either posture, even with Parity, but at least you are in control of that decision.
There is no silver bullet in security, nor am I suggesting one. But I do think the traditional approaches could benefit from a fresh perspective.