Sourcefire 3D System
Security Target
(Sourcefire Defense Center: models DC500, DC1000, and DC3000; and
Sourcefire 3D Sensor licensed for IPS: models 3D500, 3D1000, 3D2000, 3D2100,
3D2500, 3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800)
Version 4.8.2.1 (SEU 259)
Version 1.15
June 10, 2010
Prepared For
Sourcefire, Incorporated
9770 Patuxent Woods Drive
Columbia, MD 21046
Prepared By
7925 Jones Branch DriveSuite 5200 McLean, VA 22102-3321703 848-0883Fax 703 848-0960
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
2 of 105
Table of Contents
Section Page
1 SECURITY TARGET INTRODUCTION.............................................................................................7
1.1 SECURITY TARGET REFERENCE ...................................................................................................7
1.1.1 References............................................................................................................................7
1.2 TOE REFERENCE ........................................................................................................................8
1.3 TOE OVERVIEW ..........................................................................................................................8
1.3.1 TOE Type..............................................................................................................................8
1.3.2 Hardware/Firmware/Software Required by the TOE ............................................................8
1.4 TOE DESCRIPTION ......................................................................................................................9
1.4.1 Acronyms ..............................................................................................................................9
1.4.2 Terminology.........................................................................................................................10
1.4.3 Product Description.............................................................................................................14
1.4.3.1 Sourcefire 3D Sensor licensed for IPS (3D Sensor with IPS) ..................................................14
1.4.3.2 Sourcefire Defense Center (Defense Center) ..........................................................................17
1.4.4 Data.....................................................................................................................................19
1.4.5 Users...................................................................................................................................20
1.4.6 Product Guidance ...............................................................................................................20
1.4.7 Physical Scope of the TOE .................................................................................................21
1.4.7.1 Included in the TOE: ................................................................................................................24
1.4.7.2 Excluded from the TOE:...........................................................................................................24
1.4.8 Logical Scope of the TOE ...................................................................................................26
1.4.8.1 Security Audit...........................................................................................................................26
1.4.8.2 Identification and Authentication ..............................................................................................26
1.4.8.3 Security Management ..............................................................................................................27
1.4.8.4 Protection of Security Functions ..............................................................................................27
1.4.8.5 TOE Access Functions.............................................................................................................27
1.4.8.6 System Data Collection............................................................................................................27
1.4.8.7 System Data Analysis ..............................................................................................................28
1.4.8.8 System Data Review, Availability and Loss .............................................................................28
1.4.8.9 Excluded Functionality .............................................................................................................28
2 CONFORMANCE CLAIMS..............................................................................................................30
2.1 COMMON CRITERIA CONFORMANCE............................................................................................30
2.2 PROTECTION PROFILE CLAIM .....................................................................................................30
2.3 PACKAGE CLAIM ........................................................................................................................33
3 SECURITY PROBLEM DEFINITION...............................................................................................34
3.1 THREATS...................................................................................................................................34
3.2 ORGANIZATIONAL SECURITY POLICIES (OSPS) ...........................................................................35
3.3 ASSUMPTIONS ...........................................................................................................................35
4 SECURITY OBJECTIVES ...............................................................................................................37
4.1.1 Security Objectives for the TOE..........................................................................................37
4.1.2 Security Objectives for the Operational Environment .........................................................38
4.2 SECURITY OBJECTIVES RATIONALE.............................................................................................39
4.2.1 Rationale for the IT Security Objectives..............................................................................39
4.2.2 Rationale for the Security Objectives for the Environment .................................................45
5 EXTENDED COMPONENTS DEFINITION .....................................................................................46
5.1 FIA_UAU_EXT.1 TIMING OF AUTHENTICATION...........................................................................46
5.1.1 Class FIA: Identification and authentication........................................................................46
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
3 of 105
5.1.2 Family: User authentication (FIA_UAU)..............................................................................46
5.1.3 Family Behaviour ................................................................................................................46
5.1.4 Management .......................................................................................................................46
5.1.5 Audit ....................................................................................................................................47
5.1.6 Definition .............................................................................................................................47
5.1.7 Rationale .............................................................................................................................47
5.2 IDS_SDC_EXT.1 SYSTEM DATA COLLECTION...........................................................................47
5.2.1 Class IDS: Intrusion Detection System ...............................................................................47
5.2.2 Family: System Data Collection (IDS_SDC) .......................................................................47
5.2.3 Family Behavior...................................................................................................................47
5.2.4 Management .......................................................................................................................47
5.2.5 Audit ....................................................................................................................................48
5.2.6 Definition .............................................................................................................................48
5.2.7 Rationale .............................................................................................................................49
5.3 IDS_ANL_EXT.1 ANALYSER ANALYSIS......................................................................................49
5.3.1 Class IDS: Intrusion Detection System ...............................................................................49
5.3.2 Family: Analyser analysis (IDS_ANL) .................................................................................49
5.3.3 Family Behavior...................................................................................................................49
5.3.4 Management .......................................................................................................................49
5.3.5 Audit ....................................................................................................................................49
5.3.6 Definition .............................................................................................................................49
5.3.7 Rationale .............................................................................................................................50
5.4 IDS_RCT_EXT.1 ANALYSER REACT..........................................................................................50
5.4.1 Class IDS: Intrusion Detection System ...............................................................................50
5.4.2 Family: Analyser react (IDS_RCT)......................................................................................50
5.4.3 Family Behavior...................................................................................................................50
5.4.4 Management .......................................................................................................................50
5.4.5 Audit ....................................................................................................................................50
5.4.6 Definition .............................................................................................................................51
5.4.7 Rationale .............................................................................................................................51
5.5 IDS_RDR_EXT.1 RESTRICTED DATA REVIEW ...........................................................................51
5.5.1 Class IDS: Intrusion Detection System ...............................................................................51
5.5.2 Family: Security data review (IDS_RDR)............................................................................51
5.5.3 Family Behavior...................................................................................................................51
5.5.4 Management .......................................................................................................................51
5.5.5 Audit ....................................................................................................................................51
5.5.6 Definition .............................................................................................................................51
5.5.7 Rationale .............................................................................................................................52
5.6 IDS_STG_EXT.1 GUARANTEE OF SYSTEM DATA AVAILABILITY ..................................................52
5.6.1 Class IDS: Intrusion Detection System ...............................................................................52
5.6.2 Family: System data storage (IDS_STG)............................................................................52
5.6.3 Family Behavior...................................................................................................................52
5.6.4 Management .......................................................................................................................52
5.6.5 Audit ....................................................................................................................................52
5.6.6 Definition .............................................................................................................................52
5.6.7 Rationale .............................................................................................................................53
5.7 IDS_STG_EXT.2 PREVENTION OF SYSTEM DATA LOSS..............................................................53
5.7.1 Class IDS: Intrusion Detection System ...............................................................................53
5.7.2 Family: System data storage (IDS_STG)............................................................................53
5.7.3 Family Behavior...................................................................................................................53
5.7.4 Management .......................................................................................................................53
5.7.5 Audit ....................................................................................................................................53
5.7.6 Definition .............................................................................................................................53
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
4 of 105
5.7.7 Rationale .............................................................................................................................54
6 SECURITY REQUIREMENTS.........................................................................................................55
6.1 SECURITY FUNCTIONAL REQUIREMENTS .....................................................................................55
6.1.1 Class FAU: Security Audit...................................................................................................56
6.1.1.1 FAU_GEN.1 Audit Data Generation.........................................................................................56
6.1.1.2 FAU_SAR.1 Audit Review........................................................................................................57
6.1.1.3 FAU_SAR.2 Restricted audit review ........................................................................................58
6.1.1.4 FAU_SAR.3 Selectable audit review........................................................................................58
6.1.1.5 FAU_SEL.1 Selective audit......................................................................................................58
6.1.1.6 FAU_STG.2 Guarantees of audit data availability....................................................................58
6.1.1.7 FAU_STG.4 Prevention of audit data loss ...............................................................................59
6.1.2 Class FIA: Identification and Authentication .......................................................................59
6.1.2.1 FIA_ATD.1 User attribute definition..........................................................................................59
6.1.2.2 FIA_UAU_EXT.1 Timing of authentication...............................................................................59
6.1.2.3 FIA_UID.1 Timing of identification............................................................................................60
6.1.3 Class FMT: Security Management......................................................................................60
6.1.3.1 FMT_MOF.1 Management of security functions behavior........................................................60
6.1.3.2 FMT_MTD.1 Management of TSF data ...................................................................................61
6.1.3.3 FMT_SMF.1 Specification of Management Functions..............................................................64
6.1.3.4 FMT_SMR.1 Security Roles.....................................................................................................67
6.1.4 Class FPT: Protection of the TSF .......................................................................................67
6.1.4.1 FPT_ITT.1 Basic internal TSF data transfer protection............................................................67
6.1.5 Class FTA: TOE Access .....................................................................................................68
6.1.5.1 FTA_TAB.1 Default TOE access banners................................................................................68
6.1.6 Class IDS: IDS Component Requirements .........................................................................68
6.1.6.1 IDS_SDC_EXT.1 System Data Collection ...............................................................................68
6.1.6.2 IDS_ANL_EXT.1 Analyser analysis .........................................................................................68
6.1.6.3 IDS_RCT_EXT.1 Analyser react (EXT)....................................................................................69
6.1.6.4 IDS_RDR_EXT.1 Restricted Data Review (EXT).....................................................................70
6.1.6.5 IDS_STG_EXT.1 Guarantee of System Data Availability.........................................................70
6.1.6.6 IDS_STG_EXT.2 Prevention of System data loss ...................................................................70
6.2 SECURITY ASSURANCE REQUIREMENTS FOR THE TOE................................................................71
6.2.1 Class ADV: Development....................................................................................................72
6.2.1.1 ADV_ARC.1 Security architecture description .........................................................................72
6.2.1.2 ADV_FSP.2 Security-enforcing functional specification...........................................................72
6.2.1.3 ADV_TDS.1 Basic design ........................................................................................................73
6.2.2 Class AGD: Guidance documents ......................................................................................74
6.2.2.1 AGD_OPE.1 Operational user guidance..................................................................................74
6.2.2.2 AGD_PRE.1 Preparative procedures.......................................................................................74
6.2.3 Class ALC: Life-cycle support.............................................................................................75
6.2.3.1 ALC_CMC.2 Use of a CM system............................................................................................75
6.2.3.2 ALC_CMS.2 Parts of the TOE CM coverage ...........................................................................75
6.2.3.3 ALC_DEL.1 Delivery procedures .............................................................................................76
6.2.3.4 ALC_FLR.2 Flaw reporting procedures....................................................................................76
6.2.4 Class ATE: Tests ................................................................................................................77
6.2.4.1 ATE_COV.1 Evidence of coverage..........................................................................................77
6.2.4.2 ATE_FUN.1 Functional testing.................................................................................................77
6.2.4.3 ATE_IND.2 Independent testing - sample................................................................................78
6.2.5 Class AVA: Vulnerability assessment .................................................................................78
6.2.5.1 AVA_VAN.2 Vulnerability analysis ...........................................................................................78
6.3 SECURITY REQUIREMENTS RATIONALE .......................................................................................80
6.3.1 Dependencies Satisfied ......................................................................................................80
6.3.2 Functional Requirements ....................................................................................................80
6.3.3 Assurance Rationale ...........................................................................................................84
7 TOE SUMMARY SPECIFICATION .................................................................................................85
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
5 of 105
7.1 IT SECURITY FUNCTIONS............................................................................................................85
7.1.1 Security Audit Functions .....................................................................................................86
7.1.1.1 AU-1: Audit Generation............................................................................................................86
7.1.1.2 AU-2: Audit Review..................................................................................................................87
7.1.1.3 AU-3: Audit Selection...............................................................................................................87
7.1.1.4 AU-4: Audit Record Protection .................................................................................................89
7.1.2 User I&A Functions .............................................................................................................90
7.1.2.1 IA-1: User Security Attributes...................................................................................................90
7.1.2.2 IA-2: User Identification & Authentication.................................................................................91
7.1.3 Security Management Functions.........................................................................................93
7.1.3.1 SM-1: Management Functions .................................................................................................93
7.1.3.2 SM-2: Management Security Roles..........................................................................................93
7.1.4 Protection of Security Functions .........................................................................................95
7.1.4.1 PT-1: Internal Data Transfer Protection ...................................................................................95
7.1.5 TOE Access Functions........................................................................................................95
7.1.5.1 TA-1 TOE Login Information ....................................................................................................95
7.1.6 Intrusion Detection System Functions ................................................................................96
7.1.6.1 ID-1: System Data Collection ...................................................................................................96
7.1.6.2 ID-2: System Data Analysis .....................................................................................................96
7.1.6.3 ID-3: Analyzer Alarms ............................................................................................................101
7.1.6.4 ID-4: System Data Review.....................................................................................................102
7.1.6.5 ID-5: System Data Protection.................................................................................................102
7.2 TOE PROTECTION AGAINST INTERFERENCE AND LOGICAL TAMPERING.......................................103
7.3 TOE PROTECTION AGAINST BYPASS OF SECURITY FUNCTIONS..................................................104
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
6 of 105
Figures and Tables
Figures Page
FIGURE 1: SOURCEFIRE 3D SYSTEM WITH DEFENSE CENTER........................................................................22
FIGURE 2: SOURCEFIRE 3D SYSTEM USING A STAND-ALONE 3D SENSOR WITH IPS........................................23
Tables Page
TABLE 1-1: REFERENCES ..............................................................................................................................7
TABLE 1-2: PRODUCT AND CC ACRONYMS.....................................................................................................9
TABLE 1-3: PRODUCT AND CC TERMINOLOGY ..............................................................................................10
TABLE 1-4: 3D SENSOR WITH IPS CATEGORIES ...........................................................................................17
TABLE 1-5: USER GUIDANCE DOCUMENTS ...................................................................................................21
TABLE 3-1: TOE THREATS...........................................................................................................................34
TABLE 3-2: IT SYSTEM THREATS..................................................................................................................34
TABLE 3-3: ORGANIZATIONAL SECURITY POLICIES........................................................................................35
TABLE 3-4: TOE USAGE ASSUMPTIONS .......................................................................................................36
TABLE 3-5: TOE PHYSICAL ASSUMPTIONS ...................................................................................................36
TABLE 3-6: TOE PERSONNEL ASSUMPTIONS................................................................................................36
TABLE 4-1: TOE SECURITY OBJECTIVES......................................................................................................37
TABLE 4-2: SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................38
TABLE 4-3: SECURITY OBJECTIVES AND SECURITY ENVIRONMENT MAPPING..................................................40
TABLE 5-1: EXTENDED COMPONENTS ..........................................................................................................46
TABLE 5-2: SYSTEM EVENTS .......................................................................................................................48
TABLE 6-1: TOE SECURITY FUNCTIONAL COMPONENTS ...............................................................................56
TABLE 6-2: AUDITABLE EVENTS ...................................................................................................................57
TABLE 6-3: MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR ...................................................................60
TABLE 6-4: MANAGEMENT OF TSF DATA......................................................................................................61
TABLE 6-5: SYSTEM EVENTS .......................................................................................................................68
TABLE 6-6: EAL2+ ASSURANCE COMPONENTS ............................................................................................71
TABLE 6-7: TOE DEPENDENCIES SATISFIED.................................................................................................80
TABLE 6-8: REQUIREMENTS VS. OBJECTIVES MAPPING .................................................................................81
TABLE 7-1: SECURITY FUNCTIONAL REQUIREMENTS MAPPED TO SECURITY FUNCTIONS.................................85
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
7 of 105
1 Security Target Introduction
1.1 Security Target Reference
ST Title: Sourcefire 3D System Security Target (Sourcefire Defense Center:
models DC500, DC1000, and DC3000; and Sourcefire 3D Sensor
licensed for IPS: models 3D500, 3D1000, 3D2000, 3D2100, 3D2500,
3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800) Version
4.8.2.1 (SEU 259)
ST Version: v1.15
ST Author: CygnaCom Solutions
ST Date: June 10, 2010
Assurance level: EAL2 augmented with ALC_FLR.2
Protection Profile: U.S. Government Protection Profile Intrusion Detection System System
For Basic Robustness Environments, Version 1.7, July 25, 2007
Keywords: intrusion prevention, intrusion detection, intrusion detection system,
intrusion prevention system, IDS, IPS, scanner, analyzer, sensor
1.1.1 References
Table 1-1 provides the references used to develop this Security Target.
Table 1-1: References
Reference Title ID
Common Criteria for Information Technology Security Evaluation, CCMB-2007-
09-002, Version 3.1, Revision 2
[CC]
Sourcefire 3D System - CC Supplement for Version 4.8.2.1, 2010-Jun-08 [CC-SUPP]
New Features from v3.2.3 to v4.8, 2008-Aug-7 [CHANGES]
Sourcefire 3D System - Defense Center Installation Guide, Version 4.8 , 2008-Jul-
23
[DC-INSTALL]
U.S. Government Protection Profile Intrusion Detection System System For Basic
Robustness Environments, Version 1.7, July 25, 2007.
[IDS_PP]
Sourcefire 3D System - 3D Sensor Installation Guide, Version 4.8.2 2009-Oct-02 [SENS-INSTALL]
Sourcefire 3D System - Sourcefire 3D System User Guide, Version 4.8.2, 2009-
Sep-01
[USER]
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
8 of 105
1.2 TOE Reference
TOE Identification: Sourcefire 3D System (Sourcefire Defense Center: models DC500,
DC1000, and DC3000; and Sourcefire 3D Sensor licensed for IPS:
models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D3800,
3D4500, 3D5800, 3D6500, and 3D9800) Version 4.8.2.1 (SEU 259)
TOE Vendor: Sourcefire, Inc.
1.3 TOE Overview
The Target of Evaluation (TOE) is an Intrusion Prevention and Detection System, which
consists of the Sourcefire Defense Center and Sourcefire 3D Sensor licensed for IPS
appliances and software. The Sourcefire Defense Center (Defense Center) and Sourcefire 3D
Sensor licensed for IPS (3D Sensor with IPS) are components of the Sourcefire 3D System
Version 4.8.2.1 (SEU 259)
The TOE provides the following security functionality: auditing of security relevant events; TOE
user account administration; TOE user identification and authentication; security role based
access to management functions; trusted communication between components; display of
TOE access warning banners; and system data collection, analysis, review, availability and
loss.
A previous version of the product, Sourcefire Intrusion Detection System Version 3.2.3, was
evaluated and certified at EAL2 in May 2005.
1.3.1 TOE Type
The TOE is an Intrusion Prevention and Detection System that combines open-source and
proprietary technology. The TOE is used to monitor incoming (and outgoing) network traffic,
from either inside or outside a firewall. All packets on the monitored network are scanned,
decoded, processed and compared against a set of rules to determine whether inappropriate
traffic, such as system attacks, is being passed over the network. The system then notifies a
designated TOE administrator of these attempts. The system generates these alerts when
deviations of the expected network behavior are detected and when there is a match to a
known attack pattern.
1.3.2 Hardware/Firmware/Software Required by the TOE
The Sourcefire 3D System Version 4.8.2.1 (SEU 259) software is embedded in the Defense
Center and the 3D Sensor with IPS appliances. The appliance hardware, the underlying
operating systems, and third-party applications installed on the appliances provide support for
the intrusion detection functions and associated security management functions of the TOE,
and are included in the TOE.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
9 of 105
Each appliance includes a Linux-derived operating system. The hardware and operating
system on which the Sourcefire 3D System application software operates provides the support
necessary for the software applications to exist as processes and to access necessary disk,
memory, and network connection resources.
Please see Sections 1.4.3.1 Sourcefire 3D Sensor licensed for IPS (3D Sensor with IPS) and
1.4.3.2 Sourcefire Defense Center (Defense Center) for a detailed description of the TOE
components
The evaluated configuration of the TOE requires the following Operational Environment
support:
 A Web Browser for the Defense Center or 3D Sensor with IPS management interfaces.
Sourcefire 3D System Version 4.8.2.1 only supports the following three browsers:
o Firefox Version (Minimum) 2.x
o Microsoft Internet Explorer Version 6.0 with Service Pack 2
o Microsoft Internet Explorer Version 7.0
The browser must support JavaScript, cookies, and Secure Sockets Layer (SSL). The
TOE administrators must also ensure that SSL v3 and 128-bit encryption are enabled.
(For Internet Explorer 7.0, the Active Scripting option in the security settings must be
enabled.)
 A private, protected network between the Defense Center and the 3D Sensor(s) with
IPS.
 The network(s) that are to be monitored.
 Network Authentication Services.
 A trusted DNS Server.
 An NTP Server to provide reliable time.
 An Email Server to send administrator alert notifications and warnings.
The following Operational Environment components are optional for the evaluated
configuration of the TOE.
 An external Syslog Server for administrator alert notifications.
 An SNMP Trap Server for administrator alert notifications.
 An external authentication server (LDAP or RADIUS).
1.4 TOE Description
1.4.1 Acronyms
The following table defines product specific and CC specific acronyms used within this
Security Target.
Table 1-2: Product and CC Acronyms
Acronym Definition
CC Common Criteria [for IT Security Evaluation]
CIDR Classless Inter Domain Routing
CM Configuration Management
EAL Evaluation Assurance Level
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
10 of 105
Acronym Definition
FIPS Federal Information Processing Standards Publication
GB Gigabyte
HTTP HyperText Transmission Protocol
HTTPS HyperText Transmission Protocol, Secure
ICMP Internet Control Message Protocol
ID Identifier
IDS Intrusion Detection System
IPS Intrusion Prevention System
IT Information Technology
NIST National Institute of Standards and Technology
PP Protection Profile
RPC Remote Procedure Call
SEU Security Enhancement Updates
SF Security Function
SFIDS Sourcefire Intrusion Detection System
SFP Security Function Policy
SFR Security Functional Requirements
SNMP Simple Network Management Protocol
ST Security Target
TCP/IP Transmission Control Protocol/Internet Protocol
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSFI TOE Security Functions Interface
TSP TOE Security Policy
UDP User Datagram Protocol
UI User Interface
URI Uniform Resource Identifier
1.4.2 Terminology
The following table defines product-specific and CC-specific terminology used within this
Security Target.
Table 1-3: Product and CC Terminology
Terminology Definition
Access List A list of computers can access the appliance on specific ports.
Analyzer data Data collected by the analyzer functions.
Analyzer functions The active part of the analyzer responsible for performing intrusion
analysis of information that may be representative of vulnerabilities in
and misuse of IT resources, as well as reporting of conclusions. The
3D Sensor with IPS performs the analyzer functions of the TOE.
Assets Information or resources to be protected by the countermeasures of a
TOE.
Attack An attempt to bypass security controls on an IT System. The attack
may alter, release, or deny data. Whether an attack will succeed
depends on the vulnerability of the IT System and the effectiveness of
existing countermeasures.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
11 of 105
Terminology Definition
Audit The independent examination of records and activities to ensure
compliance with established controls, policy, and operational
procedures, and to recommend indicated changes in controls, policy,
or procedures.
Audit Log (Audit Trail) In an IT System, a chronological record of system resource usage.
This includes user login, file access, other various activities, and
whether any actual or attempted security violations occurred,
legitimate and unauthorized.
Authentication To establish the validity of a claimed user or object.
Authentication Object An object that contains the settings for connecting to and retrieving
user data from an external authentication server.
Authorized Administrator
(TOE Administrator)
The authorized users that manage the TOE or a subset of its TSF
data and management functions.
Availability Assuring information and communications services will be ready for
use when expected.
Compromise An intrusion into an IT System where unauthorized disclosure,
modification or destruction of sensitive information may have
occurred.
Confidentiality Assuring information will be kept secret, with access limited to
appropriate persons.
Defense Center The Sourcefire 3D System Defense Center appliance and the
software installed upon it. A central management point that allows the
management of the 3D Sensors and automatically aggregates the
events they generate.
Detection Engine The mechanism that is responsible for analyzing the traffic on the
network segment where a sensor is connected.
Evaluation Assessment of a PP, a ST or a TOE, against defined criteria.
Health Alert An alert generated by the Defense Center when a specific health
event occurs.
Health Event An event that is generated when one of the appliances in a
deployment meets (or fails to meet) performance criteria specified in a
health module. Health events indicate which module triggered the
event and when the event was triggered.
Health Module A test of a particular performance aspect of one of the appliances in a
deployment.
Health Policy The criteria used when checking the health of an appliance in a
deployment. Health policies use health modules to indicate whether
Sourcefire 3D System hardware and software are working correctly.
IDS component A sensor, scanner, or analyzer. The 3D Sensor with IPS is the IDS
component of the TOE.
Incident One or more intrusion events that are suspected of being involved in a
possible violation of a security policy.
Information Technology (IT)
System
May range from a computer system to a computer network.
Integrity Assuring information will not be accidentally or maliciously altered or
destroyed.
Interface Set One or more sensing interfaces on a 3D Sensor that can be used to
monitor network segments for one or more detection engines.
Intrusion Any set of actions that attempt to compromise the integrity,
confidentiality or availability of a resource.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
12 of 105
Terminology Definition
Intrusion Detection The process of passively analyzing network traffic for potential
intrusions and storing attack data for security analysis.
Intrusion Detection System
(IDS)
A combination of sensors, scanners, and analyzers that monitor an IT
System for activity that may inappropriately affect the IT System's
assets and react appropriately.
Intrusion Detection System
Analyzer (analyzer)
The component of an IDS that accepts data from sensors, scanners
and other IT System resources, and then applies analytical processes
and information to derive conclusions about intrusions (past, present,
or future). The 3D Sensor with IPS is the analyzer component of the
TOE.
Intrusion Detection System
Scanner (scanner)
The component of an IDS that collects 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. The 3D Sensor with
IPS is the scanner component of the TOE.
Intrusion Detection System
Sensor (sensor)
The component of an IDS that collects real-time events that may be
indicative of vulnerabilities in or misuse of IT resources. The 3D
Sensor with IPS is the sensor component of the TOE.
Intrusion Event A record of the network traffic that violated an intrusion policy.
Intrusion Policy Intrusion policies include a variety of components that are configured
to inspect network traffic for intrusions and policy violations. These
components include preprocessors; intrusion rules that inspect the
protocol header values, payload content, and certain packet size
characteristics; and tools that control how often events are logged and
displayed.
Intrusion Protection The concept of intrusion detection with the added ability to block or
alter malicious traffic as it travels across a network.
Intrusion Rule A set of keywords and arguments that, when applied to captured
network traffic, identify potential intrusions, policy violations, and
security breaches. IPS compares packets against the conditions
specified in each rule and, if the packet data matches all the
conditions specified in the rule, the rule triggers and generates an
intrusion event.
IT Product A package of IT software, firmware and/or hardware, providing
functionality designed for use or incorporation within a multiplicity of
systems.
Network Two or more machines interconnected for communications.
Packet A block of data sent over the network transmitting the identities of the
sending and receiving stations, error-control information, and
message.
Packet Sniffer A device or program that monitors the data traveling between
computers on a network.
Preprocessor A feature of IPS that normalizes traffic and helps identify network layer
and transport layer protocol anomalies by identifying inappropriate
header options, defragmenting IP datagrams, providing TCP stateful
inspection and stream reassembly, and validating checksums.
Protection Profile (PP) An implementation-independent set of security requirements for a
category of TOEs that meet specific consumer needs.
Reviewed Event An intrusion event that has been examined by an administrator who
has determined that the event does not represent a threat to network
security and who has marked the event as reviewed.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
13 of 105
Terminology Definition
Root (root user, root
account)
The superuser, a user on Unix-like systems, usually with full
administrative privileges.
Scanner data Data collected by the scanner functions.
Scanner functions The active part of the scanner responsible for collecting configuration
information that may be representative of vulnerabilities in and misuse
of IT resources (i.e., scanner data).
Security A condition that results from the establishment and maintenance of
protective measures that ensures a state of inviolability from hostile
acts or influences.
Security Policy The set of laws, rules, and practices that regulate how an organization
manages, protects, and distributes sensitive information.
Security Target (ST) A set of security requirements and specifications to be used as the
basis for evaluation of an identified TOE.
Sensor (3D Sensor with IPS) An appliance-based sensor that, as part of the Sourcefire 3D System,
can run the IPS component. The 3D Sensor with IPS includes the
appliance hardware and the Sourcefire application software, Linux
derived operating system, and supporting 3rd party software installed
on the appliance.
Sensor data Data collected by the Sensor functions.
Sensor functions The active part of the Sensor responsible for collecting information
that may be representative of vulnerabilities in and misuse of IT
resources (i.e., Sensor data).
Signatures Patterns of network traffic that can be used to detect attacks or
exploits.
System Policy Settings that are likely to be similar for multiple appliances in a
deployment, such as access configuration, authentication profiles,
database limits, DNS cache settings, the mail relay host, a notification
address for database prune messages, and time synchronization
settings.
Target of Evaluation (TOE) An IT product or system and its associated administrator and user
guidance documentation that is the subject of an evaluation.
Threat The means through which the ability or intent of a threat agent to
adversely affect an automated system, facility, or operation can be
manifest. A potential violation of security.
TOE Security Functions
(TSF)
A set consisting of all hardware, software, and firmware of the TOE
that must be relied upon for the correct enforcement of the TSP.
TOE Security Policy (TSP) A set of rules that regulate how assets are managed, protected, and
distributed within a TOE.
Trojan Horse An apparently useful and innocent program containing additional
hidden code that allows the unauthorized collection, exploitation,
falsification, or destruction of data.
TSF data Data created by and for the TOE, which might affect the operation of
the TOE.
TSF Scope of Control (TSC) The set of interactions that can occur with or within a TOE and are
subject to the rules of the TSP.
User Any entity (human user or external IT entity) outside the TOE that
interacts with the TOE.
Virus A program that can "infect" other programs by modifying them to
include a, possibly evolved, copy of itself.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
14 of 105
Terminology Definition
Vulnerability Hardware, firmware, or software flow that leaves an IT System open
for potential exploitation. A weakness in automated system security
procedures, administrative controls, physical layout, internal controls,
and so forth, which could be exploited by a threat to gain unauthorized
access to information or disrupt critical processing.
Workflow A series of Web pages available on the TOE‟s WebUI that the
administrators can use to view and evaluate events by moving from a
broad view of event data to a more focused view that contains only
the events of interest.
1.4.3 Product Description
Sourcefire markets an integrated Enterprise Threat Management (ETM) solution. To provide
the entire ETM solution, Sourcefire 3D System integrates four core products: Sourcefire IPS,
Sourcefire RNA, Sourcefire RUA, and the Sourcefire Defense Center. Sourcefire offers these
products as individual components or as a system to a meet a variety of IT security needs and
budgets. Each product is sold separately and requires a separate license to run. This
evaluation includes two of the four core products: Sourcefire IPS (the Sourcefire 3D Sensor
licensed for IPS) and the Sourcefire Defense Center.
The Sourcefire 3D System monitors a customer‟s network for traffic that could affect the
availability, integrity, and confidentiality of a host and its data. By placing 3D Sensors with IPS
on key network segments, the packets that traverse the network can be examined for
malicious activity. The TOE allows authorized administrators to monitor the network for attacks
that might affect the availability, integrity, or confidentiality of hosts on the network either
directly from the 3D Sensors with IPS or through a central Defense Center.
The Sourcefire Intrusion Prevention System (also called IPS) is one of the components of the
Sourcefire 3D System that can be run on the Sourcefire 3D Sensors. Each Sourcefire 3D
Sensor licensed for IPS uses rules, decoders, and preprocessors to look for the broad range
of exploits that attackers have developed. The Sourcefire 3D Sensors licensed for IPS allow
the Sourcefire 3D System to be used as an intrusion detection system and/or an intrusion
prevention system.
The Sourcefire 3D System TOE consists of the following components:
 The Sourcefire 3D Sensor licensed for IPS
 The Sourcefire Defense Center
1.4.3.1 Sourcefire 3D Sensor licensed for IPS (3D Sensor with IPS)
The Sourcefire 3D Sensor is based on an enhanced version of Snort, which is an open source
IDS. Snort (as modified and included in the TOE) is used to read all the packets on the
monitored network, and then analyzes them against the rule set that has been created by the
TOE administrators. Snort Version: v2.8.3 is included in the CC evaluated version of the
Sourcefire 3D System.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
15 of 105
A detection engine is the mechanism on a Sourcefire 3D Sensor that is responsible for
analyzing the traffic on the network segment where the sensor is connected. A detection
engine has two main components:
 an interface set, which can include one or more sensing interfaces
 a detection resource, which is a portion of the sensor‟s computing resources
Depending on which components are licensed on the sensor, Sourcefire 3D Sensors can
support three types of detection engines:
 Intrusion Prevention System (IPS)
 Real-Time Network Awareness (RNA)
 Real-Time User Awareness (RUA)
Only IPS is included in the scope of this evaluation.
Each 3D Sensor with IPS uses rules, decoders, and preprocessors to look for the broad range
of exploits that attackers have developed. Sourcefire 3D Sensors that are licensed to use IPS
are packaged with a set of intrusion rules developed by the Sourcefire Vulnerability Research
Team (VRT). The TOE administrators can choose to enable rules that would detect the attacks
most likely to occur on the monitored network. Custom intrusion rules and policies can also be
created for a customer‟s operating environment.
When a 3D Sensor with IPS identifies a possible intrusion, it generates an intrusion event,
which is a record of the date, time, the type of exploit, and contextual information about the
source of the attack and its target. For packet-based events, a copy of the packet or packets
that triggered the event is also recorded.
3D Sensors with IPS can be deployed either inline, where "live" traffic passes through the
appliance, or passively, in which case traffic is being only monitored. When used inline, IPS
can block malicious code and attacks in real-time so that the 3D Sensor with IPS is used as an
intrusion prevention device.
In a passive deployment, the sensing interfaces connected to the network are configured in
stealth mode so that, to other devices on the network, the sensor itself does not appear to be
connected to the network at all. A benefit of passive deployment is that almost all of the
sensor bandwidth and computational power are devoted to monitoring traffic, reconstructing
datagrams and streams, normalizing packets, detecting anomalies, and sending alerts of
possible intrusions. Moreover, because the sensor is deployed out of band and operates in
stealth mode, attackers are unlikely to know of its existence, which renders it less of a target
for attacks. However, in a passive deployment the 3D Sensor with IPS can only perform
passive intrusion detection and send alerts when it detects malicious traffic packets, but it
cannot affect the flow of network traffic.
Both the inline and passive deployments are included in the evaluated configuration.
In addition, 3D Sensors with IPS run decoders and preprocessors against detected network
traffic to normalize traffic and detect malicious packets. If the 3D Sensor with IPS is deployed
inline on the network and creates what is called an inline detection engine, the 3D Sensor with
IPS can be configured to drop or replace packets that are known to be harmful.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
16 of 105
In a Sourcefire 3D System deployment that includes 3D Sensors with IPS and a Defense
Center, the sensors transmit events and sensor statistics to the Defense Center where the
aggregated data can be viewed.
Some models of the 3D Sensor with IPS provide a local web interface (WebUI) to create
intrusion policies and review the resulting intrusion events and therefore can be run stand-
alone, without using a Defense Center for management.
The command line interface (CLI) of the appliance‟s operating system is used for the initial
configuration and off-line maintenance of the 3D Sensor with IPS. Use of the CLI is also
required to configure audit suppression lists (See Section 7.1.1.3 AU-3: Audit Selection). By
default, port 443 (Secure Sockets Layer, or SSL), which is used to access the web interface
(WebUI), and port 22 (Secure Shell, or SSH), which is used to access the shell (CLI), are
enabled for any IP address. By default, access to the appliance is not restricted. To operate
the appliance in a more secure environment, an access list should be created during the initial
configuration of the system, which restricts shell access to the appliance to specific IP
addresses. Ideally, only the IP address for one console will be enabled for shell access per
system. Since the CLI is needed for system maintenance, and creating and editing audit
suppression lists, the administrator must be careful not to disable all access to the system.
Users who have shell access to the 3D Sensor with IPS and can access the operating
system‟s root account should also be restricted to only those administrators who need to
configure and maintain the system.
Each 3D Sensor with IPS includes a MySQL (v4.1.22) database that stores audit data,
configuration data (intrusion policies, system policies …), and IDS system data. The database
storage options are configurable. A TOE administrator can choose to send the intrusion events
to the Defense Center that manages the sensor, send the events to the Defense Center and
keep a local copy in sensor's database, or if the sensor is used as a stand-alone system, all
events are stored locally in the database. There is no direct access to the MySQL database
through the management WebUI.
The same Sourcefire application software is installed on all models of the 3D Sensor with IPS
appliances. Therefore, each 3D Sensor with IPS appliance model has the same security
functionality, with the exception of the availability of the web interface noted above. However,
although the Version 4.8.2.1 source code is the same for all models of the appliance, there are
separate builds of the software that depend on the version of the operating system installed on
the appliance. The 3D Sensors with IPS can therefore be categorized by the Linux-derived
operating system installed on the appliance as follows:
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
17 of 105
Table 1-4: 3D Sensor with IPS Categories
Sourcefire 3D Sensor Category Sourcefire 3D Sensor Appliance Model
SBLinux v4.8
Bivio OS which is based on SUSE 7.3
3D Sensor 3800 *
3D Sensor 5800 *
SVLinux v4.8
Bivio OS which is based on Fedora Core 5
3D Sensor 9800 *
SFLinux v4.8
Sourcefire Proprietary Linux-derived OS
3D Sensor 500
3D Sensor 1000
3D Sensor 2000
3D Sensor 2100
3D Sensor 2500
3D Sensor 3500
3D Sensor 4500
3D Sensor 6500
* These sensors (usually referred to as the 3Dx800 sensors) do not have a web interface and
must be managed with a Defense Center.
Each category of the sensors will be tested in this evaluation.
Besides the appliance hardware, Sourcefire application software, MySQL database and the
operating systems mentioned above, the following supporting 3rd
party software is included in
the 3D Sensor with IPS TOE Component:
 Network connectivity provided through third-party encryption software (OpenSSL
v0.9.8g)
 Protocol standards including HTTPS, SMTP, SSH, and SNMP (v2 or v3)
implementations
 Perl (v5.8.3)
 Shell access through OpenSSH (v4.7pl)
 Web Server (Tomcat Apache version 1.3.39)
Note: The Tomcat Web Server is not included in the 3Dx800 sensors
Note: The cryptography used in this product has not been FIPS certified nor has it been
analyzed or tested to conform to cryptographic standards during this evaluation. All
cryptography has only been asserted as tested by the vendor.
1.4.3.2 Sourcefire Defense Center (Defense Center)
The Sourcefire Defense Center provides a centralized management interface for the
Sourcefire 3D System. The Defense Center is used to manage the full range of sensors that
are a part of the Sourcefire 3D System, and to aggregate, analyze, and respond to the threats
they detect on the monitored network.
The Defense Center provides the following functionality through a web-based GUI (WebUI):
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
18 of 105
 An interface which displays all the data collected by the managed 3D Sensors with IPS
allowing:
o monitoring of the information that the sensors are reporting in relation to one
another
o assessment of the overall activity occurring on the monitored network
 An interface to analyze and respond to the alerts generated by the sensors
 The aggregation and correlation of intrusion events, network discovery information, and
sensor performance data
 The ability to create and configure rules and policies for managed sensors and push
the rules and policies to the sensors
 The ability to push health policies to the sensors and monitor their health status
 TOE configuration and management capabilities including configuration and
management of user accounts and auditing
The command line interface (CLI) of the appliance‟s operating system is used for the initial
configuration and off-line maintenance of the Defense Center. Use of the CLI is required to
configure audit suppression lists (See Section 7.1.1.3 AU-3: Audit Selection). By default, port
443 (Secure Sockets Layer, or SSL), which is used to access the web interface (WebUI), and
port 22 (Secure Shell, or SSH), which is used to access the shell (CLI), are enabled for any IP
address. By default, access to the appliance is not restricted. To operate the appliance in a
more secure environment for Common Criteria compliance, an access list must be created
during the initial configuration of the system, which restricts shell access to the appliance to
specific IP addresses. Ideally, only the IP address for one console will be enabled for shell
access per system. Since the CLI is needed for system maintenance, and creating and editing
audit suppression lists, the administrator must be careful not to disable all access to the
system.
Users who have shell access to the Defense Center and can access the operating system‟s
root account must also be restricted to only those administrators who need to configure and
maintain the system.
The Defense Center includes the Sourcefire proprietary Linux-derived OS, SFLinux v4.8, and
a MySQL (v.4.1.22) database repository. The database is used to store intrusion, audit, and
health events, as well as other events that are outside the TOE. Configuration information is
also stored in the database. This information includes intrusion, health, and system policies.
Intrusion rules are delivered as flat files that are later stored in the database. There is no direct
access to the MySQL database through the management WebUI.
The Sourcefire 3D System has the capability of using an external LDAP or RADIUS server for
user authentication in a configuration that uses a Defense Center. User accounts are stored in
the Defense Center‟s MySQL database, including the initial RADIUS and LDAP information if
external authentication of users is configured. When RADIUS or LDAP authentication is used,
an additional file is written to disk.
The Defense Center also provides the capability to download and import Security
Enhancement Updates (SEUs) that contain new intrusion rules, which are provided by the
Sourcefire Vulnerability Research Team (VRT). The SEUs can be downloaded and imported
by authorized administrators on command and are not necessarily automatic. However, these
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
19 of 105
SEU releases may also contain new and updated decoders and preprocessors, and updates
to the 3D Sensor with IPS code. Because the SEUs can contain binaries that modify the TOE
software, once applied, the Sourcefire 3D System may no longer be in the evaluated
configuration. Therefore, the SEU feature cannot be used in the evaluated configuration.
Detailed information about the changes to rules contained in each SEU release can be
obtained on the Sourcefire customer support web site for those customers who wish to make
the updates manually.
The CC evaluation version of the Sourcefire 3D System includes SEU Version 259 (which in
turn includes Snort Version 2.8.3).
A Master Defense Center can be used to aggregate and analyze data from up to ten Defense
Centers within a Sourcefire 3D System deployment. Master Defense Centers allow the product
to monitor a large-scale enterprise. A Master Defense Center will not be included in the scope
of the evaluation.
The product also includes a High Availability feature that uses redundant Defense Centers to
manage groups of sensors. If the primary Defense Center fails, the secondary Defense Center
is used to monitor the network without interruption. The High Availability feature is not included
in the evaluated configuration of the TOE.
Besides the appliance hardware, Sourcefire application software, MySQL database and the
operating system mentioned above, the following supporting third party software is included in
the Defense Center TOE component:
 Network connectivity provided through third-party encryption software (OpenSSL
v0.9.8g)
 Protocol standards including HTTPS, SMTP, SSH, and SNMP (v2 or v3)
implementations
 Perl (v5.8.3)
 Shell access through OpenSSH (v4.7pl)
 Web Server (Tomcat Apache version 1.3.39)
Note: The cryptography used in this product has not been FIPS certified nor has it been
analyzed or tested to conform to cryptographic standards during this evaluation. All
cryptography has only been asserted as tested by the vendor.
The Sourcefire software, operating system, database, and third party products are the same
for all models of the Defense Center appliances (Defense Center Models DC500, DC1000 and
DC3000).
1.4.4 Data
The data managed by the TOE can be categorized as:
 Data used to configure, manage, and operate the TOE such as: user accounts and IDS
rules and policies
 Audit data produced by the TOE for security significant events
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
20 of 105
 Data collected from the monitored network assets such as: Identification and
authentication events, Data accesses, and Network traffic (system data)
All TOE data is considered TSF Data.
1.4.5 Users
The TOE maintains defined user roles, each with its own set of administrative privileges. When
a new user account is created, it must be assigned a role. A user may be assigned more than
one role. No access is allowed to the system until a user has been authenticated and access
to TSF data and functions is controlled by the TOE‟s interfaces only to the data and functions
allowed to the authenticated user‟s role.
All users of the TOE have access to TSF data and management functions, and therefore are
considered administrators for the purposes of this evaluation. The terms “TOE user,” TOE
administrator” and “authorized administrator” are used in this ST to refer collectively to all
authorized TOE users.
The defined roles for TOE users are:
 “Administrator” Role: this role can perform all management, maintenance and
analysis functions on the TOE.
 “Maintenance” Role: this role can view and manage status, security audit events,
system time, and the reporting functionality of the product, and can perform system
level maintenance related actions.
 “Intrusion Event Analyst” Role: this role can view, analyze, review, and delete
intrusion events and can also create incidents and generate reports.
 “Intrusion Event Analyst (Read Only)” Role: this role has read-only access to IPS
analysis features, including intrusion event views, incidents, and reports.
 “Restricted Event Analyst” Role: this role provides access to the same features as
the Intrusion Event Analyst role, but is restricted to only those events that match
specified search criteria (specific IP Addresses or subsets of data).
 “Restricted Event Analyst (Read Only)” Role: this role is the same as the Restricted
Event Analyst role except that users have read-only access to the intrusion events that
match the specified search criteria.
 “Policy and Response Administrator” Role: this role can create, modify, and
implement intrusion policies and intrusion rules for the IDS.
1.4.6 Product Guidance
The Sourcefire 3D System documentation set includes online help and PDF files.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
21 of 105
The following product guidance documents are provided with the TOE on the Documentation
CD included with the product:
Table 1-5: User Guidance Documents
Sourcefire 3D System - 3D Sensor Installation Guide, Version 4.8.2 2009-Oct-02
Sourcefire 3D System - Defense Center Installation Guide, Version 4.8 , 2008-Jul-23
Sourcefire 3D System - Sourcefire 3D System User Guide, Version 4.8.2, 2009-Sep-01
The most up-to-date versions of the documentation can be accessed on the Sourcefire
Support web site (https://support.sourcefire.com/).
Online help can be accessed in two ways:
 by clicking the context-sensitive help links on each page
 by selecting Operations > Help > Online
The CC evaluated version of the Sourcefire 3D System, Version 4.8.2.1 (SEU 259) also
includes Sourcefire 3D System - CC Supplement for Version 4.8.2.1, [CC-SUPP]. [CC-SUPP]
documents how to install, configure and maintain the Sourcefire 3D System in the CC
evaluated configuration. [CC-SUPP] is packaged with the appliances in hard-copy format.
1.4.7 Physical Scope of the TOE
The TOE consists of the two components described in Sections 1.4.3.1 and 1.4.3.2. The
physical boundary of the TOE is the Sourcefire 3D Sensor licensed for IPS and the Sourcefire
Defense Center appliances installed with the Sourcefire 3D System Version 4.8.2.1 (SEU 259)
software, Linux-derived operating system, MySQL database, and supporting third party
software as commercially available from the developer. The TOE Boundary is depicted in
Figure 1 and Figure 2.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
22 of 105
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Management Network
(Private Network among TOE components)
WebUI
Defense Center Appliance
3D System
Software
DC
MySQL
3rd Party Software Applications
Linux-Derived Operating System
3D System
Software MySQL
3D Sensor Appliance
3rd Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
MySQL
3rd Party Software Applications
Linux-Derived Operating System
RNA RUA
3D Sensor Appliance
3D System
Software
IPS
NTP
Server
EMAIL
Server
SNMP
Server
LDAP /
RADIUS
Server
DNS
Server
Syslog
Server
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Management Network
(Private Network among TOE components)
WebUI
Defense Center Appliance
3D System
Software
DC
MySQL
3rd Party Software Applications
Linux-Derived Operating System
3D System
Software MySQL
3D Sensor Appliance
3rd Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
MySQL
3rd Party Software Applications
Linux-Derived Operating System
RNA RUA
3D Sensor Appliance
3D System
Software
IPS
NTP
Server
EMAIL
Server
SNMP
Server
LDAP /
RADIUS
Server
DNS
Server
Syslog
Server
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Figure 1: Sourcefire 3D System with Defense Center
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
23 of 105
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
WebUI
3D Sensor Appliance
3D System
Software MySQL
3rd
Party Software Applications
Linux-Derived Operating System
NTP
Server
EMAIL
Server
SNMP
Server
DNS
Server
Syslog
Server
RUA
RNA
IPS
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
WebUI
3D Sensor Appliance
3D System
Software MySQL
3rd
Party Software Applications
Linux-Derived Operating System
NTP
Server
EMAIL
Server
SNMP
Server
DNS
Server
Syslog
Server
RUA
RNA
IPS
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Network
Asset
Environment Component
(required)
Environment Component
(optional)
TOE
Component
Product Component
Not in TOE
Figure 2: Sourcefire 3D System using a stand-alone 3D Sensor with IPS
The Sourcefire application software is physically installed on the Sourcefire appliances that run
Linux-derived operating systems. As such, its physical interfaces are based on and limited by
services provided by the hardware. The application software uses process, disk, and memory
management services of the appliance hardware and the operating system to execute and
manage itself. The application software also uses network services provided by the appliance
hardware and operating system: to access network traffic, including monitoring target
networks; for communication between the 3D Sensor with IPS and Defense Center; and for
the web-based user interfaces (3D Sensor with IPS and Defense Center GUIs).
The Operational Environment of the TOE includes:
 The web browsers that are used for the management interfaces of the TOE.
 The network(s) used for communications between the TOE components, which must
be protected from unauthorized access, and separate from the network that is
monitored by the TOE.
 The network(s) that are to be monitored.
 Network Authentication Services.
 A trusted DNS Server.
 An NTP Server for reliable time.
 An Email Server for administrator alert notifications and warnings.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
24 of 105
 An optional external Syslog Server for administrator alert notifications and warnings.
 An optional SNMP Trap Server for administrator alert notifications.
 An optional external authentication server (LDAP or RADIUS).
As indicated in the figures above, the TOE can consist of a single 3D Sensor with IPS or any
number of 3D Sensors with IPS combined with a single Defense Center.
1.4.7.1 Included in the TOE:
The evaluated configuration includes the following:
 The Sourcefire 3D Sensor, Version 4.8.2.1 (SEU 259)licensed to use the Sourcefire
Intrusion Prevention System (IPS)
 The Sourcefire Defense Center, Version 4.8.2.1 (SEU 259)
All typical deployments as described in Chapter 1 of [SENS-INSTALL] are permitted in the
evaluated configuration of the TOE.
The multi-site environment deployment as described in [SENS-INSTALL] is allowed in the
evaluated configuration. To secure the data in a multi-site environment deployment, the 3D
Sensors and Defense Center must be isolated from unprotected networks by transmitting the
data stream from the 3D Sensors over a VPN or with some other secure tunneling protocol.
Testing included configurations that:
 Test the 3D Sensor with IPS for each category of appliance: SFLinux v4.8, SBLinux
v4.8 and SVLinux v4.8.
 Test a stand-alone 3D Sensor with IPS configuration.
 Test one or more 3D Sensors with IPS managed by a single Defense Center.
 Test both inline and passive deployments of the 3D Sensors with IPS.
The following TOE components were used in testing:
 DC3000 (SFLinux)
 3D2500 sensor (SFLinux)
 3D5800 sensor (SBLinux)
 3D9800 sensor (SVLinux)
Because of their identical functionality and behavior only one 3D Sensor appliance from each
category of 3D Sensors was used in testing.
Note also that the sensors were located in the same physical location as the Defense Center
in the testing scenarios. This is equivalent to deployment scenarios where the sensors are in
multiple physical locations because the same SSL-encrypted communications channel is used
between the sensors and Defense Center, except that it is transmitted over a VPN in the multi-
site scenario.
1.4.7.2 Excluded from the TOE:
The following product components and functionality are not included in the scope of the
evaluation:
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
25 of 105
 Real-Time Network Awareness (RNA) – RNA is a separate product that requires
additional licensing
o Vulnerability Assessment (VA) - VA requires integration with Nessus and NMAP
and is only applicable with RNA license
o Network Behavior Analysis (NBA) – NBA requires an RNA license
o Collection of data from NetFlow devices– requires Cisco NetFlow and an RNA
license
o Adaptive IPS – uses information from RNA
 Real-Time User Awareness (RUA) – RUA is a separate product that requires additional
licensing
o NAC and Network Usage Control (NUC) – requires RUA license
 Intrusion Agents - Requires an existing installation of Snort
 Estreamer Application Programming Interface (API) - Estreamer integration requires
custom programming
 Security Enhancement Updates (SEU) – The updates may include binary updates to
the TOE software, which will take the product out of the evaluated configuration when
installed
 A Master Defense Center (MDC) – requires a multiple Defense Center configuration
 The High Availability feature - requires a multiple Defense Center configuration
 IPS for Crossbeam Systems Security Switches (software-only sensors)
 Switched Stack System Interconnect (“stack”) configuration (installation of an additional
chassis using a stack cable)
 Integration with and remediation of traffic to firewalls, including:
o Integration with Cisco PIX and Checkpoint firewalls
 Integration with and remediation of traffic to external 3rd
-party products, including:
o Sending alerts through trouble ticket systems
o Interfaces with the Shavlik patch management system
 The Stream 4 data stream preprocessor (Only the Stream 5 preprocessor is allowed in
the CC evaluated configuration and was used for CC testing)
Important: The customer must assume the risk of enabling excluded functionality that was not
part of the evaluation and has not been tested and validated.
The following are Operational Environment components, which are excluded from the scope of
the evaluation:
 The Web Browser for the Defense Center and 3D Sensor with IPS Management
Interfaces. Only the following are supported for Sourcefire 3D System Version 4.8.2.1:
o Firefox Version (Minimum) 2.x
o Microsoft Internet Explorer Version 6.0 with Service Pack 2
o Microsoft Internet Explorer Version 7.0
 The protected network(s) used for communications between the TOE components
 The network(s) that are to be monitored
 Network Authentication Services
 A trusted DNS Server
 An external NTP Server
 An external Email Server
 An optional Syslog Server
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
26 of 105
 An optional SNMP Trap Server
 An optional LDAP or RADIUS Authentication Server
1.4.8 Logical Scope of the TOE
The logical boundaries of the TOE are divided into two groups, one related to the
administration and security of the system (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, System Data Analysis
and System Data Review, Availability and Loss).
The TOE provides the following security functionality:
1.4.8.1 Security Audit
The TOE is able to audit the use of the administration/management functions of the IDS. This
audit is separate from the IDS functionality (recording network traffic), and relates specifically
to the management functions of the TOE. This function records attempts to access the system
itself, such as successful and failed authentication, as well as the actions taken by TOE users
once they are authenticated. Auditable actions include changes to the IDS rules and
viewing/modifying the audit records of both the system access and the IDS event log.
The audit data is protected by the access control mechanisms of the database and OS of the
appliances and by the TOE management interface. Only users with the Administrator Role
have access to the audit records. Users having the Administrator Role can view and sort the
audit records. Suppression lists may be configured during installation and maintenance to limit
the events recorded.
When the available audit storage is exhausted, the TOE automatically overwrites the oldest
audit events. This ensures that the availability of the most recent audit events is limited only by
the size of the audit trail.
Note: The administrator must perform periodic backups of the audit data (via the WebUI
backup function) to prevent loss of data.
Security Audit depends on the Operational Environment to provide reliable time for the audit
records. It depends on an Email Server in the Operational Environment to provide warnings to
administrators when the audit records are overwritten. It also depends on the Operational
Environment to provide a secure communications path between the TOE and the external
servers.
1.4.8.2 Identification and Authentication
The TOE requires all users to provide unique identification and authentication data before any
access to the system is granted. User identification and authentication is done by the TSF
though username/password authentication or optionally by an external authentication server
for configurations that include a Defense Center.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
27 of 105
All authorized TOE users must have a user account with security attributes that control the
user‟s access to TSF data and management functions. These security attributes include user
name, password, and level(s) of authorization (roles) for TOE users.
Identification and Authentication depends on the Operational Environment to provide an
external authentication server if that feature is configured. It also depends on the Operational
Environment to provide a secure communications path between the TOE and the external
authentication server.
1.4.8.3 Security Management
The TOE provides a web-based (using HTTPS) management interface for all run-time TOE
administration, including the IDS rule sets, user accounts and roles, and audit functions. The
ability to manage various security attributes, system parameters and all TSF data is controlled
and limited to those users who have been assigned the appropriate administrative role.
The TOE also provides a command line interface the use of which must be restricted. This
interface is only used for Security Management when creating or modifying Audit Suppression
Lists.
Security management relies on a management console in the Operational Environment with a
properly configured Web Browser to support the web-based management interfaces.
1.4.8.4 Protection of Security Functions
The TOE ensures that data transmitted between separate parts of the TOE are protected from
disclosure or modification. This protection is ensured by transmission of data between the
TOE Components over a secure, SSL-encrypted TCP tunnel.
Note: The cryptography used in this product has not been FIPS certified nor has it been
analyzed or tested to conform to cryptographic standards during this evaluation. All
cryptography has only been asserted as tested by the vendor.
1.4.8.5 TOE Access Functions
The TOE enhances the functionality of user session establishment by being able to display a
warning banner regarding unauthorized use of the TOE when a user attempts to login.
1.4.8.6 System Data Collection
The TOE has the ability to set rules to govern the collection of data regarding potential
intrusions. While the TOE contains 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 TOE administrators complete control over the types of traffic that will be
monitored.
System Data Collection depends on the Operational Environment to provide reliable
timestamps for the collected data records. It also depends on the Operational Environment to
provide a secure communications path between the TOE and the external time server.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
28 of 105
1.4.8.7 System Data Analysis
To analyze the data collected by the 3D Sensors with IPS, the TOE uses signatures,
decoders, and preprocessors. Signatures are patterns of traffic that can be used to detect
potential attacks or exploits. Since many attacks or exploits require several network
connections to work, the IDS also provides the ability to detect these more complex patterns
through decoders and preprocessors that are included in the TOE. The TOE embodies
signatures, decoders, and preprocessors in rules that can be designed and exercised by the
TOE.
The TOE administrators can manage the signature identification capabilities by adding and
editing rules to respond to the latest exploits. In addition, based upon results of analysis, the
TOE administrators can trigger alarms for the notification of a problem.
System Data Analysis relies on the Operational Environment to support the notification of
administrators via email and (optionally) SNMP and syslog alarms. It also depends on the
Operational Environment to provide a secure communications path between the TOE and the
external servers.
1.4.8.8 System Data Review, Availability and Loss
IDS event logs can only be viewed by authorized TOE users (users with the Administrator or
Intrusion Event Analyst Roles). The data stores of the raw collection data are constantly
monitored and if they become too full, new records will replace the oldest records to prevent
active/current data loss.
Note: The administrator must perform periodic backups of the event data (via the WebUI
backup function) to prevent loss of data.
System Data Review Availability and Loss depends on an Email Server in the Environment to
provide warnings to administrators when the data records are overwritten. It also depends on
the Operational Environment to provide a secure communications path between the TOE and
the external email server.
1.4.8.9 Excluded Functionality
The following product functionality is not included in the scope of the evaluation:
 Functionality provided by the Real-Time Network Awareness (RNA) feature which
includes:
o Vulnerability Assessment (VA) (Nessus and NMAP integration)
o Network Behavior Analysis (NBA)
o NetFlow Functionality
o Adaptive IPS
o Compliance Policies
 Functionality provided by the Real-Time User Awareness (RUA) feature which
includes:
o NAC and Network Usage Control (NUC)
 Intrusion Agents - Requires an existing installation of Snort
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
29 of 105
 Functionality provided by custom programming via the Estreamer Application
Programming Interface (API)
 Security Enhancement Updates (SEU)
 Functionality provided by a Master Defense Center
 The High Availability feature provided by redundant Defense Centers
 Integration with and remediation of traffic to firewalls, including:
o Integration with Cisco PIX and Checkpoint firewalls
 Integration with and remediation of traffic to external 3rd
-party products, including:
o Interfaces with the Shavlik patch management system
o Sending alerts through trouble ticket systems
 IPS for Crossbeam Systems Security Switches (software-only sensors)
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
30 of 105
2 Conformance Claims
2.1 Common Criteria Conformance
The TOE is Part 2 extended, Part 3 conformant, and meets the requirements of Evaluation
Assurance Level (EAL) 2 augmented with ALC_FLR.2 from the Common Criteria Version 3.1
R2. This Security Target conforms to the Common Criteria Version 3.1 R2.
2.2 Protection Profile Claim
This ST claims Demonstrable Compliance to U.S. Government Protection Profile Intrusion
Detection System System For Basic Robustness Environments, Version 1.7, July 25, 2007.
(IDS System PP).
Demonstrable Compliance in CC v3.1 R2 is defined as follows:
demonstrable conformance: there is no subset-superset type relation between the PP
and the ST. The PP and the ST may contain entirely different statements that discuss
different entities, use different concepts etc. However, the ST shall contain a rationale on
why the ST is considered to be “equivalent or more restrictive” than the PP (see Section
D.3). Demonstrable conformance allows a PP author to describe a common security
problem to be solved and provide generic guidelines to the requirements necessary for its
resolution, in the knowledge that there is likely to be more than one way of specifying a
resolution. Demonstrable conformance is also suitable for a TOE type where several
similar PPs already exist (or likely to exist in the future), thus allowing the ST author to
claim conformance to all these PPs simultaneously, thereby saving work. (Paragraph. 436
of CC Part 1)
Paragraph 445 of CC Part 1 provides additional details on what is required for
demonstrable compliance:
Security problem definition:
The conformance rationale in the ST shall demonstrate that the security problem definition
in the ST is equivalent (or more restrictive) than the security problem definition in the PP.
This means that:
 All TOEs that would meet the security problem definition in the ST also meet the
security problem definition in the PP;
 All operational environments that would meet the security problem definition in the
PP would also meet the security problem definition in the ST.
This Security Target includes all of the threats, organizational security policies, and
assumption statements described in the PP, verbatim. Therefore, the security problem
definition in this ST is equivalent to the security problem definition in the PP.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
31 of 105
Security objectives:
The conformance rationale in the ST shall demonstrate that the security objectives in the
ST is equivalent (or more restrictive) than the security objectives in the PP. This means
that:
 All TOEs that would meet the security objectives for the TOE in the ST also meet
the security objectives for the TOE in the PP;
 All operational environments that would meet the security objectives for the
operational environment in the PP would also meet the security objectives for the
operational environment in the ST.
This Security Target includes all of the TOE Security Objectives from the PP. In addition
the PP Operational Environment Objectives: OE.AUDIT PROTECTION and
OE.AUDIT_SORT have been made TOE objectives: O.AUDIT_PROTECTION,
O.AUDIT_SORT, since these security objectives are met by the functionality of the TOE
itself. Therefore, the ST is more restrictive than the PP in the case of the TOE objectives.
This Security Target includes all of the Operational Environment Objectives of the PP with
the following exceptions:
OE.AUDIT PROTECTION and OE.AUDIT_SORT have been made TOE Objectives as
noted above.
OE.ALARMS has been added to cover the functionality of an Email Server in the
environment to send an alarm when a possible intrusion occurs. Based on the following
PP requirement, the ST can define where the alarm's destination is located:
“IDS_RCT.1.1 The System shall send an alarm to [assignment: alarm destination] and
take [assignment: appropriate actions] when an intrusion is detected. (EXT)
IDS_RCT.1.1
Application Note: There must be an alarm, though the ST should refine the nature of the
alarm and define its target (e.g., administrator console, audit log). The Analyser may
optionally perform other actions when intrusions are detected; these actions should be
defined in the ST. An intrusion in this requirement applies to any conclusions reached
by the analyser related to past, present, and future intrusions or intrusion potential.”
OE.XAUTH has been added to cover the functionality of an external authentication
service that can be invoked by the TOE to support user authentication. The PP does
not define the authentication mechanism(s) required. Since the external user
authentication service is invoked by the TOE, this objective is equivalent to the
functionality required by the PP.
OE.PROTECTCOMM has been added to state that the Operational Environment must
provide secure communications between the TOE and the servers in the environment
that support the security functionality of the TOE. This objective is the equivalent of a
sub-clause that could be added to or assumed from OE.TIME, OE.ALARMS and
OE.XAUTH stating that the services provided by the Operational Environment are
secure and reliable.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
32 of 105
The security objectives in this ST are therefore equivalent to or more restrictive than the
security objective in the PP.
Security requirements:
The ST shall contain all SFRs and SARs in the PP, but may claim additional or
hierarchically stronger SFRs and SARs. The completion of operations in the ST must be
consistent with that in the PP; either the same completion will be used in the ST as that in
the PP or one that makes the requirement more restrictive (the rules of refinement apply).
This Security Target includes all of the Security Assurance Requirements from the PP.
This Security Target includes all of the Security Functional Requirement from the PP with
the following modifications:
FIA_UAU.1 has been modified into the explicitly stated requirement FIA_UAU_EXT.1
by adding the text “either by the TSF or by an authentication service in the Operational
Environment invoked by the TSF”. This modification was necessary to provide for the
use of an authentication service in the environment that is invoked by the TOE.
The completion of the assignments in FMT_MOF.1 and FMT_SMR.1 differ from those
in the PP since the TOE does not maintain the role: authorized System administrator.
The assignments have been made more restrictive to include only those administrative
roles that are maintained by the TOE.
FMT_SMF.1 has been added to satisfy the dependencies of FMT_MOF.1 and
FMT_MTD.1.
FTA_TAB.1 has been added to reflect the TOE‟s functionality.
Those SFRs exclusively related to authenticating or communicating TSF data with
external IT products, specifically: FIA_AFL.1, FPT_ITA.1, FPT_ITC.1, and FPT_ITI.2,
have been replaced by FPT_ITT.1 through the precedence of PD-0097. FPT_ITT.1 has
been refined to specify the specific mechanisms used by the TOE for secure internal
data transfer.
FPT_STM.1 was deleted since reliable timestamps are provided by the Operational
Environment (OE.TIME).
These changes have been approved by NIAP in the PDs: PD-0151: Acceptable
Demonstrable Assurance for the IDS System PP v1.7 (BR) and PD-0152: Internal
Inconsistency within the IDS System PP regarding FPT_STM.
Therefore, the security requirements in this ST are equivalent to or more restrictive than
the security requirements in the PP.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
33 of 105
2.3 Package Claim
This ST claims conformance to the assurance requirements package: Evaluation Assurance
Level (EAL) 2 augmented with ALC_FLR.2.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
34 of 105
3 Security Problem Definition
The IDS System PP provides the following policies, threats and assumptions about the TOE.
3.1 Threats
The following are threats identified for the TOE and the IT System the TOE monitors. The TOE
itself has threats and the TOE is 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. This section identifies the threats applicable to the IDS System PP as
specified in the Protection Profile, verbatim.
Table 3-1: TOE Threats
TOE Threats
1 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.
2 T.COMDIS An unauthorized user may attempt to disclose the data collected and
produced by the TOE by bypassing a security mechanism.
3 T.LOSSOF An unauthorized user may attempt to remove or destroy data collected and
produced by the TOE.
4 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.
5 T.PRIVIL An unauthorized user may gain access to the TOE and exploit system
privileges to gain access to TOE security functions and data.
6 T.IMPCON An unauthorized user may inappropriately change the configuration of the
TOE causing potential intrusions to go undetected.
7 T.INFLUX An unauthorized user may cause malfunction of the TOE by creating an
influx of data that the TOE cannot handle.
8 T.FACCNT Unauthorized attempts to access TOE data or security functions may go
undetected.
The following table identifies threats to the IT System that may be indicative of vulnerabilities
in or misuse of IT resources.
Table 3-2: IT System Threats
IT System Threats
9 T.SCNCFG Improper security configuration settings may exist in the IT System the
TOE monitors.
10 T.SCNMLC Users could execute malicious code on an IT System that the TOE
monitors which causes modification of the protected IT System data or
undermines the IT System security functions.
11 T.SCNVUL Vulnerabilities may exist in the IT System the TOE monitors.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
35 of 105
IT System Threats
12 T.FALACT The TOE may fail to react to identified or suspected vulnerabilities or
inappropriate activity.
13 T.FALREC The TOE may fail to recognize vulnerabilities or inappropriate activity
based on IDS data received from each data source.
14 T.FALASC The TOE may fail to identify vulnerabilities or inappropriate activity based
on association of IDS data received from all data sources.
15 T.MISUSE Unauthorized accesses and activity indicative of misuse may occur on an
IT System the TOE monitors.
16 T.INADVE Inadvertent activity and access may occur on an IT System the TOE
monitors.
17 T.MISACT Malicious activity, such as introductions of Trojan horses and viruses, may
occur on an IT System the TOE monitors.
3.2 Organizational Security Policies (OSPs)
An organizational security policy is a set of rules, practices, and procedures imposed by an
organization to address its security needs. This section identifies the organizational security
policies applicable to the IDS System PP as specified in the Protection Profile, verbatim.
Table 3-3: Organizational Security Policies
Organizational Security Policies
1 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.
2 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.
3 P.MANAGE The TOE shall only be managed by authorized users.
4 P.ACCESS All data collected and produced by the TOE shall only be used for authorized
purposes.
5 P.ACCACT Users of the TOE shall be accountable for their actions within the IDS.
6 P.INTGTY Data collected and produced by the TOE shall be protected from
modification.
7 P.PROTCT The TOE shall be protected from unauthorized accesses and disruptions of
TOE data and functions.
3.3 Assumptions
This section contains assumptions regarding the security environment and the intended usage
of the TOE applicable to the IDS System PP as specified in the Protection Profile, verbatim.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
36 of 105
Table 3-4: TOE Usage Assumptions
TOE Intended Usage Assumptions
1 A.ACCESS The TOE has access to all the IT System data it needs to perform its
functions.
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.
3 A.ASCOPE The TOE is appropriately scalable to the IT System the TOE monitors.
Table 3-5: TOE Physical Assumptions
TOE Physical Assumptions
4 A.PROTCT The TOE hardware and software critical to security policy enforcement will be
protected from unauthorized physical modification.
5 A.LOCATE The processing resources of the TOE will be located within controlled access
facilities, which will prevent unauthorized physical access.
Table 3-6: TOE Personnel Assumptions
TOE Personnel Assumptions
6 A.MANAGE There will be one or more competent individuals assigned to manage the
TOE and the security of the information it contains.
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.
8 A.NOTRST The TOE can only be accessed by authorized users.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
37 of 105
4 Security Objectives
This section defines the security objectives of the TOE and its supporting environment. These
security objectives, categorized as IT security objectives for either the TOE or its environment
are taken from the IDS System PP as specified in the Protection Profile, verbatim, with the
following exceptions:
 OE.AUDIT PROTECTION and OE.AUDIT_SORT have been made TOE objectives:
O.AUDIT_PROTECTION and O.AUDIT_SORT, since these security objectives are met
by the functionality of the TOE itself.
 OE.ALARMS has been added to cover the functionality of an Email Server in the
environment to send an alarm when a possible intrusion occurs.
 OE.XAUTH has been added to cover the functionality of an external authentication
service that can be invoked by the TOE to support user authentication.
 OE.PROTECTCOMM has been added to state that the Operational Environment must
provide secure communications between the TOE and the servers in the environment
that support the security functionality of the TOE.
4.1.1 Security Objectives for the TOE
The following are the TOE security objectives:
Table 4-1: TOE Security Objectives
TOE Security Objectives
1 O.PROTCT The TOE must protect itself from unauthorized modifications and
access to its functions and data.
2 O.IDSCAN The scanner must collect and store static configuration information that
might be indicative of the potential for a future intrusion or the
occurrence of a past intrusion of an IT System.
3 O.IDSENS The sensor must collect and store information about all events that are
indicative of inappropriate activity that may have resulted from misuse,
access, or malicious activity of IT System assets and the IDS.
4 O.IDANLZ The analyzer must accept data from IDS sensors or IDS scanners and
then apply analytical processes and information to derive conclusions
about intrusions (past, present, or future).
5 O.RESPON The TOE must respond appropriately to analytical conclusions.
6 O.EADMIN The TOE must include a set of functions that allow effective
management of its functions and data.
7 O.ACCESS The TOE must allow authorized users to access only appropriate TOE
functions and data.
8 O.IDAUTH The TOE must be able to identify and authenticate users prior to
allowing access to TOE functions and data.
9 O.OFLOWS The TOE must appropriately handle potential audit and system data
storage overflows.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
38 of 105
TOE Security Objectives
10 O.AUDITS The TOE must record audit records for data accesses and use of the
system functions.
11 O.INTEGR The TOE must ensure the integrity of all audit and system data.
12 O.EXPORT When any IDS component makes its data available to another IDS
component, the TOE will ensure the confidentiality of the system data.
13 O.AUDIT_PROTECTION The TOE must provide the capability to protect audit information.
14 O.AUDIT_SORT The TOE must provide the capability to sort the audit information.
4.1.2 Security Objectives for the Operational Environment
The TOE‟s operating environment must satisfy the following objectives.
Table 4-2: Security Objectives for the Operational Environment
Security Objectives for the Operational Environment
16 OE.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.
17 OE.PHYCAL Those responsible for the TOE must ensure that those parts of the
TOE critical to security policy are protected from any physical attack.
18 OE.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.
19 OE.PERSON Personnel working as authorized administrators shall be carefully
selected and trained for proper operation of the system.
20 OE.INTROP The TOE is interoperable with the IT System it monitors.
21 OE.TIME The Operational Environment will provide reliable timestamps to the
TOE.
22 OE.ALARMS The Operational Environment will provide mechanisms to notify
responsible personnel of a possible problem.
23 OE.PROTECTCOMM The Operational Environment must provide a mechanism to establish
a trusted communications path which provides for the protection of
the data from modification or disclosure while being exchanged
between TOE components and external entities.
24 OE.XAUTH * The Operational Environment must provide an authentication service
for user identification and authentication that can be invoked by the
TSF to control a user‟s logical access to the TOE.
* Note: OE.XAUTH is only applicable when the TOE is configured to use an external LDAP or
RADIUS authentication service.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
39 of 105
4.2 Security Objectives Rationale
This section provides the rationale for the selection of the IT security requirements, objectives,
assumptions, and threats. In particular, it shows that the IT security requirements are suitable
to meet the security objectives, which in turn are shown to be suitable to cover all aspects of
the TOE security environment.
4.2.1 Rationale for the IT Security Objectives
This section provides a rationale for the existence of each assumption, threat, and policy
statement that compose the IDS System PP. Table 4-3: Security Objectives and Security
Environment Mapping demonstrates the mapping between the assumptions, threats, and
policies to the security objectives is complete. The following discussion provides detailed
evidence of coverage for each assumption, threat, and policy.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
40 of 105
Table 4-3: Security Objectives and Security Environment Mapping
O.PROTCT
O.IDSCAN
O.IDSENS
O.IDANLZ
O.RESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
O.EXPORT
O.AUDIT_SORT
O.AUDIT_PROTECTION
OE.INSTAL
OE.PHYCAL
OE.CREDEN
OE.PERSON
OE.INTROP
OE.ALARMS
OE.TIME
OE.PROTECTCOMM
OE.XAUTH
A.ACCESS X
A.DYNMIC X X
A.ASCOPE X
A.PROTCT X
A.LOCATE X
A.MANAGE X
A.NOEVIL X X X
A.NOTRST X X
T.COMINT X X X X X X
T.COMDIS X X X X X X
T.LOSSOF X X X X X X
T.NOHALT X X X X X X X
T.PRIVIL X X X X X
T.IMPCON X X X X X X
T.INFLUX X X X
T.FACCNT X
T.SCNCFG X
T.SCNMLC X
T.SCNVUL X
T.FALACT X X X
T.FALREC X
T.FALASC X
T.MISUSE X
T.INADVE X
T.MISACT X
P.DETECT X X X X X
P.ANALYZ X
P.MANAGE X X X X X X X X X
P.ACCESS X X X X X X X
P.ACCACT X X X X X X
P.INTGTY X
P.PROTCT X X
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
41 of 105
A.ACCESS: The TOE has access to all the IT System data it needs to perform its functions.
The OE.INTROP objective ensures the TOE has the needed access.
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 OE.INTROP objective ensures the TOE has the proper access to the IT System.
The OE.PERSON objective ensures that the TOE will be managed appropriately.
A.ASCOPE: The TOE is appropriately scalable to the IT System the TOE monitors.
The OE.INTROP objective ensures the TOE has the necessary interactions with the IT
System it monitors.
A.PROTCT: The TOE hardware and software critical to security policy enforcement will be
protected from unauthorized physical modification.
The OE.PHYCAL provides for the physical protection of the TOE hardware and
software.
A.LOCATE: The processing resources of the TOE will be located within controlled access
facilities, which will prevent unauthorized physical access.
The OE.PHYCAL provides for the physical protection of the TOE.
A.MANAGE: There will be one or more competent individuals assigned to manage the TOE
and the security of the information it contains.
The OE.PERSON objective ensures all authorized administrators are qualified and
trained to manage the TOE.
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 OE.INSTAL objective ensures that the TOE is properly installed and operated and
the OE.PHYCAL objective provides for physical protection of the TOE by authorized
administrators. The OE.CREDEN objective supports this assumption by requiring
protection of all authentication data.
A.NOTRST: The TOE can only be accessed by authorized users.
The OE.PHYCAL objective provides for physical protection of the TOE against
unauthorized access. The OE.CREDEN objective supports this assumption by
requiring protection of all authentication data.
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 and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives 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. OE.PROTECTCOMM provides
for secure communications between the TOE and the external authentication server.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
42 of 105
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 and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives 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.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external authentication server.
T.LOSSOF: An unauthorized user may attempt to remove or destroy data collected and
produced by the TOE.
The O.IDAUTH and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives 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. OE.PROTECTCOMM provides
for secure communications between the TOE and the external authentication server.
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.
The O.IDAUTH and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives by only permitting authorized users to access TOE data. The
O.IDSCAN, O.IDSENS, and O.IDANLZ objectives address this threat by requiring the
TOE to collect and analyze system data, which includes attempts to halt the TOE.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external authentication server.
T.PRIVIL: An unauthorized user may gain access to the TOE and exploit system privileges to
gain access to TOE security functions and data.
The O.IDAUTH and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives by only permitting authorized users to access TOE data. The
O.PROTCT objective addresses this threat by providing TOE self-protection.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external authentication server.
T.IMPCON: An unauthorized user may inappropriately change the configuration of the TOE
causing potential intrusions to go undetected.
The OE.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 and OE.XAUTH
objectives provide for authentication of users prior to any TOE data access. The
O.ACCESS objective builds upon the O.IDAUTH and OE.XAUTH objectives by only
permitting authorized users to access TOE data. OE.PROTECTCOMM provides for
secure communications between the TOE and the external authentication server.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
43 of 105
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 that the TOE must handle
data storage overflows. OE.ALARMS provides Operational Environment support to
send warnings when the audit and/or collected system data is about to be overwritten.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external server that provides the warnings.
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.
T.SCNCFG: Improper security configuration settings may exist in the IT System the
TOE monitors.
The O.IDSCAN objective counters this threat by requiring a TOE, which contains a
scanner, collect and store static configuration information that might be indicative of a
configuration setting change. The ST will state whether this threat must be addressed
by a scanner.
T.SCNMLC: Users could execute malicious code on an IT System that the TOE monitors
which causes modification of the protected IT System data or undermines the IT System
security functions.
The O.IDSCAN objective counters this threat by requiring a TOE, which contains a
scanner, collect and store static configuration information that might be indicative of
malicious code. The ST will state whether this threat must be addressed by a scanner.
T.SCNVUL: Vulnerabilities may exist in the IT System the TOE monitors.
The O.IDSCAN objective counters this threat by requiring a TOE, which contains a
scanner, collect and store static configuration information that might be indicative of a
vulnerability. The ST will state whether this threat must be addressed by a scanner.
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. The OE.ALARMS objective provides
Operational Environment support mechanisms for alarms to notify responsible
personnel of possible intrusions. OE.PROTECTCOMM provides for secure
communications between the TOE and the external servers that provide the alarm
mechanisms.
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.
T.FALASC: The TOE may fail to identify vulnerabilities or inappropriate activity based on
association of IDS data received from all data sources.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
44 of 105
The O.IDANLZ objective provides the function that the TOE will recognize
vulnerabilities or inappropriate activity from multiple data sources.
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.
T.INADVE: Inadvertent activity and access may occur on an IT System the TOE monitors.
The O.AUDITS and O.IDSENS objectives address this threat by requiring a TOE that
contains a sensor, collect audit and sensor data.
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.
P.DETECT: Static configuration information that might be indicative of the potential for a future
intrusion or the occurrence of a past intrusion of an IT System or events that are indicative of
inappropriate activity that may have resulted from misuse, access, or malicious activity of IT
System assets must be collected.
The O.AUDITS, O.IDSENS, and O.IDSCAN objectives address this policy by requiring
collection of audit, sensor, and scanner data. OE.TIME supports the data collection by
providing reliable timestamps for the collected audit, sensor, and scanner data.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external time server.
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 are applied to data collected
from sensors and scanners.
P.MANAGE: The TOE shall only be managed by authorized users.
The OE.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 OE.INSTAL objective supports the OE.PERSON objective by ensuring
administrators follow all provided documentation and maintain the security policy. The
O.IDAUTH and OE.XAUTH objectives provide for authentication of users prior to any
TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives by only permitting authorized users to access TOE data. The
OE.CREDEN objective requires administrators to protect all authentication data. The
O.PROTCT objective addresses this policy by providing TOE self-protection.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external authentication server.
P.ACCESS: All data collected and produced by the TOE shall only be used for authorized
purposes.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
45 of 105
The O.IDAUTH and OE.XAUTH objectives provide for authentication of users prior to
any TOE data access. The O.ACCESS objective builds upon the O.IDAUTH and
OE.XAUTH objectives by only permitting authorized users to access TOE data. The
O.PROTCT objective addresses this policy by providing TOE self-protection.
O.AUDIT_PROTECTION provides for the protection of the audit data from
unauthorized deletion and modification. OE.ALARMS provides Operational
Environment support to send warnings when the audit and/or collected system data is
about to be overwritten. OE.PROTECTCOMM provides for secure communications
between the TOE and the external server that provides the warnings and between the
TOE and the external authentication server.
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 and OE.XAUTH objectives
support this policy by ensuring each user is uniquely identified and authenticated.
OE.TIME supports the generation of audit data by providing reliable timestamps.
OE.PROTECTCOMM provides for secure communications between the TOE and the
external time server and between the TOE and the external authentication server.
O.AUDIT_SORT supports the interpretation of the audit records by sorting the data.
P.INTGTY: Data collected and produced by the TOE shall be protected from modification.
The O.INTEGR objective ensures the protection of data from modification.
P.PROTCT: The TOE shall be protected from unauthorized accesses and disruptions of TOE
data and functions.
The O.OFLOWS objective implements this policy by requiring the TOE handle
disruptions. The OE.PHYCAL objective protects the TOE from unauthorized physical
modifications.
4.2.2 Rationale for the Security Objectives for the Environment
The purpose for 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, interoperability requirements on the TOE and for
external components that support the TOE objectives. Together with the IT security objectives,
these environmental objectives provide a complete description of the responsibilities of TOE in
meeting security needs.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
46 of 105
5 Extended Components Definition
All of the components defined below have been taken from the U.S. Government Protection
Profile Intrusion Detection System System for Basic Robustness Environments, Version 1.7,
July 25, 2007 (IDS System PP), verbatim, except for FIA_UAU_EXT.1, which has been
modeled on FIA_UAU.1 from Part 2 of the CC Version 3.1 R2. The extended components are
denoted by adding “_EXT” in the component name.
Table 5-1: Extended Components
Item SFR ID SFR Title
1 FIA_UAU_EXT.1 Timing of authentication
2 IDS_SDC_EXT.1 System Data Collection
3 IDS_ANL_EXT.1 Analyzer analysis
4 IDS_RCT_EXT.1 Analyzer react
5 IDS_RDR_EXT.1 Restricted Data Review
6 IDS_STG_EXT.1 Guarantee of System Data Availability
7 IDS_STG_EXT.2 Prevention of System data loss
5.1 FIA_UAU_EXT.1 Timing of authentication
5.1.1 Class FIA: Identification and authentication
See Section 12 of the Common Criteria for Information Technology Security Evaluation Part 2:
Security functional components September 2007 Version 3.1 Revision 2.
5.1.2 Family: User authentication (FIA_UAU)
5.1.3 Family Behavior
This family defines the types of user authentication mechanisms supported by the TSF. This
family also defines the required attributes on which the user authentication mechanisms must
be based.
5.1.4 Management
The following actions could be considered for the management functions in FMT:
 Management of the authentication data by an administrator
 Management of the authentication data by the user associated with this data
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
47 of 105
5.1.5 Audit
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
 Minimal: Unsuccessful use of the authentication mechanism
 Basic: All use of the authentication mechanism
5.1.6 Definition
FIA_UAU_EXT.1 Timing of authentication
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU_EXT.1.1 The TSF shall allow [assignment: list of TSF mediated actions] on
behalf of the user to be performed before the user is authenticated.
FIA_UAU_EXT.1.2 The TSF shall require each user to be successfully authenticated either
by the TSF or by an authentication service in the Operational Environment
invoked by the TSF before allowing any other TSF-mediated actions on behalf
of that user.
5.1.7 Rationale
FIA_UAU_EXT.1 is modeled closely on the standard component FIA_UAU.1: Timing of
authentication. FIA_UAU_EXT.1 needed to be defined as an extended component because
the functionality of the standard component was extended by adding the text “either by the
TSF or by an authentication service in the Operational Environment invoked by the TSF”.
5.2 IDS_SDC_EXT.1 System Data Collection
5.2.1 Class IDS: Intrusion Detection System
5.2.2 Family: System Data Collection (IDS_SDC)
5.2.3 Family Behavior
This family defines the requirements for the TSF to be able to collect information from targeted
IT System resources.
5.2.4 Management
The following actions could be considered for the management functions in FMT:
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
48 of 105
 the management (addition, removal, or modification) of specific IDS information that
will be obtained from targeted IT System resource(s);
 the management (addition, removal, or modification) of specific targeted IT System
resources.
5.2.5 Audit
There are no auditable events foreseen.
5.2.6 Definition
IDS_SDC_EXT.1 System Data Collection
Hierarchical to: No other components
Dependencies: FPT_STM.1 Reliable time stamps
IDS_SDC_EXT.1.1 The TSF shall be able to collect the following information from the
targeted IT System resource(s): [selection: Start-up and shutdown,
identification and authentication events, data accesses, service requests,
network traffic, security configuration changes, data introduction,
detected malicious code, access control configuration, service
configuration, authentication configuration, accountability policy
configuration, detected known vulnerabilities]; and [assignment: other
specifically defined events].
IDS_SDC_EXT.1.2 At a minimum, the TSF shall collect and record the following information
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) The additional information specified in the Details column of Table 5-2: System Events.
Table 5-2: System Events
Component Event Details
IDS_SDC.1 Start-up and shutdown none
IDS_SDC.1 Identification and authentication
events
User identity, location, source address, destination
address
IDS_SDC.1 Data accesses Object IDS, requested access, source address,
destination address
IDS_SDC.1 Service Requests Specific service, source address,
destination address
IDS_SDC.1 Network traffic Protocol, source address, destination address
IDS_SDC.1 Security configuration changes Source address, destination address
IDS_SDC.1 Data introduction Object IDS, location of object, source address,
destination address
IDS_SDC.1 Start-up and shutdown of audit
functions
none
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
49 of 105
Component Event Details
IDS_SDC.1 Detected malicious code Location, identification of code
IDS_SDC.1 Access control configuration Location, access settings
IDS_SDC.1 Service configuration Service identification (name or port), interface,
protocols
IDS_SDC.1 Authentication configuration Account names for cracked, passwords, account
policy, parameters
IDS_SDC.1 Accountability policy
configuration
Accountability policy configuration parameters
IDS_SDC.1 Detected known vulnerabilities Identification of the known, vulnerability
5.2.7 Rationale
IDS_SDC_EXT.1 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_SDC_EXT.1 had to be defined because the Common Criteria v3.1 Part 2 does not
provide a Security Functional Requirement for Intrusion Detection functionality, specifically
System data collection.
5.3 IDS_ANL_EXT.1 Analyzer analysis
5.3.1 Class IDS: Intrusion Detection System
5.3.2 Family: Analyzer analysis (IDS_ANL)
5.3.3 Family Behavior
This family defines the requirements for the TSF to be able to analyze the IDS data that has
been gathered from targeted IT System resources.
5.3.4 Management
The following actions could be considered for the management functions in FMT:
 the management (addition, removal, or modification) of specific IDS information that
will be obtained from targeted IT System resource(s).
5.3.5 Audit
There are no auditable events foreseen.
5.3.6 Definition
IDS_ANL_EXT.1 Analyzer analysis
Hierarchical to: No other components
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
50 of 105
Dependencies: IDS_SDC_EXP.1
IDS_ANL_EXT.1.1 The TSF shall perform the following analysis function(s) on all IDS data
received:
a) [selection: statistical, signature, integrity]; and
b) [assignment: other analytical functions].
IDS_ANL_EXT.1.2 The TSF shall record within each analytical result at least the following
information:
a) Date and time of the result, type of result, identification of data source; and
b) [assignment: other security relevant information]
5.3.7 Rationale
IDS_ANL_EXT.1 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_ANL_EXT.1 had to be defined because the Common Criteria v3.1 Part 2 does not provide
a Security Functional Requirement for Intrusion Detection functionality, specifically the
analysis function.
5.4 IDS_RCT_EXT.1 Analyzer react
5.4.1 Class IDS: Intrusion Detection System
5.4.2 Family: Analyzer react (IDS_RCT)
5.4.3 Family Behavior
This family defines the requirements for the TSF to be able to send an alarm and react when
an intrusion is detected.
5.4.4 Management
The following actions could be considered for the management functions in FMT:
 the management (addition, removal, or modification) of actions
5.4.5 Audit
There are no auditable events foreseen.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
51 of 105
5.4.6 Definition
IDS_RCT_EXT.1 Analyzer react
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1
IDS_RCT_EXT.1.1 The TSF shall send an alarm to [assignment: alarm destination] and
take [assignment: appropriate actions] when an intrusion is detected.
5.4.7 Rationale
IDS_RCT_EXT.1 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_RCT_EXT.1 had to be defined because the Common Criteria v3.1 Part 2 does not
provide a Security Functional Requirement for Intrusion Detection functionality, specifically the
alarm and reaction function.
5.5 IDS_RDR_EXT.1 Restricted Data Review
5.5.1 Class IDS: Intrusion Detection System
5.5.2 Family: Security data review (IDS_RDR)
5.5.3 Family Behavior
This family defines the requirements for data tools that should be available to authorized users
to assist in the review of system data.
5.5.4 Management
There are no management activities foreseen.
5.5.5 Audit
There are no auditable events foreseen.
5.5.6 Definition
IDS_RDR_EXT.1 Restricted Data Review
Hierarchical to: No other components
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
52 of 105
Dependencies: IDS_SDC_EXP.1
IDS_RDR_EXT.1.1 The TSF shall provide [assignment: authorized users] with the
capability to read [assignment: list of system data] from the system data.
IDS_RDR_EXT.1.2 The TSF shall provide the system data in a manner suitable for the user
to interpret the information.
IDS_RDR_EXT.1.3 The TSF shall prohibit all users read access to the system data, except
those users that have been granted explicit read-access.
5.5.7 Rationale
IDS_RDR_EXT.1 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_RDR_EXT.1 had to be defined because the Common Criteria v3.1 Part 2 does not
provide a Security Functional Requirement for Intrusion Detection functionality, specifically the
restricted data review function.
5.6 IDS_STG_EXT.1 Guarantee of System Data Availability
5.6.1 Class IDS: Intrusion Detection System
5.6.2 Family: System data storage (IDS_STG)
5.6.3 Family Behavior
This family defines the requirements for the TSF to be able to secure system data.
5.6.4 Management
There are no management activities foreseen.
5.6.5 Audit
There are no auditable events foreseen.
5.6.6 Definition
IDS_STG_EXT.1 Guarantee of System Data Availability
Hierarchical to: No other components
Dependencies: IDS_SDC_EXT.1
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
53 of 105
IDS_STG_EXT.1.1 The TSF shall protect the stored system data from unauthorized
deletion.
IDS_STG_EXT.1.2 The TSF shall protect the stored system data from modification.
IDS_STG_EXT.1.3 The TSF shall ensure that [assignment: metric for saving system
data] system data will be maintained when the following condition occurs:
[selection: system data storage exhaustion, failure, attack].
5.6.7 Rationale
IDS_STG_EXT.1 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_STG_EXT.1 had to be defined because the Common Criteria v3.1 Part 2 does not
provide a Security Functional Requirement for Intrusion Detection functionality, specifically the
guarantee of System data availability.
5.7 IDS_STG_EXT.2 Prevention of System data loss
5.7.1 Class IDS: Intrusion Detection System
5.7.2 Family: System data storage (IDS_STG)
5.7.3 Family Behavior
This family defines the requirements for the TSF to be able to secure system data.
5.7.4 Management
The following actions could be considered for the management functions in FMT:
 the maintenance (deletion, modification, addition) of actions to be taken in case of audit
storage failure
5.7.5 Audit
There are no auditable events foreseen.
5.7.6 Definition
IDS_STG_EXT.2 Prevention of System data loss (EXT)
Hierarchical to: No other components
Dependencies: IDS_SDC_EXT.1
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
54 of 105
IDS_STG_EXT.2.1 The TSF shall [selection: 'ignore system data', 'prevent system
data, except those taken by the authorized user with special rights',
'overwrite the oldest stored system data '] and send an alarm if the storage
capacity has been reached.
5.7.7 Rationale
IDS_STG_EXT.2 is taken from the U.S. Government Protection Profile Intrusion Detection
System System for Basic Robustness Environments, Version 1.7, July 25, 2007.
IDS_STG_EXT.2 had to be defined because the Common Criteria v3.1 Part 2 does not
provide a Security Functional Requirement for Intrusion Detection functionality, specifically the
prevention of system data loss
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
55 of 105
6 Security Requirements
6.1 Security Functional Requirements
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 italics 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: are identified with "Refinement:" right after the short name.
Additions to the CC text are specified in italicized bold and underlined text.
Note: Operations already performed in the corresponding Protection Profile are not identified
in this Security Target.
 Application notes provide additional information for the reader, but do not specify
requirements. Application notes are denoted by italicized text.
 Explicitly stated Security Functional Requirements (i.e., those not found in Part 2
of the CC) are identified “_EXT” in the component name.
The TOE security functional requirements are listed in Table 6-1. All SFRs are based on
requirements defined in Part 2 of the Common Criteria or the U.S. Government Protection
Profile Intrusion Detection System System for Basic Robustness Environments, Version 1.7,
July 25, 2007.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
56 of 105
Table 6-1: TOE Security Functional Components
No. Component Component Name
1 FAU_GEN.1 Audit data generation
2 FAU_SAR.1 Audit review
3 FAU_SAR.2 Restricted audit review
4 FAU_SAR.3 Selectable audit review
5 FAU_SEL.1 Selective audit
6 FAU_STG.2 Guarantees of data availability
7 FAU_STG.4 Prevention of audit data loss
8 FIA_ATD.1 User attribute definition
9 FIA_UAU_EXT.1 Timing of authentication
10 FIA_UID.1 Timing of identification
11 FMT_MOF.1 Management of security functions behavior
12 FMT_MTD.1 Management of TSF data
13 FMT_SMF.1 Specification of Management Functions
14 FMT_SMR.1 Security roles
15 FPT_ITT.1 Basic internal TSF data transfer protection
16 FTA_TAB.1 Default TOE access banners
17 IDS_SDC_EXT.1 System Data Collection
18 IDS_ANL_EXT.1 Analyzer analysis
19 IDS_RCT_EXT.1 Analyzer react
20 IDS_RDR_EXT.1 Restricted Data Review
21 IDS_STG_EXT.1 Guarantee of System Data Availability
22 IDS_STG_EXT.2 Prevention of System data loss
6.1.1 Class FAU: Security Audit
6.1.1.1 FAU_GEN.1 Audit Data Generation
Hierarchical to: No other components
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the basic level of audit; and
c) Access to the System and access to the TOE and system data
Application Note: The IDS_SDC and IDS_ANL requirements address the recording of results
from IDS scanning, sensing, and analyzing tasks (i.e., system data).
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
57 of 105
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 6-2: Auditable Events.
Table 6-2: Auditable Events
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 ID, 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
FAU_STG.2 None
FAU_STG.4 Actions taken due to the audit storage failure
FIA_ATD.1 None
FIA_UAU_EXT.1 All use of the authentication mechanism User identity, location
FIA_UID.1 All use of the user identification mechanism User identity, location
FMT_MOF.1 All modifications in the behavior of the
functions of the TSF
FMT_MTD.1 All modifications to the values of TSF data
FMT_SMF.1 Use of the management functions User identity
FMT_SMR.1 Modifications to the group of users that are
part of a role
User identity
FPT_ITT.1 None
FTA_TAB.1 None
IDS_SDC_EXT.1 None
IDS_ANL_EXT.1 None
IDS_RCT_EXT.1 None
IDS_RDR_EXT.1 None
IDS_STG_EXT.1 None
IDS_STG_EXT.1 None
6.1.1.2 FAU_SAR.1 Audit Review
Hierarchical to: No other components
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide [users with the Administrator Role] with the capability
to read [all audit information] from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
58 of 105
6.1.1.3 FAU_SAR.2 Restricted audit review
Hierarchical to: No other components
Dependencies: FAU_SAR.1 Audit review
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those
users who have been granted explicit read-access.
6.1.1.4 FAU_SAR.3 Selectable audit review
Hierarchical to: No other components
Dependencies: FAU_SAR.1 Audit review
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.
Application Note: Type of event is contained in the Subsystem field of the audit records.
Success or Failure of the event is part of the Message field.
6.1.1.5 FAU_SEL.1 Selective audit
Hierarchical to: No other components
Dependencies: FAU_GEN.1 Audit data generation
FMT_MTD.1 Management of TSF data
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) [IP address, message, subsystem, and username]
6.1.1.6 FAU_STG.2 Guarantees of audit data availability
Hierarchical to: FAU_STG.1
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG.2.1 The TSF shall protect the stored audit records from unauthorized deletion.
FAU_STG.2.2 The TSF shall be able to detect unauthorized modifications to the audit records
in the audit trail.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
59 of 105
FAU_STG.2.3 The TSF shall ensure that [the most recent, limited by available audit
storage, at least one] audit records will be maintained when the following
conditions occur: [audit storage exhaustion].
6.1.1.7 FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3
Dependencies: FAU_STG.1 Protected audit trail storage
FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and send an alarm
if the audit trail storage is full.
6.1.2 Class FIA: Identification and Authentication
6.1.2.1 FIA_ATD.1 User attribute definition
Hierarchical to: No other components
Dependencies: No dependencies
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) [
o Use External Authentication Method
o Force Password Reset on Login
o Password Strength Check
o Max Number of Failed Logins
o Password Expiration
o Warning Days
].
6.1.2.2 FIA_UAU_EXT.1 Timing of authentication
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
60 of 105
FIA_UAU_EXT.1.1 The TSF shall allow [entry of identification and authentication data]
on behalf of the user to be performed before the user is authenticated.
FIA_UAU_EXT.1.2 The TSF shall require each user to be successfully authenticated either
by the TSF or by an authentication service in the Operational Environment
invoked by the TSF before allowing any other TSF-mediated actions on behalf
of that user
Application Note: Use of an external authentication server is allowed only for TOE
configurations that include a Defense Center.
6.1.2.3 FIA_UID.1 Timing of identification
Hierarchical to: No other components
Dependencies: No dependencies
FIA_UID.1.1 The TSF shall allow [entry of identification and authentication data] on
behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
6.1.3 Class FMT: Security Management
6.1.3.1 FMT_MOF.1 Management of security functions behavior
Hierarchical to: No other components
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behavior] of the functions [See
column 1 of Table 6-3 ] to [See column 2 of Table 6-3].
Table 6-3: Management of Security Functions Behavior
Function User Role
system data collection
(create, edit IPS Rules)
Admin
Policy and Response Administrator
analysis and reaction
(create, edit Detection Engines)
Admin
audit data generation
(create, modify Audit Suppression Lists)
CLI root user *
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
61 of 105
* This is not a security role maintained by the TOE; it is maintained by the appliance OS and is
equivalent to the system administrator of the OS.
6.1.3.2 FMT_MTD.1 Management of TSF data
Hierarchical to: No other components
Dependencies: FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1 The TSF shall restrict the ability to [operations as specified in Table 6-4] the
[TSF data as specified in Table 6-4] to [user security role as specified in
Table 6-4].
Table 6-4: Management of TSF data
User Security Role Operations TSF Data
Administrator Configure Access lists
Verify Appliance licenses
View, search Audit records
Create, edit, delete * Authentication objects
Create, upload, restore from Backup files
Create, modify, delete Backup profiles
Configure Remote Backup Storage
View, edit, create, delete, export Custom workflows
Add sensor to, delete sensor
from *
Defense Center
Create, edit, delete Detection engine groups
Create, edit, delete Detection engines
Configure DNS cache properties
Create (activate), edit, delete
(deactivate)
Email alerts
Configure Email settings
View Event graphs
Configure * External authentication of users
View, search, delete * Health events
Run * Health module tests
Create, edit, delete * Health monitor alerts
Create, edit, delete, import,
export, apply, disable (blacklist
a sensor) *
Health policies
Push to sensors * Health policies
View * Health status of appliances
View, edit, create Incidents
Create, edit, delete Interface sets
View, configure, delete Intrusion event notification suppression
View Intrusion event statistics
View, configure, delete Intrusion event thresholds
View, edit, import, export Intrusion event workflows
View, search, delete Intrusion events
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
62 of 105
User Security Role Operations TSF Data
Create, edit, delete, apply,
schedule application of, import,
export
Intrusion policies
Push to sensors * Intrusion policies
Enable, disable Intrusion rules
View IPS performance statistics
Enable, disable, configure Latency Thresholding
Import Local rule file
Configure Login Banner
Configure Maximum number of records in
database
Configure Network interfaces
Configure Network settings
Change Own password
Configure Preprocessors, Preprocessor options
Configure, delete Recurring tasks
View, edit, create, delete Report profiles
View, move, download, delete Reports
View Reviewed intrusion events
Classify, view, create, edit,
delete, search, filter
Rules
Push to sensors * Rules
Delete Scheduled tasks
Modify 3D Sensor with IPS system settings
Modify * Defense Center system settings
Create, edit, delete * 3D Sensor with IPS groups
View 3D Sensor with IPS and system
statistics
View * Defense Center statistics
View, add, delete, stop (shut-
down), restart (reboot), set time
on, disable communications of *
3D Sensors with IPS
Create, edit, delete, activate,
deactivate
SNMP alerts
View Syslog
Create, edit, delete, activate,
deactivate
Syslog alerts
Shutdown, restart System
Configure System backups
Create, edit, apply, delete,
export
System policy
Push to sensors * System policy
Configure System settings
Create, edit, delete System variables
Synchronize Time
Configure Time server
View, add, modify, delete User accounts
Change User passwords
Maintenance Create, upload Backup files
Create, modify, delete Backup profiles
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
63 of 105
User Security Role Operations TSF Data
Configure Remote Backup Storage
View, search, delete * Health events
Run * Health module tests
Create, edit, delete, export,
apply, disable (blacklist a
sensor) *
Health policies
Push to sensors * Health policies
View * Health status of appliances
Schedule application of Intrusion policies
View IPS performance statistics
Change Own password
Configure, delete Recurring tasks
Delete Scheduled tasks
View 3D Sensor with IPS and system
statistics
View * Defense Center statistics
Configure System backups
Intrusion Event Analyst View, edit, create, delete, export Custom workflows
View Event graphs
View, search * Health events
Run * Health module tests
View * Health status of appliances
View, edit, create Incidents
View Intrusion event statistics
View, edit, export Intrusion event workflows
View, search, delete Intrusion events
Change Own password
View, edit, create, delete Report profiles
View, move, download, delete Reports
View Reviewed intrusion events
Intrusion Event Analyst
(Read Only)
View, edit, create, delete, export Custom workflows
View Event graphs
View, search * Health events
Run * Health module tests
View * Health status of appliances
View, edit, create Incidents
View Intrusion event statistics
View, edit, export Intrusion event workflows
View, search Intrusion events
Change Own password
View, edit, create, delete Report profiles
View, move, download, delete Reports
View Reviewed intrusion events
Restricted Event Analyst View, edit, create, delete, export Custom workflows
View, edit, export Intrusion event workflows
View, search, delete Intrusion events
Change Own password
View Reviewed intrusion events
Restricted Event Analyst View, edit, create, delete, export Custom workflows
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
64 of 105
User Security Role Operations TSF Data
(Read Only) View, edit, export Intrusion event workflows
View, search Intrusion events
Change Own password
View Reviewed intrusion events
Policy and Response
Administrator
Create (activate), edit, delete
(deactivate)
Email alerts
Create, edit, delete * Health monitor alerts
View, configure, delete Intrusion event notification suppression
View, configure, delete Intrusion event thresholds
Create, edit, delete, apply,
schedule application of, import,
export
Intrusion policies
Push to sensors * Intrusion policies
Enable, disable Intrusion rules
Enable, disable, configure Latency Thresholding
Import Local rule file
Change Own password
Configure Preprocessors, Preprocessor options
Classify, view, create, edit,
delete, search, filter
Rules
Push to sensors * Rules
Create, edit, delete, activate,
deactivate
SNMP alerts
View Syslog
Create, edit, delete, activate,
deactivate
Syslog alerts
Create, edit, delete System variables
CLI root user ** Create, modify Audit suppression lists
* These functions are available only on the Defense Center WebUI, they cannot be run from
the management interface of a stand-alone 3D Sensor with IPS.
** This is not a security role maintained by the TOE; it is maintained by the appliance OS and
is equivalent to the system administrator of the OS.
6.1.3.3 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components
Dependencies: No dependencies
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
functions: [
 Configure Access Lists
 Verify Appliance Licenses
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
65 of 105
 View and Search Audit Records
 Create, Edit, and Delete Authentication Objects
 Create, Upload, and Restore from Backup Files
 Create, Modify, and Delete Backup Profiles
 Configure Remote Backup Storage
 View, Edit, Create, Delete, and Export Custom Workflows
 Add 3D Sensor with IPS To and Delete 3D Sensor with IPS From Defense Center
 Create, Edit, and Delete Detection Engine Groups
 Create, Edit, and Delete Detection Engines
 Configure DNS Cache Properties
 Create (activate), Edit, and Delete (deactivate) Email Alerts
 Configure Email Settings
 View Event Graphs
 Configure External Authentication of Users
 View and Search Health Events
 Run Health Module Tests
 Create, Edit, and Delete Health Monitor Alerts
 Create, Edit, Delete, Import, Export, Apply, and Disable (blacklist a sensor) Health
Policies
 Push Health Policies to 3D Sensors with IPS
 View Health Status of Appliances
 View, Edit, and Create Incidents
 Create, Edit, and Delete Interface Sets
 View, Configure, and Delete Intrusion Event Notification Suppression
 View Intrusion Event Statistics
 View, Configure, and Delete Intrusion Event Thresholds
 View, Edit, Import, and Export Intrusion Event Workflows
 View, Search, and Delete Intrusion Events
 Create, Edit, Delete, Apply, Schedule Application of, Import, and Export Intrusion Policies
 Push Intrusion Policies to 3D Sensors with IPS
 Enable and Disable Intrusion Rules
 View IPS Performance Statistics
 Configure Maximum Number of Records in the Appliance Databases
 Configure Network Interfaces
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
66 of 105
 Configure Network Settings
 Configure Preprocessors and Preprocessor Options
 Configure and Delete Recurring Tasks
 View, Edit, Create, and Delete Report Profiles
 View, Move, Download, and Delete Reports
 View Reviewed Intrusion Events
 Classify, View, Create, Edit, Delete, Search, and Filter Rules
 Push Rules to 3D Sensors with IPS
 Delete Scheduled Tasks
 Modify 3D Sensor with IPS System Settings
 Modify Defense Center System Settings
 Create, Edit, and Delete 3D Sensor with IPS Groups
 View 3D Sensor with IPS, Defense Center, and System Statistics
 View, Add, Delete, Stop (shut-down), Restart (reboot), Set Time on, and Disable
Communications of 3D Sensor with IPS
 Create, Edit, Delete, Activate, and Deactivate SNMP Alerts
 View Syslog
 Create, Edit, Delete, Activate, and Deactivate Syslog Alerts
 Shutdown and Restart System
 Configure System Backups
 Create, Edit, Apply, Delete, and Export System Policy
 Push System Policy to 3D Sensors with IPS
 Configure System Settings
 Create, Edit, and Delete System Variables
 Synchronize Time on Appliances
 Configure Time Server
 View, Add, Modify, and Delete User Accounts
 Change User Passwords
 Enable, Disable and Configure Latency Thresholding
 Import Local Rule Files
 Configure Login Banners
 Create and Modify Audit Suppression Lists
].
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
67 of 105
Application Note: FMT_SMF.1 is not included in the IDS System PP; however, it needed to be
included to satisfy the dependencies of the SFRs FMT_MOF.1 and FMT_MTD.1.
6.1.3.4 FMT_SMR.1 Security Roles
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [
 Administrator
 Maintenance
 Intrusion Event Analyst
 Intrusion Event Analyst (Read Only)
 Restricted Event Analyst
 Restricted Event Analyst (Read Only)
 Policy and Response Administrator
].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
6.1.4 Class FPT: Protection of the TSF
6.1.4.1 FPT_ITT.1 Basic internal TSF data transfer protection
Hierarchical to: No other components
Dependencies: No dependencies
FPT_ITT.1.1 Refinement: The TSF shall protect TSF data from [disclosure, modification]
when it is transmitted between the Defense Center and the 3D Sensor(s)
with IPS by using a secure, SSL-encrypted TCP tunnel that uses OpenSSL
Version 0.9.8g and Cipher AES256-SHA (strength:256 bits).
Application Note: FPT_ITT.1 replaces the IDS System PP SFRs: FIA_AFL.1, FPT_ITA.1,
FPT_ITC.1, and FPT_ITI.2, through the precedence of PD-0097.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
68 of 105
6.1.5 Class FTA: TOE Access
6.1.5.1 FTA_TAB.1 Default TOE access banners
Hierarchical to: No other components.
Dependencies: No dependencies.
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorized use of the TOE.
6.1.6 Class IDS: IDS Component Requirements
6.1.6.1 IDS_SDC_EXT.1 System Data Collection
Hierarchical to: No other components
Dependencies: FPT_STM.1 Reliable time stamps
IDS_SDC_EXT.1.1 The TSF shall be able to collect the following information from the
targeted IT System resource(s):
a) [network traffic]; and
b) [no other events]
IDS_SDC_EXT.1.2 At a minimum, the TSF shall collect and record the following information
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) The additional information specified in the Details column of Table 6-5: System Events.
Table 6-5: System Events
Component Event Details
IDS_SDC_EXT.1 Network traffic Protocol
Source address
Destination address
6.1.6.2 IDS_ANL_EXT.1 Analyzer analysis
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1 System Data Collection
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
69 of 105
IDS_ANL_EXT.1.1 The TSF shall perform the following analysis function(s) on all IDS data
received:
a) [signature]; and
b) [
o Checksum Verification
o Packet IP Defragmentation
o Stateful Inspection & TCP Stream Reassembly
o RPC Decode
o Back Orifice Detection
o HTTP Decode and Normalization
o SMTP Decode and Normalization
o Telnet Decode and Normalization
o FTP Decode and Normalization
o DCE/RPC Inspection
o DNS Inspection
o SSL Inspection
o Portscan
].
IDS_ANL_EXT.1.2 The TSF shall record within each analytical result at least the following
information:
a) Date and time of the result, type of result, identification of data source; and
b) [The packets analyzed to determine the result]
6.1.6.3 IDS_RCT_EXT.1 Analyzer react (EXT)
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1 System Data Collection
IDS_RCT_EXT.1.1 The TSF shall send an alarm to [
 A defined email administrative address, and/or
 Syslog facilities, and/or
 An SNMP Trap Server
] and take [
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
70 of 105
 no actions for passive deployment of 3D Sensors with IPS
 actions to Drop, Replace packets containing suspicious network traffic
according to configured rules for inline deployment of 3D Sensors with IPS
] when an intrusion is detected.
6.1.6.4 IDS_RDR_EXT.1 Restricted Data Review (EXT)
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1 System Data Collection
IDS_RDR_EXT.1.1 The TSF shall provide [users with the Administrator or Intrusion
Event Analyst Role] with the capability to read [all captured IDS data] from
the system data.
IDS_RDR_EXT.1.2 The TSF shall provide the system data in a manner suitable for the user
to interpret the information.
IDS_RDR_EXT.1.3 The TSF shall prohibit all users read access to the system data, except
those users that have been granted explicit read-access.
6.1.6.5 IDS_STG_EXT.1 Guarantee of System Data Availability
Hierarchical to: No other components
Dependencies: No dependencies
IDS_STG_EXT.1.1 The TSF shall protect the stored system data from unauthorized
deletion.
IDS_STG_EXT.1.2 The TSF shall protect the stored system data from modification.
IDS_STG_EXT.1.3 The TSF shall ensure that [the most recent, limited by available
system data storage, at least one] system data will be maintained when the
following condition occurs: [system data storage exhaustion].
6.1.6.6 IDS_STG_EXT.2 Prevention of System data loss
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1 System Data Collection
IDS_STG_EXT.2.1 The TSF shall [overwrite the oldest stored system data] and send an
alarm if the storage capacity has been reached.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
71 of 105
6.2 Security Assurance Requirements for the TOE
This Section defines the assurance requirements for the TOE. Assurance requirements are
taken from the CC Part 3 and are EAL2 augmented with ALC_FLR.2. None of the assurance
components are refined. Table 6-6 summarizes the components.
Table 6-6: EAL2+ Assurance Components
Assurance Class Assurance Components
Development
ADV_ARC.1 Architectural Design with Domain Separation and
non-bypassability
ADV_FSP.2 Security enforcing Functional Specification
ADV_TDS.1 Basic Design
Guidance documents
AGD_OPE.1 Operational User guidance
AGD_PRE.1 Preparative User guidance
Life cycle support
ALC_CMC.2 Use of a CM system
ALC_CMS.2 Parts of the TOE CM coverage
ALC_DEL.1 Delivery procedures
ALC_FLR.2 Flaw Reporting Procedures
Tests
ATE_COV.1 Evidence of coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability assessment AVA_VAN.2 Vulnerability Analysis
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
72 of 105
6.2.1 Class ADV: Development
6.2.1.1 ADV_ARC.1 Security architecture description
Dependencies: ADV_FSP.1 Basic functional specification
ADV_TDS.1 Basic design
Developer action elements:
ADV_ARC.1.1D The developer shall design and implement the TOE so that the security
features of the TSF cannot be bypassed.
ADV_ARC.1.2D The developer shall design and implement the TSF so that it is able to
protect itself from tampering by untrusted active entities.
ADV_ARC.1.3D The developer shall provide a security architecture description of the
TSF.
Content and presentation elements:
ADV_ARC.1.1C The security architecture description shall be at a level of detail
commensurate with the description of the SFR-enforcing abstractions
described in the TOE design document.
ADV_ARC.1.2C The security architecture description shall describe the security domains
maintained by the TSF consistently with the SFRs.
ADV_ARC.1.3C The security architecture description shall describe how the TSF
initialization process is secure.
ADV_ARC.1 4C The security architecture description shall demonstrate that the TSF
protects itself from tampering.
ADV_ARC.1.5C The security architecture description shall demonstrate that the TSF
prevents bypass of the SFR-enforcing functionality.
Evaluator action elements:
ADV_ARC.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.1.2 ADV_FSP.2 Security-enforcing functional specification
Dependencies: ADV_TDS.1 Basic design
Developer action elements:
ADV_FSP.2.1D The developer shall provide a functional specification.
ADV_FSP.2.2D The developer shall provide a tracing from the functional specification to
the SFRs.
Content elements:
ADV_FSP.2.1C The functional specification shall completely represent the TSF.
ADV_FSP.2.2C The functional specification shall describe the purpose and method of
use for all TSFI.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
73 of 105
ADV_FSP.2.3C The functional specification shall identify and describe all parameters
associated with each TSFI.
ADV_FSP.2.4C For each SFR-enforcing TSFI, the functional specification shall describe
the SFR-enforcing actions associated with the TSFI.
ADV_FSP.2.5C For SFR-enforcing TSFIs, the functional specification shall describe
direct error messages resulting from processing associated with the
SFR enforcing actions.
ADV_FSP.2.6C The tracing shall demonstrate that the SFRs trace to TSFIs in the
functional specification.
Evaluator action elements:
ADV_FSP.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
ADV_FSP.2.2E The evaluator shall determine that the functional specification is an
accurate and complete instantiation of the SFRs.
6.2.1.3 ADV_TDS.1 Basic design
Dependencies: ADV_FSP.2 Security-enforcing functional specification
Developer action elements:
ADV_TDS.1.1D The developer shall provide the design of the TOE.
ADV_TDS.1.2D The developer shall provide a mapping from the TSFI of the functional
specification to the lowest level of decomposition available in the TOE
design.
Content and presentation elements:
ADV_TDS.1.1C The design shall describe the structure of the TOE in terms of
subsystems.
ADV_TDS.1.2C The design shall identify all subsystems of the TSF.
ADV_TDS.1.3C The design shall describe the behavior of each SFR-supporting or SFR-
non interfering TSF subsystem in sufficient detail to determine that it is
not SFR-enforcing.
ADV_TDS.1.4C The design shall summarize the SFR-enforcing behavior of the SFR
enforcing subsystems.
ADV_TDS.1.5C The design shall provide a description of the interactions among SFR
enforcing subsystems of the TSF, and between the SFR-enforcing
subsystems of the TSF and other subsystems of the TSF.
ADV_TDS.1.6C The mapping shall demonstrate that all behavior described in the TOE
design is mapped to the TSFIs that invoke it.
Evaluator action elements:
ADV_TDS.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
ADV_TDS.1.2E The evaluator shall determine that the design is an accurate and
complete instantiation of all security functional requirements.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
74 of 105
6.2.2 Class AGD: Guidance documents
6.2.2.1 AGD_OPE.1 Operational user guidance
Dependencies: ADV_FSP.1 Basic functional specification
Developer action elements:
AGD_OPE.11D The developer shall provide operational user guidance.
Content and presentation elements:
AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the
user accessible functions and privileges that should be controlled in a
secure processing environment, including appropriate warnings.
AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to
use the available interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the
available functions and interfaces, in particular all security parameters
under the control of the user, indicating secure values as appropriate.
AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present
each type of security-relevant event relative to the user-accessible
functions that need to be performed, including changing the security
characteristics of entities under the control of the TSF.
AGD_OPE.1.5C The operational user guidance shall identify all possible modes of
operation of the TOE (including operation following failure or operational
error), their consequences and implications for maintaining secure
operation.
AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the
security measures to be followed in order to fulfill the security objectives
for the operational environment as described in the ST.
AGD_OPE.1.7C The operational user guidance shall be clear and reasonable.
Evaluator action elements:
AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.2.2 AGD_PRE.1 Preparative procedures
Dependencies: No dependencies
Developer action elements:
AGD_PRE.11D The developer shall provide the TOE including its preparative
procedures.
Content and presentation elements:
AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for
secure acceptance of the delivered TOE in accordance with the
developer's delivery procedures.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
75 of 105
AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for
secure installation of the TOE and for the secure preparation of the
operational environment in accordance with the security objectives for
the operational environment as described in the ST.
Evaluator action elements:
AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the
TOE can be prepared securely for operation.
6.2.3 Class ALC: Life-cycle support
6.2.3.1 ALC_CMC.2 Use of a CM system
Dependencies: ALC_CMS.1 TOE CM coverage
Developer action elements:
ALC_CMC.21D The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.2.2D The developer shall provide the CM documentation.
ALC_CMC.2.3D The developer shall use a CM system.
Content and presentation elements:
ALC_CMC.2.1C The TOE shall be labeled with its unique reference.
ALC_CMC.2.2C The CM documentation shall describe the method used to uniquely
identify the configuration items.
ALC_CMC.23C The CM system shall uniquely identify all configuration items.
Evaluator action elements:
ALC_CMC.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.3.2 ALC_CMS.2 Parts of the TOE CM coverage
Dependencies: No dependencies
Developer action elements:
ALC_CMS.2.1D The developer shall provide a configuration list for the TOE.
Content and presentation elements:
ALC_CMS.2.1C The configuration list shall include the following: the TOE itself; the
evaluation evidence required by the SARs; and the parts that comprise
the TOE.
ALC_CMS.2.2C The configuration list shall uniquely identify the configuration items.
ALC_CMS.2.3C For each TSF relevant configuration item, the configuration list shall
indicate the developer of the item.
Evaluator action elements:
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
76 of 105
ALC_CMS.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.3.3 ALC_DEL.1 Delivery procedures
Dependencies: No dependencies
Developer action elements:
ALC_DEL.1.1D The developer shall document procedures for delivery of the TOE or
parts of it to the consumer.
ALC_DEL.1.2D The developer shall use the delivery procedures.
Content and presentation elements:
ALC_DEL.1.1C The delivery documentation shall describe all procedures that are
necessary to maintain security when distributing versions of the TOE to
the consumer.
Evaluator action elements:
ALC_DEL.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.3.4 ALC_FLR.2 Flaw reporting procedures
Dependencies: No dependencies
Developer action elements:
ALC_FLR.2.1D The developer shall document flaw remediation procedures addressed
to TOE developers.
ALC_FLR.2.2D The developer shall establish a procedure for accepting and acting upon
all reports of security flaws and requests for corrections to those flaws.
ALC_FLR.2.3D The developer shall provide flaw remediation guidance addressed to
TOE users.
Content and presentation elements:
ALC_FLR.2.1C The flaw remediation procedures documentation shall describe the
procedures used to track all reported security flaws in each release of
the TOE.
ALC_FLR.2.2C The flaw remediation procedures shall require that a description of the
nature and effect of each security flaw be provided, as well as the status
of finding a correction to that flaw.
ALC_FLR.2.3C The flaw remediation procedures shall require that corrective actions be
identified for each of the security flaws.
ALC_FLR.2.4C The flaw remediation procedures documentation shall describe the
methods used to provide flaw information, corrections and guidance on
corrective actions to TOE users.
ALC_FLR.2.5C The flaw remediation procedures shall describe a means by which the
developer receives from TOE users‟ reports and enquiries of suspected
security flaws in the TOE.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
77 of 105
ALC_FLR.2.6C The procedures for processing reported security flaws shall ensure that
any reported flaws are remediated and the remediation procedures
issued to TOE users.
ALC_FLR.2.7C The procedures for processing reported security flaws shall provide
safeguards that any corrections to these security flaws do not introduce
any new flaws.
ALC_FLR.2.8C The flaw remediation guidance shall describe a means by which TOE
users report to the developer any suspected security flaws in the TOE.
Evaluator action elements:
ALC_FLR.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.4 Class ATE: Tests
6.2.4.1 ATE_COV.1 Evidence of coverage
Dependencies: ADV_FSP.2 Security-enforcing functional specification
ATE_FUN.1 Functional testing
Developer action elements:
ATE_COV.1.1D The developer shall provide evidence of the test coverage.
Content and presentation elements:
ATE_COV.1.1C The evidence of the test coverage shall show the correspondence
between the tests in the test documentation and the TSFIs in the
functional specification.
Evaluator action elements:
ATE_COV.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.4.2 ATE_FUN.1 Functional testing
Dependencies: ATE_COV.1 Evidence of coverage
Developer action elements:
ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2D The developer shall provide test documentation.
Content and presentation elements:
ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results
and actual test results.
ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the
scenarios for performing each test. These scenarios shall include any
ordering dependencies on the results of other tests.
ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a
successful execution of the tests.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
78 of 105
ATE_FUN.1.4C The actual test results shall be consistent with the expected test results.
Evaluator action elements:
ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
6.2.4.3 ATE_IND.2 Independent testing - sample
Dependencies: ADV_FSP.2 Security-enforcing functional specification
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ATE_COV.1 Evidence of coverage
ATE_FUN.1 Functional testing
Developer action elements:
ATE_IND.2.1D The developer shall provide the TOE for testing.
Content and presentation elements:
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that
were used in the developer's functional testing of the TSF.
Evaluator action elements:
ATE_IND.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
ATE_IND.2.2E The evaluator shall execute a sample.
ATE_IND.2.3E The evaluator shall test a subset of the TSF to confirm that the TSF
operates as specified.
6.2.5 Class AVA: Vulnerability assessment
6.2.5.1 AVA_VAN.2 Vulnerability analysis
Dependencies: ADV_ARC.1 Security architecture description
ADV_FSP.1 Basic functional specification
ADV_TDS.1 Basic design
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Developer action elements:
AVA_VAN.2.1D The developer shall provide the TOE for testing.
Content and presentation elements:
AVA_VAN.2.1C The TOE shall be suitable for testing.
Evaluator action elements:
AVA_VAN.12.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
79 of 105
AVA_VAN.2.2E The evaluator shall perform a search of public domain sources to
identify potential vulnerabilities in the TOE.
AVA_VAN.2.3E The evaluator shall perform an independent vulnerability analysis of the
TOE using the guidance documentation, functional specification, TOE
design and security architecture description to identify potential
vulnerabilities in the TOE.
AVA_VAN.2.4E The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the TOE is resistant to attacks
performed by an attacker possessing Basic attack potential.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
80 of 105
6.3 Security Requirements Rationale
6.3.1 Dependencies Satisfied
Table 6-7 shows the dependencies between the functional requirements including the
extended components defined in Section 5. Dependencies that are satisfied by a hierarchical
component are denoted by an (H) following the dependency reference.
Table 6-7: TOE Dependencies Satisfied
Item SFR ID SFR Title Dependencies Item Reference
1 FAU_GEN.1 Audit data generation FPT_STM.1 Environment *
2 FAU_SAR.1 Audit review FAU_GEN.1 1
3 FAU_SAR.2 Restricted audit review FAU_SAR.1 2
4 FAU_SAR.3 Selectable audit review FAU_SAR.1 2
5 FAU_SEL.1 Selective audit FAU_GEN.1 1
FMT_MTD.1 12
6 FAU_STG.2 Guarantees of data availability FAU_GEN.1 1
7 FAU_STG.4 Prevention of audit data loss FAU_STG.1 6 (H)
8 FIA_UAU_EXT.1 Timing of authentication FIA_UID.1 10
9 FIA_ATD.1 User attribute definition None None
10 FIA_UID.1 Timing of identification None None
11 FMT_MOF.1 Management of security functions
behavior
FMT_SMR.1 14
FMT_SMF.1 13
12 FMT_MTD.1 Management of TSF data FMT_SMF.1 13
13 FMT_SMF.1 Specification of Management
Functions
None None
14 FMT_SMR.1 Security roles FIA_UID.1 10
15 FPT_ITT.1 Basic internal TSF data transfer
protection
None None
16 FTA_TAB.1 Default TOE access banners None None
17 IDS_SDC_EXT.1 System Data Collection (EXT) FPT_STM.1 Environment *
18 IDS_ANL_EXT.1 Analyzer analysis (EXT) IDS_SDC_EXT.1 17
19 IDS_RCT_EXT.1 Analyzer react (EXT) IDS_SDC_EXT.1 17
20 IDS_RDR_EXT.1 Restricted Data Review (EXT) IDS_SDC_EXT.1 17
21 IDS_STG_EXT.1 Guarantee of System Data
Availability (EXT)
IDS_SDC_EXT.1 17
22 IDS_STG_EXT.2 Prevention of System data loss
(EXT)
IDS_SDC_EXT.1 17
* Reliable time is satisfied by the external time server in the Operational Environment
(OE.TIME)
6.3.2 Functional Requirements
Table 6-8 traces each SFR back to the security objectives for the TOE.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
81 of 105
Table 6-8: Requirements vs. Objectives Mapping
O.PROTCT
O.IDSCAN
O.IDSENS
O.IDANLZ
O.RESPON
O.EADMIN
O.ACCESS
O.IDAUTH
O.OFLOWS
O.AUDITS
O.INTEGR
O.EXPORT
O.AUDIT_PROTECTION
O.AUDIT_SORT
FAU_GEN.1 X
FAU_SAR.1 X
FAU_SAR.2 X X
FAU_SAR.3 X X
FAU_SEL.1 X X
FAU_STG.2 X X X X X X
FAU_STG.4 X X X
FIA_ATD.1 X
FIA_UAU_EXT.1 X X
FIA_UID.1 X X
FMT_MOF.1 X X X
FMT_MTD.1 X X X X
FMT_SMF.1 X X X X
FMT_SMR.1 X
FPT_ITT.1 X X
FTA_TAB.1 X
IDS_SDC_EXT.1 X X
IDS_ANL_EXT.1 X
IDS_RCT_EXT.1 X
IDS_RDR_EXT.1 X X X
IDS_STG_EXT.1 X X X X X
IDS_STG_EXT.2 X
ADV_ARC.1 X X X X X
The following discussion provides detailed evidence of coverage for each security objective:
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]. The TOE 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_EXT.1]. The TOE is required to
provide the ability to restrict modifying the behavior of functions of the TOE to
authorized users of the TOE [FMT_MOF.1]. Only authorized administrators of the TOE
may query audit data, and only authorized administrators of the TOE may query and
modify all other TSF data [FMT_SMF.1, FMT_MTD.1]. The TOE must ensure that all
functions are invoked and succeed before each function may proceed [ADV_ARC.1].
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
82 of 105
The TSF must be protected from interference that would prevent it from performing its
functions [ADV_ARC.1].
O.IDSCAN: The scanner must collect and store static configuration information that might be
indicative of the potential for a future intrusion or the occurrence of a past intrusion of an IT
System.
A TOE containing a scanner is required to collect and store static configuration
information from an IT System. The type of configuration information collected must be
defined in the ST [IDS_SDC_EXT.1].
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 TOE containing a sensor is required to collect events indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity by the assets
of an IT System. These events must be defined in the ST [IDS_SDC_EXT.1].
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_EXT.1].
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_EXT.1].
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 TOE must provide the ability for
authorized administrators to view all system data collected and produced
[IDS_RDR_EXT.1]. The TOE must ensure that all functions are invoked and succeed
before each function may proceed [ADV_ARC.1]. The TSF must be protected from
interference that would prevent it from performing its functions [ADV_ARC.1].
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 TOE is required to restrict the review of system data to
those granted with explicit read-access [IDS_RDR_EXT.1]. The TOE is required to
protect the audit data from deletion as well as guarantee the availability of the audit
data in the event of storage exhaustion, failure or attack [FAU_STG.2]. The TOE is
required to protect the system data from any modification and unauthorized deletion
[IDS_STG_EXT.1]. Users authorized to access the TOE are defined using an
identification and authentication process [FIA_UID.1, FIA_UAU_EXT.1]. The TOE is
required to provide the ability to restrict modifying the behavior of functions of the TOE
to authorized users of the TOE [FMT_MOF.1]. Only authorized administrators of the
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
83 of 105
TOE may query audit data, and only authorized administrators of the TOE may query
and modify all other TSF data [FMT_SMF.1, FMT_MTD.1]. The TOE is required to
present a warning banner when a user attempts to login to the TOE [FTA_TAB.1].
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 TOE is required to restrict the review of system data to
those granted with explicit read-access [IDS_RDR_EXT.1]. The TOE is required to
protect the stored audit records from unauthorized deletion [FAU_STG.2]. The TOE 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_EXT.1]. Security attributes of subjects used 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.1, FIA_UAU_EXT.1]. The TOE is required to provide the ability to restrict
modifying the behavior of functions of the TOE to authorized users of the TOE
[FMT_MOF.1]. Only authorized administrators of the TOE may query audit data, and
only authorized administrators of the TOE may query and modify all other TSF data
[FMT_SMF.1, 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
[ADV_ARC.1]. The TSF must be protected from interference that would prevent it from
performing its functions [ADV_ARC.1].
O.OFLOWS: The TOE must appropriately handle potential audit and system data storage
overflows.
The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure or attack
[FAU_STG.2]. The TOE must prevent the loss of audit data in the event its audit trail is
full [FAU_STG.4]. The TOE 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_EXT.1]. The TOE must
prevent the loss of audit data in the event its audit trail is full [IDS_STG_EXT.2].
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 [ADV_ARC.1]. The TSF must be protected
from interference that would prevent it from performing its functions [ADV_ARC.1].
O.INTEGR: The TOE must ensure the integrity of all audit and system data.
The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure or attack
[FAU_STG.2]. The TOE is required to protect the system data from any modification
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
84 of 105
and unauthorized deletion [IDS_STG_EXT.1]. Only authorized administrators of the
TOE may query audit data, and only authorized administrators of the TOE may query
and modify all other TSF data [FMT_SMF.1, FMT_MTD.1]. The TOE must protect the
collected data from modification and ensure its integrity when the data is transmitted to
another part of the TOE [FPT_ITT.1]. The TOE must ensure that all functions to protect
the data are not bypassed [ADV_ARC.1]. The TSF must be protected from interference
that would prevent it from performing its functions [ADV_ARC.1].
O.EXPORT: When any IDS component makes its data available to another IDS component,
the TOE will ensure the confidentiality of the system data.
The TOE must protect all data from modification and ensure its integrity when the data
is transmitted to another TOE component [FPT_ITT.1].
O.AUDIT_PROTECTION: The TOE must provide the capability to protect audit information.
The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure or attack
[FAU_STG.2]. The TOE must also prevent the loss of audit data in the event that its
audit trail is full [FAU_STG.4].
O.AUDIT _SORT: The TOE must provide the capability to sort the audit information.
The TOE is required to perform sorting of audit data based on date and time, subject
identity, type of event, and success or failure of related event [FAU_SAR.3].
6.3.3 Assurance Rationale
EAL2 was chosen to provide a low to moderate level of assurance that is consistent with good
commercial practices. As such, minimal additional tasks are placed upon the vendor assuming
the vendor follows reasonable software engineering practices and can provide support to the
evaluation for design and testing efforts. The chosen assurance level is appropriate with the
threats defined for the environment. While the TOE may monitor a hostile environment, it is
expected to be in a non-hostile position and embedded in or protected by other products
designed to address threats that correspond with the intended environment. At EAL2, the TOE
will have incurred a search for obvious flaws to support its introduction to the non-hostile
environment.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
85 of 105
7 TOE Summary Specification
7.1 IT Security Functions
Section 7 describes the specific Security Functions of the TOE that meet the criteria of the
security features that are described in Section 1.4.8 Logical Scope of the TOE. The following
sub-sections describe how the TOE meets each SFR listed in Section 6.
Table 7-1: Security Functional Requirements Mapped to Security Functions
Security Functions Sub-Functions SFRs
Security Audit AU-1
Audit Generation
FAU_GEN.1
AU-2
Audit Review
FAU_SAR.1
FAU_SAR.2
FAU_SAR.3
AU-3
Audit Selection
FAU_SEL.1
AU-4
Audit Record Protection
FAU_STG.2
FAU_STG.4
User I&A IA-1
User Security Attributes
FIA_ATD.1
IA-2
User Identification & Authentication
FIA_UAU_EXT.1
FIA_UID.2
Security Management SM-1
Management Functions
FMT_MOF.1
FMT_MTD.1
FMT_SMF.1
SM-2
Management Security Roles
FMT_SMR.1
Protection of Security PT-1
Internal Data Transfer Protection
FTP_ITT.1
TOE Access Functions TA-1 TOE Login Information FTA_TAB.1
Intrusion Detection System ID-1
System Data Collection
IDS_SDC_EXT.1
ID-2
System Data Analysis
IDS_ANL_EXT.1
ID-3
Analyzer Alarms
IDS_RCT_EXT.1
ID-4
System Data Review
IDS_RDR_EXT.1
ID-5
System Data Protection
IDS_STG_EXT.1
IDS_STG_EXT.2
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
86 of 105
7.1.1 Security Audit Functions
7.1.1.1 AU-1: Audit Generation
(FAU_GEN.1)
Auditing is the recording of events within the system. The TOE records two classes of events:
security events and IDS events. IDS events are dealt with separately under the System Data
security functions. Security events relate to the proper functioning and use of the system, and
allow a TOE administrator to track the management functions performed.
The following events are audited by the TOE:
a) Startup and shutdown of the audit function
b) Access to the system
c) Access to the TOE and system data
d) Viewing of the audit records
e) Unsuccessful attempts to view the audit records
f) All modification to the audit configuration that occurs during collection
g) Actions taken due to an audit storage failure
h) All identification and authentication attempts, including the user and location where
authentication was attempted
i) All modification to the behavior of the TSF
j) All modifications to TSF data values
k) Creation, deletion, and modification of user accounts
Defense Centers and 3D Sensors with IPS log read-only auditing information for user activity
in the Sourcefire 3D System audit log. The audit log stores a maximum of 100,000 entries in
the MySQL database of the component. Each component generates an audit event for each
user interaction with the web interface. The following fields are recorded for each audit event
in the audit log table:
 Time: The time and date that the appliance generated the audit record.
 User: The user name of the user that triggered the audit event.
 Subsystem: The menu path the user followed to generate the audit record. For
example, “Operations > Monitoring > Audit” is the menu path to view the audit log.
 Message: The action the user performed. For example, “Page View” signifies that the
user simply viewed the page indicated in the Subsystem, while “Save” means that the
user clicked the Save button on the page.
 Source IP: The IP address of the host used by the user.
In addition to the audit log described above, the TOE records audit information in the system
log (syslog) of the Defense Center and 3D Sensor with IPS components. The system log
displays each message generated by the TOE for system events such as the startup and
shutdown of the TOE. System log information for each component can be viewed on the
System Log page of the WebUI. The following items are listed in order:
 The date the message was generated
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
87 of 105
 The time the message was generated
 The host that generated the message
 The message itself
AU-1: Audit Generation relies on the Operational Environment to supply reliable timestamps
for the audit records. (OE.TIME) AU-1 also relies on the Operational Environment to provide
secure communications between the TOE and the external Time Server.
(OE.PROTECTCOMM)
7.1.1.2 AU-2: Audit Review
(FAU_SAR.1, FAU_SAR.2, FAU_SAR.3)
The management interfaces of the TOE allow only users who have the Administrator Role to
view security audit data for the system.
While viewing the security audit records, the audit review interface, available from the Defense
Center and 3D Sensor with IPS GUIs, provides the ability to sort the data for display based
upon the following properties:
 Date and Time
 User
 Type of event (subsystem field)
 Success or Failure of the event (contained in the message field)
In addition to sorting, searches of the audit records are available to users having the
Administrator Role as well.
7.1.1.3 AU-3: Audit Selection
(FAU_SEL.1)
Suppression lists can be created for audit events based on IP address, message, subsystem,
and username. Any one of these four field types can be suppressed, preventing the audit
event from being generated.
To set up the suppression mechanism, a TOE administrator must have access to the Defense
Center‟s or 3D Sensor with IPS‟s root user account and must be able to access the Defense
Center or 3D Sensor with IPS operating system‟s shell (CLI). It must be assumed that only
authorized and limited personnel have access to the component‟s operating system and to its
root account. The audit suppression lists are created or modified at installation or during
maintenance; this functionality is not available through the WebUI.
To suppress audit records one or more files must be created in the /etc/sf directory in the
following form:
AuditBlock.type
where type is: IP address, message, subsystem, or username.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
88 of 105
The contents for each audit block type must be in a specific format as described below:
 IP address - Create a file named AuditBlock.address and include, one per line, each
IP address that will be suppressed from the audit log.
 message - Create a file named AuditBlock.message and include, one per line, the
message substrings that will be suppressed. Substrings are matched so that if the file
includes “backup”, all messages that include the word “backup” are suppressed.
 subsystem - Create a file named AuditBlock.subsystem and include, one per line,
each subsystem that will be suppressed. Substrings are matched so that if the word
“Health” is included in the file, both the “Health” and the “Health Events” subsystems
are suppressed. The subsystem names and the definition of the events audited by
each are listed below:
o Admin - administrative features such as system and access configuration, time
synchronization, backup and restore, sensor management, user account
management, and scheduling.
o Alerting - the alerting functions such as email, SNMP, and syslog alerting
o Audit Log – audit event views
o Audit Log Search – audit event searches
o Configuration – email alerting
o Coop - the continuity of operations feature.
o Date - the date and time range for event views.
o Default Subsystem - options that do not have assigned subsystems
o Detection & Prevention Policy – menu options for intrusion policies
o Error - system-level errors
o EULA – reviewing the end user license agreement
o Events – intrusion event views
o Events Clipboard - the intrusion event clipboard
o Events Reviewed - reviewed intrusion events
o Events Search - any event search
o Header - the initial presentation of the user interface after a user logs in.
o Health - health monitoring
o Health Events - health monitoring event views
o Help - the online help
o High Availability - the high availability feature
o IDS Impact Flag - impact flag configuration
o IDS Policy - intrusion policies
o IDSPolicy > policy_name > Appliance > det_engine_name - applying
intrusion policies
o IDSRule sid:sig_id rev:rev_num - intrusion rules by SID.
o Incidents - intrusion incidents
o Insert Policy Apply Job - applying policies
o Install - installing updates
o Intrusion Events - intrusion events
o Login – web interface login and logout functions
o Menu - any menu option
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
89 of 105
o Object export > obj_type > obj_name - importing objects of a specific type
and name
o Preferences - user preferences such as the time zone for a user account and
individual event preferences
o Policy - any policy, including intrusion and OPSEC policies
o Register - registering sensors on a Defense Center
o RemoteStorageDevice - configuring remote storage devices
o Reports - the report listing and report designer features
o Rules - intrusion rules including the rule editor and the rule importation process.
o Status - the syslog, as well as host and performance statistics
o System - various system-wide settings
o System Policy > policy_name Appliance > appliance_name - applying
system policies
o Task Queue - the task queue
o Users - creating and modifying user accounts
Note: subsystems pertaining to features not included in the scope of the evaluation
(e.g. SEU) have not been included in this list
 Username - Create a file named AuditBlock.user and include, one per line, each user
account that will be suppressed.
7.1.1.4 AU-4: Audit Record Protection
(FAU_STG.2, FAU_STG.4)
The audit records are protected by the access control functionality of the MySQL database
and the Linux-derived operating systems of the 3D Sensors with IPS and Defense Center. The
only way to access the audit records is through the Defense Center and 3D Sensor with IPS
GUIs. The TOE provides protection for the security audit records primarily by preventing
access to the system without successful authentication. Subsequently, the TOE requires that a
user must have the Administrator Role before it grants access to the audit records via the audit
record management functions. Further, since the audit function starts automatically with the
TOE, and cannot be disabled, all selected (see FAU_SEL.1) actions are recorded, including
possible modification to the records.
As indicated below, when the available audit storage is exhausted, the TOE automatically
overwrites the oldest audit events. This ensures that the availability of the most recent audit
events is limited only by the size of the audit trail.
When the TOE begins to run out of storage space for the audit records, (85% of the
appliance‟s disk capacity is allotted for record storage) or the database limit of 100,000 has
been reached, the oldest audit events are pruned until the database is back within limits. This
can also occur if the event database, security databases, or the log files grow and exceed the
85% limit for the /var disk partition of the appliance‟s OS. If the audit process runs out of disk
space or the database limit is exceeded, then the oldest current log files will be automatically
overwritten to prevent new actions from occurring without being tracked.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
90 of 105
The TOE can be configured so that a warning is sent to a designated TOE administrator via
email to inform them when the audit records are automatically overwritten.
Note: The administrator must perform periodic backups of the audit data (via the WebUI
backup function) to prevent loss of data.
AU-4: Audit Record Protection relies on an Email Server in the environment to send warnings
to the designated TOE administrator when the audit data is overwritten. (OE.ALARMS) AU-4
also relies on the Operational Environment to provide secure communications between the
TOE and the external Email Server. (OE.PROTECTCOMM)
7.1.2 User I&A Functions
7.1.2.1 IA-1: User Security Attributes
(FIA_ATD.1)
User account information is stored in the TOE and contains the following attributes:
 User Name
 Authentication Data (password)
 Assigned Role(s) (authorizations).
 Use External Authentication Method – If selected, the user's credentials are to be
externally authenticated. If selected and the external authentication server is
unavailable, the user cannot log into the Defense Center.
 Force Password Reset on Login – If selected, the TOE forces the user to change his
password the first time he logs in.
 Password Strength Check – If selected, the TOE enforces strong passwords. A
strong password must be at least eight alphanumeric characters of mixed case and
must include at least one numeric character. It cannot be a word that appears in a
dictionary or include consecutive repeating characters.
 Max Number of Failed Logins – A value that determines the maximum number of
times each user can try to login after a failed login attempt before her account is
locked. The default setting is five tries; if set to zero, the TOE allows an unlimited
number of failed logins. This attribute cannot be changed after the user account is
created.
 Password Expiration – The number of days after which the user‟s password will
expire. The default setting is zero, which indicates that the password never expires.
This attribute cannot be changed after the user account is created.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
91 of 105
 Warning Days – The number of warning days users have to change their password
before their password actually expires. The default setting is 0 days. The number of
warning days must not exceed the number of days before the password expires. This
attribute cannot be changed after the user account is created.
A user account can have multiple roles assigned, which allows a broader and more focused
set of privileges. The user account information is stored in a TSF database that is modifiable
only by an authorized user with the Administrator Role. The user account passwords stored in
the database are protected by a one-way hash (MD5). After adding user accounts to the
system, a user‟s assigned roles or password may be modified at any time.
Note: The password management attributes do not apply to users who authenticate to an
external authentication server. Those settings are managed on the external server.
7.1.2.2 IA-2: User Identification & Authentication
(FIA_UAU_EXT.1, FIA_UID.1)
Each individual must be successfully identified and authenticated with a username and
password by the TSF before access is allowed to the TOE.
User identification and authentication by the TSF uses the security attributes of the user
account described in Section 7.1.2.1 above. When identification and authentication data is
entered, the TOE attempts to identify the applicable user account from the provided identity
and if a match is found, the password provided is compared against that stored with the user
account information. If a user account cannot be associated with the provided identity or the
provided password does not match that stored with the user account information, identification
and authentication will fail. No actions are allowed, other than entry of identification and
authentication data, until successful identification and authentication.
Creation of a TSF authenticated TOE user through the WebUI does not give that user an
account on any of the Sourcefire 3D System appliances‟ LINUX-based operating systems (use
of the CLI). Conversely creating a OS user account on an appliance does not create a user
account in the TSF; i.e. when a shell access (CLI) user logs into an appliance, a TOE user
account is not created and that user does not have access to the management functions of the
WebUI.
Alternately, the TOE can be configured to use an external authentication service for user
identification and authentication. Both LDAP and RADIUS servers are supported. However,
the use of an external authentication server requires a TOE configuration that includes a
Defense Center; a stand-alone 3D Sensor with IPS configuration cannot use external
authentication.
A locally authenticated user (one who is authenticated by the TSF) is automatically converted
to an externally authenticated user if:
 External authentication is enabled (the Use External Authentication Method attribute
is set for that user account),
 The same username exists for the user on the external server, and
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
92 of 105
 The user logs in using the password stored for that user on the external server.
Important: Once a locally authenticated user is converted to an externally authenticated user,
that user account cannot changed back to use local authentication.
For LDAP authentication, an LDAP authentication object must be created to provide user
authentication services for the appliance. The Administrator uses the Defense Center Web
GUI to:
 define settings for the connection to the LDAP server
 select the directory context
 define search criteria used to retrieve user data from the server
 optionally configure shell access authentication
The LDAP directory server can be optionally used to authenticate accounts for shell access
(use of CLI) on a local appliance (3D Sensor or Defense Center). Note that an Administrator
can only configure shell access for the first authentication object in the system policy. Shell
users are not configured as local users (TOE users) on the appliance, even after they log in.
Addition and deletion of shell access users occurs only on the LDAP server, and the filter set
there determines which set of users on the LDAP server can log into the CLI of the appliance.
Similarly, for RADIUS authentication, a RADIUS authentication object must be created. The
Administrator uses the Defense Center Web GUI to:
 define settings for the connection to the RADIUS server
 grant user roles to specific and default users
 define custom attributes if the RADIUS server returns custom attributes
 optionally configure shell access authentication
As with LDAP authentication, the RADIUS server can be used to authenticate accounts for
shell access (use of CLI) on a local appliance (3D Sensor or Defense Center). The
Administrator specifies user names for users who are granted shell access. Only the first
authentication object in the system policy can be configures for shell access. With the
exception of the root account, the shell access list set on the RADIUS authentication object
entirely controls shell access on the appliance. Shell users are configured as local users on
the appliance when the system policy is applied.
Note: Both LDAP and RADIUS servers require TCP/IP access from the local appliance to the
authentication server.
IA-2: User Identification & Authentication relies on the Operational Environment to provide an
external authentication service if either LDAP or RADIUS authentication is configured.
(OE.XAUTH) IA-2 also relies on the Operational Environment to provide secure
communications between the TOE and the authentication server. (OE.PROTECTCOMM)
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
93 of 105
7.1.3 Security Management Functions
7.1.3.1 SM-1: Management Functions
(FMT_MOF.1, FMT_MTD.1, FMT_SMF.1)
The TOE requires user authentication before any actions (other than entry of identification and
authentication data) can be performed through the TOE interfaces (the WebUI of the Defense
Center and the 3D Sensor with IPS). Access to TSF data and management functions are
restricted by a user‟s assigned role(s) as specified in FMT_MTD.1 (see Section 6.1.3.2
FMT_MTD.1 Management of TSF data).
Use of the Defense Center and 3D Sensor with IPS WebUI requires a management console
with a properly configured web browser as specified in Section 1.3.2
Hardware/Firmware/Software Required by the TOE.
A detailed list of the menu options of the TOE‟s GUIs and the user account privileges (roles)
needed to access each option is provided in Chapter 33 (pages 1540 to 1547) of [USER].
A stand-alone 3D Sensor with IPS configuration has the same user account types as a
configuration that uses the Defense Center. The stand-alone sensor GUI has the same
functionality as the Defense Center GUI with the following exceptions:
 A sensor cannot manage other sensors, so the „Sensors‟ menu option is hidden on the
sensor GUI; therefore management functions such as creating a sensor group, or
pushing a policy to a sensor only applies to the Defense Center GUI.
 Health monitoring is a Defense Center feature, so that option is not available on the
sensor GUI.
 The sensor GUI does not support custom tables.
 External authentication of users is only applicable to a Defense Center configuration.
The management functions available only through the Defense Center WebUI are indicated in
Table 6-4: Management of TSF data.
SM-1: Management Functions depends on the Operational Environment for an administrative
console with a properly configured Web Browser to support the TOE‟s management
interfaces.
7.1.3.2 SM-2: Management Security Roles
(FMT_SMR.1)
The TOE has six defined roles, each with its own set of privileges. When a new user account
is created, it must be assigned a role. A user may be assigned more than one role. No access
is allowed to the system until a user has been authenticated and access to TSF data and
functions is controlled by the TOE‟s interfaces only to the data and functions allowed to the
authenticated user‟s role.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
94 of 105
All users of the TOE have access to TSF data and management functions, and therefore are
considered administrators for the purposes of this evaluation. The terms “TOE user”, “TOE
administrator” and “authorized administrator” are used in this ST to refer collectively to all
authorized TOE users.
The defined roles for TOE users are:
 “Administrator”: this role can perform all management functions on the TOE. A user
with this role can manage user accounts; view, query, delete and configure the security
and IDS event logs; and manage the rules that govern the IDS.
 “Maintenance”: this role can view status, system time, and the reporting functionality
of the product. Additionally, users with this role can perform system level maintenance
related actions.
 “Intrusion Event Analyst”: this role can view, query, and delete IDS event data. They
can also create incidents and generate reports.
 “Intrusion Event Analyst (Read Only)”: this role has read-only access to IPS
analysis features, including intrusion event views, incidents, and reports. Users with the
Intrusion Event Analysts (Read Only) role see only the main toolbar and IPS analysis-
related options on the „Analysis & Reporting‟ and „Operations‟ menus.
 “Restricted Event Analyst”: this role provides access to the same features as the
Intrusion Event Analyst role, but is restricted to only those events that match specified
search criteria (specific IP Addresses or subsets of data). They can be denied access
for an entire category of events. Users with the Restricted Event Analyst Role see only
the main toolbar and analysis-related options on the „Analysis & Reporting‟ and
„Operations‟ menus.
 “Restricted Event Analyst (Read Only)”: this role is the same as the Restricted
Event Analyst role except that users have read-only access to the intrusion events that
match the specified search criteria.
 “Policy and Response Administrator”: this role can create, modify, and implement
rules and intrusion policies for the IDS. This role cannot perform other functions.
Note: The Sourcefire 3D System product also maintains the role: RNA Event Analyst.
However, the RNA functionality is not in the scope of the evaluation and so this role is not
used in the TOE.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
95 of 105
7.1.4 Protection of Security Functions
7.1.4.1 PT-1: Internal Data Transfer Protection
(FPT_ITT.1)
The TSF ensures that data transmitted between separate parts of the TOE are protected from
disclosure or modification. This protection is ensured by transmission of data between the
Defense Center and the 3D Sensor(s) with IPS over a secure, SSL-encrypted TCP tunnel. The
TOE uses OpenSSL Version 0.9.8g.
There are four types of communications that can occur between TOE components:
 event transmission
 status updates
 remote copy
 remote execution
All communications between TOE components use the Management Network: a private
protected network used only by the Defense Center and the 3D Sensors with IPS. All
communications go through a single channel in the Linux-derived operating systems installed
on the appliances, which uses the following encryption strength:
Cipher used = AES256-SHA (strength:256 bits), which is (DHE-RSA-AES256-SHA)
Note: The cryptography used in this product has not been FIPS certified nor has it been
analyzed or tested to conform to cryptographic standards during this evaluation. All
cryptography has only been asserted as tested by the vendor.
Note: This function is not applicable for the stand-alone sensor configuration of the TOE.
7.1.5 TOE Access Functions
7.1.5.1 TA-1 TOE Login Information
(FTA_TAB.1)
The TOE has the functionality to present warning information to a user when attempting to
login.
Users with the Administrator role can create a custom login banner to display an advisory
warning message regarding unauthorized use of the TOE. The banner appears when users
log into an appliance (Defense Center or 3D Sensor with IPS) on the login page of WebUI.
Banners can contain any printable characters except the less-than symbol („<‟) and the greater
than symbol („>‟). Custom login banners are part of the system policy. The login banner can be
specified either by creating a new system policy or by editing an existing policy. In either case,
the new or modified login banner will not be displayed until the System Policy is applied.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
96 of 105
There is no limit to the number of characters that can be entered in the login banner field
through the WebUI, but the banner is truncated to a 64K character limit for display.
7.1.6 Intrusion Detection System Functions
7.1.6.1 ID-1: System Data Collection
(IDS_SDC_EXT.1)
The TOE has the ability to set rules to govern the collection of data regarding potential
intrusions. Each 3D Sensor with IPS uses rules, decoders, and preprocessors to look for the
broad range of exploits that attackers have developed. While the TOE contains default
intrusion rules to detect currently known attacks and exploits, new rules can be created to
detect attacks most likely to occur in a given environment. This allows the TOE administrators
control over the types of traffic that will be monitored. The 3D Sensors with IPS run decoders
and preprocessors against detected network traffic to normalize traffic and detect malicious
packets.
The TOE collects network traffic information from the target IT System resources including:
 Date and time
 Type of event
 Subject identity (e.g., source address or addresses)
 Outcome of the event (e.g., packet met an intrusion rule and was dropped)
 The additional information specified in the Details column of Table 6-5: System Events:
o Protocol
o Source address
o Destination address
ID-1: System Data Collection relies on the Operational Environment to provide reliable
timestamps for the collected data records. (OE.TIME) ID-1 also relies on the Operational
Environment to provide secure communications between the TOE and the external Time
Server. (OE.PROTECTCOMM)
7.1.6.2 ID-2: System Data Analysis
(IDS_ANL_EXT.1)
A detection engine is the mechanism on a 3D Sensor that is responsible for analyzing the
traffic on the network segment where the sensor is connected. The TOE uses the IPS type of
detection engine. A detection engine has two main components:
 an interface set, which can include one or more sensing interfaces
 a detection resource, which is a portion of the sensor‟s computing resources
Administrators can create, edit and delete detection engines through the WebUI management
functions.
Intrusion policies include a variety of components that are configured to inspect network traffic
for intrusions and policy violations. These components include preprocessors; intrusion rules
that inspect the protocol header values, payload content, and certain packet size
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
97 of 105
characteristics; and tools that control how often events are logged and displayed. Five default
intrusion policies are delivered with the Sourcefire 3D System. Administrators and Policy and
Response Administrators can create, edit, delete and apply intrusion policies.
When an intrusion policy is created, variable definitions can be included as part of the policy.
Variables represent values that are commonly used within intrusion rules. The Sourcefire 3D
System provides predefined variables for use within rules. When intrusion policy is applied to a
detection engine, those variables are used in conjunction with the detection engine to monitor
network traffic and generate events.
Besides the predefined variables, a variable with the reserved name USER_CONF can be
used to configure features not otherwise available via the standard WebUI menu items (Non-
Standard Features). USER_CONF can be used as an intrusion policy variable or as an IPS
detection engine variable. IPS recognizes only one definition of USER_CONF for each
detection engine, and that definition takes effect when an intrusion policy is applied to the
detection engine.
Users must therefore be careful not to use the reserved variable USER_CONF to configure an
IPS feature unless they are instructed to do so in the feature description or by Sourcefire
Support. Conflicting or duplicate configurations will halt IPS. Deleting USER_CONF from any
intrusion policy or detection engine deletes it from all intrusion policies and detection engines.
To analyze the network data collected, the TOE uses signatures, decoders and preprocessors.
Signatures 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 IDS also provides the
ability to detect these more complex patterns through decoders and preprocessors that are
included in the TOE. Rules are used to embody signatures, decoders and preprocessors in the
TOE. The TOE is packaged with default signatures for known exploits, and the TOE
administrators can add new signatures at any time.
New signatures are available from the Sourcefire support organization and from public Snort
forums. The evaluated configuration of the TOE does not allow importing SEUs, which contain
updated signatures and rules, since an SEU may also contain new binaries, including new
versions of Snort, which will alter the TOE. However, the signature data on the Sourcefire and
public Snort sites can be used by the TOE administrators to manually update and create rules
and policies.
The WebUI provides a graphical rule editor that allows the creation and modification of
signatures through the use of standard GUI controls (check boxes, drop down lists …).
Custom rules may be created by the Administrator or Policy and Response Administrator. Use
of the WebUI to create custom rules is described in detail in Chapter 25: Understanding and
Writing Intrusion Rules, of [USER].
The Administrator or Policy and Response Administrator may also import a text rule file that
has been created with a text editor on a local machine. Importation of a local rule file is
available through the „Policy & Response > IPS > Rules‟ menu of the WebUI.
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
98 of 105
Signatures are used for stateless detections, those intrusion attempts that can be detected
with individual packets. Signatures cannot be used to detect intrusions that require multiple
packets, such as a Denial of Service attack. To detect these types of events, the IDS uses
various decoders and preprocessors for stateful inspections, which allow these multi-packet
intrusions to be detected. Decoders and preprocessors can also provide detection of
malformed packets.
All signatures entered into the TOE by any means, must conform to this format:
<type field> <protocol field> <source IP> <source port> <operator> <destination IP>
<destination port> (option1; option2; …; optionN)
Header – defines the network addresses involved for the traffic to be considered for evaluation
by the signature options:
 <type field> - Identifies the action the system should take when a packet triggers the
rule.
o Alert - Sends an alert then logs the details about the packet that triggered the
event
o Drop – Drops the packet that triggered the event
o Pass - Ignores the packet that triggered the event
 <protocol field> - Specifies the protocol of the packets against which the rule executes.
o TCP - Executes against traffic using the Transmission Control Protocol
o UDP - Executes against traffic using the User Datagram Protocol
o ICMP - Executes against traffic using the Internet Control Message Protocol
o IP - Executes against traffic using the Internet Protocol
 <source IP> - Specifies the source IP address or range of addresses.
o Any - Executes against packets from any source IP.
o Numeric IP address - Executes against packets with the specified source IP.
o CIDR blocks - Executes against packets whose source IP address falls within
the specified CIDR block.
 <source port> – Specifies the source port.
o Any - Executes against traffic with any source port
o Numeric - Executes against traffic with the specified source port
o Numeric: numeric - Executes against traffic with the specified range of source
ports
o ! numeric - Executes against traffic with any source port except the port
specified after the exclamation point (!)
 <operator> - Specifies the direction of the traffic to which the rule applies
o Evaluates all traffic from the source IP to the destination IP
o Evaluates traffic between the source IP to the destination IP
 <destination IP> - Specifies the destination IP address or range of addresses
o Any - Executes against packets with any destination IP. For example, in the
following rule, the any in bold specifies any destination IP address: alert tcp any
any -> any any (rest of rule)
o Numeric IP address - Executes against packets with the specified destination
IP. For example, in the following rule, the numbers in bold specify a specific
destination IP address: alert tcp any any -> 192.168.17.1 any (rest of rule)
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
99 of 105
o CIDR blocks - Executes against packets whose destination IP address falls
within the specified CIDR block. For example, in the following rule, the
bracketed numbers specify a range of destination IP address: alert tcp any any
-> [10.1.0.0/16,192.168.1.2/24] any (rest of rule)
 <destination port> - Specifies the destination port
o Any - Executes against traffic with any destination port
o Numeric - Executes against traffic with the specified destination port
o Numeric: numeric - Executes against traffic with the specified range of
destination ports
o ! numeric - Executes against traffic with any destination port except the port
specified after the exclamation point (!)
Options – defines the attributes of a packet that must be inspected to determine whether the
packet is a match for a specific signature. Options are defined as a keyword and a value, and
are listed as keyword:value within the options field of the signature. Chapter 23:
Understanding Keywords and Arguments in Rules (pages 1142 through 1206) of [USER] lists
the keywords and how to use them when writing or modifying a rule.
The following decoders and preprocessors are available for the detection of stateful or
malformed intrusions:
 Checksum Verification - Verifies the size of packets being sent to the network,
detecting malformed packets that may be used in various attacks.
 Packet IP Defragmentation - Enables the TOE to rebuild packets that have been
fragmented by the network prior to inspection against other decoders, preprocessors,
and signatures.
 Stateful Inspection & TCP Stream Reassembly - Provides stateful inspection of
packets, allowing detection of intrusion attempts that span multiple packets. The
Stream reassembly allows detection of sessions between clients and servers, and then
the analysis of this traffic for specific patterns.
Note: The TOE provides two transport-layer data stream preprocessors, Stream 4 and
Stream 5. Only one TCP stream preprocessor can be enabled at a time. The Stream 5
preprocessor has improved performance and IPS capabilities and must be enabled for
the evaluated configuration of the TOE. Only the Stream 5 preprocessor was tested
and included in the Common Criteria evaluation.
 RPC Decode - Decodes RPC traffic for analysis against signatures (similar to HTTP
Normalization).
 Back Orifice Detection - Searches for packets that can show the presence of Back
Orifice, or attempts to install Back Orifice onto computers on the network.
 HTTP Inspection Preprocessor - (HTTP Decode and Normalization) Responsible for:
o Decoding the URI portion of HTTP requests into non-obfuscated ASCII
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
100 of 105
o Normalizing the HTTP request Headers
o Detecting and generating events against possible URI-encoding attacks
o Making the extracted and normalized data, Method, URI, Headers, and Client
Request components of the HTTP request are available for additional rule
processing
o Generating an event when HTTP traffic is received by ports not specified as
web server ports in an intrusion policy
 SMTP Decode and Normalization - Decodes SMTP traffic for analysis against
signatures (similar to HTTP Normalization).
 Telnet Decode and Normalization - Decodes Telnet traffic for analysis against
signatures (similar to HTTP Normalization).
 FTP Decode and Normalization - Decodes the FTP command channel for analysis
against signatures (similar to HTTP Normalization).
 DCE/RPC Inspection - Examines DCE/RPC traffic for fragmented request packets,
and reassembles them so the rules engine can inspect the complete packets.
 DNS Inspection - Inspects DNS name server responses for the following specific
exploits:
o Overflow attempts on RData text fields
o Obsolete DNS resource record types
o Experimental DNS resource record types
 SSL Inspection – Analyzes the contents of the handshake and key exchange
messages exchanged at the beginning of an SSL session to determine when the
session becomes encrypted; makes the SSL version and state information available for
additional rule processing.
 Portscan - Determines which ports are open on the host and, either directly or by
inference, which services are running on these ports; designed to help determine which
portscans might be malicious by detecting patterns of activity and generating events
accordingly.
When a decoder or a preprocessor identifies anomalous protocol behavior, or when a
signature has been matched to a traffic pattern, the specific event is recorded in the System
Data log where it can be viewed by users with either the Administrator or Intrusion Event
Analyst Roles. The events are logged with the following information:
 the event type and signature
 decoder, or preprocessor match
 the time and date of the event
 the data source
 a copy of the packets used to identify the pattern
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
101 of 105
7.1.6.3 ID-3: Analyzer Alarms
(IDS_RCT_EXT.1)
When a decoder, a preprocessor or statistical analysis identifies anomalous behavior, or when
signature matches are found, they can either be logged for later use or set to trigger an alarm
and immediately notify a specific person of critical events via email alerts. This is part of the
configuration of active signatures and intrusion policies. The TOE can also be configured to
enable logging to syslog facilities or send event data to an SNMP Trap Server.
Email Alerting
Email alerts are notifications of intrusion events by email. Email alerts include the following
information:
 total number of alerts in the database
 last email time (the time that the system generated the last email report)
 current time (the time that the system generated the current email report)
 total number of new alerts
 number of events that matched specified email filters (if events are configured for
specific rules)
 timestamp, protocol, event message, and session information (source and destination
IPs and ports with traffic direction) for each event (if Summary Output is off)
If multiple intrusion events originate from the same source IP, a note appears beneath
the event that displays the number of additional events.
 number of events per destination port
 number of events per source IP
For each rule or rule group, the TOE administrators can enable or disable email alerting on
intrusion events. Email alerting can be configured for any detection engine on the appliance
rather than per detection engine. The email alert settings are used regardless of the policy in
place for each detection engine on the sensor.
Syslog Alerting
The TOE can send syslog alerts, which are intrusion event notifications, to the syslog on an
appliance. The syslog allows authorized administrators to categorize information in the syslog
by priority and facility. The priority reflects the severity of the alert and the facility indicates the
subsystem that generated the alert. Facilities and priorities are not displayed in the actual
message that appears in syslog, but are instead used to tell the system that receives the
syslog message how to categorize it. Syslog messages are stored in flat files on the appliance.
Syslog alerts contain the following information:
 date and time of alert generation
 event message
 event data
 generator ID of the triggering event
 Snort ID of the triggering event
 revision
In an intrusion policy, the authorized administrators can turn on syslog alerting and specify the
syslog priority and facility associated with intrusion event notifications in the syslog. When the
policy is applied to a detection engine, the detection engine then sends syslog alerts for the
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
102 of 105
intrusion events it detects to the syslog facility on the appliance or to a logging host (external
Syslog Server) specified in the policy. The host receiving the alerts uses the facility and priority
information that has been set when configuring syslog alerting to categorize the alerts.
SNMP Alerting
An SNMP trap is a network management notification. The authorized administrators can
configure the sensor to send intrusion event notifications as SNMP traps, also known as
SNMP alerts. Each SNMP alert includes:
 the name of the server generating the trap
 the IP address of the sensor that detected it
 the name of the detection engine that detected it
 the event data
Intrusion event response SNMP traps use the Message Digest 5 (MD5) authentication protocol
and the Data Encryption Standard (DES) privacy protocol. In addition to enabling and disabling
SNMP alerting, a variety of parameters can be set depending on the version of SNMP used.
SNMP alerting requires either SNMP v2 or v3. SNMP v1 is not supported by the TOE.
If the 3D Sensor with IPS is deployed inline and traffic flows through a pair of interfaces on the
sensor, the detection engine of the sensor can block possible intrusions by dropping
suspicious traffic or replace harmful content in a packet if specified to do so by an intrusion
policy.
ID-3: Analyzer Alarms relies on an Email Server in the environment to send Email Alarms to a
designated TOE administrator. Analyzer Alarms may also use an external Syslog Server
and/or SNMP Trap Server to send alarms. (OE.ALARMS) ID-3 also relies on the Operational
Environment to provide secure communications between the TOE and the external servers.
(OE.PROTECTCOMM)
7.1.6.4 ID-4: System Data Review
(IDS_RDR_EXT.1)
Only successfully authenticated users can access the TOE, and then only users with either the
Administrator or Intrusion Event Analyst Roles can view the IDS events collected and
analyzed. The data gathered is interpreted into a readable format for the authorized
administrators and can then be viewed through the web-based management interfaces.
The Defense Center WebUI allows the authorized administrators to view and interpret the
aggregation of the collected and analyzed data from multiple 3D Sensors with IPS.
7.1.6.5 ID-5: System Data Protection
(IDS_STG_EXT.1, IDS_STG_EXT.2)
The TOE protects the gathered system (event) data logs from unauthorized modification or
deletion by presenting only the web-based interface to all users. No users are allowed to edit
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
103 of 105
the logs; they are marked for read-only access, preventing user modification. Only users with
the Administrator, Restricted Event Analyst, or Intrusion Event Analyst Roles can delete the
logs.
To prevent loss of new/current event data, there are three mechanisms to limit event data loss:
event database limit, audit record limit (refer to FAU_STG.4 "Prevention of Audit Data Loss"
for more detail), and disk capacity. A user with the Administrator Role can set a size limit for
the number of events stored in the appliance database. The TSF overwrites the oldest events
when it reaches the defined database limit or appliance size limit for the event records. This
limits the number of events that can be stored in the database and allows for new event
insertions. The database limits for intrusion events are 2 million for the 3D Sensors with IPS,
and from 2.5 million to 100 million for the Defense Center depending on the model of the
appliance. When the disk space of the appliance reaches 85% of its capacity, the TSF will
delete as few log files as possible to keep the space below 85% capacity. These mechanisms
maintain the system disk space in order to handle the case when a flood of data comes in
before overwriting can occur and always ensures that more than one event can always be
added in the log.
The TOE can be configured so users assigned to the Administrator Role will receive an email
warning when the event data is automatically overwritten.
Note: The administrator must perform periodic backups of the event data (via the WebUI
backup function) to prevent loss of data.
ID-5: System Data Protection relies on an Email Server in the environment to send warnings to
the designated TOE administrator when the system data is overwritten. (OE.ALARMS) ID-5
also relies on the Operational Environment to provide secure communications between the
TOE and the external Email Server. (OE.PROTECTCOMM)
7.2 TOE Protection against Interference and Logical Tampering
The TOE consists of both hardware (the 3D Sensor with IPS and Defense Center appliances)
and software (the Sourcefire 3D System applications, the MySQL database, the Linux-derived
operating system and the supporting 3rd
party applications installed on the appliances).
The TOE offers only well defined services at its network interfaces that are specifically
designed to provide only the services that are necessary to enforce the TSP and not to offer
additional services that might be used to interfere with the operation of the TOE.
The TOE protects the security functions it provides through a variety of mechanisms. One of
the primary protections is that TOE users must authenticate before any administrative
operations can be performed on the system, including creating new rules or viewing the IDS
data. Access to the TOE is also protected by the access control functions of the database and
operating system installed on the appliance.
The IDS collection portion of the TOE is 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 TOE, which
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
104 of 105
prevents it from being accessed as a network device on the network. In addition, the rule set is
protected doubly as the system is configured to not accept any management requests or input
from the monitored network.
TSF data stored in the database is protected by the security mechanisms of the MySQL
database. Data files and configuration files are protected by the security mechanisms of the
Linux-derived operating systems on the appliances. Communications between the 3D Sensors
with IPS and the Defense Center are on a protected network separate from the monitored
network. All data transmitted between TOE components is protected from disclosure and
modification by the encryption mechanisms (OpenSSL) included in the TOE.
The TOE protects the ability to continue recording data by periodically clearing the stored logs,
starting with the oldest records first. This assures there is always adequate disk space to
record current and new data that has been found to match the current rule set.
7.3 TOE Protection against Bypass of Security Functions
The TSF requires that all users successfully authenticate before any TSF functions (other than
entering identification and authentication data) can be performed. Once a user is identified and
authenticated, they are associated with a role that determines which function interfaces the
TOE will offer to the user. Each interface is defined to offer specific capabilities, all controlled
by the TSF. The TSS does not offer general programming capabilities that might offer the
opportunity to attempt to bypass the TSP.
Additionally, the TSF does not accept any commands from or offer any functions to the
networks that are monitored by the TOE. This ensures that network entities cannot cause the
TOE not to apply its TSPs to applicable network traffic.
To ensure that network traffic does not bypass the IPS functionality of the 3D Sensors with
IPS, the customer must choose the appropriate sensor model for their network and
administrators must follow the guidelines in the user guidance for optimal deployment of the
sensors.
The customer must choose a 3D Sensor model that matches or exceeds the traffic bandwidth
of the network segment it monitors. In addition, depending on the criticality of the hosts on the
network segment, the sensor should be deployed with an optional fail-open network card. The
fail-open card ensures that traffic continues to pass through the interfaces even if the
appliance itself fails or loses power (although a few packets may be lost when the appliance is
rebooted).
The Sourcefire 3D System administrator should read [SENS-INSTALL] and choose the optimal
sensor deployment configuration (outside the firewall, in the DMZ, or on the internal network)
and sensor connection to the network (using a hub, using a span port, or using a network tap)
for their network architecture and security needs.
The administrator should also understand the information in Chapter 6: Using Detection
Engines and Interface Sets, of [USER] in order to properly configure and manage the
Sourcefire 3D System Version 4.8.2.1 (SEU 259)
Security Target
105 of 105
detection engines and interface sets of the sensors. In some circumstances, editing an
interface set or detection engine can cause the detection engines on the sensor to restart,
which can cause a short pause in processing. For most 3D Sensors with inline interface sets,
a software bridge is automatically set up to transport packets when the sensor restarts.
Although some packets are transmitted without inspection during this time, no packets are lost.
Note: For any TOE configuration, there cannot be a 100% certainty that all network packets
will be analyzed by the IPS functionality of the TOE. The customer must make an informed
choice of equipment and configuration that best suits their particular network configuration,
traffic volume and security needs.