Tuesday, April 03, 2007

Where is Security??

The knee-jerk reaction says, "Security should be everywhere," and there's some truth to that. But I think there's value in breaking things down a bit more. Should all security live everywhere? That's a more useful question, and one that bears some study as we enter a season that promises to be chock full of new threats.

I started thinking about this when I saw a story about AT&T and Trend Micro providing products and services that offer content filtering, malware protection, spam filtering, and the like at the service provider level. This approach is discussed at the same time that we look at tips on desktop security. (See How to Secure Desktop PCs With Personal Firewalls.) Both are valuable discussions, but how many discussions have to be repeated for each level of the infrastructure?

Much of the discussion about security at the ISP level makes sense, as you can catch huge traffic volumes up in the cloud rather than choking an individual company's routers and firewalls with tons o' crud. Once you've acknowledged the sense of this approach, though, how much security should you slide upstream?

At the consumer level, I'm seeing just about every ISP trumpet its security features. The strong implication is that you should trust the ISP for all your security needs. For some consumers that might almost be true, but for any consumer that roams the landscape with a portable computer, and for every business user, an ISP's security offerings are going to have some holes. So now there are holes, and you have to put your own security in place -- which security goes where?

It's easy to say that it doesn't matter if you have three levels of, say, spam filtering with your ISP, corporate mail server, and desktop. It's easy to say, but not necessarily correct because each of those levels has costs associated with it -- initial purchase costs and on-going costs in maintenance, management, and performance. I've often spoken in favor of the "Swiss Cheese Security" model -- you know, the one where any given layer of the security infrastructure might have holes, but none of them go all the way through the system. This model doesn't depend on three-deep redundancy of every function.

As we try to make our information and infrastructure more secure it makes sense to ask which security function should predominate at a given level of hardware and software. Rather than repeat functions through the infrastructure, look to make each function as robust as possible in the layer where it predominates, then focus your attention on other functions in other layers. It's a more rigorous approach, and one that may seem less secure because there are fewer redundant instances of each function. It is, however, the approach most likely to keep security progressing while holding costs and complexity to a minimum.

No comments: