Lancope StealthWatch Version 5.6.1
Security Target
Version 1.0
March 5, 2008
Prepared for:
Lancope, Inc.
3650 Brookside Parkway, Suite 400
Alpharetta, GA 30022
Prepared By:
Science Applications International Corporation
Common Criteria Testing Laboratory
7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046
Restricted Rights Legend
USE, DUPLICATION, OR DISCLOSURE IS SUBJECT TO THE RESTRICTIONS AS SET FORTH IN SUBPARAGRAPH [C][1][II] OF
THE RIGHTS IN TECHNICAL DATA AND COMPUTER SOFTWARE CLAUSE OF DFARS 252.227-7013 (OR AT FAR 52.227
[C][1]).
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
1. SECURITY TARGET INTRODUCTION...........................................................................................................4
1.1 SECURITY TARGET OVERVIEW AND ORGANIZATION......................................................................................4
1.2 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4
1.3 CONFORMANCE CLAIMS.................................................................................................................................4
1.4 CONVENTIONS, TERMINOLOGY, ACRONYMS ..................................................................................................5
1.4.1 Conventions ...........................................................................................................................................5
1.4.2 Acronyms ...............................................................................................................................................5
2. TOE DESCRIPTION..........................................................................................................................................7
2.1 PRODUCT TYPE...............................................................................................................................................7
2.2 PRODUCT DESCRIPTION..................................................................................................................................7
2.3 PRODUCT FEATURES.......................................................................................................................................7
2.3.1 Detection and Protection.......................................................................................................................8
2.3.2 Intelligent Alarming...............................................................................................................................8
2.3.3 High-Speed Network Scalability............................................................................................................8
2.3.4 Security Policy Management and Enforcement.....................................................................................8
2.3.5 Forensics ...............................................................................................................................................8
2.3.6 Auto Tuning ...........................................................................................................................................8
2.4 SECURITY ENVIRONMENT TOE BOUNDARY...................................................................................................8
2.4.1 Physical Boundaries ..............................................................................................................................9
2.4.2 Logical Boundaries................................................................................................................................9
3. SECURITY ENVIRONMENT.........................................................................................................................13
3.1 ASSUMPTIONS ..............................................................................................................................................13
3.1.1 Intended Usage Assumptions...............................................................................................................13
3.1.2 Physical Assumptions ..........................................................................................................................13
3.1.3 Personnel Assumptions........................................................................................................................13
3.2 THREATS ......................................................................................................................................................13
3.2.1 TOE Threats.........................................................................................................................................13
3.2.2 IT System Threats ................................................................................................................................14
3.3 ORGANIZATIONAL SECURITY POLICIES ........................................................................................................14
4. SECURITY OBJECTIVES ..............................................................................................................................15
4.1 IT SECURITY OBJECTIVES FOR THE TOE......................................................................................................15
4.2 IT SECURITY OBJECTIVES FOR THE IT ENVIRONMENT .................................................................................15
4.3 SECURITY OBJECTIVES FOR THE ENVIRONMENT...........................................................................................15
5. IT SECURITY REQUIREMENTS..................................................................................................................16
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................16
5.1.1 Security Audit (FAU) ...........................................................................................................................16
5.1.2 Identification and Authentication (FIA)...............................................................................................18
5.1.3 Security Management (FMT)...............................................................................................................18
5.1.4 Protection of the TOE Security Functions (FPT) ................................................................................19
5.1.5 Intrusion Detection System (IDS) ........................................................................................................19
5.2 IT ENVIRONMENT SECURITY FUNCTIONAL REQUIREMENTS.........................................................................20
5.2.1 Protection of the TOE Security Functions (FPT) ................................................................................20
5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................21
5.3.1 Configuration management (ACM) .....................................................................................................21
5.3.2 Delivery and operation (ADO) ............................................................................................................21
5.3.3 Development (ADV).............................................................................................................................22
5.3.4 Guidance documents (AGD)................................................................................................................23
5.3.5 Life cycle support (ALC)......................................................................................................................24
5.3.6 Tests (ATE) ..........................................................................................................................................24
5.3.7 Vulnerability assessment (AVA)...........................................................................................................25
2
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
6. TOE SUMMARY SPECIFICATION..............................................................................................................27
6.1 TOE SECURITY FUNCTIONS..........................................................................................................................27
6.1.1 Security Audit.......................................................................................................................................27
6.1.2 Identification and Authentication ........................................................................................................28
6.1.3 Security Management ..........................................................................................................................29
6.1.4 Protection of the TOE Security Functions...........................................................................................30
6.1.5 Intrusion Detection System ..................................................................................................................31
6.2 TOE SECURITY ASSURANCE MEASURES......................................................................................................34
6.2.1 Configuration Management.................................................................................................................34
6.2.2 Delivery and Operation .......................................................................................................................34
6.2.3 Development ........................................................................................................................................35
6.2.4 Guidance documents............................................................................................................................35
6.2.5 Life cycle support.................................................................................................................................36
6.2.6 Tests.....................................................................................................................................................36
6.2.7 Vulnerability assessment......................................................................................................................36
7. PROTECTION PROFILE CLAIMS...............................................................................................................38
8. RATIONALE.....................................................................................................................................................39
8.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................39
8.1.1 Security Objectives Rationale for the TOE and Environment..............................................................39
8.2 SECURITY REQUIREMENTS RATIONALE........................................................................................................44
8.2.1 Security Functional Requirements Rationale ......................................................................................45
8.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE....................................................................................48
8.4 REQUIREMENT DEPENDENCY RATIONALE....................................................................................................48
8.5 EXPLICITLY STATED REQUIREMENTS RATIONALE........................................................................................48
8.6 STRENGTH OF FUNCTION RATIONALE ..........................................................................................................49
8.7 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................49
8.8 PP CLAIMS RATIONALE................................................................................................................................50
LIST OF TABLES
Table 1 Security Functional Components....................................................................................................................16
Table 2 Auditable Events ............................................................................................................................................17
Table 3 System Events ................................................................................................................................................19
Table 4 Security Functional Components....................................................................................................................20
Table 5 EAL 2 augmented with ALC_FLR.2 Assurance Components.......................................................................21
Table 6 Environment to Objective Correspondence....................................................................................................40
Table 7 Objective to Requirement Correspondence ....................................................................................................45
Table 8 Requirement Dependencies Rationale............................................................................................................48
Table 9 Security Functions vs. Requirements Mapping ..............................................................................................50
3
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
1. Security Target Introduction
This section provides a Security Target Overview and Organization, identifies the Security Target and Target of
Evaluation (TOE), ST conventions terminology & acronyms, and ST conformance claims. The TOE is provided by
Lancope, Inc.
1.1 Security Target Overview and Organization
The Lancope StealthWatch TOE is a network based intrusion detection system that monitors a computer
communications network for activity that may inappropriately affect the network's assets. The TOE includes sensors
that collects information regarding network activity and forwards that information to an analysis engine. The
analysis engine performs flow based analysis and reporting of the collected information. The Lancope StealthWatch
TOE provides the following security services: audit, identification and authentication, security management,
protection of the TOE Security Functions (TSF), and intrusion detection.
The Security Target contains the following additional sections:
• TOE Description (Section 2)
• Security Environment (Section 3)
• Security Objectives (Section 4)
• IT Security Requirements (Section 5)
• TOE Summary Specification (Section 6)
• Protection Profile Claims (Section 7)
• Rationale (Section 8)
1.2 Security Target, TOE and CC Identification
ST Title – Lancope StealthWatch Version 5.6.1 Security Target
ST Version – Version 1.0
ST Date –March 5, 2008
TOE Identification – Lancope StealthWatch NC Appliance (Model numbers M45. M250, M250X, G1, G1C, G1X,
G1CX, and G1CFX) and StealthWatch Xe Appliance (Model numbers XE1000 and XE2000) containing
StealthWatch version 5.6.1 and StealthWatch Management Console version 5.6.1.
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 2.3 August 2005.
1.3 Conformance Claims
This TOE is conformant to the following CC specifications:
• Common Criteria for Information Technology Security Evaluation Part 2: Security functional
requirements, Version 2.3, August 2005.
• Part 2 Extended
• Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
requirements, Version 2.3, August 2005.
• Part 3 Conformant
4
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• EAL 2 augmented with ALC_FLR.2
• This TOE is conformant to the following Protection Profile (PP):
• Intrusion Detection System Protection Profile, Version 1.6, April 4, 2006 (IDSSPP)
• Strength of Function Claim
• The minimum strength of function level for the security functional requirements is SOF-basic
1.4 Conventions, Terminology, Acronyms
This section specifies the formatting information used in the Security Target.
1.4.1 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 the ST,
iteration is indicated by a letter placed at the end of the component. For example FDP_ACC.1a
and FDP_ACC.1b indicate that the ST includes two iterations of the FDP_ACC.1 requirement, a
and b.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [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 …”).
o Note that operations already performed in the corresponding Protection Profile are not identified
in this Security Target.
• Explicitly stated Security Functional Requirements (i.e., those not found in Part 2 of the CC) are identified
with “(EXP)”.
• Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.4.2 Acronyms
The acronyms used within this Security Target are expanded below:
AGD Administrator Guidance Document
CC Common Criteria
CI Concern Index
DOS Denial Of Service
EAL Evaluation Assurance Level
HTTP Hyper Text Transmission Protocol
HTTPS Hyper Text Transmission Protocol, Secure
ICMP Internet Control Message Protocol
ID Identifier
5
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
IDS Intrusion Detection System
IDSSPP IDS System Protection Profile
I/O Input/Output
NIST National Institute of Standards and Technology
NTP Network Time Protocol (RFC 1305)
PGP Pretty Good Privacy
PP Protection Profile
RPC Remote Procedure Call
SMC StealthWatch Management Console
SF Security Functions
SFR Security Functional Requirement
ST Security Target
SW StealthWatch Appliance
SW NC StealthWatch NC Appliance
SW Xe StealthWatch Xe Appliance
TCP/IP Transmission Control Protocol/Internet Protocol
TOE Target of Evaluation
TOS Type of Service
TSF TOE Security Functions
TSP TOE Security Policy
TSC TSF Scope of Control
UDP User Datagram Protocol
UI User Interface
URI Uniform Resource Identifier
6
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
2. TOE Description
The TOE is defined as the Lancope StealthWatch NC appliance (Model numbers M45. M250, M250X, G1, G1C,
G1X, G1CX, and G1CFX) and the StealthWatch Xe appliance (Model numbers XE1000 and XE2000) containing
StealthWatch version 5.6.1 intrusion detection software and the StealthWatch Management Console (SMC) version
5.6.1.
These products are designed and manufactured by Lancope Incorporated, located at 3650 Brookside Parkway, Suite
400, Alpharetta, Georgia, 30022.
The difference between the StealthWatch NC appliance and the StealthWatch Xe appliance products is that the NC
appliance monitors (i.e., sniffs) network traffic as it passes by a monitoring point while the Xe appliance receives
summary network statistics forwarded from network infrastructure devices that support NetFlow (e.g., Cisco and
Juniper routers and switches) or sFlow (e.g., Foundry routers and switches). In both cases, the TOE analyzes a
summary of the network traffic, where the NC generates its own summary based on applicable traffic and Xe
receives network data already summarized in the form of Netflow data. Note that the analytical capabilities vary
slightly due to the difference in data sources, but the claims in this ST are designed to address an intersection of the
overall capabilities of both the NC and Xe appliances.
The TOE appliances (NC or Xe) consist of applications and data files that provide the intrusion detection related
functions and associated security management functions, an Intel CPU-based hardware platform, and a Linux
operating system.
The TOE also includes the SMC which can optionally be used in conjunction with the other TOE appliances
identified above. The SMC is an appliance and a corresponding java application that executes on a commercial
workstation offering the ability to manage multiple appliances (NC or Xe) from a single interface. The java
application implements the SMC client interface and is downloaded onto the client’s machine every time a client
user logs into the SMC. This SMC client interface serves as a TOE management interface, offering a richer set of
security management and analytical capabilities that are not addressed in the context of this evaluation.
StealthWatch characterizes and analyzes the data that flows between Internet Protocol (IP) devices on the network to
differentiate abnormal network behavior from normal network behavior. Unlike signature based IDS systems,
StealthWatch detects out-of-profile behavior without examining the contents of each packet that traverses the
network.
2.1 Product Type
The TOE is a network-based intrusion detection system that monitors, records, analyzes, displays, detects and alerts
to security breaches and internal misuse on IP based networks. A behavior-based IDS operating on a proprietary
flow-based architecture, the TOE enables configurable alarming, provides network surveillance, is capable of
operating at near gigabit speeds, recognizes unknown threats and creates forensic data of network activity.
2.2 Product Description
StealthWatch approaches intrusion detection and network management through a behavior-based architecture that
provides protection from unknown threats, network policy management, activity tracking, and forensics tools for a
proactive approach to managing threats. StealthWatch characterizes and analyzes the data flow between Internet
Protocol (IP) devices to differentiate abnormal network behavior from normal behavior. StealthWatch should not be
confused with signature or protocol anomaly products.
2.3 Product Features
Lancope's StealthWatch expands intrusion detection beyond monitoring, detecting and responding to network
misuse in real-time. Unlike traditional IDS, StealthWatch detects out-of-profile behaviors without looking inside
each packet that transits the network.
7
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
2.3.1 Detection and Protection
StealthWatch is capable of recognizing attacks that typically evade intrusion detection systems such as
undocumented attacks, encrypted attacks, mutated signatures, internal hacking attempts, DoS attacks and Trojan
Horses. Unlike traditional IDS’s, StealthWatch does not rely on signature updates for attack recognition. Its
behavior-based recognition is available from the time it is introduced to the network architecture. In addition,
StealthWatch can trace the source of attacks, a useful tool when responding to attacks.
2.3.2 Intelligent Alarming
StealthWatch differentiates between legitimate and suspicious connections (probes). Instead of alarming system
administration on every ping, probe or scan, StealthWatch builds a profile of each suspicious host. By using an
algorithm to determine the level of suspicion, StealthWatch can filter out background noise associated with
traditional IDS tools. When the Concern Index of any particular host surpasses an administrator-defined threshold,
StealthWatch responds with customizable alerts.
2.3.3 High-Speed Network Scalability
By not having to search through strings of signature data, StealthWatch's flow-based engine can analyze network
traffic at bandwidth rates approaching 1 Gbps for the NC appliance and multiple gigabit network using the Xe
appliance. Furthermore, the StealthWatch appliances (NC or Xe) are passive monitoring devices that introduces zero
latency in the enterprise network.
2.3.4 Security Policy Management and Enforcement
An important component in a secure network environment is the ability to monitor services that are run on a daily
basis within the network. Maintaining a timely and complete picture of network services on each host is time
consuming and difficult using manual techniques, and traditional network management tools are also labor
intensive. StealthWatch provides a unique component in this arena, allowing security teams to set policies and
enforce them. With its service profiler, administrators can view the services running on the network, by host, to
determine which are appropriate and in profile. The appropriate system administrator will be notified whenever an
out-of-profile service is run.
2.3.5 Forensics
StealthWatch's patent-pending technology, called data flow analysis, provides a unique forensics tool - the network
flow log. By characterizing each flow that occurs on the network, StealthWatch can maintain a detailed and easy-to-
digest trail of information. This log is maintained for up to 30 days and can be archived for later use. In addition,
StealthWatch provides on-demand, daily and weekly reports of network activity.
2.3.6 Auto Tuning
The intent of StealthWatch is to reduce resource requirements and provide ease-of-use. StealthWatch requires
minimal configuration during implementation and its administrator interface allows administrators to quickly
determine the likelihood of possible malicious activity. The concern index and service profile capabilities are
meaningful metrics that combine to reduce false positives, and reduce the time required of administrators or security
teams.
2.4 Security Environment TOE Boundary
The TOE includes both physical and logical boundaries as defined in the following sections.
8
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
2.4.1 Physical Boundaries
The TOE is physically comprised of an Intel based hardware platform. The TOE utilizes process, disk, and memory
management services provided by the hardware to manage itself. The TOE also uses network communication
services to monitor network traffic and to communicate between the StealthWatch appliance (NC or Xe) and the
web-based administrative interface. The only security relevant aspect of the operating system and underlying
hardware is that they work together to provide reliable time information for use by the embedded StealthWatch
application software.
While not depicted below, the TOE also includes a StealthWatch Management Console (SMC). The SMC consists
of an appliance and a java application executing on a commercial workstation (in the IT environment) served by
(i.e., services are provided by the SMC appliance specifically to support the corresponding java application) the
SMC appliance. The java application is the SMC Client Interface, which is installed on the client’s computer every
time a client user logs into the SMC appliance via a web browser. The SMC client interacts with the SMC appliance
which in turn interacts with the other TOE appliances using TLSv1 on a network recommended to be dedicated for
this purpose. As a result, in addition to the network being monitored, the environment of the TOE includes the host
of the SMC Java application. Note that the SMC is not required for the secure use of any of the other TOE
appliances, but is an available option within the evaluated configuration.
The components that comprise StealthWatch appliances are the data collection interface, the flow based analysis
engine (including universal behavior, traffic patterns, and host profile data files), a forensic data repository, the
alarm generation component, the audit component (comprised of audit configuration, time generation, audit
generation, and an audit repository), and the administrative interface. The following figure provides a depiction of
the StealthWatch architecture.
Figure 1 StealthWatch Component Architecture
2.4.2 Logical Boundaries
The logical boundaries of the TOE fall into two categories. The first deals with security and administration of the
system as a whole (Security Audit, Identification and Authentication, Security Management, and Protection of
9
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
Security Functions). The second deals with collection and analysis of data regarding the network traffic on the
monitored networks (System Data Collection; System Data Analysis and Reaction; and System Data Review,
Availability, and Loss).
2.4.2.1 Security Audit
The TOE generates audit data for administrative and management actions taken on the system. This audit data is
unrelated to the system data that is collected about the monitored networks. The actions audited by the TOE include
start-up and shutdown of the system, system access, access to collected system and audit data, modification to the
auditing configuration, modifications to configuration data, and adding or removing users. Access to the security
audit log is provided through the administrative interface via a secure connection from a web browser or the SMC
java application. Note that each TOE appliance (including the SMC) records security management related audit
events so that they are associated with the user that is currently logged into that appliance.
The TOE protects its ability to continue recording audit data by periodically purging data, starting with the oldest
data first. In a situation where there is adequate storage space, audit data is preserved for 30 days. If storage space is
exhausted prior to 30 days, the oldest records are overwritten with new data on a first-in / first-out basis. This
ensures that there is always storage available for recording current audit events.
2.4.2.2 Identification and Authentication
All users of the TOE must enter a valid user identity and password before the user can access any TOE functionality.
In the context of StealthWatch appliances, there are 3 types of accounts, Administrator, Web Administrator, and
Technician. The Administrator and Web Administrator accounts have predefined identities (usernames), but
configurable authentication data. Administrative guidance defines the assignment of these user identities. The users
holding the authorised System Administrator role (see definition in section 2.4.2.3) can create the third type of
account: Technician. Technician accounts have a definable identity (username) and authentication data, but are
limited in the access allowed to configuration and audit data.
In the context of the SMC, there is a single pre-defined Administrator role. The SMC Administrator (and other SMC
users granted a role allowing the creation of users) can define additional users – assigning them unique identities,
passwords, and applicable SMC roles (see below).
2.4.2.3 Security Management
The TOE appliances (NC and Xe) provide a secure web-based (utilizing SSL) management interface for all
administrative tasks. Similarly, the SMC offers a robust administrative interface, utilizing a client (java) application
on the user’s own workstation, that allows the management of multiple TOE appliances from a single interface. The
SMC communications are all secured using TLS.1
In the context of StealthWatch appliances, there are three classes of user accounts supported by the TOE. Those
account classes have the following access rights defined:
• Administrator: Read/write access to the Administration/Appliance (hardware configuration) GUI as well as
all areas of the StealthWatch GUI, including the StealthWatch configuration screens.
• Web Administrator: Read/write access to all areas of the StealthWatch GUI, including the StealthWatch
configuration screens. The Web Administrator account does not have access to the
Administration/Appliance (hardware configuration) GUI.
• Technician: Read/write access to all areas of the StealthWatch GUI except for read-only access to the
StealthWatch configuration screens. Technicians do not have access to the Administration/Appliance
(hardware configuration) GUI.
1
The cryptography used in this product has not been FIPS certified nor has it been analyzed or tested to conform to
cryptographic standards during this evaluation. All cryptography has only been asserted as tested by the TOE
developer.
10
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
The Administrator and Web Administrator accounts are provided with the ability to modify the behavior of the
analysis and reporting functions by allowing them to modify the policies and thresholds of a host that is being
monitored by the TOE. The Administrator and Web Administrator classes comprise the authorised System
administrator role, while the Technician class comprises the authorised administrator role.
In the context of the SMC, there is a single pre-defined Administrator role. The SMC supports the notion of Data
and Function roles that can be assigned to users. Data roles dictate whether the associated user can only perform
read or query operations or alternately whether the user is allowed to make changes within the TOE. Function roles
serve to group specific TOE functions. SMC users are assigned a Data and Function role which together serve to
define (and limit) the set of TOE functions available to that user. SMC users can also be explicitly designated as
SMC administrators enabling the applicable administrative privileges.
2.4.2.4 Protection of the TOE Security Functions
The TOE appliances (including the SMC appliance) protect their own security functions through a variety of
mechanisms. One of the primary protections is that users must authenticate before any administrative operation can
be performed. The data transferred between the TOE and the administrative user is protected by using SSL for the
web-based interface and TLS for the SMC java application communications to encrypt and verify the
communication.
The data collection interface of the TOE is protected from the monitored network by operating in a completely
passive mode. The TOE does not respond to any traffic received from the monitored networks. The TOE cannot
receive any management requests or management input from the monitored network interfaces. Management
requests can only be received via a physically separate network management port.
Note that the TOE SMC java application is protected from potential bypass and tampering by its hosting IT
environment while it is active. However, the application is re-loaded on the client machine from the SMC appliance
during each client login to mitigate a need for protection between sessions.
2.4.2.5 System Data Collection
The TOE collects communications flow information about all monitored network activity. The system can either
auto-tune itself by monitoring normal activity on the network for a pre-defined period of time, or it can be manually
tuned utilizing the zone and host policies (see section 2.4.2.6).
2.4.2.6 System Data Analysis and Reaction
The TOE monitors all network traffic against predefined thresholds (called Concern Indices (or CIs)) and policies
(set at the granularity of a specific host or a collection of hosts, known as a zone), to detect potential intrusions, and
to generate alarms when either are detected.
Extensive analysis tools are provided via the Administrative interface to view system data. The main menu of the
Administrative interface provides the following options:
• Status Screen: The system “dashboard.” It displays a variety of graphs and data that assist the authorised
administrator to monitor the network.
• Alarm Manager: Displays all non-cleared alarms, with an option to display cleared alarms.
• Security Menu: Security-related screens associated with concern index, probes2
, and touched hosts3
.
• Hosts Menu: Displays several host-specific screens such as service profiles, traffic profiles, and
snapshot reports.
• Policy Menu: Displays, and allows authorised administrators to configure, various settings and
exceptions on both a per host and per zone basis, that affect how the system processes
incoming and outgoing flows
2
Any effort, such as a communications request or transaction which is used to gather information about a computer
or the network state.
3
A touched host is a host computer hat has been contacted by another computer that is outside its zone.
11
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• Traffic Menu: Displays several screens of traffic flow data.
2.4.2.7 System Data Review, Availability, and Loss
The TOE protects the data it collects by limiting access. It limits access in two ways:
1) Only authorised administrators are permitted to read system data
2) The only interface provided to the data store is read only
The TOE ensures availability and limits loss of system data by periodically purging data, starting with the oldest
data first. In a situation where there is adequate storage space, system data is preserved for 30 days. If storage space
is exhausted prior to 30 days, the oldest records are overwritten with new data on a first-in / first-out basis, and an
alarm is sent to the authorised administrator. This ensures that there is always storage available for recording current
system data.
12
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
3. Security Environment
This section defines the assumptions, threats, and organizational security policies that the TOE, in conjunction with
its environment, is subject to. With one exception, the assumptions, threats and organizational security policies are
taken from the IDS System PP.
3.1 Assumptions
This section contains assumptions regarding the security environment and the intended usage of the TOE.
3.1.1 Intended Usage Assumptions
A.ACCESS The TOE has access to all the IT System data it needs to perform its functions.
A.DYNMIC The TOE will be managed in a manner that allows it to appropriately address changes in the IT
System the TOE monitors.
A.ASCOPE The TOE is appropriately scalable to the IT System the TOE monitors.
3.1.2 Physical Assumptions
A.PROTCT The TOE hardware and software critical to security policy enforcement will be protected from
unauthorised physical modification.
A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will
prevent unauthorised physical access.
3.1.3 Personnel Assumptions
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 authorised administrators are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the TOE documentation.
A.NOTRST The TOE can only be accessed by authorised users.
3.2 Threats
The following are threats identified for the TOE and the IT System the TOE monitors. The TOE itself has threats
and the TOE is also responsible for addressing threats to the environment in which it resides. The assumed level of
expertise of the attacker for all the threats is unsophisticated.
3.2.1 TOE Threats
T.COMINT An unauthorised user may attempt to compromise the integrity of the data collected and produced
by the TOE by bypassing a security mechanism.
T.COMDIS An unauthorised user may attempt to disclose the data collected and produced by the TOE by
bypassing a security mechanism.
T.LOSSOF An unauthorised user may attempt to remove or destroy data collected and produced by the TOE.
T.NOHALT An unauthorised user may attempt to compromise the continuity of the Systems collection and
analysis functions by halting execution of the TOE.
T.PRIVIL An unauthorised user may gain access to the TOE and exploit system privileges to gain access to
TOE security functions and data
13
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
T.IMPCON An unauthorised user may inappropriately change the configuration of the TOE causing potential
intrusions to go undetected.
T.INFLUX An unauthorised user may cause malfunction of the TOE by creating an influx of data that the
TOE cannot handle.
T.FACCNT Unauthorised attempts to access TOE data or security functions may go undetected.
3.2.2 IT System Threats
The following identifies threats to the IT System that may be indicative of vulnerabilities in or misuse of IT
resources.
T.SCNCFG Improper security configuration settings may exist in the IT System the TOE monitors.
T.SCNMLC Users could execute malicious code on an IT System that the TOE monitors which causes
modification of the IT System protected data or undermines the IT System security functions.
T.SCNVUL Vulnerabilities may exist in the IT System the TOE monitors.
T.FALACT The TOE may fail to react to identified or suspected vulnerabilities or inappropriate activity.
T.FALREC The TOE may fail to recognize vulnerabilities or inappropriate activity based on IDS data received
from each data source.
T.FALASC The TOE may fail to identify vulnerabilities or inappropriate activity based on association of IDS
data received from all data sources.
T.MISUSE Unauthorised accesses and activity indicative of misuse may occur on an IT System the TOE
monitors.
T.INADVE Inadvertent activity and access may occur on an IT System the TOE monitors.
T.MISACT Malicious activity, such as introductions of Trojan horses and viruses, may occur on an IT System
the TOE monitors.
3.3 Organizational Security Policies
An organizational security policy is a set of rules, practices, and procedures imposed by an organization to address
its security needs. This section identifies the organizational security policies applicable to the TOE and the intended
environment of the TOE.
P.DETECT 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 or events that are indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity of IT System assets must
be collected.
P.ANALYZ Analytical processes and information to derive conclusions about intrusions (past, present, or
future) must be applied to IDS data and appropriate response actions taken.
P.MANAGE The TOE shall only be managed by authorised users.
P.ACCESS All data collected and produced by the TOE shall only be used for authorised purposes.
P.ACCACT Users of the TOE shall be accountable for their actions within the IDS.
P.INTGTY Data collected and produced by the TOE shall be protected from modification.
P.PROTCT The TOE shall be protected from unauthorised accesses and disruptions of TOE data and
functions.
14
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
4. Security Objectives
This section identifies the security objectives of the TOE and its supporting environment. With one exception, the
security objectives, categorized as either IT security objectives for the TOE or its environment are taken from the
IDS System PP. All of the identified organization policies are addressed by the security objectives described below.
4.1 IT Security Objectives for the TOE
O.PROTCT The TOE must protect itself from unauthorised modifications and access to its functions and data.
O.IDSCAN The Scanner must collect and store 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.
O.IDSENS The Sensor must collect and store information about all events that are indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity of IT System assets and
the IDS.
O.IDANLZ The Analyzer must accept data from IDS Sensors or IDS Scanners and then apply analytical
processes and information to derive conclusions about intrusions (past, present, or future).
O.RESPON The TOE must respond appropriately to analytical conclusions.
O.EADMIN The TOE must include a set of functions that allow effective management of its functions and
data.
O.ACCESS The TOE must allow authorised users to access only appropriate TOE functions and data.
O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to TOE functions
and data.
O.OFLOWS The TOE must appropriately handle potential audit and System data storage overflows.
O.AUDITS The TOE must record audit records for data accesses and use of the System functions.
O.INTEGR The TOE must ensure the integrity of all audit and System data.
4.2 IT Security Objectives for the IT Environment
OE.PROTECT The IT environment will protect itself and the TOE from external interference or tampering.
4.3 Security Objectives for the Environment
O.INSTAL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and
operated in a manner which is consistent with IT security.
O.PHYCAL Those responsible for the TOE must ensure that those parts of the TOE critical to security policy
are protected from any physical attack.
O.CREDEN Those responsible for the TOE must ensure that all access credentials are protected by the users in
a manner which is consistent with IT security.
O.PERSON Personnel working as authorised administrators shall be carefully selected and trained for proper
operation of the System.
O.INTROP The TOE is interoperable with the IT System it monitors.
15
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
5. IT Security Requirements
This section provides a list of all security functional requirements for the TOE. Security functional requirements in
this ST are drawn from the IDSSPP.
5.1 TOE Security Functional Requirements
Table 1 describes the SFRs that are satisfied by the TOE.
Requirement Class Requirement Component
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: Security Audit
FAU_STG.4: Prevention of Audit Data Loss
FIA_ATD.1: User Attribute Definition
FIA_UAU.1: Timing of Authentication
FIA: Identification and Authentication
FIA_UID.1: Timing of Identification
FMT_MOF.1: Management of Security Functions
Behaviour
FMT_MTD.1: Management of TSF Data
FMT: Security Management
FMT_SMR.1: Security Roles
FPT_ITT.1: Basic internal TSF data transfer
protection
FPT_RVM.1a: Non-bypassability of the TSP
FPT_SEP.1a: TSF domain separation
FPT: Protection of the TOE Security Functions
FPT_STM.1: Reliable time stamps
IDS_ANL.1: Analyser analysis (EXP)
IDS_RCT.1: Analyser react (EXP)
IDS_RDR.1: Restricted Data Review (EXP)
IDS_SDC.1: System Data Collection (EXP)
IDS_STG.1: Guarantee of System Data Availability
(EXP)
IDS: Intrusion Detection System
IDS_STG.2: Prevention of System data loss (EXP)
Table 1 Security Functional Components
5.1.1 Security Audit (FAU)
5.1.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 (as included by Table 2); and
c) Access to the System and access to the TOE and System data.
Component Event Details
FAU_GEN.1 Start-up and shutdown of audit functions
FAU_GEN.1 Access to System
16
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
Component Event Details
FAU_GEN.1 Access to the TOE and System data Object IDS, Requested access
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
FIA_UAU. 1 All use of the authentication mechanism User identity, location
FIA_UID.1 All use of the user identification mechanism User identity, location
FMT_MOF.1 All modifications in the behaviour of the functions of the
TSF
FMT_MTD.1 All modifications to the values of TSF data
FMT_SMR.1 Modifications to the group of users that are part of a role User identity
Table 2 Auditable Events
Note: The IDS_SDC and IDS_ANL requirements in this ST address the recording of results from IDS scanning, sensing, and analysing tasks (i.e.,
System data).
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, the additional information specified in the Details column
of Table 2 Auditable Events.
5.1.1.2 Audit Review (FAU_SAR.1)
FAU_SAR.1.1 The TSF shall provide [the authorised administrators and the authorised System
administrators] with the capability to read [all audit information] 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.1.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.1.1.4 Selectable Audit Review (FAU_SAR.3)
FAU_SAR.3.1 The TSF shall provide the ability to perform sorting of audit data based on date and time, subject
identity, type of event, and success or failure of related event.
5.1.1.5 Selective Audit (FAU_SEL.1)
FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based
on the following attributes:
a) event type;
b) [no additional attributes].
5.1.1.6 Guarantees of Audit Data Availability (FAU_STG.2)
FAU_STG.2.1 The TSF shall protect the stored audit records from unauthorised deletion.
FAU_STG.2.2 The TSF shall be able to detect unauthorised modifications to the audit records in the audit trail.
17
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
FAU_STG.2.3 The TSF shall ensure that [the most recent, limited by available storage space] audit records
will be maintained when the following conditions occur: [audit storage exhaustion].
5.1.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.1.2 Identification and Authentication (FIA)
5.1.2.1 Timing of Authentication (FIA_UAU.1)
FIA_UAU.1.1 The TSF shall allow [no TSF-mediated actions] on behalf of the user to be performed before the
user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-
mediated actions on behalf of that user.
5.1.2.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:
a) User identity;
b) Authentication data;
c) Authorisations; and
d) [no other security attributes].
5.1.2.3 Timing of Identification (FIA_UID.1)
FIA_UID.1.1 The TSF shall allow [no TSF-mediated actions] on behalf of the user to be performed before the
user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-
mediated actions on behalf of that user.
5.1.3 Security Management (FMT)
5.1.3.1 Management of Security Functions Behaviour (FMT_MOF.1)
FMT_MOF.1.1 The TSF shall restrict the ability to modify the behaviour of the functions of System data
collection, analysis and reaction to authorised System administrators.
5.1.3.2 Management of TSF Data (FMT_MTD.1)
FMT_MTD.1.1 The TSF shall restrict the ability to query and add System and audit data, and shall restrict the
ability to query and modify all other TOE data to [the authorised administrators and the
authorised System administrators].
5.1.3.3 Security Roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the following roles: authorised administrator, authorised System
administrators, and [no other authorised identified roles].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
18
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
5.1.4 Protection of the TOE Security Functions (FPT)
5.1.4.1 Basic internal TSF data transfer protection (FPT_ITT.1)
FPT_ITT.1 The TSF shall protect TSF data from [disclosure, modification] when it is transmitted between
separate parts of the TOE.
5.1.4.2 Non-bypassability of the TSP (FPT_RVM.1a)
FPT_RVM.1a.1 The TSF shall ensure that TSP enforcement functions of the TOE appliances are invoked and
succeed before each function within the TSC is allowed to proceed.
5.1.4.3 TSF domain separation (FPT_SEP.1a)
FPT_SEP.1a.1 The TSF shall maintain a security domain for its own execution the execution of the TOE
appliances that protects it from interference and tampering by untrusted subjects.
FPT_SEP.1a.2 The TSF shall enforce separation between the security domains of subjects in the TSC.
5.1.4.4 Reliable time stamps (FPT_STM.1)
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.
5.1.5 Intrusion Detection System (IDS)
5.1.5.1 System Data Collection (EXP) (IDS_SDC.1)
IDS_SDC.1.1 The System shall be able to collect the following information from the targeted IT System
resource(s):
a) [service requests, network traffic]; and
b) [no other information]. (EXP)
IDS_SDC.1.2 At a minimum, the System 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 Table 3 System Events. (EXP)
Component Event Details
IDS_SDC.1 Service Requests Specific service, source
address, destination address
IDS_SDC.1 Network traffic Protocol, source address,
destination address
Table 3 System Events
5.1.5.2 Analyser analysis (EXP) (IDS_ANL.1)
IDS_ANL.1.1 The System shall perform the following analysis function(s) on all IDS data received:
a) [statistical]; and
b) [no other analytical functions]. (EXP)
IDS_ANL.1.2 The System 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 flow statistics]. (EXP)
19
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
5.1.5.3 Analyser react (EXP) (IDS_RCT.1)
IDS_RCT.1.1 The System shall send an alarm to [the Alarm Manager] and take [no other actions or execute
commands to block the connection] when an intrusion is detected. (EXP)
5.1.5.4 Restricted Data Review (EXP) (IDS_RDR.1)
IDS_RDR.1.1 The System shall provide [the authorised administrators and the authorised System
administrators] with the capability to read [all data] from the System data. (EXP)
IDS_RDR.1.2 The System shall provide the System data in a manner suitable for the user to interpret the
information. (EXP)
IDS_RDR.1.3 The System shall prohibit all users read access to the System data, except those users that have
been granted explicit read-access. (EXP)
5.1.5.5 Guarantee of System Data Availability (EXP) (IDS_STG.1)
IDS_STG.1.1 The System shall protect the stored System data from unauthorised deletion. (EXP)
IDS_STG.1.2 The System shall protect the stored System data from modification. (EXP)
IDS_STG.1.3 The System shall ensure that [the most recent, limited by available storage space] System data
will be maintained when the following conditions occur: [System data storage exhaustion].
(EXP)
5.1.5.6 Prevention of System data loss (EXP) (IDS_STG.2)
IDS_STG.2.1 The System shall [overwrite the oldest stored System data] and send an alarm if the storage
capacity has been reached. (EXP)
5.2 IT Environment Security Functional Requirements
Table 1 describes the SFRs that are satisfied by the IT environment of the TOE
Requirement Class Requirement Component
FPT_RVM.1b: Non-bypassability of the TSP
FPT: Protection of the TOE Security Functions
FPT_SEP.1b: TSF domain separation
Table 4 Security Functional Components
5.2.1 Protection of the TOE Security Functions (FPT)
5.2.1.1 Non-bypassability of the TSP (FPT_RVM.1b)
FPT_RVM.1b.1 The TSF IT environment shall ensure that TSP enforcement functions of the TOE applications
are invoked and succeed before each function within the TSC is allowed to proceed.
5.2.1.2 TSF domain separation (FPT_SEP.1b)
FPT_SEP.1b.1 The TSF IT environment shall maintain a security domain for its own execution the execution of
TOE applications that protects it from interference and tampering by untrusted subjects.
FPT_SEP.1b.2 The TSF IT environment shall enforce separation between the security domains of subjects in the
TSC.
20
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the EAL 2 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
ACM: Configuration management ACM_CAP.2: Configuration items
ADO_DEL.1: Delivery procedures
ADO: Delivery and operation
ADO_IGS.1: Installation, generation, and start-up
procedures
ADV_FSP.1: Informal functional specification
ADV_HLD.1: Descriptive high-level design
ADV: Development
ADV_RCR.1: Informal correspondence
demonstration
AGD_ADM.1: Administrator guidance
AGD: Guidance documents
AGD_USR.1: User guidance
ALC: Life cycle support ALC_FLR.2: Flaw reporting procedures
ATE_COV.1: Evidence of coverage
ATE_FUN.1: Functional testing
ATE: Tests
ATE_IND.2: Independent testing - sample
AVA_SOF.1: Strength of TOE security function
evaluation
AVA: Vulnerability assessment
AVA_VLA.1: Developer vulnerability analysis
Table 5 EAL 2 augmented with ALC_FLR.2 Assurance Components
5.3.1 Configuration management (ACM)
5.3.1.1 Configuration items (ACM_CAP.2)
ACM_CAP.2.1d The developer shall provide a reference for the TOE.
ACM_CAP.2.2d The developer shall use a CM system.
ACM_CAP.2.3d The developer shall provide CM documentation.
ACM_CAP.2.1c The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.2.2c The TOE shall be labeled with its reference.
ACM_CAP.2.3c The CM documentation shall include a configuration list.
ACM_CAP.2.4c The configuration list shall uniquely identify all configuration items that comprise the TOE.
ACM_CAP.2.5c The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.2.6c The CM documentation shall describe the method used to uniquely identify the configuration
items that comprise the TOE.
ACM_CAP.2.7c The CM system shall uniquely identify all configuration items that comprise the TOE.
ACM_CAP.2.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.2 Delivery and operation (ADO)
5.3.2.1 Delivery procedures (ADO_DEL.1)
ADO_DEL.1.1d The developer shall document procedures for delivery of the TOE or parts of it to the user.
21
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
ADO_DEL.1.2d The developer shall use the delivery procedures.
ADO_DEL.1.1c The delivery documentation shall describe all procedures that are necessary to maintain security
when distributing versions of the TOE to a user’s site.
ADO_DEL.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.2.2 Installation, generation, and start-up procedures (ADO_IGS.1)
ADO_IGS.1.1d The developer shall document procedures necessary for the secure installation, generation, and
start-up of the TOE.
ADO_IGS.1.1c The installation, generation and start-up documentation shall describe all the steps necessary for
secure installation, generation and start-up of the TOE.
ADO_IGS.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADO_IGS.1.2e The evaluator shall determine that the installation, generation, and start-up procedures result in a
secure configuration.
5.3.3 Development (ADV)
5.3.3.1 Informal functional specification (ADV_FSP.1)
ADV_FSP.1.1d The developer shall provide a functional specification.
ADV_FSP.1.1c The functional specification shall describe the TSF and its external interfaces using an informal
style.
ADV_FSP.1.2c The functional specification shall be internally consistent.
ADV_FSP.1.3c The functional specification shall describe the purpose and method of use of all external TSF
interfaces, providing details of effects, exceptions and error messages, as appropriate.
ADV_FSP.1.4c The functional specification shall completely represent the TSF.
ADV_FSP.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_FSP.1.2e The evaluator shall determine that the functional specification is an accurate and complete
instantiation of the TOE security functional requirements.
5.3.3.2 Descriptive high-level design (ADV_HLD.1)
ADV_HLD.1.1d The developer shall provide the high-level design of the TSF.
ADV_HLD.1.1c The presentation of the high-level design shall be informal.
ADV_HLD.1.2c The high-level design shall be internally consistent.
ADV_HLD.1.3c The high-level design shall describe the structure of the TSF in terms of subsystems.
ADV_HLD.1.4c The high-level design shall describe the security functionality provided by each subsystem of the
TSF.
ADV_HLD.1.5c The high-level design shall identify any underlying hardware, firmware, and/or software required
by the TSF with a presentation of the functions provided by the supporting protection mechanisms
implemented in that hardware, firmware, or software.
ADV_HLD.1.6c The high-level design shall identify all interfaces to the subsystems of the TSF.
22
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
ADV_HLD.1.7c The high-level design shall identify which of the interfaces to the subsystems of the TSF are
externally visible.
ADV_HLD.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_HLD.1.2e The evaluator shall determine that the high-level design is an accurate and complete instantiation
of the TOE security functional requirements.
5.3.3.3 Informal correspondence demonstration (ADV_RCR.1)
ADV_RCR.1.1d The developer shall provide an analysis of correspondence between all adjacent pairs of TSF
representations that are provided.
ADV_RCR.1.1c For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all
relevant security functionality of the more abstract TSF representation is correctly and completely
refined in the less abstract TSF representation.
ADV_RCR.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.4 Guidance documents (AGD)
5.3.4.1 Administrator guidance (AGD_ADM.1)
AGD_ADM.1.1dThe developer shall provide administrator guidance addressed to system administrative personnel.
AGD_ADM.1.1cThe administrator guidance shall describe the administrative functions and interfaces available to
the administrator of the TOE.
AGD_ADM.1.2cThe administrator guidance shall describe how to administer the TOE in a secure manner.
AGD_ADM.1.3cThe administrator guidance shall contain warnings about functions and privileges that should be
controlled in a secure processing environment.
AGD_ADM.1.4cThe administrator guidance shall describe all assumptions regarding user behaviour that are
relevant to secure operation of the TOE.
AGD_ADM.1.5cThe administrator guidance shall describe all security parameters under the control of the
administrator, indicating secure values as appropriate.
AGD_ADM.1.6cThe administrator guidance shall describe each type of security-relevant event relative to the
administrative functions that need to be performed, including changing the security characteristics
of entities under the control of the TSF.
AGD_ADM.1.7cThe administrator guidance shall be consistent with all other documentation supplied for
evaluation.
AGD_ADM.1.8cThe administrator guidance shall describe all security requirements for the IT environment that are
relevant to the administrator.
AGD_ADM.1.1eThe evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.4.2 User guidance (AGD_USR.1)
AGD_USR.1.1d The developer shall provide user guidance.
AGD_USR.1.1c The user guidance shall describe the functions and interfaces available to the non-administrative
users of the TOE.
AGD_USR.1.2c The user guidance shall describe the use of user-accessible security functions provided by the
TOE.
23
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
AGD_USR.1.3c The user guidance shall contain warnings about user-accessible functions and privileges that
should be controlled in a secure processing environment.
AGD_USR.1.4c The user guidance shall clearly present all user responsibilities necessary for secure operation of
the TOE, including those related to assumptions regarding user behaviour found in the statement
of TOE security environment.
AGD_USR.1.5c The user guidance shall be consistent with all other documentation supplied for evaluation.
AGD_USR.1.6c The user guidance shall describe all security requirements for the IT environment that are relevant
to the user.
AGD_USR.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.5 Life cycle support (ALC)
5.3.5.1 Flaw reporting procedures (ALC_FLR.2)
ALC_FLR.2.1d The developer shall provide flaw remediation procedures addressed to TOE developers.
ALC_FLR.2.2d The developer shall establish a procedure for accepting and acting upon user 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.
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
corrected and the correction 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.6 Tests (ATE)
5.3.6.1 Evidence of coverage (ATE_COV.1)
ATE_COV.1.1d The developer shall provide evidence of the test coverage.
ATE_COV.1.1c The evidence of the test coverage shall show the correspondence between the tests identified in the
test documentation and the TSF as described in the functional specification.
24
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
ATE_COV.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.6.2 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, test procedure descriptions, expected test results
and actual test results.
ATE_FUN.1.2c The test plans shall identify the security functions to be tested and describe the goal of the tests to
be performed.
ATE_FUN.1.3c The test procedure descriptions shall identify the tests to be performed and describe the scenarios
for testing each security function. These scenarios shall include any ordering dependencies on the
results of other tests.
ATE_FUN.1.4c The expected test results shall show the anticipated outputs from a successful execution of the
tests.
ATE_FUN.1.5c The test results from the developer execution of the tests shall demonstrate that each tested
security function behaved as specified.
ATE_FUN.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.6.3 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 test a subset of the TSF as appropriate to confirm that the TOE operates as
specified.
ATE_IND.2.3e The evaluator shall execute a sample of tests in the test documentation to verify the developer test
results.
5.3.7 Vulnerability assessment (AVA)
5.3.7.1 Strength of TOE security function evaluation (AVA_SOF.1)
AVA_SOF.1.1d The developer shall perform a strength of TOE security function analysis for each mechanism
identified in the ST as having a strength of TOE security function claim.
AVA_SOF.1.1c For each mechanism with a strength of TOE security function claim the strength of TOE security
function analysis shall show that it meets or exceeds the minimum strength level defined in the
PP/ST.
AVA_SOF.1.2c For each mechanism with a specific strength of TOE security function claim the strength of TOE
security function analysis shall show that it meets or exceeds the specific strength of function
metric defined in the PP/ST.
AVA_SOF.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
25
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
AVA_SOF.1.2e The evaluator shall confirm that the strength claims are correct.
5.3.7.2 Developer vulnerability analysis (AVA_VLA.1)
AVA_VLA.1.1d The developer shall perform a vulnerability analysis.
AVA_VLA.1.2d The developer shall provide vulnerability analysis documentation.
AVA_VLA.1.1c The vulnerability analysis documentation shall describe the analysis of the TOE deliverables
performed to search for obvious ways in which a user can violate the TSP.
AVA_VLA.1.2c The vulnerability analysis documentation shall describe the disposition of obvious vulnerabilities.
AVA_VLA.1.3c The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the
vulnerability cannot be exploited in the intended environment for the TOE.
AVA_VLA.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AVA_VLA.1.2e The evaluator shall conduct penetration testing, building on the developer vulnerability analysis,
to ensure obvious vulnerabilities have been addressed.
26
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
6. TOE Summary Specification
This chapter describes the security functions and associated assurance measures.
6.1 TOE Security Functions
6.1.1 Security Audit
FAU_GEN.1 Audit Data Generation
Auditing is the recording of events within the system, exclusive of the recording of sensing and analysis tasks
performed by the flow based analysis engine. Both StealthWatch appliances and the SMC utilize protected disk files
to record audit log information in a data store.
The following information relevant to each auditable event is stored in the audit data store:
a) Date and time that the event occurred,
b) The type of event,
c) The user causing the event,
d) The outcome of the event – success or failure.
The following auditable events can be included in the set of audited events:
a) Startup and shutdown of the audit function,
b) Access to the system,
c) All access to the TOE and System data – including the requested access,4
d) All modification to the audit configuration that occur during collection
e) All authentication attempts – including the identification data (e.g. username) and location where
authentication was attempted
f) All modification to the behavior of the TSF
g) All modifications to TSF data values
h) All modifications to user accounts – including the user identity that was created, deleted, or modified,
and the user identity that performed the modification.
FAU_SAR.1 Audit Review
StealthWatch provides the ability for the appliance or StealthWatch Management Console (SMC) administrators
(i.e., users in the authorised administrator or authorised System administrator role) to view security audit data for the
system. The audit logs for a given appliance are viewable through the standard web-based administrative interface to
that appliance or alternately the audit logs for all appliances can be viewed using the associated SMC.
FAU_SAR.2 Restricted Audit Review
4
Note: The object IDS required to be audited by the FAU_GEN.1 requirement is inherent in the location of the audit
log. The audit record itself does not contain this information, but each StealthWatch appliance (e.g. IDS System)
contains only one audit log which is for that particular appliance. Therefore the appliance being accessed to view the
audit log is the object IDS of the audit record. Note that each TOE appliance (including the SMC appliance)
maintains its own audit trail of security management events originated from its administrative interface – web-based
interfaces for the NC and Xe appliance and the SMC java application in the case of the SMC appliance.
27
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
No security related actions can be taken on the appliance or the SMC without successful user authentication,
therefore only authorised users who have the authorised administrator or authorised System administrator role can
view the audit records on any appliances and the SMC.
FAU_SAR.3 Selectable Audit Review
While viewing the security audit records, it is possible to sort and filter the data based upon the following properties:
• Date and time,
• User,
• Type of event, and
• Success or Failure of the event.
Note that this is true when accessing the audit records from either an appliance or the SMC.
FAU_SEL.1 Selectable Audit
The StealthWatch administrative interface (web-based appliance or SMC) provides a GUI screen that allows a user
with the authorised System administrator role to select auditable events from the set of audited events based on the
event type. The selection is via a series of check boxes in the administrative interface that identify which events will
be audited.
FAU_STG.2 Guarantees of Data Availability
The only way to access the audit records is through the administrative interface (web-based appliance or SMC). The
TOE provides protection for the security audit records primarily by preventing access to the system without
successful authentication. Secondly, no interface is provided (either on the appliances or the SMC) for the
authorised administrator or authorised System administrator roles to modify the audit records. Further, since the
audit function starts automatically with the TOE, and cannot be disabled, all actions taken against the audit records
are recorded. The most recent audit records will always be available as the oldest audit records are overwritten in the
event of audit storage exhaustion.
Furthermore, the SMC will automatically delete SMC audit records once they have exceeded 30 days in age.
FAU_STG.4 Prevention of Audit Data Loss
When the TOE exhausts the available storage space (on each appliance and the SMC itself) for audit records, an
alert is entered in the Alarm Manager. If an audit process runs out of storage space, then the oldest records (in the
appliance or the SMC) will be automatically overwritten to prevent new audited events from occurring without
being audited.
The Security Audit function is designed to satisfy the following security functional requirements:
• FAU_GEN.1
• FAU_SAR.1
• FAU_SAR.2
• FAU_SAR.3
• FAU_SEL.1
• FAU_STG.2
• FAU_STG.4
6.1.2 Identification and Authentication
FIA_UAU.1 Timing of Authentication
28
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
When a potential user attempts to access the TOE (both via the web-based appliance interfaces and the SMC
interface), the user is presented with a username and password dialog. No access to the TOE will be provided until
the potential user has been successfully authenticated to the TOE. The TOE requires users to provide unique
identification (username) and authentication data (passwords) before any access to the system is granted. In order for
access to be granted the password provided must match the password that the TSF recognizes as being assigned to
the provided username. No actions are allowed, other than entry of identification and authentication data, until
successful authentication occurs.
FIA_ATD.1 User Attribute Definition
User accounts in the TOE (both appliances and the SMC) have the following attributes: user name, authentication
data (password), and their assigned role (authorizations). All user accounts are in either the authorised administrator
or authorised System administrator role. The requirements for password complexity and password assignment are
provided in the administrative guidance.
Note that each appliance and the SMC have their own separate user definitions.
FIA_UID.1 Timing of Identification
The TOE (both appliances and the SMC) requires users to provide unique identification and authentication data
(passwords) before any access to the system is granted. No actions are allowed, other than entry of identification and
authentication data, until successful identification occurs.
The Identification and Authentication function is designed to satisfy the following security functional requirements:
• FIA_UAU.1
• FIA_ATD.1
• FIA_UID.1
6.1.3 Security Management
FMT_MOF.1 Management of Security Functions Behavior
The TOE (both appliances and the SMC) requires user authentication before any actions can be performed (other
than entry of identification and authentication data), security-related or otherwise. Given this and the fact that all
users are either authorized administrators or authorized System administrators (see below), only authorised
administrators or authorised System administrators can access any functions on the system.
Users with the authorised System administrator role have the ability to modify traffic and host profiles that influence
how System Data is analyzed, displayed, and reacted to. Users with the authorised administrator role only have the
ability to view the settings that influence how System Data is analyzed, displayed, and reacted to. The authorised
System administrator role is the only role that can manage the security settings on the system, such as user accounts
and audit settings. No user can modify the behavior of the TOE relevant to System data collection, as all
communication flow data collected by the system is always collected. Users can only affect the way the collected
data is analyzed, displayed, and reacted to.
FMT_MTD.1 Management of TSF Data
See FMT_SMR.1.
FMT_SMR.1 Security Roles
In the context of StealthWatch appliances, the TOE has three classes of users that form two roles, each with its own
set of privileges. When a user is assigned to a class, the class mandates the role.
• “Administrator” class: this class of user can perform all management functions on the TOE. The user
in this class can manage user accounts (create, delete, modify), view the security audit log, view,
query, modify, and delete the System Data log and manually tune the profiles that govern the IDS.
29
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• “Web Administrator” class: The user in this class can view the security audit log, view, query, and
modify the System Data log and manually tune the profiles that govern the IDS.
• “Technician” class: A user of this class can view the security audit logs, view and query the System
Data log, and clear alarms.
Note that the Administrator and Web Administrator classes of users are part of the “authorised System
administrator” role and the Technician class of users are part of the “authorised administrator” role. The
Administrator and Web Administrator classes each have a single predefined user identity each of which is assigned
to a single user as stipulated in the StealthWatch administrative guidance.
In the context of the SMC, there is a single pre-defined Administrator role. The SMC supports the notion of Data
and Function roles that can be assigned to users. Data roles dictate whether the associated user can only perform
read or query operations or alternately whether the user is allowed to make changes within the TOE. Function roles
serve to group specific TOE functions. There is a default set of Function roles and the SMC Administrator can
define additional Functions roles. Functions include access to TOE appliance, domain, and network settings;
policies; and other security functions (e.g., audit review). SMC users are assigned a Data and Function role which
together serve to define (in the case of Function roles) and also limit (in the case of Data roles) the set of TOE
functions available to that user. There is also an administrator setting that can be set for each user specifically
granting SMC administrator privileges. Only these explicitly configured administrative users are able to create other
users, review and configure the audit log, and SMC Failover
Note that users that have been explicitly configured as SMC Administrators are part of the “authorised System
administrator” role while other users that have only been granted Data and Function roles are part of the “authorised
administrator” role.
The Security Management function is designed to satisfy the following security functional requirements:
• FMT_MOF.1
• FMT_MTD.1
• FMT_SMR.1
6.1.4 Protection of the TOE Security Functions
FPT_ITT.1 Basic internal TSF data transfer protection
When TOE appliances are used in conjunction with a SMC, the SMC is required to connect to the other applicable
TOE appliances using Transport Layer Security (TLS) in order to ensure that any data transmitted between the
components is protected from both modification and disclosure. Similarly, the SMC java application uses TLS to
communicate with the SMC appliance.
Note that the TOE uses TLS version 1.0 (per RFC 2246) using OpenSSL to ensure communication protection. The
TLS mechanism supports connections using 256- or 128-bit AES or 168-bit triple-DES. More specifically the
following six cipher suites – each identifying a key exchange algorithm, an encryption algorithm, and a Message
Authentication Code (MAC) algorithm – are supported:
1. DHE-RSA-AES256-SHA
2. AES256-SHA
3. DHE-RSA-AES128-SHA
4. AES128-SHA
5. EDH-RSA-DES-CBC3-SHA
6. DES-CBC3-SHA
30
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
Note that the last two cipher suites (5 & 6) use triple-DES in accordance with the OpenSSL cipher list
(http://www.openssl.org/docs/apps/ciphers.html) while the first four (1-4) use AES extending TLS v1.0 in
accordance with RFC3268.
When any client (SMC client or StealthWatch appliance) requests a secure channel with the SMC, the client and
server negotiate the highest mutually supported cipher suite according to the order of the list as presented above. If
the client and server do not agree on a cipher suite the connection attempt fails.
FPT_RVM.1a Non-bypassability of the TSP
The TSF (within all TOE appliances) requires that all users successfully authenticate before being able to view or
modify the TSP. No actions are allowed on the TOE until after successful authentication, and the allowed actions are
determined by the assigned user role. The TOE implements a receive only, passive, monitoring interface on the
monitored network. The TOE does not provide any interface for an entity to interact with it via the monitored
network.
Note that the TOE application (i.e., the SMC java application), when used, depends somewhat on its hosting IT
environment to prevent potential bypass opportunities per (FPT_RVM.1b), though it also requires successful user
authentication before allowing access to its functions which are designed to enforce the rules otherwise specified in
this Security Target.
FPT_SEP.1a TSF Domain Separation
The TOE appliances are housed by an enclosed appliance in which all operations are self-contained. The TOE
appliances do not respond to any network traffic on the network it monitors and its management interface is on a
physically protected network. No operations are performed outside the physical boundary of the TOE appliances.
Note that the TOE application (i.e., the SMC client (java) application), when used, depends on its hosting IT
environment to prevent potential tampering opportunities per (FPT_SEP.1b) while it is active. The SMC client
application is re-loaded on the client machine each time a session is established mitigating the need to protect it
between sessions.
FPT_STM.1 Reliable Time Stamps
The TOE provides time stamps to system data and audit data log entries. It requests and receives time from its
hardware clock via an operating system call and then applies that time directly to the corresponding log entry. The
TOE provides a limited interface to the time mechanism that allow authorised System administrators to set the
correct time utilizing the administrative interface (web-based appliance or SMC). The time keeping mechanism is
the only security relevant aspect of the operating system and hardware that underlies the embedded StealthWatch
application software.
Note that the TOE can optionally be configured to synchronize its time with an external time server via Network
Time Protocol (NTP). In that case, while the TOE ensures the reliability of its time stamp, the time will be relative
to that of the NTP server and as such only a trustworthy NTP server should be so configured.
The Protection of the TOE Security Functions function is designed to satisfy the following security functional
requirements:
• FPT_ITT.1
• FPT_RVM.1a
• FPT_SEP.1a
• FPT_STM.1
6.1.5 Intrusion Detection System
IDS_SDC.1 System Data Collection
The StealthWatch appliances have the ability to manually and automatically tune profiles that define when alerts are
generated, indicating potential intrusions. While StealthWatch contains default universal behaviors to detect known
31
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
vulnerabilities and exploits, new profiles can be defined to alert on abnormal behaviors as well as specific network
traffic, allowing the authorised System administrator role complete control over the types of traffic that will be
alerted. Note that these profiles do not affect the flows that are monitored, as all communication flows are monitored
for potential later analysis. As Ethernet frames are received through one of the promiscuous interfaces on the
StealthWatch appliance (NC or Xe), these packets are fed into a flow analysis engine that separates and categorizes
the active data flows.
The system data that is collected includes the following information:
a) Date and time that the event occurred,
b) The type of event,
c) The outcome of the event,
d) The protocol of the particular event,
e) The service identifier of the event,
f) The source IP address,
g) The source MAC address (if available),
h) The destination IP address,
i) The destination MAC address (if available).
j) 80 bytes of packet data from flow initiation (if available, NC only)
k) Contributing exporters (if available, Xe only)
IDS_ANL.1 Analyzer Analysis
To analyze the data collected by the data collection interface, StealthWatch appliances use a collection of universal
behaviors, traffic profiles, and host profiles.
Universal behaviors and profiles are patterns of traffic that define normal activity for the network and for each host,
and can be used to detect attacks, exploits, and misuse of the network.
StealthWatch appliances operate by establishing a behavioral profile of normal network activity and usage. During
initial installation, an autotuning period will take place, allowing StealthWatch appliances to “autotune” host
specific thresholds and settings. Once the profile is complete and final manual tuning has taken place, the behavioral
profile is “locked down.”
In normal operation, once the collected data flows have been properly categorized, StealthWatch appliances perform
periodic analysis of the collected data, checking host profiles, traffic profiles, and system-wide Universal Behavior
threshold settings to verify the flows satisfy the parameters of the established behavioral profile.
Nefarious traffic is then identified and reported. As patterns emerge and suspect flows are identified, StealthWatch
appliances begin to accumulate Concern Index points for the suspect host. As a host’s Concern Index increases,
StealthWatch raises alarms to notify an administrator of the host’s activity.
Each network host has an individual Concern Index threshold. During the autotuning process, or manually through
the StealthWatch appliance host profiler, a host’s Concern Index threshold will be set to its optimum value.
All communication flows are logged and contain, at least, the information specified below:
a) Flow start date & time
b) Flow end date & time
c) Source IP
d) Source MAC (if available)
e) Destination IP
f) Destination MAC (if available)
32
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
g) Total bytes transferred during the flow
h) Average Kb per second
i) Total packets transferred during the flow
j) Length in seconds of the flow
k) TCP, UDP or other IP protocol type
l) Data bytes sent by source IP
m) Data bytes sent by destination IP
n) Number of packets sent by source IP
o) Number of packets sent by destination IP
IDS_RCT.1 Analyzer React
When any communication flow occurs, the details of that flow are logged in the system data log within the
applicable StealthWatch appliance for future forensic analysis and event reconstruction. In addition, when the
characteristics of a communication flow violate the defined acceptable behavior of a host, an alarm is triggered.
When an alarm is triggered on a StealthWatch appliance or SMC, it is recorded in the StealthWatch appliance or
SMC Alarm Manager to notify the authorised System administrator and authorised administrator roles. In addition,
the appliance can be configured to execute a command to block further communications if the administrator deems
that problem to be sufficiently dangerous. This command may be configured to occur automatically, or upon
administrator’s authorization. Similarly, the SMC can be configure to send out e-mail alerts corresponding with the
alarms.
IDS_RDR.1 Restricted Data Review
In StealthWatch (appliances and the SMC), only successfully authenticated users can access the TOE. Since all
users that successfully authenticate are members of either the authorised System administrator role or authorised
administrator role, no further restrictions on the ability to review the system data log are necessary.
All system data is only available through the administrative interface (web-based appliance or SMC) provided by
StealthWatch. The alarm generation component identifies events of particular interest and the administrative
interface interprets the data in a readable format for the user. The information is then displayed via the
administrative interface. All members of the authorised System administrator and authorised administrator roles are
granted explicit read access to all system data.
IDS_STG.1 Guarantee of System Data Availability
StealthWatch (appliances and the SMC) protects the gathered system data log from unauthorised modification or
deletion by presenting only the administrative interface (web-based appliance or SMC) to all users. No users are
allowed to edit the log; it is marked for read-only access, preventing user modification. Only users with the
authorised System administrator role can delete the logs using web-based appliance or SMC administrative
interfaces .
To guarantee that the most recent system data is always able to be recorded, when the system data storage space is
exhausted, the oldest events stored in the system data store will be overwritten.
IDS_STG.2 Prevention of System Data Loss
To prevent the loss in new/current event data, the oldest events stored in the log will be overwritten when the
appliance or SMC data storage capacity is exhausted. When this occurs the authorised System administrator and the
authorised administrator roles will be alerted via a system alert on the applicable appliance or SMC.
The Intrusion Detection System function is designed to satisfy the following security functional requirements:
• IDS_SDC.1
• IDS_ANL.1
33
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• IDS_RCT.1
• IDS_RDR.1
• IDS_STG.1
• IDS_STG.2
6.2 TOE Security Assurance Measures
The following assurance measures are applied to satisfy the Common Criteria EAL2 assurance requirements:
• Configuration Management,
• Delivery and Operation,
• Development,
• Guidance Documentation,
• Tests,
• Vulnerability Assessment.
In addition, Lancope implements the following assurance measure, exceeding the assurance requirements of EAL2:
• Life Cycle Support.
6.2.1 Configuration Management
The configuration management measures applied by Lancope ensure that configuration items are uniquely
identified, and that documented procedures are used to control and track changes that are made to the TOE.
Lancope performs configuration management on the TOE implementation representation, design, tests, user and
administrator guidance, the CM documentation, and the Vulnerability Assessment documentation. These activities
are documented in:
• StealthWatch Configuration Management Procedure
• Configuration Item List, StealthWatch Appliance V5.6.1
The Configuration management assurance measure satisfies the following EAL 2 assurance requirements:
• ACM_CAP.2
6.2.2 Delivery and Operation
Lancope provides delivery documentation that explains how the TOE is delivered, procedures to identify the TOE,
and procedures to allow detection of unauthorised modifications of the TOE. These procedures are documented in:
• StealthWatch Build, Test and Delivery Procedures
Lancope provides installation and initialization procedures in the administrator guidance. The installation and
generation procedures describe the steps necessary to install StealthWatch products in accordance with the evaluated
configuration and the procedures to be used for the generation, and start-up of the TOE.
The installation, generation, and start-up procedures are documented in:
• StealthWatch Installation Process
• StealthWatch Appliance:
34
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• The StealthWatch Appliance Configuration Guide Includes StealthWatch NC and StealthWatch Xe
For v5.6
• SWA Quick Start Checklist
• SMC:
• SMC Installation Checklist
• SMC Configuration Guide For v5.6.1
The Delivery and Guidance assurance measure satisfies the following Assurance requirements:
• ADO_DEL.1
• ADO_IGS.1
6.2.3 Development
The Design Documentation provided for StealthWatch is provided in the following documents:
• Functional Specification for StealthWatch™ NC Appliance (SW NC), StealthWatch Xe Appliance (SW
Xe), and StealthWatch Management Console (SMC) Release Version 5.6.1
• High-Level Design Document for StealthWatch™ NC Appliance (SW NC), StealthWatch Xe Appliance
(SW Xe), and StealthWatch Management Console (SMC) Release Version 5.6.1
• Correspondence Document for StealthWatch™ NC Appliance (SW NC), StealthWatch Xe Appliance (SW
Xe), and StealthWatch Management Console (SMC) Release Version 5.6.1
These documents serve to describe the security functions of the TOE, its interfaces both external and between
subsystems, the architecture of the TOE (in terms of subsystems), and correspondence between the available design
abstractions (including the ST).
The Development assurance measure satisfies the following EAL 2 requirements:
• ADV_FSP.1
• ADV_HLD.1
• ADV_RCR.1
6.2.4 Guidance documents
Lancope provides administrator guidance documents that describe the administrative functions and the
administrative interfaces (web-based and SMC) available to authorised System administrators and authorised
administrators of the StealthWatch appliances. These documents are consistent with other supplied documentation
and describe how to administer StealthWatch in a secure manner. The guidance documents describe the assumptions
regarding user behavior that is relevant to the secure operation of the appliances, and describes the parameters that
are under the control of the authorised System administrators and the authorised administrators.
These activities are documented in:
• StealthWatch Appliance:
• StealthWatch v6.5.1 Help
• The StealthWatch Appliance Configuration Guide Includes StealthWatch NC and StealthWatch Xe
For v5.6
• SMC:
• SMC Admin v5.6.1 Online Help
• SMC Help File for v5.6.1
35
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• SMC User’s Guide For v5.6
• SMC Configuration Guide For v5.6.1
The Guidance documents assurance measure satisfies the following EAL 2 assurance requirements:
• AGD_ADM.1
• AGD_USR.1
6.2.5 Life cycle support
Lancope has a series of procedures that define the process for accepting and acting upon user reports of security
flaws. These procedures describe the acceptance criteria for security flaws, how all security flaws are tracked and
the status of the fix for each security flaw.
In addition, the flaw remediation procedures describe how fixes are reviewed to ensure that they do not introduce
new security flaws and how the fixes for security flaws are issued to Lancope customers.
These activities are documented in:
• StealthWatch System Flaw Remediation Procedure
The Life cycle support assurance measure satisfies the following assurance requirement, exceeding EAL2:
• ALC_FLR.2
6.2.6 Tests
The Test Documentation is found in the following documents:
• Test Plan for StealthWatch™ NC and Xe Appliances Release Version 5.6.1
• Test Plan for StealthWatch™ Management Console (SMC) Release Version 5.6.1
• Executed Test Plan for StealthWatch™ NC and Xe Appliances Release Version 5.6.1
• Executed Test Plan for StealthWatch™ Management Console (SMC) Release Version 5.6.1
• Test Plan Coverage Analysis for StealthWatch™ NC Appliance (SW NC), StealthWatch Xe Appliance
(SW Xe), and StealthWatch Management Console (SMC) Release Version 5.6.1
These documents describe the overall test plan, testing procedures, the tests themselves, including expected and
actual results. In addition, these documents describe how the functional specification has been appropriately tested.
The Tests assurance measure satisfies the following EAL 2 assurance requirements:
• ATE_COV.1
• ATE_FUN.1
• ATE_IND.2
6.2.7 Vulnerability assessment
Lancope performs vulnerability analyses of the TOE to identify weaknesses that can be exploited in the TOE. All of
the SOF claims are based on password space calculations and based on the SOF rationale provided in the
Vulnerability Assessment. The vulnerability analysis is documented in:
• Vulnerability Assessment for StealthWatch™ NC Appliance (SW NC), StealthWatch Xe Appliance (SW
Xe), and StealthWatch Management Console (SMC) Release Version 5.6.1
The Vulnerability Assessment assurance measure satisfies the following assurance requirements:
• AVA_SOF.1
36
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
• AVA_VLA.1
37
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
7. Protection Profile Claims
The TOE conforms to the US Government Intrusion Detection System System Protection Profile, Version 1.6, April
4, 2006.
This Security Target includes all of the Security Functional and Security Assurance Requirements from the PP.
This Security Target includes all of the assumptions and threats statements described in the PP, verbatim.
This Security Target includes all of the Security Objectives from the PP, verbatim, except for O.EXPORT as
explained below.
Section 5 of this Security Target specifically identifies each of the operations that have been performed on
requirements drawn from the PP. Note that operations already performed in the PP have not been identified in this
Security Target.
The following SFRs from the PP have not been included in this ST: FPT_ITA.1, FPT_ITC.1, and FPT_ITI.1. The
reason they were dropped is the TOE has no communications with external IT products and the SFRs are
unnecessary. To further support the exclusion of these SFRs, PD-0097 (http://niap.nist.gov/cc-
scheme/PD/0097.html) states the inter-TSF related requirements (FPT_ITA.1, FPT_ITC.1, and FPT_ITI.1) were
erroneously included in the PP. PD-0097 also states the O.EXPORT objective was erroneously replicated into the
system PP. This ST has deleted the O.EXPORT objective to be consistent with PD-0097. Additionally, PD-0097
also indicates that FPT_ITT.1 should be included when the TOE is a distributed TOE. The IDS system described
herein is distributed TOE when a SMC is used to manage the other TOE appliances (NC or Xe) and therefore
FPT_ITT.1 has been included in the SFRs in this ST.
Note also that since part of the TOE (i.e., the SMC java application associated with the SMC) is protected by the IT
environment, FPT_RVM.1 and FPT_SEP.1 have all been iterated to more clearly indicate that all the TOE
appliances protect themselves and the TOE management application is protected by its environment. The PP
specifically allows that these SFRs could be assigned to the IT environment, but in this case, they are only partially
assigned to the environment as is appropriate. Note that each SFR has been additionally refined to indicate the
applicable part of the TOE (i.e., appliance or application) where all parts of the TOE are represented by the
combined TOE and IT environment SFRs.
CCv2.3
The following changes have been made to requirements based on CCv2.3 as opposed to CCv2.1 used to create the
PP. These changes have no impact on conformance with the PP since they are only minor updates to clarify the
requirements.
• FAU_STG.2
• ACM_CAP.2
• ADO_IGS.1
• ALC_FLR.2
• AVA_VLA.1
38
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8. 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;
• TOE Summary Specification;
• Security Functional Requirement Dependencies; and
• Internal Consistency.
8.1 Security Objectives Rationale
This section shows that all secure usage assumptions, organizational security policies, and threats are completely
covered by security objectives. In addition, each objective counters or addresses at least one assumption,
organizational security policy, or threat.
8.1.1 Security Objectives Rationale for the TOE and Environment
This section provides evidence demonstrating the coverage of organizational policies and usage assumptions by the
security objectives.
O.PROTCT
O.IDSCAN
O.IDSENS
O.IDANLZ
O.RESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
O.INSTAL
O.PHYCAL
O.CREDEN
O.PERSON
O.INTROP
OE.PROTECT
A.ACCESS X
A.DYNMIC X X
A.ASCOPE X
A.PROTCT X
A.LOCATE X
A.MANAGE X
A.NOEVIL X X X
A.NOTRST X X
T.COMINT X X X X X
T.COMDIS X X X X
T.LOSSOF X X X X
T.NOHALT X X X X X
T.PRIVIL X X X
T.IMPCON X X X X
T.INFLUX X
T.FACCNT X
T.SCNCFG X
39
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
OE.PROTECT
O.OFLOWS
O.PERSON
O.CREDEN
O.PHYCAL
O.PROTCT
O.EADMIN
O.RESPON
O.IDAUTH
O.ACCESS
O.INTEGR
O.INTROP
O.IDANLZ
O.IDSCAN
O.AUDITS
O.INSTAL
O.IDSENS
T.SCNMLC X
T.SCNVUL X
T.FALACT X
T.FALREC X
T.FALASC X
T.MISUSE X
T.INADVE X
T.MISACT X
P.DETECT X X X
P.ANALYZ X
P.MANAGE X X X X X X X
P.ACCESS X X X
P.ACCACT X X
P.INTGTY X
P.PROTCT X X X
Table 6 Environment to Objective Correspondence
8.1.1.1 A.ACCESS
The TOE has access to all the IT System data it needs to perform its functions.
The O.INTROP objective ensures the TOE has the needed access.
8.1.1.2 A.DYNMIC
The TOE will be managed in a manner that allows it to appropriately address changes in the IT System the
TOE monitors.
The O.INTROP objective ensures the TOE has the proper access to the IT System. The O.PERSON objective
ensures that the TOE will manage appropriately.
8.1.1.3 A.ASCOPE
The TOE is appropriately scalable to the IT System the TOE monitors.
The O.INTROP objective ensures the TOE has the necessary interactions with the IT System it monitors.
8.1.1.4 A.PROTCT
The TOE hardware and software critical to security policy enforcement will be protected from
unauthorised physical modification.
The O.PHYCAL provides for the physical protection of the TOE hardware and software.
40
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8.1.1.5 A.LOCATE
The processing resources of the TOE will be located within controlled access facilities, which will prevent
unauthorised physical access.
The O.PHYCAL provides for the physical protection of the TOE.
8.1.1.6 A.MANAGE
There will be one or more competent individuals assigned to manage the TOE and the security of the
information it contains.
The O.PERSON objective ensures all authorised administrators are qualified and trained to manage the TOE.
8.1.1.7 A.NOEVIL
The authorised administrators are not careless, willfully negligent, or hostile, and will follow and abide by
the instructions provided by the TOE documentation.
The O.INSTAL objective ensures that the TOE is properly installed and operated and the O.PHYCAL objective
provides for physical protection of the TOE by authorised administrators. The O.CREDEN objective supports this
assumption by requiring protection of all authentication data.
8.1.1.8 A.NOTRST
The TOE can only be accessed by authorised users.
The O.PHYCAL objective provides for physical protection of the TOE to protect against unauthorised access. The
O.CREDEN objective supports this assumption by requiring protection of all authentication data.
8.1.1.9 T.COMINT
An unauthorised user may attempt to compromise the integrity of the data collected and produced by the
TOE by bypassing a security mechanism.
The O.IDAUTH objective provides for authentication of users prior to any TOE data access. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE data. The
O.INTEGR objective ensures no TOE data will be modified. The O.PROTCT objective addresses this threat by
providing TOE self-protection. The OE.PROTECT objective also serves to address this threat by ensuring that the
IT environment protects aspects of the TOE unable to protect themselves.
8.1.1.10 T.COMDIS
An unauthorised user may attempt to disclose the data collected and produced by the TOE by bypassing a
security mechanism.
The O.IDAUTH objective provides for authentication of users prior to any TOE data access. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE data. The
O.PROTCT objective addresses this threat by providing TOE self-protection. The OE.PROTECT objective also
serves to address this threat by ensuring that the IT environment protects aspects of the TOE unable to protect
themselves.
8.1.1.11 T.LOSSOF
An unauthorised user may attempt to remove or destroy data collected and produced by the TOE.
The O.IDAUTH objective provides for authentication of users prior to any TOE data access. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE data. The
O.INTEGR objective ensures no TOE data will be deleted. The O.PROTCT objective addresses this threat by
providing TOE self-protection.
41
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8.1.1.12 T.NOHALT
An unauthorised user may attempt to compromise the continuity of the System’s collection and analysis
functions by halting execution of the TOE.
The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE functions. The
O.IDSCAN, O.IDSENS, and O.IDANLZ objectives address this threat by requiring the TOE to collect and analyze
System data, which includes attempts to halt the TOE.
8.1.1.13 T.PRIVIL
An unauthorised user may gain access to the TOE and exploit system privileges to gain access to TOE
security functions and data.
The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE functions. The
O.PROTCT objective addresses this threat by providing TOE self-protection.
8.1.1.14 T.IMPCON
An unauthorised user may inappropriately change the configuration of the TOE causing potential
intrusions to go undetected.
The O.INSTAL objective states the authorised administrators will configure the TOE properly. The O.EADMIN
objective ensures the TOE has all the necessary administrator functions to manage the product. The O.IDAUTH
objective provides for authentication of users prior to any TOE function accesses. The O.ACCESS objective builds
upon the O.IDAUTH objective by only permitting authorised users to access TOE functions.
8.1.1.15 T.INFLUX
An unauthorised user may cause malfunction of the TOE by creating an influx of data that the TOE cannot
handle.
The O.OFLOWS objective counters this threat by requiring the TOE handle data storage overflows.
8.1.1.16 T.FACCNT
Unauthorised attempts to access TOE data or security functions may go undetected.
The O.AUDITS objective counters this threat by requiring the TOE to audit attempts for data accesses and use of
TOE functions.
8.1.1.17 T.SCNCFG
Improper security configuration settings may exist in the IT System the TOE monitors.
The O.IDSCAN objective counters this threat by requiring a TOE that contains a Scanner, collect and store static
configuration information that might be indicative of a configuration setting change. The ST will state whether this
threat must be addressed by a Scanner.
8.1.1.18 T.SCNMLC
Users could execute malicious code on an IT System that the TOE monitors which causes modification of
the IT System protected data or undermines the IT System security functions.
The O.IDSCAN objective counters this threat by requiring a TOE that contains a Scanner, collect and store static
configuration information that might be indicative of malicious code. The ST will state whether this threat must be
addressed by a Scanner.
42
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8.1.1.19 T.SCNVUL
Vulnerabilities may exist in the IT System the TOE monitors.
The O.IDSCAN objective counters this threat by requiring a TOE that contains a Scanner, collect and store static
configuration information that might be indicative of a vulnerability. The ST will state whether this threat must be
addressed by a Scanner.
8.1.1.20 T.FALACT
The TOE may fail to react to identified or suspected vulnerabilities or inappropriate activity.
The O.RESPON objective ensures the TOE reacts to analytical conclusions about suspected vulnerabilities or
inappropriate activity.
8.1.1.21 T.FALREC
The TOE may fail to recognize vulnerabilities or inappropriate activity based on IDS data received from
each data source.
The O.IDANLZ objective provides the function that the TOE will recognize vulnerabilities or inappropriate activity
from a data source.
8.1.1.22 T.FALASC
The TOE may fail to identify vulnerabilities or inappropriate activity based on association of IDS data
received from all data sources.
The O. IDANLZ objective provides the function that the TOE will recognize vulnerabilities or inappropriate activity
from multiple data sources.
8.1.1.23 T.MISUSE
Unauthorised accesses and activity indicative of misuse may occur on an IT System the TOE monitors.
The O.AUDITS and O.IDSENS objectives address this threat by requiring a TOE, that contains a Sensor, collect
audit and Sensor data.
8.1.1.24 T.INADVE
Inadvertent activity and access may occur on an IT System the TOE monitors.
The O.AUDITS and O.IDSENS objectives address this threat by requiring a TOE, that contains a Sensor, collect
audit and Sensor data.
8.1.1.25 T.MISACT
Malicious activity, such as introductions of Trojan horses and viruses, may occur on an IT System the TOE
monitors.
The O.AUDITS and O.IDSENS objectives address this threat by requiring a TOE, that contains a Sensor, collect
audit and Sensor data.
8.1.1.26 P.DETECT
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 or events that are indicative of inappropriate activity that
may have resulted from misuse, access, or malicious activity of IT System assets must be collected.
The O.AUDITS, O.IDSENS, and O.IDSCAN objectives address this policy by requiring collection of audit, Sensor,
and Scanner data.
43
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8.1.1.27 P.ANALYZ
Analytical processes and information to derive conclusions about intrusions (past, present, or future) must
be applied to IDS data and appropriate response actions taken.
The O.IDANLZ objective requires analytical processes be applied to data collected from Sensors and Scanners.
8.1.1.28 P.MANAGE
The TOE shall only be managed by authorised users.
The O.PERSON objective ensures competent administrators will manage the TOE and the O.EADMIN objective
ensures there is a set of functions for administrators to use. The O.INSTAL objective supports the O.PERSON
objective by ensuring administrator follow all provided documentation and maintain the security policy. The
O.IDAUTH objective provides for authentication of users prior to any TOE function accesses. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE functions. The
O.CREDEN objective requires administrators to protect all authentication data. The O.PROTCT objective
addresses this policy by providing TOE self-protection.
8.1.1.29 P.ACCESS
All data collected and produced by the TOE shall only be used for authorised purposes.
The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses. The O.ACCESS
objective builds upon the O.IDAUTH objective by only permitting authorised users to access TOE functions. The
O.PROTCT objective addresses this policy by providing TOE self-protection.
8.1.1.30 P.ACCACT
Users of the TOE shall be accountable for their actions within the IDS.
The O.AUDITS objective implements this policy by requiring auditing of all data accesses and use of TOE
functions. The O.IDAUTH objective supports this objective by ensuring each user is uniquely identified and
authenticated.
8.1.1.31 P.INTGTY
Data collected and produced by the TOE shall be protected from modification.
The O.INTEGR objective ensures the protection of data from modification.
8.1.1.32 P. PROTCT
The TOE shall be protected from unauthorised accesses and disruptions of TOE data and functions.
The O.OFLOWS objective counters this policy by requiring the TOE handle disruptions. The O.PHYCAL objective
protects the TOE from unauthorised physical modifications. The OE.PROTECT objective also serves to address this
policy by ensuring that the IT environment protects aspects of the TOE unable to protect themselves.
8.2 Security Requirements Rationale
This section provides evidence supporting the completeness of the components (requirements) in the Security
Target. Note that Table 7 indicates the requirements that effectively satisfy the individual objectives.
The purpose of the environmental objectives is to provide protection for the TOE that cannot be addressed through
IT measures. The defined objectives provide for physical protection of the TOE, proper management of the TOE,
and interoperability requirements on the TOE. Together with the IT security objectives, these environmental
objectives provide a complete description of the responsibilities of the TOE in meeting security needs.
44
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
All of the SFRs have been derived from the IDSSPP. All operations completed in this Security Target have been
completed in accordance with the IDSSPP.
8.2.1 Security Functional Requirements Rationale
All Security Functional Requirements (SFR) identified in this Security Target are fully addressed in this section and
each SFR is mapped to the objective for which it is intended to satisfy.
O.PROTCT
O.IDSCAN
O.IDSENS
O.IDANLZ
O.RESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
OE.PROTECT
FAU_GEN.1 X
FAU_SAR.1 X
FAU_SAR.2 X X
FAU_SAR.3 X
FAU_SEL.1 X X
FAU_STG.2 X X X X X
FAU_STG.4 X X
FIA_UAU.1 X X
FIA_ATD.1 X
FIA_UID.1 X X
FMT_MOF.1 X X X
FMT_MTD.1 X X X X
FMT_SMR.1 X
FPT_ITT.1 X
FPT_RVM.1a X X X X X
FPT_SEP.1a X X X X X
FPT_STM.1 X
IDS_SDC.1 X X
IDS_ANL.1 X
IDS_RCT.1 X
IDS_RDR.1 X X X
IDS_STG.1 X X X X X
IDS_STG.2 X
FPT_RVM.1b X
FPT_SEP.1b X
Table 7 Objective to Requirement Correspondence
8.2.1.1 O.PROTCT
The TOE must protect itself from unauthorised modifications and access to its functions and data.
The TOE is required to protect the audit data from deletion as well as guarantee the availability of the audit data in
the event of storage exhaustion, failure or attack [FAU_STG.2]. The System is required to protect the System data
from any modification and unauthorised deletion, as well as guarantee the availability of the data in the event of
storage exhaustion, failure or attack [IDS_STG.1]. The TOE is required to provide the ability to restrict managing
45
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
the behavior of functions of the TOE to authorised users of the TOE [FMT_MOF.1]. Only authorised administrators
of the System may query and add System and audit data, and authorised administrators of the TOE may query and
modify all other TOE data [FMT_MTD.1]. The TOE must ensure that all functions are invoked and succeed before
each function may proceed [FPT_RVM.1a]. The TSF must be protected from interference that would prevent it from
performing its functions [FPT_SEP.1a]. The TOE must protect TSF data that is being transferred between
distributed components of the TOE (i.e., the SMC java application, SMC appliance, and other TOE appliances)
[FPT_ITT.1].
8.2.1.2 O.IDSCAN
The Scanner must collect and store 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.
A System containing a Scanner is required to collect and store static configuration information of an IT System.
The type of configuration information collected must be defined in the ST [IDS_SDC.1]
8.2.1.3 O.IDSENS
The Sensor must collect and store information about all events that are indicative of inappropriate activity
that may have resulted from misuse, access, or malicious activity of IT System assets and the IDS.
A System containing a Sensor is required to collect events indicative of inappropriate activity that may have resulted
from misuse, access, or malicious activity of IT System assets of an IT System. These events must be defined in the
ST [IDS_SDC.1].
8.2.1.4 O.IDANLZ
The Analyzer must accept data from IDS Sensors or IDS Scanners and then apply analytical processes and
information to derive conclusions about intrusions (past, present, or future).
The Analyzer is required to perform intrusion analysis and generate conclusions [IDS_ANL.1]
8.2.1.5 O.RESPON
The TOE must respond appropriately to analytical conclusions.
The TOE is required to respond accordingly in the event an intrusion is detected [IDS_RCT.1]
8.2.1.6 O.EADMIN
The TOE must include a set of functions that allow effective management of its functions and data.
The TOE must provide the ability to review and manage the audit trail of the System [FAU_SAR.1, FAU_SAR.3,
FAU_SEL.1]. The System must provide the ability for authorised administrators to view all System data collected
and produced [IDS_RDR.1]. The TOE must ensure that all functions are invoked and succeed before each function
may proceed [FPT_RVM.1a]. The TSF must be protected from interference that would prevent it from performing
its functions [FPT_SEP.1a]
8.2.1.7 O.ACCESS
The TOE must allow authorised users to access only appropriate TOE functions and data.
The TOE is required to restrict the review of audit data to those granted with explicit read-access [FAU_SAR.2].
The System is required to restrict the review of System data to those granted with explicit read-access [IDS_RDR.1].
The TOE is required to protect the audit data from deletion as well as guarantee the availability of the audit data in
the event of storage exhaustion, failure or attack [FAU_STG.2]. The System is required to protect the System data
from any modification and unauthorised deletion [IDS_STG.1]. Users authorised to access the TOE are defined
using an identification and authentication process [FIA_UID.1, FIA_UAU.1]. The TOE is required to provide the
ability to restrict managing the behavior of functions of the TOE to authorised users of the TOE [FMT_MOF.1].
46
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
Only authorised administrators of the System may query and add System and audit data, and authorised
administrators of the TOE may query and modify all other TOE data [FMT_MTD.1].
8.2.1.8 O.IDAUTH
The TOE must be able to identify and authenticate users prior to allowing access to TOE functions and
data.
The TOE is required to restrict the review of audit data to those granted with explicit read-access [FAU_SAR.2].
The System is required to restrict the review of System data to those granted with explicit read-access [IDS_RDR.1].
The TOE is required to protect the stored audit records from unauthorised deletion [FAU_STG.2]. The System is
required to protect the System data from any modification and unauthorised deletion, as well as guarantee the
availability of the data in the event of storage exhaustion, failure or attack [IDS_STG.1]. Security attributes of
subjects use to enforce the authentication policy of the TOE must be defined [FIA_ATD.1]. Users authorised to
access the TOE are defined using an identification and authentication process [FIA_UID.1, FIA_UAU.1]. The TOE
is required to provide the ability to restrict managing the behavior of functions of the TOE to authorised users of the
TOE [FMT_MOF.1]. Only authorised administrators of the System may query and add System and audit data, and
authorised administrators of the TOE may query and modify all other TOE data [FMT_MTD.1]. The TOE must be
able to recognize the different administrative and user roles that exist for the TOE [FMT_SMR.1]. The TOE must
ensure that all functions are invoked and succeed before each function may proceed [FPT_RVM.1a]. The TSF must
be protected from interference that would prevent it from performing its functions [FPT_SEP.1a].
8.2.1.9 O.OFLOWS
The TOE must appropriately handle potential audit and System data storage overflows.
The TOE is required to protect the audit data from deletion as well as guarantee the availability of the audit data in
the event of storage exhaustion, failure or attack [FAU_STG.2]. The TOE must prevent the loss of audit data in the
event the audit trail is full [FAU_STG.4]. The System is required to protect the System data from any modification
and unauthorised deletion, as well as guarantee the availability of the data in the event of storage exhaustion, failure
or attack [IDS_STG.1]. The System must prevent the loss of audit data in the event the audit trail is full
[IDS_STG.2].
8.2.1.10 O.AUDITS
The TOE must record audit records for data accesses and use of the System functions.
Security-relevant events must be defined and auditable for the TOE [FAU_GEN.1]. The TOE must provide the
capability to select which security-relevant events to audit [FAU.SEL.1]. The TOE must prevent the loss of
collected data in the event the audit trail is full [FAU_STG.4]. The TOE must ensure that all functions are invoked
and succeed before each function may proceed [FPT_RVM.1a]. The TSF must be protected form interference that
would prevent it from performing its functions [FPT_SEP.1a]. Time stamps associated with an audit record must be
reliable [FPT_STM.1].
8.2.1.11 O.INTEGR
The TOE must ensure the integrity of all audit and System data.
The TOE is required to protect the audit data from deletion as well as guarantee the availability of the audit data in
the event of storage exhaustion, failure or attack [FAU_STG.2]. The System is required to protect the System data
from any modification and unauthorised deletion [IDS_STG.1]. Only authorised administrators of the System may
query or add audit and System data [FMT_MTD.1]. The System must protect the collected data from modification
and ensure its integrity when the data is transmitted to another IT product [FPT_ITC.1, FPT_ITI.1]. The TOE must
ensure that all functions to protect the data are not bypassed [FPT_RVM.1a]. The TSF must be protected form
interference that would prevent it from performing its functions [FPT_SEP.1a].
47
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
8.2.1.12 OE.PROTECT
The IT environment will protect itself and the TOE from external interference or tampering.
The IT environment is required to protect the application (as opposed to the appliance) portion of the TOE so that
the TOE is not vulnerable to interference from tampering [FPT_SEP.1b] or potential bypass attempts
[FPT_RVM.1b]. Note that the TOE objectives (above) reference the TOE or TSF and while FPT_RVM.1a and
FPT_SEP.1a are referenced, it should be assumed that FPT_RVM.1b and FPT_SEP.1b implicitly serve to complete
the protection of the TOE via support from the IT environment as indicated here.
8.3 Security Assurance Requirements Rationale
This ST contains the assurance requirements from the CC EAL2 assurance package augmented with ALC_FLR.2.
The CC permits assurance packages to be augmented, which allows the addition of assurance components from the
CC not already included in the EAL. Augmentation was chosen to provide the added assurance acquired by
defining flaw remediation procedures and correcting security flaws. This ST is based on good commercial
development practices to provide a low to moderate level of assurance. While the System may monitor a hostile
environment, it is expected to be in a non-hostile position and embedded in or protected by other products designed
to address threats that correspond with the intended environment. Note that the security environment assumes
physical protection. The TOE itself offers a very limited interface that can only be configured during initialization,
offering essentially no opportunity for an attacker to subvert the security policies without physical access. As such, it
is believed that EAL 2, augmented with ALC_FLR.2, provides an appropriate level of assurance in the security
functions offered by the TOE.
8.4 Requirement Dependency Rationale
The ST satisfies all the requirement dependencies of the Common Criteria. Table 8 Requirement Dependencies
Rationale lists each requirement from Section 5.1 with a dependency and indicates which requirement was included
to satisfy the dependency. For each dependency not included, a justification is proved.
Functional Component Dependency Included
FAU_GEN.1 FPT_STM.1 YES
FAU_SAR.1 FAU_GEN.1 YES
FAU_SAR.2 FAU_SAR.1 YES
FAU_SAR.3 FAU_SAR.1 YES
FAU_SEL.1 FAU_GEN.1 and FMT_MTD.1 YES
FAU_STG.2 FAU_GEN.1 YES
FAU_STG.4 FAU_STG.1 NO
FIA_UAU.1 FIA_UID.1 YES
FMT_MOF.1 FMT_SMR.1 YES
FMT_MTD.1 FMT_SMR.1 YES
FMT_SMR.1 FIA_UID.1 YES
Table 8 Requirement Dependencies Rationale
FAU_STG.4 includes a dependency on FAU_STG.1. FAU_STG.1 is not included in this ST, however FAU_STG.2
(which is hierarchical to FAU_STG.1) is included and satisfies the dependency.
CCv2.3 added a new dependency of FMT_SMF.1 to FMT_MOF.1 and FMT_MTD.1. FMT_SMF.1 has not been
added to this ST because the IDSSPP was evaluated and it was concluded that the IDSSPP contained all the
management requirements it needed to satisfy the PP objectives. Therefore, the FMT_SMF.1 requirement is not
necessary to meet any PP objectives and has not been included in this ST.
8.5 Explicitly Stated Requirements Rationale
A 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
48
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
requirements is to address the unique nature of IDS data and provide for requirements about collecting, reviewing
and managing the data. These requirements have no dependencies since the stated requirements embody all the
necessary security functions.
8.6 Strength of Function Rationale
The TOE minimum strength of function is SOF-basic. The TOE is intended to operate in commercial and DoD low
robustness environments processing unclassified information. This security function is in turn consistent with the
security objectives described in section 4.
8.7 TOE Summary Specification Rationale
Each subsection in Section 6, the TOE Summary Specification, describes a security function of the TOE. Each
description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding
security function. The set of security functions work together to satisfy all of the security functions and assurance
requirements. Furthermore, all of the security functions are necessary in order for the TSF to provide the required
security functionality.
This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that the security
functions are suitable to meet the TOE security requirements. The collection of security functions work together to
provide all of the security requirements. The security functions described in the TOE summary specification are all
necessary for the required security functionality in the TSF. Table 9 Security Functions vs. Requirements Mapping
demonstrates the relationship between security requirements and security functions.
Security
Audit
Identification
&
Authentication
Security
Management
Protection
of
TOE
Security
Functions
Intrusion
Detection
System
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
FIA_UAU.1 X
FIA_ATD.1 X
FIA_UID.1 X
FMT_MOF.1 X
FMT_MTD.1 X
FMT_SMR.1 X
FPT_ITT.1 X
FPT_RVM.1a X
FPT_SEP.1a X
FPT_STM.1 X
IDS_SDC.1 X
IDS_ANL.1 X
IDS_RCT.1 X
IDS_RDR.1 X
IDS_STG.1 X
49
StealthWatch V5.6.1 Security Target Version 1.0, 03/05/08
Security
Audit
Identification
&
Authentication
Security
Management
Protection
of
TOE
Security
Functions
Intrusion
Detection
System
IDS_STG.2 X
Table 9 Security Functions vs. Requirements Mapping
8.8 PP Claims Rationale
• See section 7, Protection Profile Claims.
50