Arms Race

While listening to an interview with Bruce Schneier recently, I was struck by his depiction of the problem of the red and blue doors. Simply put, he observes that much security thinking is (given the way politics works) inevitably built around watching which door the bad guys go through, then putting guards on it. Money spent, “something has been done”, problem solved.

Unfortunately, the bad guys aren’t that stupid; if you put guards on the red door, they will stop going through it and just go through the blue door instead. You’ve spent money, effort and political capital implementing a “solution” that doesn’t work in the face of their adaptation: in other words, you’ve made them do something they wouldn’t have done if you hadn’t put the guards on the red door, but your security hasn’t improved. In the example of the doors, the opponents are simply choosing a different, probably equally accessable target; this is the enduring problem in fighting terrorism in a reactive way, and also applies to malware. There are no shortage of ways to write a virus, or e-mail spam, or a phishing attempt.

If we manage to get a little ahead of the opponent by depriving him of easy alternative targets, we might think we get to win the game. Again, that relies on the idea that the opponent is static; that only we have the ability to adapt. What actually happens is that in the absence of easy alternatives, we force our opponent up the technological ladder instead. Spam has to be much more sophisticated to get past filtering systems now, and so it is; viruses need to be much more devious to get past anti-virus programs, and we now observe viruses that come in encrypted .zip files along with captcha-encoded passwords embedded as images in the message.

In short, if we get really good at defense, we swap the game of technological whack-a-mole for a possibly even more expensive evolutionary arms race.

I got another taste of this today when this blog was hit by a storm of comment spam, all apparently advertising one or two web sites. I’ve been running Jay Allen’s MT-Blacklist plug-in for some time, and it is pretty much the ultimate in whack-a-mole solutions as long as you keep the blacklist updated. The worrying thing here is that the wily comment spammer had encoded each of the advertising URLs differently, using numeric entities for a different selection of characters in the URL so that it is harder to include all of the possible encodings in a blacklist.

I’d guess Jay is already beavering away plugging this particular hole so that numeric entities are collapsed before checking for spam URLs. For all I know, that’s already done (I upgraded to the latest version, just in case). In the longer term, though, I think this is a sign that MT-Blacklist is now sufficiently successful that comment spammers have become frustrated with being whacked moles and feel the need to move up the technological ladder. We need to respond not just with a fix for this one issue, but with a different approach to the problem.

Maybe that next answer is TypeKey, maybe not. But in an arms race, nothing ever gives superiority to one side for ever.