The Best Damn Firewall Book Period

Before even trying to decide how to write your firewall rules, you need to establish a security policy. A security policy does not have to be very complicated (however, due to the nature of organizations, they tend to be complicated and political). However, a security policy should define this: who has access to which network resources.

A firewall is an enforcement of your security policy. Your security policy should be designed to prevent intentional internal security breaches, as well as making it something supportive of your system administrators and your users.

Preventing Intentional Internal Security Breaches

According to most computer security studies, as documented in RFC 2196, actual loss (in terms of money, productivity, computer reputation, and other tangible and intangible harm) is greater for internal security breaches than for those from the outside. Internal attackers are more dangerous for several reasons:

• They generally know more about the company, the network, the layout of the building(s), normal operating procedure, and other information that will make it easier for them to gain access without detection.

• They usually have at least some degree of legitimate access and might find it easy to discover passwords and holes in the current security system.

• They know what information is on the network and what actions will cause the most damage.

To a large extent, unintended breaches can be prevented through education. This obviously will not have the same effect on network users who intend to breach security as it has on "innocent" employees. The best way to prevent such breaches depends, in part, on the motivations of the employee(s) concerned.

Tactical Planning

In dealing with network intruders, you should practice what police officers in defensive tactics training call if/then thinking. This means considering every possible outcome of a given situation and then asking yourself, "If this happens, then what could be done to protect us from the consequences?" The answers to these questions will form the basis of your security policy.

This tactic requires that you be able to plan your responses in detail, which means that you must think in specifics rather than generalities. Your security threat must be based in part on understanding the motivations of those initiating the attack and in part on the technical aspects of the type of attack that is initiated. In the next section, we discuss common intruder motivations and specific types of network attacks.

Designating Responsibility for Network Security

In any undertaking as complex as the development and implementation of a comprehensive corporate security plan and accompanying policies, it is vital that areas of responsibility be clearly designated.

Best practices dictate that no one person should have complete authority or control. Besides, in an enterprise-level network, it would be difficult for any single person to handle all facets of developing and implementing the security plan.

Responsibility for Developing the Security Plan and Policies

The initial creation of a good security plan requires a great deal of thought and effort. The policy will impact employees at all levels of the organization, and you should soliciting input from as many representatives of different departments and job descriptions as is practical. An effective approach is to form a committee consisting of people from several areas of the organization to be involved in creating and reviewing the security plan and policies.

Your security planning committee might include some or all of the following:

• The network administrator and one or more assistant administrators

• The site's security administrator

• Heads of various company departments or their representatives

• Representatives of user groups that will be impacted by the security policies (for example, the secretarial staff, the data processing center, etc.)

• A member of the legal department who specializes in computer and technology law

• A member of the finance or budget department

Responsibility for Implementing and Enforcing the Security Plan and Policies

Security policies are generally implemented and enforced by network administrators and members of the IT staff. Job descriptions and policies should designate exactly who is responsible for the implementation of which parts of the plan. A clear-cut chain of command should specify whose decision prevails in case of conflict.

In some cases—such as physical penetration of the network—the company security staff will become involved. There should be written, clearly formulated policies that stipulate which department has responsibility for particular tasks in such situations.

The security plan should also address the procedures for reporting security breaches, both internally and if the police or other outside agencies are to be brought in (as well as who is responsible for or has the authority to call in outside agents).

One of the most important factors in a good security policy is that it must be enforceable. If the policy can be enforced through security tools, this method is preferred. If the policies must be enforced through reprimand or other actions against employees who violate them, there should be clearly worded, universally distributed written documentation indicating what constitutes a violation and the sanctions that will result, as well as who is responsible for imposing such sanctions.

Designing the Corporate Security Policy

The process of designing a good corporate network security policy will differ from organization to organization. However, common elements should be addressed, including (but not limited to) the following:

• Developing an effective password and authentication policy

• Developing a privacy policy that sets forth reasonable expectations of privacy as to employees' e-mail, monitoring access to Web sites, access to users' directories and files, and so forth

• Developing an accountability policy that defines responsibility in regard to security issues, including policies regarding users' obligation to report security violations and the process for doing so

• A network use statement that defines users' responsibilities in regard to accessing network resources, protecting password confidentiality, reporting problems, and expectations as to availability of network resources

• A disaster protection and recovery policy that specifies policies for fault tolerance, scheduling data backups and storing backed-up data, fail-over plans for critical systems, and other related matters

It is beyond the scope of this chapter to provide detailed examples of all these elements. We do, however, address the first issue: how to go about developing an effective password policy and some of the factors that should be considered. The other policy areas should be addressed in similar depth and detail in your plan. Also refer to Chapter 13 for an additional discussion of security policies that encompass some of these other elements.

Developing an Effective Password Policy

In the networking world, passwords (in combination with user account names) are normally the "keys to the kingdom" that provide access to network resources and data. It might seem simplistic to say that your comprehensive security plan should include an effective password policy, but it is a basic component that is more difficult to implement than it might appear at first glance.

In order to be effective, your password policy must require users to select passwords that are difficult to "crack" yet easy for them to remember so that they don't commit the common security breach of writing the password on a sticky note that will end up stuck to the monitor or sitting prominently in the top desk drawer.

A good password policy is the first line of defense in protecting your network from intruders. Careless password practices (choosing common passwords such as "god" or "love" or the user's spouse's name; choosing short, all-alpha, one-case passwords, writing passwords down or sending them across the network in plain text) are like leaving your car doors unlocked with the keys in the ignition. Although some intruders might target a specific system, many others simply "browse" for a network that's easy to break into. Lack of a good password policy is an open invitation them.

Best practices for password creation require that you address the following:

• Password length and complexity

• Who creates the password?

• Forced changing of passwords

Password Length and Complexity

It's easy to define a "bad" password: It's one that can be easily guessed by someone other than the authorized user.

One way in which "crackers" (hackers who specialize in defeating passwords to break into systems) do their work is called the brute force attack. In this kind of attack, the cracker manually or, more often, using a script or specially written software program, simply tries every possible combination of characters until he or she finally hits on the right one. These programs can utilize huge dictionaries that contain many thousands of words and character combinations. Using this method, it is easier to guess a short password than a longer one because there are more possible combinations. For this reason, most security experts recommend that passwords have a minimum required length (for example, eight characters). Modern network operating systems such as Windows 2000 allow domain administrators to impose such rules so that if a user attempts to set a password that doesn't meet the minimum length requirement, the password change will be rejected.

Physical security is critical in thwarting brute force attacks, since they are more likely to succeed when the hacker has physical access to the machine than when they are launched across the network.

Who Creates the Password?

Network administrators might be tempted to institute a policy whereby they create all passwords and "issue" them to users. This method has the advantage of ensuring that all passwords meet the administrator's criteria in regard to length and complexity. However, it has a few big disadvantages as well:

• It places a heavy burden on administrators, who must handle all password changes and be responsible for letting users know what their passwords are. Of course, you would not want to notify the user of his or her password via e-mail or other insecure channels. In fact, the best way is to personally deliver the password information. In a large organization, this becomes particularly taxing if you have a policy requiring that passwords be changed on a regular basis (as you should; we discuss this rule in the next section).

• Users have more difficulty remembering passwords that they didn't choose themselves. This means that they are more likely to write the passwords down, resulting in security compromises. Otherwise, users might have to contact the administrator frequently to be reminded of their passwords.

• If the administrator creates all passwords, the administrator knows everyone's password. This might or might not be acceptable under your overall security policy. Some users (including management) could be uncomfortable with the idea that the administrator knows their passwords. Even though an administrator can generally access a user's account and/or files without knowing the password anyway, that fact is less obvious to users and thus of less concern.

Allowing users to create their own passwords within set parameters (length and complexity requirements) is usually the best option. The user is less likely to forget the password because he or she can create a complex password that is meaningless to anyone but the user.

For example, it would be difficult for others to guess the password "Mft2doSmis." It has 10 characters, combines alpha and numeric characters, and combines upper and lower case in a seemingly random manner. To the user, it would be easy to remember because it means "My favorite thing to do on Sunday morning is sleep."

Password Change Policy

Best practices dictate that users change their passwords at regular intervals and after any suspected security breach. Windows 2000 allows the administrator to set a maximum password age, forcing users to change their passwords at the end of the specified period (in days). Password expiration periods can be set from 1 to 999 days. The default is 42 days.

Because it is the nature of most users to make their passwords as easy to remember as possible, you must institute policies to prevent the following practices, all of which can present security risks:

• Changing the password to a variation of the same password (for example, changing from Tag2mB to Tag3mB)

• Changing the password back and forth between two favored passwords each time a change is required (that is, changing from Tag2mB to VERoh9 and back again continuously)

• "Changing" the password to the same password (entering the same password for the new password as what was already being used)

Administrators can use operating system features to prevent these practices. For example, in Windows 2000, you can configure the operating system to remember the user's password history so that up to a maximum of the last 24 passwords will be recorded. This way, the user will not be able to change the password to one that has been used during that time.

Summary of Best Password Practices

Keep these best practices in mind:

• Passwords should have a minimum of eight characters.

• Passwords should not be "dictionary" words.

• Passwords should consist of a mixture of alpha, numeric, and symbol characters.

• Passwords should be created by their users.

• Passwords should be easy for users to remember.

• Passwords should never be written down.

• Passwords should be changed on a regular basis.

• Passwords should be changed any time compromise is suspected.

• Password change policies should prevent users from making only slight changes.

Designing a Comprehensive Security Plan

Now that you have some understanding of basic security concepts and terminology, general security objectives, common motivation of network intruders, various types of specific attacks and how they are used, and an overview of available hardware and software solutions, you can begin to design a comprehensive security policy for your organization.

A widely accepted method for developing your network security plan is laid out in RFC 2196, Site Security Handbook, and attributed to Fites, et al (1989). It consists of the following steps:

• Identify what you are trying to protect.

• Determine what you are trying to protect it from.

• Determine how likely the anticipated threats are.

• Implement measures that will protect your assets in a cost-effective manner.

• Review the process continually and make improvements each time a weakness is discovered.

  Note

  The entire text of RFC 2196, which provides many excellent suggestions that focus primarily on the implementation phase, can be found on the Web at www.faqs.org/rfcs/rfc2196.html.

It is important to understand that a security plan is not the same thing as a security policy, although the two words are sometimes used interchangeably. Your security policies (and there are likely to be many of them) grow out of your security plan. Think of policy as "law" or "rules," whereas the security plan is procedural; it lays out how the rules will be implemented.

Your security plan will generally address three different aspects of protecting your network:

• Prevention The measures that are implemented to keep your information from being modified, destroyed, or compromised.

• Detection The measures that are implemented to recognize when a security breach has occurred or has been attempted, and if possible, the origin of the breach.

• Reaction The measures that are implemented to recover from a security breach, to recover lost or altered data, to restore system or network operations, and to prevent future occurrences.

These can be divided into two types of actions: proactive and reactive. The first, prevention, is proactive because it takes place before any breach has occurred and involves actions that will, if successful, make further actions unnecessary. Unfortunately, our proactive measures don't always work. Reactive measures such as detection and reaction do, however, help us develop additional proactive measures that will prevent future intrusions.

Regardless of how good your prevention and detection methods, it is essential that you have in place a reaction plan in case attackers do get through your line of defense and damage your data or disrupt your network operations. As the old saying goes, "Hope for the best, and plan for the worst."

Evaluating Security Needs

Before you can develop a security plan and policies for your organization, you must assess the security needs, which will generally be based on the following broad considerations:

• Type of business in which the organization engages

• Type of data that is stored on the network

• Type of connection(s) of the network to other networks

• Philosophy of the organization's management

Each of these factors will play a part in determining the level of security that is desirable or necessary for your network.

Assessing the Type of Business

Certain fields have inherently high security requirements. An obvious example is the military or other government agencies that deal with defense or national security issues. Private companies with government defense contracts also fall into this category. Others might be less obvious:

• Law firms, bound by law and ethics to protect client confidentiality

• Medical offices, which must protect patient records and confidentiality

• Law enforcement agencies, courts, and other governmental bodies

• Educational institutions that have student records stored on their networks

• Any company that gathers information from individuals or organizations under guarantee that the data will be kept confidential

The competitive nature of a business is also a consideration. In a field such as biogenetic research, which is a "hot" market in which new developments—any of which could involve huge profits for the company that patents the idea—occur on a daily basis, protecting trade secrets becomes vitally important.

Most businesses have some data of a confidential nature on the network's computer systems, but the security requirements in some fields are much higher than in others. The confidentiality needs of the business should be considered as you begin to develop your security plan.

Assessing the Type of Data

The second question to consider involves the type of data stored on your network and where it is stored. You could find that a higher level of security is needed in one department or division than another. You might, in fact, want to divide the network physically, into separate subnets, to allow better control of access to various parts of the company network independently.

Generally, payroll and human resource records (personnel files, insurance claim documents, and the like), company financial records (accounting documents, financial statements, tax documents), and a variety of other common business records need to be protected. Even in cases in which these documents must be made public, you will want to take steps to ensure that they can't be modified or destroyed. Remember that data integrity as well as data confidentiality are protected by a good security plan.

Assessing the Network Connections

Your business's exposure to outside intruders is another consideration in planning how security will be implemented on your network. A LAN that is self-contained and has no Internet connectivity nor any modems or other outside connections does not require the degree of protection (other than physical security) that is necessary when an intruder can take many avenues "in."

Dial-up modem connections merit special consideration. A dial-up connection is less open to intrusion than a full-time dedicated connection—both because it is connected to the outside for a shorter time period, reducing the window of opportunity for intrusion, and because it usually has a dynamic IP address, making it harder for an intruder to locate it on multiple occasions—allowing workstations on your network to have modems and phone lines can create a huge security risk.

If improperly configured, a computer with a dial-up connection to the Internet that is also cabled to the internal network can act as a router, allowing outside intruders to access not only the workstation connected to the modem but other computers on the LAN as well.

One reason for allowing modems at individual workstations is to allow users to dial up connections to other private networks. A more secure way to do this is to remove the modems and have the users establish a VPN connection with the other private network through the LAN's Internet connection.

The best security policy is to have as few connections from the internal network to the outside as possible and control access at those entry points (collectively called the network perimeter).

Assessing Management Philosophy

This last criterion is the most subjective but can have a tremendous influence on the security level that is appropriate for your organization. Most companies are based on one (or a combination of more than one) management model.

Understanding Management Models

Some companies institute a highly structured, formal management style. Employees are expected to respect a strict chain of command, and information is generally disseminated on a "need to know" basis. Governmental agencies, especially those that are law enforcement-related such as police departments and investigative agencies, often follow this philosophy. This model is sometimes referred to as the paramilitary model.

Other companies, particularly those in the IT industry and other fields that are subject to little state regulation, are built on the opposite premise: that all employees should have as much information and input as possible, that managers should function as "team leaders" rather than authoritarian supervisors, and that restrictions on employee actions should be imposed only when necessary for the efficiency and productivity of the organization. This is sometimes called the one big happy family model. Creativity is valued more than "going by the book," and job satisfaction is considered an important aspect of enhancing employee performance and productivity.

In business management circles, these two diametrically opposed models are called Theory X (traditional paramilitary style) and Theory Y (the modern, team-oriented approach). Although numerous other management models such as management by objective (MBO) and total quality management (TQM) have been popularized in recent years, each company's management style falls somewhere on the continuum between Theory X and Theory Y. The management model is based on the personal philosophies of the company's top decision makers regarding the relationship between management and employees.

An organization's management model can have a profound influence on what is or isn't acceptable in planning security for the network. A "deny all access" security policy that is viewed as appropriate in a Theory X organization could meet with so much resentment and employee dissatisfaction in a Theory Y company that it disrupts business operations. Always consider the company "atmosphere" as part of your security planning. If you have good reasons to implement strict security in a Theory Y atmosphere, realize that you will probably have to justify the restrictions to management and "sell" them to employees, whereas those same restrictions might be accepted without question in a more traditional organization.

Understanding Security Ratings

Security ratings could be of interest as you develop your company's security policy, although they are not likely to be important unless your organization works under government contract, requiring a specified level of security.

The U.S. government provides specifications for rating network security implementations in a publication often referred to as the Orange Book, formally called the Department of Defense Trusted Computer System Evaluation Criteria, or TCSEC. The Red Book, or Trusted Network Interpretation of the TCSEC (TNI), explains how the TCSEC evaluation criteria are applied to computer networks.

Other countries have security rating systems that work in a similar way. For example:

• CTPEC (Canada)

• AISEP (Australia)

• ITSEC (Western Europe)

To obtain a government contract in the United States, companies are often required to obtain a C2 rating. A C2 rating has several requirements:

• That the operating system in use be capable of tracking access to data, including both who accessed it and when it was accessed (as is done by the auditing function of Windows NT/2000)

• That users' access to objects be subject to control (access permissions)

• That users be uniquely identified on the system (via user account names and passwords)

• That security-related events be traceable and permanently recorded for auditing (audit log)

In order to receive certification, a company must implement these requirements in particular ways. If your organization needs C2 rating for its systems, you should consult the National Computer Security Center (NCSC) publications to ensure that they meet all the requirements.

Legal Considerations

Another important step in preparing to design your network security plan is to consider legal aspects that could affect your network. It is a good idea to have a member of your company's legal department who specializes in computer law be involved in the development of your security plan and policies. If this is not possible, the written policies should be submitted for legal review before you put them into practice.

Addressing Security Objectives

If your security goal is to have complete control over the data that comes into and goes out of your networks, you must define objectives that will help you reach that goal. We listed some general security objectives related to computer networks—especially those connected to an outside internetwork such as the Internet—as controlling physical access, preventing accidental compromise of data, detecting and preventing intentional internal security breaches, and detecting and preventing unauthorized external intrusions. In the following sections, we examine each of these objectives in detail.

Know Your Users

To prevent accidental compromise of data, you should first know your users and their skill levels. Those with few technical skills should be given as little access as possible; allow them the access required to do their jobs, and no more. Too many network users have, in all innocence, destroyed or changed important files while attempting to clear space on their hard disks or troubleshoot a computer problem on their own.

Control Your Users

In some cases, establishing clear-cut policies and making staffers and other users aware of them will be enough. In other cases, you will find that users are unable or unwilling to follow the rules, and you will have to take steps to enforce them—including locking down desktops with system or group policies and implementing access rules and filtering to prevent unauthorized packets from being sent or received over the network.

Luckily, most users will at least attempt to comply with the rules. A more serious problem is the "insider" who is looking to intentionally breach network security. This person could be simply a maverick employee who doesn't like being told what to do, or he or she could be someone with a darker motive.

Hiring and Human Resource Policies

In many cases, prevention starts with good human resources practices. That means that management should institute hiring policies aimed at recruiting people of good character. Background investigations should be conducted, especially for key positions that will have greater than usual user network access.

The work environment should encourage high employee morale; in many cases, internal security breaches are committed as "revenge" by employees who feel underpaid, under-appreciated, or even mistreated. Employees who are enthusiastic about their jobs and feel valued by the organization will be much more likely to comply with company rules in general and network security policies in particular.

Another motivation for internal breaches is money. If your company engages in a highly competitive business, competitors could approach employees with lucrative offers for trade secrets or other confidential data. If you are in a field that is vulnerable to corporate espionage, your security policies should lean toward the deny all access model, in which access for a particular network user starts at nothing and access is added on the basis of the user's need to know.