The missing glue in the fight against malware

by ZDNet's David Berlind --
“ …Three years from now, the spyware problem will be worse than it is today and I’ll be writing about one of the reasons that there has been no improvement: the failure of the industry to recognize where technological consensus is needed, and then to build solutions on top of that consensus technology.

So, in the case of spyware, what would that technology be? I’m directing that question rhetorically at the new executive team at Tenebril because it’s simply an extension of the same conversation that I was having with them about personal firewalls while they were at Zone Labs. Personal Firewalls and anti-spyware have quite a bit in common. In some ways, personal firewalls help to solve the spyware problem because they can block spyware from "phoning home" — what happens when malware reports back to its creators or distributors with its findings (eg: logged keystrokes).

But, one reason personal firewalls aren’t always successful in this endeavour is that they often require user inputs. When a personal firewall detects a first time attempt by some process to reach the outside world, it notifies the user that something new is trying to get out and it asks the user if the attempted communication should be permitted. But, as I’ve written before, this allow/disallow inquiry is all too often noticably deficient in the kind of information a user needs to make an informed decision. This is particularly troubling since, regardless of whether it’s trapping malware or legitimate software, the wrong answer might render your software inoperable. "LSASS.EXE is trying to reach 177.24.202.16. Allow Always? Allow this once? Deny?" it asks me. What the heck is LSASS.EXE? What or where is 177.24.202.16? And finally, why isn’t the software answering these questions for me?

The answer to that last question is easy. The software doesn’t know. Nor, considering the number of software components out there (legitimate and not), can it know. For a while, with many personal firewalls, this meant that answering the allow/deny question was guesswork (or, a lot of Googlework). Fortunately, guessing couldn’t get you into too much trouble. Sooner or later, every networked computer loses its connection to its network anyway. When, through a personal firewall, a user denies network access to a particular software component, the net result for that software component is pretty much the same as what happens when the system suddenly loses its network connection for some other reason (the cable get pulled out, the Wi-Fi signal disappears, etc.). If a user mistakenly denies network access to a legitimate software component that needs it, and the system or the software hangs, fixing the problem requires little more than a reboot and a correction to the firewall’s ruleset.

But that’s not how software should work. And when I started dinging Zone Labs and other firewall makers for having this problem, I also recognized that no single firewall developer — not even Symantec — was big enough to develop and maintain the database they’d need in order to provide users with the information required to make an informed decision. How do I know this? Some of them tried. But the information was invariably incomplete. To really do that database right would require the participation of all the software vendors, and for them to participate, it would have to be easy and it would have to be centralized. ”

http://blogs.zdnet.com/BTL/?p=1353