Bank of America recently discovered that one of its employees had planted malware on some ATMs and had stolen a little over $300,000. Two very obvious countermeasures come to mind – use embedded devices instead of COTS, and whitelisting. There is really no reason that arbitrary code should be run on an ATM, and therefore there’s no reason to allow it.

A few weeks ago Trustwave reported on a new piece of malware that targets ATMs. This sparked a conversation in Bruce Schneier’s blog about the value of running a well known commercial OS (like Windows) on a limited use device (like an ATM or voting machine). The debate has centered around the fact that commercial operating systems have well known vulnerabilities which can be targeted by black hats. This has of course raised calls of security through obscurity.

I’ve been doing a lot of work in this area of late, and I think the debate is missing the point. Writing a custom OS for a custom piece of hardware is not more secure than a Windows OS on a Intel chip because it’s less common, it’s more secure because it does less. A windows machine is general purpose – it can be used to surf the web, read PDF documents, play movies, edit images, send email, and transfer files. An ATM should do none of those things. If you were making an ATM from scratch and not using Windows, you would undoubtedly write a very small custom OS that would only perform the dozen or so functions that an ATM actually needs to do. It is not more secure because it is obscure, it is more secure because there is less of it to be insecure.