The word "policy" makes many people flinch, because it
suggests impenetrable documents put together by unknowledgeable
committees, which are then promptly ignored by everyone involved (except
when they make a good excuse or weapon). That's not the kind of policy
we're discussing in this chapter.

The policy we're talking about here is like a nation's foreign policy.
It might be discussed in documents - of varying amounts of
legibility - but its primary purpose is to lay out a direction, a
theory of what you're trying to achieve. People sometimes confuse the
words "policy," "strategy," and
"tactics." A
policy
is what
determines what wars you're going to fight and why. A
strategy
is the plan for carrying out the war. A
tactic
is a method for carrying out a strategy.
Presidents determine policy; generals determine strategies; and
anybody down to a foot soldier might determine a tactic.

Most of this book is about tactics. The tactics involved in building a
firewall, the nitty-gritty details of what needs to be done here, are
complex and intricate. However, no matter how good your tactics are, if
your strategy and policy are bad, you can't succeed. In the 1800s, an
American named William Walker set out to conquer Nicaragua for the
United States. His strategy and tactics were, if not impeccable,
certainly successful: he conquered Nicaragua. Unfortunately, there was
a literal fatal flaw in his plan. The United States did not at the time
want Nicaragua, and when he announced that he had conquered it, the U.S.
government was completely uninterested in doing anything about it.
Walker ended up ruling Nicaragua very briefly, before he was killed in a
popular uprising. This was the result of getting the strategy and the
tactics right, but completely botching the policy.

Most technical computer people consider a single, unified, published
security policy to be desirable in the abstract, but believe - with a
strong basis in personal experience - that attempting to come up with
one is going to be extremely painful. For example, walk up to any
system administrator and ask about users and passwords, and you are
almost guaranteed to be rewarded with a rant. Everybody has a story
about the apparent insanity of people faced with passwords, one of the
simplest and most comprehensible security issues: the professor who
explained that he was too important to need a good password; the
mathematician who was told that he couldn't use a password because it
was in an English dictionary (and who replied that he wasn't using the
English
word that was spelled that way, he was
using the
Russian
word that was spelled that way,
and nobody had told him not to use Russian words). This kind of
experience is apt to convince system administrators that their user
community is incapable of dealing intelligently with security issues.

There is no doubt that putting together a security policy is going to be
a long, involved process, and that it's the exact opposite of the types
of tasks most technical people enjoy. If you like to program, you
are extremely unlikely to enjoy either the meetings or the bureaucracy
involved in policy making. On the other hand, putting together a
security policy is a great deal more amusing than dealing with the
side effects of not having a policy. In the long run, you'll spend less
time in meetings arguing about security if you get it out of the way
ahead of time.

Developing a security policy also doesn't need to be as bad as you may
be expecting. Many of the problems with security policies are caused
by people who are trying to write a security policy that sounds like a
security policy, which is to say that it's written in big legal and
technical words and says threatening things about how users had better
behave themselves. This doesn't work. It's also the most unpleasant
way to do things, because it involves hostility and incomprehension
all around. It's true that your organization may at some point need a
security policy that's written in big legal words (to satisfy some big
legal requirements). In that case, the security policy you write
shouldn't contradict the legalistic document, but the policy you write
doesn't need to be that legalistic one.

Another problem people have in trying to write security policies is
that they have a strong feeling about what the policy ought to be, and
they're uncomfortable that the actual policy they enforce does not
meet that standard. There is a great deal of lip service paid to the
notion that security should be absolute: you should have a site that
nobody could ever break in to; where every user has exactly one
account, and every account has exactly one user; and where all the
passwords are excellent, and nobody ever uses anybody else's password
for anything.

In the real world, nobody's site is like that, a fact that is well-known
and well-accepted. That doesn't keep people from claiming that they want
to make their site like that, sometimes in big words on many pieces of
paper that they call a security policy. Invariably, every time, without
exception, these policies are not followed by anybody.

It's unlikely that your policy is one that emphasizes
security at all costs. Such a policy would be irrational. It is
reasonable to value other things highly enough to be willing
to compromise security.

Most houses would be more secure with bars over all the windows. Few
people are willing to put bars over their windows, despite a desire to
protect themselves. People have a number of reasons for compromising
their security in this way. To start with, bars are expensive and they
interfere with using the windows for many of their normal purposes
(e.g., seeing out of, climbing out of in an emergency). But people are
willing to go to equal expense and inconvenience to apply other security
solutions, and they may avoid barring windows even when it's the
cheapest and most convenient solution, because it looks bad and makes
them feel oppressed.

This is entirely reasonable, and it's entirely reasonable to make the
same type of decision about your computer security. You may not want
the best security money can buy, or even the best security you can
afford.

What do you want? You want the best security that meets your
requirements for:

Affordability

How much money does the security cost?

Functionality

Can you still use your computers?

Cultural compatibility

Does it conflict with the way people at your site normally interact
with each other and the outside world?

Legality

Does it meet the your site's legal requirements?

Don't pretend that you want to be absolutely secure, if only you could
afford it. You don't live your life with the most perfect security money
could buy. For the same reasons, it's extremely unlikely that your
institution can maintain the characteristics that are important to it if
it also installs the most perfect security money could buy. People
don't like learning or working in a hostile environment; because they
won't do it, you'll either lose the security or lose the organization.

Sometimes a small concession to insecurity can buy a large payoff in
morale. For example, rulemakers reel at the idea of guest accounts, but
a guest account for a spouse can make a big difference in how people
feel about work. And there are sometimes unexpected results.
One university computer center was asked why its student employees were
allowed to hang around at all hours, even after the labs were closed,
doing random activities of dubious value to the computer center; it
seemed insecure at best. The answer was that several years before, an
operator who was typing his girlfriend's term paper in a lab after hours
had discovered and responded to a critical emergency. Because he had
saved the facility from what seemed likely to be a million dollars worth
of uninsured damage (insurance companies have a nasty tendency to
consider floods in windowless third-floor computer rooms to be acts of
God, and thus uninsurable), the computer facility management figured
that all the computer time the operators wanted had already been paid
for.

On the other hand, if you have too little security, you can lose the
organization to lawyers or attackers, and what matters there is what you
do, not what you write down. Writing down marvelous policies that don't
get enforced certainly won't save you from people who are trying to
break into your computer, and it generally won't save you from lawsuits,
either. The law counts only policies that you make some attempt to
enforce. Writing it down and brazenly not doing it proves that you
aren't simply too stupid to know what to do: it demonstrates that you
actually knew what you had to do, and didn't do it!

It's important that the policy be explicit and understandable
about why certain decisions have been made. Most people will not follow
rules unless they understand why they're important. A policy that
specifies what's supposed to be done, but not why, is doomed. As soon as
the people who wrote it leave, or forget why they made those decisions,
it's going to stop having any effect.

A policy sets explicit expectations and responsibilities among you, your
users, and your management; it lets all of you know what to expect from
each other. It's a mistake to distribute a policy that concentrates
entirely on what users need to do to make the site secure (it seems
hostile and unfair), or entirely on what system administrators need to
do (it encourages the users to believe that somebody else will handle it,
and they don't have to worry about it).

Most people are not lawyers, and they're not security experts. They're
comfortable with casual descriptions. You may be afraid to write a
policy that way because it may seem uncomfortably casual and too
personal. But it's more important to make your security policy
friendly and understandable than to make it precise and
official-looking. Write it as if you were explaining it to a reasonably
bright but nontechnical friend. Keep it a communication between peers,
not a memo from Mount Olympus. If that's not acceptable in your
corporate culture, write two separate policy descriptions.

You will not get people to comply unless they understand the document
and want to comply with it, and that means they have to at least be
willing to read it. If they shut their brains off in paragraph two
because the document sounds legal and threatening, you lose. You also
lose if they decide that you think they're stupid, or if they decide
that you don't care. Don't get so informal that you seem condescending
or sloppy. If necessary, get a technical writer to clean up the
punctuation and spelling.

Writing down the policy is not the point; living by it is. That means
that when the policy isn't followed, something should happen to fix it.
Somebody needs to be responsible for making those corrections happen,
and the policy needs to specify who that's going to be and the general
range of corrections. Here are some examples of what a security policy
might specify:

Managers of certain services have the authority to revoke access.

Managers will be asked to take care of some kinds of
transgressions.

Facilities that don't meet certain standards may be cut off from the
corporate network and external access by the people who run the
corporate network.

The policy should specify who is going to decide and give some
indication of what kinds of penalties are available to them. It
should not specify exactly what will happen when; it's a policy, not a
mandatory sentencing law.

You can't expect to set a policy up once and forget it. The needs of
your site will change over time, and policies that were perfectly
sensible may become either too restrictive or too lax. Sometimes
change is obvious: if you work for a startup company that goes from
six people to 6,000 people, it will probably occur to you that things
are different in important ways (but you still may not get around to
redoing the security policy if you didn't set up a mechanism for that
in advance). If you work for a 200-year old university, however, you
may not expect much change. However, even if the organization appears
to be doing its best to fossilize, the computers change, the external
networks change, and new people come in to replace ones who leave. You
still need to review and change your policies on a regular basis.

Because of the differences between organizations, it's hard to be
specific about issues without writing an entire book just about security
policies. However, here are some common issues to consider when you are
writing a policy:

Who is allowed to have an account at your site? Do you have guest
accounts? What do you do about contractors, vendors, and clients?

Can accounts be shared between multiple people? What about a
secretary who uses an executive's account to process that person's
electronic mail? What about joint projects? What about family members?
Is it sharing an account if you let somebody else borrow a window on
your machine really quickly?

When do people lose the privilege of having an account, and what
do you do about it? What happens if people leave or are denied access?

Who can set up dial-in modems? Is it
OK
for other
people to set up dial-out modems? Is there anything special about
PPP
,
SLIP
, or
ISDN
lines?

What do people need to do before they connect a computer
to the main network?

How secure do computers need to be before they get services from
centrally maintained machines?

How secure do computers need to be in order to connect to a
network with unprotected access to the Internet?

How is financial data going to be protected?

How is confidential information about people going to be
protected?

What do individual users need to do to protect themselves and the
site? What kinds of passwords should they have, and when should they
change them?

What can people do on the Internet? Should they be transferring
random executables in and running them?

What precautions do you need to take against viruses on personal
computers?

Who can connect your site to external networks, and what's an
external network? Is it
OK
for a project manager to connect your site to
another specific site? How about putting in a second Internet
connection?

How are home computers going to be secured? How are they going to
get secure access to your network?

How are people who are traveling going to get access to the
network?

What information is considered company confidential? How is it
going to be protected? Can it be sent outside the site via electronic
mail?

If you have remote sites, how are they going to get secure access
to your main network?

The security policy needs to describe what you're trying to protect and
why; it doesn't necessarily need to describe the details of how. It's
much more useful to have a one-page document that describes
"what" and "why" in terms that everyone in your
organization can understand, than a 100-page document that describes
"how," but that nobody except your most senior technical
staff can understand.

For example, consider a policy that includes a requirement that says:

Nonreusable passwords shall be used to authenticate all incoming
connections from the outside world, in order to prevent potential
attackers from being able to capture reusable passwords by monitoring
such connections.

This requirement is much more useful than a policy that says:

S/Key will be used for all incoming connections.

Why? Because the first policy describes
what
is to
be protected and
why
, and it leaves
how
open so the technical staff can select the best
implementation.

A policy that says the following is better yet:

Regular passwords are often stolen and reused when they pass across
networks. We won't use passwords that can be reused across networks our
company doesn't control.

This policy communicates the same information without the legal-style
language. It also clarifies some other points. For example, in the
original language does the "outside world" include companies
that have special relationships with yours? It may seem obvious to you
that it does, but it probably doesn't seem obvious to the managers who
are arranging to work with those companies. The reworded language makes
it clear what the criterion is (although you may still end up arguing
about what networks meet it).

Policy can guide you in selecting and implementing technology, but it
shouldn't be used to specify it. It's often much easier to get
management to buy into, and sign off on, an overall policy than on a
specific technology.

Every site's security policy is different. Different sites have
different concerns, different constraints, different users, and
different capabilities; all of these lead to different policies.
Further, a site's policy may change over time, as the site grows and
changes. Don't assume that you need to do things the way they've always
been done, or that you can borrow somebody else's policy and simply
change the names in it.