Firewall Products - A Quick Overview and Evaluation

Prepared by: Cliff Kettemborough, Section 312

August 5, 1996

This is a quick overview of some of the existing Firewall products as related to Network technology
The findings are based on a limited survey of literature, i.e., trade journals, published during the past couple of weeks
Copies of selected articles are attached for your perusal
This may be considered just a beginning; this is not a completed task; appropriate resources and expertise are recommended pending approval to pursue the preliminary findings herein

One of the major concerns of NAV Network Task Group is related to network security:
Provide a network architecture that satisfies both TMOD and NAV sub-systems requirements
Propose and implement a secure operating environment within these sub-systems and in their communication with the outside "world," as needed

Definition: "A Firewall is typically a router- or server-based gateway through which incoming information requests are screened and outgoing requests are transmitted."
Firewalls may become increasingly important as agencies develop intranets - internal World Wide Web-based networks with links to the Internet
There are an estimated 60 to 80 firewalls vendors on the market
A $10,000 price point is fairly typical of midsize networks of 50 to 250 nodes network
According to experts, a firewall alone won't help agencies that lack coherent security policies

"We see a lot of problems where people throw up firewalls, but their security policy is not that well-defined" - according to Bruce Hartley, the chief technology officer for integrator Trident Data Systems
Often users "don't go back and look at [the firewall] periodically to make sure it's doing what they need", and some agencies have paid to have firewalls installed but lack the expertise "to look whether [the firewalls] are doing the right job," according to John Wack, a computer scientist for National Institute of Standards and Technology's Computer Systems Laboratory
"When it comes to securing information systems, firewalls are only as good as the IS organization implementing them" according to Julie Bort in a article in Software Magazine, August 1996 - attached

National Security Agency (NSA) within DoD, and National Computer Security Association (NCSA) - a private organization, are involved in firewall testing and certification as well. [See please attachment of 16 firewall products NCSA certified, so far]
NSA has published a draft set of requirements for firewalls
Beginning this fall, commercial firewalls will be tested against these requirements. [The document is on the Web at http://mittn.ie.org:8000/]
The following issues are to be considered as part of a plan to select and implement a firewall: [according to Julie Bort's article: "Only you can prevent faulty firewalls" in Software Magazine, August 1996]

Weak, neglected or non-existing security policies
A firewall is, by definition, an enforcer of security policies. It's extremely difficult, if not impossible, to configure a firewall properly if security policies have not been created.
Network access points that fall outside the wall

A network access point inadvertently left outside the protection of the firewall is a security breach waiting to happen

Most firewall have the ability to produce copious amounts of information on the activities they are charged with monitoring

Users who are granted access to information systems should have airtight passwords

Users should be training to scan E-mail attachment for a "Trojan Horse," an unauthorized program that gains entry by attaching itself to authorized programs or data

New technology is often overlooked as a security threat: Java (an object-oriented, open, network-focus programming language) is the most cited by security experts

Even the best firewall is vulnerable to attack if someone on the "inside" collaborates with an outsider

It behooves security managers to foster a "closer door" policy regarding users who want to surf the Internet/Intranet

The same article points out a very "aggressive" curve representing Worldwide Firewall Shipments, 1995 - 2000, as well as 6 major vendors, with their addresses, that sold about 10,000 units, already
Products availability ranges from a PC all the way up to a Mainframe platform, within a variety of operating systems and price range [see please attachments]
For instance, a product comparison is done in InforWorld Magazine issue of July 29, 1996. Here are the main points:

Good fences make good neighbors
A proxy server will isolate your system more fully by creating a physical barrier between the inside and outside (without compromising user transparency). In a proxy configuration, users' clients communicate directly with a proxy server for a specific set of protocols, such as FTP, HTTP, and Telnet

Even after your firewall is in place, your security responsibilities don't ever really end. Firewalls promise many things, except minimal care and feeding; they are far from a set-and-forget technology

Even a "strawman" cost benefit analysis should be performed before next step will be taken. User's and business requirements should be the driver. A draft dollar estimate may help, for the next step. These may be some of the questions to answer:

Based on the existing and future needs what is the cost of not having an acceptable (to be defined) firewall product in place?
What would be the cost to identify, evaluate and implement an acceptable firewall product?

The Cost-Benefit Analysis is not an easy exercise, but justifiable

The above presented ideas is just a top level overview of issues related to firewall products, perhaps a beginning
The survey of some of firewall products has been done at a top level, based on other authors' input and a limited search of available resources, within given time constraints
Firewall technology is a relatively new one, but developing very rapidly. Even though most products sound like not solid yet, the idea of a firewall is worth to be pursued, given the resources and "down the road"-derived benefits
Perhaps working in collaboration with other resources/groups on the Lab can be more effective and providing for "short-cuts"

Based on the above, in particular the Conclusions and Cost-Benefit Analysis areas, the next step would be that recommended by this Task Group

Regarding the pages posted to this WWW area or for further information about the Software Architecture, contact Cliff Kettemborough