Back in the day, firewalls were all the rage. The bad stuff was outside, the good stuff was inside, and the firewall was the line between them. I haven't heard anyone seriously advocating the 'crunchy shell, chewy center' model for many years, and there is more than one long-standing list of anti-firewall arguments, plus recurring questions about where, exactly, the perimeter is anyway. Yet most corporations still use them, in one form or another. Why?
For one thing, a filter (a module or device that only some things go through, but others don't) is a very basic security technology. Just as there are a limited number of elements in the periodic table, there
are a very limited number of basic security technologies, so even when people are building "new" security technology, the most basic pieces to pick from are limited, and you'll see a lot of repeats. Since firewall is a pretty well-known word that covers several members of this family, any filtering technology that works on traffic of some sort (whether it be a packet filter or a web application firewall) will tend to be called a firewall, even though firewalls now frequently work much higher up the stack than they did in the 80s.
So the real question is, what good is a filter installed on a perimeter? Most people will say it's for defense in depth, i.e. "We know it's not perfect, but we're hoping each layer will catch some different things and minimize the bad stuff that gets all the way through." It's the stock answer, and I wouldn't argue against the concept, but I think it misses a key point:
In a network, filters (including firewalls) break what can be enormously complex into smaller, more manageable pieces. It's like providing an API and using it to write modular code. The goal is to minimize the cases in which tweaking something over here wiggles something unexpected way over there. Sounds good for maintainability, but what does reducing action-at-a-distance have to do with security? Here we go back to design flaws. If the designer wasn't expecting anything else to be using or modifying some resource, but something else can, there could well be an exploitable design flaw. A well-configured filter in a good location can reduce the possibility of interaction, and therefore the chance the design flaw will be exploitable. Plus, partitioning any system means you can partition security analysis: each portion, the partitions, and any possible interactions between them. Without the partitions, it's all interactions, which are the least-well-understood security analysis subject I can think of.
These days, you have more perimeters than you think, and the things you are dividing aren't necessarily more adversarial to each other than they are internally. But at least if you divide them, you have smaller chunks to worry about.
-- Brenda
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
In favor of defense in depth: A host based FW can be bypassed (e.g. Sinowall). Even if the exceedingly useful host-based system is compromised, the network based FW will (hopefully) stop the trojan. IN theory.
In our instance it was the combination of the FW and the authenticated proxy that stopped it. But the point is still valid.
To clarify, I think firewalls are a fine thing to use for defense in depth, which is a good, solid security practice, and I'm glad it worked in practice in mtgarden's example.
My intended point is that filters also act as partitions. Partitions can reduce complexity; reduced complexity gives you a better chance at successful security.
I expect this use of filters, including firewalls, to become more prevalent and important over time, as relationships on the network reflect more and more of the relationships between the parties using the network. Or possibly, as we acknowledge that network relationships already reflect real-world relationships, which are usually significantly more complex than adversary and target.
Post a Comment