3. Policy as the Key
 

Although it is helpful to diagram various configurations of filters and gateways, it is imperative that we not lose sight of the broad definition of a firewall as an implementation of security policy, not the totality of security. A firewall is an approach to security; it helps implement a larger security policy that defines the services and access to be permitted [Wack, which is the basis for the rest of this section]. In other words, a firewall is both policy and the implementation of that policy in terms of network configuration, one or more host systems and routers, and other security measures such as advanced authentication in place of static passwords. There are two levels of network policy that directly influence the design, the installation and the use of a firewall system:

Network Service Access Policy: a higher-level, issue-specific policy which defines those services that will be allowed or explicitly denied from the restricted network, plus the way in which these services will be used, and the conditions for exceptions to this policy.

Firewall Design Policy: a lower-level policy which describes how the firewall will actually go about restricting the access and filtering the services as defined in the network service access policy.

Network Service Access Policy
While focusing on the restriction and use of internetwork services, the network service access policy should also include all other outside network access such as dial-in and SLIP/PPP connections. This is important because of the "belt-and-bulge" effect, where restrictions on one network service access can lead users to try others. For example, if restricting access to the Internet via a gateway prevents Web browsing, users are likely to create dial-up PPP connections in order to obtain this service. Since these are non-sanctioned, ad hoc connections, they are likely to be improperly secured while at the same time opening the network to attack.

Network service-access policy should be an extension of a strong site-security policy and an overall policy regarding the protection of information resources in the organization. This includes everything from document shredders to virus scanners, remote access to floppy disk tracking. At the highest level, the overall organizational policy might state a few broad principles. For example, the fictitious Megabank, Inc. might use the following as a starting point for its information security policy:

A. Information is vital to the economic well-being of Megabank.

B. Every cost-effective effort will be made to ensure the confidentiality, control, integrity, authenticity, availability and utility of Megabank information.

C. Protecting the confidentiality, control, integrity, authenticity, availability and utility of Megabank's information resources is a priority for all Megabank employees at all levels of the company.

D. All information processing facilities belonging to Megabank will be used only for authorized Megabank purposes.

Below this statement of principles come site-specific policies covering physical access to the property, general access to information systems, and specific access to services on those systems. The firewall's network service-access policy is formulated at this level.

For a firewall to be successful, the network service-access policy should be drafted before the firewall is implemented. The policy must be realistic and sound. A realistic policy is one that provides a balance between protecting the network from known risks while still providing users reasonable access to network resources. If a firewall system denies or restricts services, it usually requires the strength of the network service-access policy to prevent the firewall's access controls from being modified or circumvented on an ad hoc basis. Only a sound, management-backed policy can provide this defense against user resistance. Here are the two typical and contrasting network service-access policies that a firewall can implement:
· Allow no access to a site from the Internet, but allow access from the site to the Internet;

or,

· Allow some access from the Internet, but only to selected systems such as information servers and e-mail servers.

Firewalls often implement network service-access policies that allow some users access from the Internet to selected internal hosts, but this access would be granted only if necessary and only if it could be combined with advanced authentication. In a moment we will look at network security access policy in more detail.

Firewall Design Policy
The firewall design policy is specific to the firewall. It defines the rules used to implement the network service access policy. This policy must be designed in relation to, and with full awareness of, issues such as firewall capabilities and limitations, and the threats and vulnerabilities associated with TCP/IP. As mentioned above, firewalls generally implement one of two basic design policies:

· Permit any service unless it is expressly denied; or

· Deny any service unless it is expressly permitted.

Firewalls that implement the first policy (the permissive approach) allow all services to pass into the site by default, with the exception of those services that the service-access policy has identified as disallowed. Firewalls that implement the second policy (the restrictive approach) deny all services by default, but then pass those services that have been identified as allowed. This second, restrictive, policy follows the classic access model used in all areas of information security. The permissive first policy is less desirable, since it offers more avenues for getting around the firewall. For example, users could access new services currently not denied by the policy (or even addressed by the policy). For example, they could run denied services at non-standard TCP/UDP ports that are not specifically denied by the policy.

On the other hand, certain services, such as X Windows, FTP, Archie, and RPC are difficult to filter [Chap92], [Ches94]. For this reason, they may be better accommodated by a firewall that implements the permissive policy. Also, while the restrictive policy is stronger and safer, it is more difficult to implement and more restrictive for users; services such as those just mentioned may have to be blocked or heavily curtailed. This is where firewall design comes in. Certain firewalls can implement either design policy. One particular design, the dual-homed gateway, is inherently a "deny-all" restrictive firewall. But it is possible to locate systems which require services that should not be passed through the firewall on screened subnets, separated from other site systems. In other words, depending on security and flexibility requirements, certain types of firewall designs are more appropriate than others, making it extremely important that you consider policy before implementing the firewall. Failure to do so could result the firewall's failing to meet expectations.

Questions to Ask
To arrive at a firewall design policy and then ultimately a firewall system that implements the policy, we recommend that you start with the most secure firewall design policy; that is, deny all services except those that are explicitly permitted. The policy designer should then understand and document the following:

A. Which Internet services does the organization plan to use (for example, TELNET, Mosaic, and NFS)?

B. Where will the services be used (for example, on a local basis, across the Internet, dial-in from home, or from remote organizations)?

C. What additional needs, such as encryption or dial-in support, may be supported?

D. What risks are associated with providing these services and access?

E. What is the cost, in terms of controls and impact on network usability, of providing protection?

F. What assumptions are made about security versus usability (does security automatically win out if a particular service is too risky or too expensive to secure)?

Addressing these items is straightforward but highly iterative. For example, a site may wish to use NFS across two remote sites, but the restrictive design policy may not permit NFS. There are several possible responses:

· If the risks associated with NFS are acceptable, the organization may change the design policy to the less secure approach of permitting all services except those specifically denied and then pass NFS through the firewall to site systems.

· Alternatively, the site could obtain a firewall capable of locating the systems that require NFS on a screened subnet, thus preserving the restrictive design policy for the rest of the site systems. On the other hand, the risks of using NFS may be considered too great, so NFS would have to be dropped from the list of services to use remotely.