For the last few months, I've been hearing some well-regarded security people tell me they are considering ditching their antivirus protection all together. They haven't done it, but these individuals feel the days of having a special application scan to remove malware on your desktop are numbered. Malware has changed, but the applications to ferret them out have not.
Antivirus programs, as we know them today, are based on 20-year-old technology of pattern matching. Pattern matching may have worked in the days of the Micheangelo virus and even as recently as Netsky, but methodically matching each and every file on a computer against a list of known malware is getting tedious, if not archaic. In 2007, Symantec detected more than 1 million viruses, with two-thirds created within the calendar year. Loading 1 million signatures, or even a percentage of that if generic signatures are used, is a pretty serious undertaking.
That's why vendors are talking to me about newer strategies for 2009 (and beyond). Among these is the exact opposite of signature file databases--something called whitelisting. If pattern matching is just another way of saying certain bad files have been blacklisted, whitelisting goes to the other extreme: it only allows certain trusted files to run on your machine.
That's more or less what Symantec CEO John Thompson called for at this year's RSA: "If the growth of malicious software continues to outpace the growth of legitimate software, techniques like whitelisting--where we identify and allow only the good stuff to come in--will become critical." He actually didn't say much more about whitelisting, yet everyone talks about this speech as though Thompson had provided clear guidance the year of whitelisting.
So how viable is whitelisting? Turns out we've been using it to defend against spam for years.
To see how whitelisting works on an enterprise level, I spoke with Tom Murphy, chief strategy officer for Bit9, a Massachusetts-based company that has been quietly leading the way in whitelist technology.
For several years Bit9 has been building what it calls a Global Software Registry or GSR (formerly called Bit9 Knowledgebase), cataloging "known good" and "known bad" applications and files. Murphy said Bit9 uses three methods--MD5, SHA1 and OMAC--to create a unique hash of the file and ensure that the file is what it says it is. For the moment, the catalog is used for Bit9's enterprise products. But they've entered into an agreement with Kaspersky, who will be using the registry for its 2009 desktop security products.
Bit9 is not alone. SecureWave's Sanctuary, Savant Protection, and DriveSentry have also been creating whitelisting technology for the enterprise. What's interesting is that the big guys Google (Green Border Technologies), Microsoft (Winternals Software's Protection Manager, and now Symantec have started paying attention to whitelisting.
Which gets us back to antivirus software.
If hosting a million antivirus signature files is daunting, how many "clean" files might there be? Think about all the versions of software that exist, not to mention the files those products create.
The downside of whitelisting, indeed the main argument, is that all those clean files outnumber the bad guys by a considerable margin. Right now, maintaining a whitelist file is impractical for the desktop.
Trend Micro (if it wants to get into the whitelist space) thinks it has the answer. For the last few years, Trend Micro has been building servers around the world to provide continuous service to its Software-as-a-service enterprise systems. Last month, Trend Micro CEO Eva Chen told me it's time to bring that SaaS service down to the desktop. Instead of having all the signature files on the desktop, the desktop app would instead ping "the cloud" and get results from the much larger database of known malware stored there.
Make no mistake, Trend Micro is still using antivirus signature databases. Chen said even after 20 years, there are still advantages to pattern-matching antivirus signature files. For one thing, she says it's faster than firing up a heuristic sandbox and testing each individual piece of malware. True, although we're talking about shaving nanoseconds between the two processes. Still, with several thousand files, those saved nanoseconds do add up. So instead of running the operation on the PC, the PC sends all its unknowns to a server in the cloud and gets the results back lickety-split. An added benefit, says Chen, is that new samples are submitted in real time and evaluated quickly. In her estimate, Trend Micro can have a new signature file for an unknown threat ready within 15 minutes.
Fifteen minutes is also the new mantra over at Symantec. For its 2009 Norton products, Tom Powledge, vice president of consumer product management at Symantec, told me the new products are lighter and faster in part because they've jettisoned the multiple copies of the signature database found in previous versions. They're also not scanning each and every file. Instead, the 2009 products will be building a trust index--that is, the app will declaring certain files (say photos or MP3s) clean and then not scan them again unless the files change. He showed me a graphic where roughly 70 percent of a given machine is trusted, and only that last 30 percent is actively scanned.
Like Trend, Norton is experimenting with faster new malware turnaround. Powledge says Norton should be updating not every 15 minutes, but every couple of minutes. This is a vast improvement from hourly or even daily updates by some antivirus vendors.
Given the improvements to the traditional antivirus programs proposed by Trend Micro and Symantec, are the days of antivirus applications numbered?
Yes.
I asked Murphy if white lists worked well enough to replace traditional antivirus protection at some companies. He answered, very diplomatically, "if (a customer) feel(s) that they have a control over the environment, some customers have removed antivirus off their machines."
I'm still not convinced that white listing is the way to go, but I do know that security solutions in the enterprise space have a way of trickling down to the desktop.
Programming note: As of Friday, July 11, 2008, Defense in Depth will now only carry my weekly column plus additional commentary on the state of computer security. My security news blogs will instead appear under the CNET News Security banner going forward. And my CNET News Security Bites podcasts can be found at here. All of these can be subscribed to via RSS.
While security researcher Dan Kaminsky still won't comment on the specific nature of a flaw within the Domain Name System--for fear that criminal hackers might exploit it before the worldwide network of name servers worldwide and client systems that contact them can be updated--he nonetheless went public on July 8 with some details, backed by simultaneous patch releases from Microsoft, Cisco, and others.
There have been other multiparty patch releases, but never has there been one on such a massive scale. It took someone with the gravitas and reputation of Kaminsky to pull together the affected parties.
Dan Kaminsky at DefCon in 2006.
(Credit: Declan McCullagh/CNET News)What he and others he took into his confidence did over the last few months was not only responsible but extraordinary. The flaw that Kaminsky discovered could allow criminal hackers to guess the transaction ID of any request to a DNS server for a particular domain, such as one used for a bank or an e-commerce site, and then redirect that request to another site, a phishing site. It would do so silently, evading most anti-phishing technology because the change would be made not at the desktop level but at the DNS server itself. Certainly this is big, and certainly one would want to get the news out as soon as possible--but Kaminsky took the time to inform the proper vendors and authorities and, only after they were ready with patches, did he disclose some of what he'd discovered.
That isn't to say what Kaminsky did was perfect; he himself admits there are lessons to be learned and improved upon the next time this happens. Whether you agree with the severity of the flaw Kaminsky disclosed last Tuesday, I do think all future vulnerability disclosures could benefit from his example.
Kaminsky, director of penetration testing at IOActive, is no stranger to vulnerabilities. Over the years he's found a fair share and says that in the case of the DNS flaw he wasn't looking for it. In this week's Security Bites podcast, Kaminsky told me that after three days of testing he knew he had something important. At that point, early in 2008, he had a few options.
One was to tell the vendor (or, in this case, vendors) directly. Ari Takanen of Codenomicon told me he prefers that security researchers keep vulnerabilities between them and the vendor. Vendors, Takanen said, have their own development cycles, and for a researcher to burst into a room or go public and demand that everyone work on his or her vulnerability is unrealistic. While Kaminsky was willing to work with the vendors, he wasn't willing to give them forever.
Another option was to sell the vulnerability to a third party like TippingPoint's Zero Day Initiative. ZDI acts as the middleman, talking with the vendor and communicating with the researcher. The advantage here is that a researcher with no connections to the affected vendor can communicate the problem clearly.
ZDI has been credited with several vulnerabilities, such as those announced by Apple and Microsoft. Kaminsky has no qualms with those who opt for this method, although he said he didn't understand why a company would pay for this information. (I know the answer: TippingPoint uses the vulnerability data it purchases to protect its customers first, thereby giving it a competitive advantage in the vulnerability assessment space).
Another option for Kaminsky was to go public, to announce the vulnerability and publish details, including an exploit, on, say, Bugtraq. A few researchers have gone this route, but often as a last resort after getting a cold shoulder from the vendor. A few researchers have published flaw details first without contacting anyone, taking both the public and the vendor by surprise. But such moves are unwise since they give the bad guys all the information they need while everyone is vulnerable.
Finally, as Kaminsky reminded me, there's the option of selling your vulnerability to the criminal underside of the Internet.
With the DNS flaw, Kaminsky was in a very weird position. What he found wrong with DNS, the servers that translate a Web site's common name to its IP address, wasn't just within one vendor's product, it cut across various products, from various vendors. He said he consulted with DNS expert Paul Vixie, and together they decided they had to convene a meeting, and do so within a few weeks of the discovery.
That meeting occurred at Microsoft's Redmond, Wash., headquarters on March 31, 2008. There, representatives from 16 vendors sat down and listened to Kaminsky's pitch. After deciding this was a real and exploitable problem, the vendors decided they would have little choice but to agree to release simultaneously their respective patches.
At some point, July 8, 2008, was agreed upon as the date, perhaps because it coincided with Microsoft's monthly Patch Tuesday. The date was significant in other ways: for example, it fell roughly 30 days before Kaminsky was scheduled to speak at Black Hat in Las Vegas.
Between March and July, there was considerable back and forth among Kaminsky and the vendors, and then, as the date neared, he decided to share the details with a few others.
In retrospect, Kaminsky confessed that he really should have told more people. He had gone through great pains to inform the DNS community, the specific vendors, and few researchers. He did so to keep word from getting out.
But within hours of making his announcement, Kaminsky faced a chorus of public ridicule by other security researchers, most hearing about the flaw for the very first time. The complaints, at times, trivialized the announcement, with fellow researchers citing that similar claims had been made against DNS 3 to 10 years before or even longer. Some suggested Kaminsky was simply trying to advertise his talk at Black Hat next month.
Most vocal was Matasano Security researcher Thomas Ptacek, who blogged his doubts. But Kaminsky called Ptacek and he retracted his comments. He now says, "Dan has the goods. Patch now, ask questions later."
Whether or not Kaminsky knocks the socks off of everyone at Black Hat seems considerably less important than the responsible nature of his disclosure. He could have, as Ptacek notes, made thousands of dollars off this DNS thing. Instead, Kaminsky has set a high mark for future disclosures. He has changed Internet security, and done so for the better of us all.
- prev
- 1
- next
