Place Your Trust in the New Perimeter
Trusted systems fall in where today's firewalls fall short, keeping watch on a litany of new connections and devices. by Bob Blakley
The perimeter was always an illusion.
Our elders (Jim Anderson, Roger Schell, Paul Karger, and many others) told us from the beginning that we needed trusted systems to do important work. A trusted system, in their parlance, was one whose policy was not in the hands of the user or the system owner, but instead in the hands of a trusted module called a reference monitor.
The security community agreed that reference monitors were the right structure for secure systems, and started to build them. But a funny thing happened on the way to the reference monitor: A bunch of users got trapped inside. They had to be, because it was the only place they could get useful work done.
Trusted systems are difficult to build. You have to design and code very carefully. You need to understand the mission, threats and security requirements before you build. This makes trusted systems expensive. It also makes them inconvenient; you have to accept limitations on features in the name of security.
These limitations make it difficult to do work, which drives users to try to get around the limitations and get "inside" the trusted system's inner sanctum.
We told ourselves this was OK. We told ourselves that there was nobody in here but us chickens--the good guys--so we could wall ourselves in with a bunch of highly functional, usable and untrusted systems, and surround the whole thing with a few boring, expensive trusted machines: the perimeter. We said this was the equivalent of one big trusted system.
Our first mistake was assuming that good guys exist. The bad guys kept getting in by lying to us and claiming to be good guys (Pirate!).
Our second mistake was assuming that we could surround untrusted systems. It turned out that because the untrusted systems were highly functional, they kept sprouting new ways to connect. And because they were also highly usable, people kept wanting to connect them to lots of things to get work done. And the perimeter hadn't been designed to keep an eye on the new connections.
The perimeter, it turned out, wasn't in enough places, so it wasn't effective. But the perimeter isn't disappearing, it's metastasizing. It's moving from a few systems at the boundary of an IP subnet onto endpoints in the form of personal firewalls and host-based IPS. It's moving onto email servers in the form of malware scanners. It's moving onto appliances in the form of packet filters. It's moving onto app servers and even end-user clients in the form of TPMs and virtual machines.
Soon the perimeter will be everywhere. You won't recognize it as a perimeter, because its functions won't all look like what a firewall used to do. Instead, the new perimeter will look like a flock of special-purpose security appliances. This means that we will have to pay a lot more attention to topology; form will follow (security) function in our systems.
The new perimeter will not disconnect systems; it will connect them. Connections will be dictated and enabled by the existence of an effective special-purpose security device. In the end, we will arrive at the place from which we began: each functional component will be a little trusted system, with its own tiny perimeter--because, as we always knew, that's the right structure for secure systems.
Bob Blakley is principal analyst with Burton Group. Send comments on this column to firstname.lastname@example.org.