25.2. Putting Together a Security Policy
Once you know what you want in a security policy, how do you put one
together?
25.2.1. What Is Your Security Policy?
The first step towards putting together a working security policy for
your site is to decide what your personal opinion is. If you've
been administering a site or making any decisions about security,
you've been enforcing an implicit theory about security, even
if you've never articulated it. You're going to need to
come to a clear and explicit understanding of what that implicit
policy is before you can discuss policy issues with other people in
order to produce a written policy for your site.
With that in mind, look at the decisions you've made about
security and decide what you think your site's security goals
should be. That may not be the policy that your site ends up with,
but it's an important first step.
25.2.2. What Is Your Site's Security Policy?
The second step towards putting together a working security policy
for your site is to determine what everybody else's security
policy is. What do the users and managers expect security to do for
them? What do they think of the way security is handled currently?
What are other computer facilities doing and why?
Every site has at least one security policy. The problem is that most
sites have more than one, all the way up to as many as there are
people involved with the site's computers. Sometimes this
proliferation of policies is purely unconscious; different computer
facilities within the same site may be doing radically different
things without even realizing it. Sometimes it's an open
secret; administrators may be trying to maintain a security policy
that they believe is necessary, even though the user population does
not agree with them. Sometimes it's out-and-out war. Generally,
people think of universities as the main place where computer users
and computer administrators are engaged in open security warfare, but
in fact many companies spend large amounts of time fighting about
security issues (for example, administration and the engineers are
often at odds).
Some of the security policies for a site may be written down already,
but most are likely to be implicit and unpublicized. The only way to
find out about them is to ask. Be sure to ask managers, system
administrators, and users. Then look at the actual computers and see
what's really going on. It's unlikely that anybody will
actually lie to you. However, they may be telling you what they think
is going on, or what they wish was going on, or what they know is
supposed to be going on, instead of reporting the actual state of
affairs.
anagers who are used to dealing with computers that have been
secured may believe that computers are automatically secure; the
shipped configuration will be reasonably safe if it is connected to a
network. This is not true. In fact, the truth is almost the exact
opposite. The default configuration that machines are shipped with is
usually laughably insecure, and it requires considerable expertise to
arrive at a secure configuration. Therefore, a manager who says that
all of the computers are perfectly secure may be completely
incorrect, without having the least intention of deceiving you.
If you ask questions that have clear "right" answers,
most people will tend to try to give you those answers. Other people
will become defensive. Try to ask neutral questions that don't
have a clear bias. For example, don't ask people if they think
security is important; instead, ask which is more important to them,
security or a cooperative work environment, and then get them to
expand on that answer.
When you talk to people, make it extremely clear why you're
asking. Asking about security policies tends to give people the
impression that you're trying to check up on them. Some people
will try to get a good grade, rather than discussing reality. Others
will become hostile (after all, why should you be checking up on
them?). If you get either of these reactions, stop asking questions
about security policies (there's no point in it if
they're not going to give useful answers) and go back to trying
to explain what you're doing and why. If they never believe
you, ask somebody else.
25.2.3. External Factors That Influence Security Policies
Your site isn't
completely independent. Issues outside of a computer facility
influence security policy. These include legal requirements,
contractual obligations, and existing organizational policies.
Let's look first at legal issues. In the United States, a
publicly traded company has a legal responsibility to its
shareholders to protect its assets. This means that if you work for
such a company, even if everybody at the company agrees that you
ought to remove all of the passwords and let the Internet in, you
can't choose that as a security policy. Your security policy
must show evidence that you are safeguarding the company's
computers and information. What's required is "due
diligence", an attempt in good faith to take normal
precautions. "Normal precautions" limit what you need to
do; you don't have a legal responsibility to require retinal
scans before people can touch the computers!
Regardless of the type of institution you work for, in most places in
the United States, there is also a legal responsibility to safeguard
certain types of information about employees. Employee reviews are
generally legally protected, and so are straightforward personnel
records of information like home addresses. Universities have legal
responsibilities to safeguard student records, right down to the
information about which students attend the university. Data about
individuals has even more legal protection in some European
countries. If you do not work for Human Resources or Student Records,
you may think you don't have to worry about protecting this
kind of information, but you're probably wrong. Every manager
or supervisor usually has confidential employee data to deal with;
similarly, the information used to maintain accounts at universities
contains confidential student data (e.g., whether or not the student
is enrolled, and what classes the student is taking).
Your organization may also have contractual obligations to protect
data. If you have customer or client data on your systems, your
contracts probably require you to protect it. (This may apply to
research contracts at universities as well.) If you have source code
or prerelease software, you almost certainly have a license that
requires you to protect it.
Your organization may also have existing policies that influence
security policies. These are often policies about the protection of
data (usually written to meet the many and varied legal obligations
discussed previously), but there may be policies requiring that
people have access to data, especially at universities and public
institutions.
If your organization has a legal department, consult it. Don't
ask the people in the legal department to write a policy; just ask
them to explain the institution's legal obligations or to join
the team that writes the policy. If your organization does not have a
legal department, consult a senior manager. In any case, find any
existing written policies and wade through them to see what they say
that's relevant to security. Going through these written
policies will also give you a good idea for what works and
doesn't work in a written policy. If you like the existing
policies, base your new ones on them. If you hate the existing
policies, resist the temptation to make your new ones like them just
because they're the way they've always been written
before.
any people resist determining their legal responsibilities out of a
hope that they won't have to actually meet them if they
don't know what they are. You may have an uneasy feeling that
it's probably not legal to keep employee reviews on an
unprotected machine, but you don't want to have to deal with
it. You may also suspect that the law is going to require you to do
something insanely difficult. The bad news is that ignorance of the
law is no excuse, and you simply must find out what the legal
responsibilities are and make a good-faith effort to meet them. (It
is inadvisable to find out what they are and then spend all your time
trying to figure out how to avoid them. It will not protect you from
legal problems, and it will annoy the judge.) The good news is that
it is actually quite rare for the law to require you to do anything
incredibly difficult. If your lawyer says it does, check out other
legal opinions and other institutions' practices.
| | |
25. Security Policies | | 25.3. Getting Strategic and Policy Decisions Made |