Search Security today put out a list of reasons why we need email firewalls. My question is this: how many firewalls do we ultimately need? Already, if we are a typical enterprise, we probably already have multiple DMZ's, each of which requires one or more "traditional" (IP) firewalls, then we'll probably have "application firewalls" for proxying SOAP or other XML connections (probably one or two per DMZ,) we might have an outbound http proxy/gateway (e.g. squid, inktomi,) now we have email firewalls, and "cutting edge" vendors are already selling "database firewalls".
Here's what I'm getting at - is the end-point a world where every application has its own firewall? How about IM firewalls? Is that coming too? I'm skeptical about introducing all this complexity - I think the gauntlet has been laid down. Nobody wants to introduce a new box (and hence a new bottleneck) into the landscape for every new application that we use. How can we as an industry design applications that do not require all this additional overhead? After all, it's not just the cost of the product, but the cost of maintaining that product over time - with patches and administration, each new entry to the ecosystem adds a cost of much greater magnitude than the sum of the individual parts. If we as an industry keep going down this road, I hope enterprises are prepared for when they see the bill.
Posted by Ed at March 9, 2005 09:42 AM