How to Develop Policy

Earlier, we pointed out the risks of trying to develop firewall rules without policy. The tendency is to do this willy-nilly, adding a rule here, modifying a rule there, until the rule set becomes difficult to maintain. Because we are in the active policy-enforcement business, sooner or later there will be controversy about why a certain service is either granted access or controlled. If the firewall administrator has a signed, approved, up-to-date policy to refer to, it can stifle the controversy. We need to have a policy on which to base our access and control decisions. Policy development can be approached in several ways, but in information security, we are probably best off to use a risk-based approach. For this to work, we identify the risk, communicate what we have learned to an authority, update or create security policy, and figure out how to measure compliance.

Identify Risks

It is time for a walkabout. Try not to let this stress you, but you will need to get out of your cubicle and go talk to some people. We realize that computer security types are a fairly introverted bunch, but users are a significant source of risk. Determine how your organization uses computers and networks in the conduct of business, both routinely and under emergency circumstances. You need to ask two questions:

• What data do you have or do you use from a different source that would really hurt the organization if it were not available?

• Do you use the Internet for anything other than email? (Of course, if your organization doesn't have a presumption of privacy, you can pull the logs and know what answer to expect before you meet.) Keep in mind that if no policy exists, the users in your organization aren't doing anything wrong. Make sure they understand you are simply trying to establish a baseline, not cause anyone trouble.

These questions will provide insight into the risks that your organization faces. Odds are, this will not be pretty. Just because you are using a personal firewall and keeping your antivirus software up to date doesn't mean anyone else is. You might find that people download games and other untested software, and that they run chat programs capable of transferring files. You might even find a copy of a web server on a workstation if you look long enough. The next step will be to pass your findings on the areas of risk to management, the folks who are paid to approve or mitigate business risk.

Where Is It Written?

For many years, I believed that people were rational, and that any two reasonable persons could be expected to make the same decision in a given situation. That isn't so. Really intelligent people will ask questions like, "If we have a firewall, why should we have to patch our systems?" We all know the perimeter cannot guarantee that a system will be 100% protected 100% of the time. But when people get a notion like that in their heads, logic ceases to be the drug of choice. You can try to explain things to them and they just don't get it. What is phenomenal, though, is the power of the written word. Someone might ask, "What instruction requires that we do it that way (or at all)?" If you show a written and dated policy signed by upper management, a surprising number of times the person nods and accepts the policy.

Communicate Your Findings

When communicating what you have learned to management, keep it simple, balanced, and fairly concise. If you mention an individual's name with respect to a problem or risk you have discovered at any point, management is likely to think of this as a personal attack and dismiss everything you have done. Keep the general tone on the types of problems you found and the implications. When possible, give an example of where this type of behavior was financially damaging to the organization.

SirCam as an Awareness Tool

I worked with a group that was pretty lax about antivirus, and nothing I said seemed to get them to understand the risks of malicious code. After SirCam hit in July 2001, I was at a restaurant with the group's senior manager. We were discussing a business deal, and I told him about a law firm that was hit by SirCam over the weekend. When the firm came in that Monday, the phones were lit up because sensitive documents of all sorts had been blasted over the Internet. It was fun to watch his face as he suddenly got it. The group added email screening to its firewall, and began updating workstation antivirus signatures regularly. SirCam created awareness of how malicious code could expose sensitive information in unexpected ways.

Offer management a range of options for managing those risks. It's probably best to use two different antivirus tools on the mail gateway, but if management decides to make the investment in only one, that is their choice. Our job is to give management the data in such a way they can make a reasonable decision. Don't try to do this by discussion only. Make sure you leave a written summary of your findings as well.

Create or Update the Security Policy as Needed

If no written policy is in place, write it and get it signed by upper-level management. Later in this chapter, we will cover the elements of policy and give you a few more tips for creating policy. However, life is too short to write policy from the ground up if you can avoid it. You don't write a makefile from scratch every time you build a new software distribution, do you? You usually modify an existing makefile. Many policy references are on the SANS web server (http://www.sans.org/resources/policies/), and an Internet search should turn up plenty of additional resources. We went through a lot of trouble to build the case for avoidance of unenforceable policy. One way to prevent unenforceable policy is to build in methods that allow us to audit compliance.

Determine Policy Compliance

If you cannot measure compliance (conformance), the policy is unenforceable. If the policy is specific enough, it should be easy to determine whether any item you are testing is in compliance. For instance, if we are only allowed to play Star Trek two days a year, it is possible to audit the system for the presence of that software. If trading sound files is against policy, we can monitor logs for the default ports of tools such as Kazaa clients, but also use Snort or a similar tool to look for the .mp3 file extension. One warning: If your plan is to spot check, make sure someone spot checks to see whether the spot checks actually happen. The spot checks should be logged and should occur quarterly. Audit the spot check log. Again, if there are no metrics and no controls to ensure compliance, it is probably unenforceable policy. If security supposedly spot checks for disk media at secure installations and it really isn't happening, the security function will not detect violations of their policy. A word of warning, though: Most people will choose compromise over confrontation. Management might have the best of intentions. They might say all the right words, but make sure you do not run afoul of your corporate culture, or your policy experience might be a very unpleasant one.

Sound Out the Organization's Rules and Culture

Every organization has a particular style, an ethic or image. Many times, a senior manager maintains this style and the organization buys into it to some extent. Does the organization favor managers over technical people? Does it favor seniority over excellent performance? Do the rules apply to everyone or only to some people? Is the organization laid back or aggressive? If you are writing policy, make sure it reflects the culture; otherwise, it is certainly going to be unenforceable.

We like to ask a few questions to determine the security posture of the organization before looking at policy. Some of those questions include the following:

• What is the presumption of privacy, including phone and network monitoring? Do employees have a reasonable expectation that what they store on their computers, what they say on the phone, and what they send on the Internet are protected communications?

• Are random physical searches permitted, and is there an active search program?

• Is the perimeter configured to allow all connections that are initiated from inside the organization?

• Are employees able to add software or modify settings on their desktop systems?

• Are administrators able to make changes without going through a formal configuration management approval program?

The answers to these questions can really help you see the "tone" you would expect the policy to have. Then you can continue to do an assessment of the culture by reading existing written policy and writing down unwritten policy.

Comparing Policy and Culture

Written policy can be found in a number of ways. It includes official policy, of course, but also directives from senior management, contracts, and other legal agreements, and even existing Human Resources cases. It can be an interesting experience to compare the official policy that is listed in documents with the other sources of policy we have described. The wise analyst examines the alternate sources and the cases of enforced policy to be alert for indications that the corporate culture does not completely agree with its stated policy. In a sense, this is just like Windows Active Directory: You have the Group Policy and the Local Security Policy, and they might not totally agree. If you want your Windows system to be secure, you need to be aware of what the effective policy is at all times. This is the same principle at work when we consider official policy and corporate culture.

Note

Policy must be documented and consistently enforced. Humans have trouble with this, but perimeter devices do not. This is why it is imperative to consider the human side of the equation before engaging the perimeter.

Written Policy

The first place to start looking for your corporate culture is the Human Resources handbook that is given to every new employee. At some point, this document was almost certainly approved by senior management as the document they wanted new employees to see. Be sure to check that the same management team that approved the employee handbook is still in power. Also, directives and other standard policy information might be available. It can't hurt to check those, being sensitive to when they were created. Checking these sources gives you an idea of what some combination of policy writers and management thought they wanted the policy to be.

Directives

Senior management will have approved the primary policy documents of their organization, but they might have modified them afterward by issuing directives. Generally, an executive secretary or administrative officer serves as the organizational memory. Clearly, this person would not be comfortable sharing all email or directives with you, but you are only interested in directives that modify either access or control. Even informal emails from senior management can have a large effect on a corporate climate.

How do you ensure that the administrative officer takes this exercise seriously? We suggest a checklist that lists the proposed perimeter policy based to the extent possible on the written policy. This should be in English, not in a firewall rules language. This checklist can be done with bullets, as in the following example:

• All internal systems are maintained according to the organization's best-practice checklist.

• All connections that are implemented from the inside are considered trusted.

• Acme Corporation, a strategic partner, has implemented a direct connection to us and is not blocked or monitored for the following services: file transfer, access to our product's database, and email.

Then you provide a place on the checklist for the administrative officer: "I have reviewed senior management directives, and the following directives and instructions indicate the proposed policy might need to be modified. If none, so state." This way, if the CEO or president of the company is offended by the perimeter's active policy enforcement, you have a layer of protection, a firewall between the angry manager and yourself.

Contracts and Human Resources Rulings

Legal contracts can effectively modify corporate policy, as can the hiring and firing disciplinary rulings from Human Resources. Many policies have a references section, and if you are aware of documents that modify the policy, you can include these in references as you update.

Unwritten Policy

If you immediately jumped to the conclusion, "No, policy has to be written," then we would ask you to consider the following:

• We have always done it that way!

• We have tried that five times and it always just dies.

• I wouldn't go there if I were you.

Every organization has hidden rules. Crossing these rules usually doesn't cause employment termination, but you can waste a lot of time. Every organization has wise folks who have been around for a long time, and these are the folks with whom to chat. Don't ask them to sign your checklist, but ask where the minefields are. You can always raise points with the senior manager who approves the implementation of the perimeter policy. Senior managers are paid to make the hard calls.

A chapter that is devoted to implementation of policy for perimeter devices cannot possibly cover all the elements of policythat would be a book all by itself. That said, we do want to make sure we discuss the most common elements.

Elements of Policy

You can think about the elements of policy as the outline or skeleton. When we learned to code, many of us were taught to build the main program and put in dummy function calls. The idea was to call the function and make sure we returned so that the flow of the program would work. This limits troubleshooting to one function at a time, so we would be able to build the program efficiently. The elements of policy serve the same purpose; you can think of them as function calls in a main program.

We are not going to provide an exhaustive list of the elements of policy. This policy is tailored to a perimeter situation, so it will not need everything that you find in more Human Resourcerelated policies. Keep in mind that we need to focus on access and control with the policy. We will discuss authority, scope, and expiration next. We will also cover the characteristics of good policy.

Authority

We need to consider levels of authority: the manager who is authorized to sign the paper, and the policy under which this policy might fall. Often, a higher-level ruling policy exists. For instance, a perimeter policy might reference the organization's information security policy, and that might reference the organization's security policy. If this is not policy at the highest level, then to whom does it apply? Everyone, or perhaps everyone in a particular department or group? This is why we need to explicitly define the scope of the policy.

Scope

The scope section of policy identifies the depth and breadth of coverage (to whom or what the policy applies). Is it for one element of the organization, or will it also apply to contractor agencies that work for your organization? It is worth paying careful attention to the scope. If the scope proves to be incorrect, you might end up having to support two firewall policies: one for group A and another for group B. Of course, things change, and the policy should be reevaluated periodically. This is the purpose of the expiration information.

Expiration

Some policy is only valid for a short period of time. If your organization merges with another, you might have a transitional policy for 3090 days. Policy is fairly static, with the exception of perimeter policy, which needs to be reviewed at least yearly. Taking the time to craft good policy makes it easier to check periodically.

Hallmarks of Good Policy

Anything worth doing is worth doing well, and that certainly applies to policy. Let's take a few minutes to define what good policy is and is not. It does not have to be wordy, use obscure words, or use acronyms. It does need to state the issue, state what is expected, and be a tool that can be used to measure compliance. To best accomplish this task, the policy should be specific, concise, and realistic.

Specificity and Clarity

Specificity is one of the most important aspects of good policy. One of the best ways to avoid unenforceable policy is to reduce ambiguity. Many times, people who write policy attempt to write in a formal tone that makes the policy hard to read. Just state the issue in plain, readable language. It is imperative to be specific about the following:

• What needs to be done Enough information should be available from the policy to create a checklist that is sufficient to ensure compliance.

• Why the policy exists and what the problem is designed to solve Rational people need to understand what the problem is to fully buy into the solution.

• Who is responsible for accomplishing the tasks listed on the policy This is particularly important if procedures are developed from the policy. It must be clear who is responsible for completing the procedures.

The policy should be reviewed for clarity to make sure the reader can understand it. One simple way to test for clarity is to have one of the individuals identified as being responsible determine whether he understands the responsibility. Ask this person to read the policy and describe in his own words what the policy requires to be done. One of the best ways to make a policy clear is to make it concise.

Conciseness

Rules of thumbs are dangerous, so this is meant to challenge you to say what you need to say in a reasonable length. A specific policy topic (such as antivirus signature updates) shouldn't exceed two pages. Many organizations limit them to one page.

Realism

Perhaps you have heard of the mnemonic SMART. It stands for Specific, Measurable, Achievable, Realistic, and Time-based, and it is a good basis for effective policy. SMART also illustrates the importance of a realistic policy. Security policy shouldn't require people to try to implement things that can't be implemented. The R for Realistic is such an important characteristic; if the policy is not realistic, it is unenforceable.