McAfee Incorporated
IntruShield Product Family
Intrusion Prevention System
Security Target
Version 1.21
August 11, 2008
Prepared for:
McAfee, Incorporated
3965 Freedom Circle
Santa Clara, CA 95054
Prepared By:
Science Applications International Corporation
Common Criteria Testing Laboratory
7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046
McAfee Incorporated
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
1. SECURITY TARGET INTRODUCTION...........................................................................................................4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4
1.2 CONFORMANCE CLAIMS.................................................................................................................................4
1.3 CONVENTIONS, TERMINOLOGY, ACRONYMS ..................................................................................................5
1.3.1 Conventions ...........................................................................................................................................5
1.3.2 Acronyms ...............................................................................................................................................5
1.3.3 Terminology...........................................................................................................................................6
2 TOE DESCRIPTION..........................................................................................................................................9
2.1 PRODUCT TYPE.............................................................................................................................................10
2.2 PRODUCT DESCRIPTION................................................................................................................................10
2.3 PRODUCT FEATURES.....................................................................................................................................10
2.4 SECURITY ENVIRONMENT TOE BOUNDARY.................................................................................................11
2.4.1 Physical Boundaries ............................................................................................................................11
2.4.2 Logical Boundaries..............................................................................................................................15
3 SECURITY ENVIRONMENT.........................................................................................................................17
3.1 THREATS TO SECURITY.................................................................................................................................17
3.1.1 TOE Threats.........................................................................................................................................17
3.1.2 IT System Threats ................................................................................................................................17
3.2 ORGANIZATION SECURITY POLICIES ............................................................................................................17
3.3 SECURE USAGE ASSUMPTIONS .....................................................................................................................18
3.3.1 Intended Usage Assumptions...............................................................................................................18
3.3.2 Physical Assumptions ..........................................................................................................................18
3.3.3 Personnel Assumptions........................................................................................................................18
3.3.4 Operating System Assumption .............................................................................................................18
4 SECURITY OBJECTIVES ..............................................................................................................................19
4.1 IT SECURITY OBJECTIVES FOR THE TOE......................................................................................................19
4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT...........................................................................................19
4.2.1 Security Objectives for the IT Environment.........................................................................................20
5 IT SECURITY REQUIREMENTS..................................................................................................................21
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................21
5.1.1 Security audit (FAU)............................................................................................................................21
5.1.2 Identification and authentication (FIA)...............................................................................................23
5.1.3 Security management (FMT) ...............................................................................................................24
5.1.4 Protection of the TOE security functions (FPT) ..................................................................................24
5.1.5 IDS Component Requirements (IDS)...................................................................................................25
5.2 SECURITY FUNCTIONAL REQUIREMENT FOR THE IT ENVIRONMENT ............................................................27
5.2.1 Security audit (FAU)............................................................................................................................27
5.2.2 Protection of the TOE security functions (FPT) ..................................................................................27
5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................29
5.3.1 Configuration Management (ACM).....................................................................................................29
5.3.2 Delivery and Operation (ADO) ...........................................................................................................31
5.3.3 Development (ADV).............................................................................................................................32
5.3.4 Guidance Documents (AGD)...............................................................................................................34
5.3.5 Life Cycle Support (ALC) ....................................................................................................................35
5.3.6 Security Testing (ATE).........................................................................................................................36
5.3.7 Vulnerability Assessment.....................................................................................................................38
6 TOE SUMMARY SPECIFICATION..............................................................................................................40
6.1 TOE SECURITY FUNCTIONS..........................................................................................................................40
6.1.1 Security Audit.......................................................................................................................................40
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
2
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
6.1.2 Identification and Authentication ........................................................................................................42
6.1.3 Security Management ..........................................................................................................................43
6.1.4 Protection of Security Functions .........................................................................................................44
6.1.5 System Data Collection........................................................................................................................44
6.1.6 System Data Analysis...........................................................................................................................45
6.1.7 System Data Review, Availability and Loss.........................................................................................47
6.2 TOE SECURITY ASSURANCE MEASURES ...................................................................................................48
6.2.1 Process Assurance...............................................................................................................................48
6.2.2 Delivery and Guidance........................................................................................................................48
6.2.3 Development ........................................................................................................................................49
6.2.4 Life-Cycle Support...............................................................................................................................49
6.2.5 Tests.....................................................................................................................................................50
6.2.6 Vulnerability Assessment.....................................................................................................................50
7 PROTECTION PROFILE CLAIMS...............................................................................................................51
8 RATIONALE.....................................................................................................................................................53
8.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................53
8.1.1 Security Objectives Rationale for the TOE and Environment..............................................................53
8.2 SECURITY REQUIREMENTS RATIONALE........................................................................................................58
8.2.1 Security Functional Requirements Rationale ......................................................................................58
8.2.2 Strength of Function (SOF) Rationale.................................................................................................62
8.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE....................................................................................62
8.4 REQUIREMENT DEPENDENCY RATIONALE....................................................................................................63
8.5 EXPLICITLY STATED REQUIREMENTS RATIONALE........................................................................................63
8.6 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................63
8.7 PP CLAIMS RATIONALE................................................................................................................................64
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
3
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
1. Security Target Introduction
This section identifies the Security Target and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. McAfee Incorporated provides the TOE, which includes the
IntruShield 1200, 1400, 2600, 2700, 3000, 4000, and the IntruShield 4010 Sensors and an IntruShield Security
Management System (ISM).
• 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.1 Security Target, TOE and CC Identification
ST Title – IntruShield Product Family, Intrusion Prevention System, Security Target
ST Version –Version 1.21
ST Date – August 11, 2008
TOE Identification – The TOE is composed of the following three components:
The TOE is identified as one or more of these sensors:
1. McAfee Incorporated IntruShield Sensors,
a. IntruShield 1200 appliance, Rev. 3 or earlier
b. IntruShield 1400 appliance, Rev. 3 or earlier
c. IntruShield 2600 appliance, Rev. 7 or earlier
d. IntruShield 2700 appliance, Rev. 1
e. IntruShield 3000 appliance, Rev. 6 or earlier
f. IntruShield 4000 appliance, Rev. 7 or earlier
g. IntruShield 4010 appliance, Rev. 6 or earlier
2. IntruShield Security Management System (ISM) Version 3.1.5.13
3. Sensor Build Version 3.1.40.6
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005.
1.2 Conformance Claims
This TOE is conformant to the following CC specifications:
• Common Criteria (CC) for Information Technology (IT) Security Evaluation Part 2: Security functional
requirements, Version 2.3, August 2005.
• Part 2 Extended (with IDS_SDC.1, IDS_ANL.1, IDS_RCT.1, IDS_RDR.1, IDS_STG.1, and IDS_STG.2)
• Common Criteria (CC) for Information Technology Security Evaluation Part 3: Security assurance
requirements, Version 2.3, August 2005.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
4
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
• Part 3 Conformant
• Evaluation Assurance Level 3 (EAL3)
This TOE is conformant to the following Protection Profiles (PP):
• U.S. Government Intrusion Detection System System Protection Profile (IDSSPP), Version 1.6, April 4,
2006.
1.3 Conventions, Terminology, Acronyms
This section specifies the formatting information used in the Security Target.
1.3.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 in parenthesis placed at the end of the component. For example
FDP_ACC.1(a) and FDP_ACC.1(b) 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)”.
• Requirements that have been modified from the original text in the Common Criteria to be compliant with
an International Interpretation are identified with (RI #n).
• Requirements that have been modified from the original text in the Common Criteria to be compliant with
an Interpretation recommended by the U.S. Common Criteria Evaluation and Validation Scheme are
identified with (NIAP ..).
• Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.3.2 Acronyms
The acronyms used within this Security Target:
ACM Access Control Management
AGD Administrator Guidance Document
CC Common Criteria
CM Control Management
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
5
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
DAC Discretionary Access Control
DO Delivery Operation
EAL Evaluation Assurance Level
FIPS Federal Information Processing Standards Publication
GB Gigabyte
IDS Intrusion Prevention System
I/O Input/Output
NIST National Institute of Standards and Technology
PP Protection Profile
SF Security Functions
SFR Security Functional Requirements
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
TSP TOE Security Policy
TSC TSF Scope of Control
VLAN Virtual Local Area Network
1.3.3 Terminology
The following terminology is used in this document:
Alert An alert is a notification of a system event, attack, or other incident that triggers the
intrusion Detection System.
Alert Manager A graphical user interface for viewing specific attack information in the IntruShield
System. The Alert Manager interface is part of the ISM, and focuses on alert forensic
analysis.
Appropriate Any administrator with the authorization to perform the administrator action for
Administrator discussion.
Attack A set of actions performed by an attacker that poses a threat to the security state of a
protected entity in terms of confidentiality, integrity, authenticity, availability,
authorization, and access policies.
CIDR Classless Inter-Domain Routing. A scheme which allocates blocks of Internet addresses
in a way that allows summarization into a smaller number of routing table entries. A
CIDR address contains the standard 32-bit IP address but includes information on how
many bits are used for the network prefix. For example, in the CIDR address
123.231.121.04/22, the “/22” indicates the first 25 bits are used to identify the unique
network leaving the remaining bits to identify the specific host
Denial of In a Denial of Service (DoS) attack, the attacker attempts to crash a service (or the
Service machine), overload network links, overload the CPU, or fill up the disk. The attacker
does not always try to gain information, but to simply act as a vandal to prevent you from
making use of your machine. Ping floods and Smurf attacks are examples of DoS attacks.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
6
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
Distributed Distributed Denial of Service (DDoS) attacks usually consist of standard DoS attacks
Denial of orchestrated by attackers covertly controlling many, sometimes hundreds, of different
Service machines.
HTTPS The secure hypertext transfer protocol (HTTPS) is a communications protocol designed
to transfer encrypted information between computers over the World Wide Web. HTTPS
is http using a Secure Socket Layer (SSL).
Intrusion Unauthorized access to, and/or activity in, an information system. Usually for the purpose
of tampering with or disrupting normal services. See also Attack.
Intrusion The process of identifying that an intrusion has been attempted, is occurring, or has
Detection occurred.
NTP Network Time Protocol provides a mechanism to synchronize time on computers across
an internet. The specification for NTP version 3 is defined in RFC 1305. Such
synchronization can be very useful for multi-machine activities that depend upon
accurate time stamps.
Policy A user-configured security rule that determines the permission of traffic across a
network. Policies can set rules for protocols (HTTP, UDP), machines (NT, Solaris),
operating systems (Unix), and other types of network information. A policy also defines
what actions should be taken in the event of non-permissible activity.
Policy All activities for which the underlying traffic content may not be malicious by itself, but
Violations are explicitly forbidden by the usage policies of the network as defined by a security
policy. These can include “protocol violations” wherein packets do not conform to
network protocol standards. (For example, they are incorrectly structured, have an invalid
combination of flags set, or contain incorrect values.) Examples might include TCP
packets with their SYN and RST flags enabled, or an IP packet whose specified length
doesn’t match its actual length. A protocol violation can be an indication of a possible
attack, but can also be triggered by malfunctioning software or hardware.
Port Cluster Port Cluster is a more intuitive term for an Interface Group. Interface Group An
interface group enables multiple sensor ports to be grouped together for the effective
monitoring of asymmetric environments. Interface groups normalize the impact of traffic
flows split across multiple interfaces, thus maintaining state to avoid information loss.
Once configured, an interface group appears in the Resource Tree as a single interface
node (icon) under the sensor where it is located. All of the ports that make up the
interface are configured as one logical entity, keeping the configuration consistent.
MySQL A Relational database. Allows the definition of data structures, storage and retrieval
DATABASE operations, and integrity constraints. The data and relations between them are kept in
organized tables, which are collections of records and each record in a table contains the
same fields.
Roles A class of user privileges that determines the authorized activities of the various users in
the system.
Sensor The sensor is a network device containing the intrusion detection engine. It analyzes
network traffic, searching for signs of unauthorized activity.
Signature Activities or alterations to an information system indicating an attack or attempted
attack, detectable by examination of audit trail logs.
Span Mode One of the monitoring modes available for an IntruShield sensor. Functions by mirroring
the packet information on a switch or hub and sending the information to a sensor for
inspection, while continuing the transmission of traffic with negligible latency. SPAN
mode is typically half-duplex, and works through a connection of a sensor to a port on a
hub or the SPAN port of a switch.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
7
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
SPAN Port On a switch, SPAN mirrors the traffic at one switched segment onto a predefined port,
known as a SPAN port.
SSL A secure socket layer (SSL) is an encryption protocol invoked on a Web server that uses
HTTPS.
Tap A tap is hardware device that passes traffic unidirectionally from a network segment to
the IDS. Traffic is mirrored as it passes through the tap. This mirror image is sent to the
IDS for inspection. This prevents traffic passing from being directed at the IDS.
Tap Mode One of the monitoring modes available for an IntruShield sensor. Functions by mirroring
the packet information and sending the information to a sensor for inspection, while
continuing the transmission of traffic with negligible latency. Tap mode works through
installation of an external wire tap, a port on a hub, the SPAN port of a switch, or through
an internal tap when deploying the I-2600. Also known as passive monitoring mode.
Trojan Horse A computer program that has a useful function, but which also contains additional
hidden, typically malicious functions.
Virtual IDS An IntruShield feature that enables you to logically segment a sensor into a large number
of virtual sensors, each of which can be customized with its own security policy. Virtual
IDS (VIDS) are represented in the ISM as interfaces and sub-interfaces.
VLAN Virtual Local Area Network. A logical grouping of two or more nodes which are not
necessarily on the same physical network segment, but which share the same network
number. This is often associated with switched Ethernet networks.
In McAfee Incorporated, also an administrative interface that allows an administrator to
change the type of monitored traffic to a VLAN.
Vulnerability Any characteristic of a computer system that will allow someone to keep it from
operating correctly, or that will let unauthorized users take control of the system.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
8
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
2 TOE Description
The TOE is the McAfee, Inc., IntruShield Intrusion Prevention System product. The TOE consists of two main
components that are: the IntruShield sensor(s) and the IntruShield Security Management System (ISM).
The following figure provides a high-level visual representation of the TOE.
S
e
n
s
o
r
Manager
Update
Server
Browser
(Administrator
and user
interface)
Network
TOE
Collection
IntruShield sensors are high-performance, scalable, and flexible content processing appliances. The IntruShield
sensor performs stateful inspection for each packet to discover and prevent intrusions, misuse, denial of service
(DoS) attacks, and distributed denial of service (DDoS) attacks. McAfee Incorporated offers seven types of sensor
appliances providing different bandwidth and deployment strategies. These are the IntruShield 1200, IntruShield
1400, the IntruShield 2600, IntruShield 2700, IntruShield 3000, IntruShield 4000, and the IntruShield 4010 sensors.
All seven sensor types provide the same security functions.
The ISM consists of software that is used to configure and manage an IntruShield deployment. The ISM is a set of
applications, MySQL DATABASE is embedded. MySQL database is installed during ISM installation and is
configured so that it can be accessed only by the TOE. The MySQL database must reside on the same platform as
does the ISM. ISM is available in three versions: IntruShield Global Manager, IntruShield Manager, and IntruShield
Starter Manager. All versions of the ISM are part of the TOE and are the same software. All versions of the ISM
operate within an IT environment composed of an Intel-based hardware platform with a Windows 2000/2003
operating system (OS). The difference between the three versions is one of scalability. The IntruShield Starter
Manager supports up to 2 IntruShield sensors, the IntruShield Manager supports up to 6 IntruShield sensors and the
IntruShield Global Manager supports unlimited number of IntruShield sensors of any kind.
The McAfee Incorporated Update Server is a McAfee-owned and operated file server that provides updates to the
signature files and software of IntruShield sensors in customer installations. The Update Server always resides at
McAfee Incorporated.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
9
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
2.1 Product Type
The IntruShield system from McAfee Incorporated Corporation is a network Intrusion Prevention system (IPS) that
offers real-time network intrusion detection and prevention1
against the following types of attacks for enterprise
networks:
• network traffic
• detected known vulnerabilities.
2.2 Product Description
The IntruShield IPS product is a combination of network appliances and software built for the detection and
prevention of intrusions, denial of service (DoS) attacks, distributed denial of service (DDoS) attacks, and network
misuse. The IntruShield IPS combines real-time detection and prevention for the most comprehensive and effective
network security system. The IntruShield system enables highly accurate network attack detection and prevention at
up to 2 Gbps. The product line includes the IntruShield 1200, IntruShield 1400, the IntruShield 2600, IntruShield
2700, IntruShield 3000, IntruShield 4000, and the IntruShield 4010 sensors, and the IntruShield Security
Management System (ISM).
The IntruShield IPS system is composed of a family of sensor appliances and an ISM. The sensor appliances are
stand-alone appliances from McAfee Incorporated. The seven sensor appliances are the IntruShield 1200,
IntruShield 1400, the IntruShield 2600, the IntruShield 2700, the IntruShield 3000, the IntruShield 4000, and the
IntruShield 4010 sensors. All other components of the product are software only components that run on a
Windows workstation. The ISM is an IPS management solution for managing IntruShield sensor appliance
deployments for large and distributed enterprise networks. The ISM operates with an MYSQL DATABASE to
persist configuration information and alert data. ISM for Windows 2000/2003 includes the MySQL database.
2.3 Product Features
The TOE implements the following features:
The Sensor Subsystem performs the following components:
• Traffic Capture is non–intrusive and captures packets into a data store for review.
• Load balancing and protocol verification makes security decisions such that it can filter packets of no
interest.
• Denial of Service detection and response detects DoS attacks and provides an alert capability and the
capability to drop packets identified that are part of the DoS attack.
• Signature detection and anomaly detection performs anomaly detection, logs attack information, and
performs response functions. The response functions include the following: alert, packet log, TCP reset,
ICMP host unreachable, forward blocking, and drop packets.
• Sensor management is the interface between the sensor and the ISM. It has the responsibility to push
policies that have been defined in the Management Subsystem to the appropriate sensor module.
The ISM provides management functions to manage IntruShield sensor appliance deployments for large and
distributed enterprise networks. The ISM is an intuitive, scalable, powerful web-based security management system
that provides network intrusion prevention. It offers features to define, distribute, enforce, and audit security policies
to protect critical servers, data centers, individual departments, and distributed branch and remote offices of a global
business. The ISM provides a Web-based interface to the sensor, also referred to as the ISM console. The ISM is a
centralized web-based application that runs on a client platform. The ISM performs real-time alert analysis. This
analysis provides intelligent management and analysis of alerts in real time with granular drill-down capabilities and
color-coding that enable the administrators to quickly pinpoint the target, source, and severity of network attacks.
1
Note that prevention is accomplished with varying effectiveness. When the product is in-line, it can drop network
packets. When it is not in-line, it can send resets or other responses that might serve to stop an information
exchange.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
10
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The management features provided by the ISM include the following:
• Threat Updates: An Update Server controlled by McAfee Incorporated delivers signature updates without
requiring sensor reboots, providing protection against newly-discovered attacks.
• Granular Security Policy Management: Flexible and custom policy management per sensor — from
multiple network segments to individual hosts — delivers improved attack detection and prevention.
• Administrative Domains: Scalable security policy administration with role-based access control allows
delegation of administrative responsibilities.
• Forensic Analysis: Analysis tools, including enable detailed historical and real-time forensic analysis to
determine network attack patterns. Note that while the product also includes some report generation
capabilities, those capabilities are not included in the scope of evaluation as the resulting reports serve to
make audit data accessible to users beyond those allowed in the security functional requirements.
• Response management: A set of response actions — including user-defined responses and notification
capabilities — provide proactive attack notification and prevention.
The McAfee Incorporated Update Server is a McAfee Incorporated-owned and -operated file server that updates the
signature files of IntruShield sensors in McAfee Incorporated customer installations. McAfee Incorporated uses the
Update Server to securely provide signature updates. McAfee Incorporated develops and releases signature updates
as they are developed. Since new vulnerabilities are discovered almost daily, signature updates are released on a
regular basis. These new signatures are made available to customers through the Internet via the McAfee
Incorporated Update Server.
Note that other product updates and patches can also be made available via the Update Server. However, such
changes to the product would serve to take the product out of its evaluated configuration since it would subsequently
be running code that has not been subject to evaluation per this Security Target. As such, automatic patch updates
must be disabled in the evaluated configuration so that the administrator can selectively apply only signature
updates.
2.4 Security Environment TOE Boundary
The TOE includes both physical and logical boundaries.
2.4.1 Physical Boundaries
The components of the IntruShield IPS TOE are the Collection Subsystem and the ISM Subsystem. An Update
Server subsystem is also available, but since it is neither delivered to nor operated by the TOE users, it is outside the
TOE boundary. Each subsystem performs dedicated functions. The following figure provides a high-level depiction
of the IntruShield subsystem architecture.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
11
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
Manager Sub System
Home
Page
System
Health
Config
Page
Alert
Manager
Collection Sub System
Detection
Mechanism
Monitor and
Analyze
Sensor:
Update Server
2.4.1.1 Collection Subsystem
The Collection Subsystem is provided by the IntruShield Sensor appliance. The primary function of an IntruShield
sensor is to analyze traffic on selected network segments and to respond when an attack is detected. The sensor
examines the header and data portion of every network packet, looking for patterns and behavior in the network
traffic that indicate malicious activity. The sensor examines packets according to user-configured policies, or rule
sets, which determine what attacks to watch for, and how to react with countermeasures if an attack is detected. If an
attack is detected, the sensor raises an alert to describe the event, and responds according to its configured policy.
Sensors can perform many types of attack responses, including generating alerts and packet logs, resetting TCP
connections, “scrubbing” malicious packets, and even dropping packets entirely before they reach their target.
The IntruShield system is a network-based Intrusion Prevention System (IPS) that combines network sensor
appliances and management software for the accurate detection and prevention of known attacks using signature
detection, unknown (first strike) attacks using anomaly detection, denial of service (DoS) attacks, and distributed
denial of service (DDoS) attacks. The IntruShield IPS couples real-time IDS with prevention—the ability to block
attacks before they reach their target—to offer the most powerful, comprehensive and effective network security
system in the market.
Once the packet is captured, it is analyzed into its corresponding protocol fields. The sensor analyzes a frame
completely and thoroughly from Layers two through seven, and understands the semantics of the protocol fields
even at the Application Layer. After it analyzes the protocols, it verifies that the packet conforms to the protocol
specification. IntruShield then passes the parsed packet through its DoS, Signature, and Anomaly detection engines.
This enables IntruShield to be very efficient in terms of packet processing because the packet is “peeled” only once
and then fed to the corresponding detection engines.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
12
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
Signature detection techniques systematically scan network traffic looking for signature patterns of known attacks,
comparing these patterns against an extensive database of signatures. Anomaly detection determines a baseline of
normal behavior of network traffic, and then attempts to detect intrusions by noting significant departures from
normal behavior. Signature-based detection concentrates on known attack patterns, while anomaly detection is best
at picking up new or unknown attacks. Denial of Service (DoS) attack detection characterizes normal traffic using
pre-programmed thresholds or real-time, self-learning distributions, and then using this data to detect what might
constitute a maliciously excessive consumption of network bandwidth, host processing cycles or other resources.
The sensor can operate in three modes:
• Inline: The product is installed as an appliance within the network that applicable traffic must flow through.
• Tap: The network traffic flows between the clients and servers and the data is copied by the tap to the
sensor which is essentially invisible to the other network entities. Note that the TOE cannot inject response
packets back through an external tap, so IntruShield sensors offer Response ports through which a response
packet (such as a TCP reset) can be injected to close a malicious connection. Sometimes the attacker can
succeed in causing the intended damage when the attack packet reaches its intended victim host before the
TCP reset closes the connection. Hence, inline mode is more effective in preventing an attack.
• Span: The traffic is spanned off either the server side or the client side of a router or switch, copying both
the incoming and outgoing traffic from any one of the ports. This requires a special network device that has
a span port capability. Note that SPAN mode is also a “sniffing” mode, which—unlike inline mode—does
not enable the TOE to prevent attacks from reaching their targets. However, While the TOE can issue
response packets via the sensor’s response ports, some switches allow response packets to be injected by an
IPS back through the SPAN port.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
13
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
Unlike single-port sensors, a single multi-port IntruShield sensor can monitor many network segments in any
combination of operating modes—that is, the monitoring or deployment mode for the sensor —SPAN mode, tap
mode, or in-line mode.2
Additionally, IntruShield’s Virtual IDS (VIDS) feature enables you to further segment a
port on a sensor into many “virtual sensors.” A VIDS can be dedicated to a specific network port with monitoring
rules appropriate for that segment which might be different than the rules used to monitor other segments.
Alternately, if a monitored network segment includes the use of Virtual LANs (VLANs) or Classless Inter-Domain
Routing (CIDR), one or more VIDS can be directed at monitoring them with VIDS each configured with distinct
monitoring rules. Note that VIDS are not particularly security relevant in and of themselves, but rather serve to
organize and distinguish monitoring rules.
2.4.1.2 Manager Subsystem
The ISM is the Manager Subsystem. The ISM is a dedicated Windows 2000/2003 platform running the ISM
software. The ISM is also referred to as The Manager. There are three versions of the ISM:
1. IntruShield Global Manager supports unlimited number of sensors and is best suited for global IPS
deployments;,
2. IntruShield Manager that supports deployments of up to six sensors.
3. IntruShield Starter Manager that supports up to 2 sensors
Functionally, the products are otherwise identical. The Security Target uses the term “ISM” to describe any of the
three versions.
The ISM software is a Web-based user interface for configuring and managing the IntruShield Sensors.
The ISM has the following components:
• Home Page (formerly known as Network Console) is the first screen displayed after the user logs on to the
system. The Home Page displays system health—i.e., whether all components of the system are functioning
properly, the number of unacknowledged alerts in the system and the configuration options available to the
current user. Options available within the Network Console are determined by the current user’s assigned
role(s).
• System Health Viewer displays the status of the ISM, database, and any deployed sensors; including all
system faults.
• System Configuration Tool provides all system configuration options, and facilitates the configuration of
sensors, administrative domains, users, roles, attack policies and responses, user-created signatures, and
system reports. Access to various activities, such as user management, system configuration, or policy
management is based on the current user’s role(s) and privileges.
• Alert Manager displays detected security events that violate your configured security policies. The Alert
Manager provides powerful drill-down capabilities to enable you to see all the details on a particular alert,
including its type, source and destination addresses,
An administrator or user can directly use the ISM interface from the server itself as it is a Windows ISM server.
The keyboard, mouse and screen interfaces into the ISM interface are customer provided.
The ISM operates with a MYSQL DATABASE (relational database management system) for storing persistent
configuration information and event data. The ISM for Windows 2000/2003 includes a MySQL database that is
installed during ISM software installation.
2.4.1.3 Update Server
As stated in Section 2.3, the Update Server is a McAfee Incorporated -owned and -operated file server that updates
the signature files of IntruShield sensors in customer installations. McAfee Incorporated uses the Update Server to
securely provide signature updates at the request of the ISM (i.e., per administrator direction). When initiated, the
2
For these three modes please refer to the Getting Started Guide, Chapter 5.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
14
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
ISM polls the McAfee Incorporated Update Server, and compares the file on the Update Server with what is already
available in the ISM to determine what it needs to download. Once it has received the update, the ISM then
determines what signatures need to be pushed out to sensors based on the policy applied to the sensor.
2.4.2 Logical Boundaries
The logical boundaries of the TOE are divided into two broad groups, one related to the administration and security
attributes associated with the TOE (Security Audit, Identification and Authentication, Security Management, and
Protection of Security Functions), and the other related to the collection and analysis of the network traffic (System
Data Collection, Data Analysis and Data Review, Availability and Loss).
Of the features implemented within the TOE the report generation feature and use of external authentication servers
(e.g., RADIUS, LDAP) are not available in the evaluated configuration. The report generation feature serves to
make audit data available to users other than those allowed in the U.S. Government Intrusion Detection System
System Protection Profile (IDSSPP), Version 1.6, April 4, 2006. Similarly, the IDSSPP requires the TOE to
authenticate users, which would not be the case if that function is performed by external authentication products
such as a RADIUS server. Similarly, automatic updates must be disabled in the evaluated configuration to ensure
that the evaluated version of the product is not modified or replaced while in operation. As such, the TOE
administrators are expected to configure and use the TOE such that the following features will not be used in the
evaluated configuration: report generation, external authentication servers, and automatic updates. Note also that
this Security Target and the corresponding evaluation only serve to evaluated specific security-relevant claims. As
such, there are some non security relevant features that have been evaluated only to the extent necessary to ensure
they do not serve to allow any of the claimed requirements to be violated.
2.4.2.1 Security Audit
The ISM generates audit records related to the administration/management of the TOE and traffic logs for IDS
information. The ISM records both the audit and traffic log information into a data store, which is part of the TOE.
The data store employed is MySQL. The MYSQL DATABASE provides storage and retrieval for audit and traffic
log information. This function records attempts to access the system itself, such as successful and failed
authentication, as well as the actions taken by the user once authenticated. Auditable actions include changes to the
IDS rules and viewing the audit records of both the system access and the IDS traffic log.
2.4.2.2 Identification and Authentication
The ISM is the only TOE subsystem that provides an external user interface protected by identification and
authentication mechanism. The sensor provides an external administrative interface protected by identification and
authentication mechanism. The ISM requires users to provide unique identification (user IDs) and authentication
data (passwords) before any access to the TOE is granted
2.4.2.3 Security Management
The ISM provides a web-based (using https) management interface for all administration, including the IDS rule set,
user accounts and roles, and audit functions.
2.4.2.4 Protection of Security Functions
The TOE protects the security functions it provides through a variety of mechanisms. One of the primary protections
is that users must authenticate before any administrative operations can be performed on the system.
The Sensor implements multiple configuration, and performance MIB objects. ISM does an SNMP get on read-only
objects while SNMP get/set on read/write objects. The sensor MIB configuration between the ISM and the sensor is
implemented via SNMPv3 (56bit DES, MD5). The encrypted data (signature and profile files) transferred between
the ISM and sensor uses a proprietary SSL implementation.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
15
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The data communicated between the Update Server and the ISM is encrypted using SSL version 3.0 (using 168bit
3DES, SHA1 or 128bit RC4, MD5).3
.The McAfee Incorporated sensors are protected on the monitored network by “hiding” the fact it is there. This is
done primarily by using a non-TCP/IP network stack on the sensors, which prevents it from being accessed as a
device on the network. Also, the signature files are protected doubly as the system is configured to not accept any
management requests or input from the monitored network.
The ISM is a dedicated Windows 2000/2003 server running the ISM software. The TOE contains MySQL database
in which ISM stores the traffic logs as well as the audit of human interaction with the User/Admin interface. The
MySQL DATABASE resides on the same platform as does the ISM. All MYSQL DATABASE tables used for TSF
data are dynamically allocated so that the limit on the recording capacity of the audited information is the limit of
the physical disk partition on the platform that is not dedicated to the operating system, the MYSQL DATABASE,
and the ISM. This assures there is always adequate disk space to record current and new data that has been found to
match the current rule set. However, as a safety feature, if the audit and/or log data could not be written to a
MYSQL DATABASE table, an alarm is presented at the ISM console and the ISM then attempts to delete the oldest
audit records in order to make space to write new audit records.
Note that audit records include time stamps that need tgo be reliable. The TOE depends largely on its environment
(e.g., Windows 2000/2003) to provide time information. However, the TOE itself ensures reliability by not only
obtaining time information from the presumed reliable operating system source, but also by sharing that time
information with its associated sensors so that all parts of the TOE share the same relative time information.
MySQL database can only be accessed through the local host and is further protected by a username and passwd for
the MySQL DB which are set up during installation and stored in an encrypted form within the ISM configuration.
As a result, MySQL is accessible only to ISM within the evaluated configuration.
2.4.2.5 System Data Collection
The TOE has the ability to set rules to govern the collection of data regarding potential intrusions. While the
signatures available on the Update Server contain default rules to detect currently known vulnerabilities and
exploits, new rules can be created to detect new vulnerabilities as well as specific network traffic, allowing the
administrator complete control over the types of traffic that will be monitored.
2.4.2.6 System Data Analysis
The TOE provides tools at the ISM console for menu selection to analyze both IDS traffic log data as well as audit
information. The TOE provides two methods of reviewing traffic log information, one is a real-time viewer. The
real-time viewer is a “tab” selection at the ISM console. Audit information is reviewed from the console through the
user Activities Audit Report.
2.4.2.7 System Data Review, Availability and Loss
IDS Audit data can only be viewed by authorized users (specific roles). The ISM console provides a user interface
for menu selectable data review. The data stores of the raw collection data are limited only by the storage capacity of
the platform and table management of the MYSQL DATABASE. The TOE monitors the data store to determine
when storage is exhausted and then the TOE takes appropriate action.
3
Note that the TOE has not been subject to independent cryptographic certification and this evaluation does not
extend to ensuring conformance with any identified cryptographic standard. As such, while the security claims made
in this Security Target in the form of security requirements have been subject to evaluation, conformance with
SNMPv3, SSLv3, and their underlying cryptographic algorithms (e.g., 3DES) remain unverified.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
16
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
3 Security Environment
The IDS System PP provides the following policies, threats and assumptions about the TOE.
3.1 Threats to Security
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.1.1 TOE Threats
T.COMINT An unauthorized user may attempt to compromise the integrity of the data collected and produced
by the TOE by bypassing a security mechanism.
T.COMDIS An unauthorized user may attempt to disclose the data collected and produced by the TOE by
bypassing a security mechanism.
T.LOSSOF An unauthorized user may attempt to remove or destroy data collected and produced by the TOE.
T.NOHALT An unauthorized user may attempt to compromise the continuity of the System’s collection and
analysis functions by halting execution of the TOE.
T.PRIVIL An unauthorized user may gain access to the TOE and exploit system privileges to gain access to
TOE security functions and data
T.IMPCON An unauthorized user may inappropriately change the configuration of the TOE causing potential
intrusions to go undetected.
T.INFLUX An unauthorized user may cause malfunction of the TOE by creating an influx of data that the
TOE cannot handle.
T.FACCNT Unauthorized attempts to access TOE data or security functions may go undetected.
3.1.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.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 Unauthorized 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.2 Organization Security Policies
The following policies apply to the TOE and the intended environment of the TOE.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
17
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
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 authorized users.
P.ACCESS All data collected and produced by the TOE shall only be used for authorized 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 unauthorized accesses and disruptions of TOE data and
functions.
3.3 Secure Usage Assumptions
The following usage assumptions are made about the intended environment of the TOE.
3.3.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.3.2 Physical Assumptions
A.PROTCT The TOE hardware and software critical to security policy enforcement will be protected from
unauthorized physical modification.
A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will
prevent unauthorized physical access.
3.3.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 authorized 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 authorized users.
3.3.4 Operating System Assumption
A.TIME The Windows 2000/2003 operating system, which is a part of the environment, shall provide
reliable time stamps for the TOE.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
18
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
4 Security Objectives
This section defines the security objectives of the TOE and its supporting environment. These 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 organizational policies are addressed by the security objectives described below.
4.1 IT Security Objectives for the TOE
The following security objectives are intended to be satisfied by the TOE.
O.PROTCT The TOE must protect itself from unauthorized modifications and access to its functions
and data.
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 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 authorized 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.
O.EXPORT When any IDS component makes its data available to other IDS components, the TOE
will ensure the confidentiality of the System data.
4.2 Security Objectives for the Environment
The following security objectives for the non-IT environment of the TOE must be satisfied in order for the TOE to
fulfill its own security objectives.
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 authorized 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.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
19
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
4.2.1 Security Objectives for the IT Environment
The following security objectives for the IT environment of the TOE must be satisfied in order for the TOE to fulfill
its own security objectives.
OE.AUDPRT The IT Environment will provide the capability to protect audit information.
OE.TIME The IT environment shall provide a reliable time stamp.
OE.PROTCT The IT environment will protect itself and the TOE from external interferences or
tampering.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
20
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5 IT Security Requirements
This section provides a list of all security functional requirements for the TOE as taken from the IDSSPP. It includes
security functional requirements for the IT environment.
5.1 TOE Security Functional Requirements
The following table lists the SFRs required to satisfy the IDS System PP.
Security Functional Class Security Functional Components
Security audit (FAU)
Audit data generation (FAU_GEN.1)
Audit review (FAU_SAR.1)
Restricted audit review (FAU_SAR.2)
Selectable audit review (FAU_SAR.3)
Selective audit (FAU_SEL.1)
Guarantees of audit data availability (FAU_STG.2(a))
Prevention of audit data loss (FAU_STG.4)
Identification and authentication (FIA)
User authentication before any action (FIA_UAU.2)
User attribute definition (FIA_ATD.1)
User identification before any action (FIA_UID.2)
Security management (FMT)
Management of security functions behavior (FMT_MOF.1)
Management of TSF data (FMT_MTD.1)
Specification of Management Functions (FMT_SMF.1.1)
Security roles (FMT_SMR.1)
Protection of the TSF (FPT)
Basic internal TSF data transfer protection (FPT_ITT.1)
Non-bypassability of the TSP (FPT_RVM.1(a))
TSF domain separation (FPT_SEP.1(a))
Reliable time stamps (FPT_STM.1(a))
Intrusion Detection System (IDS)
System Data Collection (IDS_SDC.1)
Analyzer analysis (IDS_ANL.1)
Analyzer react (IDS_RCT.1)
Restricted Data Review (IDS_RDR.1)
Guarantee of System Data Availability (IDS_STG.1)
Prevention of System data loss (IDS_STG.2)
Table 1 Security Functional Requirements
5.1.1 Security audit (FAU)
5.1.1.1 Audit data generation (FAU_GEN.1)
5.1.1.1.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 (see Table 2); and
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
21
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
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
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.2 All use of the user identification mechanism User identity, location
FMT_MOF.1 All modifications in the behavior of the functions of the TSF
FMT_MTD.1 All modifications to the values of TSF data
FMT_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 address the recording of results from IDS scanning, sensing, and
analyzing tasks (i.e., System data).
5.1.1.1.2 FAU_GEN.1.2 NIAP-0410
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)
5.1.1.2.1 FAU_SAR.1.1
The TSF shall provide [authorized administrator, Security Expert, and System Administrator] with the
capability to read [all of the audit information] from the audit records.
5.1.1.2.2 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)
5.1.1.3.1 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)
5.1.1.4.1 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.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
22
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.1.1.5 Selective audit (FAU_SEL.1)
5.1.1.5.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(a) – NIAP-0422)
5.1.1.6.1 FAU_STG.2(a).1 NIAP-0422
The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
5.1.1.6.2 FAU_STG.2(a).2 NIAP-0422
The TSF shall be able to detect modifications to the audit records in the audit trail.
5.1.1.6.3 FAU_STG.2(a).3(a)
The TSF shall ensure that [all already recorded] audit records will be maintained when the following conditions
occur: [failure, attack].
5.1.1.6.4 FAU_STG.2(a).3(b)
The TSF shall ensure that [newly generated] audit records will be maintained when the following condition occurs
[storage exhaustion].
5.1.1.7 Prevention of audit data loss (FAU_STG.4)
5.1.1.7.1 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 User authentication before any action (FIA_UAU.2)
5.1.2.1.1 FIA_UAU.2.1
The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on
behalf of that user.
5.1.2.2 User attribute definition (FIA_ATD.1)
5.1.2.2.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) Authorizations; and
d) [No other security attributes].
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
23
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.1.2.3 User identification before any action (FIA_UID.2)
5.1.2.3.1 FIA_UID.2.1
The TSF shall require each user to identify itself 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 behavior (FMT_MOF.1)
5.1.3.1.1 FMT_MOF.1.1
The TSF shall restrict the ability to modify the behavior of the functions of System data collection, analysis and
reaction to authorized administrator, Security Expert, and System Administrator.
5.1.3.2 Management of TSF data (FMT_MTD.1)
5.1.3.2.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 [authorized administrator, Security Expert, and Systems Administrator].
5.1.3.3 Specification of Management Functions (FMT_SMF.1) [RI-65]4
5.1.3.3.1 FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions: [modify the behavior of the
system data collection, analysis and reactions, and the query audit data and system data].
5.1.3.4 Security roles (FMT_SMR.1)
5.1.3.4.1 FMT_SMR.1.1
The TSF shall maintain the following roles: authorized administrator, authorized System administrator, and
[Security Expert, Operator, Restricted, and No Role].
5.1.3.4.2 FMT_SMR.1.2
The TSF shall be able to associate users with roles.
5.1.4 Protection of the TOE security functions (FPT)
5.1.4.1 Basic internal TSF data transfer protection (FPT_ITT.1)
5.1.4.1.1 FPT_ITT.1.1
The TSF shall protect TSF data from [modification] when it is transmitted between separate parts of the TOE.
4
This requirement has been modified to comply with International Interpretation #65
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
24
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.1.4.2 Non-bypassability of the TSP (FPT_RVM.1(a))
5.1.4.2.1 FPT_RVM.1(a).1
The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC
is allowed to proceed.
5.1.4.3 TSF domain separation (FPT_SEP.1(a))
5.1.4.3.1 FPT_SEP.1(a).1
The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by
untrusted subjects.
5.1.4.3.2 FPT_SEP.1(a).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(a))
5.1.4.4.1 FPT_STM.1(a).1
The TSF shall be able to provide reliable time stamps for its own use.
5.1.5 IDS Component Requirements (IDS)
5.1.5.1 System Data Collection (EXP) (IDS_SDC.1)
5.1.5.1.1 IDS_SDC.1.1
The System shall be able to collect the following information from the targeted IT System resource(s):
a) [network traffic, detect known vulnerabilities].
5.1.5.1.2 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 Systems Events. (EXP)
Component Event Details
IDS_SDC.1 Network traffic Protocol, source address, destination address
IDS_SDC.1 Detect vulnerabilities Identification of known vulnerability
Table 3 System Events
5.1.5.2 Analyzer analysis (EXP) (IDS_ANL.1)
5.1.5.2.1 IDS_ANL.1.1
The System shall perform the following analysis function(s) on all IDS data received:
a) [signature]; and
b) [thresholds, statistical anomaly, protocol anomaly-based detection mechanisms]. (EXP)
5.1.5.2.2 IDS_ANL.1.2
The System shall record within each analytical result at least the following information:
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
25
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
a) Date and time of the result, type of result, identification of data source; and
b) [none]. (EXP)
5.1.5.3 Analyzer react (EXP) (IDS_RCT.1)
5.1.5.3.1 IDS_RCT.1.1
The System shall send an alarm to [the administrator] and take [log an alert, drop packet, or send TCP reset, or
send ICMP host unreachable, or log packet] when an intrusion is detected. (EXP)
5.1.5.4 Restricted Data Review (EXP) (IDS_RDR.1)
5.1.5.4.1 IDS_RDR.1.1
The System shall provide [authorized administrator, System Administrator, Security Expert, and Restricted
User] with the capability to read [captured IDS data] from the System data. (EXP)
5.1.5.4.2 IDS_RDR.1.2
The System shall provide the System data in a manner suitable for the user to interpret the information. (EXP)
5.1.5.4.3 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)
5.1.5.5.1 IDS_STG.1.1
The System shall protect the stored System data from unauthorized deletion. (EXP)
5.1.5.5.2 IDS_ STG.1.2
The System shall protect the stored System data from modification. (EXP)
5.1.5.5.3 IDS_STG.1.3
The TSF shall ensure that [all already recorded] system events will be maintained when the following conditions
occur: [failure, attack, storage exhaustion].
5.1.5.6 Prevention of System data loss (EXP) (IDS_STG.2)
5.1.5.6.1 IDS_STG.2.1
The System shall [ignore system data] and send an alarm if the storage capacity has been reached. (EXP)
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
26
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.2 Security Functional Requirement for the IT Environment
The following table identifies the security functional requirements for the IT environment.
Security Functional Class Security Functional Components
Security audit (FAU)
Guarantees of audit data availability
(FAU_STG.2(b))
Protection of the TSF (FPT)
Non-bypassability of the TSP (FPT_RVM.1(b))
TSF domain separation (FPT_SEP.1(b))
Reliable time stamps (FPT_STM.1(b))
Table 4 IT Security Functional Requirements for the IT Environment
5.2.1 Security audit (FAU)
5.2.1.1 Guarantees of audit data availability (FAU_STG.2(b) – NIAP-0422)
5.2.1.1.1 FAU_STG.2(b).1 NIAP-0422
The TSF IT Environment shall protect the stored audit records in the audit trail from unauthorized deletion.
5.2.1.1.2 FAU_STG.2(b).2 NIAP-0422
The TSF IT Environment shall be able to detect prevent modifications to the audit records in the audit trail.
5.2.1.1.3 FAU_STG.2(b).3(a)
The TSF shall ensure that [all already recorded] audit records will be maintained when the following conditions
occur: [failure, attack].
5.2.1.1.4 FAU_STG.2(b).3(b)
The TSF IT Environment shall ensure that [newly generated] audit records will be maintained when the following
condition occurs [storage exhaustion].
5.2.2 Protection of the TOE security functions (FPT)
5.2.2.1 TSF domain Separation (FPT_SEP.1(b))
5.2.2.1.1 FPT_RVM.1(b).1
The TSF IT Environment shall ensure that TSP enforcement functions are invoked and succeed before each
function within the TSC is allowed to proceed.
5.2.2.2 TSF domain Separation (FPT_SEP.1(b))
5.2.2.2.1 FPT_SEP.1(b).1
The TSF IT Environment shall maintain a security domain for its own execution that protects it from interference
and tampering by untrusted subjects.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
27
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.2.2.2.2 FPT_SEP.1(b).2
The TSF IT Environment shall enforce separation between the security domains of subjects in the TSC.
5.2.2.3 Reliable Time Stamps (FPT_STM.1(b))
5.2.2.3.1 FPT_STM.1(b).1
The TSF IT Environment shall be able to provide reliable time stamps for its own use and for the TOE’s use.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
28
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the Evaluation Assurance Level 3 components as specified in
Part 3 of the Common Criteria. No operations are applied to the assurance components.
Assurance Class Assurance Components
Configuration Management (ACM)
ACM_CAP.3 Authorization Controls
ACM_SCP.1 TOE CM Coverage
Delivery and Operation (ADO)
ADO_DEL.1 Delivery procedures
ADO_IGS.1 Installation, generation, and start-up procedures
Development (ADV)
ADV_FSP.1 Informal Function Specification
ADV_HLD.2 Security-enforcing high-level design
ADV_RCR.1 Informal correspondence demonstration
Guidance Documents (AGD)
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
Life-cycle Support (ALC) ALC_DVS.1 Identification of security measures
Tests (ATE)
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: High-level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability assessment (AVA)
ATE_MSU.1 Examination of guidance
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.1 Developer vulnerability analysis
Table 5 EAL3 Assurance Components
5.3.1 Configuration Management (ACM)
5.3.1.1 Configuration Items (ACM_CAP.3)
5.3.1.1.1 ACM_CAP.3.1D
The developer shall provide a reference for the TOE.
5.3.1.1.2 ACM_CAP.3.2D
The developer shall use the CM system.
5.3.1.1.3 ACM_CAP.3.3D
The developer shall provide CM documentation.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
29
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.1.1.4 ACM_CAP.3.1C
The reference for the TOE shall be unique to each version of the TOE.
5.3.1.1.5 ACM_CAP.3.2C
The TOE shall be labeled with its reference.
5.3.1.1.6 ACM_CAP.3.3C
The CM documentation shall include a configuration list and a CM plan.
5.3.1.1.7 International Interpretation RI #3
The configuration list shall uniquely identify all configuration items that comprise the TOE.5
5.3.1.1.8 ACM_CAP.3.4C
The configuration list shall describe the configuration items that comprise the TOE.
5.3.1.1.9 ACM_CAP.3.5C
The CM documentation shall describe the method used to uniquely identify the configuration items.
5.3.1.1.10 ACM_CAP.3.6C
The CM system shall uniquely identify all configuration items.
5.3.1.1.11 ACM_CAP.3.7C
The CM plan shall describe how the CM system is used.
5.3.1.1.12 ACM_CAP.3.8C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.
5.3.1.1.13 ACM_CAP.3.9C
The CM documentation shall provide evidence that all configuration items have been and are being effectively
maintained under the CM system.
5.3.1.1.14 ACM_CAP.3.10C
The CM system shall provide measures such that only authorized changes are made to the configuration items.
5.3.1.1.15 ACM_CAP.3.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.1.2 TOE CM Coverage (ACM_SCP.1)
5.3.1.2.1 ACM_SCP.1.1D [RI-4]6
The developer shall provide a list of configuration items for the TOE.
5
This new assurance requirement has been added to conform to International Interpretation RI #3
4
This requirement has been modified to comply with International Interpretation RI #4
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
30
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.1.2.2 ACM_SCP.1.1C [RI-4]7
The list of configuration items shall include the following: implementation representation and the evaluation
evidence required by the assurance components in the ST.
5.3.1.2.3 ACM_SCP.1.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)
5.3.2.1.1 ADO_DEL.1.1D
The developer shall document procedures for delivery of the TOE or parts of it to the user.
5.3.2.1.2 ADO_DEL.1.2D
The developer shall use the delivery procedures.
5.3.2.1.3 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.
5.3.2.1.4 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)
5.3.2.2.1 ADO_IGS.1.1D
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.
5.3.2.2.2 ADO_IGS.1.1C [RI-51]
The installation, generation and start-up documentation shall describe all the steps necessary for secure
installation, generation, and start-up of the TOE.8
5.3.2.2.3 ADO_IGS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.2.2.4 ADO_IGS.1.2E
The evaluator shall determine that the installation, generation, and start-up procedures result in a secure
configuration.
7
This requirement has been modified to comply with International Interpretation #4
8
This requirement has been modified to comply with International Interpretation #51.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
31
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.3 Development (ADV)
5.3.3.1 Informal Function Specification (ADV_FSP.1)
5.3.3.1.1 ADV_FSP.1.1D
The developer shall provide a functional specification.
5.3.3.1.2 ADV_FSP.1.1C
The functional specification shall describe the TSF and its external interfaces using an informal style.
5.3.3.1.3 ADV_FSP.1.2C
The functional specification shall be internally consistent.
5.3.3.1.4 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.
5.3.3.1.5 ADV_FSP.1.4C
The functional specification shall completely represent the TSF.
5.3.3.1.6 ADV_FSP.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.3.1.7 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 Security enforcing high-level design (ADV_HLD.2)
5.3.3.2.1 ADV_HLD.2.1D
The developer shall provide the high level design of the TSF.
5.3.3.2.2 ADV_HLD.2.1C
The presentation of the high level design shall be informal.
5.3.3.2.3 ADV_HLD.2.2C
The high level design shall be internally consistent.
5.3.3.2.4 ADV_HLD.2.3C
The high level design shall describe the structure of the TSF in terms of subsystems.
5.3.3.2.5 ADV_HLD.2.4C
The high level design shall describe the security functionality provided by each subsystem of the TSF.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
32
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.3.2.6 ADV_HLD.2.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.
5.3.3.2.7 ADV_HLD.2.6C
The high level design shall identify all interfaces to the subsystems of the TSF.
5.3.3.2.8 ADV_HLD.2.7C
The high level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.
5.3.3.2.9 ADV_HLD.2.8C
The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF,
providing details of effects, exceptions and error messages, as appropriate.
5.3.3.2.10 ADV_HLD.2.9C
The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.
5.3.3.2.11 ADV_HLD.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.3.2.12 ADV_HLD.2.2E
The evaluator shall determine that the high level design is an accurate and complete instantiation of the TOE
security requirements.
5.3.3.3 Informal correspondence demonstration (ADV_RCR.1)
5.3.3.3.1 ADV_RCR.1.1D
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are
provided.
5.3.3.3.2 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.
5.3.3.3.3 ADV_RCR.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
33
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.4 Guidance Documents (AGD)
5.3.4.1 Administrator Guidance (AGD_ADM.1)
5.3.4.1.1 AGD_ADM.1.1D
The developer shall provide administrator guidance addressed to system administrative personnel.
5.3.4.1.2 AGD_ADM.1.1C
The administrator guidance shall describe the administrative functions and interfaces available to the administrator
of the TOE.
5.3.4.1.3 AGD_ADM.1.2C
The administrator guidance shall describe how to administer the TOE in a secure manner.
5.3.4.1.4 AGD_ADM.1.3C
The administrator guidance shall contain warnings about functions and privileges that should be controlled in a
secure processing environment.
5.3.4.1.5 AGD_ADM.1.4C
The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure
operation of the TOE.
5.3.4.1.6 AGD_ADM.1.5C
The administrator guidance shall describe all security parameters under the control of the administrator, indicating
secure values as appropriate.
5.3.4.1.7 AGD_ADM.1.6C
The 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.
5.3.4.1.8 AGD_ADM.1.7C
The administrator guidance shall be consistent with all other documents supplied for evaluation.
5.3.4.1.9 AGD_ADM.1.8C
The administrator guidance shall describe all security requirements on the IT environment that are relevant to the
administrator.
5.3.4.1.10 AGD_ADM.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
34
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.4.2 User Guidance (AGD_USR.1)
5.3.4.2.1 AGD_USR.1.1D
The developer shall provide user guidance.
5.3.4.2.2 AGD_USR.1.1C
The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.
5.3.4.2.3 AGD_USR.1.2C
The user guidance shall describe the use of user-accessible security functions provided by the TOE.
5.3.4.2.4 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.
5.3.4.2.5 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 behavior found in the statement of TOE security environment.
5.3.4.2.6 AGD_USR.1.5C
The user guidance shall be consistent with all other documentation supplied for evaluation.
5.3.4.2.7 AGD_USR.1.6C
The user guidance shall describe all security requirements on the IT environment that are relevant to the user.
5.3.4.2.8 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 Identification of security measures (ALC_DVS.1)
5.3.5.1.1 ALC_DVS.1.1D
The developer shall produce development security documentation.
5.3.5.1.2 ALC_DVS.1.1C
The development security documentation shall describe all the physical, procedural, personnel, and other security
measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its
development environment.
5.3.5.1.3 ALC_DVS.1.2C
The development security documentation shall provide evidence that these security measures are followed during
the development and maintenance of the TOE.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
35
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.5.1.4 ALC_DVS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.5.1.5 ALC_DVS.1.2E
The evaluator shall confirm that the security measures are being applied.
5.3.6 Security Testing (ATE)
5.3.6.1 Analysis of coverage (ATE_COV.2)
5.3.6.1.1 ATE_COV.2.1D
The developer shall provide an analysis of the test coverage.
5.3.6.1.2 ATE_COV.2.1C
The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test
documentation and the TSF as described in the functional specification.
5.3.6.1.3 ATE_COV.2.2C
The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the
functional specification and the tests identified in the test documentation is complete.
5.3.6.2 ATE_COV.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.6.3 Testing: high-level design (ATE_DPT.1)
5.3.6.3.1 ATE_DPT.1.1D
The developer shall provide the analysis of the depth of testing.
5.3.6.3.2 ATE_DPT.1.1C
The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate
that the TSF operates in accordance with its high-level design.
5.3.6.3.3 ATE_DPT.1.2E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.6.4 Functional testing (ATE_FUN.1)
5.3.6.4.1 ATE_FUN.1.1D
The developer shall test the TSF and document the results.
5.3.6.4.2 ATE_FUN.1.2D
The developer shall provide test documentation.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
36
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.6.4.3 ATE_FUN.1.1C
The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test
results.
5.3.6.4.4 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.
5.3.6.4.5 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.
5.3.6.4.6 ATE_FUN.1.4C
The expected test results shall show the anticipated outputs from a successful execution of the tests.
5.3.6.4.7 ATE_FUN.1.5C
The test results from the developer execution of the tests shall demonstrate that each tested security function
behaved as specified.
5.3.6.4.8 ATE_FUN.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.6.5 Independent testing – sample (ATE_IND.2)
5.3.6.5.1 ATE_IND.2.1D
The developer shall provide the TOE for testing.
5.3.6.5.2 ATE_IND.2.1C
The TOE shall be suitable for testing.
5.3.6.5.3 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.
5.3.6.5.4 ATE_IND.2.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.6.5.5 ATE_IND.2.2E
The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified.
5.3.6.5.6 ATE_IND.2.3E
The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
37
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.7 Vulnerability Assessment
5.3.7.1 Examination of Guidance (AVA_MSU.1)
5.3.7.1.1 AVA_MSU.1.1D
The developer shall provide guidance documentation.
5.3.7.1.2 AVA_MSU.1.1C
The guidance documentation shall identify all possible modes of operation of the TOE (including operation
following failure or operational error), their consequences and implications for maintaining secure operation.
5.3.7.1.3 AVA_MSU.1.2C
The guidance documentation shall be complete, clear, consistent and reasonable.
5.3.7.1.4 AVA_MSU.1.3C
The guidance documentation shall list all assumptions about the intended environment.
5.3.7.1.5 AVA_MSU.1.4C
The guidance documentation shall list all requirements for external security measures (including external
procedural, physical and personnel controls).
5.3.7.1.6 AVA_MSU.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.7.1.7 AVA_MSU.1.2E
The evaluator shall repeat all configuration and installation procedures to confirm that the TOE can be configured
and used securely using only the supplied guidance documentation.
5.3.7.1.8 AVA_MSU.1.3E
The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.
5.3.7.2 Strength of TOE security function evaluation (AVA_SOF.1)
5.3.7.2.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.
5.3.7.2.2 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 of SOF-Basic.
5.3.7.2.3 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 SOF-Basic.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
38
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
5.3.7.2.4 AVA_SOF.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.7.2.5 AVA_SOF.1.2E
The evaluator shall confirm that the strength claims are correct.
5.3.7.3 Developer vulnerability analysis (AVA_VLA.1)
5.3.7.3.1 AVA_VLA.1.1D [RI-51]
The developer shall perform a vulnerability analysis.9
5.3.7.3.2 AVA_VLA.1.2D [RI-51]
The developer shall provide vulnerability analysis documentation. 10
5.3.7.3.3 AVA_VLA.1.1C [RI-51]
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.11
5.3.7.3.4 AVA_VLA.1.2C [RI-51]
The vulnerability analysis documentation shall describe the disposition of obvious vulnerabilities.12
5.3.7.3.5 AVA_VLA.1.3C [RI-51]
The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot
be exploited in the intended environment for the TOE. 13
5.3.7.3.6 AVA_VLA.1.1E
The evaluator shall confirm that the information provided meets all requirements for content and presentation of
evidence.
5.3.7.3.7 AVA_VLA.1.2E
The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure obvious
vulnerabilities have been addressed.
9
This requirement has been modified to comply with International Interpretation #51.
10
This requirement has been modified to comply with International Interpretation #51.
11
This requirement has been modified to comply with International Interpretation #51.
12
This requirement has been added to comply with International Interpretation #51.
13
This requirement has been added to comply with International Interpretation #51.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
39
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
6 TOE Summary Specification
This chapter describes the security functions and associated assurance measures.
6.1 TOE Security Functions
Each of the security function descriptions is organized by the security requirements corresponding to the security
function. Hence, each function is described in terms of how it specifically satisfies each of its associated
requirements. This serves to both describe the security functions and rationalize that the security functions are
suitable to satisfy the necessary requirements.
6.1.1 Security Audit
FAU_GEN.1 Audit Data Generation
The ISM generates audit records and stores them into the MySQL database, running on the same dedicated platform
as does the IntruShield management software. The MySQL database provides storage and retrieval for audit log
information. This function records attempts to access the system itself, such as successful and failed authentication,
as well as the actions taken by the user once authenticated. Auditable actions include changes to the IDS rules and
viewing the audit records.
Auditing is the recording of events within the system. The ISM records the audit information into a data store.
The following information about an audited event is stored in the audit log whenever that audited event is recorded
in the audit information:
a) Date and time of the event,
b) Type (i.e., category and action) of event,
c) Subject (i.e., user and domain) identity,
d) Result (success or failure) of the event, and
e) Description (where applicable access mode, target object, etc.).
The actions that can be performed at the Management ISM Console console are audited. This includes the
following:
a) Startup and shutdown of the audit function (modification of audit settings and ISM startup and
shutdown);
b) Access to the TOE and System data that includes the object IDS and the requested access (starting the
audit , attempts to read the audit log, and alert acknowledgement and deletion);
c) All modification to the audit configuration that occur during collection (modification of audit
settings);
d) All authentication attempts, including the user and location where authentication was attempted (all
login attempts as well as user logoff events);
e) All modification to the behavior of the TSF (modification of audit settings, creation of policies,
updating signatures, and ISM startup and shutdown)
f) All modifications to TSF data values (modification of audit settings, creation of policies, and updating
signatures); and,
g) Modification of user accounts, creation, deletion, and modifications (create user, delete user, assign
roles, and update roles).
FAU_SAR.1 Audit Review
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
40
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The ISM provides the ability for the user with the authorized role to view security audit data for the system. The
TSF provides the roles: authorized administrator known as Super User, Security Expert, and Systems Administrators
with the capability to read all of the audit information from the audit records. The audit logs are viewable through
the standard web-based management interface.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
41
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
FAU_SAR.2 Restricted Audit Review
No security related actions can be taken without a successful user authentication, and hence only authorized users
who have been authenticated into the Super user, Security Expert, and Systems Administrators role can view the
audit records.
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
• Success or Failure of the event
FAU_SEL.1 Selectable Audit
The ISM allows a user with the Super User role to set the types of auditable events by their type. The ISM allows
the Super User to include or exclude auditable events from the set of audited events based on the event type.
Similarly, a person assigned to the Security Expert role can include or exclude recorded events in the traffic log that
match a specific signature.
FAU_STG.2(a) Guarantees of Data Availability
The only way to access the audit records is through the ISM console. The TOE provides protection for the security
audit records primarily by preventing access to the system without successful authentication. Secondly is the use of
roles, requiring that a user have the proper role before gaining access to the audit records, even after a successful
authentication. Further there is no TSF interface to disable audit or delete or modify audit records. The audit
function starts automatically when the TOE is installed. Once recorded, audit data cannot be modified except, in the
case where the audit log reach its capacity. Under these circumstances new audit data will overwrite the oldest audit
data. This occurrence will also cause a system fault message to be posted to the system fault log. Only TSF
interfaces to the audit mechanism allow the creation of an audit log, viewing audit information, backing up and
restoring audit log information.
The TSF ensures that all already recorded audit records will be maintained when the following conditions occur:
failure or attack. It does so by protecting the existing audit trail from unauthorized access.
The TSF ensures that newly generated audit records will be maintained when the following conditions occurs
storage exhaustion. It does so by deleting the oldest audit records as necessary to make space in order to store new
audit records.
Note that the TOE does rely on the underlying operating system to protect the files that serve as a persistent
repository for the TOE audit records.
FAU_STG.4 Prevention of Audit Data Loss
The ISM records the audit log information into a data store. The data store employed is a part of the ISM.
Data Store tables used for TSF audit data are capable in storing 50,000 audit records if the audit log should be filled
up and alarm is presented at the ISM console and the oldest data stored in the audit log is overwritten with the
newest data.
6.1.2 Identification and Authentication
FIA_ATD.1 User Attribute Definition
User accounts in the TOE have the following attributes: user name (identification data), password (authentication
data), and their assigned role (authorizations data). A user can have more than one role but could not log-in with
more than one role at any specified time. Role log-in ID depends on the domain.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
42
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
FIA_UAU.2 User Authentication Before Any Action and FIA_UID.2 User Identification Before Any Action
Identification and authentication is provided by the ISM, by requiring the user to enter both a user ID and a
password. The user’s ID and password supplied by the user are verified by comparing them to user attributes
already established and stored. If the user ID and password matches a valid user attributes, the user supplying that
user ID and password is allowed to proceed with privileges determine by the role assigned to that user account. If
the user ID and password do not match a valid user attributes, the user submitting them is simply returned to the
screen (or prompt) requesting user ID and password.
6.1.3 Security Management
FMT_MOF.1 Management of Security Functions Behavior
The ISM requires user authentication before any actions can be performed (other than identification and
authentication) on the TOE, security-related or otherwise. Therefore only authorized users can access any functions
on the system. Signatures are updated by McAfee Incorporated on a protected server with a controlled space and/or
by an administrative person with the Security Expert role. Only users with “System Administrator” privileges can
implement rules on the IDS. System Administrators can also create, delete, and modify existing rules on the system.
System Administrator is the only role that can manage the security settings on the system, such as user accounts and
audit settings.
FMT_MTD.1 Management of TSF Data
See FMT_SMR.1.
FMT_SMF.1 Specification of Management Functions (RI#65)
The ISM implements interfaces that allow users to perform the following instructions:
• Modify policies, including which events are detected, whether alerts are logged for each event detected and
how the system will react when events are detected.
• Query the Audit Logs.
• Query the alerts logged for detected events.
FMT_SMR.1 Security Roles
The TSF is capable of maintaining the following roles: Authorized administrator is known as Super User role and
authorized System Administrator is known as System Administrator.
Super User All functions. Super Users must manage themselves within the
domain(s) they reside. They can read, modify, delete and push policy.
Super Users can also administer other administrators and their roles,
adding, maintaining, and deleting users and role assignments.
Restricted User A restricted user has read-only access to Alert Manager data. They can
not read configuration information.
System Administrator Manager, Sensors, Sensor_Name, and Failover Pairs node actions
(interfaces and sub-interfaces included). System Administrators do not
control Super Users, and can change own role to anything but Super
User. System Administrators can add, maintain, and delete admin
domains, read Alert data, read Audit data.
Operator Reporting only. Run and analyze reports.
Security Expert Responsible for Policy configuration and application, software/signature
updates, and alert monitoring (Alert Manager).
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
43
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
No Role The user cannot perform any actions. This is the state when a user is first
created.
6.1.4 Protection of Security Functions
FPT_ITT.1 Basic internal TSF data transfer protection
The McAfee Incorporated Sensors and ISM all protect TSF data from disclosure and modification, when it is
transmitted between separate parts of the TOE, by communicating using SSL version 3.0 connections.
The Sensor communicates with ISM through its dedicated 10/100 Ethernet, out-of-band management port using
TCP/IP. This communications uses secure channels; providing link privacy using encryption and mutual
authentication using public key authentication. The ciphers suites used for this communications are SSL (168bit
3DES, SHA1), SSL (128bit RC4, MD5). It is recommended that ISM use a separate, dedicated management subnet
to interconnect with the sensor. Communication between ISM and the Update Server is secured via SSL. There is
no communication between the sensor and Update Server.
Note that the TOE has not been subject to independent cryptographic certification and this evaluation does not
extend to ensuring conformance with any identified cryptographic standard. As such, while the security claims made
in this Security Target in the form of security requirements have been subject to evaluation, conformance with
SNMPv3, SSLv3, and their underlying cryptographic algorithms (e.g., 3DES) remain unverified.
FPT_RVM.1(a) Non-bypassability of the TSP
The TSF requires that all users successfully authenticate before any actions can 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 McAfee Incorporated sensors are protected on the monitored network by “hiding” the fact it is there. This is
done by using a non-TCP/IP network stack on the sensors, which prevents it from being accessed as a device on the
network. Also, the signature files are protected doubly as the system is configured to not accept any management
requests or input from the monitored network.
FPT_SEP.1(a) TSF Domain Separation
The TOE consists of two architecturally separate components that are: the IntruShield sensor(s) and the IntruShield
Security Management System (ISM). The IntruShield sensor is an appliance dedicated to its function. The sensor’s
only interface that is external to the TOE is a passive listener and the sensor views the packet construction as input
data only. The ISM is a software application that executes on a dedicated platform with an operating system. The
ISM has network connections to the IntruShield sensors and also the Update Server (in the IT environment) and an
encrypted connection through HTTPS to a client web browser running in a user workstation. All of these network
connections are encrypted. The IntruShield Update Server is a repository of signatures. It responds to requests from
ISMs for a signature update.
FPT_STM.1(a) Reliable Time Stamps
The TOE uses Windows Time Services provided by the Windows 2000/2003 operating system to provide time
stamps for the TSF to write time stamps for audit records, both the security records and the System Data records.
The ISM receives time stamps from the Windows 2000/2003, which is part of the environment, ensuring they are
reliable by consistently obtaining time information from the well-defined and presumed trusted and reliable source.
Each Sensor receives a time reference from the ISM. The ISM periodically passes a timestamp reference to the
sensors. Each Sensor uses this timestamp to synchronize its own independent timing mechanism synchronizing at
regular intervals per the timestamps sent form the ISM.
6.1.5 System Data Collection
IDS_SDC.1 System Data Collection
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
44
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The collection subsystem is used to detect events while monitoring the target network. Upon detection of such
events, the collection subsystem shall generate data, which is then sent to the ISM for storage in the system
database. The types of events that can be detected are shown in the table below. For each event detected the
collection subsystem records and the ISM stores date and time of the event, type of event, subject identity, and the
outcome (success or failure) of the event along with additional details for each event type.
The Update Server stores default signatures to detect currently known vulnerabilities and exploits of interest in
network traffic. The ISM allows the Security Expert to establish new rules to detect new vulnerabilities as well as
specific network traffic, allowing the Security Expert complete control over the types of traffic that will be
monitored and to set rules to govern the collection of data regarding potential intrusions. The following table
identifies the events audited and the information recorded in the audit record.
Component Event Details
IDS_SDC.1 Network traffic Protocol, source address, destination address
IDS_SDC.1 Detect vulnerabilities Identification of known vulnerability
6.1.6 System Data Analysis
IDS_ANL.1 Analyzer Analysis
To analyze the data collected by the McAfee Incorporated Sensor, the ISM uses signatures. A signature is the
protection profile term for a rule as defined by the TOE. They are patterns of traffic that can be used to detect attacks
or exploits. Since many attacks or exploits require several network connections to work, the ISM also provides the
ability to detect these more complex patterns through sensors placed at strategic locations throughout the network.
The TOE comes with default signatures for known exploits, and the administrator can add new signatures at any
time. New signatures are obtained from the Update Server as they are created and are downloaded. New signatures
also can be created by an administrator authenticated in the Security Expert role manually. This gives the
administrator control over the detection of traffic, allowing customization for the intended environment.
When a pattern of traffic has been matched to a signature, the specific event is recorded in the traffic log where it
can be viewed and analyzed by users authenticated in the Security Expert role. The events are logged with the
following information: the event type and signature match, the time of the event, the data source and a copy of the
packets used to identify the pattern.
A pattern of traffic that meets a signature is called an “alert.” The graphical interface to view alerts and alert analysis
is the “Alert Manager.” The Alert Manager is used for the analysis of the alerts detected by IntruShield sensors.
Alert details include transmission information such as source and destination IP addresses in the packet, as well as
security analysis information (performed by the sensor) such as attack severity and type. Alerts are backed up to the
database and archived in order of occurrence.
For detailed analysis of alert information, the Alert Manager provides a “Drill Down” graphical administrative
interface. Drill Down provides the administrator with the capability to review statistical, signature, threshold, and
anomaly-based functions by port scan. Alert information is organized by category of alert as follows: _
• Severity: by severity,
• Attack: by attack name,
• Source IP: by source IP addresses,
• Destination IP: by destination (target) IP addresses,
• Interface: by the sensor interface where alerts were captured,
• Domain: by admin domain where alerts were captured,
• Type: by attack type,
• Sensor: by the sensors where alerts were captured, and
• Application Protocol: by the application protocol of the detected attack.
For each category of alert, the administrator may continue to drill down to get more detailed information. Drill
Down allows the administrator to review alert category information by time, or details.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
45
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The “Time View” provides a view of the alert count during a specific time period. Time periods are expressed in
date/time range. Alert Manager provides an interface to view alerts in real time, as they occur, as well as a historical
view. The historical view sets the filter to retrieve information for both acknowledged and unacknowledged alerts
archived in the database during a specified time. The historical view does not refresh with new alerts as they occur,
thus you can focus on analyzing all alerts within the time frame you requested.
The Alert Manager provides a view to analyze an individual alert called the “Alert Details.” The Alert Details
interface lists all of the alerts for the selected time span in order of occurrence, with most recent being listed first.
Alert details are presented in multiple named columns, known as attributes. The attributes represent packet fields
such as source and destination IP, as well as sensor analysis fields such as attack severity and type.
The attributes in the Alert Details are as follows:
• Acknowledged: for Historical View, indicates state of recognition. If unchecked by an administrator, then
the alert has not been manually acknowledged,
• Deleted: for Historical View, indicates if the alert has been selected for deletion during current analysis
session,
• Time: time when the alert occurred. Alerts are listed from most (top of the list) to least (bottom) recent,
• Severity: system impact severity posed by the attack,
• Attack: specific name of the attack that triggered the alert,
• Source IP: IP address where the attack originated,
• Source IP Port: port on source machine where attack originated,
• Destination IP: IP address the attack was targeting,
• Destination IP Port: port on target machine where attack was destined,
• Domain: admin domain in which the attack was detected,
• Sensor: ID (name) of the sensor from where the alert was generated,
• Interface: sensor interface where the attack was detected, and
• Type: the type of attack. The choices are:
o Exploit: an attack matching a known exploit attack signature.
o Host Sweep: a reconnaissance attack attempting to see which IP addresses have live systems
attached to them.
o Port Scan: a reconnaissance attack attempting to see what services a particular system is offering.
o Simple Threshold: denial of service attack against a set threshold limits.
o Statistical: denial of service attack based on a learning statistical traffic profile.
• Throttle: a number of the same Signature attack occurring that exceeded an established limit suppression
threshold in a designated period.
IDS_RCT.1 Analyzer React
When signature matches are found, they can either be logged for later use or set to trigger an alarm. Current log
entries can be viewed in real time by setting the “Real-time Log Viewer” values at the ISM console. Real-time
viewing displays a limited number of entries as logged to the database. The number of entries to view can be
selected as well as the refresh rate to refresh the console screen.
The ISM provides an interface to establish IDS security policies. A security policy, or IDS policy, is a set of rules
that governs what traffic is permitted across your network, and how to respond to misuse of the network. An
IntruShield policy is a set of rules/instructions defining the malicious activity that can be detected and the response.
Creating a policy enables an administrator in the Security Expert role to define an environment to protect by the
different operating systems (OSs), applications, and protocols in the network. These environment parameters, or
rules, relate to all of the well-known attacks defended against by IntruShield.
All activities for which the underlying traffic content can violate an IntruShield policy may not be malicious, but
may be explicitly forbidden by the usage policies of the network as defined by a security policy. These can include
“protocol violations” wherein packets do not conform to network protocol standards. (For example, they are
incorrectly structured, have an invalid combination of flags set, or contain incorrect values.) Examples might include
TCP packets with their SYN and RST flags enabled, or an IP packet whose specified length doesn’t match its actual
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
46
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
length. A protocol violation can be an indication of a possible attack, but can also be triggered by malfunctioning
software or hardware. Policy violations trigger alerts that are displayed on the ISM console.
Alerts are asynchronous notifications sent when a system event or attack triggers the IDS. When a transmission
violating a security policy is detected by a sensor, the sensor compiles information about the offending transmission
and sends the information to the ISM in the form of an alert. An alert contains a variety of information on the
incident that triggered it—such as the type of attack, its source and destination IP addresses, its source and
destination ports, as well as security analysis information (performed by the sensor) such as attack severity and type.
In addition to the alert that is generated, the IDS policy may be configured to ensure that the sensor responds by
doing one or more of the following:
• Dropping the packet,
• Sending a TCP reset,
• Generating alert,
• Logging packets, and
• Sending an ICMP Host Unreachable in response to attacks detected.
These responses are configurable by the end user.
6.1.7 System Data Review, Availability and Loss
IDS_RDR.1 Restricted Data Review
The ISM provides an interface where only successfully authenticated users can access the TOE, and then those users
that have access to the Alert Manager (i.e., all except Operator) can view the traffic log data collected and analyzed
by sensor as indicated in the table for FMT_SMR.1 above. The data gathered by a sensor is transferred to the ISM
and then saved in a MYSQL DATABASE table. The ISM provides a Graphical User Interface (GUI) menu driven
tool to interpret and review log data based on specific search criteria.
For a user to be authenticated they must use a password with a minimum password length of any eight characters on
a keyboard. Account lockout is provided after an installed limit of failed password attempts has exceeded. The
default limit is three.
IDS_STG.1 Guarantee of System Data Availability
The ISM protects the gathered system traffic logs from unauthorized modification or deletion by presenting only the
web-based interface to all users. No users are allowed to edit the logs; they are marked for read-only access,
preventing user modification.
Further there is no TSF interface to disable audit or delete or modify audit records. The ability to back up and
restore these audit logs exists. The audit function starts automatically when the TOE is installed. Once recorded,
audit data cannot be modified or deleted except by the MYSQL DATABASE managing the audit data. The only
TSF interfaces to the audit mechanism allow the creation of an audit log, viewing audit information, and copy the
audit information to another media for back-up and restore purposes. The TSF shall ensure that all already recorded
system events will be maintained when the following conditions occur: failure, attack, storage exhaustion.
Audit data storage exhaustion can occur if the disk space allocated to the MYSQL DATABASE segment exceeds
the storage allowed. If this unlikely event occurs, an alarm is set and an administrator must backup the audit and
alert tables. This alarm is triggered when the log files reach 50%, 70% and 90% of their storage capacity limit.
IDS_STG.2 Prevention of System Data Loss
The ISM records the system data into a data store. The data store employed is running on the same dedicated
platform as does the ISM. The MYSQL DATABASE provides storage and retrieval for the system data.
All MYSQL DATABASE tables used for TSF data are dynamically allocated so that the limit on the recording
capacity of the information is the limit of the physical disk partition on the platform dedicated to the MYSQL
DATABASE data store. This assures there is always adequate disk space to record current and new data that has
been found to match the current rule set.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
47
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
When the storage capacity reaches 50%, 70% and 90% of their storage capacity limit, an alarm is presented at the
ISM console. The administrator must then take action by using a graphical interface to copy the system data to
another storage media.
If the MYSQL DATABASE tables on a dedicated disk partition that stores the system data ever becomes exhausted,
new system data will be ignored.
6.2 TOE Security Assurance Measures
The following assurance measures are applied to satisfy the Common Criteria EAL3 assurance requirements:
• Process Assurance;
• Delivery and Guidance;
• Design Documentation;
• Life-cycle Support
• Tests; and
• Vulnerability Assessment.
6.2.1 Process Assurance
6.2.1.1 Configuration Management
The configuration management measures applied by McAfee Incorporated ensures that all configuration items are
uniquely identified, and that documented procedures are used to control and track changes that are made to the TOE.
McAfee Incorporated ensures changes to the implementation representation are controlled and that TOE associated
configuration item modifications are properly controlled. McAfee Incorporated performs configuration
management on the TOE implementation representation, design, tests, user and administrator guidance, and the CM
documentation. These activities are documented in:
• IntruShield IPS System Configuration Management
The Configuration Management assurance measure satisfies the ACM_CAP.3, and ACM_SCP.1 assurance
requirements.
6.2.2 Delivery and Guidance
McAfee Incorporated provides delivery documentation that explains how the TOE is delivered and procedures to
identify the TOE, allow detection of unauthorized modifications of the TOE and installation and generation
instructions at start-up. McAfee Incorporated delivery procedures describe the steps to be used for the secure
installation, generation, and start-up of the TOE. These procedures are documented in:
• McAfee IntruShield Order, Delivery, and Billing
• Manufacturing Flow Process, Test Plan and Delivery
McAfee Incorporated provides administrator guidance in the installation and initialization procedures. The
installation and generation procedures, included in the administrator guidance, describe the steps necessary to install
McAfee Incorporated IDS products in accordance with the evaluated configuration.
The administrator guidance is documented in:
IntruShield IPS System Sensor Installation and Configuration Guide, Version 3.1
IntruShield Quick Start Guide, Version 3.1
IntruShield IPS System Manager Installation Guide, Version 3.1,
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
48
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
IntruShield IPS System Manager Configuration Guide, Version 3.1
IntruShield IPS System Getting Started Guide, Version 3.1
IntruShield IPS Release Notes, Version 3.1, 03/08/07
IntruShield Sensor Configuration Guide, revision 3.0
IntruShield Sensor 4010 Product Guide, revision 4.0
IntruShield Sensor 4000 Product Guide, revision 4.0
IntruShield Sensor 3000 Product Guide, revision 4.0
IntruShield Sensor 2700 Product Guide, revision 4.0
IntruShield Sensor 2600 Product Guide, revision 4.0
IntruShield Sensor 1200 Product Guide, revision 4.0
IntruShield Sensor 1400 Product Guide, revision 4.0
Since there are no users who are not a member of an administrative role, the Delivery and Guidance assurance
measure satisfies the following Assurance requirements:
• ADO_DEL.1,
• ADO_IGS.1,
• AGD_ADM.1, and
• AGD_USR.1.
6.2.3 Development
The Design Documentation provided for IntruShield is provided in three documents:
• IntruShield Functional Specification,
• IntruShield High-level Design, and
• IntruShield Informal Correspondence
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 Design Documentation security assurance measure satisfies the following
security assurance requirement:
• ADV_FSP.1,
• ADV_HLD.2, and
• ADV_RCR.1.
6.2.4 Life-Cycle Support
The Life-cycle support documentation provided for IntruShield is provided in the document
• Assurance Lifecycle Support
The life-cycle document describes the physical, procedural, personnel, and other development security measures that
are used in the development environment to protect the TOE. It includes the physical security of the development
location and any procedures used to select development staff.
The Life-cycle Support documented procedures satisfies the ALC_DVS.1 security assurance requirement.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
49
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
6.2.5 Tests
The Test Documentations are found in the following documents
• IntruShield IPS System Test (ATE)
• ATE Test Results
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 assurance requirements:
• ATE_COV.2,
• ATE_DPT.1,
• ATE_FUN, and
• ATE_IND.2.
6.2.6 Vulnerability Assessment
The claim made in this Security Target document is SOF-Basic. This is the minimum requirement for vulnerability
specified in IDSSPP. The only probabilistic or permutation function on which the strength of the authentication
mechanisms depends is the password entered for login to the ISM console. This “Strength of Function” has a
probability smaller than one in one million (.000001) that authentication data can be guessed. The minimum
password length is 8 characters that can consist of alpha-numeric or symbol that is upper and lower-case sensitive,
therefore, satisfying this requirement.
McAfee Incorporated 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 in this ST; a
separate SOF analysis is not applicable. The vulnerability analysis is documented in:
• IntruShield Vulnerability Assessment
The Vulnerability Assessment assurance measure satisfies the following assurance requirements:
• AVA-MSU.1,
• AVA_SOF.1, and
• AVA_VLA.1.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
50
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
7 Protection Profile Claims
The TOE conforms to the U.S. Government Intrusion Detection System System Protection Profile (IDSSPP),
Version 1.6, April 4, 2006.
This Security Target includes all applicable assumptions, organizational policies, security objectives, and threats
statements described in the PP, verbatim. The following threats and security objectives were excluded due to the
TOE not having scanner component:
• T.SCNCFG
• T.SCNMLC
• T.SCNVUL
• O.IDSCAN
Security Functional Requirements
This Security Target includes all of the Security Functional Requirements from the PP, except those exclusively
related to authenticating external IT products. Specifically:
• FPT_ITA.1 – this requirement is intended to specify how audit and System data are made available to
external (trusted) IT products that would provide audit and data services. Since the TOE provides these
functions as internally, no external IT products are necessary, and therefore this requirement is not
applicable.
• FPT_ITC.1 – this requirement is intended to specify how TSF data is protected while transmitted to
external (trusted) IT products. Since the TOE provides all functionality for the IDS in a self-contained
manner, no data is transferred to external products, and therefore this requirement is not applicable.
• FPT_ITI.1 - this requirement is intended to specify how modifications to TSF data can be detected when it
is transmitted to external (trusted) IT products. This includes both integrity checks and detection of
modification during transmission. Since the TOE does not transmit data to external products, this
requirement is not applicable.
These three requirements apply to the transfer of information between trusted products. There is no such transfer
with IntruShield or any other IDS systems. The three requirements were replaced with FPT_ITT.1 of the transfer of
information between the TOE components.
Refinement
• FMT_MOF.1.1 – This requirement was refined to include the required administrative roles that have
permissions to modify the behavior of the functions of System data collection, analysis and reaction. The
permission is limited to authorized administrator known as Super User, Security Expert, and System
Administrator.
Iterations
• FAU_STG.2(a).3 - This requirement is intended to satisfy the need for the TSF to ensure that all already
recorded audit records will be maintained when failure, attack occurs and that newly generated audit
records will be maintained when the storage exhaustion occurs.
Exclusions:
• FIA_AFL.1.1 and FIA_AFL.1.12 these security requirements were intended to detect attempts by untrusted
external IT products to access the TOE. The TOE have account lockout specifications for these external
IT product connections to the TOE. A required specification, for example, would require an authorized
system administrator to specifically unlock a locked account. The TOE does not allow access to itself from
external IT products; only authorized users may access the TOE. Therefore, this requirement is not
applicable.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
51
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
Inclusion of Operating System Assumption and an IT Environment Security Objective and Errata Section 1
• FMT_STM.1(b) – the ISM does not provide timestamps of its own. It relies on the Windows 2000/2003
operating system, which is part of the environment, to provide it with an accurate time stamp. Having
received this accurate time stamp from the environment, the ISM provides a time stamp to the Sensor. The
Sensor uses this time stamp to set its own internal real time clock. A.TIME assumption and OE.TIME an
IT environment security objective addresses time stamp. The IT Environment will provide reliable
timestamps to the TOE. This additional security objective should be mapped to the P.ACCACT and
P.DETECT policies which require audit and system data to be generated and include a timestamp.
• FPT_RVM.1(b), FPT_SEP.1(b) The requirements address the ISM dependency on Windows 2000/2003
system to help provide security against tampering and external interference and provide a secure domain
for ISM execution. The objective OE.PROTCT was instantiated to represent the corresponding objective
for the IT environment.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
52
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
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 and organizational security policies are completely covered by
security objectives. In addition, each objective counters or addresses at least one assumption or organizational
security policy.
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,IDSENS
O.IDANLZ
O,RESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
O.EXPORT
O.INSTAL
O.PHYCAL
O.CREDEN
O.PERSON
O.INTROP
OE.AUDPRT
OE.TIME
OE.PROTCT
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.NOTRUST X X
A.TIME X
T.COMINT X X X X X
T.COMDIS X X X X X
T.LOSSOF X X X X
T.NOHALT X X X X
T.PRIVIL X X X
T.IMPCON X X X X
T.INFLUX X
T.FACCNT X
T.SCNCFG
T.SCNMLC
T.SCNVUL
T.FALACT X
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
53
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
OE.PROTCT
OE.AUDPRT
O.OFLOWS
O.PHYCAL
O.CREDEN
O.EADMIN
O.EXPORT
O.PROTCT
O.PERSON
O,RESPON
O.IDAUTH
O.ACCESS
O.IDANLZ
O.INTEGR
O.AUDITS
O.INTROP
O.INSTAL
O,IDSENS
OE.TIME
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 X
P.ACCACT X 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 unauthorized
physical modification.
The O.PHYCAL provides for the physical protection of the TOE hardware and software
8.1.1.5 A.LOCATE
The processing resources of the TOE will be located within controlled access facilities, which will prevent
unauthorized 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.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
54
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The O.PERSON objective ensures all authorized administrators are qualified and trained to manage the TOE.
8.1.1.7 A.NOEVIL
The authorized administrators are not careless, willfully negligent, or hostile, and will follow and abide by the
instructions provided by the TOE documentation.
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 authorized 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 authorized users.
The O.PHYCAL objective provides for physical protection of the TOE to protect against unauthorized access. The
O.CREDEN objective supports this assumption by requiring protection of all authentication data.
8.1.1.9 A.TIME
The Windows Operating System, which is part of the environment, will provide a reliable time stamp.
The OE.TIME IT environment security objective provides a reliable timestamp for the TOE to use for accurately
tracking audit records.
8.1.1.10 T.COMINT
An unauthorized 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 authorized 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.PROTCT objective ensures that the IT environment and TOE is protected
from external interferences or tampering.
8.1.1.11 T.COMDIS
An unauthorized 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 authorized users to access TOE data. The
O.EXPORT objective ensures that confidentiality of TOE data will be maintained. The O.PROTCT objective
addresses this threat by providing TOE self-protection. The OE.PROTCT objective ensures that the IT environment
and TOE is protected from external interferences or tampering.
8.1.1.12 T.LOSSOF
An unauthorized 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 authorized 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.
8.1.1.13 T.PRIVIL
An unauthorized user may gain access to the TOE and exploit system privileges to gain access to TOE security
functions and data.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
55
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
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 authorized users to access TOE functions. The
O.PROTCT objective addresses this threat by providing TOE self-protection.
8.1.1.14 T.IMPCON
An unauthorized user may inappropriately change the configuration of the TOE causing potential intrusions to go
undetected.
The O.INSTAL objective states the authorized 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 authorized users to access TOE functions.
8.1.1.15 T.INFLUX
An unauthorized 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
Unauthorized 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. O.TIME provides reliable timestamps for audit events.
8.1.1.17 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.18 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.19 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.20 T.MISUSE
Unauthorized 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.21 T.INADVE
Inadvertent activity and access may occur on an IT System the TOE monitors.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
56
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
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.22 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.23 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 and O.IDSENS objectives address this policy by requiring collection of audit, Sensor, and data.
O.TIME provides reliable timestamps for audit events.
8.1.1.24 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.25 P.MANAGE
The TOE shall only be managed by authorized 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 authorized 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.26 P.ACCESS
All data collected and produced by the TOE shall only be used for authorized 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 authorized users to access TOE functions. The
O.PROTCT objective addresses this policy by providing TOE self-protection. The OE.AUDPRT objective also
serves to limit who may access TOE data.
8.1.1.27 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. The O.TIME objective supports this objective by providing an accurate time stamp.
8.1.1.28 P.INTGTY
Data collected and produced by the TOE shall be protected from modification.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
57
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
The O.INTEGR objective ensures the protection of data from modification.
8.1.1.29 P. PROTCT
The TOE shall be protected from unauthorized 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 unauthorized physical modifications.
8.2 Security Requirements Rationale
This section provides evidence supporting the internal consistency and 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 TOE in meeting security needs.
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
ORESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
O.EXPORT
OE.AUDPRT
OE.TIME
OE.PROTCT
X
FAU_GEN.1
X
FAU_SAR 1
X X
FAU_SAR.2
X
FAU_SAR.3
X X
FAU_SEL.1
FAU_STG.2(a) X X X X X
X X
FAU_STG.4
X X
FIA_UAU.2
X
FIA_ATD.1
X X
FIA_UID.2
X X X
FMT_MOF.1
X X X X
FMT_MTD.1
X X X
FMT_SMF.1
X
FMT_SMR.1
X
FPT_ITT.1
FPT_RVM.1(a) X X X X X
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
58
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
OE.PROTCT
OE.AUDPRT
O.OFLOWS
O.EADMIN
O.EXPORT
O.PROTCT
O.IDAUTH
O.ACCESS
O.IDANLZ
O.IDSCAN
O.INTEGR
O.AUDITS
ORESPON
O.IDSENS
OE.TIME
X X X X X
FPT_SEP.1(a)
X
FPT_STM.1(a)
X X
IDS_SDC.1
X
IDS_ANL.1
X
IDS_RCT.1
X X X
IDS_RDR.1
X X X X X
IDS_STG.1
X
IDS_STG.2
FAU_STG.2(b) X
FPT_RVM.1(b) X
X
FPT_SEP.1(b)
X
FPT_STM.1(b)
Table 7 Objective to Requirement Correspondence
8.2.1.1 O.PROTCT
The TOE must protect itself from unauthorized 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(a)]. The System is required to protect the System
data from any modification and unauthorized 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
the behavior of functions of the TOE to authorized users of the TOE [FMT_MOF.1]. Only authorized
administrators of the System may query and add System and audit data, and authorized 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
successful before each function may proceed [FPT_RVM.1(a)]. The TSF must be protected from interference that
would prevent it from performing its functions [FPT_SEP.1(a)].
8.2.1.2 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.3 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].
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
59
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
8.2.1.4 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]. The responses can
be configured for each administrative domain [FMT_SMF.1]
8.2.1.5 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 authorized 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.1(a)]. The TSF must be protected from interference that would prevent it from performing
its functions [FPT_SEP.1(a)]. The TSF is capable of performing security management functions through the
administrator interface [FMT_SMF.1].
8.2.1.6 O.ACCESS
The TOE must allow authorized 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(a)]. The System is required to protect the System
data from any modification and unauthorized deletion [IDS_STG.1]. Users authorized to access the TOE are
defined using an identification and authentication process [FIA_UID.2, FIA_UAU.2]. The TOE is required to
provide the ability to restrict managing the behavior of functions of the TOE to authorized users of the TOE
[FMT_MOF.1]. The TFS is required to perform security management functions such as create log-ins and assign
roles to user log-in IDs [FMT_SMF.1]. Only authorized administrators of the System may query and add System
and audit data, and authorized administrators of the TOE may query and modify all other TOE data [FMT_MTD.1].
8.2.1.7 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 unauthorized deletion [FAU_STG.2(a)]. The System is
required to protect the System data from any modification and unauthorized 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 authorized to
access the TOE are defined using an identification and authentication process [FIA_UID.2, FIA_UAU.2]. The TOE
is required to provide the ability to restrict managing the behavior of functions of the TOE to authorized users of the
TOE [FMT_MOF.1]. Only authorized administrators of the TOE may query and add System and audit data, and
authorized 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.1(a)]. The TSF
must be protected from interference that would prevent it from performing its functions [FPT_SEP.1(a)].
8.2.1.8 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(a)]. 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
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
60
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
modification and unauthorized 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.9 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 that its 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.1(a)]. The TSF must be protected form
interference that would prevent it from performing its functions [FPT_SEP.1(a)]. Time stamps associated with an
audit record must be reliable [FPT_STM.1(a)].
8.2.1.10 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(a)]. The System is required to protect the System
data from any modification and unauthorized deletion [IDS_STG.1]. Only authorized administrators of the System
may query or add audit and System data [FMT_MTD.1]. The TOE must ensure that all functions to protect the data
are not bypassed [FPT_RVM.1(a)]. The TSF must be protected form interference that would prevent it from
performing its functions [FPT_SEP.1(a)].
8.2.1.11 O.EXPORT
When any IDS component makes its data available to other IDS components, the TOE will ensure the confidentiality
of the System data.
The TSF shall protect TSF data from modification when it is transmitted between separate parts of the TOE
[FPT_ITT.1.1]. The encryption and authentication applied to system data while it is in transit between any two IDS
components.
8.2.1.12 OE.AUDPRT
The IT Environment will provide the capability to protect audit information.
This IT security environment objective assures that the files used for persistent storage underlying the TOE are
protected so that the supported audit data is not subject o inappropriate access [FAU_STG.2(b)].
8.2.1.13 OE.TIME
The IT security environment shall provide an accurate time stamp.
This IT security environment objective assures that an accurate time stamp is used by the TOE. Accurate record
information based on time and date can be produced, queried, and tracked [FMT_STM.1(b)].
8.2.1.14 OE.PROTCT
The IT security environment shall protect itself and the TOE from external interference or tampering.
This IT security environment objective assures that the IT environment will protect itself and the TOE from external
interferences or tampering [FPT_RVM.1(b) and FPT_SEP.1(b)].
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
61
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
8.2.2 Strength of Function (SOF) Rationale
The rationale for TOE Strength of Function described in this section satisfies the SOF-Basic claim. The reasoning
for SOF-Basic claim is that the TOE strength of function provides adequate protection against casual breach of TOE
security by attackers possessing a low attack potential. The SOF-basic strength level is also sufficient to meet the
objectives of the TOE given the security environment described in the ST.
This Security Target includes a probabilistic or permutation analysis of the password mechanism required by
AVA_SOF.1. This is provided below along with specific functional security requirements:
FIA_UAU.2.1 (Identification and Authentication) was satisfied in compliance with Protection Profile
functional security requirement for SOF-Basic claim. The only probabilistic or permutational function on
which the strength of the authentication mechanisms depends is the password entered for login into the ISM
console.
The ISM console valid range or values for password is at least 8 characters, is case sensitive, and can consist
of any alpha-numeric character or symbol.
The CEM general evaluation guidance (page 367) for SOF indicated that patterns of human usage must be
taken into consideration. Assuming that in a worst case scenario a user chooses a number comprising only
eight characters, the number of password permutations demonstrated is below:
52 alpha (upper 26 and lower 26 = 52)
10 digits ( 0 to 9)
32 symbols (~, `, !, @, #, $, %, ^, &, *, (, ), _, +, -, =, [, ], {, }, \, |, ;, : ", ', ,, ., <, >, ?, /)
94 possible values
6.10x1015
or 94^8 = (94*94*94*94*94**94*94*94) = 6,095,689,385,410,816
Presume that a manual password input or entry is 6 seconds. The best number of attempts for an attacker is
(60/6 = 10 possible password entries every minute, or 600 password entries every hour). Typically, an
attacker would need to input (6,095,689,385,410,816/ 2 =) 3,047,844,692,705,408 passwords, over
(3,047,844,692,705,408 / 600) 5,079,741,154,509 hours, prior to entering the correct password. The average
triumphant attack would, as a result, occur in slightly less than:
5,079,741,154,509 / 24 /365) = 579,879,127 years
According to the Common Evaluation Methodology Table B3 (page 365), the elapse time is not practical.
The result presents a HIGH strength of function, which surpasses SOF-Basic.
8.3 Security Assurance Requirements Rationale
This ST contains the assurance requirements from the CC EAL3 assurance package and is based on good
commercial development practices. This ST has been developed for a generalized environment with a medium level
of risk to the assets. The security environment assumes physical protection and the TOE itself offers only a very
limited interface and 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 3 provides an appropriate
level of assurance in the security functions offered by the TOE.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
62
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
8.4 Requirement Dependency Rationale
The ST satisfies all the requirement dependencies of the Common Criteria, except as noted below. Table 8
Requirement Dependency Rationale lists each requirement from Section 5.1 with a dependency and indicates which
requirement was included to satisfy the dependency, if any. 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(a) & (b) FAU_GEN.1 YES
FAU_STG.4 FAU_STG.2(a) YES
FIA_UAU.2 FIA_UID.2 YES
FMT_MOF.1 FMT_SMF.1, FMT_SMR.1 YES
FMT_MTD.1 FMT_SMF.1, FMT_SMR.1 YES
FMT_SMR.1 FIA_UID.2 YES
Table 8 Requirement Dependency Rationales
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
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 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. Working together, this set of security functions 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 c 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.
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
63
Security Target McAfee, Incorporated Version 1.21, August 11, 2008
© 2009 McAfee Incorporated McAfee Incorporated
Rights Reserved.
64
SECURITY
AUDIT
IDENTITY
&
AUTHENTICATION
SECURITY
MANAGEMENT
PROTECTION
OF
SECURITY
FUNCTIONS
SYSTEM
DATA
COLLECTION
SYSTEM
DATA
ANALYSIS
SYSTEM
DATA
REVIEW,
AVAILABILITY
&
LOSS
FAU_GEN.1 X
FAU_SAR 1 X
FAU_SAR.2 X
FAU_SAR.3 X
FAU_SEL.1 X
FAU_STG.2(a) X
FAU_STG.4 X
FIA_UAU.2 X
FIA_ATD.1 X
FIA_UID.2 X
FMT_MOF.1 X
FMT_MTD.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_ITT.1 X
FPT_RVM.1(a) X
FPT_SEP.1(a) X
FPT_STM.1(a) X
IDS_SDC.1 X
IDS_ANL.1 X
IDS_RCT.1 X
IDS_RDR.1 X
IDS_STG.1 X
IDS_STG.2 X
Table 9 Security Functions vs. Requirements Mapping
8.7 PP Claims Rationale
See section 7, Protection Profile Claims.