Firewall Product Functional Summary Format

Conventions Used in this Document

This document is a template that consists of a numbered outline with a few pieces of standard "boilerplate" text interspersed within it. When following the template, leave the outline and boilerplate text the same. In the sections of text that are free-form areas, any combination of text or illustrations is permissible.

Throughout the template comments have been marked in italic text surrounded by bracket '[' ']' symbols. When filling out the template, delete the comments.

Formatting and Availability

This draft uses a very basic subset of document formatting conventions, to make the results easy to mark up in HTML or other formatting languages. There are 4 primary text types:

Level 1 headings are formatted with a canonical number, in 14-pt Times Roman bold, with no indenting or paragraph indenting. A full line's leading (whitespace) precedes each level 1 header.

Level 2 headings are formatted with the canonical number of their parent level 1 heading, and a sub-section number. They are formatted in 12-pt Times Roman bold, with .3" indent from the left and .9" line leading before the header.

Paragraph text and bulletted paragraphs are justified 10-pt Times Roman, with a .5" left indent on the first line of text, and .5" leading between paragraphs. Bulletted paragraphs are the same, with a bullet followed by .2" whitespace before the beginning of the text.

Within the comments, a number of sections are formatted as bulletted lists. This convention is not mandated by the template.

This draft will be made available for public use as HTML, in MS-Word format, and as MS-RTF (Rich Text Format)


[You may insert a corporate or product logo here]

Firewall Product Functional Summary

1. Product Version

Vendor Name: [This should be the corporate name of the vendor]

Product Version: [This should be a single sentence, specifying the name and version of the product to which this summary applies. The purpose of this section is to prevent confusion and to allow the vendor to supersede a version of the summary as a product is updated.]

Date of Publication: [This should be the date of publication of this summary, specifying when it becomes "official"]

2. Executive Overview

[Fill in this section with a one paragraph summary of what your product is, what it does, and its distinguishing characteristics. Avoid technical jargon in the Executive Overview section.]

3. Overview of firewall product functional summary program

[The section following is boilerplate to be included with all firewall product summaries verbatim and is not to be altered or deleted.]

3.1. Scope and purpose of firewall product functional summaries

The purpose of the firewall product functional summary program is twofold:

The summary format used in the program has been derived through an open process including firewall vendors, agencies of the computer security community, and the firewall customer community. This cooperative effort is a voluntary program.

3.2. Security and design principles

When designing computer security systems, as with other mission critical systems, it is important that the basic design principles of the system be sound, and that the implementation be of high quality. When choosing a computer security system, it is important for the customer to be able to judge the capabilities and design principles of the system in terms of the protections required by that customer's intended deployment of the system. The functional summary program permits computer security product manufacturers to present their products and designs in the best possible light, while adhering to a format that encourages accurate product comparison. The summary format requests information from the vendor about design decisions made in a number of important areas, yet tries to permit the response to be as free-form as necessary so as not to constrain the vendor within the bounds of a narrow definition of what constitutes a "firewall."

3.3. Terms and definitions

Since the network security field is dynamic and rapidly growing, new techniques and terms are constantly being brought into use. To provide a basis for clear communication, a simple glossary of terms and definitions is provided as a part of the summary format. Vendors are welcome to define their own terminology, distinct from the terms in the glossary, but are requested to provide definitions in the glossary section for new terminology that is coined, and to annotate them as such. Readers of this document are encouraged to peruse the glossary section for annotations and definitions of such new terms as may appear.

4. Product Overview

[Fill in this section with a brief description of your product's primary features. This section should be more detailed than the Executive Overview and should include information about:

]

5. Vendor information

[Fill in this section with whatever you wish to say about your company and its background, etc.]

5.1. Contact Information:

Contact name: [optional]

Contact Business Hours:

Contact telephone number:

Contact FAX number:

Contact Email address: [optional]

Contact Web URL: [optional]

Contact postal address:

6. Product security architecture

[The Rationale paragraph below is boilerplate to include with all firewall product summaries verbatim and should not be altered or deleted.]

6.1. Rationale

When describing a networked computer security system, there are several aspects of its design that must be taken into consideration. A security system such as a firewall must be able to protect not only the systems connected to it, it must be able to protect itself. Generally, the mechanisms whereby this is accomplished are different. The firewall system's security is dependent on whatever security mechanisms the firewall has built into itself. The systems connected to the firewall's security are dependent on whatever security mechanisms the firewall provides to them. In some cases these mechanisms may be based on a common design feature. In others they may be a result of a combination of features. In this section we explain how the firewall protects itself and the systems connected to it. In cases where additional protections are provided, or additional protective relationships are provided, we will explain the design principles and operation of these protective relationships.

6.2. Security Architecture

[Fill in this section with as much information as is appropriate to provide an overview of the basic security architecture and philosophy of your product. The goal of this section is to indicate why your approach is valid, unique and desirable, and how the overall architecture of your system enhances its security properties.]

6.3. Product default operations

[Describe briefly the assumptions that your product makes on behalf of the user when the product is initially installed. Topics that are appropriate to discuss here are:

]

The goal of this section is to give the potential customer an idea of what assumptions are already built into the firewall. This is important in order to understand its security properties as well as how much configuration they will have to perform on their own. Explaining the default options your firewall supports will give your customers a better idea of how much effort is needed to make it operational. Since a firewall implements policy, the firewall's defaults are its default policy.]

6.4. Protection of the firewall system

[Fill in this section with a description of how the firewall system protects itself against attack. Some topics that might be appropriate here are:

The goal of this section is to explain to your potential customers why your product is secure and why you believe your firewall is resistant to attack.]

6.5. Protection of attached networks and hosts

[Fill in this section with a description of how the firewall system protects connected systems against attack. Some topics that might be appropriate here are:

The goal of this section is to explain to your potential customers why your product protects hosts that are behind it, and why you believe that the protective controls it implements are resistant to attack.]

6.6. Protection of individual hosts [optional]

[Fill in this section with a description of how the firewall system interacts with individual hosts "inside" or "outside" of the firewall, if there is some kind of interaction that improves or bolsters the security of the firewall or the individual hosts. Some topics that might be appropriate here are:

The goal of this section, if it is appropriate to your product, is to explain to your potential customers what extra security related interactions your product may provide for systems it protects, and how these mechanisms are resistant to attack.]

6.7. Other protective relationships [optional]

[Using the same format as above, if your firewall has some other protective relationship it maintains with some other network or system, take this opportunity to describe it and how it is of significant value or interest examples might be:

...etc.

The goal of this section, if it is appropriate to your product, is to explain to your potential customers what extra protective capabilities your firewall provides and why you believe that they improve the security of networks where it is deployed, and how the additional mechanisms are resistant to attack.]

7. Product features and mechanisms

7.1. Services Provided

[If your product provides service-based controls, please list the services that are supported across the firewall. This should be in the form of a relatively simple list, since there is an opportunity to provide more detailed per-service information below. If your product does something unique in its handling of network services and security, describe it here, and how/why it works and how it is resistant to attack.]

[This section "Services Provided" may be extended as appropriate to explain your design/service philosophy.]

7.2. [Service 1] [optional]

[For each service, as desired, if appropriate, describe the:

The goal of this section is to describe how you provide security for services, and how your approach is resistant to attack, easy to use, etc. Another topic that we recommend you mention is any default behaviors applied to this service, e.g., is it initially disabled? does it log all transactions by default or does it require action to have logging enabled? etc.]

7.3. [Service 2] [optional]

7.4. [Service ... N] [optional]

8. Product audit/event reporting and summaries

[Fill in this section with as much information as you wish to provide about what kinds of events the firewall logs and audits, how they are reported, and summarized. Topics that are of interest here are:

The goal of this section is to demonstrate to a potential customer the types of information that the product will provide to the administrator, and the types of operational summaries that will be available. We suggest that sample report formats or alert messages be included as Appendices to this document.]

9. Product testing methodology

[Fill in this section with a description of your product testing and quality assurance procedures. Topics that are of interest here are:

The goal of this section is to demonstrate the tests and procedures that are applied as part of the release/test cycle for the product, and to show how they argue for the reliability and integrity of the product.]

10. Product operational assumptions

[Fill in this section with a brief description of operational/environmental assumptions your product makes. Topics that are of interest here are:

]

11. Product operational/management requirements and interface

[Fill in this section with a brief description of operational/periodic management requirements. Topics that are of interest here are:

]

12. Product customer support

[Fill in this section with a description of your product and customer support policies and services offered. Topics that are of interest here are:

]

13. Product interoperability considerations

[Fill in this section with a discussion, if appropriate, of any interoperation concerns or features. Topics that are of interest here are:

]

14. Glossary

[The "Format" section below is boilerplate to be included with all firewall product summaries verbatim and is not to be altered or deleted. Authors of this document are requested to carefully observe the annotation/change marking policy.]

14.1. Format

Newly added terms or annotated/re-interpreted glossary terms specific to this document are prefaced with a mark to denote the change or addition. Readers of this document are requested to pay special attention to such terms.

14.2. Glossary of Terms

Abuse of Privilege: When a user performs an unauthorized action that there are no software controls or site policies to prevent.

Application-Level Firewall: A firewall system in which traffic is provided by processes that maintain complete TCP connection state and sequencing. Application level firewalls often re-address traffic so that outgoing traffic appears to have originated from the firewall, rather than the internal host.

Authentication: The process of determining who or what is attempting to access a system.

Authentication Token: A portable device used for authenticating a user. Authentication tokens operate by challenge/response, time-based code sequences, or other techniques.

Authorization: The process of determining what types of activities are permitted. Usually, authorization is in the context of authentication: once you have authenticated a user, they may be authorized different types of access or activity.

Bastion Host: A system that has been hardened to resist attack, and which is installed on a network in such a way that it is expected to potentially come under attack. Bastion hosts are often components of firewalls, or may be "outside" Web servers or public access systems. Generally, a bastion host is running some form of general purpose operating system (e.g., UNIX, VMS, WNT, etc.) rather than a ROM-based or firmware operating system.

Challenge/Response: An authentication technique whereby a server sends a random challenge to the user, who computes a response using some form of authentication token.

Checksum: A one-way function applied to a file to produce a unique "fingerprint" of the file for later reference. Checksum systems are a primary means of detecting filesystem tampering on UNIX.

Chroot: A technique under UNIX whereby a process is permanently restricted to an isolated subset of the filesystem.

Data Driven Attack: A form of attack in which the attack is encoded in innocuous-seeming data which is executed by a user or other software to implement an attack. In the case of firewalls, a data driven attack is a concern since it may get through the firewall in data form and launch an attack against a system behind the firewall.

Defense in Depth: The security approach whereby each system on the network is secured to the greatest possible degree.

DNS spoofing: Assuming the DNS name of another system by either corrupting the name service cache of a victim system, or by compromising a domain name server for a valid domain.

Dual Homed Gateway: A dual homed gateway is a system that has two or more network interfaces, each of which is connected to a different network. In firewall configurations, a dual homed gateway usually acts to block or filter some or all of the traffic trying to pass between the networks.

Encrypting Router: see Tunneling Router and Virtual Network Perimeter.

Firewall: A system or combination of systems that enforces a boundary between two or more networks.

Host-based Security: The technique of securing an individual system from attack. Host based security is operating system and version dependent.

Insider Attack: An attack originating from inside a protected network.

Intrusion Detection: Detection of break-ins or break-in attempts either manually or via software expert systems that operate on logs or other information available on the network.

IP Spoofing: An attack whereby a system attempts to illicitly impersonate another system by using its IP network address.

IP Splicing: An attack whereby an active, established, session is intercepted and co-opted by the attacker. IP Splicing attacks may occur after an authentication has been made, permitting the attacker to assume the role of an already authorized user. Primary protections against IP Splicing rely on encryption at the session or network layer.

Least Privilege: Designing operational aspects of a system to operate with a minimum amount of system privilege. This reduces the authorization level at which various actions are performed and decreases the chance that a process or user with high privileges may be caused to perform unauthorized activity resulting in a security breach.

Logging: The process of storing information about events that occurred on the firewall or network.

Log Retention: How long audit logs are retained and maintained.

Log Processing: How audit logs are processed, searched for key events, or summarized.

Network-Level Firewall: A firewall in which traffic is examined at the network protocol packet level.

Perimeter-based Security: The technique of securing a network by controlling access to all entry and exit points of the network.

Policy: Organization-level rules governing acceptable use of computing resources, security practices, and operational procedures.

Proxy: A software agent that acts on behalf of a user. Typical proxies accept a connection from a user, make a decision as to whether or not the user or client IP address is permitted to use the proxy, perhaps does additional authentication, and then completes a connection on behalf of the user to a remote destination.

Screened Host: A host on a network behind a screening router. The degree to which a screened host may be accessed depends on the screening rules in the router.

Screened Subnet: A subnet behind a screening router. The degree to which the subnet may be accessed depends on the screening rules in the router.

Screening Router: A router configured to permit or deny traffic based on a set of permission rules installed by the administrator.

Trojan Horse: A software entity that appears to do something normal but which, in fact, contains a trapdoor or attack program.

Tunneling Router: A router or system capable of routing traffic by encrypting it and encapsulating it for transmission across an untrusted network, for eventual de-encapsulation and decryption.

Social Engineering: An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems.

Virtual Network Perimeter: A network that appears to be a single protected network behind firewalls, which actually encompasses encrypted virtual links over untrusted networks.

Virus: A self-replicating code segment. Viruses may or may not contain attack programs or trapdoors.

* [term: this is a sample annotated or new term]

15. References to additional documents

[Optional: References to books, marketing literature, trade publications, magazine articles, white papers, etc.]

16. Appendices

[Optional: Product costs, configurations and options]

17. Functional Summary Program: Contacts

[This section is boilerplate to be included with all firewall product summaries verbatim and is not to be altered or deleted.]

17.1. For more information

How to contact the functional summary program group, for more information or to participate:

Email:

Web:

17.2. Sponsorship of the firewall product functional summary program

The following members of the security community have generously endorsed and agreed to voluntarily support this program:

[list]

(C)Copyright, 1995, Marcus J. Ranum, Information Works! Inc. All rights reserved. This document may be freely for review in its draft form, as long as this copyright message remains intact.

[This section should contain your corporate copyright statement] Format version: 1.0 DRAFT