HP TippingPoint
Intrusion Prevention Systems
Security Target
Version 1.0
9 January 2015
Prepared for:
HP TippingPoint
14231 Tandem Blvd
Austin, TX 78728
USA
Prepared By:
Leidos
Common Criteria Testing Laboratory
6841 Benjamin Franklin Drive
Columbia, MD 21046
2
Table of Contents
1. SECURITY TARGET INTRODUCTION...........................................................................................................4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4
1.2 CONFORMANCE CLAIMS.................................................................................................................................4
1.3 CONVENTIONS ................................................................................................................................................5
1.4 GLOSSARY......................................................................................................................................................5
1.5 ABBREVIATIONS AND ACRONYMS..................................................................................................................5
2. TOE DESCRIPTION ..........................................................................................................................................8
2.1 TOE OVERVIEW .............................................................................................................................................8
2.2 TOE ARCHITECTURE....................................................................................................................................10
2.2.1 Deployment Architecture .....................................................................................................................10
2.2.2 Software Architecture ..........................................................................................................................11
2.2.3 Physical Boundaries ............................................................................................................................14
2.2.4 Logical Boundaries..............................................................................................................................16
2.2.5 Excluded Functionality........................................................................................................................17
2.3 TOE DOCUMENTATION ................................................................................................................................17
3. SECURITY PROBLEM DEFINITION ..........................................................................................................18
3.1 ASSUMPTIONS ..............................................................................................................................................18
3.2 THREATS ......................................................................................................................................................18
4. SECURITY OBJECTIVES ..............................................................................................................................19
4.1 SECURITY OBJECTIVES FOR THE TOE...........................................................................................................19
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ...................................................................19
5. IT SECURITY REQUIREMENTS..................................................................................................................20
5.1 EXTENDED COMPONENTS DEFINITION .........................................................................................................20
5.1.1 Intrusion Detection System (IDS) ........................................................................................................20
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................24
5.2.1 Security Audit (FAU) ...........................................................................................................................24
5.2.2 User Data Protection (FDP) ...............................................................................................................26
5.2.3 Identification and Authentication (FIA)...............................................................................................27
5.2.4 Security Management (FMT)...............................................................................................................27
5.2.5 Protection of the TOE Security Functions (FPT) ................................................................................28
5.2.6 Trusted Path/Channels (FTP)..............................................................................................................28
5.2.7 Intrusion Detection System (IDS) ........................................................................................................28
5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................30
5.3.1 Development (ADV).............................................................................................................................30
5.3.2 Guidance Documents (AGD) ...............................................................................................................32
5.3.3 Life-cycle Support (ALC).....................................................................................................................32
5.3.4 Security Target Evaluation (ASE)........................................................................................................34
5.3.5 Tests (ATE) ..........................................................................................................................................37
5.3.6 Vulnerability Assessment (AVA) ..........................................................................................................38
6. TOE SUMMARY SPECIFICATION..............................................................................................................39
6.1 TOE SECURITY FUNCTIONS..........................................................................................................................39
6.1.1 Security Audit.......................................................................................................................................39
6.1.2 Identification and Authentication ........................................................................................................42
6.1.3 Intrusion Detection and Prevention.....................................................................................................44
6.1.4 Traffic Management.............................................................................................................................46
6.1.5 Security Management ..........................................................................................................................47
6.1.6 TSF Protection.....................................................................................................................................48
6.1.7 Trusted Path.........................................................................................................................................48
3
7. RATIONALE.....................................................................................................................................................50
7.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................50
7.2 SECURITY FUNCTIONAL REQUIREMENTS RATIONALE ..................................................................................53
7.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE....................................................................................56
7.4 REQUIREMENT DEPENDENCY RATIONALE....................................................................................................56
7.5 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................57
LIST OF TABLES
Table 1: TOE Security Functional Components.....................................................................................................24
Table 2: Auditable Events.........................................................................................................................................25
Table 3: IDS Events...................................................................................................................................................29
Table 4: EAL 3 augmented with ALC_FLR.2 Assurance Components ...............................................................30
Table 5: Default Console Settings.............................................................................................................................40
Table 6: Sorting Criteria...........................................................................................................................................41
Table 7: Auditable Event Categories .......................................................................................................................42
Table 8: Filter Categories .........................................................................................................................................44
Table 9: Management Functions and Role Restrictions.........................................................................................48
Table 10: Security Problem Definition to Security Objective Correspondence...................................................50
Table 11: Objectives to Requirement Correspondence..........................................................................................53
Table 12: Requirement Dependencies......................................................................................................................57
Table 13: Security Functions vs. Requirements Mapping .....................................................................................58
4
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE is HP TippingPoint Intrusion Prevention Systems,
comprising the S7500NX, S7100NX, S6200NX, S5200NX, S2600NX, S1400N, and S660N model appliances
running TippingPoint Operating System v3.7.2.
The Security Target contains the following additional sections:
 TOE Description (Section 2)—provides an overview of the TOE and describes the physical and logical
boundaries of the TOE
 Security Problem Definition (Section 3)—describes the assumptions, threats, and organizational security
policies that define the security problem to be addressed by the TOE and its environment
 Security Objectives (Section 4)—describes the objectives necessary to counter the defined threats and
satisfy the assumptions and organizational security policies
 IT Security Requirements (Section 5)—provides a set of security functional requirements to be met by the
TOE. The IT security requirements also provide a set of security assurance requirements that are to be
satisfied by the TOE
 TOE Summary Specification (Section 6)—describes the security functions of the TOE and how they satisfy
the security functional requirements
 Rationale (Section 7)—provides mappings and rationale for the security environment, security objectives,
security requirements, and security functions to justify their completeness, consistency, and suitability.
1.1 Security Target, TOE and CC Identification
ST Title – HP TippingPoint Intrusion Prevention Systems Security Target
ST Version – 1.0
ST Date – 9 January 2015
TOE Identification – HP TippingPoint Intrusion Prevention Systems, comprising the S7500NX, S7100NX,
S6200NX, S5200NX, S2600NX, S1400N, and S660N model appliances running TippingPoint Operating System
v3.7.2
TOE Developer – HP TippingPoint
Evaluation Sponsor – HP TippingPoint
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4,
September 2012.
1.2 Conformance Claims
This ST and the TOE it describes are conformant to the following CC specifications:
 Common Criteria for Information Technology Security Evaluation Part 2: Security Functional
Components, Version 3.1, Revision 4, September 2012
 Part 2 Extended
 Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance
Components, Version 3.1, Revision 4, September 2012
 Part 3 Conformant
This ST and the TOE it describes are conformant to the following package:
 EAL3 Augmented (ALC_FLR.2).
5
1.3 Conventions
The following conventions have been applied in this document:
 Security Functional Requirements—Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In this ST,
iteration is indicated by a number in parentheses placed at the end of the component. For
example, FMT_MTD.1(1) and FMT_MTD.1(2) indicate that the ST includes two iterations of the
FMT_MTD.1 requirement.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a
selection would be identified in italics and with embedded bold brackets (e.g., [[selected-
assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
 Extended Requirements (i.e., those not found in Part 2 of the CC) are identified with “_EXT” following the
new functional family and class identification. Example: Analyzer analysis (IDS_ANL_EXT.1)
 Other sections of the ST—Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.4 Glossary
This ST uses a number of terms that have a specific meaning within the context of the ST and the TOE. This
glossary provides a list of those terms and how they are to be understood within this ST.
Analyzer The function of an IDS that applies analytical processes to IDS data collected by Sensors or
Scanners in order to derive conclusions about potential or actual intrusions.
IDS/IPS Intrusion Detection System/Intrusion Prevention System—a combination of Sensors,
Scanners, and Analyzers that monitors an IT System for activity that may inappropriately
affect the IT System or its resources, and that can react appropriately if such activity is
detected.
IDS data Refers both to raw data collected by the TOE and to the results of analysis applied by the
TOE to that data.
IT System A combination of computers, network infrastructure devices, cables, etc.
Scanner A function of an IDS involving collection of static configuration information that might be
indicative of the potential for a future intrusion or the occurrence of a past intrusion of an IT
System. Although the IDS extended components defined in this ST cater for specification of
Scanner capabilities, the TOE operates as a Sensor rather than as a Scanner.
Sensor A function of an IDS involving collection of real-time events that may be indicative of
vulnerabilities in or misuse of IT System resources.
1.5 Abbreviations and Acronyms
The following abbreviations and acronyms are used in this document. A brief definition is provided for
abbreviations that are potentially unfamiliar, are specific to the TOE, or not obviously self-explanatory.
AES Advanced Encryption Standard
6
AH Authentication Header
CC Common Criteria
CFast A variant of the CompactFlash mass storage device format
CIDR Classless Inter Domain Routing
CLI Command Line Interface
CM Configuration Management
CMOS Complementary metal-oxide-semiconductor—a class of integrated circuits
DES Digital Encryption Standard
DSA Digital Signature Algorithm
FIPS Federal Information Processing Standard
FPGA Field Programmable Gate Array
GbE Gigabit Ethernet
GPRS General Packet Radio Service
GRE Generic Routing Encapsulation
GTP GPRS Tunneling Protocol
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICMP Internet Control Message Protocol
ID Identity or Identification
IM Instant Messaging
IP Internet Protocol
IT Information Technology
LC Local Connector—a type of optical fiber connector
LCD Liquid Crystal Display
LSM Local Security Manager—HP TippingPoint name for the IPS device GUI
MAC Media Access Control
NIST National Institute of Standards and Technology
P2P Peer-to-Peer
PC Personal Computer
POSIX Portable Operating System Interface for Unix
QSFP Quad Small Form-factor Pluggable—a compact, hot-pluggable transceiver used for data
communications applications
RC2 Rivest Cipher 2—a block cipher designed by Ron Rivest
RC4 Rivest Cipher 4—a block cipher designed by Ron Rivest
RSA Rivest-Shamir-Adleman—an asymmetric cryptographic algorithm
SAR Security Assurance Requirement
SFP Small Form-factor Pluggable—extractable optical or electrical transmitter/receiver module used in
telecommunications
SFP Security Function Policy
SFR Security Functional Requirement
SMS Security Management System—HP TippingPoint name for its architecture for managing multiple
IPS devices.
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SSH Secure Shell
SSL Secure Sockets Layer
ST Security Target
TCP Transmission Control Protocol
TOE Target of Evaluation
TOS TippingPoint Operating System—the software component of the HP TippingPoint IPS device
TSE Threat Suppression Engine—a logical component of the HP TippingPoint IPS device
TSF TOE Security Functionality
TSFI TSF Interface
UDP User Datagram Protocol
7
USGv6 United States Government v6—technical infrastructure developed by NIST to support wide-scale
adoption of IPv6 within the US government
ZPHA Zero Power High Availability
8
2. TOE Description
The Target of Evaluation (TOE) is the HP TippingPoint Intrusion Prevention System (IPS) devices, comprising the
S7500NX, S7100NX, S6200NX, S5200NX, S2600NX, S1400N, and S660N model appliances running
TippingPoint Operating System v3.7.2. The devices covered within the scope of the evaluation are network-based
intrusion prevention system appliances that are deployed in-line between pairs of networks.
The remainder of this section provides an overview of the TOE and a description of the TOE, including a
description of the physical and logical scope of the TOE.
2.1 TOE Overview
The HP TippingPoint IPS is a hardware-based intrusion prevention platform consisting of network processor
technology and HP TippingPoint’s own set of custom Field Programmable Gate Arrays (FPGAs). The TOE is a
hardware and software appliance that contains all the functions needed for intrusion prevention, including Internet
Protocol (IP) defragmentation, TCP flow reassembly, statistical analysis, traffic shaping, flow blocking, flow state
tracking and application-layer parsing of network protocols.
The primary function of the TOE is to protect networks from intrusion attempts by scanning network traffic,
detecting intrusion attempts, and reacting to detected intrusion attempts according to the filters and action sets with
which the device is configured.
A filter comprises rules and conditions used by the TOE to detect and handle malicious network traffic. Each filter
includes an action set that determines the TOE’s response when network traffic matches a filter.
The TOE provides intrusion prevention for the network according to the number of network connections and
hardware capabilities of the specific model. A single instance of the TOE can be installed at the perimeter of the
network, at the network core, on the customer’s Intranet, or in all three locations. HP TippingPoint IPS devices can
secure up to 24 network segments depending upon traffic volumes and the load capacity of the model.
A network segment is the portion of a computer network in which computers can access each other using a data link
layer protocol (e.g., in Ethernet, this would be the ability to send an Ethernet packet to others using their MAC
addresses). The TOE is installed in a network such that all traffic to and from a group of hosts is mediated by the
TOE. A segment uses two ports on the TOE and all traffic flows between connected networks through the TOE.
Members of the segment are hosts connected to those ports.
A segment is protected when its traffic passes through a pair of ports and the TOE applies filters that are configured
for that segment.
The TOE organizes filters into groups and categories of filter groups, based on the type of protection provided by
the filter. The TOE defines the following categories and filter groups:
Application Protection Filters—defend against known exploits and exploits that may take advantage of
known vulnerabilities targeting applications and operating systems. This category comprises the following
groups:
 Exploits
 Identity Theft
 Reconnaissance
 Security Policy
 Spyware
 Virus
 Vulnerabilities
9
Infrastructure Protection Filters—protect network bandwidth and network infrastructure elements such as
routers and firewalls from attack by using protocols and detecting statistical anomalies. This category comprises
the following groups:
 Network Equipment
 Traffic Normalization
Performance Protection Filters—block or rate-limit traffic from applications that can consume excessive
bandwidth, leaving network resources available for use by key applications. This category comprises the
following groups:
 IM (Instant Messaging)
 P2P (Peer-to-Peer)
 Streaming Media.
Category settings are used to assign global configuration settings to filters in a filter group. For example, if there is
no requirement to monitor P2P traffic, the category settings for the P2P filter group within the Performance
Protection category can be set to disable these filters. Category settings comprise the following global parameters:
 State—determines whether filters within the filter group are enabled or disabled. If a filter group is
disabled, all filters within the group are disabled
 Action Set—determines the action set that all filters within a group will execute when a filter match occurs.
It is also possible to override category settings on individual filters by editing the filter to define custom settings.
Each action set can include a set of recipients (termed “notification contacts”) to receive alerts when the device
detects and responds to traffic. A notification contact can be: a remote syslog server; an email address; an SNMP
server; or the TOE’s management GUI. The TOE also enables the administrator to set limits and exceptions for
filters, which apply filters to specific IP addresses or exclude traffic from filtering based on source and destination
IP addresses.
The TOE manages filter behavior using a mechanism known as Adaptive Filtering. This works by monitoring each
filter and identifying any filter suspected of causing congestion. Any filter identified in this fashion is handled in one
of two ways, depending on how global or filter-level Adaptive Filtering is configured:
 Automatic Mode—enables the TOE to automatically disable the identified filter and generate a system
message
 Manual—enables the TOE to generate a system message regarding the identified filter. However, the filter
is not disabled. Adaptive Filtering should be configured for this mode in the evaluated configuration to
prevent filters being automatically disabled.
The TOE uses Security Profiles to define the traffic that it monitors and the filters that it applies. Traffic monitoring
is based on incoming and outgoing port pairs. The default filtering configuration can be used to protect the segment
or it can be customized as necessary. The segment specifies both the port and the traffic direction, allowing separate
Security Profiles to be defined for traffic in and out of a port. The default Security Profile is set to ANY incoming
ports and ANY outgoing ports, with all filters configured with their default settings (which could be to block or
permit traffic).
In addition to IPS filters (which are also identified as ‘Digital Vaccine’ filters in the TOE documentation1
), the TOE
provides Traffic Management Profiles that allow traffic management filters to be configured and applied to traffic
on virtual segments. These allow the TOE to operate like a firewall.
The TOE supports IPv6 traffic inspection, and IPv6 options are available when configuring the Security Profile
options. Most IPS filters are compatible with both IPv4 and IPv6 traffic. The host management port, default
gateway, and management port routes can also be configured with IPv6 addresses.
1
Digital Vaccine®
is a registered trademark of TippingPoint Technologies, Inc. that refers to packages of filters
developed by TippingPoint and supplied with the HP TippingPoint IPS devices.
10
The TOE enables inspection of a wide range of tunneled traffic, including:
 Generic Routing Encapsulation (GRE)
 GTP (General Packet Radio Service (GPRS) Tunneling Protocol)
 Mobile IPv4 (IP-in-IP)
 IPv6, including 6-in-4, 4-in-6, and 6-in-6
 Tunnels up to 10 layers of tunneling or a header size of 256 bytes.
The NX devices included in the TOE also support inspection bypass rules for trusted traffic. Any network traffic
matching an inspection bypass rule is transmitted through the TOE without further inspection, either by traffic
management filters or IPS filters.
The TOE provides a Management Interface that enables authorized administrative users to access the security
management capabilities of the TOE and to view IPS data and audit logs. Authorized administrative users are
identified and authenticated by the TOE prior to gaining access to the TOE. The Management Interface provides two
methods for accessing the TOE—a Command Line Interface (CLI) and a web-based Graphical User Interface (GUI)
termed the Local Security Manager (LSM). The TOE supports secure access for both methods—SSHv2 for the CLI
and HTTPS for the LSM.
The HP TippingPoint IPS documentation describes mechanisms (termed “High Availability”) intended to support
continued flow of network traffic in the event of a system failure of the IPS device. These mechanisms are outside
the scope of the evaluation. However, the administrator needs to be aware of the following aspects of these
mechanisms, as they have implications for the secure operation of the TOE:
 Intrinsic Network High Availability—if the device detects certain failed conditions, it enters Layer-2
Fallback mode and either permits or blocks all traffic on each segment, depending on the Layer-2 Fallback
configuration setting for the segment. If the segment’s Layer-2 Fallback mode is “permit”, all traffic on the
segment passes through the device without inspection (i.e., the IPS capability of the device is disabled). In
the evaluated configuration, the Layer-2 Fallback mode should be set to “block” on each segment
 Zero-Power High Availability—allows network traffic to continue flowing without inspection (i.e., the IPS
capability of the device is disabled) if the device loses power. This mechanism should not be used in the
evaluated configuration.
2.2 TOE Architecture
2.2.1 Deployment Architecture
The HP TippingPoint IPS is designed for network transparency. The HP TippingPoint IPS is deployed into the
network to be monitored with no IP address or MAC address assigned, and immediately begins filtering unwanted
traffic.
The HP TippingPoint IPS is installed such that traffic to internal hosts flows through the IPS. This is shown in
Figure 1 as the “Sensing Interface”.
Each HP TippingPoint IPS device has two dedicated management interfaces—a 1GbE network port and an RJ-45
serial console port. These are represented in Figure 1 as the Management Interface. Administrators access the
Management Interface using a web-based interface—the Local Security Manager (LSM)—or via a command line
interface (CLI).
Once installed in the network, the TOE intercepts network packets as they pass through the TOE. These packets are
inspected to determine whether they are legitimate or malicious. This determination is made based upon filters
configured on the TOE.
The HP TippingPoint IPS also forms one component of the HP TippingPoint System, a suite of security products
that also includes the Security Management System (SMS) Secure Server, SMS Management Client, and Core
Controller. The SMS Secure Server is a hardware appliance that can be used to manage multiple HP TippingPoint
IPS appliances. The SMS Management Client is a Java-based application that provides a management interface to
11
the SMS Secure Server. The Core Controller is a hardware appliance that can be used to balance traffic loads across
multiple IPS appliances. These products are separately purchasable and are not required to support the operation of
the HP TippingPoint IPS in its evaluated configuration. As such, none of these other products are included within
the scope of this evaluation.
Cloud
TippingPoint TSE Sensing
Interface
NO IP Assigned
Firewall
IP: 1.1.1.1
LAN
IP: 1.1.1.x
TippingPoint
Management Interface
IP: 192.168.1.1
Management Client PC
IP: 192.168.1.2
Figure 1: Deployment Scenario
2.2.2 Software Architecture
The TOE software, identified as the TippingPoint Operating System (TOS), comprises IPS-specific software
developed by HP TippingPoint that runs on top of VxWorks v6.9.2, which is a real-time operating system made and
sold by Wind River Systems. The TOE software comprises the following major components:
 Operating System (OS)
 Threat Suppression Engine (TSE)
 Management Interface.
The OS provides a set of support services to both the TSE and Management Interface. Amongst other functions, the
OS provides services to utilize device hardware features (e.g., a reliable time stamping capability based upon a
CMOS clock). More information regarding OS functions is given in section 2.2.2.1.
An administrator initiates a connection with the Management Interface using either the HTTPS or SSH protocol.
Once identification and authentication have occurred, the administrator uses the Management Interface to configure
the TOE based on the access level associated with the administrator’s account.
12
Figure 2: TOE Architecture
2.2.2.1 Operating System
The OS component provides the basic execution environment for the IPS-specific software. The IPS-specific
software relies on the following OS services:
 Boot processing and system initialization
 File system services
 Process scheduling services
 POSIX library implementation
 Network and other hardware device drivers
 Real time clock
 Network protocol implementations
 Email client.
The file system service provides a layer of abstraction between various data elements and any external interfaces.
User authentication data (username and passwords) are stored in the file system and are not directly accessible from
the Management Interface. Additionally, filter data that is used by the TSE is also stored in the file system and is not
directly accessible from any external interface. The file system service is also used to store all audit data and to
ensure that it is not directly accessible from any external interface.
The OS is supplied as part of the TOE and only contains trusted processes. There are no external capabilities to alter
the function of the OS, or introduce any new processes.
2.2.2.2 Threat Suppression Engine
The main component of the IPS device is the Threat Suppression Engine (TSE), a custom engine designed to detect
and block a range of attacks at wire speeds. The TSE is a “flow” based network security engine. Each packet is
identified as a member of a flow. A flow can have one or more packets. Each flow is tracked in the “connection
table”. A flow is uniquely identified by the port it was received on and its packet header information:
 IP protocol (ICMP, TCP, UDP)
 source IP address
Data Network Interfaces
TSE
Management
Interface
Network
Network
Network
Network
Operating
System
TOE Boundary
Management
Client PC Management
Network
13
 source ports (TCP or UDP)
 destination IP address
 destination ports (TCP or UDP).
The TSE reconstructs and inspects flow payloads by parsing the traffic at the application layer. As each new packet
belonging to a flow arrives, the flow is re-evaluated for malicious content. When a flow is deemed malicious (by
matching a configured filter), the current packet and all subsequent packets pertaining to the flow are handled
according to the configured action (e.g., blocked). Once classified, each packet is inspected by the appropriate set of
protocol and application filters. Out of the box, the IPS will identify flows in asymmetric mode—meaning the IPS
only needs to see the transmit side or the receive side of a TCP connection (not both).
HP TippingPoint’s Digital Vaccine Labs develop the filters that are included in the Digital Vaccine package
provided as part of the TOE. The TOE provides the capability to update the Digital Vaccine package as new filters
become available. Updated filters can be downloaded directly to the TOE appliance from Digital Vaccine Labs
using a secure SSL tunnel. The filters are themselves encrypted and digitally signed. Use of this capability requires
the management network be able to connect to the Internet.
The TSE provides the functionality of a Sensor and Analyzer (see Section 1.4 Glossary). When intrusions are
detected, the TSE generates alarms, blocks flows and/or logs activity depending upon its configuration. Logged data
is stored and protected by the OS file system services. Logs are managed such that when the available storage
capacity is exhausted, the oldest log is overwritten.
Sensor Capabilities
The TSE is used to monitor network traffic. The traffic is inspected according to a set of predefined filters or
signatures. When network traffic that matches a particular filter is sensed, this component informs the notification
mechanism.
Analyzer Capabilities
The TOE performs statistical and signature-based analysis of the collected traffic against configured IPS filters. The
TOE additionally decodes protocol headers to support reconstructing fragmented packets or flows. Once decoded,
the TOE applies its filters to achieve desired protections for the protected network segments.
Within each analytical result, the following information is stored:
 Date and time of the result
 Type of result (message, policy ID, signature ID, and classification)
 Identification of data source
 Data destination
 Protocol
 Severity.
2.2.2.3 Management Interface
The TOE offers two methods for configuring, monitoring, and reporting on the IPS device. Both of these methods
are accessible through the secure management network connection, which protects all data transferred between the
TOE and the administrative user.
The Command Line Interface (CLI) is used to issue commands in the TippingPoint command language via a
command line prompt.
The TippingPoint Local Security Manager (LSM) manages the IPS via a web-based graphical user interface.
14
To access the security functions, users must authenticate by logging into the Management Interface with a username
and password. The username is used to identify the role of the user and the password to authenticate them. There are
three roles that can be assigned to a user:
 Super-user—full access to the TOE. This role is able to manage the users of the TOE and to view/modify
the configuration of the TOE and the logs
 Administrator—write access to the TOE. This role is able to view/modify the configuration of the TOE
(with the exception of managing user accounts) and the logs (with the exception of selection of auditable
events and viewing/clearing of the audit log)
 Operator—read-only access to the TOE. This role is able to view the system data logs (with the exception
of audit logs) and configuration of the TOE, but is not permitted to modify any information other than
his/her own password.
All security relevant and Management Interface actions are recorded in the Audit log. The Audit log records the
command that was executed, the username of the user who performed an action, the interface from which the user
logged in, such as the LSM or CLI, and a timestamp of when the action was performed. Storage services for the
Audit log are provided by the operating system file system services. The Management Interface also provides a
mechanism for administrators to review the contents of the audit trail.
2.2.3 Physical Boundaries
The physical boundary of the TOE is the HP TippingPoint IPS device (i.e., a S7500NX, S7100NX, S6200NX,
S5200NX, S2600NX, S1400N, or S660N model device).
The S1400N and S660N models each comprise a single chassis that is rack-mountable on a 19 or 23 inch rack and
takes up 2 rack units of space. The S660N supports up to 750Mbps of traffic across multiple copper and fiber
segments, while the S1400N supports up to 1.5 Gbps of traffic across multiple copper and fiber segments. Each
device provides the following external interfaces:
 10 1GbE copper ports paired into 5 1GbE segments
 10 1GbE fiber ports paired into 5 1GbE segments
 1 1GbE copper network management port
 1 RJ-45 console port
 1 interface for external Zero Power High Availability (ZPHA) device
 1 Compact Flash drive that provides a facility to store TSF data (such as logs, traffic threshold history,
persistent statistics, packet traces) for long term persistence or archiving purposes
 A Liquid Crystal Display (LCD) screen and associated keypad that can be used to initially configure the
appliance and to subsequently display basic configuration information (Note: use of the LCD/keypad,
either for initial configuration or for subsequent information display, is excluded from the scope of
evaluation).
The ports on the S1400N and S660N devices associated with the data networks, through which monitored traffic
flows, can be connected to either twisted pair (copper) networks or fiber optic networks. For twisted pair networks,
the Copper Segments interface is used via RJ45 connectors. For fiber networks, Small Form-factor Pluggable (SFP)
transceivers with Local Connector (LC) connectors are used. Both Single-Mode and Multi-Mode SFP fiber modules
are supported. Once connected, network traffic on these interfaces can be monitored by the TOE.
The HP TippingPoint NX-Platform devices are rack-mountable on a 19- or 23-inch rack and accommodate up to
four I/O modules, enabling the devices to be customized to suit the needs of the network in which they are deployed.
15
The following traffic throughputs are supported across multiple copper and fiber segments for each model.
Model Supported Throughput
TippingPoint S2600NX Up to 3 Gbps
TippingPoint S5200NX Up to 5 Gbps
TippingPoint S6200NX Up to 10 Gbps
TippingPoint S7100NX Up to 15 Gbps
TippingPoint S7500NX Up to 20 Gbps
The NX devices support both standard I/O modules and bypass I/O modules for fiber and copper components. Note,
however, that bypass I/O modules are excluded from the evaluation.
The following are the standard I/O modules supported by the NX devices in the evaluated configuration:
Module Name Ports Port Speed
HP 6-Segment Gig-T NX (Gig-T) 12 Copper 10/100/1000 Mbps
HP 6-Segment GbE SFP NX (SFP) 12 SFP 1 Gbps
HP 4-Segment 10GbE SFP+ NX (SFP+) 8 Fiber 10 Gbps
HP 1-Segment 40GbE QSFP+ NX (QSFP+) 2 Fiber 40 Gbps
Each NX device additionally provides the following external interfaces:
 1 1GbE copper network management port
 1 RJ-45 console port
 1 CFast card slot that provides a facility to store TSF data (such as logs, traffic threshold history, persistent
statistics, packet traces) for long term persistence or archiving purposes
 Status LEDs.
The network management port supports the connection of a management network hosting management client PCs
and the following optional servers: syslog; SMTP; SNMP. The network management port presents the LSM (over
HTTPS) and CLI (over SSHv2) administrative interfaces. Access to the LSM requires a browser on the management
client PC—the most recent version of Internet Explorer or Firefox is recommended. The CLI requires an SSH client
on the management client PC. Note that the LSM can also be accessed via HTTP and the CLI can be accessed via
Telnet, but use of HTTP and Telnet over the management network is excluded from the evaluated configuration.
The TOE’s HTTP and Telnet servers are disabled by default and should not be enabled.
The TOE can be configured to send alarms (i.e., notifications of detected malicious network traffic) to the following
external destination types: syslog server; email address (which requires an SMTP server); SNMP server. These
alarms are in addition to the alarms the TOE writes to the IDS data logs.
The management network, management client PCs, optional servers, and all software on these clients and servers are
in the operational environment of the TOE.
Additionally, a serial console port is provided to allow a local terminal to be connected. When connected, the CLI is
available on the local terminal. Communication between the local terminal and the serial console port is not
protected and so such connections should only be used when both the local terminal and the TOE are in the same
physically secure location.
In summary, use of the TOE may require the following components in its operational environment:
 Serial terminal client, connected via the serial console port, to support local management of the TOE via
the CLI
16
 Management client PCs, connected via the network management port, to support remote management of
the TOE. The management client PC in turn requires:
o A browser (latest version of Internet Explorer or Firefox recommended) to connect to the LSM;
and/or
o An SSHv2 client to connect to the CLI
 Syslog server, SMTP server, and/or SNMP server, connected via the network management port, to receive
alarms.
2.2.4 Logical Boundaries
This section summarizes the security functions provided by HP TippingPoint IPS devices.
2.2.4.1 Security Audit
The TOE is able to generate auditable events for the basic level of audit. It provides Super-users with the ability to
review audit records stored in the audit trail and prevents other administrative user roles from reviewing the audit
data. Super-users are able to select auditable events to be audited, based on event type. The audit records are stored
in the underlying file system, where they are protected from unauthorized modification and deletion. When the
space available for audit storage is exhausted, the oldest 50% of audit records are deleted and an audit record to this
effect is generated.
2.2.4.2 Identification and Authentication
The TOE identifies and authenticates all administrative users2
of the TOE before granting them access to the TOE.
The TOE associates a user identity, authentication data (password), and authorizations (or security role) with each
user. The TOE enforces minimum requirements for the construction of user passwords and provides a mechanism to
lock or disable a user account after a configured number of consecutive failed attempts to logon.
2.2.4.3 Intrusion Detection and Prevention
The TOE collects network traffic and subjects it to statistical and signature-based analysis, depending on configured
IPS filters. If the analysis of collected network traffic indicates a potential intrusion attempt, an action set associated
with the detecting filter is triggered. The action set determines if the traffic is permitted or blocked. If traffic is
permitted, an alert will be written to the IDS data log (specifically, the Alert log). If traffic is blocked, writing an
alert to the IPS data log (specifically, the Block log) is configurable—in the evaluated configuration, action sets that
block traffic must also be configured to generate an alert. In addition to writing to the IDS data log, the TOE can
generate alerts in the form of a notification to a syslog server, email address, or SNMP server. The TOE provides
capabilities for the administrative users to review the IDS data logs. The TOE protects the IDS data logs from
modification and deletion. When the space available for IDS data storage is exhausted, the oldest 50% of IDS data is
deleted and an audit record to this effect is generated.
2.2.4.4 Traffic Management
The TOE can be configured to operate as a firewall, blocking or permitting network traffic based on protocol or IP
address and port. Network traffic that is permitted based on traffic management filtering is still subject to IPS
filtering, unless the traffic management filter is configured to allow traffic through the device without IPS filtering.
On the NX models, inspection bypass rules can be configured that permit matching network traffic to pass through
the TOE without being subject to either traffic management or IPS filters.
2.2.4.5 Security Management
The TOE defines three security management roles: Super-user; Administrator; and Operator. The TOE provides the
security management functions to enable the administrative users to manage user accounts, audit data and audit
2
That is, those users who access the TOE for administrative purposes via the network management port or console
port. Since the TOE is invisible to users on the networks being monitored by the TOE, there is no concept of such
users being able or required to identify or authenticate themselves to the TOE.
17
configurations, security configuration data, traffic management filters, and IDS data collection, analysis, and
reaction. The Super-user role has full access to all management functions and data. The Administrator role is
restricted to managing IDS and traffic management filters and reviewing configuration and IDS data. The Operator
role is restricted to reviewing configuration and IDS data.
2.2.4.6 TSF Protection
The TOE includes its own time source for providing reliable time stamps that are used in audit records and stored
IDS data.
2.2.4.7 Trusted Path
The TOE provides a trusted path for remote administrative users of the TOE to communicate with the TOE. The
trusted path is implemented over the network management port using HTTPS for access to the LSM and SSHv2 for
access to the CLI. Remote users initiate the trusted path by establishing an HTTPS connection (using a supported
web browser) or SSH session (using an SSH client). The trusted path is used for initial authentication and all
subsequent administrative actions. The use of HTTPS or SSHv2 ensures all communication over the trusted path is
protected from disclosure and undetected modification.
The TOE supports a FIPS mode of operation and, when configured in FIPS mode, will allow only FIPS 140-2
approved cryptographic algorithms to be used. Note the TOE is not required to operate in FIPS mode to be in the
evaluated configuration—the choice to do so or not is left up to the customer.
2.2.5 Excluded Functionality
The following capabilities of the TOE are not included in the scope of the evaluation and no claims are made
regarding them:
 High availability capabilities
 Uploading and use of X.509 certificates to support checking of client certificates when connecting to the
LSM.
2.3 TOE Documentation
This section identifies the guidance documentation included in the TOE.
 HP TippingPoint IPS Command Line Interface Reference: TOS Version 3.7, 5998-1404, April 2014
 HP TippingPoint Local Security Manager User’s Guide: TOS Version 3.7, 5998-1405, April 2014
 Read Me First—Registering and Contacting Support, 5900-3703, Edition A1, February 2014
 HP TippingPoint—TippingPoint Operating System MIBs Guide: TOS Version 3.7, 5998-1407, April 2014
 HP TippingPoint N-Platform Hardware Installation and Safety Guide, 5900-2851, October 2013
 HP TippingPoint NX-Platform Hardware Installation and Safety Guide, 5998-1403, 2013
 HP TippingPoint NX-Platform Quick Start, 5998-3067, Edition A7, April 2014
 Quick Start TippingPoint N-Platform, 5998-1200, Edition A5, April 2014
 HP TippingPoint—TippingPoint Operating System V. 3.7.0 Release Notes, 5998-1406, April 2014
 Using the TippingPoint External Compact Flash Card, 5998-1202, November 2010.
18
3. Security Problem Definition
This section defines the security problem to be addressed by the TOE, in terms of threats to be countered by the
TOE or its operational environment, and assumptions about the intended operational environment of the TOE.
3.1 Assumptions
This section contains assumptions regarding the operational environment and the intended usage of the TOE.
A.ACCESS The TOE has access to all the IT System data it needs to perform its functions.
A.PROTECT The TOE hardware and software critical to security policy enforcement will be protected from
unauthorized physical modification.
A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the
security of the information it contains.
A.NOEVIL The authorized administrators are not careless, willfully negligent, or hostile, and will follow
and abide by the instructions provided by the TOE documentation.
3.2 Threats
The following are threats identified for the TOE and the IT System the TOE monitors.
T.COMPROMISE An unauthorized user may attempt to compromise the confidentiality or integrity of the data
collected and produced by the TOE by bypassing a security mechanism.
T.LOSSOF An unauthorized user may attempt to remove or destroy data collected and produced by the
TOE.
T.PRIVILEGE An unauthorized user may gain access to the TOE and exploit system privileges to gain access
to TOE security functions and data.
T.CONFIG An unauthorized user may inappropriately change the configuration of the TOE causing
potential intrusions to go undetected.
T.INFLUX An unauthorized user may cause malfunction of the TOE by creating an influx of data that the
TOE cannot handle.
T.ACCOUNT Unauthorized attempts to access TOE data or security functions may go undetected.
T.MISUSE Unauthorized accesses and activity indicative of misuse may occur on an IT System the TOE
monitors.
T.ACCIDENT Inadvertent activity and access may occur on an IT System the TOE monitors.
T.MALICE Malicious activity, such as introductions of Trojan horses and viruses, may occur on an IT
System the TOE monitors.
19
4. Security Objectives
This section identifies the security objectives of the TOE and its operational environment. The security objectives
identify the responsibilities of the TOE and its environment in addressing the security problem defined in Section 3.
4.1 Security Objectives for the TOE
The following are the TOE security objectives:
O.SENSOR The TOE shall collect IDS data in the form of network packets flowing between network
segments to which it is connected.
O.ANALYZER The TOE shall analyze collected IDS data in order to identify intrusion attempts and shall be
able to record the results of its analysis.
O.RESPONSE The TOE shall respond to intrusion attempts it identifies based on its configuration.
O.REVIEW The TOE shall provide capabilities for effective review of stored IDS data.
O.ADMIN The TOE shall include capabilities to enable effective management of its functions and data.
O.ACCESS The TOE shall restrict access to its management capabilities based on the authorization level
it assigns to identified and authenticated users.
O.I&A The TOE shall identify and authenticate users prior to allowing access to its functions and
data.
O.AUDIT The TOE shall generate audit records of security relevant events and provide capabilities for
effective review of stored audit records.
O.INTEGRITY The TOE shall protect stored audit records and IDS data from unauthorized modification or
deletion.
O.STORAGE The TOE shall provide capabilities to automatically manage stored audit records and IDS data
in the event that available storage space is exhausted.
O.TRAFFIC The TOE shall provide a capability to filter network traffic based on combinations of
protocol, IP address and port.
4.2 Security Objectives for the Operational Environment
The following are the security objectives for the operational environment of the TOE:
OE.INSTALL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and
operated in accordance with its supplied guidance documentation and in a manner which is
consistent with IT security.
OE.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE critical to security
policy are protected from any physical attack.
OE.PERSONNEL Those responsible for the TOE must ensure that personnel working as authorized
administrators have been carefully selected and trained for proper operation of the TOE.
OE.CONFID Those responsible for the TOE must ensure the operational environment provides capabilities
to protect the confidentiality of data communicated by the administrative users to the TOE.
20
5. IT Security Requirements
5.1 Extended Components Definition
5.1.1 Intrusion Detection System (IDS)
This ST defines a new functional class for use within this ST: Intrusion Detection System (IDS). This family of IDS
requirements was created to specifically address the data collected and analyzed by an IDS. The audit family of the
CC (FAU) was used as a model for creating these requirements. The purpose of this family of requirements is to
address the unique nature of IDS data and specify requirements for collecting, analyzing and reviewing IDS data.
5.1.1.1 IDS Data Collection (IDS_SDC_EXT)
This family defines requirements for being able to collect IDS data from targeted IT resources. It specifies
requirements for both a Sensor capability and a Scanner capability.
Management: IDS_SDC_EXT.1
The following actions could be considered for the management functions in FMT:
a) maintenance of the parameters that control IDS data collection.
Audit: IDS_SDC_EXT.1
There are no auditable events foreseen.
IDS_SDC_EXT.1: IDS data collection
Hierarchical to: No other components.
Dependencies: None
IDS_SDC_EXT.1.1 The TSF shall be able to collect the following information from targeted IT System
resource(s):
a) [selection: Start-up and shutdown, identification and authentication events,
data accesses, service requests, network traffic, security configuration changes,
data introduction, detected malicious code, access control configuration, service
configuration, authentication configuration, accountability policy configuration,
detected known vulnerabilities]; and
b) [assignment: other specifically defined events].
Application Note: The ST will define the IDS capabilities of the TOE. This requirement indicates
that the TOE must support at least a Sensor capability or a Scanner capability, by requiring the
TOE be able to collect information pertaining to at least one of the selections in bullet a above. A
Sensor would generally collect information pertaining to the following events in bullet a: start-up
and shutdown, identification and authentication events, data accesses, service requests, network
traffic, security configuration changes, and data introduction. The Scanner would generally
collect static configuration information which include the following events in bullet a: detected
malicious code, access control configuration, service configuration, authentication configuration,
accountability policy configuration, and detected known vulnerabilities. Malicious code includes
viruses, worms, simple Trojan horses, etc. Access control configuration includes access control
lists, search for writeable files and directories, etc. Service configuration includes identification of
network services and/or associated network ports, host services, versions of services, protocols
acknowledged by services, etc. Authentication configuration includes cracking passwords,
configuration settings (e.g., minimum password length, duration between allowed and required
password changes), acceptable authentication means (e.g., NTLM, kerberos), defined guest
accounts, account authorisations, etc. Accountability policy configuration includes size of audit
trails, whether audit is enabled, what to do when the audit trail fills, etc. Known vulnerabilities is
21
fairly open ended, but may include installed patches, checks for common or default configuration
errors, etc.
IDS_SDC_EXT.1.2 At a minimum, the TSF shall collect and record the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success
or failure) of the event; and
b) The additional information specified in the Details column of the following table.
Event Details
Start-up and shutdown None
Identification and authentication events User identity, location, source address, destination address
Data accesses Object identifier, requested access, source address, destination address
Service requests Specific service, source address, destination address
Network traffic Protocol, source address, destination address
Security configuration changes Source address, destination address
Data introduction Object identifier, location of object, source address, destination address
Detected malicious code Location, identification of code
Access control configuration Location, access settings
Service configuration Service identification (name or port), interface, protocols
Authentication configuration Account names for cracked passwords, account policy parameters
Accountability policy configuration Accountability policy configuration parameters
Detected known vulnerabilities Identification of the known vulnerability
Application Note: In the case where a Sensor is collecting host-based events, for the identification
and authentication event, the source address could be a subject IDS on a local machine and the
destination is defined by default. For the data access and data introduction events, the source
address could be filename and the destination address may be target location for the file.
5.1.1.2 IDS Analyzer (IDS_ANL_EXT)
This family defines requirements for being able to analyze collected IDS data.
Management: IDS_ANL_EXT.1
The following actions could be considered for the management functions in FMT:
b) maintenance of the parameters that control IDS data analysis.
Audit: IDS_ANL_EXT.1
There are no auditable events foreseen.
IDS_ANL_EXT.1: Analyzer analysis
Hierarchical to: No other components.
Dependencies: IDS_SDC_EXT.1
IDS_ANL_EXT.1.1 The TSF shall perform the following analysis function(s) on all IDS data received:
a) [selection: statistical, signature, integrity]; and
b) [assignment: other analytical functions].
Application Note: Statistical analysis involves identifying deviations from normal patterns of
behavior. For example, it may involve mean frequencies and measures of variability to identify
abnormal usage. Signature analysis involves the use of patterns corresponding to known attacks
22
or misuses of a System. For example, patterns of System settings and user activity can be
compared against a database of known attacks. Integrity analysis involves comparing System
settings or user activity at some point in time with those of another point in time to detect
differences.
IDS_ANL_EXT.1.2 The TSF shall record within each analytical result at least the following information:
a) Date and time of the result, type of result, identification of data source; and
b) [assignment: other security relevant information about the result].
Application Note: The analytical conclusions drawn by the analyser should both describe the
conclusion and identify the information used to reach the conclusion.
5.1.1.3 Intrusion Reaction (IDS_RCT_EXT)
This family defines requirements for being able to react to the results of IDS data analysis.
Management: IDS_RCT_EXT.1
The following actions could be considered for the management functions in FMT:
c) maintenance of the parameters that control IDS reaction.
Audit: IDS_RCT_EXT.1
There are no auditable events foreseen.
IDS_RCT_EXT.1: Analyzer reaction
Hierarchical to: No other components.
Dependencies: IDS_ANL_EXT.1
IDS_RCT_EXT.1.1 The TSF shall send an alarm to [assignment: alarm destination] and take [assignment:
appropriate actions] when an intrusion is detected.
Application Note: There must be an alarm, though the ST should refine the nature of the alarm
and define its target (e.g., administrator console, audit log). The Analyzer function may optionally
perform other actions when intrusions are detected; these actions should be defined in the ST. An
intrusion in this requirement applies to any conclusions reached by the Analyzer function related
to past, present, and future intrusions or intrusion potential.
5.1.1.4 IDS Data Review (IDS_RDR_EXT)
This family defines requirements for reviewing IDS data and restricting access to IDS data.
Management: IDS_RDR_EXT.1
The following actions could be considered for the management functions in FMT:
d) maintenance of the group of users with read access rights to the IDS data.
Audit: IDS_RDR_EXT.1
There are no auditable events foreseen.
IDS_RDR_EXT.1: Restricted data review
Hierarchical to: No other components.
Dependencies: IDS_SDC_EXT.1, IDS_ANL_EXT.1
IDS_RDR_EXT.1.1 The TSF shall provide [assignment: authorized users] with the capability to read
[assignment: list of IDS data] from the IDS data.
IDS_RDR_EXT.1.2 The TSF shall provide the IDS data in a manner suitable for the user to interpret the
information.
IDS_RDR_EXT.1.3 The TSF shall prohibit all users read access to the IDS data, except those users that have
been granted explicit read access.
23
Application Note: This requirement applies to authorized users of the TOE. The requirement is
left open for the writers of the ST to define which authorized users may access what IDS data.
5.1.1.5 IDS Data Storage (IDS_STG_EXT)
This family defines requirements for securely storing IDS data.
Management: IDS_STG_EXT.1, IDS_STG_EXT.2
There are no management actions foreseen.
Audit: IDS_STG_EXT.1, IDS_STG_EXT.2
There are no auditable events foreseen.
IDS_STG_EXT.1: Guarantee of IDS data availability
Hierarchical to: No other components.
Dependencies: IDS_SDC_EXT.1, IDS_ANL_EXT.1
IDS_STG_EXT.1.1 The TSF shall protect the stored IDS data from unauthorized deletion.
IDS_ STG_EXT.1.2 The TSF shall protect the stored IDS data from modification.
Application Note: Authorized deletion of data is not considered a modification of IDS data in this
context. This requirement applies to the actual content of the IDS data, which should be protected
from any modifications.
IDS_ STG_EXT.1.3 The TSF shall ensure that [assignment: metric for saving IDS data] IDS data will be
maintained when the following conditions occur: [selection: IDS data storage
exhaustion, failure, attack].
Application Note: The ST needs to define the amount of IDS data that could be lost under the
identified scenarios.
IDS_STG_EXT.2: Prevention of IDS data loss
Hierarchical to: No other components.
Dependencies: IDS_STG_EXT.1
IDS_STG_EXT.2.1 The TSF shall [selection: ignore IDS data, overwrite the oldest stored IDS data] and
send an alarm if the storage capacity has been reached.
Application Note: The ST must define what actions the TOE takes if the storage capacity has been
reached. Anything that causes the TOE to stop collecting and analyzing IDS data may not be the
best solution, as this will only affect the TOE and not the IT resource(s) the TOE is monitoring,
leaving those resources potentially open to intrusion.
24
5.2 TOE Security Functional Requirements
This section specifies the security functional requirements (SFRs) for the TOE. SFRs were drawn from Part 2 of the
Common Criteria v3.1 Revision 4, and from the extended components defined in Section 5.1 above.
Requirement Class Requirement Component
FAU: Security Audit FAU_GEN.1: Audit data generation
FAU_SAR.1: Audit review
FAU_SAR.2: Restricted audit review
FAU_SAR.3: Selectable audit review
FAU_SEL.1: Selective audit
FAU_STG.2: Guarantees of audit data availability
FAU_STG.4: Prevention of audit data loss
FDP: User Data Protection FDP_IFC.1: Subset information flow control
FDP_IFF.1: Simple security attributes
FIA: Identification and Authentication FIA_AFL.1: Authentication failure handling
FIA_ATD.1: User attribute definition
FIA_SOS.1: Verification of secrets
FIA_UAU.2: User authentication before any action
FIA_UID.2: User identification before any action
FMT: Security Management FMT_MOF.1: Management of security functions behavior
FMT_MTD.1: Management of TSF data
FMT_SMF.1: Specification of Management Functions
FMT_SMR.1: Security roles
FPT: Protection of the TOE Security Functions FPT_STM.1: Reliable time stamps
FTP: Trusted path/channels FTP_TRP.1: Trusted path
IDS: IDS Component requirements IDS_ANL_EXT.1: Analyzer analysis
IDS_RCT_EXT.1: Analyzer reaction
IDS_RDR_EXT.1: Restricted data review
IDS_SDC_EXT.1: IDS data collection
IDS_STG_EXT.1: Guarantee of IDS data availability
IDS_STG_EXT.2: Prevention of IDS data loss
Table 1: TOE Security Functional Components
5.2.1 Security Audit (FAU)
5.2.1.1 Audit Data Generation (FAU_GEN.1)
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [basic] level of audit; and
25
c) [no other specifically defined auditable events].
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 (if applicable), and the outcome
(success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional components
included in the PP/ST, [none].
Component Auditable Event
FAU_GEN.1 Start-up and shutdown of audit functions
FAU_SAR.1 Reading of information from the audit records
FAU_SAR.2 Unsuccessful attempts to read information from the audit records
FAU_SEL.1 All modifications to the audit configuration that occur while the audit collection functions are
operating
FAU_STG.4 Actions taken due to the audit storage failure.
FDP_IFF.1 All decisions on requests for information flow
FIA_AFL.1 Reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the
subsequent restoration to the normal state.
FIA_SOS.1 Rejection or acceptance by the TSF of any tested secret
FIA_UAU.2 All use of the authentication mechanism
FIA_UID.2 All use of the user identification mechanism, including the user identity provided.
FMT_MOF.1 All modifications in the behavior of the functions of the TSF
FMT_MTD.1 All modifications to the values of TSF data
FMT_SMF.1 Use of the management functions.
FMT_SMR.1 Modifications to the group of users that are part of a role
FPT_STM.1 Changes to the time
FTP_TRP.1 All attempted uses of the trusted path functions, to include identification of the user associated with
all trusted path invocations, if available.
Table 2: Auditable Events
5.2.1.2 Audit Review (FAU_SAR.1)
FAU_SAR.1.1 The TSF shall provide [the Super-user role] with the capability to read [all auditable events that
are recorded] 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.
5.2.1.3 Restricted Audit Review (FAU_SAR.2)
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been
granted explicit read-access.
5.2.1.4 Selectable Audit Review (FAU_SAR.3)
FAU_SAR.3.1 The TSF shall provide the ability to apply [sorting] of audit data based on [date and time,
subject identity, type of event, and success or failure of related event].
26
5.2.1.5 Selective Audit (FAU_SEL.1)
FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from the set of all auditable events
based on the following attributes:
a) [event type]
b) [no additional attributes].
5.2.1.6 Guarantees of Audit Data Availability (FAU_STG.2)
FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion.
FAU_STG.2.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the
audit trail.
FAU_STG.2.3 The TSF shall ensure that [the most recent 50% of] stored audit records will be maintained when
the following conditions occur: [audit storage exhaustion].
5.2.1.7 Prevention of Audit Data Loss (FAU_STG.4)
FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and [send an alarm] if the audit trail is
full.
5.2.2 User Data Protection (FDP)
5.2.2.1 Subset Information Flow Control (FDP_IFC.1)
FDP_IFC.1.1 The TSF shall enforce the [Traffic Management SFP] on [
 subjects: unauthenticated external IT entities that send and receive information
through the TOE to one another;
 information: traffic sent through the TOE from one subject to another;
 operation: pass information].
5.2.2.2 Simple Security Attributes (FDP_IFF.1)
FDP_IFF.1.1 The TSF shall enforce the [Traffic Management SFP] based on the following types of subject
and information security attributes: [
 Subject security attributes: presumed IP address
 Information security attributes: protocol, source IP address, source port,
destination IP address, destination port].
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information
via a controlled operation if the following rules hold: [if all the information security attribute
values match the rules in a traffic filter, the TSF shall enforce the action configured for the
filter, where the possible actions are:
 Block: traffic that triggers the filter is denied
 Allow: allows traffic that meets the filter criteria; this traffic is then subjected to IPS
filtering
 Rate Limit: rate limits traffic that meets the filter criteria; this traffic is then
subjected to IPS filtering
 Trust: allows traffic that meets the filter criteria through the TOE without being
subjected to IPS filtering.
Otherwise, the traffic is subjected to IPS filtering].
FDP_IFF.1.3 The TSF shall enforce the [no additional rules].
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following rules: [All the
information security attribute values match an inspection bypass rule].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: [none].
Application Note: Note that the explicit authorization rule specified by FDP_IFF.1.4 is
implemented only on the NX models of the TOE.
27
5.2.3 Identification and Authentication (FIA)
5.2.3.1 Authentication Failure Handling (FIA_AFL.1)
FIA_AFL.1.1 The TSF shall detect when [an administrator configurable positive integer within [1..10]]
unsuccessful authentication attempts occur related to [user login].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [met], the TSF shall
[perform the configured Failed Login Action, which can be one of the following:
 Lock the account for a configured Lockout Period
 Disable the account
 Generate an audit event documenting the failed login attempt].
5.2.3.2 User Attribute Definition (FIA_ATD.1)
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [
 User identity
 Authentication data
 Access level (role)].
5.2.3.3 Verification of Secrets (FIA_SOS.1)
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [the following requirements:
 passwords must be at least 8 characters long
 passwords must contain at least two alphabetic characters
 passwords must contain at least one numeric character
 passwords must contain at least one non-alphanumeric character].
5.2.3.4 User Authentication before any Action (FIA_UAU.2)
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-
mediated actions on behalf of that user.
5.2.3.5 User Identification before any Action (FIA_UID.2)
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-
mediated actions on behalf of that user.
5.2.4 Security Management (FMT)
5.2.4.1 Management of Security Functions Behavior (FMT_MOF.1)
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions [of IDS data
collection, analysis and reaction] to [the Super-user and Administrator role].
5.2.4.2 Management of TSF Data (FMT_MTD.1)
FMT_MTD.1.1(1) The TSF shall restrict the ability to [modify] the [
 Failed Login Action
 Security Level
 Other users’ passwords
 System time
] to [Super-user].
FMT_MTD.1.1(2) The TSF shall restrict the ability to [modify, delete, [create]] the [User accounts] to [Super-
user].
FMT_MTD.1.1(3) The TSF shall restrict the ability to [modify, delete, [create]] the [
 Traffic management filters
 Notification contacts
28
 Inspection bypass rules
] to [Super-user, Administrator].
FMT_MTD.1.1(4) The TSF shall restrict the ability to [modify] the [set of audited events] to [Super-user,
Administrator].
FMT_MTD.1.1(5) The TSF shall restrict the ability to [clear] the [audit trail] to [Super-user].
FMT_MTD.1.1(6) The TSF shall restrict the ability to [clear] the [IDS data] to [Super-user, Administrator].
5.2.4.3 Specification of Management Functions (FMT_SMF.1)
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
 Modify the set of audited events
 Modify the Failed Login Action
 Modify the Security Level
 Modify user passwords
 Modify system time
 Create, modify and delete notification contacts
 Create, modify and delete user accounts
 Create, modify and delete traffic management filters
 Create, modify and delete inspection bypass rules (NX models only)
 Clear the audit trail and IDS data
 Modify the behavior of the IDS data collection, analysis and reaction functions].
5.2.4.4 Security Roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the roles [Super-user, Administrator, Operator].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.2.5 Protection of the TOE Security Functions (FPT)
5.2.5.1 Reliable Time Stamps (FPT_STM.1)
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
5.2.6 Trusted Path/Channels (FTP)
5.2.6.1 Trusted Path (FTP_TRP.1)
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [remote] users that is logically
distinct from other communication paths and provides assured identification of its end points and
protection of the communicated data from [disclosure, [undetected modification]].
FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [initial user authentication, [all remote
administrative actions]].
5.2.7 Intrusion Detection System (IDS)
5.2.7.1 Analyzer Analysis (IDS_ANL_EXT.1)
IDS_ANL_EXT.1.1 The TSF shall perform the following analysis function(s) on all IDS data received:
a) [statistical, signature]; and
b) [no other functions].
IDS_ANL_EXT.1.2 The TSF shall record within each analytical result at least the following information:
a) Date and time of the result, type of result, identification of data source; and,
b) [Data destination, protocol, and severity].
29
5.2.7.2 Analyzer reaction (IDS_RCT_EXT.1)
IDS_RCT_EXT.1.1 The TSF shall send an alarm to [the IDS data log and the notification contacts
configured for the filter triggered by the network traffic] and take [the action
configured for the filter triggered by the network traffic, which can be to:
 Block the network traffic
 Permit the network traffic
] when an intrusion is detected.
Application Note: If traffic is permitted, an alert will be written to the IDS data log. If traffic is
blocked, writing an alert to the IDS data log is configurable. In the evaluated configuration,
action sets that block traffic must also be configured to generate an alert.
5.2.7.3 Restricted Data Review (IDS_RDR_EXT.1)
IDS_RDR_EXT.1.1 The TSF shall provide [the Super-user, Administrator and Operator roles] with the
capability to read [all IDS data] from the IDS data.
IDS_RDR_EXT.1.2 The TSF shall provide the IDS data in a manner suitable for the user to interpret the
information.
IDS_RDR_EXT.1.3 The TSF shall prohibit all users read access to the IDS data, except those users that have
been granted explicit read access.
5.2.7.4 IDS Data Collection (IDS_SDC_EXT.1)
IDS_SDC_EXT.1.1 The TSF shall be able to collect the following information from the targeted IT System
resource(s):
a) [network traffic]; and
b) [no additional events].
IDS_SDC_EXT.1.2 At a minimum, the TSF shall collect and record the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success
or failure) of the event; and
b) The additional information specified in the Details column of the following table.
Event Details
Network traffic Protocol, source address, destination address
Table 3: IDS Events
Application Note: The TOE can collect all network traffic on each configured network segment,
for subsequent analysis as specified by IDS_ANL_EXT.1. However, the TOE will not collect for
analysis any network traffic that has been Blocked or Trusted by the application of traffic
management filters as specified in FDP_IFF.1, since traffic management filters are applied to
network traffic before IPS filters. The TOE retains collected network traffic for as long as it
requires to complete its analysis, after which the network traffic is allowed to pass through the
TOE or is discarded, based on the action set associated with the triggered IPS filter (if any).
5.2.7.5 Guarantee of IDS Data Availability (IDS_STG_EXT.1)
IDS_STG_EXT.1.1 The TSF shall protect the stored IDS data from unauthorized deletion.
IDS_STG_EXT.1.2 The TSF shall protect the stored IDS data from modification.
IDS_STG_EXT.1.3 The TSF shall ensure that [the most recent 50% of the] IDS data will be maintained
when the following conditions occur: [IDS data storage exhaustion].
5.2.7.6 Prevention of IDS Data Loss (IDS_STG_EXT.2)
IDS_STG_EXT.2.1 The TSF shall [overwrite the oldest stored IDS data] and send an alarm if the
storage capacity has been reached.
30
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the EAL 3 augmented with ALC_FLR.2 components as
specified in Part 3 of the Common Criteria. No operations are applied to the assurance components.
Requirement Class Requirement Component
ADV: Development ADV_ARC.1: Security architecture description
ADV_FSP.3: Functional specification with complete summary
ADV_TDS.2: Architectural design
AGD: Guidance documents AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-cycle support ALC_CMC.3: Authorisation controls
ALC_CMS.3: Implementation representation CM coverage
ALC_DEL.1: Delivery procedures
ALC_DVS.1: Identification of security measures
ALC_FLR.2: Flaw reporting procedures
ALC_LCD.1: Developer defined life-cycle model
ASE: Security Target evaluation ASE_INT.1: ST introduction
ASE_CCL.1: Conformance claims
ASE_SPD.1: Security problem definition
ASE_OBJ.2: Security objectives
ASE_ECD.1: Extended components definition
ASE_REQ.2: Derived security requirements
ASE_TSS.1: TOE summary specification
ATE: Tests ATE_COV.2: Analysis of coverage
ATE_DPT.1: Testing: basic design
ATE_FUN.1: Functional testing
ATE_IND.2: Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.2: Vulnerability analysis
Table 4: EAL 3 augmented with ALC_FLR.2 Assurance Components
5.3.1 Development (ADV)
5.3.1.1 Security Architecture Description (ADV_ARC.1)
ADV_ARC.1.1D The developer shall design and implement the TOE so that the security features of the TSF
cannot be bypassed.
ADV_ARC.1.2D The developer shall design and implement the TSF so that it is able to protect itself from
tampering by untrusted active entities.
ADV_ARC.1.3D The developer shall provide a security architecture description of the TSF.
ADV_ARC.1.1C The security architecture description shall be at a level of detail commensurate with the
description of the SFR-enforcing abstractions described in the TOE design document.
31
ADV_ARC.1.2C The security architecture description shall describe the security domains maintained by the
TSF consistently with the SFRs.
ADV_ARC.1.3C The security architecture description shall describe how the TSF initialisation process is
secure.
ADV_ARC.1.4C The security architecture description shall demonstrate that the TSF protects itself from
tampering.
ADV_ARC.1.5C The security architecture description shall demonstrate that the TSF prevents bypass of the
SFR-enforcing functionality.
ADV_ARC.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.1.2 Functional Specification with Complete Summary (ADV_FSP.3)
ADV_FSP.3.1D The developer shall provide a functional specification.
ADV_FSP.3.2D The developer shall provide a tracing from the functional specification to the SFRs.
ADV_FSP.3.1C The functional specification shall completely represent the TSF.
ADV_FSP.3.2C The functional specification shall describe the purpose and method of use for all TSFI.
ADV_FSP.3.3C The functional specification shall identify and describe all parameters associated with each
TSFI.
ADV_FSP.3.4C For each SFR-enforcing TSFI, the functional specification shall describe the SFR-enforcing
actions associated with the TSFI.
ADV_FSP.3.5C For each SFR-enforcing TSFI, the functional specification shall describe direct error
messages resulting from SFR-enforcing actions and exceptions associated with invocation of
the TSFI.
ADV_FSP.3.6C The functional specification shall summarise the SFR-supporting and SFR-non-interfering
actions associated with each TSFI.
ADV_FSP.3.7C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.
ADV_FSP.3.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ADV_FSP.3.2E The evaluator shall determine that the functional specification is an accurate and complete
instantiation of the SFRs.
5.3.1.3 Architectural Design (ADV_TDS.2)
ADV_TDS.2.1D The developer shall provide the design of the TOE.
ADV_TDS.2.2D The developer shall provide a mapping from the TSFI of the functional specification to the
lowest level of decomposition available in the TOE design.
ADV_TDS.2.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.2.2C The design shall identify all subsystems of the TSF.
ADV_TDS.2.3C The design shall describe the behaviour of each SFR non-interfering subsystem of the TSF in
detail sufficient to determine that it is SFR non-interfering.
ADV_TDS.2.4C The design shall describe the SFR-enforcing behaviour of the SFR-enforcing subsystems.
ADV_TDS.2.5C The design shall summarise the SFR-supporting and SFR-non-interfering behaviour of the
SFR-enforcing subsystems.
ADV_TDS.2.6C The design shall summarise the behaviour of the SFR-supporting subsystems.
ADV_TDS.2.7C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.2.8C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE
design that they invoke.
ADV_TDS.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
32
ADV_TDS.2.2E The evaluator shall determine that the design is an accurate and complete instantiation of all
security functional requirements.
5.3.2 Guidance Documents (AGD)
5.3.2.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1D The developer shall provide operational user guidance.
AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user-accessible functions
and privileges that should be controlled in a secure processing environment, including
appropriate warnings.
AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available
interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
values as appropriate.
AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-
relevant event relative to the user-accessible functions that need to be performed, including
changing the security characteristics of entities under the control of the TSF.
AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and
implications for maintaining secure operation.
AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be
followed in order to fulfil the security objectives for the operational environment as described
in the ST.
AGD_OPE.1.7C The operational user guidance shall be clear and reasonable.
AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.2.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.
AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the
delivered TOE in accordance with the developer's delivery procedures.
AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the
TOE and for the secure preparation of the operational environment in accordance with the
security objectives for the operational environment as described in the ST.
AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared
securely for operation.
5.3.3 Life-cycle Support (ALC)
5.3.3.1 Authorisation Controls (ALC_CMC.3)
ALC_CMC.3.1D The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.3.2D The developer shall provide the CM documentation.
ALC_CMC.3.3D The developer shall use a CM system.
ALC_CMC.3.1C The TOE shall be labelled with its unique reference.
ALC_CMC.3.2C The CM documentation shall describe the method used to uniquely identify the configuration
items.
ALC_CMC.3.3C The CM system shall uniquely identify all configuration items.
33
ALC_CMC.3.4C The CM system shall provide measures such that only authorised changes are made to the
configuration items.
ALC_CMC.3.5C The CM documentation shall include a CM plan.
ALC_CMC.3.6C The CM plan shall describe how the CM system is used for the development of the TOE.
ALC_CMC.3.7C The evidence shall demonstrate that all configuration items are being maintained under the
CM system.
ALC_CMC.3.8C The evidence shall demonstrate that the CM system is being operated in accordance with the
CM plan.
ALC_CMC.3.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.3.2 Implementation Representation CM Coverage (ALC_CMS.3)
ALC_CMS.3.1D The developer shall provide a configuration list for the TOE.
ALC_CMS.3.1C The configuration list shall include the following: the TOE itself; the evaluation evidence
required by the SARs; the parts that comprise the TOE; and the implementation
representation.
ALC_CMS.3.2C The configuration list shall uniquely identify the configuration items.
ALC_CMS.3.3C For each TSF relevant configuration item, the configuration list shall indicate the developer of
the item.
ALC_CMS.3.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.3.3 Delivery Procedures (ALC_DEL.1)
ALC_DEL.1.1D The developer shall document and provide procedures for delivery of the TOE or parts of it to
the consumer.
ALC_DEL.1.2D The developer shall use the delivery procedures.
ALC_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain
security when distributing versions of the TOE to the consumer.
ALC_DEL.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.3.4 Identification of Security Measures (ALC_DVS.1)
ALC_DVS.1.1D The developer shall produce and provide development security documentation.
ALC_DVS.1.1C The development security documentation shall describe all the physical, procedural,
personnel, and other security measures that are necessary to protect the confidentiality and
integrity of the TOE design and implementation in its development environment.
ALC_DVS.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ALC_DVS.1.2E The evaluator shall confirm that the security measures are being applied.
5.3.3.5 Flaw Reporting Procedures (ALC_FLR.2)
ALC_FLR.2.1D The developer shall document and provide flaw remediation procedures addressed to TOE
developers.
ALC_FLR.2.2D The developer shall establish a procedure for accepting and acting upon all reports of security
flaws and requests for corrections to those flaws.
ALC_FLR.2.3D The developer shall provide flaw remediation guidance addressed to TOE users.
ALC_FLR.2.1C The flaw remediation procedures documentation shall describe the procedures used to track
all reported security flaws in each release of the TOE.
34
ALC_FLR.2.2C The flaw remediation procedures shall require that a description of the nature and effect of
each security flaw be provided, as well as the status of finding a correction to that flaw.
ALC_FLR.2.3C The flaw remediation procedures shall require that corrective actions be identified for each of
the security flaws.
ALC_FLR.2.4C The flaw remediation procedures documentation shall describe the methods used to provide
flaw information, corrections and guidance on corrective actions to TOE users.
ALC_FLR.2.5C The flaw remediation procedures shall describe a means by which the developer receives from
TOE users reports and enquiries of suspected security flaws in the TOE.
ALC_FLR.2.6C The procedures for processing reported security flaws shall ensure that any reported flaws are
remediated and the remediation procedures issued to TOE users.
ALC_FLR.2.7C The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
ALC_FLR.2.8C The flaw remediation guidance shall describe a means by which TOE users report to the
developer any suspected security flaws in the TOE.
ALC_FLR.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.3.6 Developer Defined Life-Cycle Model (ALC_LCD.1)
ALC_LCD.1.1D The developer shall establish a life-cycle model to be used in the development and
maintenance of the TOE.
ALC_LCD.1.2D The developer shall provide life-cycle definition documentation.
ALC_LCD.1.1C The life-cycle definition documentation shall describe the model used to develop and
maintain the TOE.
ALC_LCD.1.2C The life-cycle model shall provide for the necessary control over the development and
maintenance of the TOE.
ALC_LCD.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.4 Security Target Evaluation (ASE)
5.3.4.1 ST Introduction (ASE_INT.1)
ASE_INT.1.1D The developer shall provide an ST introduction.
ASE_INT.1.1C The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a
TOE description.
ASE_INT.1.2C The ST reference shall uniquely identify the ST.
ASE_INT.1.3C The TOE reference shall identify the TOE.
ASE_INT.1.4C The TOE overview shall summarise the usage and major security features of the TOE.
ASE_INT.1.5C The TOE overview shall identify the TOE type.
ASE_INT.1.6C The TOE overview shall identify any non-TOE hardware/software/firmware required by the
TOE.
ASE_INT.1.7C The TOE description shall describe the physical scope of the TOE.
ASE_INT.1.8C The TOE description shall describe the logical scope of the TOE.
ASE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ASE_INT.1.2E The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE
description are consistent with each other.
5.3.4.2 Conformance Claims (ASE_CCL.1)
ASE_CCL.1.1D The developer shall provide a conformance claim.
35
ASE_CCL.1.2D The developer shall provide a conformance claim rationale.
ASE_CCL.1.1C The conformance claim shall contain a CC conformance claim that identifies the version of
the CC to which the ST and the TOE claim conformance.
ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either
CC Part 2 conformant or CC Part 2 extended.
ASE_CCL.1.3C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either
CC Part 3 conformant or CC Part 3 extended.
ASE_CCL.1.4C The CC conformance claim shall be consistent with the extended components definition.
ASE_CCL.1.5C The conformance claim shall identify all PPs and security requirement packages to which the
ST claims conformance.
ASE_CCL.1.6C The conformance claim shall describe any conformance of the ST to a package as either
package-conformant or package-augmented.
ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the TOE type is consistent with the
TOE type in the PPs for which conformance is being claimed.
ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of the security problem
definition is consistent with the statement of the security problem definition in the PPs for
which conformance is being claimed.
ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security objectives is
consistent with the statement of security objectives in the PPs for which conformance is being
claimed.
ASE_CCL.1.10C The conformance claim rationale shall demonstrate that the statement of security requirements
is consistent with the statement of security requirements in the PPs for which conformance is
being claimed.
ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.4.3 Security Problem Definition (ASE_SPD.1)
ASE_SPD.1.1D The developer shall provide a security problem definition.
ASE_SPD.1.1C The security problem definition shall describe the threats.
ASE_SPD.1.2C All threats shall be described in terms of a threat agent, an asset, and an adverse action.
ASE_SPD.1.3C The security problem definition shall describe the OSPs.
ASE_SPD.1.4C The security problem definition shall describe the assumptions about the operational
environment of the TOE.
ASE_SPD.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.4.4 Security Objectives (ASE_OBJ.2)
ASE_OBJ.2.1D The developer shall provide a statement of security objectives.
ASE_OBJ.2.2D The developer shall provide a security objectives rationale.
ASE_OBJ.2.1C The statement of security objectives shall describe the security objectives for the TOE and the
security objectives for the operational environment.
ASE_OBJ.2.2C The security objectives rationale shall trace each security objective for the TOE back to
threats countered by that security objective and OSPs enforced by that security objective.
ASE_OBJ.2.3C The security objectives rationale shall trace each security objective for the operational
environment back to threats countered by that security objective, OSPs enforced by that
security objective, and assumptions upheld by that security objective.
ASE_OBJ.2.4C The security objectives rationale shall demonstrate that the security objectives counter all
threats.
36
ASE_OBJ.2.5C The security objectives rationale shall demonstrate that the security objectives enforce all
OSPs.
ASE_OBJ.2.6C The security objectives rationale shall demonstrate that the security objectives for the
operational environment uphold all assumptions.
ASE_OBJ.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.4.5 Extended Components Definition (ASE_ECD.1)
ASE_ECD.1.1D The developer shall provide a statement of security requirements.
ASE_ECD.1.2D The developer shall provide an extended components definition.
ASE_ECD.1.1C The statement of security requirements shall identify all extended security requirements.
ASE_ECD.1.2C The extended components definition shall define an extended component for each extended
security requirement.
ASE_ECD.1.3C The extended components definition shall describe how each extended component is related
to the existing CC components, families, and classes.
ASE_ECD.1.4C The extended components definition shall use the existing CC components, families, classes,
and methodology as a model for presentation.
ASE_ECD.1.5C The extended components shall consist of measurable and objective elements such that
conformance or nonconformance to these elements can be demonstrated.
ASE_ECD.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ASE_ECD.1.2E The evaluator shall confirm that no extended component can be clearly expressed using
existing components.
5.3.4.6 Derived Security Requirements (ASE_REQ.2)
ASE_REQ.2.1D The developer shall provide a statement of security requirements.
ASE_REQ.2.2D The developer shall provide a security requirements rationale.
ASE_REQ.2.1C The statement of security requirements shall describe the SFRs and the SARs.
ASE_REQ.2.2C All subjects, objects, operations, security attributes, external entities and other terms that are
used in the SFRs and the SARs shall be defined.
ASE_REQ.2.3C The statement of security requirements shall identify all operations on the security
requirements.
ASE_REQ.2.4C All operations shall be performed correctly.
ASE_REQ.2.5C Each dependency of the security requirements shall either be satisfied, or the security
requirements rationale shall justify the dependency not being satisfied.
ASE_REQ.2.6C The security requirements rationale shall trace each SFR back to the security objectives for
the TOE.
ASE_REQ.2.7C The security requirements rationale shall demonstrate that the SFRs meet all security
objectives for the TOE.
ASE_REQ.2.8C The security requirements rationale shall explain why the SARs were chosen.
ASE_REQ.2.9C The statement of security requirements shall be internally consistent.
ASE_REQ.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.4.7 TOE Summary Specification (ASE_TSS.1)
ASE_TSS.1.1D The developer shall provide a TOE summary specification.
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR.
ASE_TSS.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
37
ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is consistent with the TOE
overview and the TOE description.
5.3.5 Tests (ATE)
5.3.5.1 Analysis of Coverage (ATE_COV.2)
ATE_COV.2.1D The developer shall provide an analysis of the test coverage.
ATE_COV.2.1C The analysis of the test coverage shall demonstrate the correspondence between the tests in
the test documentation and the TSFIs in the functional specification.
ATE_COV.2.2C The analysis of the test coverage shall demonstrate that all TSFIs in the functional
specification have been tested.
ATE_COV.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.5.2 Testing: Basic Design (ATE_DPT.1)
ATE_DPT.1.1D The developer shall provide the analysis of the depth of testing.
ATE_DPT.1.1C The analysis of the depth of testing shall demonstrate the correspondence between the tests in
the test documentation and the TSF subsystems in the TOE design.
ATE_DPT.1.2C The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE
design have been tested.
ATE_DPT.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.5.3 Functional Testing (ATE_FUN.1)
ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2D The developer shall provide test documentation.
ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and actual test results.
ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the scenarios for
performing each test. These scenarios shall include any ordering dependencies on the results
of other tests.
ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a successful execution of the
tests.
ATE_FUN.1.4C The actual test results shall be consistent with the expected test results.
ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
5.3.5.4 Independent Testing - Sample (ATE_IND.2)
ATE_IND.2.1D The developer shall provide the TOE for testing.
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in the
developer's functional testing of the TSF.
ATE_IND.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ATE_IND.2.2E The evaluator shall execute a sample of tests in the test documentation to verify the developer
test results.
ATE_IND.2.3E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
38
5.3.6 Vulnerability Assessment (AVA)
5.3.6.1 Vulnerability Analysis (AVA_VAN.2)
AVA_VAN.2.1D The developer shall provide the TOE for testing.
AVA_VAN.2.1C The TOE shall be suitable for testing.
AVA_VAN.2.1E The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
AVA_VAN.2.2E The evaluator shall perform a search of public domain sources to identify potential
vulnerabilities in the TOE.
AVA_VAN.2.3E The evaluator shall perform an independent vulnerability analysis of the TOE using the
guidance documentation, functional specification, TOE design and security architecture
description to identify potential vulnerabilities in the TOE.
AVA_VAN.2.4E The evaluator shall conduct penetration testing, based on the identified potential
vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker
possessing Basic attack potential.
39
6. TOE Summary Specification
This chapter describes the security functions implemented by the TOE to satisfy the SFRs.
6.1 TOE Security Functions
The TOE implements the following security functions that together satisfy the SFRs claimed in Section 5.2 of this
ST:
 Security Audit
 Identification and Authentication
 Intrusion Detection and Prevention
 Traffic Management
 Security Management
 TSF Protection
 Trusted Path.
6.1.1 Security Audit
The TOE generates two types of activity monitoring logs:
 Audit data logs
 IDS data logs (comprising the Block log and the Alert log).
IDS data logs record activity related to the TOE’s intrusion detection and prevention capabilities. These logs differ
from Audit data logs in their contents and controls. The IDS data logs are generated by the Intrusion Detection and
Prevention security function (see Section 6.1.3).
The TOE provides the capability to generate and store audit records of auditable events. The TOE provides secure
storage of audit records until they are automatically overwritten or cleared by an administrative user in the Super-
user role. The TOE ensures that only the Super-user is able to view the audit data and that the audit data is presented
in an interpretable manner. The TOE provides a means for the Super-user to determine what audit data the TOE
generates, and the capability to sort the audit data that is being reviewed.
6.1.1.1 Audit Data Generation (FAU_GEN.1)
The Security Audit security function generates audit records for the following auditable events:
 Start-up and shutdown of the audit function
 Reading of information from the audit records
 Unsuccessful attempts to read information from the audit records
 All modifications to the audit configuration that occur while the audit collection functions are operating
 Actions taken due to audit storage failure
 All decisions on requests for information flow
 Reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the
subsequent restoration to the normal state
 Rejection by the TSF of any tested secret
 All use of the authentication mechanisms
40
 All use of the user identification mechanism, including the user identity provided
 All modifications in the behavior of the functions of the TSF
 All modifications to the values of TSF data
 Use of the management functions
 Modifications to the group of users that are part of a role
 Changes to the time
 All attempted uses of the trusted path functions, to include identification of the user associated with all
trusted path invocations, if available.
The Security Audit security function includes in the audit record, for each auditable event: the date and time of the
event; type of event; subject identity; and the outcome (success or failure) of the event.
Note that the TOE does not support the ability to start up and shutdown the audit functions outside the ability to
startup and shutdown the entire TOE. Thus, each time the TOE starts, the auditing functions are started and an
“Audit facilities started” audit record is generated. Similarly, the audit functions are shutdown only when the TOE is
shutdown. When this occurs, the TOE generates an “Audit facilities stopped” audit record.
6.1.1.2 Audit Review (FAU_SAR.1, FAU_SAR.2, FAU_SAR.3)
The Security Audit security function provides mechanisms to view data from the Audit log. Only a user assigned the
Super-user role can view events stored in the Audit log. This is done by restricting access using the file system
service capabilities to protect the Audit log so that only authenticated Super-users can read audit data.
The Management Interface provides commands to configure how terminal sessions behave. The presentation format
of data within the Management Interface can be defined. Data from the Audit log can be displayed in text format
over the Management Interface. The default settings listed in Table 5 can be modified to provide for the optimal
viewing of data.
Setting Default Value Command to Change Setting
columns 80 hostname# conf t session col <number of columns>
rows 25 hostname# conf t session row <number of rows>
more On hostname# conf t session no more
wraparound On hostname# conf t session no wrap
timeout 20 minutes hostname# conf t session timeout <number of minutes>
Table 5: Default Console Settings
The Security Audit security function provides the ability to sort audit data. This capability is only provided by the
LSM and is not available in the CLI. Sorting audit data is performed using the pointing device (e.g., mouse) to select
the column to be sorted, based on the criteria shown in Table 6.
Criteria Description
Time Sorts log entries in an ascending or descending list based on the time of the
entry
User <“login name”> Sorts logs by the login name of the user that was logged in when the log entry
was created
Status [PASS|FAIL] Display only records with pass or fail status.
IP <nnn.nnn.nnn.nnn> Displays log records whose access was from the IP address entered
41
Criteria Description
Interface [WEB,CLI, LSM,
SNMP, OTHER]
Filters on the interface through which the user accessed the TOE
Event type Sorts events based on the severity of the event in one column, or by the
specific name of the event in another column
Table 6: Sorting Criteria
6.1.1.3 Audit Event Selection (FAU_SEL.1)
Audited events can be selected from the set of auditable events based on event categories (i.e., the event type). These
event categories are listed in Table 7. A user in the Super-user or Administrator role can use the CLI ‘configure’
command to select the event categories to be included in the set of auditable events. The ‘configure’ command
allows the event category to be enabled or disabled, thus determining which auditable events are actually written to
the Audit log.
Event Category Description
boot This flag toggles the auditing of boot information for the system.
compact-flash This flag toggles the auditing of use of a compact-flash card with the TOE.
config This flag toggles the auditing of configuration data. This includes changing the
auditable events in the logs.
conn-table This flag toggles the auditing of connection table information
device This flag toggles the auditing of device information.
general This flag toggles the auditing of the rotation of logs.
high-availability This flag toggles the auditing of high-availability information
host This flag toggles the collection of audit records whenever audit starts or stops.
host-communications This flag toggles the auditing of host-communication information
ip-filter This flag toggles the auditing of HOST IP filter information
login This flag toggles the auditing of login events.
logout This flag toggles the auditing of logout events.
monitor This flag toggles the auditing of monitor information, such as packet and network traffic
scanning and events
policy This flag toggles the auditing of TSE System policy data.
report This flag toggles the auditing of events related to reports, including the viewing and
clearing of logs to include both audit and System data logs.
segment This flag toggles the auditing of network segment information, such as port and system
settings per segment of a device
server This flag toggles the auditing of server information
slot This flag toggles the auditing of I/O module slot configuration information
sms This flag toggles the auditing of SMS information
time This flag toggles the auditing of changes to time settings.
42
Event Category Description
tse This flag toggles the auditing of events related to the threat suppression engine.
update This flag toggles the auditing of system and software updates, such as Digital Vaccine
and software updates
user This flag toggles the auditing of changes to user account related data. This includes user
creation, modification and deletion of user accounts.
Table 7: Auditable Event Categories
6.1.1.4 Audit Event Storage (FAU_STG.2, FAU_STG.4)
The TOE prevents unauthorized access (i.e., deletion, viewing and modification) to audit records by requiring users
to be successfully identified and authenticated before gaining access to the TOE. The Security Audit security
function ensures that when the audit storage becomes exhausted, that the oldest 50% of audit records are purged to
ensure adequate disk space for the more recent auditable events.
The Security Audit security function does not allow a user to modify audit data outside of allowing a Super-user to
completely purge the Audit log, either by using the ‘clear’ CLI command or by resetting the log in the LSM by
clicking the “reset log” icon next to the Audit Log entry. The TOE compares the user access level for all incoming
audit purge requests to the access level of the role provided and maintained by the TOE. If the access level of the
requested action is greater than the current user’s access level, the requested action to purge is denied. All purge
requests (successful and unsuccessful) are logged, allowing for detection of the deletion, or attempted deletion, of
audit records.
Each of the logs maintained by the TOE (Audit, Block, Alert) consists of a “current” log file and a “historical” log
file. Thus, there are six separate log files that provide the log storage—the current Audit, Block, and Alert log files,
and the historical Audit, Block, and Alert log files. The TOE uses a volume threshold to limit the size of each log
file (configured maximum size is 4 MB3
). Entries for each type of log are initially written to the applicable current
log file. When the current log file reaches the maximum file size, the log file is closed, a new log file is created, and
an alarm is generated. This alarm comprises an email sent to a specified user, configurable by the Super-user role.
The log file that is closed becomes the historical log file and the new file becomes the current log file. If a historical
log file already exists, it is deleted. Subsequent log records are then written to the newly created current log file.
This mechanism, which is applied to all types of log files (i.e., Audit, Block, and Alert) is used to limit the amount
of audit data that is overwritten when the system’s capacity to store audit records is reached. Access to any type of
log file through the Management Interface for the purpose of viewing or clearing always treats both the historical
log file and the current log file as one log. Therefore, viewing audit records in the Audit log displays all records
from both files. Similarly, clearing the Audit log deletes both the current and historical files.
The deletion of the historical Audit log file when the current Audit log file becomes full effectively overwrites the
oldest audit records. The TOE also writes a new log record to the Alert log when new log files are created. This
mechanism, which applies to all log types, is used to generate alarms whenever the Audit log overwrites the oldest
stored audit records.
6.1.2 Identification and Authentication
The Identification and Authentication security function is implemented within the Management Interface subsystem
of the TOE. The Identification and Authentication security function provides the capability for the TOE to identify
and authenticate administrative users of the TOE.
6.1.2.1 User Identification and Authentication (FIA_UID.2, FIA_UAU.2)
The Identification and Authentication security function provides the capability to identify and authenticate the
administrative users of the TOE. It prevents administrative user actions from being performed prior to identification
and authentication of the user. In order to establish a connection with the TOE, the administrative user is required to
3
The TOE implements a capability to modify the configured maximum log file size, but this is intended only for HP
TippingPoint QA and technical support staff.
43
submit user credentials, comprising user identity and authentication data (in the form of a password) through the
Management Interface. The Identification and Authentication security function compares the submitted credentials
with the details of user accounts configured in the TOE. When a valid username/password pair is provided, the
management functionality is available to the logged in user via the Management Interface.
6.1.2.2 Verification of Secrets (FIA_SOS.1)
The Identification and Authentication security function maintains a global configuration parameter, identified as
‘Security Level’, that determines the length and complexity requirements for all passwords on the TOE. The
following options are provided:
 No Security Checking (Level 0)—passwords are not required
 Basic Security Checking (Level 1)—user names must be 6-32 characters long; passwords must be 8-32
characters long
 Maximum Security Checking (Level 2)—in addition to the Level 1 requirements, passwords must contain
at least two alphabetic characters, at least one numeric character and one non-alphanumeric character
(special characters such as ‘!’, ‘?’, or ‘#’).
The Super-user can configure the Security Level. The default security level is Level 2, which is the level that
ensures passwords satisfy the strength requirements specified by FIA_SOS.1.
6.1.2.3 Authentication Failure Handling (FIA_AFL.1)
The Identification and Authentication security function is able to detect when the number of consecutive failed user
login attempts meets an administrator-configured number (in the range 1..10, with 5 as the default value). When this
occurs, the TOE takes the configured action. A user in the Super-user role can configure the number of consecutive
failed login attempts (Max Login Attempts) that will cause the Identification and Authentication security function to
take action, and can also configure the action to be taken (Failed Login Action). The options for the Failed Login
Action are as follows:
 Lockout Account—lock the user account for a configured Lockout Period
 Disable Account—disable the user account. The user will be unable to login until the account is enabled by
a Super-user
 Generate an audit event and write an audit record to the Audit log documenting the failed login attempt.
The Super-user can configure the Lockout Period, in minutes, for which the account will be locked if the Failed
Login Action is Lockout Account. The Authentication Failure Handling mechanism applies to all user accounts.
6.1.2.4 User Attribute Definition (FIA_ATD.1)
The Identification and Authentication security function maintains the following security attributes associated with
administrative users of the TOE:
 User identity—the user name the TOE uses to uniquely identify each administrative user
 Authentication data (password)—the credential used to authenticate the administrative user’s identity
 Authorizations (roles)—the management role (Super-user, Administrator, Operator) to which the user has
been assigned. The TOE documentation also identifies this attribute as ‘Access Level’. Every
administrative user must be assigned a management role.
The user security attributes maintained for administrative users are stored in the file system implemented by the
TippingPoint Operating System and are managed through the Management Interface. The ability to manage the user
attributes is restricted to the Super-user role (except that any user can modify their own password, regardless of their
assigned role).
44
6.1.3 Intrusion Detection and Prevention
The Threat Suppression Engine (TSE) component implements the Intrusion Detection and Prevention security
function that provides the TOE with the sensing capabilities to collect network traffic, the analyzing capabilities to
inspect network traffic according to filter settings, and the reaction capabilities to generate alert records for certain
network traffic, block certain network traffic and pass along certain network traffic.
6.1.3.1 IDS Data Collection, Analysis and Reaction (IDS_SDC_EXT.1, IDS_ANL_EXT.1,
IDS_RCT_EXT.1)
The TOE collects network traffic and retains it for as long as it requires to complete its analysis, after which the
network traffic is allowed to pass through the TOE or is discarded, based on the action set associated with the
triggered IPS filter (if any).
The TOE performs statistical and signature-based analysis of the collected traffic, depending on configured IPS
filters, as it enters the TOE. The TOE decodes protocol headers to support reconstructing fragmented packets or
flows. Once decoded, the TOE uses installed filters to achieve desired protections for the protected network
segments (e.g., statistical analysis, traffic shaping, flow blocking, flow state tracking and application-layer parsing
of network protocols).
The TOE groups filters (i.e., signature-based rules combined with an action) into categories that the analyzer
function uses in order to provide protection against malicious network traffic as it passes through the data network
interface of the TOE. The categories provided by the TOE allow for simplified administration of a large number of
filters by allowing the Administrator or Super-user to enable, disable or specify an action set for a group of filters.
The grouping for filters cannot be changed. The categories defined by the TOE and the types of filter each contains
are listed in Table 8.
Application Protection Infrastructure Protection Performance Protection
• Exploits
• Identity Theft
• Reconnaissance
• Security Policy
• Spyware
• Virus
• Vulnerabilities
• Network Equipment
• Traffic Normalization
• IM
• P2P
• Streaming Media
Table 8: Filter Categories
Intrusion prevention capabilities such as traffic shaping are accomplished using traffic management filters (see
Section 6.1.4) and/or traffic normalization filters. Flow state tracking, flow blocking and application-layer parsing of
network protocols are characteristics of most of the filters in the categories described in Table 8.
The sensor and analyzer capabilities, implemented in the TSE, work together to record relevant collected data, as the
analytical results, to the Block log or Alert log, depending on the action prescribed for the filter. Within each
analytical result, the following information is stored:
 Date and time of the result
 Type of result (message, policy ID, signature ID, and classification)
 Identification of data source—address and port
 Data destination—address and port
 Protocol
 Severity.
45
The detection of an intrusion in the context of the TOE is the matching of network traffic to the configured security
policies (i.e., filters). When an intrusion is detected, the TOE reacts based upon the action set associated with the
matched filter.
An action set can specify the following possible actions:
 Block4
—blocks a packet from being transferred to the outgoing port of the network segment
 Block + Notify—blocks a packet from being transferred, writes a record to the Block log, and notifies all
selected contacts of the blocked packet
 Block + Notify + Trace—blocks a packet from being transferred, writes a record to the Block log, notifies
all selected contacts of the blocked packet, and logs all information about the packet according to the
packet trace settings
 Permit + Notify—permits a packet to be transferred to the outgoing port of the network segment, writes a
record to the Alert log, and notifies all selected contacts of the packet
 Permit + Notify + Trace—permits a packet to be transferred, writes a record to the Alert log, notifies all
selected contacts of the packet, and logs all information about the packet according to the packet trace
settings.
The following types of notification contacts can be configured:
 Remote System Log—sends messages to a syslog server on the management network
 Management Console—sends messages to the LSM
 Email or SNMP—sends messages to the email address or specified SNMP server on the management
network.
Each “Block” action can optionally specify that a TCP Reset occur, which results in the TOE resetting the TCP
connection for the source or destination IP address when the Block action executes.
In addition to the Block and Permit action sets described above, the TOE supports Rate Limit and Quarantine action
sets.
A Rate Limit action set defines a maximum bandwidth that can be used by traffic that matches filters assigned to
that action set. Incoming traffic in excess of this bandwidth is dropped. If two or more filters use the same rate
limiting action set, then all packets matching these filters share the bandwidth. For example, if filters 164 (ICMP
Echo Request) and 161 (ICMP Redirect Undefined Code) use the same 10 Mbps action set, then both “Echo
Requests” and “Redirect Undefined Codes” filters share the 10 Mbps “pipe” as opposed to each filter getting a
dedicated 10Mbps pipe. The supported rates are subject to restrictions based on the device model. Any of these
listed rates can be used as long as it does not exceed 25% percent of the total bandwidth of the product.
A Quarantine action set allows the TOE to block or permit packets based on the IP addresses in the packet that
triggers the filter. When a filter with a quarantine option is triggered, the TOE installs a block for the quarantined IP
address and quarantines the IP address based on the instructions in the action set. If the quarantine action is
combined with a Block action, the flow is blocked. The quarantine action can also be combined with a Permit
action, in which case the flow is permitted while the IP address is placed in quarantine. The action of adding an IP
address to, or removing an IP address from, quarantine is recorded in the Quarantine log. Quarantine logging
operates independently of a policy’s notification contacts, and quarantine events are always recorded in the
Quarantine log. Any user can view the log, but only Super-user and Administrator level users can reset the log.
6.1.3.2 IDS Data Review (IDS_RDR_EXT.1)
The ability to read the logs stored on the TOE is restricted to authorized users. The three access levels supported by
the TOE—Super-user, Administrator and Operator—all have read access to the Block and Alert logs once
authenticated to the TOE.
4
This option should not be used in the evaluated configuration, since alarms will not be written to the Block log or
sent to configured notification contacts, meaning IDS_RCT.1 is not satisfied.
46
The TOE compares the user access level for all incoming data review requests to the access level of the user role
provided. If the access level of the requested action is greater than the current user’s access level, the requested
action is denied. This applies to requests to review IDS data stored by the TOE in the Block log and Alert log. This
data can be accessed either using the ‘show’ CLI command or by using the Navigation Tree of the LSM to select
Events, then Logs, then choosing the appropriate log from the list provided. The log data is displayed in a manner
suitable for the user to interpret the information.
If the access level of the requested action is greater than the current user’s access level, the requested action is
denied. This control prevents the unauthorized deletion of the IDS data log contents. Deletion can be performed by
using the ‘clear’ CLI command or by using the Navigation Tree of the LSM to select Events, then Logs, then
choosing the appropriate log from the list provided. Administrator and Super-user roles have the ability to clear the
IDS data logs.
6.1.3.3 IDS Data Storage (IDS_STG_EXT.1, IDS_STG_EXT.2)
The TOE records the collected IDS data into two logs: the Block log and the Alert log. The Block log holds records
associated with filters that block traffic and the Alert log holds records associated with notification filters.
As discussed in Section 6.1.1 in relation to the Audit logs, the TOE maintains a historical log file and a current log
file for both the Block log and the Alert log. Whenever either current log file becomes full an alarm is sent.
The deletion of the historical log files that form the IDS data when the corresponding current log file becomes full
effectively overwrites the oldest IDS data records. The alarm that is sent when a new current log file is created takes
the form of an email alarm that is sent to a specified user. The TOE also writes a new log record to the Alert log
when new log files are created.
Notification contacts for alarms (syslog, email, SNMP, LSM) can be created in the Management Interface.
6.1.4 Traffic Management
In addition to IPS filtering described in Section 6.1.3, the TSE component provides traffic management filters that
can be applied to traffic on selected segments, allowing the TOE to enforce an information flow control policy and
operate as a firewall. Traffic management filters are managed within the context of a Traffic Management Profile
that identifies the segment to which the Profile applies.
6.1.4.1 Information Flow Control Policy and Functions (FDP_IFC.1, FDP_IFF.1)
Traffic management filters are specified in terms of the following attributes of network packets:
 Source address and port—the source IP address and source port for traffic managed by the filter.
 Destination address and port—the destination IP address for traffic managed by the filter
 Protocol—specifies the protocol the filter checks for. It can have the following values: IP; ICMP; TCP; and
UDP
 Action—defines how the TOE will handle traffic that triggers the filter. The possible actions are:
o Block—traffic that satisfies the filter criteria is blocked
o Allow—traffic that satisfies the filter criteria is allowed; such traffic is still subjected to IPS
filtering
o Rate Limit—traffic that meets the filter criteria is limited to a specified rate; such traffic is still
subjected to IPS filtering
o Trust—traffic that meets the filter criteria is passed through the TOE without IPS filtering.
IP addresses can be specified in Classless Inter Domain Routing (CIDR) format or as ‘any’. Ports can be specified as
a specific port number or as ‘any’. A traffic management filter comprises a prioritized list of one or more rules
specifying the values for the information attributes to be checked against and the action to take if a network packet
matches all the values in the rule. When a traffic management filter is configured for a network segment, all traffic
arriving at the TOE from that segment is compared against each rule in the filter, in priority order, until a match is
47
found or all rules have been checked. A network packet that matches all of the criteria specified in a rule is handled
based on the Action specified in the rule (Block, Allow, Rate Limit, or Trust). If a network packet does not trigger
any of the rules specified in the traffic management filter, it is allowed to continue on but is subject to IPS filtering.
On the NX models, the Super-user and Administrator can configure inspection bypass rules, which can allow traffic
to pass through the TOE without being subject to either traffic management or IPS filtering. Rules can be specified
in terms of source address and port, destination address and port, and protocol. Source and destination IP addresses
can be specified in CIDR format. Inspection bypass rules can be specified for specific network segments and ports
on the TOE appliance, or for all segments and ports.
The section titled “Traffic Management Profiles” in Chapter 4 of HP TippingPoint Local Security Manager User’s
Guide describes how to create and manage traffic management profiles and filters.
6.1.5 Security Management
6.1.5.1 Security Management Roles (FMT_SMR.1)
The TOE implements the following security roles:
 Super-user—has full access to the TOE. This role is able to manage the users of the TOE and to view and
modify the configuration of the TOE and the logs
 Administrator—has full access to most functions of the TOE. This role is able to view and modify the
configuration of the TOE (with the exception of managing user accounts) and the logs (with the exception
of selection of auditable events and viewing and clearing the Audit log)
 Operator—has read-only access to the TOE. This role is able to view the System data logs (but not the
Audit logs) and the configuration of the TOE, but is not permitted to modify any information other than his
or her own password.
The TOE provides two interfaces by which administrative users can access and manage the TOE: the Local Security
Manager (LSM), a web-based GUI; and a Command Line Interface (CLI). These interfaces together comprise the
Management Interface component of the TOE.
A user account cannot be created without an associated role—if this is attempted, the action is denied and the
Security Management security function enforces that a role be specified before proceeding with account creation.
Super-users are permitted to change their role or the roles of other users. This is accomplished either by using the
‘configure user’ CLI command or by navigating to the AuthenticationUser List page of the LSM. These two
options will also allow a user to display a list of all users and their associated roles.
6.1.5.2 Security Management Functions (FMT_SMF.1)
The Security Management security function provides the following management capabilities:
 Modify the set of audited events
 Modify the Failed Login Action
 Modify the Security Level
 Modify user passwords
 Modify system time
 Create, modify and delete notification contacts
 Create, modify and delete user accounts
 Create, modify and delete traffic management filters
 Create, modify and delete inspection bypass rules (NX models only)
 Clear the audit trail and IDS data
 Modify the behavior of the IDS data collection, analysis and reaction functions (by managing IPS filters
and action sets).
The management capabilities are provided by the TippingPoint Operating System and are accessed through the
Management Interface.
48
6.1.5.3 Management of Security Functions, and TSF Data (FMT_MOF.1, FMT_MTD.1(*))
The Security Management security function restricts the ability to modify the behavior of the functions of IDS data
collection, analysis and reaction to users associated with the Administrator or Super-user role. These roles have the
ability to modify the security policies that determine how IDS data is analyzed, displayed, and reacted to. Users with
the Operator role only have the ability to view the security policies that affect how the IDS data is analyzed,
displayed, and reacted to.
The Security Management security function enforces the following restrictions on security roles.
Management function Role Required to perform action
Modify set of audited events Administrator, Super-user
Modify the Failed Login Action Super-user
Modify the Security Level Super-user
Modify user passwords Each user can modify their own password, regardless of
role. Only the Super-user can modify another user’s
password.
Modify system time Super-user
Create, modify and delete notification contacts Administrator, Super-user
Create, modify and delete user accounts Super-user
Create, modify and delete traffic management filters Administrator, Super-user
Create, modify and delete inspection bypass rules Administrator, Super-user
Clear the audit trail Super-user
Clear the IDS data Administrator, Super-user
Manage IPS filters and action sets Administrator, Super-user
Table 9: Management Functions and Role Restrictions
The Management Interface controls access to the security functions provided by the TOE. Access to commands is
based on the user’s role. Commands that the user is not authorized to perform are not recognized and are
inaccessible. Furthermore, any commands that are unavailable based upon the user’s authorization will not be
displayed to the user.
6.1.6 TSF Protection
6.1.6.1 Reliable Time Stamps (FPT_STM.1)
The TOE maintains time internally using a CMOS clock and this internal time is used as the source for the
timestamp recorded in each audit record and collected IDS data record.
6.1.7 Trusted Path
6.1.7.1 Trusted Path (FTP_TRP.1)
The TOE provides a trusted path for remote administrative users of the TOE to communicate with the TOE. The
trusted path is implemented over the network management port using HTTPS (i.e., SSL over HTTP) for access to
the LSM and SSHv2 for access to the CLI. Remote users initiate the trusted path by establishing an HTTPS
connection (using a supported web browser) or SSH session (using an SSH client). The trusted path is used for
initial authentication and all subsequent administrative actions. The use of HTTPS or SSHv2 ensures all
communication over the trusted path is protected from disclosure and undetected modification.
49
The TOE uses SSLimSecure 3.0 from TeamF1 for its SSL support. This library is based on OpenSSL 0.9.8b, was
ported by TeamF1 to run under vxWorks, and has been subsequently patched. The TOE uses SSHield 2.2.0 from
TeamF1 for its SSH support. This library is based on OpenSSH 3.5p1, was ported by TeamF1 to run under
vxWorks, and has also been subsequently patched.
The TOE supports two modes of FIPS operation—crypto and full. When configured in either FIPS mode, the TOE
will allow only FIPS 140-2 approved cryptographic algorithms to be used. When configured in ‘full’ FIPS mode, the
following additional restrictions are enforced: HTTP and telnet access cannot be enabled; only passwords that meet
Security Level 1 or Security Level 2 are allowed; the debug shell cannot be enabled; restoring snapshots taken when
the TOE was not in Full FIPS mode is not allowed; and restoring an older OS that is non FIPS-compliant is not
allowed.
The TOE has a set list of supported algorithms and bit lengths for SSL. The client negotiates with the TOE to find a
match that it also supports—this occurs without administrator intervention. Note that algorithms marked with a ‘+’
are not available in FIPS mode:
 Symmetric:
o AES (128-bit, 256-bit)
o DES (56-bit)+
o 3DES (168-bit)
o RC2 (variable)+
o RC4 (variable)+
 Asymmetric:
o RSA
o DSA.
The TOE has a set list of supported algorithms and bit lengths for SSH. The client negotiates with the TOE to find a
match that it also supports—this occurs without administrator intervention. Note that algorithms marked with a ‘+’
are not available in FIPS mode:
 3DES (168-bit)
 Blowfish (variable)+
 AES (128-bit, 192-bit, 256-bit).
The TOE requires the client to provide the same capability in order to access the TOE via HTTPS or SSHv2.
50
7. Rationale
This section provides the rationale for completeness and consistency of the Security Target. The rationale addresses
the following areas:
 Security Objectives
 Security Functional Requirements
 Security Assurance Requirements
 Requirement Dependencies
 TOE Summary Specification.
7.1 Security Objectives Rationale
This section shows that all secure usage assumptions and threats are completely covered by security objectives for
the TOE or operational environment. In addition, each objective counters or addresses at least one assumption or
threat.
T.COMPROMISE
T.LOSSOF
T.PRIVILEGE
T.CONFIG
T.INFLUX
T.ACCOUNT
T.MISUSE
T.ACCIDENT
T.MALICE
A.ACCESS
A.PROTECT
A.MANAGE
A.NOEVIL
O.SENSOR X X X
O.ANALYZER X X X
O.RESPONSE X X X
O.REVIEW X X X
O.ADMIN X
O.ACCESS X X X
O.I&A X X
O.AUDIT X
O.INTEGRITY X
O.STORAGE X
O.TRAFFIC X X X
OE.INSTALL X
OE.PHYSICAL X
OE.PERSONNEL X X
OE.CONFID X X
Table 10: Security Problem Definition to Security Objective Correspondence
7.1.1.1 T.COMPROMISE
An unauthorized user may attempt to compromise the confidentiality or integrity of the data collected and
produced by the TOE by bypassing a security mechanism.
This threat is countered by the following security objectives:
 O.I&A—addresses this threat by ensuring that users are identified and authenticated before gaining access
to the capabilities of the TOE.
51
 O.ACCESS—supports O.I&A address this threat by ensuring that users are restricted in how they can
access the management capabilities of the TOE, based on their assigned authorization level.
 OE.CONFID—supports O.I&A by ensuring the operational environment provides capabilities to protect
the confidentiality of data communicated by administrative users (including authentication data) to the
TOE.
7.1.1.2 T.LOSSOF
An unauthorized user may attempt to remove or destroy data collected and produced by the TOE.
This threat is countered by the following security objectives:
 O.INTEGRITY—addresses this threat by ensuring the TOE protects stored audit records and IDS data from
unauthorized modification or deletion.
7.1.1.3 T.PRIVILEGE
An unauthorized user may gain access to the TOE and exploit system privileges to gain access to TOE
security functions and data.
This threat is countered by the following security objectives:
 O.I&A—addresses this threat by ensuring that users are identified and authenticated before gaining access
to the capabilities of the TOE.
 O.ACCESS—supports O.I&A address this threat by ensuring that users are restricted in how they can
access the management capabilities of the TOE, based on their assigned authorization level.
 OE.CONFID—supports O.I&A by ensuring the operational environment provides capabilities to protect
the confidentiality of data communicated by administrative users (including authentication data) to the
TOE.
7.1.1.4 T.CONFIG
An unauthorized user may inappropriately change the configuration of the TOE causing potential
intrusions to go undetected.
This threat is countered by the following security objectives:
 O.ACCESS—addresses this threat by ensuring that users are restricted in how they can access the
management capabilities of the TOE, based on their assigned authorization level.
 O.ADMIN—supports O.ACCESS address this threat by ensuring the TOE provides capabilities to enable
effective management of the TOE’s functions.
7.1.1.5 T.INFLUX
An unauthorized user may cause malfunction of the TOE by creating an influx of data that the TOE cannot
handle.
This threat is countered by the following security objectives:
 O.STORAGE—addresses this threat by ensuring the TOE is able to automatically manage storage of audit
records and IDS data in the event that available storage is exhausted.
7.1.1.6 T.ACCOUNT
Unauthorized attempts to access TOE data or security functions may go undetected.
This threat is countered by the following security objectives:
 O.AUDIT—addresses this threat by ensuring the TOE is able to generate audit records of security relevant
events and provides capabilities for effective review of stored audit records.
52
7.1.1.7 T.MISUSE
Unauthorized accesses and activity indicative of misuse may occur on an IT System the TOE monitors.
This threat is countered by the following security objectives:
 O.SENSOR, O.ANALYZER, O.RESPONSE, O.REVIEW, O.TRAFFIC—these objectives work together
to counter this threat by ensuring the TOE is able to collect all network packets flowing between network
segments to which it is connected, analyzing those network packets and network flows in order to identify
intrusion attempts, responding to identified intrusion attempts, and providing capabilities to review the
results of the TOE’s analysis and response. The TOE ca also filter network traffic based on combinations of
protocol, IP address and port.
7.1.1.8 T.ACCIDENT
Inadvertent activity and access may occur on an IT System the TOE monitors.
This threat is countered by the following security objectives:
 O.SENSOR, O.ANALYZER, O.RESPONSE, O.REVIEW, O.TRAFFIC—these objectives work together
to counter this threat by ensuring the TOE is able to collect all network packets flowing between network
segments to which it is connected, analyzing those network packets and network flows in order to identify
intrusion attempts, responding to identified intrusion attempts, and providing capabilities to review the
results of the TOE’s analysis and response. The TOE ca also filter network traffic based on combinations of
protocol, IP address and port.
7.1.1.9 T.MALICE
Malicious activity, such as introductions of Trojan horses and viruses, may occur on an IT System the TOE
monitors.
This threat is countered by the following security objectives:
 O.SENSOR, O.ANALYZER, O.RESPONSE, O.REVIEW, O.TRAFFIC—these objectives work together
to counter this threat by ensuring the TOE is able to collect all network packets flowing between network
segments to which it is connected, analyzing those network packets and network flows in order to identify
intrusion attempts, responding to identified intrusion attempts, and providing capabilities to review the
results of the TOE’s analysis and response. The TOE ca also filter network traffic based on combinations of
protocol, IP address and port.
7.1.1.10 A.ACCESS
The TOE has access to all the IT System data it needs to perform its functions.
This assumption is satisfied by the following security objectives:
 OE.INSTALL—this objective satisfies the assumption by ensuring the TOE is installed, managed, and
operated in accordance with its guidance documentation, which describes how to install and manage the
TOE securely such that it is able to monitor network segments for attempted intrusions.
7.1.1.11 A.PROTECT
The TOE hardware and software critical to security policy enforcement will be protected from
unauthorized physical modification.
This assumption is satisfied by the following security objectives:
 OE.PHYSICAL—this objective satisfies the assumption by ensuring the TOE is protected from physical
attack.
7.1.1.12 A.MANAGE
There will be one or more competent individuals assigned to manage the TOE and the security of the
information it contains.
53
This assumption is satisfied by the following security objectives:
 OE.PERSONNEL—this objective satisfies the assumption by ensuring those assigned as authorized
administrators are properly trained in operating the TOE.
7.1.1.13 A.NOEVIL
The authorized administrators are not careless, willfully negligent, or hostile, and will follow and abide by
the instructions provided by the TOE documentation.
This assumption is satisfied by the following security objectives:
 OE.PERSONNEL—this objective satisfies the assumption by ensuring those assigned as authorized
administrators are carefully selected for the job and are properly trained in operating the TOE.
7.2 Security Functional Requirements Rationale
All security functional requirements identified in this Security Target are fully addressed in this section and each is
mapped to the objective it is intended to satisfy. Table 11 summarizes the correspondence of functional
requirements to TOE security objectives.
O.SENSOR
O.ANALYZER
O.RESPONSE
O.REVIEW
O.ADMIN
O.ACCESS
O.I&A
O.AUDIT
O.INTEGRITY
O.STORAGE
O.TRAFFIC
FAU_GEN.1 X
FAU_SAR.1 X X
FAU_SAR.2 X
FAU_SAR.3 X
FAU_SEL.1 X
FAU_STG.2 X X
FAU_STG.4 X
FDP_IFC.1 X
FDP_IFF.1 X
FIA_AFL.1 X
FIA_ATD.1 X X
FIA_SOS.1 X
FIA_UAU.2 X
FIA_UID.2 X
FMT_MOF.1 X
FMT_MTD.1(*) X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_STM.1 X X
FTP_TRP.1 X
IDS_ANL_EXT.1 X
IDS_RCT_EXT.1 X
IDS_RDR_EXT.1 X X
IDS_SDC_EXT.1 X
IDS_STG_EXT.1 X X
IDS_STG_EXT.2 X
Table 11: Objectives to Requirement Correspondence
54
7.2.1.1 O.SENSOR
The TOE shall collect IDS data in the form of network packets flowing between network segments to which
it is connected.
The following security functional requirements contribute to satisfying this security objective:
 IDS_SDC_EXT.1—the ST includes IDS_SDC_EXT.1 to specify the capability to collect information from
targeted IT System resource(s). In the case of the TOE, the capability is specifically to collect network
packets for subsequent analysis.
7.2.1.2 O.ANALYZER
The TOE shall analyze collected IDS data in order to identify intrusion attempts and shall be able to record
the results of its analysis.
The following security functional requirements contribute to satisfying this security objective:
 IDS_ANL_EXT.1—the ST includes IDS_ANL_EXT.1 to specify the capability to perform statistical and
signature analysis on collected IDS data (i.e., network packets) and to record results of that analysis.
 FPT_STM.1—the ST supports IDS_ANL_EXT.1 by including FPT_STM.1 to specify the capability for the
TOE to provide reliable time stamps, which are used by the TOE’s analyzer capability when generating
analysis results.
7.2.1.3 O.RESPONSE
The TOE shall respond to intrusion attempts it identifies based on its configuration.
The following security functional requirements contribute to satisfying this security objective:
 IDS_RCT_EXT.1—the ST includes IDS_RCT_EXT.1 to specify the capability to respond to identified
intrusion attempts by generating an alarm and taking action (Block or Permit) based on the configuration of
the IDS filter that was triggered.
7.2.1.4 O.REVIEW
The TOE shall provide capabilities for effective review of stored IDS data.
The following security functional requirements contribute to satisfying this security objective:
 IDS_RDR_EXT.1—the ST includes IDS_RDR_EXT.1 to specify capabilities for authorized users to
review the results generated by the TOE’s analysis functions.
7.2.1.5 O.ADMIN
The TOE shall include capabilities to enable effective management of its functions and data.
The following security functional requirements contribute to satisfying this security objective:
 FMT_SMF.1—the ST includes FMT_SMF.1 to specify the security management functions that are
required to provide the capabilities for effective management of the TOE’s functions and data.
7.2.1.6 O.ACCESS
The TOE shall restrict access to its management capabilities based on the authorization level it assigns to
identified and authenticated users.
The following security functional requirements contribute to satisfying this security objective:
 FMT_SMR.1—the ST includes FMT_SMR.1 to specify the security management roles that are provided by
the TOE and the capability to associate users with roles.
 FIA_ATD.1—the ST supports FMT_SMR.1 by including FIA_ATD.1 to ensure the Access Level (i.e.,
role) security attribute is associated with individual users.
55
 FMT_MOF.1—the ST includes FMT_MOF.1 to specify the restrictions on which roles are able to manage
the TOE’s IDS data collection, analysis and reaction functions.
 FMT_MTD.1(*)—the ST includes iterations FMT_MTD.1 to specify the restrictions on which roles are
able to manage TSF data.
 FAU_SAR.1, FAU_SAR.2—the ST includes FAU_SAR.1 to specify which roles are to be able to read data
from stored audit records, and FAU_SAR.2 to specify that only those roles will have that specific
capability.
 IDS_RDR_EXT.1—the ST includes IDS_RDR_EXT.1 to specify which roles are to be able to read stored
IDS data, and to specify that only those roles will have that capability.
7.2.1.7 O.I&A
The TOE shall identify and authenticate users prior to allowing access to its functions and data.
The following security functional requirements contribute to satisfying this security objective:
 FIA_UID.2, FIA_UAU.2—the ST includes FIA_UID.2 and FIA_UAU.2 to specify that users must be
successfully identified and authenticated by the TOE before being able to perform any other TSF-mediated
actions.
 FIA_SOS.1—the ST supports FIA_UAU.2 by including FIA_SOS.1 to specify a quality metric to ensure
authentication data is resistant to brute-force guessing.
 FIA_AFL.1—the ST supports FIA_UAU.2 by including FIA_AFL.1 to specify a mechanism for detecting
multiple consecutive failed authentication attempts and the action the TOE is to take when this occurs. This
capability also provides resistance to brute-force guessing of user authentication data.
 FTP_TRP.1—the ST supports FIA_UAU.2 by including FTP_TRP.1 to specify mechanisms for a trusted
path between remote users and the TOE that protects data (including authentication data) from disclosure
when transmitted between the remote user and the TOE, and also provides assurances to the user that they
are indeed communicating with the TOE.
 FIA_ATD.1—the ST supports FIA_UID.2 and FIA_UAU.2 by including FIA_ATD.1 to ensure user
identity and authentication data security attributes are associated with individual users.
7.2.1.8 O.AUDIT
The TOE shall generate audit records of security relevant events and provide capabilities for effective
review of stored audit records.
The following security functional requirements contribute to satisfying this security objective:
 FAU_GEN.1—the ST includes FAU_GEN.1 to specify the capability to generate audit records of security
relevant events, and to specify the specific events to be audited and the content of generated audit records
of those events.
 FAU_SAR.1, FAU_SAR.3—the ST includes FAU_SAR.1 and FAU_SAR.3 to specify capabilities to
review the contents of the stored audit records and to be able to sort records being reviewed.
 FAU_SEL.1—the ST supports FAU_GEN.1 by including FAU_SEL.1 to specify the capability to
determine the set of auditable events that are to be audited by the TOE.
 FPT_STM.1—the ST supports FAU_GEN.1 by including FPT_STM.1 to specify the capability for the
TOE to provide reliable time stamps, which are used by the TOE when generating audit records.
7.2.1.9 O.INTEGRITY
The TOE shall protect stored audit records and IDS data from unauthorized modification or deletion.
56
The following security functional requirements contribute to satisfying this security objective:
 FAU_STG.2, IDS_STG_EXT.1—the ST includes FAU_STG.2 and IDS_STG_EXT.1 to specify that stored
audit records and stored IDS data are to be protected from unauthorized modification or deletion.
7.2.1.10 O.STORAGE
The TOE shall provide capabilities to automatically manage stored audit records and IDS data in the event
that available storage space is exhausted.
The following security functional requirements contribute to satisfying this security objective:
 FAU_STG.2, FAU_STG.4, IDS_STG_EXT.1, IDS_STG_EXT.2—the ST includes FAU_STG.2,
FAU_STG.4, IDS_STG_EXT.1 and IDS_STG_EXT.2 to specify the TOE behavior in the event the storage
available for audit records and IDS data is exhausted and mechanisms for ensuring a specified amount of
audit records and IDS data will still be available when this occurs.
7.2.1.11 O.TRAFFIC
The TOE shall provide a capability to filter network traffic based on combinations of protocol, IP address
and port.
The following security functional requirements contribute to satisfying this security objective:
 FDP_IFC.1—the ST includes FDP_IFC.1 to specify the scope of control of the Traffic Management
information flow control SFP. This SFP mediates the passing of traffic through the TOE between
unauthenticated external IT entities. When activated on a network segment, it is applied to traffic before the
IPS filtering capabilities and enables the TOE to behave as a firewall as well as an IPS device.
 FDP_IFF.1—the ST includes FDP_IFF.1 to specify the information flow functionality to be provided by
the Traffic Management SFP. The TOE will act on traffic triggered by filters, based on the presumed
source and destination addresses, ports and protocol of the traffic and will perform the specified filter
action: Block; Allow; Rate Limit; or Trust.
7.3 Security Assurance Requirements Rationale
EAL 3 was selected as the assurance level because the TOE is a commercial product whose users require a moderate
level of independently assured security. The TOE is targeted at an environment with good physical access security
where it is assumed that attackers will have Basic attack potential. Augmentation was chosen to provide the added
assurance that is gained by defining flaw remediation and flaw reporting procedures. Therefore, the target assurance
level of EAL 3 augmented with ALC_FLR.2 is appropriate for such an environment.
7.4 Requirement Dependency Rationale
The following table identifies the SFRs claimed in the ST, their dependencies as defined in CC Part 2 or in the
Extended Components Definition, and how the dependency is satisfied in the ST. If the dependency is satisfied by
inclusion in the ST of the appropriate dependent SFR, this is identified. Otherwise, rationale is provided below the
table.
Requirement Dependencies How Satisfied
FAU_GEN.1 FPT_STM.1 FPT_STM.1
FAU_SAR.1 FAU_GEN.1 FAU_GEN.1
FAU_SAR.2 FAU_SAR.1 FAU_SAR.1
FAU_SAR.3 FAU_SAR.1 FAU_SAR.1
FAU_SEL.1 FAU_GEN.1, FMT_MTD.1 FAU_GEN.1, FMT_MTD.1(1)
FAU_STG.2 FAU_GEN.1 FAU_GEN.1
FAU_STG.4 FAU_STG.1 FAU_STG.2 (hierarchical to FAU_STG.1)
FDP_IFC.1 FDP_IFF.1 FDP_IFF.1
FDP_IFF.1 FDP_IFC.1, FMT_MSA.3 FDP_IFC.1, FMT_MTD.1 (see rationale below)
FIA_AFL.1 FIA_UAU.1 FIA_UAU.2 (hierarchical to FIA_UAU.1)
57
Requirement Dependencies How Satisfied
FIA_ATD.1 None n/a
FIA_SOS.1 None n/a
FIA_UAU.2 FIA_UID.1 FIA_UID.2 (hierarchical to FIA_UID.1)
FIA_UID.2 None n/a
FMT_MOF.1 FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1
FMT_MTD.1(*) FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1
FMT_SMF.1 None n/a
FMT_SMR.1 FIA_UID.1 FIA_UID.2 (hierarchical to FIA_UID.1)
FPT_STM.1 None n/a
FTP_TRP.1 None None
IDS_ANL_EXT.1 IDS_SDC_EXT.1 IDS_SDC_EXT.1
IDS_RCT_EXT.1 IDS_ANL_EXT.1 IDS_ANL_EXT.1
IDS_RDR_EXT.1 IDS_SDC_EXT.1, IDS_ANL_EXT.1 IDS_SDC_EXT.1, IDS_ANL_EXT.1
IDS_SDC_EXT.1 None n/a
IDS_STG_EXT.1 IDS_SDC_EXT.1, IDS_ANL_EXT.1 IDS_SDC_EXT.1, IDS_ANL_EXT.1
IDS_STG_EXT.2 IDS_STG_EXT.1 IDS_STG_EXT.1
Table 12: Requirement Dependencies
CC Part 2 defines a dependency of FDP_IFF.1 (Simple security attributes) on FMT_MSA.3 (Static attribute
initialization) to specify the nature of default values of security attributes used to enforce the SFP defined by
FDP_IFF.1. However, the Traffic Management SFP defined by FDP_IFF.1 does not provide for default security
attributes. The information security attributes are created outside the TOE boundary and the TOE has no control
over whether they are restrictive, permissive, or some other quality. The TOE’s ability to control information flow is
defined by traffic management filters and their rules, specified in terms of information security attributes (i.e.,
protocol, source address, source port, destination address, and destination port). Restrictions on the management of
these filters are specified by FMT_MTD.1, which therefore is shown to satisfy the dependency of FDP_IFF.1.
7.5 TOE Summary Specification Rationale
Section 6, the TOE Summary Specification, describes how the security functions of the TOE meet the claimed
SFRs. The following table provides a mapping of the SFRs to the security function descriptions to support the TOE
Summary Specification.
Security
Audit
Identification
and
Authentication
Intrusion
Detection
&
Prevention
Traffic
Management
Security
Management
TSF
Protection
Trusted
Path
FAU_GEN.1 X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_SAR.3 X
FAU_SEL.1 X
FAU_STG.2 X
FAU_STG.4 X
FDP_IFC.1 X
58
Security
Audit
Identification
and
Authentication
Intrusion
Detection
&
Prevention
Traffic
Management
Security
Management
TSF
Protection
Trusted
Path
FDP_IFF.1 X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_SOS.1 X
FIA_UAU.2 X
FIA_UID.2 X
FMT_MOF.1 X
FMT_MTD.1(*) X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_STM.1 X
FTP_TRP.1 X
IDS_ANL_EXT.1 X
IDS_RCT_EXT.1 X
IDS_RDR_EXT.1 X
IDS_SDC_EXT.1 X
IDS_STG_EXT.1 X
IDS_STG_EXT.2 X
Table 13: Security Functions vs. Requirements Mapping