Developing a Site-Wide Security Policy

A security policy is the critical first step toward securing your organization's network. It lays the overall foundation of how your organization approaches security issues. It explains what resources are important, who is responsible for those resources, and the general guidelines on how your organization will protect those resources. It does not go into detail about how this policy is enforced, which is often decided by the security administrators.

Firewalls are a technical tool used to enforce the security policy. A firewall is not the only tool that can be used to enforce a security policy, but it plays a major role in many organizations. With a clearly defined policy, you will know precisely who will maintain your firewalls and what kinds of changes will be allowed. Without a policy, it is not clear what the purpose of the firewall is, nor is it clear what kinds of changes to the policy are allowed. As a result, different people will enforce different rules, which may often conflict with one another. What was enforced one day may be changed the next . Rules might be randomly added and dropped with no real, coherent plan. The outcome would be an effective tool configured ineffectively.

The sort of security policy discussed in this section has nothing to do with FireWall-1, at least not yet. A security policy is a written document that should be simple to read and states what resources should be secured and under what conditions access will be provided or denied . It does not provide details on what needs to be done to secure the organization.

Senior Management Buy-In

Regardless of how you attack this problem, unless the senior managers in your organization approve of and support the implementation of a security policy, all attempts at implementing and enforcing the security policy will likely be futile. Discuss the issue with your senior managers. Get them to allocate the necessary resources to craft the security policy, which includes representatives from each functional area within the organization. Involving actual end users is also important because the results of those policies will be most visible to them.

The What, Who, and How

Once you have support from senior management, the next challenge is creating a simple document that everyone can use. Too often, extensive security policies are created, which cover every conceivable situation. These documents become so large and cumbersome that no one has time to either read or understand them. By keeping the document short and simple, you will have a usable document that can be understood by all.

As stated earlier, there are three general areas you want to include in your security policy: what is important, who is responsible for it, and guidelines on how to protect it. You should first identify the assets you need to protect, the value of which often determines what steps are reasonable and prudent to protect them. For most companies, specific types of information have to be protected from unauthorized access. Often, people protect servers, systems, and/or users. Although this is often necessary in the course of protecting the data, keep in mind that the primary goal is to protect the information. When the information moves from one system to another, you may have to update your security policy on the firewall or other devices to ensure that data remains protected.

The second area of security policies is ownership, namely, who is responsible for what. Ownership and responsibility should begin at the upper management levels of your organization and work down from there. It is critical that all parts of your organization have someone who is held accountable for that area. For example, most organizations have someone in charge of financial affairs, marketing, sales, and customer service. This is just as true for network security. The security policy needs to define someone responsible for both the administration of the firewall and the approval of the policy the firewall is intended to enforce. The individual rules configured into your firewall can have a major impact on your organization. Someone in your organization should be responsible for approving all requests for the rulebase to be changed. In organizations where this administrator is not defined, one person may add a rule, and then another person might remove the same rule. If there is only one person (or group of persons) responsible for approving rulebase changes, you can avoid these problems.

The security policy should not name specific individuals but instead name positions. Individuals come and go. If John Doe is responsible for the firewalls, as defined by the security policy, what happens when John Doe leaves the company or moves to a new position? All positions should be defined by a title, such as Chief Security Officer (CSO) or Firewall Administrator. The positions themselves should be clearly defined in this policy as well.

Finally, the security policy should cover basic guidelines on how to secure its assets, which may include the types of devices necessary to perform this function. For example, a policy document might state that a firewall should be used to mediate access between the organization's network and the Internet. This is reasonable. The document might also state that the firewall should support certain features or carry a particular certification, such as Common Criteria EAL4, FIPS 140-1 level 2, ITSEC E3, or ICSA. However, the document should not state that Check Point FireWall-1 should be used. Why? Technology changes too rapidly to be detailed in a security policy. The security policy should provide only guidelines or basic standards as to what will be implemented. The technical details of implementing the security policy should be left to those who must implement it (i.e., the security team).

To give another example, your organization's security policy could state that all Internet access to the company's intranet Web server must be securely authenticated using a token-based, one-time password scheme. This is what is required. How this is enforced should be left to the security team. For this book, the how could be enforced by Check Point FireWall-1. The firewall would intercept any HTTP requests to the intranet Web server and require authentication first. This could be done through the use of the HTTP Security Server tied into a SecurID-based authentication system. Mentioning either FireWall-1 or SecurID by name in the security policy document would be inappropriate because those are references to specific products.

It is your security policy that guides your firewall implementation and maintenance. A firewall is just part of the technical implementation of that security policy. If you and your organization do not understand your security policy, you will not be able to properly implement and maintain your firewall, not to mention other items that make up the security infrastructure in your organization.

Implementing Firewalls without a Written Security Policy

Your organization may not have a security policy or, if a security policy does exist, it may be poorly documented or understood. The problem then is that the firewall must be implemented and maintained , but without much guidance on what it is supposed to enforce. Normally in these situations, a firewall is quickly constructed , and rules are added as needed. No prior planning is done. If you find yourself or your organization in this situation, there are steps you can take to prevent problems.

The best solution is to create a security policy as soon as possible. If this cannot be done, you can take some short- term measures. First, be careful. If you are responsible for maintaining the firewall, including implementing the firewall rules, you could be held responsible if something happens. Even if you were told by someone from a different department to create a new rule (e.g., the marketing department requested access to its internal Web server from the Internet), you could be liable for a security breach.

In order for network security to be properly implemented, you must educate the managers and get them to buy into the process. This may mean spending some time with members of upper management explaining to them the importance of network security. Without support from upper management, all attempts to implement proper network security are doomed to fail. It is highly recommended that someone in upper management (perhaps your boss) be responsible for security. Ask him or her to identify someone to approve the firewall rules and make sure that person has adequate authority with which to do this. Organizations that already have a clear security policy will have already defined these policies and procedures. Unfortunately, if your organization does not have a security policy, or the security policy does not cover firewalls, you will have to do much of this yourself.

Once you have identified areas of responsibility and procedures for approving and maintaining the firewall, your life will become a lot less stressful, with less liability falling on your shoulders.

An Example of a Security Policy

Instead of reviewing an entire security policy, I present a portion of a security policy here. It is designed to give you an idea of how a security policy document might look. Keep in mind that no two security policies are alike. Every organization's policy document has its own unique format and issues. This example not only gives you a better idea of how a security policy can look but also provides specific examples of what to look for in relation to firewalls. As covered earlier, a security policy should be general in nature, covering who is responsible for what. The particular section shown here describes the management and procedures for implementing and maintaining Company X's firewalls. A sample Acceptable Usage Policy can be found in Appendix B of this book.

Company X Information Security Policy

Section 010: Firewall Implementation and Management

SUMMARY

Firewalls are a critical security asset used to protect Company X's information resources. It is critical that all firewalls be configured, implemented, and maintained in a standardized and secure fashion. In response to the risks, this document describes Company X's official policy regarding firewall implementation and management.

I. CONFIGURATION AND IMPLEMENTATION

A. Operating System: Before a firewall can be installed on an operating system, that operating system must be fully secured and tested in accordance with the Chief Security Officer. See Company X Operating System Standards document for more information.

B. Responsibility: Before implementation, an administrator must be identified as responsible for the firewall. This administrator is fully responsible for maintaining both the firewall software and the underlying operating system. The administrator may select up to two other individuals to assist in maintaining the firewall. However, these individuals must be approved by the Chief Security Officer.

C. Access: Only the administrator and approved assistant(s) may access the firewall or operating system. Thus, there can be no more than three accounts for the firewall and operating system. Only the firewall administrators may have administrative access to the operating system and firewall software.

D. Default Rule: All of Company X's firewalls are based on this premise : That which is not expressly permitted is denied.

II. MAINTENANCE

A. Logs: The firewall administrator is responsible for ensuring the daily review and archiving of firewall logs.

B. Rules: Only the firewall administrator is authorized to make any changes in the firewall rulebase. All requests must be forwarded to the firewall administrator and be approved by the Chief Security Officer prior to the enactment of any changes.

This section of the sample security policy covers the policies and procedures of maintaining the organization's firewalls. It is highly recommended because it helps define who is responsible for what. Notice that specific names are not used, only positions. This ensures that as people change positions, the security policy does not have to be continually updated. In addition, this section states the overall policy for firewall rulebases , specifically : That which is not expressly permitted is denied. The firewall can enforce this policy by denying all traffic. The rulebase is then modified to allow only that which is expressly permitted.

Other samples can be found at The SANS Institute (http://www.sans.org). This organization maintains several sample security policy documents that cover a wide variety of situations and are based on common best practices. You can use them as templates to craft your own document. SANS also provides links to other locations that provide sample security policies.