Up to this point, this document has provided a basic vocabulary of threats and risks associated with the Internet, how Internet firewalls can be used to address those problems, and some examples of firewall implementations. This chapter provides basic guidance on designing a network service policy and choosing a firewall design policy, and then discusses next steps in obtaining a firewall. It closes with a discussion of issues involved in maintaining a firewall and other steps for improving overall network security. The discussion is brief and serves only to raise issues;

Firewall Policy

Policy was discussed in in terms of a service access policy and a firewall design policy. This section discusses these policies in relationship to overall site policy, and offers guidance on how to identify needs, risks, and then policies.

Policy decisions regarding the use of firewall technology should be made in conjunction with the policy decisions needed to secure the whole site. This includes decisions concerning host systems security, dial-in access, off-site Internet access, protection of information off-site, data communications security and others. A stand-alone policy concerning only the firewall is not effective; it needs to be incorporated into a strong site security policy. Refer to [RFC1244] for information on creating a site security policy geared towards the needs of Internet sites.

Steps in Creating a Service Access Policy

A firewall is a direct implementation of the network service access and design policies, as discussed in section . There are a number of service access policies that may be implemented, such as no inbound access and full outbound access or restricted inbound access and restricted outbound access. The firewall design policy determines to a large degree the service access policy: the more robust the firewall design policy, the more stringent the service access policy. Thus, the firewall design policy needs to be decided upon first.

As explained in section , the firewall design policy is generally to deny all services except those that are explicitly permitted or to permit all services except those that are explicitly denied. The former is more secure and is therefore preferred, but it is also more stringent and causes fewer services to be permitted by the service access policy.

Chapter 3 provided several firewall examples, and showed that certain firewalls can implement either design policy whereas one, the dual-homed gateway, is inherently a ``deny all'' firewall. However, the examples also showed that systems needing certain services that shouldn't be passed through the firewalls could be located on screened subnets separate from other site systems. The point here is that depending on security and flexibility requirements, certain types of firewalls are more appropriate than others. This shows also the importance of choosing a policy first before implementing the firewall; doing the opposite could result in a clumsy fit.

To arrive at a firewall design policy and then ultimately a firewall system that implements the policy, NIST recommends that the firewall design policy start with the most secure, i.e., deny all services except those that are explicitly permitted. The policy designer then should understand and document the following:

• which Internet services the organization plans to use, e.g., TELNET, Mosaic, and NFS,
• where the services will be used, e.g., on a local basis, across the Internet, dial-in from home, or from remote organizations,
• additional needs, such as encryption or dial-in support,
• what are the risks associated with providing these services and access,
• what is the cost in terms of controls and impact on network usability to provide protection, and
• assumptions about security versus usability: does security win out if a particular service is too risky or too expensive to secure.

The creation of these items is straightforward, however at the same time highly iterative. For example, a site may wish to use NFS across two remote sites, however the ``deny all'' design policy may not permit NFS (as explained in sec. ). If the risks associated with NFS are acceptable to the organization, it may require changing the design policy to the less secure approach of permitting all services except those specifically denied and passing NFS through the firewall to site systems. Or, it may require obtaining a firewall that can locate the systems that require NFS on a screened subnet, thus preserving the ``deny all'' design policy for the rest of the site systems. Or, the risks of using NFS may prove too great; NFS would have to be dropped from the list of services to use remotely. The aim of this exercise, then, is to arrive at a service access policy and the firewall design policy.

To assist in this process, the following sections present some common issues that need to be addressed in the policies associated with firewall use.

Flexibility in Policy

Any security policy that deals with Internet access, Internet services, and network access in general, should be flexible. This flexibility must exist for two reasons: the Internet itself is in flux, and the organization's needs may change as the Internet offers new services and methods for doing business. New protocols and services are emerging on the Internet, which offers more benefits to organizations using the Internet, but may also result in new security concerns. Thus, a policy needs to be able to reflect and incorporate these new concerns. The other reason for the flexibility is that the risk of the organization also does not remain static. The change in risk may be a reflection of major changes such as new responsibilities being assigned to the organization, or smaller changes such as a network configuration change.

Remote User Advanced Authentication Policy

Remote users are those who originate connections to site system from elsewhere on the Internet. These connections could come from any location on the Internet, from dial-in lines, or from authorized users on travel or working from home. Regardless, all such connections should use the advanced authentication service of the firewall to access systems at the site. Policy should reflect that remote users may not access systems through unauthorized modems placed behind the firewall. There must be no exceptions to this policy, as it may take only one captured password or one uncontrolled modem line to enable a backdoor around the firewall.

Such a policy has its drawbacks: increased user training for using advanced authentication measures, increased expense if remote users must be supplied with authentication tokens or smartcards, and increased overhead in administering remote access. But, it does not make sense to install a firewall and at the same time not control remote access.

Dial-in/out Policy

A useful feature for authorized users is to have remote access to the systems when these users are not on site. A dial-in capability allows them to access systems from locations where Internet access is not available. However as discussed in section , dial-in capabilities add another avenue for intruder access.

Authorized users may also wish to have a dial-out capability to access those systems that cannot be reached through the Internet. These users need to recognize the vulnerabilities they may be creating if they are careless with modem access. A dial-out capability may easily become a dial-in capability if proper precautions are not taken.

The dial-in and dial-out capabilities should be considered in the design of the firewall and incorporated into it. Forcing outside users to go through the advanced authentication of the firewall should be strongly reflected in policy. Policy can also prohibit the use of unauthorized modems attached to host systems and personal computers at the site if the modem capability is offered through the firewall. A strong policy and effective modem service may limit the number of unauthorized modems throughout the site, thus limiting this dangerous vulnerability as well.

Remote Network Connections

In addition to dial-in/dial-out connections, the use of Serial Line IP (SLIP) and Point-to-Point Protocol (PPP) connections need to be considered as part of the policy. Users could use SLIP or PPP to create new network connections into a site protected by a firewall. Such a connection is potentially a backdoor around the firewall, and may be an even larger backdoor than a simple dial-in connection.

Section provided several examples for locating dial-in capability such that dial-in connections would pass first through the firewall. This sort of arrangement could be used as well for SLIP and PPP connections, however this would need to be set forth in policy. As usual, the policy would have to be very strong with regard to these connections.

Information Server Policy

A site that is providing public access to an information server must incorporate this access into the firewall design. While the information server itself creates specific security concerns, the information server should not become a vulnerability to the security of the protected site. Policy should reflect the philosophy that the security of the site will not be compromised in order to provide an information service.

One can make a useful distinction that information server traffic, i.e., the traffic concerned with retrieving information from an organization's information server, is fundamentally different from other ``conduct of business'' traffic such as e-mail (or other information server traffic for the purposes of business research). The two types of traffic have their own risks and do not necessarily need to be mixed with each other.

Section discusses incorporating an information server into the firewall design. The screened subnet and dual-homed gateway firewall examples show information servers that can be located on a screened subnet and in effect be isolated from other site systems. This reduces the chance that an information server could be compromised and then used to attack site systems.

Procuring a Firewall

After policy has been decided, there are a number of issues to be considered in procuring a firewall. Many of these issues are the same as for procuring other software systems, thus familiar steps such as requirements definition, analysis, and design specification are standard. The following sections describe some additional considerations, including minimal criteria for a firewall and whether to build or purchase a firewall.

What Should a Firewall Contain?

Once the decision is made to use firewall technology to implement an organization's security policy, the next step is to procure a firewall that provides the appropriate level of protection and is cost-effective. However, what features should a firewall have, at a minimum, to provide effective protection? One cannot answer this question entirely with specifics, but it is possible to recommend that, in general, a firewall have the following features or attributes:

• The firewall should be able to support a ``deny all services except those specifically permitted'' design policy, even if that is not the policy used.
• The firewall should support your security policy, not impose one.
• The firewall should be flexible; it should be able to accommodate new services and needs if the security policy of the organization changes.
• The firewall should contain advanced authentication measures or should contain the hooks for installing advanced authentication measures.
• The firewall should employ filtering techniques to permit or deny services to specified host systems as needed.
• The IP filtering language should be flexible, user-friendly to program, and should filter on as many attributes as possible, including source and destination IP address, protocol type, source and destination TCP/UDP port, and inbound and outbound interface.
• The firewall should use proxy services for services such as FTP and TELNET, so that advanced authentication measures can be employed and centralized at the firewall. If services such as NNTP, X, http, or gopher are required, the firewall should contain the corresponding proxy services.
• The firewall should contain the ability to centralize SMTP access, to reduce direct SMTP connections between site and remote systems. This results in centralized handling of site e-mail.
• The firewall should accomodate public access to the site, such that public information servers can be protected by the firewall but can be segregated from site systems that do not require the public access.
• The firewall should contain the ability to concentrate and filter dial-in access.
• The firewall should contain mechanisms for logging traffic and suspicious activity, and should contain mechanisms for log reduction so that logs are readable and understandable.
• If the firewall requires an operating system such as UNIX, a secured version of the operating system should be part of the firewall, with other security tools as necessary to ensure firewall host integrity. The operating system should have all patches installed.
• The firewall should be developed in a manner that its strength and correctness is verifiable. It should be simple in design so that it can be understood and maintained.
• The firewall and any corresponding operating system should be updated with patches and other bug fixes in a timely manner.

There are undoubtably more issues and requirements, however many of them will be specific to each site's own needs. A thorough requirements definition and high-level risk assessment will identify most issues and requirements, however it should be emphasized that the Internet is a constantly changing network. New vulnerabilities can arise, and new services and enhancements to other services may represent potential difficulties for any firewall installation. Therefore, flexibility to adapt to changing needs is an important consideration.

To Buy or Build a Firewall

A number of organizations may have the capability to build a firewall for themselves, i.e., put together a firewall by using available software components and equipment or by writing a firewall from scratch. At the same time, there are a number of vendors offering a wide spectrum of services in firewall technology. Service can be as limited as providing the necessary hardware and software only, or as broad as providing services to develop security policy, risk assessments, security reviews and security training.

Whether one buys or builds a firewall it must be reiterated that one should first develop a policy and related requirements before proceeding. If an organization is having difficulty developing a policy, it may need to contact a vendor who can assist in this process.

If an organization has the in-house expertise to build a firewall, it may prove more cost-effective to do so. One of the advantages of building a firewall is that in-house personnel understand the specifics of the design and use of the firewall. This knowledge may not exist in-house with a vendor supported firewall.

At the same time, an in-house firewall can be expensive in terms of time required to build and document the firewall, and the time required for maintaining the firewall and adding features to it as required. These costs are sometimes not considered; organizations sometimes make the mistake of counting only the costs for the equipment. If a true accounting is made for all costs associated with building a firewall, it could prove more economical to purchase a vendor firewall.

In deciding whether to purchase or build a firewall, answers to the following questions may help an organization gauge whether it has the resources to build and operate a successful firewall:

• how will the firewall be tested; who will verify that the firewall performs as expected,
• who will perform general maintenance of the firewall, such as backups and repairs,
• who will install updates to the firewall, such as for new proxy servers, new patches, and other enhancements,
• can security-related patches and problems be corrected in a timely manner, and
• who will perform user support and training.

Many vendors offer maintenance services along with firewall installation, therefore the organization should consider whether it has the internal resources to perform the above.

Administration Issues with Firewalls

It should not be surprising that firewall administration is a critical job role and should be afforded as much time as possible. In small organizations, it may require less than a full-time position, however it should take precedence over other duties. The cost of a firewall should include the cost of administering the firewall; administration should never be shortchanged.

System Management Expertise

As evidenced by previous discussions concerning the many host system break-ins occurring throughout the Internet, the need for highly trained, quality, full-time host system administrators is clearly shown. But, there is also indication that this need is not being met; many sites do not manage systems such that the systems are secure and protected from intruder attacks. Many system managers are part-time at best and do not upgrade systems with patches and bug fixes as available.

Firewall management expertise is a highly critical job role, as a firewall can only be as effective as its administration. If the firewall is not maintained properly, it may become insecure, and may permit break-ins while providing an illusion that the site is still secure. A site's security policy should clearly reflect the importance of strong firewall administration. Management should demonstrate its commitment to this importance in terms of full-time personnel, proper funding for procurement and maintenance and other necessary resources.

Site System Administration

A firewall is not an excuse to pay less attention to site system administration. It is in fact the opposite: if a firewall is penetrated, a poorly administered site could be wide-open to intrusions and resultant damage. A firewall in no way reduces the need for highly skilled system administration.

At the same time, a firewall can permit a site to be ``proactive'' in its system administration as opposed to reactive. Because the firewall provides a barrier, sites can spend more time on system administration duties and less time reacting to incidents and damage control. It is recommended that sites

• standardize operating system versions and software to make installation of patches and security fixes more manageable,

• institute a program for efficient, site-wide installation of patches and new software,

• use services to assist in centralizing system administration, if this will result in better administration and better security,

• perform periodic scans and checks of host systems to detect common vulnerabilities and errors in configuration, and

• ensure that a communications pathway exists between system administrators and firewall/site security administrators to alert the site about new security problems, alerts, patches, and other security-related information.

Incident Handling Contacts

An important consideration under firewall and site system administration is incident handling assistance and contacts. NIST recommends that organizations develop incident handling capabilities that can deal with suspicious activity and intrusions, and that can keep an organization up to date with computer security threat and vulnerability information. Because of the changing nature of Internet threats and risks, it is important that those maintaining firewalls be part of the incident handling process. Firewall administrators need to be aware of new vulnerabilities in products they are using, or if intruder activity is on-going and can be detected using prescribed techniques. [Cur92], [Garf92], and [RFC1244], contain information on developing incident response teams and contacts. NIST has produced a publication specifically on creating incident response capabilities [NIST91b].

See Appendix A for more information on incident response team contacts and the Forum of Incident Response and Security Teams (FIRST).