Chapter 25. Security Policies
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.
Contents:Your Security Policy
Putting Together a Security Policy
Getting Strategic and Policy Decisions Made
What If You Can't Get a Security Policy?
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 establish 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.
ost 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 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.
25.1. Your Security Policyost 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, ask any system administrator 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.
Putting together a security policy undoubtedly is going to be a long, involved process, and it's the exact opposite of the types of tasks most technical people enjoy. If you like to program, you are 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. A great deal of lip service is paid to the notion that security should be absolute: you should have a site that nobody could ever break into; 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". 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.
ost 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:
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. If you don't do anything, that's bad; but if you write it down, and then you don't do it, that's worse. You've proved that you knew you were supposed to do it.
25.1.1. What Should a Security Policy Contain?First and foremost, a security policy is a way of communicating with users and managers. It should tell them what they need to know to make the decisions they need to make about security.
188.8.131.52. ExplanationsIt'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.
184.108.40.206. Everybody's responsibilitiesA 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).
220.127.116.11. Regular languageost 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 organizational 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 grammar, punctuation, and spelling.
Writing in legalese will not make a document more legally binding, particularly if it's not written by a lawyer. Lawyers write the way they do because they are trying to achieve very precise meanings. Using a legal-sounding term slightly wrong just confuses the situation; it might have its legal meaning, in which case your document very accurately says something you didn't mean, or it might have no meaning, in which case your document is no more accurate than it would be if you just wrote it in casual language.
18.104.22.168. Enforcement authorityWriting 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 the situation. 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:
22.214.171.124. Provision for exceptionsNo policy is perfect. You can't cover every possible future event, and the policy will be unreadable and unusable if you even try. Therefore, you need to specify what process will be used to make exceptions. Is there a person with that authority? Is it a committee? How is the reader going to make contact? How long is it going to take?
126.96.36.199. Provision for reviewsYou can't expect to set up a policy 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 6 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 update your policies on a regular basis.
188.8.131.52. Discussion of specific security issuesBecause 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:
25.1.2. What Should a Security Policy Not Contain?Some pieces of information don't belong in your site's security policy, as we discuss in this section.
184.108.40.206. Technical detailsThe 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 1-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:
OTP will be used for all incoming connections.
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.
220.127.116.11. Somebody else's problemsEvery 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.
18.104.22.168. Problems that aren't computer security problemsPeople displaying obscene pictures on their computer screens aren't a computer security problem; they're a human resources problem (and a legal problem, if somebody decides to sue for harassment). People playing computer games all day aren't a computer security problem, either; they're a management problem. These issues should be adequately covered by existing policies. If they aren't, you have problems far too large to try to handle with a computer security policy. If they are, trying to cover them again risks setting up a conflict between the two policies. Furthermore, computer security policies cover enough complex and emotional territory without adding yet more.
Copyright © 2002 O'Reilly & Associates. All rights reserved.