By Andrew Brandt

If you’re a customer or an employee of McAfee, chances are, you’re having a rough week. The company published a false positive, or FP, in its antivirus definitions that went out to customers a few days ago. The FP resulted in some computers going into a loop where the antivirus engine misidentified a key component of the Windows operating system as malicious, Windows replaced the quarantined file, and then the McAfee engine removed it again.

I really feel badly both for McAfee’s customers as well as their researchers. The customers certainly didn’t deserve or want their protection to go haywire. Security firms that make antimalware programs, like Webroot and McAfee do, confront the risk of publishing false positives every day. I don’t think there’s a single company that doesn’t strive for a zero percent false positive rate (aside from the snake oil pitchmen who sell rogue antivirus products, whose entire business model is predicated on lies and deception).

Every legitimate company in this space has had to retract some definition set at some point because it misidentifies or removes the wrong thing. We’ve done it, too; It’s nothing to be proud of, but it’s the reality of the situation in which anti-malware researchers work. The malware creators do their best to make this task as difficult as possible. We also know that every minute longer it takes to work on an updated definition, is another minute where our customers roam the Web unprotected from the dangers that lurk around virtually every corner. In the rush to press forward, we sometimes make mistakes. And as a result of those mistakes, we’ve made some improvements over time: Our desktop Webroot Antivirus product can’t, for example, accidentally quarantine some of the key system files Windows needs just to remain operational, as long as those system files remain unmodified by malware.

What happened with McAfee has been the subject of a lot of water-cooler discussion here, too. One of the bright points that has come out of the internal conversations I’ve shared with some of my colleagues is this: Putting the definitions into the cloud, instead of letting them reside on the “endpoint” (the desktop computer running the antivirus software) has a clear advantage in cases like this. If a definition hosted in the cloud goes horribly, horribly wrong, we can pull that definition from circulation immediately, thereby limiting the scope of the damage, and hopefully containing it to the small number of users who happen to be in the unlucky position to be first to use a defective definition set.

Another point that someone made concerned the Webroot Web Security Service, which is a Web filtering service we sell to businesses as a way to protect their entire network from dangerous Web sites hosting malware-pushing exploit kits or phishing pages. Web SaaS provides a critical layer of protection from Web-based threats in the unlikely event that you might have to temporarily remove a misbehaving endpoint anti-malware product. Our Email SaaS service does the same for threats that might come through corporate mail systems. SaaS security won’t ever totally replace some sort of security app running on the computer, but it does a bang-up job keeping you safe from most threats.

When it comes to offering protection, the state of the Internet today demands a far more rapid response to threats. We need to respond immediately to new attacks, so our customers are protected the minute we discover something new. And likewise, we need to be able to pull back changes immediately, so we can limit the damage if we make mistakes. This immediacy is the benefit of keeping some security components out in the cloud, and we’re working towards a goal that protects not just the computer, but the people using that computer, the minute new threats reveal themselves. Waiting days and days for protection just isn’t an option anymore.