|
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 RisksIt 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:
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.
Communicate Your FindingsWhen 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.
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 NeededIf 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 ComplianceIf 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 CultureEvery 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:
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 CultureWritten 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 PolicyThe 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. DirectivesSenior 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 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 RulingsLegal 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 PolicyIf 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 PolicyYou 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. AuthorityWe 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. ScopeThe 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. ExpirationSome 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 PolicyAnything 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 ClaritySpecificity 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. ConcisenessRules 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. RealismPerhaps 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. |
|