Appendix A - Requirements vs. Firewall Designs

During the creation and analysis of different potential designs each was systematically assessed with respect to criteria and requirements established at the beginning of the process. The requirements were refined and enhanced during this process. This Appendix summarizes our evaluation of the designs vs. the requirements. The specific results are available on the Task Force website:

http://fwtf.berkeley.edu/Design-vs-Requirement-TABLE.htm

http://fwtf.berkeley.edu/Designs-Requirements-Writeup.htm

Requirements

The Firewall Task Force evaluated the set of firewall design options using the following requirements. These requirements represent the key issues for departments, campus networking and overall campus security.

Departments

Provides robust security for department hosts on the campus network.

Aids compliance to guidelines mandates, laws, etc., of outside agencies governing department's projects or data.

Enforces comprehensive departmental security policy.

Preserves or enhances departmental business continuity and system resilience. A concern is that a firewall can be a single point of failure and that it can effect business communication in unintended ways. In general, the greater the number of hosts behind the firewall, the greater the risk that failure or incorrect operation of the firewall would adversely affect business continuity.

Campus Security Requirements

Any firewall deployed on campus should advance SNS's goals for establishing network security for the campus as a whole, and not make this responsibility more difficult by creating a false sense of security. That the firewall not be installed as a "set it and forget it" device, resulting in an under managed firewall and/or inadequate host security. Even with a firewall standard host security procedures shall be followed: application of security patches, monitoring of system and security logs, system and application access controls, and installation of host-based intrusion detection software as appropriate.

Firewall configurations will need to provide SNS secure access to the departmental network for the purpose of proactive scanning. The purpose of these scans is to detect vulnerabilities within a host or server. On one hand, if a firewall protects a vulnerable system then it has done its job. On the other hand, by blocking a proactive scan the system's administrator may never learn that the system is vulnerable.

The firewall should not increase the risk of "perusal of contents" as referred to in the Electronic Communications Policy, (http://www.ucop.edu/ucophome/policies/ec/html/). To evaluate this risk the Firewall Task Force evaluated who will have access to the traffic that a firewall monitors, are they professional firewall or system administrators familiar with the policy and privacy issues, how many people will have access to the firewall's monitored data, and how much data, or data from how many systems is being monitored by the firewall.

Network Management, Operations

A firewall cannot interfere with the normal operation of the non-secure network. Among other things, this means, a CNS-managed router cannot exchange route information with any device that is operated by another group.

Firewalls must allow network management traffic from CNS polling systems or control networks to CNS managed network devices. Maintenance and operation of CNS-managed network devices requires the following protocols: ICMP, SNMP, telnet, TFTP, FTP, BOOTP/DHCP, IPSEC and SSH. (This list of protocols may change.) If CNS-managed devices are behind a firewall, the firewall rule-set must be configured to permit this traffic.

In addition, network engineers diagnosing a problem will likely connect test equipment or laptops to the network and may sniff packets in order to trouble-shoot the problem.

Other

Lastly implementation and management of the firewall must be relatively easy and effective from both technical and organizational culture perspectives. Technical issues include the relative ease or complexity of configuration and operation of the firewall. Cultural issues include how affected users, owners of data, web page administrators, etc., will be affected by the intended and unintended operation of the firewall.

Designs vs. Requirements

Border Design

A Border firewall design scores low on nearly all requirements. It will not provide good security to departments because it will not protect them from hosts on campus. On the other hand by its very placement at the border it can have grave consequences for off-campus connectivity thereby disrupting business continuity. For those requirements that it does score high (not interfering with campus routing, network management, or proactive scanning) has more to do with its singularity at the campus border than anything useful about this design.

In general, the Border design would not work well on this campus. Most significantly it is unlikely to provide robust security to any department. There are over 40,000 hosts on this campus and as the number of hosts "inside" a firewall increase its effectiveness decreases -- the security perimeter is simply too large. In addition, the campus has multiple, very high speed border connections. There is no single location to place a border firewall, nor is it likely that a firewall appliance could support our traffic speeds and the necessary number of policy rules.

Secure Pen

The Secure Pen provides great protection but only for a small number of critical servers.  It provides robust security and meets the requirements of outside agencies for the hosts it protects; but it is not a comprehensive solution from either the department or campus perspective. Unless mitigated by high performance, redundant firewalls this design can pose a business continuity risk to the servers it protects.

Because it is a single site it unlikely to affect normal network operations, and while it would affect network management the impact would be small.

The effect on proactive scanning is low since the scans could be coordinated with the group operating the secure pen. And because the Secure Pen would be operated by a relatively small group, the chance of inappropriate access to firewall data is also low.

The effect on cultural practicality, the measure of impact on users, is good again because the firewall protects a small number of servers. On the other hand, system administration and software installation may be impacted simply because a critical server is housed outside its department, hence a relatively low mark for technical practicality.

Nevertheless there is already a need on campus for a highly secure facility for the campus's most sensitive servers. And in fact the facility exists. The Task Force recommends that a service be developed and made available to departments who wish to house their servers in this facility.

Entire Subnet - All Support Methods

All of the Entire Subnet models score above average for robust security since there are a moderate number of hosts behind the firewall (and the greater the number of hosts behind a firewall the less effective it is), and they are comprehensive solutions for the whole department. They also score high as this design is usually what outside agencies require. Conversely, they score just above average on business continuity because the firewall can be a single point of failure.

Entire Subnet - Full Support

Entire Subnet - Full Support does not adversely affect network operations because, while the firewalls are topologically in the middle of a department's subnet, both models include a central support service providing 24x7 response, consistent expertise and assistance during problem diagnosis.

Entire Subnet - Full Support provides good overall campus security because the design could scale to every department that desired a firewall while providing consistent, robust firewall management and operations. And SNS can easily coordinate with the FSS to conduct scans behind the firewalls. The FSS would provide better access control to the firewall and the data it monitors.

Entire Subnet - Full Support scores high on technical practicality because the presence of an FSS to provide operational support eases the technical implementation and management issues; but low on cultural practicality because departments would be dependent upon an outside unit to for firewall configuration and management. And also for the firewall to be effective the department users would have to agree on fairly restrictive firewall policy, such as "deny all, permit only what is truly needed."

Entire Subnet - Mixed Support

Network operations and management, trouble-shooting procedures and problem resolution will be severely impacted in this design because every firewall would be administered by a different department.

Overall campus security is more problematic because inconsistent firewall management will reduce overall effectiveness of this design. This would only work effectively for departments who had well trained security experts. For those departments this model enhances campus security. However, there is a high probability that some departments would choose a model like this to save money. It is precisely those departments that this model would be least effective for. This, again, raises the danger of a poorly administered firewall creating a false sense of security. If it is combined with inadequate system administration resources the net result is a reduction in overall campus security.

Proactive scanning would be more difficult for SNS because they have to coordinate with dozens of people in dozens of departments. It is very likely that many departments will not understand SNS's needs or how to best accommodate them. Entire Subnet - Mixed Support did not meet the requirement of least perusal. The privacy issues associated with access to sensitive data are at the core of what the campus networking and security groups do on a daily basis. It is not clear how to ensure that these concerns are effectively incorporated by other units.

From a technical perspective the design is only average; it does not impact implementation but would adversely effect network management. From a cultural practicality perspective this design is only average; the department system administrators would have control over the rule-sets pertaining to the department's hosts. However department users would still have to accept a potentially restrictive security policy.

Entire Subnet - Shared Support

Network operations and network management are not adversely affected by this design. While the firewall is topologically in the middle of a department's subnet, the design includes a central support service providing 24x7 response, consistent expertise and assistance during problem diagnosis. The same group would have developed standards to allow the necessary protocols to CNS managed devices. In fact, CNS could be just another department with a particular allowable view into the firewall configuration; to view and modify rule-sets applying to CNS managed devices.

SNS believes the shared management opportunities provided to departments could reduce overall effective management of the firewall. And there is a slight possibility that a department (or someone who does not understand security issues) could do something inappropriate and reduce the effectiveness of their firewall.

Proactive scanning will be easily possible in this design because in this case SNS can easily coordinate with the FSS to do scans behind firewalls. But the requirement of lease perusal is not sufficiently met. There is the possibility the many more people would have access to the firewall data. Some of those people might not understand what they can and cannot do with that data.

The presence of a FSS enhances technical practicality because it can ease the technical implementation and management issues. From a cultural perspective the design does only moderately well because the department system administrators would have control over the rule-sets pertaining to the department's hosts. However department users would still have to accept a potentially restrictive security policy.

Entire Subnet - No Support, AKA "Private Network"

Normal network operations may be adversely affected because private networks can cause operational issues when interacting with the supported network and CNS may have difficulty contacting administrators of the private network and has no visibility into the private network. On the other hand, because CNS does not manage the network devices within this design, it has no adverse effect on network management.

As for overall campus security it does poorly because there is no central organization involved in the management of the firewall or the network. This would only work for departments who had well trained security experts. There is a high probability that some departments would choose a model like this to save money. It's precisely those departments that this model would be least effective for.

With regards to proactive scanning, this model has problems similar to the Entire Subnet - Department Support model. But, with this model, not only could there be problems with the firewall, but the network itself could make it difficult for SNS to evaluate it's vulnerability. Similarly the requirement for least perusal is not met, or is at risk. In addition to giving possibly untrained people access to sensitive firewall data, they now have access to even more sensitive network monitoring capabilities.

From a technical perspective this design does poorly because the department is left to manage both the firewall and the network. It does do moderately well from a cultural practicality perspective because the department would have full control of the firewall and network. They would not be constrained by a central group's limitations on rule sets, etc.

Multi-subnet with Routing Firewall

This design does not provide good security because there are a great number of hosts behind the firewall. Despite its poor security it may be acceptable to outside agencies because this design is often what they mandate. And at first look it seems like a comprehensive solution but contains many of the same weaknesses of a border firewall design. The firewall's rule set will either be very weak, i.e. allow many protocols or block only the lowest common denominator, or be a complicated to manage. And while the risk can be mitigated by redundant firewalls, business continuity is at stake because so many systems could be cut off from the network if the firewall failed.

Normal network operations are at risk because the design requires routing. Network management would be nearly impossible (in fact, one can assume that this design is only usable if the network and the firewall are managed by the network, i.e., that this is deployed as a private network.)

This design only moderately enhances overall campus security. It is covers a great many hosts but is likely to be weak security for the same reason. Proactive scanning would be very difficult to coordinate. The requirement of least perusal is not met because the firewall administrator in this design would have the ability to monitor many users communication.

From a technical perspective this design does poorly because it requires the added complexities of routing and maintaining a more complex firewall configuration. As for cultural practicality the design affects many users. In addition firewall rule sets may be too restrictive to meet the needs of all the users behind the firewall.

Hidden VLAN

If deployed to protect all the connections within a set of switches then the security perimeter is much larger; and because the design depends on the switch configuration it is not the most robust design. For the same reason it may not meet the requirements of outside agencies. However, it can be used to provide moderate protection to all the hosts within a subnet provided the department has modern network infrastructure.

Business continuity may be adversely affected by the complexity of the configuration. While the switch configuration is non-standard the design is optimal for network operation and management. There are no CNS managed devices behind the firewall. CNS supported connections can easily be moved to the non-secure portion of the subnet in order to complete problem diagnosis. The firewall is not topologically between devices that CNS manages and network management facilities. Also, an individual connection can be moved from the secure side of the firewall to the public side easily; allowing CNS to remove the firewall from the equation while diagnosing that host's connection.

The firewall is managed by departments, which is advantageous to departments from an administration and control perspective. This may lead to inconsistent firewall management throughout the campus as a whole, however. Therefore the design is rated slightly above average in enhancing overall campus security.

Proactive scanning is adversely effected by the firewall. If the departmental firewall administrators have not coordinated with SNS, proactive scanning cannot be used to evaluate vulnerabilities in the department's hosts. The least perusal requirement is not met as there could be potentially many system administrators and part-time system administrators who would have the ability to monitor network data for their labs, offices, etc.

From a technical perspective the Hidden VLAN design would be relatively easy to implement but have some configuration complexity. And from a cultural practicality perspective the application of a security policy could be on a relatively small number of hosts, affecting a relatively small number of users.

Host Cluster

Host Cluster designs provide robust security for the hosts they protect and can meet requirements of outside agencies provided that the outside agency is only concerned with security for the hosts behind the Host Cluster firewall, and not all the hosts within a department. For the same reason Host Cluster designs do not provide comprehensive security for an entire department.

Host Cluster does well with business continuity because the firewall would only be a single point of failure between the host cluster and the rest of the network. Clearly this risk depends on which hosts are protected by the Host Cluster firewall and whether their traffic patterns are normally within the cluster or not.

The design does not adversely affect normal network operations because there are no CNS managed devices behind the firewall in these models. CNS is able to support the network up to the wall jack as though there were no firewall.

This design enhances overall campus security by being good, relatively easy security for departmental servers. SNS may not be able to scan the hosts in the cluster. But the rest of the network can still be scanned.

Host Cluster does not do well for the least perusal requirement because there is a possibility of many system administrators and part-time administrators having the ability to view and monitor network data.

From a technical perspective the Host Cluster design would be relatively easy to implement but have some configuration complexity. And from a cultural practicality perspective the application of a security policy would be on a relatively small number of hosts, affecting a relatively small number of users.

Personal Firewalls

Personal firewall software can provide robust security for the hosts where it is installed but is not a good comprehensive solution because configuration and use of the firewall software would not necessarily be consistent across all the hosts within a department. Individual users might re-configure, misconfigure or disable the firewall software. Nor does the solution do well with outside agencies because they usually mandate a separate physical firewall device.

Personal firewalls do well for business continuity since failure of the firewall is only as bad as failure of the protected host itself.

Personal firewalls do not affect normal network operations because there are no CNS managed devices behind the firewall in these models. CNS is able to support the network up to the wall jack as though there were no firewall. And network management is unaffected because the host's connection can be easily tested and diagnosed.

Personal firewalls can greatly enhance overall campus security. They should be promoted regardless of whatever other firewall models are recommended. Personal firewalls have the potential to protect nearly every campus computer. Further, they tend to increase awareness of security issues and help individuals to take more responsibility for the security of their computers.

While personal firewalls can block proactive scans, it is the same result as if the host did not respond to the scan, i.e., was not vulnerable. The host with a personal firewall can still be scanned to find unprotected or open ports and services.

Because the only perusal of network data is by the user who presumably already has access to the data, personal firewalls do well by the least perusal requirement.

Personal firewalls however are difficult from a technical practicality perspective because without some sort of auto-update function or central administration tools it will be very difficult for system administrators to administer large number of personal firewall configurations. They are however, very practical for individual users. And they do well with cultural practicality because firewall rules could be tailored for each individual--those who need access to applications could allow it themselves.

Table of Contents

Glossary