 |  |
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 |
