Cisco ASA 5500 Series Adaptive Security Appliances

Table Of Contents

Security Target for Cisco PIX Security Appliances 515/515E, 525, 535 and Cisco Adaptive Security Appliances 5510, 5520, and 5540, Version 1.0

Contents

Security Target Introduction

Security Target Identification

Security Target Overview

CC Conformance

Related Documents

Conventions

TOE Description

Overview

Physical Boundaries

Logical Scope and Boundaries

Single or Multiple Context

Routed or Transparent Mode

Management

Audit

Outside Scope

PP Conformance

Assurance Requirements

TOE Security Environment

Assumptions

Threats to the Security of the TOE

Threats to the Security of the Environment

Organizational Security Policies

Security Objectives

Security Objectives for the TOE

Security Objectives for the Environment

IT Security Requirements

TOE Security Functional Requirements

Security Audit

Cryptographic Operation

User Data Protection

Identification and Authentication

Security Management

Protection of the TSF

TOE Environment Security Functional Requirements

TOE Security Assurance Requirements

Configuration Management

Delivery and Operation

Development

Guidance Documents

Life Cycle Support

Tests

Vulnerability Assessment

TOE Summary Specification

TOE Security Functions

Security Management Function

Audit Function

Information Flow Control Function

Identification and Authentication Function

Protection Function

Clock Function

Assurance Measures

Protection Profile Claims

Environment Rationale

Objectives Rationale

Security Functional Requirements Rationale

Security Assurance Requirements Rationale

Rationale

Security Objectives Rationale

Rationale for Security Objectives for the Environment

TOE Security Functional Requirements (SFR) Rationale

TOE Environment Security Functions Rationale

Security Assurance Requirements (SAR) Rationale

Rationale for Not Satisfying All Dependencies

TOE Summary Specification Rationale

Mutually Supportive IT Security Functions

Glossary

Obtaining Documentation, Obtaining Support, and Security Guidelines

Security Target for Cisco PIX Security Appliances 515/515E, 525, 535 and Cisco Adaptive Security Appliances 5510, 5520, and 5540, Version 1.0

---

March 2007

Contents

This document includes the following sections:

•Security Target Introduction

•TOE Description

•TOE Security Environment

•Security Objectives

•IT Security Requirements

•TOE Summary Specification

•Protection Profile Claims

•Rationale

•Glossary

•Obtaining Documentation, Obtaining Support, and Security Guidelines

Security Target Introduction

This section includes the following topics:

•Security Target Identification

•Security Target Overview

•CC Conformance

•Related Documents

•Conventions

Security Target Identification

TOE Identification: Cisco PIX Security Appliances 515/515E, PIX 525, PIX 535 and Adaptive Security Appliances 5510, ASA 5520 and ASA 5540, Version 7.0(6).

ST Identification: Security Target for Cisco PIX Security Appliances 515/515E, PIX 525, PIX 535 and Cisco Adaptive Security Appliances 5510, ASA 5520 and ASA 5540, Version 1.0, March 2007.

Assurance Level: Evaluation Assurance Level (EAL) 4 augmented with Common Criteria (CC) component ALC_FLR.1.

ST Author: Cisco Systems, 170 West Tasman Drive, San Jose CA 95124-1706.

Keywords: Firewall, Packet Filtering, Application-level.

CC Identification: Common Criteria for Information Technology Security Evaluation, Version 2.2, January 2004, plus applicable CCIMB and US National interpretations up to 25 March 2004. Where specific changes result from application of an interpretation or precedent, this is noted in the security target.

Security Target Overview

The Cisco PIX Security Appliance and the Cisco ASA Adaptive Security Appliance are stateful packet filtering firewalls. A stateful packet filtering firewall controls the flow of IP traffic by matching information contained in the headers of connection-oriented or connectionless IP packets against a set of rules specified by the firewall's authorized administrator. This header information includes source and destination host (IP) addresses, source and destination port numbers, and the transport service application protocol (TSAP) held within the data field of the IP packet. Depending upon the rule and the results of the match, the firewall either passes or drops the packet. The stateful firewall remembers the state of the connection from information gleaned from prior packets flowing on the connection and uses it to regulate current packets. The packet will be denied if the security policy is violated.

In addition to IP header information, Cisco PIX and ASA appliances mediate information flows on the basis of other information, such as the direction (incoming or outgoing) of the packet on any given firewall network interface. For connection-oriented transport services, the firewall either permits connections and subsequent packets for the connection or denies the connection and subsequent packets associated with the connection.

CC Conformance

The TOE is Part 2 conformant, Part 3 conformant, and meets the requirements of EAL 4 augmented with the CC component, ALC_FLR.1.

Related Documents

[FWPP] "U.S. Department of Defense Application-level Firewall Protection Profile for Medium Robustness Environments," Version 1.0, June 28, 2000.

[FIPS140] "Security Engineering Requirements for Cryptographic Modules," FIPS 140-1, National Institute of Standards and Technology, 11 January 1994, and "Security Engineering Requirements for Cryptographic Modules," FIPS 140-2, National Institute of Standards and Technology, 25 May 2001 with Change Notices (12-03-2002).

Conventions

The following conventions have been applied in this document:

•All requirements in this ST are reproduced relative to the requirements defined in [FWPP].

•Security Functional Requirements-Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: assignment, selection, refinement and iteration.

–The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is denoted by bold text. For an example, see FMT_SMR.1 in this security target.

–The selection operation is used to select one or more options provided by the CC in stating a requirement. Selections are denoted by italicized text. For an example, see FDP_RIP.1 in this security target.

–The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignment is indicated by showing the value in square brackets, [assignment_value]. For an example, see FIA_AFL.1 in this security target.

–The iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing the iteration number in parenthesis following the component identifier, (iteration_number). For example, see FMT_MSA in this security target.

Underlining is used to identify operations completed in the ST, to distinguish them from those completed in [FWPP].

Other sections of the ST use boldface and italics to highlight text of special interest, such as captions.

TOE Description

This section includes the following topics:

•Overview

•Physical Boundaries

•Logical Scope and Boundaries

•PP Conformance

•Assurance Requirements

Overview

This section presents an overview of the Cisco PIX Security Appliance (PIX) and Adaptive Security Appliance (ASA), Version 7.0(6) to assist potential users in determining whether they meet their needs. The appliances control the flow of Internet Protocol (IP) traffic (datagrams) between network interfaces. The appliances are provided on a number of platforms. The PIX platforms included within the scope of this evaluation are PIX 515/515E, PIX 525, and PIX 535. The ASA platforms included within the scope of this evaluation are ASA 5510, ASA 5520, and ASA 5540. From this point forward, these platforms will be referred to as the Target of Evaluation (TOE).

The PIX and ASA (the TOE) are purpose-built hardware devices that use an Intel processor in all models.

The PIX runs the Cisco Secure PIX Security Appliance software image Version 7.0(6), and the ASA runs the Cisco Adaptive Security Appliance software image Version 7.0(6). These software images are identical.

The TOE provides a single point of defense as well as controlled and audited access to services between networks by permitting or denying the flow of information traversing the appliance.

Figure 1 TOE Physical Boundary and Illustrative Network Connections

Physical Boundaries

The TOE physical configuration includes one PIX or one ASA, which controls the flow of IP traffic between network interfaces, and an audit server used for audit storage and analysis. The TOE physical boundary includes these components (see Figure 1). The physical scope of the TOE includes the hardware and software elements identified in Table 1.

Table 1 TOE Component Identification 

Component	Description
Hardware	PIX 515 or 515E with of one of the following: •Single 433 MHz Intel Celeron processor (515E) •PI-MMX 200MHz processor (515) with up to six network interfaces PIX-VAC-PLUS Cryptographic accelerator card
	PIX 525 consisting of a 600 MHz Intel Pentium III processor with up to ten network interfaces PIX-VAC-PLUS Cryptographic accelerator card
	PIX 535 consisting of a 1000 MHz Intel Pentium III processor with up to 14 network interfaces PIX-VAC-PLUS Cryptographic accelerator card
	ASA 5510, ASA 5520, and ASA 5540 Each consisting of a 2 GHz Intel Celeron processor with up to nine network interfaces
	PC audit server platform
Software	Cisco Secure PIX Firewall Version 7.0(6)
	Windows 2000 Professional Service Pack 3 (including hotfix Q326886) or Windows XP Professional, Service Pack 2 (including hotfixes 896423, 899587, 899588, 896422, 890859, 873333, 885250, 888302, 885835, and 907865) with Service Pack 2 (for audit server)
	PIX Firewall Syslog Server (PFSS) 5.1(3)

All appliances are configurable with additional modules. As well as the built-in network interfaces, three types of network module are supported. The network modules supported in this evaluation are:

PIX

•One-port 10/100 Module (part number PIX-1FE)

•Four-port 10/100 Module (part number PIX-4FE)

•One-port Gigabit Ethernet Module (part number PIX-1GE-66 (available only on the PIX 525 and 535)

ASA

•Four-port Gigabit Ethernet Security Services Module (part number ASA-SSM-4GE=)

All models are available with either AC or DC power. Because the power supplies do not provide any security enforcing functionality, the AC and DC-powered models are treated identically.

Other than the connection to the audit server, the physical boundaries of the TOE are the physical port connections on the TOE external casing. One such port is to connect to the management console. Management of the TOE may be conducted either from a directly connected console (shown in Figure 1), or from a network console linked via SSH. There are no constraints on the location of the network console. In both cases, the console must be physically protected.

Separate secure management networks are used (see DMZ1 and DMZ2 in Figure 1) for the audit and authentication servers.

The TOE includes a Windows 2000 or Windows XP server for the purpose of storing the audit data generated by the TOE. The certified versions of these operating systems, as listed in Table 2.1, must be used. This server may be combined with the network console if desired.

The TOE provides interconnections between two or more networks depending on the number of interface cards installed within the product. A combination of network cards can be installed in the PIX 515/515E, PIX 525, PIX 535, ASA 5510, ASA 5520, and ASA 5540. It is possible to identify each network interface as either internal or external. If an interface is identified as external then the network to which it attaches is classed as being outside of the firewall. If an interface is identified as an internal interface that the network to which it attaches is classed as being inside (or behind) the firewall. All networks inside (or behind) the firewall are protected by the TOE against those outside of the firewall. The TOE can provide protection between networks connecting to the different internal network interfaces of the TOE.

The TOE environment includes a commercially available, single-use TACACS+ or RADIUS authentication server.

All traffic between each network attached to the TOE must flow through the TOE to maintain security.

Logical Scope and Boundaries

The scope of the TOE includes the following security functions:

•Security management to enable, disable, or modify the behavior of the TOE

•Security auditing

•Information flow control between interfaces of the firewall

•Identification and authentication of administrators

•Provision of a secure multitasking environment with residual information protection and assured invocation of security functions

•Provision of accurate date and time information

This section includes the following topics:

•Single or Multiple Context

•Routed or Transparent Mode

•Management

•Audit

•Outside Scope

The TOE controls the flow of IP traffic (datagrams) between network interfaces by matching information contained in the headers of connection-oriented or connectionless IP packets against a set of rules specified by the firewall's authorized administrator. This header information includes source and destination host (IP) addresses, source and destination port numbers, and the transport service application protocol (TSAP) held within the data field of the IP packet. Depending upon the rule and the results of the match, the firewall either passes or drops the packet. In addition to IP header information, the TOE mediates information flows on the basis of other information, such as the direction (incoming or outgoing) of the packet on any given firewall network interface. For connection-oriented transport services, the firewall either permits connections and subsequent packets for the connection or denies the connection and subsequent packets associated with the connection.

The types of traffic through or to the TOE that are within the scope of the evaluation include, but are not limited to: Ethernet, ARP, CTIQBE, DNS, Echo, Finger, H.323, IP, ICMP, TCP, UDP, FTP, GTP, HTTP, ILS, MGCP, POP3, RSH, RTSP, Skinny, SIP, ESMTP, SunRPC, Telnet, TFTP and XDMCP. Application inspection is also provided within the TOE for the following protocols and applications: CTIQBE, H.323, ICMP, FTP, GTP, HTTP, ILS, MGCP, RSH, RTSP, Skinny, SIP, ESMTP, SunRPC, TFTP, and XDMCP.

The TOE allows for NAT. NAT is used to map IP addresses from an inside interface to an outside interface. Using this feature an IP address on an inside interface is mapped to range of global IP addresses that can be addressed from the outside. The feature can also be used in the opposite direction to map addresses from the outside interface to the inside interface. Port numbers can also be mapped in this way, and this function is often referred to as PAT.

Logical network interfaces may be mapped to physical interfaces on a one to one basis (inside, outside, and DMZ). The TOE also supports multiple logical networks on a single physical interface.

Single or Multiple Context

A security context is a collection of processes that exist to model the logical virtual firewall into the constraints of the hardware. Each security context (virtual device) is treated as a separate independent device with its own security policy, interfaces, administrators, and configuration file.

When the firewall is operating in single routed mode one instance of a security context is present and executing. When the firewall is configured in multiple-context mode multiple security contexts are executing simultaneously. Each context in multiple-context mode is made up of the same processes used in single routed mode, only multiple instances of those processes are executing. There is no difference between the processes that are running for a single instance of a context in single, routed mode or multiple-context mode. Multiple contexts are similar to having multiple stand-alone devices.

Routed or Transparent Mode

The security appliance can run in these two firewall modes:

•Routed mode

•Transparent mode

In routed mode, the security appliance is considered to be a router hop in the network. It can perform NAT between connected networks, and can use OSPF or passive RIP (in single context mode). Routed mode supports many interfaces. Each interface is on a different subnet. Interfaces can be shared between contexts.

In transparent mode, the security appliance acts like a "bump in the wire," or a "stealth firewall," and is not a router hop. The security appliance connects the same network on its inside and outside interfaces. No dynamic routing protocols or NAT are used. However, like routed mode, transparent mode also requires access lists to allow any traffic through the security appliance, except for ARP packets, which are allowed automatically. Transparent mode can allow certain types of traffic in an access list that is blocked by routed mode, including unsupported routing protocols. Transparent mode can also optionally use EtherType access lists to allow non-IP traffic. Transparent mode only supports two interfaces, an inside interface and an outside interface, in addition to a dedicated management interface, if available for your platform.

Management

The TOE can be managed by authorized administrators via a physically secure local connection. The firewall part of the TOE can also be managed remotely from a connected network, through use of a FIPS 140-2 approved encrypted link. The TOE (both firewall and audit server) supports the authentication of authorized administrators by means of user id and password, and, with support from the environment, supports the use of third-party, single-use authentication servers.

Audit

The PIX and ASA also interact with a Windows 2000 or Windows XP server running PIX Firewall Syslog Server (PFSS) for the purpose of storage and analysis of the audit data generated by the TOE.PFSS (for firewall logs) and Windows Event Viewer (for audit server logs) are the tools that are included as part of the TOE. Use of other tools is not addressed by the evaluation. Windows access controls will ensure that the integrity of the audit logs is not compromised by use of these tools. The PIX and ASA, through the export of audit data, support the capability to perform audit analysis. The audit server is on a separate trusted network and is accessible only by trusted administrators.

Outside Scope

Features that are outside the scope of the defined TOE Security Functions (TSF) and thus not evaluated are:

•RIP

•SNMP

•ASDM

•DHCP Server

•Virtual Private Networks

Besides these exceptions, all types of network traffic through and to the TOE are within the scope of the evaluation.

The external AAA server used provides single-use authentication is outside the scope of the TOE, although use made by the TOE of this server is within scope.

The TOE definition in this ST makes use of the following precedents under the CCEVS: PD-0113.

PP Conformance

The TOE functionality is specified to be consistent with the U.S. Department of Defense Application-level Firewall Protection Profile for Medium Robustness Environments, Version 1.0, June 28, 2000 [FWPP].

The ST includes all security functional requirements included in [FWPP] (as modified under PD-0115 and PD-0026).

Assurance Requirements

The TOE is designed to meet the EAL4 assurance requirements, augmented with ALC_FLR.1.

TOE Security Environment

This section includes the following topics:

•Assumptions

•Threats to the Security of the TOE

•Threats to the Security of the Environment

•Organizational Security Policies

Assumptions

Table 2 lists the assumptions for the TOE security environment, which are the same as those for the [FWPP].

Table 2 Assumptions

No.	Assumption Name	Description
1	A.PHYSEC	The TOE is physically secure.
2	A.PROTECTPF	The PFSS is to be connected to the firewall such that the network interface of the PFSS is only accessible by the TSF. This may be achieved by either directly connecting the PFSS to the firewall, or indirectly over the trusted network. This protection of the PFSS network interface is required by PD-0113.
3	A.MODEXP	The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered moderate.
4	A.GENPUR	There are no general-purpose computing capabilities (for example, the ability to execute arbitrary code or applications) and storage repository capabilities on the TOE.
5	A.PUBLIC	The TOE does not host public data.
6	A.NOEVIL	Authorized administrators are non-hostile and follow all administrator guidance; however, they are capable of error.
7	A.SINGEN	Information can not flow among the internal and external networks unless it passes through the TOE.
8	A.DIRECT	Human users within the physically secure boundary protecting the TOE may attempt to access the TOE from some direct connection (for example, a console port) if the connection is part of the TOE.
9	A.NOREMO	Human users who are not authorized administrators can not access the TOE remotely from the internal or external networks.
10	A.REMACC	Authorized administrators may access the TOE remotely from the internal and external networks.

Threats to the Security of the TOE

Table 3 defines security threats for the TOE. The asset under attack is the information that transits the TOE in accordance with the security policy, as represented by the TOE rule set. In general, the threat agent includes, but is not limited to: 1) people with TOE access who are expected to possess "low" expertise, resources, and motivation, or 2) failure of the TOE.

Table 3 Threats for the TOE 

No.	Threat Name	Threat Description
1	T.NOAUTH	An unauthorized person may attempt to bypass the security of the TOE, so as to access and use security functions and/or non-security functions provided by the TOE.
2	T.REPEAT	An unauthorized person may repeatedly try to guess authentication data in order to use this information to launch attacks on the TOE.
3	T.REPLAY	An unauthorized person may use valid identification and authentication data obtained to access functions provided by the TOE.
4	T.ASPOOF	An unauthorized person on an external network may attempt to by-pass the information flow control policy by disguising authentication data (for example., spoofing the source address) and masquerading as a legitimate user or entity on an internal network.
5	T.MEDIAT	An unauthorized person may send impermissible information through the TOE which results in the exploitation of resources on the internal network.
6	T.OLDINF	Because of a flaw in the TOE functioning, an unauthorized person may gather residual information from a previous information flow or internal TOE data by monitoring the padding of the information flows from the TOE.
7	T.PROCOM	An unauthorized person or unauthorized external IT entity may be able to view, modify, and/or delete security related information that is sent between a remotely located authorized administrator and the TOE.
8	T.AUDACC	Persons may not be accountable for the actions that they conduct because the audit records are not reviewed, thus allowing an attacker to escape detection.
9	T.SELPRO	An unauthorized person may read, modify, or destroy security-critical TOE configuration data.
10	T.AUDFUL	An unauthorized person may cause audit records to be lost or prevent future records from being recorded by taking actions to exhaust audit storage capacity, thus masking an attacker's actions.
11	T.MODEXP	An attacker with low attack potential may attempt to bypass the TSF to gain access to the TOE or the assets it protects.

Threats to the Security of the Environment

This section defines the threats to the IT Environment, which are listed in Table 4. The asset under attack is the information transiting the TOE. In general, the threat agent includes, but is not limited to: 1) people with TOE access who are expected to possess "average" expertise, few resources, and moderate motivation, or 2) failure of the TOE.

Table 4 Threats to Security for the IT Environment

No.	Threat Name	Threat Description
1	T.TUSAGE	The TOE may be inadvertently configured, used and administered in an insecure manner by either authorized or unauthorized persons.

Organizational Security Policies

Table 5 lists the organizational security policies.

Table 5 Organizational Security Policies

No.	Policy Name	Policy Description
1	P.CRYPTO	Triple DES encryption (as specified in FIPS 46-3 [3]) or AES encryption (as specified in FIPS 197) must be used to protect remote administration functions, and the associated cryptographic module must comply, at a minimum, with FIPS 140-1 (level 1) or FIPS 140-2 (level 1).

Security Objectives

This section includes the following topics:

•Security Objectives for the TOE

•Security Objectives for the Environment

Security Objectives for the TOE

Table 6 lists security objectives for the TOE.

Table 6 Security Objectives for the TOE 

No.	Objective Name	Objective Description
1	O.IDAUTH	The TOE must uniquely identify and authenticate the claimed identity of all users, before granting a user access to TOE functions.
2	O.SINUSE	The TOE must prevent the reuse of authentication data for users attempting to authenticate at the TOE from a connected network.
3	O.MEDIAT	The TOE must mediate the flow of all information between clients and servers located on internal and external networks governed by the TOE, disallowing passage of non-conformant protocols and ensuring that residual information from a previous information flow is not transmitted in any way.
4	O.SECSTA	Upon initial start-up of the TOE or recovery from an interruption in TOE service, the TOE must not compromise its resources or those of any connected network.
5	O.ENCRYP	The TOE must protect the confidentiality of its dialogue with an authorized administrator through encryption, if the TOE allows administration to occur remotely from a connected network.
6	O.SELPRO	The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functions.
7	O.AUDREC	The TOE must provide a means to record a readable audit trail of security-related events, with accurate dates and times, and a means to search and sort the audit trail based on relevant attributes.
8	O.ACCOUN	The TOE must provide user accountability for information flows through the TOE and for authorized administrator use of security functions related to audit.
9	O.SECFUN	The TOE must provide functionality that enables an authorized administrator to use the TOE security functions, and must ensure that only authorized administrators are able to access such functionality.
10	O.LIMEXT	The TOE must provide the means for an authorized administrator to control and limit access to TOE security functions by an authorized external IT entity.
11	O.EAL	The TOE must be structurally tested and shown to be resistant to obvious vulnerabilities.

Security Objectives for the Environment

Table 7 lists security objectives for the IT environment.

Table 7 Security Objectives for the IT Environment

No.	Objective Name	Objective Description
1	OE.IDAUTH	The claimed identity of a remote user must be uniquely identified and authenticated, before granting the user access to TOE functions or, for certain specified services, to a connected network. Note: The objective IDAUTH is present for both the TOE and the TOE environment. This reflects the use of an authentication server in the environment to generate authentication credentials where single-use authentication is applied for remote users.
2	OE.SINUSE	The reuse of authentication data must be prevented for users attempting to authenticate at the TOE from a connected network.
3	OE.PHYSEC	The TOE and its operating environment are physically secure, and the network interface of the PFSS is only accessible by the TSF.
4	OE.MODEXP	The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered moderate.
5	OE.GENPUR	There are no general-purpose computing capabilities (for example, the ability to execute arbitrary code or applications) and storage repository capabilities on the TOE.
6	OE.PUBLIC	The TOE and the authentication server do not host public data.
7	OE.NOEVIL	Authorized administrators are non-hostile and follow all administrator guidance; however, they are capable of error.
8	OE.SINGEN	Information can not flow among the internal and external networks unless it passes through the TOE.
9	OE.DIRECT	Human users within the physically secure boundary protecting the TOE may attempt to access the TOE from some direct connection (for example, a console port) if the connection is part of the TOE.
10	OE.NOREMO	Human users who are not authorized administrators can not access the TOE remotely from the internal or external networks.
11	OE.REMACC	Authorized administrators may access the TOE remotely from the internal and external networks.
12	OE.GUIDAN	The TOE must be delivered, installed, administered, and operated in a manner that maintains security.
13	OE.ADMTRA	Authorized administrators are trained as to establishment and maintenance of security policies and practices.

IT Security Requirements

This section includes the following topics:

•TOE Security Functional Requirements

•TOE Environment Security Functional Requirements

•TOE Security Assurance Requirements

TOE Security Functional Requirements

All security functional requirements are drawn from Part 2 of the CC. They are repeated in Table 8 in the ST to demonstrate the refinements. See Conventions for the conventions used for refinements.

This section includes the following topics:

•Security Audit

•Cryptographic Operation

•User Data Protection

•Identification and Authentication

•Security Management

•Protection of the TSF

Table 8 TOE Security Functional Requirements 

Security Functional Requirements Class	Security Functional Requirements Components
Security Audit (FAU)	Audit data generation (FAU_GEN.1)
	Audit review (FAU_SAR.1)
	Selectable audit review (FAU_SAR.3)
	Protected audit trail storage (FAU_STG.1)
	Prevention of audit data loss (FAU_STG.4)
Cryptographic Operation (FCS)	Cryptographic operation (FCS_COP.1)
User Data Protection (FDP)	Subset information flow control 1 (FDP_IFC.1)
	Subset information flow control 2 (FDP_IFC.1)
	Simple security attributes1 (FDP_IFF.1)
	Simple security attributes2 (FDP_IFF.1)
	Subset residual information protection (FDP_RIP.1)
Identification and Authentication (FIA)	Authentication failure handling (FIA_AFL.1)
	User attribute definition (FIA_ATD.1)
	Multiple authentication mechanisms (FIA_UAU.5)
	User identification before any action (FIA_UID.2)
Security Management (FMT)	Management of security functions behavior 1 (FMT_MOF.1)
	Management of security functions behavior 2 (FMT_MOF.1)
	Management of security attributes 1 (FMT_MSA.1)
	Management of security attributes 2 (FMT_MSA.1)
	Management of security attributes 3 (FMT_MSA.1)
	Management of security attributes4 (FMT_MSA.1)
	Static attribute initialization (FMT_MSA.3)
	Management of TSF data 1 (FMT_MTD.1)
	Management of TSF data 2 (FMT_MTD.1)
	Management of limits on TSF data (FMT_MTD.2)
	Specification of management functions (FMT_SMF.1)
	Security roles (FMT_SMR.1)
Protection of the TSF (FPT)	Non-bypassability of the TSP (FPT_RVM.1)
	TSF domain separation (FPT_SEP.1)
	Reliable time stamps (FPT_STM.1)

Security Audit

FAU_GEN.1 Audit data generation
Hierarchical to		No other components.
FAU_GEN.1.1		The TSF shall be able to generate an audit record of the following auditable events: a. Startup and shutdown of the audit functions. b. All auditable events for the not specified level of audit. c. [The events in Table 9].
FAU_GEN.1.2		The TSF shall record within each audit record at least the following information: a. Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event. b. For each audit event type, based on the auditable event definitions of the functional components included in the ST, [information specified in column three of Table 9].
Dependencies		FPT_STM.1 Reliable time stamps

Table 9 Auditable Events 

Functional Component	Auditable Event	Additional Audit Record Contents
FCS_COP.1	Success and failure, and the type of cryptographic operation	The identity of the external IT entity attempting to perform the cryptographic operation.
FDP_IFF.1	All decisions on requests for information flow.	The presumed addresses of the source and destination subject.
FIA_AFL.1	The reaching of the threshold for unsuccessful authentication attempts and the subsequent restoration by the authorized administrator of the user`s capability to authenticate.	The identity of the offending user and the authorized administrator.
FIA_UAU.5	The final decision on authentication.	The user identity and the success or failure of the authentication.
FIA_UID.2	All use of the user identification mechanism.	The user identities provided to the TOE.
FMT_MOF.1	Use of the functions listed in this requirement pertaining to audit.	The identity of the authorized administrator performing the operation.
FMT_SMR.1	Modifications to the group of users that are part of the authorized administrator role. Unsuccessful attempts to authenticate the authorized administrator.	The identity of the authorized administrator performing the modification and the user identity being associated with the authorized administrator role. The user identity and the role.
FPT_STM.1	Changes to the time.	The identity of the authorized administrator performing the operation.

Application Note: The boldface text in Table 9 is an addition to the CC Part 2 requirement.

FAU_SAR.1 Audit review
	Hierarchical to	No other components.
FAU_SAR.1.1		The TSF shall provide [an authorized administrator] with the capability to read [all audit trail data] from the audit records.
FAU_SAR.1.2		The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
Dependencies		FAU_GEN.1 Audit data generation

FAU_SAR.3 Selectable audit review
Hierarchical to		No other components.
FAU_SAR.3.1		The TSF shall provide the ability to perform searches and sorting of audit data based on [: a. User identity b. Presumed subject address c. Ranges of dates d. Ranges of times e. Ranges of addresses].
Dependencies		FAU_SAR.1 Audit review

FAU_STG.1 Protected audit trail storage
Hierarchical to		No other components.
FAU_STG.1.1 FAU_STG.1.2 Dependencies		The TSF shall protect the stored audit records from unauthorized deletion.
		The TSF shall be able to prevent modifications to the audit records.
		FAU_GEN.1 Audit data generation

FAU_STG.4 Prevention of audit data loss
Hierarchical to		FAU_STG.3
FAU_STG.4.1		The TSF shall prevent auditable events, except those taken by the authorized administrator and [shall limit the number of audit records lost] if the audit trail is full.
Dependencies		FAU_GEN.1 Audit data generation

Cryptographic Operation

FCS_COP.1 Cryptographic operation
Hierarchical to		No other components.
FCS_COP.1.1		The TSF shall perform [encryption of remote authorized administrator sessions] in accordance with a specified cryptographic algorithm: [Triple Data Encryption Standard (DES) as specified in FIPS PUB 46-3 and implementing any mode of operation specified in FIPS PUB 46-3 with Keying Option 1 (K1, K2, K3 are independent keys)] and cryptographic key sizes [that are 192 binary digits in length and Advanced Encryption Standard (AES), as specified in FIPS PUB 197 and cryptographic key sizes [that are 128, 192 or 256 binary digits in length] that meet the following: [FIPS PUB 46-3 with Keying Option 1 and FIPS PUB 140-1 (Level 1)].
Dependencies		[FDP_ITC.1 Import of user data without security attributes or: •FCS_CKM.1 Cryptographic key generation] •FCS_CKM.4 Cryptographic key destruction •FMT_MSA.2 Secure security attributes
Application Note		This requirement is applicable as the firewall part of the TOE includes the capability for the authorized administrator to perform security functions remotely from a connected network.

User Data Protection

FDP_IFC.1 (1) Subset information flow control
Hierarchical to		No other components.
FDP_IFC.1.1		The TSF shall enforce the [UNAUTHENTICATED SFP] on [: a. Subjects—Unauthenticated external IT entities that send and receive information through the TOE to one another. b. Information—Traffic sent through the TOE from one subject to another. c. Operation—Pass information].
Dependencies		FDP_IFF.1 Simple security attributes

FDP_IFC.1 (2) Subset information flow control
Hierarchical to		No other components.
FDP_IFC.1.1		The TSF shall enforce the [AUTHENTICATED SFP] on [: a. Subjects—A human user or external IT entity that sends and receives FTP and Telnet information through the TOE to one another, only after the human user initiating the information flow has authenticated at the TOE per FIA_UAU.5. b. FTP and Telnet traffic sent through the TOE from one subject to another. c. Operation—Initiate service and pass information].
Dependencies		FDP_IFF.1 Simple security attributes

FDP_IFF.1 (1) Simple security attributes
Hierarchical to		No other components.
FDP_IFF.1.1		The TSF shall enforce the [UNAUTHENTICATED SFP] based on the following types of subject and information security attributes: [ a. Subject security attributes: •Presumed address •No other subject security attributes b. Information security attributes: •Presumed address of source subject •Presumed address of destination subject •Transport layer protocol •TOE interface on which traffic arrives and departs •Service •No other information security attributes].
FDP_IFF.1.2		The TSF shall permit an information flow between a controlled subject and another controlled subject via a controlled operation if the following rules hold: a. [Subjects on an internal network can cause information to flow through the TOE to another connected network if the following are true: •The human user initiating the information flow authenticates according to FIA_UAU.5. •All the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the authorized administrator. •The presumed address of the source subject, in the information, translates to an internal network address. •The presumed address of the destination subject, in the information, translates to an address on the other connected network. b. Subjects on an external network can cause information to flow through the TOE to another connected network if the following are true: •All the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the authorized administrator. •The presumed address of the source subject, in the information, translates to an external network address. •The presumed address of the destination subject, in the information, translates to an address on the other connected network].
FDP_IFF.1.3		The TSF shall enforce the [none].
FDP_IFF.1.4		The TSF shall provide the following [none].
FDP_IFF.1.5		The TSF shall explicitly label an information flow based on the following rules: [none].
FDP_IFF.1.6		The TSF shall explicitly deny an information flow based on the following rules: [ a. The TOE shall reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network; b. The TOE shall reject requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an external IT entity on the external network; c. The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network; d. The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network; e. The TOE shall reject requests in which the subject specifies the route in which information shall flow en route to the receiving subject; and f. For application protocols supported by the TOE (for example, DNS, HTTP. SMTP, and POP3), the TOE shall deny any access or service requests that do not conform to its associated published protocol specification (for example RFC). This shall be accomplished through protocol filtering proxies that are designed for that purpose].
Application Notes		1. Rule 6 applies when an application-level proxy is provided for DNS, HTTP, SMTP and POP3. 2. NAT and PAT were specifically tested, even though they were not explicitly referenced in an SFR.
Dependencies		FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialization

FDP_IFF.1 (2) Simple security attributes
Hierarchical to		No other components.
FDP_IFF.1.1		The TSF shall enforce the [AUTHENTICATED SFP] based on the following types of subject and information security attributes: [ a. Subject security attributes: •Presumed address •No other subject security attributes b. Information security attributes: •User identity •Presumed address of source subject •Presumed address of destination subject •Transport layer protocol •TOE interface on which traffic arrives and departs •Service (that is, FTP and Telnet) •Security-relevant service command •No other information security attributes].
FDP_IFF.1.2		The TSF shall permit an information flow between a controlled subject and another controlled subject via a controlled operation if the following rules hold: [ a. Subjects on an internal network can cause information to flow through the TOE to another connected network if: •The human user initiating the information flow authenticates according to FIA_UAU.5. •All the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the authorized administrator. •The presumed address of the source subject, in the information, translates to an internal network address. •The presumed address of the destination subject, in the information, translates to an address on the other connected network. b. Subjects on an external network can cause information to flow through the TOE to another connected network if: •The human user initiating the information flow authenticates according to FIA_UAU.5. •All the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the authorized administrator. •The presumed address of the source subject, in the information, translates to an external network address •The presumed address of the destination subject, in the information, translates to an address on the other connected network].
FDP_IFF.1.3		The TSF shall enforce the [none].
FDP_IFF.1.4		The TSF shall provide the following [none].
FDP_IFF.1.5		The TSF shall explicitly label an information flow based on the following rules: [none].
FDP_IFF.1.6		The TSF shall explicitly deny an information flow based on the following rules: [ a. The TOE shall reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network. b. The TOE shall reject requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an external IT entity on the external network. c. The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network. d. The TOE shall reject requests for access or services, in which the information arrives on an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network]. e. The TOE shall reject requests in which the subject specifies the route in which information shall flow en route to the receiving subject. f. The TOE shall reject Telnet or FTP command requests that do not conform to generally accepted published protocol definitions (for example, RFCs). This must be accomplished through protocol filtering proxies designed for that purpose.
Dependencies		FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialization

FDP_RIP.1 Subset residual information protection
Hierarchical to		No other components.
FDP_RIP.1.1		The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to [all objects].
Dependencies		No dependencies

Identification and Authentication

FIA_AFL.1 Authentication failure handling
Hierarchical to		No other components.
FIA_AFL.1.1		The TSF shall detect when [a non-zero number determined by the authorized administrator] of unsuccessful authentication attempts occur related to [authorized TOE administrator access or authorized TOE IT entity access].
FIA_AFL.1.2		When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [prevent the offending external IT entity from successfully authenticating until an authorized administrator takes some action to make authentication possible for the external IT entity in question].