If I want to stop credit card information from leaving my system, either over the network or through somebody's laptop or USB stick, then I have to have software that knows what a credit card number looks like and can do things when it sees data being moved to the wrong places. That goes way beyond what most popular desktop security environments do.

So these are new products that are emerging now. The desktop is not as secure as we'd like it to be, and there's still tons of room for improvement on the desktop and laptop side of the equation.

Then there's new application environments, like Web 2.0 environments. There was a great presentation by David Backley [chief technology officer at Australian bank Westpac] about how they're using Facebook-type social-networking environments within Westpac to promote collaboration and teamwork, and they're looking at virtual worlds, like Second Life, as well.

These sorts of new applications that rely on large distributed network deployment introduce all sorts of new aggregations of security risks.

I say "aggregations"; to break down these application types--virtual worlds, social networks, blogs, whatever it is--if you look at the components that make these up, they're no different from any other application. They may use a language that's a bit newer--Ajax or new forms of HTML--but they're still languages and they still have the same issues: validation and making sure the code has not been altered--the same basic thing.

The issue in the new Web 2.0 world that we're all dealing with is that those components cannot exist by themselves. It's not that you can get a copy of a word processor in one nice tidy piece on its own; Web 2.0 applications are often made up of dozens of these individual components. Those components may come from different companies or may be home-grown, developed internally. Ensuring the security of each one of those components is critical if you're going to ensure the security of the network.

With the increased complexity of these collections, or mashups, the challenge to secure them goes up logarithmically. Every time we add more systems together, the [number of] potential interactions, and the potential corruptions among them, expands, and we have to secure each of them.

The only way we can secure the whole mass is to secure each component by monitoring, managing data transfer, firewalling, and, in the end, we just have to watch our applications like a hawk. Now these are all standard approaches.

Nothing about this is new. We're doing all of these already. The issue is that it's getting more and more complex--we have to do it more aggressively; we have to do it faster; we have to do it at a much more granular level within the application than we have in the past.

As a result, we're seeing vendors with products and services coming out which focus on different levels within applications--to do code reviews, application vulnerability scanning, testing, continuous scanning and testing of application suites. This is all self-defense--how can we automate these tasks to be as responsive as we can be to continue to secure our organization? It's all about: how can we manage burgeoning complexity in the application environment? The processes are the same as they've always been, but we need to do it faster, and we need to do a lot more of it.

Nobody is going to give you more budget to do it, of course, so you've got to do it with what you've got. You've got to develop your staff, and your tools and your relationships with vendors--you've got to be a much more adept and sophisticated manager to manage security these days.

To what extent is security management going to be playing catch up with the malicious side of the security industry?
You can close the gap to a certain extent, but you're always going to be lagging slightly behind. This is the same situation that law enforcement faces: certain national governments notwithstanding, you generally can't arrest someone before they've done something wrong.

It's very difficult to defend against a truly novel attack. We know how to defend against attacks that are in classes of attacks that we know. A virus? Well, we know how to defend against viruses; we understand essentially how they work. We understand buffer overflows, so 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.