McAfee and the ‘false positive’

Note: Thoughts expressed here are mine alone. They may echo the thoughts of others, but I’m not publishing this on behalf of or in representation of anyone else.

Nearly everyone is aware of the issues of this week surrounding a problematic McAfee update. I could link hundreds of articles and I’m not sure anything else can be said that hasn’t already been said. However, I suppose writing is therapeutic to some extent and I’ve had a few thoughts running through my mind as our school districts work to correct thousands of affected computers.

* Kudos to our school districts. They probably don’t get enough credit as it is, but it’s amazing to see how districts have massed on this problem and developed plans to touch thousands of machines. Their work is to be commended. These are dedicated workers who have given away countless hours (no overtime pay in a school district) to fix these machines. In addition, many CIOs made a tough spur-of-the-moment call to shut down every machine in their district. I’m not sure I could have made that call that quickly, being fearful that a false alarm would infuriate my user base. It was a courageous call and a correct one given the circumstances. I’m proud to work alongside our area school district technology staff members.

* The Internet records everything. McAfee’s initial response was delayed and was out of touch with the difficult realities facing a good portion of their user base.

…a number of customers have incurred a false positive error due to this release. Corporations who kept a feature called “Scan Processes on Enable” in McAfee VirusScan Enterprise disabled, as it is by default, were not affected…

McAfee went out of the way to point out that it was a false positive and not a virus. The end result was the same and no one I talked to was concerned about whether the problem was a virus or a false positive. Also, later reports indicate that the “Scan Processes on Enable” is not disabled by default in all cases. The language here implies that, had a customer not changed the default settings, they wouldn’t be in this predicament. There’s an implication that it wasn’t McAfee’s fault.

We are not aware of significant impact on consumers. We believe that this incident has impacted less than one half of one percent of our consumer base and enterprise accounts globally…

There may be some funny math going on here. If I had 199 consumers with a single copy of the software that weren’t affected and I also had one corporate account with 1000 machines that were impacted, I suppose one could say that “one half of one percent of customers” were impacted. However, that doesn’t accurately state the percentage of machines affected and it certainly downplays the significance. Again, the focus seemed to be that the incident wasn’t a major concern. To affected customers, it was. Also, it’s worth noting that a machine that constantly reboots and will not function is a “significant impact” and it’s very hard to believe that, upon this press release, these symptoms weren’t known.

To be fair, subsequent responses have a different tone and the company definitely took the matter seriously. Initial reports indicated that support information was hard to find. At this time, there is a link on the McAfee launch page. I’m not sure when that appeared. The bottom line is that effective crisis management, as exemplified in the Tylenol situation in the 80’s, involves swift and wide-reaching action if there’s even a chance of devastating impact to users.

* What if it were a virus? – My final thought is that, had SVCHOST.EXE truly been infected, was this the proper response? Should the file have been quarantined, rendering the machine useless and unable to communicate with the network? It’s hard to say, but I’m sure this is one of the areas that will be investigated moving forward.