…we can defend against those; [we know] how to shape our applications around that. When we're talking [about] a totally new kind of attack, it's difficult to anticipate how to defend against them. We can do what we can, but it's just going to close the gap a little bit. There will always be a gap.
This basic concept is what a lot of business people don't seem to understand: there is no such thing as a bug-free system — no system is ever devoid of flaws. Someone could write a perfect application with no perceptible flaws, but, the minute they finish that application and it goes out into the world, people will start coming up with new concepts and new uses of that application that the designers did not intend and did not anticipate. It will break; it will have flaws.
I remember a time long, long ago, before sport utility vehicles dominated the roads, when cars were [just] cars. When cars slam into each other, you were worried about bumpers on the front, bumpers on the side, seatbelts and that was it. Now we've got nice small cars, and big SUVs. If I'm driving a Mini and I slam into a big truck-like car, then their bumper's at the height of my windscreen. The Mini was safe when it was on the road with other Minis, but then the environment changed around it and now I have a security problem.
It's the same thing with application code; it can look great today but, as soon as you put it out in the real world, the real world will change. There's another version of this that gets bandied about a bit, which is: "As soon as you build a foolproof system, the universe will build a bigger fool." This is why software vendors and product vendors are constantly upgrading and updating their systems.
Application code can look great today but, as soon as you put it out in the real world, the real world will change
Andrew Walls, Gartner
What should developers do to make their software less susceptible to security flaws?
Fundamentally, the development community needs to take personal responsibility for security. Security is not something that can be slapped onto a piece of code once it's all done. Every structure within that piece of code has got to be built with security as an objective. It used to be that security was not considered to be a business requirement and so, when you were developing an application, or a driver even, you were driven by performance and functionality — security requirements were not inserted into that environment. The result was that you got a lot of buggy code floating around systems, and there's always someone who's going to discover flaws in something that hasn't been updated in 10 years.
The fix is not more firewalls, more IDS, or whatever — those things buy us time and they slow the attack down, but they won't solve it. The problem is in the coding. Now, admittedly, you can't cure every ill — a new problem will pop up as soon as you put it back in the wild — but the coding structures and the approach to coding must have security as a major aspect of the process at all levels.
This goes back to how we teach programmers. Our universities are now taking security much more seriously. We don't see security as just a unit you have to take; now security is being involved in every single unit in programming classes at more and more universities. That's exactly the attitude we need in every business process and every development system. Security has got to be a bedrock requirement of every piece of code generated. We're seeing this in universities and, slowly but surely, we'll see it in the business world as well.
