Security on the Internet A Viewpoint by Frederick M. Avolio

[Originally appeared in the Proceedings of the 17th National Computer Security Conference, October 1994]

Firewalls Are Not Enough: You have just bought a house. It is red. Is a dead-bold lock on the front door enough to secure it? The color of the house is extraneous information; you haven't been given any other information. You have no idea if a dead-bolt locked front door is sufficient. You wouldn't dream of making a security related decision on such limited information, and yet, daily, organizations are trying to establish security perimeters for their networks with little more data than we have on the above-mentioned house, thinking that firewalls are enough.

I've nothing against firewalls. In fact, I am all for them. The problem with today's attention to firewalls is that focusing on an Internet firewall focuses on only part of the broader area of network security. To secure a private network, we establish what we call a network security perimeter.

A security perimeter is established by a security policy and security policy enforcement mechanisms and methods. An internetwork firewall may be one of the mechanisms. There are usually others as well, but they come after the security policy, not before. A security policy must be joined to an implementation (the mechanisms and methods), but not directly. The things that join a security policy and an implementation together -- and help them to minor reality -- are a risk analysis and a business needs analysis. These steps are well practiced in the DoD arena -- although, unlike in the private sector, the security policy often comes first -- but much less so in industry, especially in relation to connecting to the Internet. Not only is each of these four steps -- a security policy, a risks analysis, a business needs analysis, and identifying security mechanisms and methods -- required, but order is important, too.

While among purists, a security policy is viewed as primary and something that should be established before anything else is done, I suggest that a security policy useful for an organization cannot be drawn up unless a clear understanding to the answer "What are the threats" exists. To put it another way, an organization needs to know what it needs to protect and what it is afraid of. Often a security survey is required to gather this information. Two people in an organization might both agree that they want to protect their network against unlawful electronic entry. Ask one person why, and she might say that she would be afraid of the information on the network getting out (to competitors, perhaps). The other person might say that he wants to keep the company from the "bad press" of a network break-in. A security survey gathers everyones list of what needs to be protected, from what, and why.

This information, of course, is drawn out into a formal risk analysis, wherein threats are postulated, vulnerabilities identified, probabilities of the exploitation of those vulnerabilities assessed, and countermeasures identified and priced out for cost effectiveness. (Again, while the purist would say that a cost benefit analysis has no place in a risk analysis, I say that it has to go somewhere, and since it must be done in conjunction -- hand in hand with -- a risk analysis. I call it out as part of the risk analysis.) Without such a risk analysis, an organization will have no way of knowing if their security policy matches reality and has no way of measuring if the methods they put in place are adequate.

A business needs requirement document is also needed. This does not have to be elaborate, but should include what the service requirements are and a statement of what happens to the business if the services are interrupted. After these two steps, a security policy may be developed. Every organization thinking of connecting their private network to another, such as the Internet, has a network security policy. The policy may not be written down or well formulated, but the organization has one, if they are lucky, and they have several in conflict, if they are like most organizations. A security policy must match reality, which is why a risk analysis and a business needs analysis should precede it.

Readers may remember the television program "WKRP in Cincinnati." The news announcer of that radio station, Les Nessman, didn't have a private office and couldn't get one, so, Les established his office perimeter with masking tape applied to the carpet. He got annoyed when someone walked through the "wall" instead of waiting at the "door" until invited in.

To Les, his policy was sufficient. There are organizations today that likewise have policies that do not match reality and, so prescribe methods that are insufficient, while like Les Nessman, thinking -- or pretending -- that they are sufficient.

After a risk analysis and a business needs analysis, the security policy can then suggest security mechanisms and methods. Mechanisms and methods are based on the security policy, help meet business needs, and counter perceived threats. In a network security perimeter, we may use security mechanisms and methods such as encryption of files, data transmission encryption, user authentication servers and tokens, and internetwork firewalls.

Firewalls are not enough. A risk analysis and a business analysis is almost always required, leading into the development of a security policy and the prescription of security mechanisms and methods for implementation. Doing this once is not enough. Threats change, vulnerabilities change, business requirements change, and the available countermeasure change. All of these must be periodically and routinely re-evaluated.

Security methods, such as Internet firewalls, are very popular now, but many organizations may believe, or be led to believe, that an Internet firewall alone is sufficient for securing their network. It's like getting the most secure front door money can buy for your house but leaving the garage door unlocked, or the same, weak sliding door entrance from your back deck. It's like making a stand in a fortified city, with gates and walls, but forgetting about the water shaft that runs below and outside the walls, allowing an army to make a secret entrance. (It's been done: 2 Samuel 5:6--8.) And it is like Les Nesmen's office. Only if everyone plays by the same rules is it effective.