Picking a Security Policy

Even paranoids have enemies.
—ANONYMOUS
A security policy is the set of decisions that, collectively, determines an organization’s posture
toward security. More precisely, a security policy determines the limits of acceptable behavior,
and what the response to violations should be. Naturally, security policies will differ from
organization to organization. An academic department in a university has different needs than a
corporate product development organization, which, in turn, differs from a military site. But every
organization should have one, if only to let it take action when unacceptable events occur.
In this book, we are not much concerned with how to respond to incidents; that is covered quite
well in other works, such as [Holbrook and Reynolds, 1991]. But defining the limits of acceptable
behavior is fundamental to the operation of a firewall.
Picking a Security Policy 5
Hosts
detected
on the
Internet
100
1,000
10,000
100,000
1,000,000
10,000,000
81 82 83 84 85 86 87 88 89 90 91 92 93 94
Source: nic.merit.edu:/nsfnet/statistics/history.hosts
Total nets
(solid)
and non-U.S.
nets (dotted)
registered on
NSFnet
1988 1989 1990 1991 1992 1993 1994
10
100
1,000
10,000
100,000
Source: nic.merit.edu:/nsfnet/statistics/history.netcount
Figure 1.1: Internet growth.
6 Introduction
The first step, then, is to decide what is and is not permitted. To some extent, this process is
driven by the business or structural needs of the organization; thus, there might be an edict that
bars personal use of corporate computers. Some companies wish to restrict outgoing traffic, to
guard against employees exporting valuable data. Other aspects may be driven by technological
considerations: a specific protocol, though undeniably useful, may not be used, because it cannot
be administered securely. Still others are concerned about employees importing software without
proper permission: the company doesn’t want to be sued for infringing on someone else’s rights.
Making such decisions is clearly an iterative process, and one’s answers should never be carved
in stone or etched into silicon.
1.2.1 Stance
The moral of this story is, anything you don’t understand is dangerous until you do
understand it.
Beowulf Schaefer in Flatlander
—LARRY NIVEN
A key decision in the policy is the stance of the firewall design. The stance is the attitude of the
designers. It is determined by the cost of the failure of the firewall and the designers’ estimate
of that likelihood. It is also based on the designers’ opinions of their own abilities. At one end
of the scale is a philosophy that says, “we’ll run it unless you can show me that it’s broken.”
People at the other end say, “show me that it’s both safe and necessary; otherwise, we won’t run
it.” Those who are completely off the scale prefer to pull the plug on the network, rather than
take any risks at all. Such a move is too extreme, but understandable. Why would a company
risk losing its secrets for the benefits of network connection? One can best appreciate just how
little confidence the U.S. military has in computer security techniques by realizing that connecting
machines containing classified data to unsecured networks is forbidden.
In general, we lean toward the paranoid end of the scale (for our corporate environment, we
should stress). We’ve tried to give our firewalls a fail-safe design: if we have overlooked a
security hole or installed a broken program, we believe our firewalls are still safe. Compare this
approach to a simple packet filter. If the filtering tables are deleted or installed improperly, or if
there are bugs in the router software, the gateway may be penetrated. This nonfail-safe design
is an inexpensive and acceptable solution if your stance allows a somewhat looser approach to
gateway security.
We do not advocate disconnection for most sites. Our philosophy is simple: there are no
absolutes. (And we believe that absolutely􀀀_􀀀_􀀀 .) One cannot have complete safety; to pursue
that chimera is to ignore the costs of the pursuit. Networks and internetworks have advantages;
to disconnect from a network is to deny oneself those advantages. When all is said and done,
disconnection may be the right choice, but it is a decision that can only be made by weighing the
risks against the benefits.
Picking a Security Policy 7
We advocate caution, not hysteria. For reasons that are spelled out below, we feel that firewalls
are an important tool that can minimize the danger, while providing most—but not necessarily
all—of the benefits of a network connection. But a paranoid stance is necessary for many sites
when setting one up, and we can prove it.
Axiom 1 (Murphy) All programs are buggy.
Theorem 1 (Law of Large Programs) Large programs are even buggier than their size would
indicate.
Proof: By inspection.
Corollary 1.1 A security-relevant program has security bugs.
Theorem 2 If you do not run a program, it does not matter whether or not it is buggy.
Proof: As in all logical systems, 􀀀false
_
true
___
true.
Corollary 2.1 If you do not run a program, it does not matter if it has security holes.
Theorem 3 Exposed machines should run as few programs as possible; the ones that are run
should be as small as possible.
Proof: Follows directly from Corollaries 1.1 and 2.1.
Corollary 3.1 (Fundamental Theorem of Firewalls) Most hosts cannot meet our requirements:
they run too many programs that are too large. Therefore, the only solution is to isolate them
behind a firewall if you wish to run any programs at all.
Our math, though obviously not meant to be taken seriously, does lead to sound conclusions.
Firewalls must be configured as minimally as possible, to minimize risks. And if risks do not
exist, why run a firewall? We forbear to label it an axiom, but it is nevertheless true that some
paranoids have real enemies.
We can draw other conclusions as well. For one thing, we feel that any program, no matter
how innocuous it seems, can harbor security holes. (Who would have guessed that on some
machines, integer divide exceptions1 could lead to system penetrations?) We thus have a firm
belief that everything is guilty until proven innocent. Consequently, we configure our firewalls to
reject everything, unless we have explicitly made the choice—and accepted the risk—to permit it.
Taking the opposite tack, of blocking only known offenders, strikes us as extremely dangerous.
Furthermore, whether or not a security policy is formally spelled out, one always exists. If
nothing else is said or implemented, the default policy is “anything goes.” Needless to say,
this stance is rarely acceptable in a security-conscious environment. If you do not make explicit
decisions, you have made the default decision to allow almost anything.
It is not for us to decree what services are or are not acceptable. As stated earlier, such decisions
are necessarily context-dependent. But the rules we have given are universal.
1See CERT Advisory CA-92:15, July 21, 1992. Information on obtaining CERT advisories is given in Appendix A.