Proposed Network Security Recommendations on Direction and Strategy for Firewalls and Related Technology for UW-

Madison

Executive Summary

University of Wisconsin-Madison’s network provides the technical foundation for conduct of its academic, research and administrative missions. This network has largely been open to the internet over the years. In order to better protect UW-Madison assets and the privacy of the university community, a campus-wide network security strategy is now needed. This strategy should include a network-based security approach for packet filtering and related technologies, along with the needed standards and procedures. The approach taken needs to accommodate UW-Madison’s diverse needs while ensuring a more secure network which is both able to provide reliable secure service to the university while not posing a threat to other parts of the internet community.

As a part of the XXI Century Network project, a study was conducted to propose strategies and recommendations for improving network security for UW-Madison. The strategies and recommendations provided in this document are the result of this effort by DoIT and campus staff in August and September of 2003, with input from UW-Madison school, college, and department stakeholders. The methodology for this study included:

• reviewing input received from UW-Madison school, college, and department IT staff through open forums and other dialogues, such as electronic mailing lists,

• consultation with the CTIG (Campus Technology Interest Group), and with the TechPartners steering committee,

• reviewing what other CIC institutions are doing in the network security area, • reviewing what higher education peers are doing, • evaluating the August-September 2003 experience with perimeter level port blocking and packet

filtering, • assessing network security technologies currently in use at UW-Madison, • studying vendor technology products, • obtaining expert advice from DoIT staff, and • receiving advice from our technology partners.

The directions and recommendations in this document are organized around a framework that separates the UW-Madison campus into 3 zones: Zone 1 – Campus Perimeter, Zone 2 – Campus Network, and Zone 3 – Servers and Desktops. Additional recommendations are also included that are not associated with a particular zone.

Overall Strategy

The overall strategy for improving network security at UW-Madison includes safeguards from the campus perimeter to the desktop. The goals of these strategies include a phased approach, with both intermediate and long-term solutions. The strategies proposed include:

• Zone 1

o DoIT will continue traffic filtering

o DoIT will research, recommend and implement intrusion prevention technologies

o DoIT will formalize urgent response procedures to guide in providing response to campus during high-impact security incidents

• Zone 2

o DoIT will research, recommend, fund and implement firewalls at strategic network segments which will provide firewalling capabilities for campus

DoIT will seek out possible solutions that will allow for the collaborative operation of campus firewalls

o DoIT will create standards and guidelines for firewalls in this zone

o DoIT will research and implement intermediate campus firewalling solutions for those with more immediate needs. DoIT will assess needs and identify possible solutions including packet filtering on campus routers and dedicated firewall appliances

• Zone 3

o DoIT and campus staff will research and recommend host firewall software options as well as possible volume discount licensing

o DoIT and campus staff will continue to emphasize anti-virus and the patching of operating systems including research on possible automated patch management

o DoIT will continue campus scanning for vulnerable computers

Critical to the success of all these initiatives is the active input and engagement of campus IT staff and stakeholders. A first step will be review of this document with campus IT staff.

PROPOSED NETWORK SECURITY RECOMMENDATIONS ON DIRECTION AND STRATEGY FOR FIREWALLS AND RELATED TECHNOLOGY 1

EXECUTIVE SUMMARY 1

INTRODUCTION 4

METHODOLOGY 4

BACKGROUND 5 CURRENT STATE OF THE CAMPUS 5 CURRENT STATE OF HIGHER EDUCATION 5 CURRENT STATE OF THE CIC 5 FIREWALLS, FIREWALL ZONES AND STRATEGY AND RECOMMENDATIONS TO IMPROVE NETWORK SECURITY 6

APPENDIX A – CURRENT STATE OF THE CAMPUS 11 LISTS OF FIREWALLS IN PLACE 11 LISTS OF FIREWALLS DESIRED 11 EXPERIENCE OF AUG-SEPT PORT BLOCKING 11

APPENDIX B – CURRENT STATE OF THE CIC 13

Introduction

Recent years have seen four disturbing trends in network security. First, the frequency of indiscriminate attacks aimed at any machine connected to the Internet is increasing. Second, many attacks build on techniques developed in previous attacks. Third, the current "state of the art" in writing malicious code has allowed for the creation of attacks that can affect thousands of machines in a few minutes. Finally, the interval between the announcement of system vulnerability and its likely exploitation has dropped to a matter of a few days. Given the potential current rapid exploitation possibility, it is no longer effective to wait for a vulnerability to be revealed, and then patch for it. It is likely the vulnerability will be massively exploited while machines are still in process of being patched.

Since it is not possible for UW-Madison staff and students to successfully patch tens of thousands of machines attached to the UW network in a short amount of time, other methods are required to try and reduce the risk of the attack and mitigate the damage. The methods required depend on the type of attack. Anti-virus scanning, vulnerability scanning, intrusion detection, and security policy are all appropriate parts of a defense. In the period immediately following the discovery of an exploit, however, the usual most successful defense is through use of network level security techniques such as firewalls, router access control lists, etc. According to Jim Leinweber of the Wisconsin State Hygiene Lab, “The usual defensive trinity: windows update, host-based or network firewalls, and antivirus software will keep your hosts safe. Whether or not your networks remain usable depends on how patched your neighbors are.”

In order to improve the network security at UW-Madison, a project was launched in the Fall of 2003 to recommend network security measures, tools and techniques. The scope of this project included security issues that can be dealt with by network packet filtering and can be solved by use of routers and firewalls. Other important security practices such as password policies, antivirus software, email attachment scanning, vulnerability scanning and vulnerability patching are specifically excluded from this project. Initial team members putting the strategies and recommendations in this document included: Perry Brunelli, Scott Buckingham, Judy Caruso, LaVonne Frank, Rick Keir, Kim Milford, Hideko Mills, Paul Nazario, and Jeff Savoy. Additional members will be added as these strategies are reviewed and various implementation projects are initiated. This proposal is a result of the team’s efforts.

Methodology The recommendations in this document were formulated using the following methodology: • reviewing input received from UW-Madison school, college, and department IT staff through

open forums and other dialogues, such as electronic mailing lists, • consultation with the CTIG (Campus Technology Interest Group), and with the TechPartners

steering committee, • reviewing what other CIC institutions are doing in the network security area, • reviewing what higher education peers are doing, • evaluating the August-September 2003 experience with perimeter level port blocking and packet

filtering, • assessing network security technologies currently in use at UW-Madison,

• studying vendor technology products, • obtaining expert advice from DoIT staff, and • receiving advice from our technology partners. The recommendations presented in this document will be vetted with campus stakeholders and will be presented to the ITC on October 17. The goal is to ensure that the recommendations have "face validity", that is, recommendations that come to ITC have received prior review by a significant number of both DoIT and non-DoIT staff.

Background

Current State of the Campus As of the fall of 2003, several campus departments have installed and manage their own firewalls and historically DoIT has worked with campus on these deployments (see Appendix A). DoIT has also implemented packet filtering at various points on the network to react to specific problems or instances of abuse. In response to the most recent (August and September 2003) exploits DoIT deployed packet filtering at the campus border and on the dial pool to block ports that are most commonly used by the malicious activity. In addition DoIT actively blocked traffic from infected hosts by routing that traffic to a null interface or “bit bucket.” (See Appendix A)

Current State of Higher Education Recently the EDUCAUSE Center for Applied Research (ECAR) conducted a study of 435 higher education institutions. More than 87 percent of the June 2003 respondents reported firewall implementations at their institution. Among Carnegie class Doctoral Extensive institutions, more than 40% deploy perimeter firewalls and almost 50% deploy interior firewalls. Table 4.2. Percentage of institutions in each Carnegie class that has adopted a security approach

IT security approach Dr. Ext.

Dr. Int. MA BA AA Special System Canada

SSL for web transactions 81.8% 85.7% 68.2% 67.1% 60.0% 66.1% 73.7% 85.7%Centralized data backup 61.8% 77.1% 69.1% 72.1% 78.0% 66.1% 84.2% 61.9%Network firewall (perimeter) 40.3% 62.9% 76.6% 82.6% 76.5% 82.1% 52.6% 76.2%Network firewall (interior) 49.4% 51.4% 48.6% 51.8% 35.3% 12.5% 15.8% 66.7%Enterprise directory 48.1% 48.6% 38.0% 52.3% 44.0% 58.2% 11.1% 52.4%VPN for remote access 53.2% 48.6% 38.2% 38.4% 34.0% 56.4% 52.6% 57.1%Intrusion detection 53.2% 54.3% 31.8% 38.8% 33.3% 53.6% 31.6% 42.9%Intrusion prevention tools 34.2% 42.9% 24.8% 35.7% 25.5% 38.2% 21.1% 25.0%Encryption 32.5% 37.1% 25.7% 37.6% 33.3% 35.7% 15.8% 23.8%Content monitoring/filtering 19.5% 40.0% 26.6% 36.5% 33.3% 35.7% 15.8% 23.8%Standard for application and system development 19.5% 31.4% 29.4% 31.8% 18.0% 34.5% 26.3% 25.0%Electronic signature 9.1% 8.6% 3.7% 4.7% 6.0% 7.1% 5.3% 4.8%Shibboleth 2.6% 0.0% 0.0% 1.2% 0.0% 0.0% 0.0% 0.0%

@ 2003 ECAR used with permission

Current State of the CIC Within the CIC institutions, there is an overall focus on defense in depth, with firewalls providing an important layer of protection. Almost all CIC institutions provide basic filtering at the peering router, often in combination with departmental firewalls and/or host-based firewalls. Some institutions prefer to rely more heavily on the use of host-based firewalls and other host-based security controls, thereby limiting the deployment of firewalls as well as the utilization of filtering at the router level. The Ohio State University, which offers cost-recovered firewall consulting services to departments, has more than 40 departmental firewalls deployed, which is the highest degree of deployment in the CIC. Departments at the University of Illinois Urbana-Champaign can choose between a fully-open subnet option, mostly-open or mostly-closed. Most institutions recognize the need for a firewall strategy that allows for central management of the firewall structure with departmental administration of the firewall rules and little performance degradation.

Detailed responses from the CIC institutions are included in Appendix B.

Firewalls, Firewall Zones and Strategy and Recommendations to Improve Network Security

The goal of this project and the basis of the recommendations offered are to improve network security for UW-Madison. Inherent in this is the need to protect the university’s assets, respect the privacy of the university community, respond to changes in technology, and ensure compliance with federal and state legislation. The recommendations presented here are, at the same time, respectful of and responsive to the decentralized culture of UW-Madison and the need for the appropriate balance between central security measures and school, college and departmental autonomy. The recommendations presented are organized around the following framework:

Zone 1

Zone 2

Zone 3

Campus Perimeter

Campus Network

Servers and Desktops

Diagram Note: The security controls for all three zones are complementary for our defense-in-depth security plan.

Zone 1 Overview: As necessary, the DoIT Urgent Response Team will implement filters on network traffic entering and/or leaving the campus in order to mitigate risk. Examples of this include the filters established in August 2003 blocking Windows networking. The response team will make recommendations to the CIO on filtering that might be beneficial to UW-Madison. The response team includes staff from DoIT Security, Networking, Platform and Operating Systems Technology, Communications, and others as needed. The response team will alert campus to the current filtering in place as well as periodically review the filters to ensure that are still useful. As appropriate the response team will seek feedback from campus on the implemented filtering rules, e.g. BadgIRT volunteers, CTIG, etc. The filters in Zone 1 are currently implemented with

packet filtering rules on the campus peering router. However, in a follow-up effort, DoIT will investigate other filtering options that may provide additional functionality, e.g. TippingPoint’s Intrusion Prevention appliance. Benefits: The benefits of filtering traffic entering campus include providing a centralized point to assist in protecting campus from external threats, and also the speed at which implementation can proceed once the specific filtering rule has been planned. The primary benefit of filtering traffic leaving campus is protecting the Internet community from machines on the campus network that may be compromised or infected. Implications: In many cases, filtering done in Zone 1 will provide campus additional time to resolve core issues, e.g. patch vulnerable machines. However, the filtering does not eliminate the important need of addressing the core issues in a timely fashion. In some cases, filtering done in Zone 1 will have an adverse effect on a subset of the campus users. A recent example is the case where campus users were sharing files using Windows Networking, which was subsequently blocked for traffic crossing Zone 1. Alternatives, however, were available to help mitigate this problem, e.g. using the WiscVPN client, exceptions to filter, etc. Recommendations:

• DoIT will research, recommend and implement intrusion prevention technologies • DoIT will continue traffic filtering

• DoIT will formalize urgent response procedures to guide in providing timely response to campus during high-impact security incidents

• DoIT will publish the packet filtering rules on the DoIT web site

Zone 2 Overview: The controls in Zone 2 are implemented on the campus network and may include multiple layers. For example, a department may choose to implement high level filtering with packet filtering rules on the campus router for their organization as well as a smaller network firewall for their servers. DoIT will research, fund and implement a centralized firewalling capability for campus. For those with more immediate needs, DoIT will research intermediate options that may include offering packet filtering on the campus routers or implementing dedicated firewall appliances. However, these intermediate options may not offer as many features or be compatible with the future centralized firewalling service.

DoIT will publish networking firewalling best practices including filtering rules corresponding to DoIT centralized services that need to be implemented. The firewalling solutions within Zone 2 may be supplemented with network based intrusion prevention systems for additional protection. Benefits: A centralized service and enforcing firewall standards will enable better management of the campus network as well as reduce risk. Recommendations:

• DoIT will research, recommend, fund and implement firewalls at strategic network

segments which will provide firewalling capabilities for campus o DoIT will seek out possible solutions that will allow for the collaborative

operation of campus firewalls • DoIT will research intrusion prevention technologies for Zone 2 • DoIT will create standards and guidelines for firewalls in this zone • DoIT will research and implement intermediate campus firewalling solutions in

which DoIT will assess needs and identify possible solutions including packet filtering on campus routers and dedicated firewall appliances

Zone 3 Overview: The controls within Zone 3 are implemented with software installed directly on servers and desktops connected to the network. Often the filtering done in Zone 3 can be of increased granularity and tailored specifically for the applications that the individual server or desktop is running. Some operating systems include an integrated firewall capability. These firewalls often offer a basic level of filtering. Examples include:

• Linux operating system -> iptables • Solaris -> Sunscreen • Windows 2000 -> IPSEC • Windows XP -> ICF

In the cases in which host firewalling is not integrated within the operating system or additional features are desired, eg increased logging, increase flexibility in the filtering rules, etc, a third party firewall solution may be needed. Examples include:

• Zone Alarm

• BlackICE • Kerio • 8signs.com

DoIT and campus staff will identify host based firewalling software that might be the most useful to campus and seek out a possible volume license discount as well as publish a list of recommended host based firewall packages. In the cases where it is important to keep risk to a minimum, software packages that provide host intrusion detection and/or file integrity software in addition to firewalling should be considered. These can be separate software packages or integrated into one package, e.g. Cisco Security Agent. Implications: Host firewalls installed on desktops can increase the time needed to troubleshoot usage problems reported by end users. DoIT recommends that campus organizations initially focus on a patching strategy and organization virus protection before implementing host firewalls for end user desktops. Recommendations:

• DoIT and campus staff will research and recommend firewall options as well as

volume discount licensing • DoIT and campus staff will continue to emphasize anti-virus and the patching of

operating systems including research on possible automated patch management

• DoIT and campus staff will research and document best practices for operating system configurations to minimize security risks

• DoIT will continue campus scanning for vulnerable computers

Additional general recommendations:

Offering training to campus staff on firewall information and practices

Use groups such as CTIG, BadgIRT, NT Administrators, CIO Council, etc. to vet recommendations as appropriate

Add CTIG chair and vice chair to Network Security Oversight team

Collaborate and communicate with campus staff on initiatives

Document and post firewalling information and best practices on the DoIT web site

Publish the packet filtering rules on the DoIT web site

Appendix A – Current State of the campus as of September, 2003

Examples of firewalls currently in place Public Health Information Network –Jeff Savoy Human Ecology - John Hilgers, Desktop Svcs, assisted with the Red Gym/Peterson/Fin Aids (Student Affairs) - on-going cycles School of Education – Dean Winger – worked with DoIT Network Services College of Engineering – Bruce Orchard Law School – Eric Giefer (?) State Lab of Hygiene – Jim Leinweber

Lists of requested firewalls Pharmacy - pending; equipment queued NROTC - pending; equipment queued Bascom - 2 hour presentation by DoIT Networking staff; on-going cycles Humanities - pending; equipment queued History - Open Clarify Case Center for Dairy Research - Seth Keel - Open Clarify Case; awaiting contractor Athletics - Open Clarify Case Resnet - Open Clarify Case Plant Pathology - pending; awaiting contractor

Experience of DoIT’s Aug-Sept 2003 port blocking

After Microsoft announced the RPC vulnerabilities and made patching available, DoIT began scanning the 144.192 and 128.104 subnets for unpatched machines, consistent with the University's centralized campus scanning policy. An initial scan showed hundreds of possibly vulnerable machines, thus raising concerns that the necessary patching would be difficult to accomplish before worms exploiting the vulnerabilities were released on the Internet. Filtering rules to block ports 135 through 139 and port 445 for both TCP and UDP traffic were implemented on the peering router to give campus users additional time to patch their machines. These filtering rules did not affect users of the modem pool or VPN service, who were still able to access campus computing resources. Broadcast messages were sent out announcing the filtering. In addition, Tech Partners and the DoIT web site were kept updated with information about the filtering. Instructions for patching machines were made widely available. DoIT continues to scan campus computers for the RPC vulnerabilities and notifies the appropriate contacts of vulnerable machines. While this is helpful, there are false positives, caused in part by

firewalls and machines that are powered off. Self-service vulnerability scanning is available to departments. DoIT also began blocking compromised machines from the internet to minimize damage to the campus network infrastructure. Appropriate contacts are automatically notified by email when a machine is blocked. So far, 552 hosts have been blocked due to Blaster or Nachi-type activity.

Appendix B – Current state of the CIC Indiana University Network Isolation Strategy "Firewalls" Mark Bruhn December 2, 2002 We at Indiana University have long recognized that I) Network connected devices at Indiana University are being probed for vulnerabilities daily. 2) Reports of compromised machines are received at least weekly. 3) Some of these machines host sensitive institutional or personal data. 4) Departments are not consistently maintaining systems - some departments are not equipped to adequately maintain systems. 5) New vulnerabilities are identified every day, and patches often come weeks later. So, even well maintained systems are periodically open to exploit. 6) Our current practice of using network router access lists to provide protection is administratively burdensome, and if widely encouraged would quickly become infeasible -- and these cannot accommodate some legitimate department needs, In any case. Our response to the concept of firewalls at our perimeter has been typical - we were concerned about throughput, cost, and the administrative burden of maintaining firewall policies for a large and technology-diverse environment such as ours. However, lately the concerns outlined above are becoming more numerous and serious, and time spent (and other costs) responding to them has increased commensurately. In addition, devices are now available that will support much higher throughput (in the area of 10 mps), thought they are still somewhat expensive. We are initiating a two phase project, described below. To support both phases, we are establishing a semi-permanent "Network Defense Team", which will be initially comprised of a new Network Security Engineer, a current staff person from Telecommunications and a current staff person from the IT Security Office. The first phase is designed to provide additional protection for our main data centers, at IUB and at IUPUI. We will purchase and install medium-throughput firewalls to provide an additional layer of defense for these central data centers. The new Network Security Engineer will maintain these firewalls, with planning assistance by the other Defense Team members, as well as manage current and planned router access control lists. For phase II, we will borrow two high-throughput devices and install those at our two links to the Indiana GigaPoP, to protect connections to/from external networks. The Network Defense Team will identify several departments as needed to represent our user environment, and will work with those departments to represent their traffic in the firewalls. If the perimeter evaluation proves successful, we will purchase these devices, and we will hire a second Network Security Engineer. These 2 network security engineers, in consultation with the other Defense Team members, will maintain the data center firewalls, router access control lists, and perimeter firewalls. Very "simply", the plans are to use the firewalls to create I) a "logically private network", and no devices with these "private addresses" will be visible off-campus. This will eventually be come the default connection for new devices. A large gain here is the protection of workstations, which number in the several-IO-thousands on our campuses, very few of which need to be accessible from off campus. In addition, sever-class devices that only service on-campus functions will be likewise hidden from the outside world. 2) a "logically public network" on which devices that do need to be accessible from the Internet and Abilene reside. Attachment to this network will require that the device undergo a security review initially and periodically. Reviews will include management and other non-technical aspects, as well as mandatory vulnerability scans and other technical requirements.

University of Illinois at Urbana-Champaign Firewall Report Campus units have recently been offered a firewall service that provides an IP address with wide-open, mostly-open, or mostly-closed Internet access. Some units are using equipment that can not support this service. The equipment will be upgraded on a schedule that addresses any unfulfilled firewall requests. Within these service levels, all machines can get an outbound Internet connection. The firewall services addresses only connections originating from the Internet. The current campus firewall acts as a IDS and a means to filter campus addresses from making Internet connections. Campus Security and campus Networking have access rights to create/remove these filters. Additionally, there is some limited ability to identify virus signatures in the flow of network data packets. These devices are under the juristiction of the networking group. I do not have information as the the level of capital investment. However, there is a full time staff member assigned to this service. The presence of this firewall permits the networking people to examine traffic patterns. Certain traffic patterns alert the networking staff to compromised machines, misconfigured machines, and virus infected machines. These reports are relayed to Campus Security which involves the appropriate staff within the unit to resolve the issue(s). This arrangement, although not ideal, does provide an indication of trouble before reports come from the 'victims'. It is felt that the issue of who 'manages' the desktop is one that needs to be addressed. Units who 'lock down' the desktop so users cannot install random applications tend to have fewer incident reports then the units where users can install applications. Often these systems do not have current versions of system patches and do not have any anti-virus software installed.

Ed Zawacki University of Illinois at Chicago We see firewalls as playing an important role on campus at the department and individual host level. A firewall at a higher level than that (i.e. at the campus level) would be incredibly difficult, if not impossible, to maintain in our diverse environment. Currently, the number of departments that have invested in firewalls of their own accord is in the neighborhood of 5-10. The firewalls purchased range from approximately $2000 to $10,000 each. In addition, many individuals have either purchased, or downloaded free copies of personal firewalls for their desktop machines. An alternative that we are considering is to purchase a firewall from a vendor such as Netscreen that

can use one firewall box to provide firewalls for departments that they can individually manage.

We believe the best solution is, as mentioned. above, to implement departmental firewalls with a machine that is (hopefully) powerful enough to throw the offending packets away and continue to provide useful service. In reality, if the DOS attack is powerful enough, the best way to currently deal with the attack is to contact the upstream provider and have it filtered on their end. In addition to the above, basic filters in the border router can be of tremendous help in deterring and mediating attacks. Filters for things such as netbios over tcp (Windows file sharing), snmp (simple network management protocol) and icmp (ping) can be of tremendous help in preventing attacks.

University of Chicago Firewall Report Right now, we are using firewalls to protect most of our centrally managed servers on our network. These firewalls are for the most part host-based firewalls, however some systems have hardware firewalls in place. We tend to use hardware firewalls on systems which have multiple machines that communicate with each other in complex methods which make host-based firewalls less effective, or which have services which we feel have a non-eligible chance of being compromised and need to run with privileges that would allow the firewalls to be disabled. At the moment we recommend to students, staff, and faculty that they run a properly configured host-based firewall on their machines -- both desktops as well as departmental servers. We do not currently provide either a license for such software or configuration instructions, but we are in the process of investigating options to do so. At the campus border we currently do limited stateless filtering on our routers on a few select ports.

Overall, we probably spend less about $50,000 a year on firewalls for the systems.

Right now, our goal we are happy with our general configuration, though we would like to improve it in a few ways -- specifically, we would like to see a much more widespread implementation of host based firewalls. We would also like to work on installing a proper firewall at our gateway in order to do stateful filtering as well as to allow us to filter more ports without an adverse effect on network performance.

Purdue Firewall Use & Plans Current Status Purdue University does not currently have dedicated firewall devices in place within the network infrastructure. Standard ingress and egress filtering is applied on the border routers, however, to ensure that packets entering and leaving the campus network do not contain a forged source address. Standard Network Management Protocol (SNMP) traffic is also blocked at the border to prevent external access to campus network devices. Purdue also restricts network access to the campus mainframe and a few other administrative machines. The restriction only allows access to these machines from other campus hosts with a valid Purdue source address. Ports-based access control is also maintained for the Engineering Computing Network (ECN) to restrict external (non-Purdue) access to certain services such as the Network File System (NFS). Initiatives Firewalls are a necessary component to provide network security. Towards that end, Purdue has been investigating and developing several solutions to improve network security on at the university. The wide variety of environments at the university requires that we take several approaches. IT Security has been developing software-based firewall appliances for small departmental networks. The appliances are based on freely available packet filtering software that is part of Open Source software such as Linux and OpenBSD. These firewalls provide stateful packet filtering capabilities with no software licensing costs and can be run on commodity hardware. This solution is currently undergoing performance testing. Additionally, IT Security has been investigating different vendor solutions for a more global firewall strategy. The goal is to find a system that can delegate daily administration to the various departments or areas being protected while maintaining centralized control and management of the firewall devices. Currently IT Security is researching products from Cisco, Netscreen, and Checkpoint-I.

more susceptible to being disabled. Both network and personal firewalls have a place in a security architecture. Neither can really replace the other. One can try Intrusion Detection Systems (IDS) either a) minus firewalls - in which case you still get "had" but know more quickly that it's happened and can respond; or b) in combination with a function or device that provides the filtering (e.g., a firewall or a separate filtering component (Hogwash-like). Penn State is currently in the testing phases for IDS which will determine how and where they will be deployed and whether they will be employed alone, in tandem with a filtering capability/firewall, or some combination of both. The following are some relevant portions of the 1999 "Computer, Network and Information Security Strategic Plan" for Penn State that address many of the reasons for pursuing Firewalls and IDS (network security vs. host alone). Note: since this is a comparatively old document now, the estimate was that we had days or hours to patch vulnerabilities and (even at the time) this was insufficient to enable reliance on host security alone. The time from vulnerability-to-probe now is actually closer to minutes rather than hours for our address space to be "tested":

"One of the more critical elements needed to bring about an effective security architecture! for the University is an examination of solutions beyond those that can be implemented at the individual workstation level. While for many years it was possible to rely on "host-based" security and the ability of individual users and system administrators to secure each machine attached to the University's backbone, this is no longer a realistic expectation. Within days or even hours of a vulnerability being announced and a program to exploit that vulnerability released on the Internet, the entire University's address space may be probed by someone, somewhere, who is looking for any machine that has the vulnerability. The machine can then be co-opted for whatever purpose the intruder desires. Even with knowledgeable system administrators reacting promptly to new threats, the speed with which new problems must be identified and patches applied means host- or workstation-based security alone may not keep pace with the dynamic nature of the threats.

While host security will continue to be an important element in the security program, controls beyond

the desktop are now increasingly essential to maintain an effective security posture University-wide. A strategy integrating security elements effectively at multiple levels is the ultimate goal. Segregating sensitive administrative information and/or limiting the number of systems that can access such data to only certain network ranges has long been a hallmark of the University's "trusted LAN" concept. The concept needs to be fortified and extended, with similar mechanisms applied (as appropriate) to safeguarding other sensitive data. If access to insecure and unneeded services can be filtered out either centrally or at the LAN level, the attacker is essentially blocked from compromising the system. A combination of carefully planned

lA security architecture is the entire integrated set of technical controls and other measures necessary to protect an enterprise effectively. No single control can protect a large enterprise, hence "defense in depth" or a security "architecture" with multiple layers of defense mechanisms is essential.

Penn State Below is the Penn State Security response to the CIC CIO questions regarding firewalls. Note: the response is from Security Operations and Services alone and does not represent an overall Information Technology Services or institutional response: 1) The role that firewalls play on CIC campuses... Firewalls have a steadily growing presence within Penn State. At present it is a unit decision whether to procure and operate a firewall. Information Technology Services (the central IT organization), through its Security Operations and Services unit, will assist/advise units on firewall needs if requested. The Telecommunications and Networking Services (TNS) unit within ITS will soon announce a firewall service that units can contract, in which TNS will be responsible for installation and management of the firewall device in response to configuration requests from the network contact(s) for the affected network segments. Currently very little filtering is done at the main border level. 2) The approximate level of investment in firewalls. . . This is not possible to calculate easily since the firewalls that are installed are unit funded. The most educated guess available (based upon responses/blocks/exceptions that must be requested) when the scanning service offered by SOS/ITS encounters a firewalled network is: approximately 41 firewalled unit-level networks system-wide. More units are in varying stages of evaluating and/or purchasing firewalls, so their presence overall is increasing. 3) Are there alternatives and what role these alternatives are playing? The real question is alternatives for what? Firewalls are part of a defense-in-depth strategy. To have an effective security strategy, the institution needs to have addressed at a minimum authentication and authorization, communications security (for confidentiality and integrity protection en route), host security, audit logging (for reconstruction) and limitation of unnecessary services (open ports)/unnecessary connection attempts (through disabling them on the host or limiting them via a filtering strategy). Where firewalls fit is mostly in the category of filtering strategies and limiting unneeded services, though there is an audit/reconstruction component associated with the firewall logs. Are there alternatives for this part of the security architecture? Yes, but these have largely failed. Every host could be well-administered and patched within minutes of the time a vulnerability is announced. That simply isn't a realistic expectation and plainly hasn't worked over time. Routers can do some simple filtering but largely cannot handle the complex ruleset (stateful handling) that a true firewall can handle (and which is ultimately necessary to allow the level of flexibility required for academic settings). A campus could try for ubiquitous dissemination of personal firewalls, but that has many of the same limitations currently experienced in trying to secure 100% of the hosts on campus. Moreover, if the host is compromised (by for instance an email borne attack or by poor fileshare permissions or trust relationships), the personal firewall is

filtering2 implementations and intrusion detection software to determine whether an attack is ongoing may provide vital warning and allow some of the more common attacks to be thwarted before actual damage or system compromise occurs." 4) Best approaches for minimizing and managing the impact of security attacks throughout our campuses. . . a. Recognize that this is a very complex problem that requires a constant funding stream. (It's not a "fix-it-once-and-you're-done" proposition). b. Recognize that there are no magic bullets. There is no single security technology that can solve the current situation unilaterally. What is needed is "defense-in-depth" with a well-integrated and well-considered architecture. Firewalls play an important role in this, but are not the "end all" or single element needed. Similarly (or is it conversely?), the need for something to perform a filtering role also can't be ignored forever and shouldn't be delayed. A well-configured firewall/filtering strategy does not inhibit what users need to do; it enables needed functionality while limiting attacks. (Overall this is desirable end, recognizing that at some point firewall technology will become dated/obsolete. But, for the present, they're both available and effective for the specific role that they play in a well-planned security architecture). c. Put the policies, plans and procedures in place necessary to install an integrated defense-in-depth set of solutions. Identify a funding stream to support the Plan (when formulated). d. Lobby vendors for better security out of the box. e. Find a practical way to train and recognize system administrators for their role in creating a more secure environment. 2"Filtering" in this context refers to configurable hardware or software that allows, at a minimum, for inbound and outbound network address and port filtering. In certain locations, more sophisticated measures may be required depending on the results of the study.

Ohio State University Firewall Report I. The role that firewalls play on CIC campuses: At Ohio State, we've been encouraging "groups" (Colleges, departments, research groups and other business units) to install firewalls at the borders of their networks, and to use virtual private networks to protect sensitive traffic that flows between different worksites or for remote access. We do very limited filtering at the University's border to the Internet. Although we do filter out spoofed traffic and source-routed traffic, we do not filter any traffic based on source/destination port or IP protocol. This is because, due to the size and diversity of our campus, any such filtering would necessarily be incomplete and would not provide an effective level of security. Departments and other groups would still have to install firewalls at their borders. Rather than install an ineffective "firewall" for all of campus, we have invested our resources into departmental firewalls. Our incident response team encourages the use of firewalls at the University (both in propactive and reactive ways). We also have a full time person on staff whose job is to provide firewall consulting services (design, deployment, maintenance) on cost-recovery basis. Some departments choose to buy their own hardware/software and either configure their firewalls themselves or hire outside consultants to do it. Best estimate is that there are between 40 and 50 firewalls on campus, installed in about as many different departments. II. The approximate level of investment: A conservative estimate for the cost of each is $2000 for the hardware/software and $2000 in staff time to design and deploy each firewall. If there are 40 firewalls, that totals to $120,000, mostly distributed among the departments that have installed firewalls. That's a lower bound, some of the firewalls are fairly expensive and external consultants are not cheap. III. Whether there are alternatives and what roles those alternatives are I Firewalls are used to restrict access to network services. One alternative would be to just -disable all network services, but that isn't very practical - many network services are necessary for "effective" use of computers in a LAN environment (file and printer

sharing services, for instance). In an ideal world, we could prevent intrusions if everyone just secured each individual computer, but the reality is that computers are rarely properly secured, and even if they were, new bugs for which patches are not yut available are always being discovered, so intruders would still be able to gain access to these "secured" computers. One long-standing security principle is called "defense in depth", which means that you should protect assets with a variety of complementary protections, rather than relying on a single mechanism. From this standpoint, firewalls are really pretty irreplacable. There's been a lot of work lately toward "personal" or host-level firewalls, such as what you find on most of the Linux distributions or in Windows XP. These are good and useful, but can't take the place of network level firewalls, since they can be subverted by successful attacks on the computer they are installed on (many recent viruses look for and disable local anti-virus and personal firewall settings) and because network level firewalls can be used to enforce policies regarding the availability of network services to the outside world. You can't do that with the so-called personal firewalls since these are (generally) under the administrative control of the workstation user, rather than the network administrator. IV. What the best approach(es) might be to minimizing and managing the impact of security attacks on machines throughout our campuses: Prevention is good. We find that most (>95%) of successful attacks on our computers could have been prevented through the correct application of basic security precautions: set passwords on all accounts, use good passwords, install security patches in a timely fashion, disable unneeded network services, use anti-virus software and update it frequently, and use firewalls to restrict external access to just what is needed. It would be nice to mandate these practices through some sort of policy, but we don't currently have anything like that at OSU, but instead resort to common sense, awareness building and education (mostly after computers have been broken into, unfortunately). Early detection is critical also. Security attacks will still sometimes succeed, and it is important to have effective host and network based intrusion detection systems to help you identify and respond to successful attacks quickly. At OSU, we have long-standing policies that have allowed us to scan computers attached to our networks for security vulnerabilities and report these to the appropriate network administrators so that they can fix them. We also have a policy whereby compromised computers are blocked at the local router until they have been fixed, which prevents them from sourcing malicious behavior (such as denial of service attacks or scans) and from further damage from the intruders.

Northwestern University Firewall Report Northwestern University does not run a campus firewall.

UNIVERSITY OF MINNESOTA Office of Information Technology Security and Assurance 612-625-1505 November 25, 2002 TO: Steve Cawley, CIO & Assistant Vice President FR: Ken Hanna, Director of Security & Assurance RE: Firewall response I recently received a request from Karen Partlow of the CIC office on behalf of the CIO's for some information concerning current practice and alternatives. My responses to the specific questions for the University of Minnesota are below. Note that I am using the term "firewall" to include other forms of filtering as well.

1) The role that firewalls play on CIC campuses: Border filters (e.g. 30 filtered ports and other rules) RFC-1918 non-routed addresses (lOO's of machines) Desktop software firewalls (lOO's of machines) Server-level software filters (e.g. iptables & ipchains for Unix; 1O0's of machines) Classic hardware firewalls (5-10 departments protecting 100's of machines) The border filters are the first line of defense by our campuses to protect against many common attacks. Hardware firewalls are used as a tool in some departments to help protect a population of machines. The non-routable addresses as well as the software firewalls are used to protect individual hosts.

2) The approximate level of investment in them: $50-100,000 for the desktop software and hardware firewalls in one-time costs plus ongoing monitoring, updating, and maintenance costs (people time) that are difficult to estimate, but nonetheless significant

3) Whether there are alternatives and what roles those alternatives are playing: The alternatives to centralized or departmental/collegiate firewalls in the short term somewhat depend upon the architecture of the network and the needs of the user population. We have a mixture of private networks and centrally managed networks that are not provisioned by organizational unit. This architecture makes agreement on firewall rules quite difficult at the network level. Even within a department, agreement is difficult in an academic environment. Host-based filtering for the most important machines along with internal-only addressing allows fine-tuning of the firewall rules to meet needs. 4) What the best approaches might be to minimizing and managing the impact of security attacks on

machines throughout our campuses: More than anything, we need "defense in depth", i.e. multiple layers of protection. No single security tool will ever sufficiently protect our machines from security attacks including denial of service (DoS) attacks. There is a temptation (and danger) in overly depending upon a border firewall or even a departmental firewall for a "secure" environment. With the recent rapid evolution of attack methods, a staff with a high degree of expertise in addition to tools such as a firewall is a necessity.

Still, firewalls can be useful to reduce the level of noise to allow novel attack methods to be visible. The ability to filter/firewall at the border level as well as the core and port levels would be an ideal approach. This could be accomplished by segmenting the network with associated network filtering/firewall rules for the various risk areas (dorms, enterprise servers, etc.). Filtering at the edge would ideally be configurable per port, but lacking that a few filter templates (appropriate to the risk) would provide security choices for protection from the most common attacks. In addition, a policy for the dorms of no in-bound connections from the Internet (i.e. connections initiated by a machine off-campus not allowed) would likely reduce the exploitation of the largely un-secured machines there. In addition to the above networking changes, tightened policies and practices, particularly for connecting machines with sensitive data to the campus network, should be considered. For example, machines that store sensitive data should be set up and administered by a technology professional (not a random grad student or staff member). Increased attention should be given to increasing user awareness of security issues and ways to mitigate risks. Another part of the defense in depth might be site licensing of one or more software firewalls for desktop machines. Based upon the experience with centrally funded antivirus programs, usage and protection of the campus community increases greatly if the dollar implications are taken out of the picture for the user. A few types of Denial of Service attacks can be mitigated somewhat, but attacks such as in-bound distributed DoS's must mainly rely on upstream ISP notification and filtering. Network architectural changes to allow bypass of certain routes may mitigate the negative effects of certain attacks on the rest of the network. Of the DoS attacks that can be mitigated, improved and early detection is key. Active monitoring of traffic patterns, router flow analysis, and other metrics allow timely identification of anomalies and reduced damage from any intrusions. Since hacked machines are frequently either the source of outbound DoS attacks or the target of inbound attacks, the use of intruSion detection systems can be helpful.

Response to CIC CIOs questions on firewalls. November 27, 2002 The University of Michigan Paul Howell I. THE ROLE THAT FIREWALLS PLAY ON CIC CAMPUSES At The University of Michigan, units decide if a firewall is to be installed or not based on a risk assessment. Units that choose to install a firewall usually do so as one part of a broader effort to protect critical assets such as human resource records, or a group of key business administrators such as General Counsel and Provost office staffs, or in response to regulatory requirements such as HIP AA. A firewall, while capable of filtering network traffic, has to be configured to do so. Any question about the role of firewalls should also include a discussion of the network filtering policy it enforces. Firewalls do little good if they are left wide open. Academic and research units tend not to deploy firewalls due to the unpredictability of network traffic. Firewalls can pose a risk to legitimate work being done by students, ,

academicians, and researchers through the enforcement of network filtering and potential limitations on network performance. This is particularly true of researchers working on IPV6 and multicast protocols that are not universally supported by fIrewall manufacturers. II. THE APPROXIMATE LEVEL OF INVESTMENT IN THEM (FIREWALLS) The investment in a firewall can be significant both in terms of money and resources. In most settings, selecting the appropriate firewall is a product of the following:

. offered workload by the network is used to size the hardware correctly

. selection of appropriate firewall technology based upon security requirements of what is being protected

. physically where in the overall network topology will a firewall be placed

. a fundamental approach to the policy that will be enforced by the firewall and the level of risk that the organization willing to accept

. deciding if a high availability architecture is necessary Support of a firewall may require periodic training of the firewall support staff as newer versions of the software are released. Users may be affected when applications that rely on network protocols that are blocked by the firewall, struggle to understand why an application is not working. Finally, the privacy of peoples' network activity can be impacted based upon what post-processing occurs on the firewall logs.

III. WHETHER THERE ARE AL TERNA TIVES AND WHAT ROLES THOSE ALTERNATIVES ARE PLAYING Host- based security is an alternative strategy to firewalling networks. Appropriate steps are taken to secure each host attached to the network, such as turning off unnecessary services, configuring services that must run to be more secure, and appropriately monitoring system activity for unauthorized access. This approach is widely adopted here at Michigan by many departments.

IV. WHAT ARE THE BEST APPROACH(ES) MIGHT BE TO MINIMIZING AND MANAGING THE IMPACT OF SECURITY ATTACKS ON MACHINES THROUGHOUT OUR CAMPUSES

Many approaches that could be taken have been spelled out in a recent meeting of the CIC SWG and the Educause security task force. See http://www.educause.edu/security/ for more information.

DRAFT DRAFT DRAFT DRAFT 10/10/03

CIC-CIO Firewall Report - The University of Iowa I. Role of firewalls at the University of Iowa We believe that firewalls are just one aspect ofa total "defense in depth" security strategy. We strive to manage the many layers of security, including physical access, host-based controls, network-based controls, data access controls (confidentiality), user-based controls (authentication), security policy, guidance (best practices), and procedures, and also our employee/user practices. Solutions are rapidly changing, and newer port-independent applications negate much of the usefulness of packet filtering firewalls. The costs of application gateways or hybrid firewalls are prohibitive. We choose to rely less on network-based "firewall" protections that may provide a false sense of security, and more on standard host based security controls. We employ the standard packet filtering "firewall" measures at the campus border routers (ingress/egress filters, SNMP, etc), which still provide maximum performance and throughput, and tend to rely more on host-based "firewall" and intrusion detection techniques to protect critical services. 2. Approximate level of investment in firewalls Iowa has a low investment in firewalls. Some departments have chosen to purchase and implement network firewall devices, but they are not employed centrally. In addition, there has been a modest investment in workstation/personal firewalls, but no campus/site licensing agreements or recommendations are made. 3. Alternatives to firewalls Our philosophical position is that firewalls might do more damage than good, as they are often marketed as "the" security solution. If a firewall fails, or is not actively managed, it can either cause denial of service to legitimate users, or a complete data disclosure/compromise situation for unauthorized users. If a firewall is required for application security (e.g., other controls are not available), we will use them, but their use is not promoted. We prefer to promote the use of standards-based security controls at the host/server level, and hope to look into wider use of passive intrusion detection. 4. Best approaches to minimizing/managing impact of security breaches We believe that the best approach is education, through the development and dissemination of policy, best practices, and procedures for securing computer systems and networks. The widespread availability of low-cost or free tools and services to help the administrator secure their systems is also important. (e.g., the certificate service, mirror sites for patches, and the scanning service.) Finally, a support network is important to ensure resources are available when problems arise, and people know what to do.

Page 28 of 28