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
It is time for a walkabout. Try not to let this stress you, but you will need to get out of your
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
Communicate Your Findings
When communicating what you have learned to management, keep it simple, balanced, and fairly
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
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
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
Sound Out the Organization's Rules and Culture
Every organization has a particular style, an
We like to ask a few questions to determine the security
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
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.
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.
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:
Then you provide a place on the checklist for the administrative officer: "I have reviewed senior management directives, and the following directives and instructions
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.
If you immediately jumped to the conclusion, "No, policy has to be written," then we would ask you to consider the following:
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
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.
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
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.
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:
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.
Rules of thumbs are dangerous, so this is
Perhaps you have