Lost in Reception

Various things:

• Keep your AV software up to date, not just your signatures.
• Corollary: make certain you’re aware of the presence of out-of-date protection in your environment.
• Fail safe! Deal with version skew. Bricking a device because its software was out of date is not a reasonable failure mode.
• There is nothing in what happened that is specific to McAfee. Similar risks apply to all protective systems.
• As important as host-based protective software is, it actually introduces an entire class of risks that need to be understood.
• Human error is often at least as dangerous as malice. Provide defence in depth not only to limit the damage done by intruders, but also that caused by accidents.

Further thoughts:

• This is about false positives in in-host malware identification rather than in-network spam identification, but there is some overlap. In case you missed it, details are here. The issue appears to be that signature update “DAT 5644″ is not intended for use on EOL’d engine version 5100, but the latter is accepting the update anyway and then misclassifying legitimate software including vital HP/Compaq drivers, which are being quarantined, which is blue-screening many thousands of affected machines.
• Brandon Wiley’s curious blue idea suggests that this problem is going to get worse over time because, serious as the risks of automatically deploying the latest and greatest software are, the risks associated with not minimising exposure are greater, and becoming more so. Worse, the update distribution mechanisms required to deploy protection as quickly as possible provide a potential vector for intruders. A single exploit in a major AV vendor’s release process could, in a matter of hours, produce a botnet hundreds of times larger than anything seen to date. (Think this sort of exploit can’t happen? We could always hope that banks turn out to be less adept at managing risk than computer security companies are.) This almost argues for different schedules for machines at different levels sensitivity and, paradoxically, for updates on more sensitive machines (those which should be behind several layers of protection already) to be applied less rapidly. It similarly argues for intentionally using a mix of systems – and minority platforms in particular – in an organisation’s most sensitive environments.
• There are now [at least] two commercial pressures that lead to the “device bricking” scenario: (a) the well-known “jail-breaking” of iPhones leading to updates failing in a way which renders the device unusable and (b) the “out-of-date” software automatically applying updates which has the same effect. Even if a vendor is willing to punish customers who knowingly work against them (similar to the DRM-peddler’s conceit that a device owner is nothing more than a source of profit), customers who fail, for one reason or another, to keep their software up to date really should be accommodated, at least to the point where failures are graceful. This is not an appeal to altruism but to self-interest on the vendor’s part: right now, thousands of CSOs, IT managers and the like are wondering whether they’ll ever purchase McAfee products again. At least some will decide not to. The simple, pragmatic act of having signature updates contain enough metadata to indicate which engine version they require and having engines check this, rather than blindly applying updates, would have prevented this.
• The “fail safe” choice is more difficult than my comment suggests but, in any event, an auto-lobotomy is not a reasonable failure mode (any more than auto-vaporising is). The problem is that dealing with the incompatibility by ceasing to apply updates means that a machine is being unexpectedly transitioned from “up to date protection” to “out of date protection” while still in use, connected to the Internet, etc. There is a policy choice here: for corporate-owned machines where security responsibility is not with the user of the machine, a protective shutdown and lockout which only an authorised administrator can undo is a better response. For machines where the user is also responsible for security (e.g. owns the machine), a system-tray alert that protection is now outdated – and will require an upgrade to resolve – would be a more appropriate response.
• Host-based protective software (at least where it has the ability to prevent, rather than simply to alert) introduces self-DoS risks which affect product selection and configuration choices. This is not to say that host-based software shouldn’t be used (quite the contrary, I believe that it is a must), just that it is worth recognising that host- and network- based aren’t just “the same thing in two different places”; rather they have a different set of risks and benefits.