Lost in Reception

It’s like déjà vu all over again.

Eight months ago I wrote about McAfee’s blunder, and then two months ago about Sourcefire doing the much the same; now BitDefender has joined the fun. (also, also)

Rather than rehash my entire article, some fine-tuning:

Bricking a device because its software was out of date is not a reasonable failure mode.

…nor indeed, bricking a device because of a broken process for developing and testing signature updates. Stated another way, “wrong version” isn’t the only possible cause of problems in this area; automated distribution of signatures/software multiplies the impact of all kinds of bug. David Cawley drew my attention to BitDefender’s problem and suggested a possible cause: an automated process for recognising files created by malware coupled with no smoke-testing for new signature releases. In a previous life I created a signature distribution system and, amongst other things, included a step to automatically load a copy of the about-to-be-released signature set onto an instance of the target system and verified that it didn’t crash as a result. This was not quite the same scenario as that for a host-based anti-malware system (the test amounted to “does the signature set load correctly”), but the idea is the same: if you’re going to automatically distribute signatures, or software, then verifying that it will run in its likely deployment environment(s) without disrupting service is a must. Even if that’s not entirely feasible, or not feasible for all possible platform configurations, sanity checking proposed blocked files against NIST’s RDS, and indeed, your own software (apparently BitDefender was also quarantining itself) would appear to be a bare minimum level of diligence.

There is nothing in what happened that is specific to McAfee. Similar risks apply to all protective systems.

Quite.

[The set of problems around automated distribution of software, signatures, etc.] almost argues for different [update] 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.

My guess is that errors of this type are going to be made again and again. Practising defence in depth, and including security vendor errors amongst the threats to defend against, remain vitally important.

(In case it’s not amazingly obvious, I do have a commercial interest in the topic of this post!)

I am thrilled to be able to say that BoxSentry has finally released the third and most ambitious form of our approach to preventing email loss caused by [anti-]spam filters: TrustCloud.

The website covers what it is and does pretty well so I won’t repeat it here. Sadly, as with RealMail and LogiQ, only the administrators or developers of email security systems can deploy it; an end-user deployable version remains a wishlist item for the time being.