Rethinking software security evaluation: Time to interrogate the chef

Dr. Herbert H. Thompson

If you were running Windows XP at work and used McAfee to protect it, Wednesday, April 21st was probably a pretty interesting day. Through an automated update, McAfee antivirus software wrongly identified a core Windows system file as a virus on some machines. It "cleaned" the infection, removing the suspicious file, which put thousands of government and corporate machines into an infinite reboot cycle.

The impact ranged from shutting down computers in the patrol cars of Kentucky state police to postponing elective surgeries in some Rhode Island hospitals. McAfee isn't the first company to pass through a bad update, and in the rapid-fire world of antivirus, quick turnarounds for updates are the nature of the business. This latest incident though shines a light on the risk of automatic update, and more broadly, hints at new approaches we need to evaluate the security of modern software.

When a desktop application reaches out to the Internet for extended functionality, help documentation, and updates, it starts to take on some of the properties of a Web-based application in that some functionality may change without our explicit consent or knowledge.

How many times have you logged into your Web-based e-mail account, a social networking site or an online retailer only to see that the site looks or behaves slightly differently from the last time you logged in? When we start to see these same dynamic characteristics in the desktop software that manages legally protected information or keeps key government offices running, it means we need to change the way we assess software and software vendors. 

Buying software needs to be viewed as subscribing to a service, where regular changes and updates occur seamlessly. Under this model, evaluating software means asking software vendors hard questions about development and update processes. How is security integrated into your software development, testing, and response processes? What percentage of your development staff is dedicated to security? Do these folks attend security conferences, training, etc., to stay current? What development security awareness and training programs do you have in place? What process improvements have you made as a result of vulnerabilities reported in your software?

Understanding software development and maintenance processes will be even more critical as more services move out to the cloud.

Ultimately, mistakes happen, vulnerabilities slip through the cracks of development, and, yes, sometimes updates make things worse. Long term though, we need to look at the commitment that software vendors have to security and the processes they use to build and update applications. Instead of just tasting the soup, we need to start interrogating the chef.