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.