"But there are two other techniques: one is called firewalling and the other is called keeping the software up to date. None of these problems (viruses and worms) happened to people who did either one of those things. If you had your firewall set up the right way - and when I say firewall I include scanning e-mail and scanning file transfer -- you wouldn't have had a problem. But did we have the tools that made that easy and automatic and that you could really audit that you had done it? No. Microsoft in particular and the industry in general didn't have it."
"The second is just the updating thing. Anybody who kept their software up to date didn't run into any of those problems, because the fixes preceded the exploit. Now the times between when the vulnerability was published and when somebody has exploited it, those have been going down, but in every case at this stage we've had the fix out before the exploit. So next is making it easy to do the updating, not for general features but just for the very few critical security things, and then reducing the size of those patches, and reducing the frequency of the patches, which gets you back to the code quality issues. We have to bring these things to bear, and the very dramatic things that we can do in the short term have to do with the firewalls and the updating infrastructure. "
In a recent interview for ITBusiness.ca (full text available at http://www.itbusiness.ca/index.asp?theaction=61&sid=53897), Microsoft Chairman and Chief Software Architect Bill Gates is quoted as having said:
You don't need perfect code to avoid security problems. There are things we're doing that are making code closer to perfect, in terms of tools and security audits and things like that. But there are two other techniques: one is called firewalling and the other is called keeping the software up to date. None of these problems (viruses and worms) happened to people who did either one of those things. If you had your firewall set up the right way -- and when I say firewall I include scanning e-mail and scanning file transfer -- you wouldn't have had a problem.
Mr. Gates overlooks here two critical points.
First, firewalling and patching can not in fact shield networks from all of the impact of worms and viruses. Ask any experienced network admin. There will always be users who bring into a firewalled network a laptop that was, for example, infected at home. Once that infected laptop is connected to the enterprise, the firewall is irrelevant. Worse yet, no matter how aggressively a company has propagated a patch throughout the network, the routine influx of vulnerable, unpatched systems (from that same migrant laptop community) will continue to supply fresh meat for the malicious software.
Second, the security of the application itself is tightly bound to its design and implementation as well. A company that writes its own business software could well go broke following Mr. Gates's advice.
To illustrate this, let's consider a hypothetical example that is very realistic in today's business environment. A company writes a web-based application that enables its customers to login and purchase its goods. In keeping with Mr. Gates's recommendations, they install a high quality, state of the art firewall and put in place processes for rapidly installing every security patch that Microsoft releases. (Perhaps they test them in a controlled lab environment first.)
Now, let's further say that the team that wrote the application software took the above quote by Mr. Gates to be accurate. But it turns out that there's a problem in the software that the team wrote. Because their front-end software (that runs on their web server) doesn't properly screen users' input -- after all, "you don't need perfect code" -- and an attacker discovers that a vulnerability known as "SQL Insertion" exists in the application. The SQL Insertion vulnerability enables the attacker to enter SQL-based database inquiries directly to the back-end database server, and make read/write changes to the database at will -- perhaps he would change the price of his purchase to $0 and the quantity of his order to 1000, or some such. You get the drift.
In this hypothetical example, the firewall did its job perfectly. All systems had up-to-date security patches installed. Yet the attack succeeded at compromising the database system (AKA the company's crown jewels).
While it's true that "perfect code" is probably not achievable, you do need "secure enough" code; and achieving that takes a great deal more than a good firewall and patch maintenance processes. It takes a sound design, built on top of a firm architecture. It takes an implementation of the software that is free of such common flaws as SQL Insertion, buffer overflows, and the like. And, it takes a well designed and operated production environment with a firewall and such.
Every Software Designer and Software Architect in major corporations needs to understand these principles if their own network and business applications are to be secure.
Mark G. Graff
Kenneth R. van Wyk
Authors, Secure Coding
Copyright (C) 2003, Mark G. Graff and Kenneth R. van Wyk. Permission granted to reproduce and distribute in entirety with credit to authors.