Firewalls: The New Maginot Line
Mechanisms like firewalls have the downside of frustrating effective use of the network, while providing only the illusion of security. Updated with comments about malicious programs sent via email.25-Feb-1998


Update: Turns out that Andre Maginot told the French they still needed and army but unfortunately he died the politician ignored his advice

Internet security is a serious concern. But we have a responsibility to provide an effective solution rather than the illusion of one.

Firewalls do have a place in protecting legacy systems from attack, but protection from attack must not be confused with an effective solution.

An effective solution must meet the following criteria:

  • It must work sufficiently well in the absence of any special action by the user and must not fail due to simple errors whether on the part of the user or anyone else.
  • It must be understandable by the users. People cannot and should not trust systems they don't understand. A lack of understanding exacts a price in inhibiting effective use of the security mechanism. In terms of business, it means a lower return on the investment in technology and, perhaps, the loss of strategic advantage.
  • It must work "with the grain" of normal behavior.

It came in the mail!

The increasing concern about malicious programs (worms? viruses?) delivered via mail clearly illustrates that the problem with firewalls. Once these programs run on any machine inside a campus network, they can quickly find other unprotected machines and do damage. And because of the reliance on firewalls, there are many such unprotected machines.

The virus analogy is a apt since such stresses are necessary in order to develop an effective immune systems. Creates that develop in a benign environment fail to develop the necessary antibodies to protect against attacks.

The key is to keep the architecture simple and explicable and to make the defaults "safe".

The good news is that we are developing mechanisms such as IPSEC (IP Security) to support secure connections between systems. We must be careful to keep aspects of the problem separate. For example, the mechanism of employing a key is separate from that of associating keys with individuals. We needn't make the IPSEC implementation dependent upon finding a single universal access policy. There isn't one. Instead we need to provide the tools that support a variety of policies.

Update: The October 1998 issue of Scientific American has an article detailing a possible site attack. It is a good example of the vulnerability of a site protected by a firewall. Once one finds a path around the wall, the entire site is vulnerable. Note that there is much to criticize about the article so don't take it too seriously, except as an example of going around a firewall. The methods and the responses are not very realistic.

Why Firewalls are Like the Maginot Line

Security is more than putting up a big fence as the French learned when they relied on the Maginot Line for their defense. The fortification was impressive but the Germans simply walked around it. Unfortunately for the French, the Maginot Line gave them the illusion of security so that once the Germans had evaded it, there were no other significant barriers.

There is a real problem with legacy systems. LANs have been developed with a simple notion that it is shared among friends and that social strictures are sufficient. But the Internet allows the entire world access, and therein lies the problem.

We do need to provide a "front door" that prevents strangers from entering the halls of the corporation. This analogy is useful for keeping legacy systems, those created in the benign environment, from exposure to a hostile world.

The analogy of the front door is very appealing, after all, it works very well for our homes. But it doesn't scale to larger and more complex environments.

It is very attractive to view the firewall as a starting point and as the focus for security. But this is a very bad idea. Even if it worked, there is a fundamental conflict between putting a high wall around the corporation and integrating the Internet as a fundamental means of doing business. But the idea isn't even valid, it gives only the illusion of security.

One pragmatic response to firewalls has been to create ways to work around firewalls by creating tunnels through them. Since web traffic is normally permitted, other traffic is made to look like a web page. For example, Real Audio traffic (audio and video streams) looks like just another image on a web page. The result is a constant battle to guess on what is really being sent across the firewall. This involves guessing at the intent of the traffic. Email messages are opened and the messages are examined for known viruses and other problems. Does this mean that users can ignore normal safety considerations and run any program they get via email? Of course not, so why focus one's efforts on endless skirmishes? The result is that security actually diminished by diverting efforts from providing effective protection. If email is encrypted, this whole complex effort at snooping is rendered moot.

Imagine trying to do business when one has to justify each call to a new phone number to the company operators and each call is screened for appropriateness. It would require a large support staff while frustrating those who simply need to get their job done. The Internet is rapidly becoming a more important tool than the telephone. It is appropriate to be concerned about the security problems, but one must seek effective solutions.

Getting Real

As noted, firewalls do have a place in protecting legacy systems. The tragedy of firewalls is that they remove the incentive to address the real security issues inherent in these legacy systems.

We must focus on effective security. Each system must take responsibility for its own protection. This requires giving the users of these systems the means to do so. For systems with effective security, the firewall must simply get out of the way.

How do we create such systems? This essay can't do more than touch upon some of the points:

  1. All systems must default to providing no access at all.
  2. Applications that do choose to provide access must do so with an awareness of the Internet:
    • If access is public, it is really public to everyone in the world.
    • Innocent errors on the user's part shouldn't result in exposure.
    • Access must be audited for failures whether due to user errors or system problems.
  3. In order to specify access, we need ways of specifying who has access:
    • Credentials must be universal. Current systems typically define user names only within the local network.
    • Credentials are associated with people, with systems, with locations or other factors. But they must be meaningful to those who are setting the policies.
  4. Existing legacy systems, primarily Windows systems, need to be retrofitted. We can reuse the concept of the firewall but move it within the system. Existing unsafe services, such as file sharing, would be blocked. We can then reintroduce the capabilities with explicit policies. Files would only be shared by explicitly making them available.

The basis for access would be keys (essentially large unforgeable numbers). We can then experiment with approaches to managing these keys and associating them with authorization. Since there are an essentially infinite number of such keys we can use them freely and easily create one associated with specific uses and time periods. I might, for example, use my personal key to gain access to my corporate key. This indirection allows it to be revoked. I may also have keys associated with my role (or job). Such a key might be used less often so as to be less likely to be exposed and stolen.

This indirection allows us to separate issues such as establishing who I am from the mechanism of access. Agencies, such as Verisign, can compete for authenticating who I am.

This approach seems simple, and it is. In fact, simplicity is a requirement for real security. If we can't understand it, it is likely to be vulnerable to attack.

There is some progress with protocols such as IPSEC which define standards for authenticated and encrypted connections. Firewalls are often justified because they often come with services for working around the limitations of the current IP address (V4), Version 6 (IPV6) addresses these issues.

The bad news is that the focus and blind faith in the magic of firewalls has managed to divert attention from effective solutions.

Related Issues

Ideally we can have a simple (or, "stupid") network. One that allows very simple and efficient universal connectivity. Any two devices anywhere in the world can connect to each other (or multicast to many others).

With IPV6 providing sufficient addresses and each device safe to connect directly to the net, this is doable. Such simplicity provides many opportunities for innovation and assures that the economic benefits of the Internet will continue.

The danger is that we will opt for complexity in our security strategy. The result will be little security and much frustration. Just as any disaster creates busy work that seems to contribute to the economy, a complex Internet creates self-perpetuating activity. But it also retards progress.


We have managed to confuse clever workarounds for legacy issues with effective security. Adding mechanisms to existing complexity can only decrease security and frustrate the effective use of the Internet as a strategic tool in business.

It is important that we do not lose site of the larger issue. The Internet is based on simple and explicable protocols. Creating complex mechanisms simply frustrates fulfilling its promise.


Maginot Line References

For those interested in learning more about the Maginot Line:

Postscript: Other Maginot Line Analogies

The folly of the Maginot line does serve as an effective metaphor for other failures. I'll add to this list as I run across references.