Sourcefire 3D System
Security Target
(Sourcefire Defense Center: models DC500, DC1000, and DC3000;
Sourcefire 3D Sensor licensed for IPS:
models 3D500, 3D1000, 3D2000, 3D2100, 3D2500,
3D3500, 3D4500, 3D6500 and 3D9900;
Sourcefire Virtual Defense Center,
Sourcefire Virtual 3D Sensor licensed for IPS)
Version 4.9.1.4 (SEU 371)
Version 1.6
March 25, 2011
Prepared For
Sourcefire, Incorporated
9770 Patuxent Woods Drive
Columbia, MD 21046
Prepared By
7925 Jones Branch DriveSuite 5400McLean, VA 22102-3321703 848-0883Fax 703 848-0960
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 2 of 116 - CygnaCom Solutions Proprietary
Table of Contents
Section Page
1 SECURITY TARGET INTRODUCTION.............................................................................................7
1.1 SECURITY TARGET REFERENCE ...................................................................................................7
1.1.1 References............................................................................................................................8
1.2 TOE REFERENCE ........................................................................................................................8
1.3 TOE OVERVIEW ..........................................................................................................................8
1.3.1 TOE Type..............................................................................................................................9
1.3.2 Hardware/Firmware/Software Required by the TOE ............................................................9
1.4 TOE DESCRIPTION ....................................................................................................................11
1.4.1 Acronyms ............................................................................................................................11
1.4.2 Terminology.........................................................................................................................12
1.4.3 Product Description.............................................................................................................16
1.4.3.1 Sourcefire 3D Sensor licensed for IPS (3D Sensor with IPS) ..................................................16
1.4.3.2 Sourcefire Virtual 3D Sensor licensed for IPS (Virtual 3D Sensor with IPS) ............................19
1.4.3.3 Sourcefire Defense Center (Defense Center) ..........................................................................21
1.4.3.4 Sourcefire Virtual Defense Center (Virtual Defense Center)....................................................23
1.4.4 Data.....................................................................................................................................24
1.4.5 Users...................................................................................................................................24
1.4.6 Product Guidance ...............................................................................................................25
1.4.7 Physical Scope of the TOE .................................................................................................25
1.4.7.1 Included in the TOE: ................................................................................................................29
1.4.7.2 Excluded from the TOE:...........................................................................................................30
1.4.8 Logical Scope of the TOE ...................................................................................................31
1.4.8.1 Security Audit...........................................................................................................................31
1.4.8.2 Identification and Authentication ..............................................................................................32
1.4.8.3 Security Management ..............................................................................................................32
1.4.8.4 Protection of Security Functions ..............................................................................................32
1.4.8.5 TOE Access Functions.............................................................................................................33
1.4.8.6 System Data Collection............................................................................................................33
1.4.8.7 System Data Analysis ..............................................................................................................33
1.4.8.8 System Data Review, Availability and Loss .............................................................................33
1.4.8.9 Excluded Functionality .............................................................................................................34
1.4.9 Differences between Versions 4.8 and Versions 4.9 ..........................................................34
2 CONFORMANCE CLAIMS..............................................................................................................36
2.1 COMMON CRITERIA CONFORMANCE............................................................................................36
2.2 PROTECTION PROFILE CLAIM .....................................................................................................36
2.3 PACKAGE CLAIM ........................................................................................................................39
3 SECURITY PROBLEM DEFINITION...............................................................................................40
3.1 THREATS...................................................................................................................................40
3.2 ORGANIZATIONAL SECURITY POLICIES (OSPS) ...........................................................................41
3.3 ASSUMPTIONS ...........................................................................................................................41
4 SECURITY OBJECTIVES ...............................................................................................................43
4.1.1 Security Objectives for the TOE..........................................................................................43
4.1.2 Security Objectives for the Operational Environment .........................................................44
4.2 SECURITY OBJECTIVES RATIONALE.............................................................................................45
4.2.1 Rationale for the IT Security Objectives..............................................................................45
4.2.2 Rationale for the Security Objectives for the Environment .................................................51
5 EXTENDED COMPONENTS DEFINITION .....................................................................................52
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 3 of 116 - CygnaCom Solutions Proprietary
5.1 FIA_UAU_EXT.1 TIMING OF AUTHENTICATION...........................................................................52
5.1.1 Class FIA: Identification and authentication........................................................................52
5.1.2 Family: User authentication (FIA_UAU)..............................................................................52
5.1.3 Family Behaviour ................................................................................................................52
5.1.4 Management .......................................................................................................................52
5.1.5 Audit ....................................................................................................................................53
5.1.6 Definition .............................................................................................................................53
5.1.7 Rationale .............................................................................................................................53
5.2 IDS_SDC_EXT.1 SYSTEM DATA COLLECTION...........................................................................53
5.2.1 Class IDS: Intrusion Detection System ...............................................................................53
5.2.2 Family: System Data Collection (IDS_SDC) .......................................................................53
5.2.3 Family Behavior...................................................................................................................53
5.2.4 Management .......................................................................................................................53
5.2.5 Audit ....................................................................................................................................54
5.2.6 Definition .............................................................................................................................54
5.2.7 Rationale .............................................................................................................................55
5.3 IDS_ANL_EXT.1 ANALYSER ANALYSIS......................................................................................55
5.3.1 Class IDS: Intrusion Detection System ...............................................................................55
5.3.2 Family: Analyser analysis (IDS_ANL) .................................................................................55
5.3.3 Family Behavior...................................................................................................................55
5.3.4 Management .......................................................................................................................55
5.3.5 Audit ....................................................................................................................................55
5.3.6 Definition .............................................................................................................................55
5.3.7 Rationale .............................................................................................................................56
5.4 IDS_RCT_EXT.1 ANALYSER REACT..........................................................................................56
5.4.1 Class IDS: Intrusion Detection System ...............................................................................56
5.4.2 Family: Analyser react (IDS_RCT)......................................................................................56
5.4.3 Family Behavior...................................................................................................................56
5.4.4 Management .......................................................................................................................56
5.4.5 Audit ....................................................................................................................................56
5.4.6 Definition .............................................................................................................................57
5.4.7 Rationale .............................................................................................................................57
5.5 IDS_RDR_EXT.1 RESTRICTED DATA REVIEW ...........................................................................57
5.5.1 Class IDS: Intrusion Detection System ...............................................................................57
5.5.2 Family: Security data review (IDS_RDR)............................................................................57
5.5.3 Family Behavior...................................................................................................................57
5.5.4 Management .......................................................................................................................57
5.5.5 Audit ....................................................................................................................................57
5.5.6 Definition .............................................................................................................................57
5.5.7 Rationale .............................................................................................................................58
5.6 IDS_STG_EXT.1 GUARANTEE OF SYSTEM DATA AVAILABILITY ..................................................58
5.6.1 Class IDS: Intrusion Detection System ...............................................................................58
5.6.2 Family: System data storage (IDS_STG)............................................................................58
5.6.3 Family Behavior...................................................................................................................58
5.6.4 Management .......................................................................................................................58
5.6.5 Audit ....................................................................................................................................58
5.6.6 Definition .............................................................................................................................58
5.6.7 Rationale .............................................................................................................................59
5.7 IDS_STG_EXT.2 PREVENTION OF SYSTEM DATA LOSS..............................................................59
5.7.1 Class IDS: Intrusion Detection System ...............................................................................59
5.7.2 Family: System data storage (IDS_STG)............................................................................59
5.7.3 Family Behavior...................................................................................................................59
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 4 of 116 - CygnaCom Solutions Proprietary
5.7.4 Management .......................................................................................................................59
5.7.5 Audit ....................................................................................................................................59
5.7.6 Definition .............................................................................................................................59
5.7.7 Rationale .............................................................................................................................60
6 SECURITY REQUIREMENTS.........................................................................................................61
6.1 SECURITY FUNCTIONAL REQUIREMENTS .....................................................................................61
6.1.1 Class FAU: Security Audit...................................................................................................62
6.1.1.1 FAU_GEN.1 Audit Data Generation.........................................................................................62
6.1.1.2 FAU_SAR.1 Audit Review........................................................................................................63
6.1.1.3 FAU_SAR.2 Restricted audit review ........................................................................................64
6.1.1.4 FAU_SAR.3 Selectable audit review........................................................................................64
6.1.1.5 FAU_SEL.1 Selective audit......................................................................................................64
6.1.1.6 FAU_STG.2 Guarantees of audit data availability....................................................................64
6.1.1.7 FAU_STG.4 Prevention of audit data loss ...............................................................................65
6.1.2 Class FIA: Identification and Authentication .......................................................................65
6.1.2.1 FIA_ATD.1 User attribute definition..........................................................................................65
6.1.2.2 FIA_UAU_EXT.1 Timing of authentication...............................................................................65
6.1.2.3 FIA_UID.1 Timing of identification............................................................................................66
6.1.3 Class FMT: Security Management......................................................................................66
6.1.3.1 FMT_MOF.1 Management of security functions behavior........................................................66
6.1.3.2 FMT_MTD.1 Management of TSF data ...................................................................................67
6.1.3.3 FMT_SMF.1 Specification of Management Functions..............................................................71
6.1.3.4 FMT_SMR.1 Security Roles.....................................................................................................73
6.1.4 Class FPT: Protection of the TSF .......................................................................................74
6.1.4.1 FPT_ITT.1 Basic internal TSF data transfer protection............................................................74
6.1.5 Class FTA: TOE Access .....................................................................................................74
6.1.5.1 FTA_TAB.1 Default TOE access banners................................................................................74
6.1.6 Class IDS: IDS Component Requirements .........................................................................75
6.1.6.1 IDS_SDC_EXT.1 System Data Collection ...............................................................................75
6.1.6.2 IDS_ANL_EXT.1 Analyser analysis .........................................................................................75
6.1.6.3 IDS_RCT_EXT.1 Analyser react (EXT)....................................................................................76
6.1.6.4 IDS_RDR_EXT.1 Restricted Data Review (EXT).....................................................................77
6.1.6.5 IDS_STG_EXT.1 Guarantee of System Data Availability.........................................................77
6.1.6.6 IDS_STG_EXT.2 Prevention of System data loss ...................................................................77
6.2 SECURITY ASSURANCE REQUIREMENTS FOR THE TOE................................................................79
6.2.1 Class ADV: Development....................................................................................................79
6.2.1.1 ADV_ARC.1 Security architecture description .........................................................................79
6.2.1.2 ADV_FSP.2 Security-enforcing functional specification...........................................................80
6.2.1.3 ADV_TDS.1 Basic design ........................................................................................................81
6.2.2 Class AGD: Guidance documents ......................................................................................81
6.2.2.1 AGD_OPE.1 Operational user guidance..................................................................................81
6.2.2.2 AGD_PRE.1 Preparative procedures.......................................................................................82
6.2.3 Class ALC: Life-cycle support.............................................................................................82
6.2.3.1 ALC_CMC.2 Use of a CM system............................................................................................82
6.2.3.2 ALC_CMS.2 Parts of the TOE CM coverage ...........................................................................83
6.2.3.3 ALC_DEL.1 Delivery procedures .............................................................................................83
6.2.3.4 ALC_FLR.2 Flaw reporting procedures....................................................................................84
6.2.4 Class ATE: Tests ................................................................................................................85
6.2.4.1 ATE_COV.1 Evidence of coverage..........................................................................................85
6.2.4.2 ATE_FUN.1 Functional testing.................................................................................................85
6.2.4.3 ATE_IND.2 Independent testing - sample................................................................................85
6.2.5 Class AVA: Vulnerability assessment .................................................................................86
6.2.5.1 AVA_VAN.2 Vulnerability analysis ...........................................................................................86
6.3 SECURITY REQUIREMENTS RATIONALE .......................................................................................87
6.3.1 Dependencies Satisfied ......................................................................................................87
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 5 of 116 - CygnaCom Solutions Proprietary
6.3.2 Functional Requirements ....................................................................................................87
6.3.3 Assurance Rationale ...........................................................................................................91
7 TOE SUMMARY SPECIFICATION .................................................................................................92
7.1 IT SECURITY FUNCTIONS............................................................................................................92
7.1.1 Security Audit Functions .....................................................................................................93
7.1.1.1 AU-1: Audit Generation............................................................................................................93
7.1.1.2 AU-2: Audit Review..................................................................................................................94
7.1.1.3 AU-3: Audit Selection...............................................................................................................94
7.1.1.4 AU-4: Audit Record Protection .................................................................................................96
7.1.2 User I&A Functions .............................................................................................................97
7.1.2.1 IA-1: User Security Attributes...................................................................................................97
7.1.2.2 IA-2: User Identification & Authentication.................................................................................98
7.1.3 Security Management Functions.......................................................................................100
7.1.3.1 SM-1: Management Functions...............................................................................................100
7.1.3.2 SM-2: Management Security Roles........................................................................................101
7.1.4 Protection of Security Functions .......................................................................................102
7.1.4.1 PT-1: Internal Data Transfer Protection .................................................................................102
7.1.5 TOE Access Functions......................................................................................................103
7.1.5.1 TA-1 TOE Login Information ..................................................................................................103
7.1.6 Intrusion Detection System Functions ..............................................................................103
7.1.6.1 ID-1: System Data Collection .................................................................................................103
7.1.6.2 ID-2: System Data Analysis ...................................................................................................104
7.1.6.3 ID-3: Analyzer Alarms ............................................................................................................111
7.1.6.4 ID-4: System Data Review.....................................................................................................113
7.1.6.5 ID-5: System Data Protection.................................................................................................113
7.2 TOE PROTECTION AGAINST INTERFERENCE AND LOGICAL TAMPERING.......................................114
7.3 TOE PROTECTION AGAINST BYPASS OF SECURITY FUNCTIONS..................................................115
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 6 of 116 - CygnaCom Solutions Proprietary
Figures and Tables
Figures Page
FIGURE 1: SOURCEFIRE 3D SYSTEM WITH DEFENSE CENTER........................................................................26
FIGURE 2: SOURCEFIRE 3D SYSTEM WITH VIRTUAL DEFENSE CENTER ..........................................................27
FIGURE 3: SOURCEFIRE 3D SYSTEM USING A STAND-ALONE 3D SENSOR WITH IPS........................................28
Tables Page
TABLE 1-1: REFERENCES ..............................................................................................................................8
TABLE 1-2: SUPPORTED WEB BROWSERS....................................................................................................10
TABLE 1-3: PRODUCT AND CC ACRONYMS...................................................................................................11
TABLE 1-4: PRODUCT AND CC TERMINOLOGY ..............................................................................................12
TABLE 1-5: 3D SENSOR WITH IPS CATEGORIES ...........................................................................................19
TABLE 1-6: USER GUIDANCE DOCUMENTS ...................................................................................................25
TABLE 3-1: TOE THREATS...........................................................................................................................40
TABLE 3-2: IT SYSTEM THREATS..................................................................................................................40
TABLE 3-3: ORGANIZATIONAL SECURITY POLICIES........................................................................................41
TABLE 3-4: TOE USAGE ASSUMPTIONS .......................................................................................................42
TABLE 3-5: TOE PHYSICAL ASSUMPTIONS ...................................................................................................42
TABLE 3-6: TOE PERSONNEL ASSUMPTIONS................................................................................................42
TABLE 4-1: TOE SECURITY OBJECTIVES......................................................................................................43
TABLE 4-2: SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................44
TABLE 4-3: SECURITY OBJECTIVES AND SECURITY ENVIRONMENT MAPPING..................................................46
TABLE 5-1: EXTENDED COMPONENTS ..........................................................................................................52
TABLE 5-2: SYSTEM EVENTS .......................................................................................................................54
TABLE 6-1: TOE SECURITY FUNCTIONAL COMPONENTS ...............................................................................62
TABLE 6-2: AUDITABLE EVENTS ...................................................................................................................63
TABLE 6-3: MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR ...................................................................67
TABLE 6-4: MANAGEMENT OF TSF DATA......................................................................................................67
TABLE 6-5: SYSTEM EVENTS .......................................................................................................................75
TABLE 6-6: EAL2+ ASSURANCE COMPONENTS ............................................................................................79
TABLE 6-7: TOE DEPENDENCIES SATISFIED.................................................................................................87
TABLE 6-8: REQUIREMENTS VS. OBJECTIVES MAPPING.................................................................................88
TABLE 7-1: SECURITY FUNCTIONAL REQUIREMENTS MAPPED TO SECURITY FUNCTIONS.................................92
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 7 of 116 - CygnaCom Solutions Proprietary
1 Security Target Introduction
1.1 Security Target Reference
ST Title: Sourcefire 3D System Security Target (Sourcefire Defense Center:
models DC500, DC1000, and DC3000; Sourcefire 3D Sensor licensed
for IPS: models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500,
3D4500, 3D6500 and 3D9900; Sourcefire Virtual Defense Center,
Sourcefire Virtual 3D Sensor licensed for IPS) Version 4.9.1.4 (SEU
371)
ST Version: v1.6
ST Author: CygnaCom Solutions
ST Date: March 25, 2011
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, IPS, IDS, intrusion prevention
system, intrusion detection system, scanner, analyzer, sensor
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 8 of 116 - CygnaCom Solutions Proprietary
1.1.1 References
Table 1-1 provides the references used to develop this Security Target.
Table 1-1: References
Reference Title ID
Sourcefire 3D System - Sourcefire 3D System Administrator Guide, Version
4.9.1, 2010-Jul-12.
[ADMIN]
Sourcefire 3D System - Sourcefire 3D System Analyst Guide, Version 4.9.1,
2010-Jul-13.
[ANALYST]
Common Criteria for Information Technology Security Evaluation, CCMB-2009-
07-002, Version 3.1, Revision 3
[CC]
Sourcefire 3D System Common Criteria Supplement to the Administrative
Guidance Version 4.9.1.4
[CC-SUPP]
Sourcefire 3D System – Defense Center Installation Guide, Version 4.9.1, 2010-
Jul-13.
[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 - RELEASE NOTES, Version 4.9.1, May 19, 2010 [RELEASE]
Sourcefire 3D System - 3D Sensor Installation Guide, Version 4.9.1, 2010-Jun-
03.
[SENS-INSTALL]
Sourcefire 3D System - Virtual Defense Center and 3D Sensor Installation
Guide, Version 4.9.1, 2010-Mar-18.
[VIRTUAL-INSTALL]
1.2 TOE Reference
TOE Identification: Sourcefire 3D System (Sourcefire Defense Center: models DC500,
DC1000, and DC3000; Sourcefire 3D Sensor licensed for IPS: models
3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D4500, 3D6500
and 3D9900; Sourcefire Virtual Defense Center, Sourcefire Virtual 3D
Sensor licensed for IPS) Version 4.9.1.4 (SEU 371)
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) and the Sourcefire Virtual Defense Center and Sourcefire Virtual 3D
Sensor licensed for IPS (software-only).
The Sourcefire Defense Center (Defense Center), Sourcefire 3D Sensor licensed for IPS (3D
Sensor with IPS), Sourcefire Virtual Defense Center (Virtual Defense Center) and Sourcefire
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 9 of 116 - CygnaCom Solutions Proprietary
Virtual 3D Sensor licensed for IPS (Virtual 3D Sensor with IPS) are components of the
Sourcefire 3D System Version 4.9.1.4.
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 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) was evaluated and certified at EAL2 in June 2010.
1.3.1 TOE Type
The TOE is an Intrusion Prevention and Detection System that combines open-source and
proprietary technology. The TOE monitors 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.9.1.4 (SEU 371) software is embedded in the Sourcefire
Defense Center and the Sourcefire 3D Sensor licensed for 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.
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.3 Sourcefire Defense Center (Defense Center) for a detailed description of the
appliance-based components of the TOE.
The Sourcefire 3D System 4.9.1.4 also includes the software-only Sourcefire Virtual Defense
Center and Sourcefire Virtual 3D Sensor licensed for IPS components. These components
consist of only the software that implements the security functionality of the TOE. These
components consist of the same Sourcefire application code, Linux-derived operating system
and third-party applications as used on the appliance-based components. The platform,
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 10 of 116 - CygnaCom Solutions Proprietary
underlying operating system of the platform and the VMware implementation needed to run
the Virtual Defense Center and Virtual 3D Sensor with IPS components are included in the
Operational Environment.
Important: The customer is responsible for using a VMware version that is not subject to
vulnerabilities and for patching their VMware server accordingly as vulnerabilities are
identified.
Please see Sections 1.4.3.2 Sourcefire Virtual 3D Sensor licensed for IPS (Virtual 3D Sensor
with IPS) and 1.4.3.4 Sourcefire Virtual Defense Center (Virtual Defense Center) for a detailed
description of the virtual components of the TOE.
The evaluated configuration of the TOE requires the following Operational Environment
support:
 A Web Browser for the Defense Center, Virtual Defense Center and 3D Sensor with
IPS management interfaces. Sourcefire 3D System Version 4.9.1.4 only supports the
following browsers as configured in the following table:
Table 1-2: Supported Web Browsers
Browser Required Enabled Options and Settings
Firefox 3.5.x JavaScript
Cookies
Secure Sockets Layer (SSL) v3
Microsoft Internet Explorer 7.0 JavaScript
Cookies
Secure Sockets Layer (SSL) v3
128-bit encryption
Active scripting security setting
Microsoft Internet Explorer 8.0 JavaScript
Cookies
Secure Sockets Layer (SSL) v3
128-bit encryption
Active scripting security setting
Compatibility View
 A private, protected network between the Defense Center (virtual and appliances) and
the 3D Sensor(s) with IPS (virtual and appliances)
 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
 Virtual Defense Center and Virtual 3D Sensor with IPS platforms:
o These platforms must be capable of hosting VMware ESX or ESXi Version 3.5
or 4.0.
o The ESX host for the Virtual 3D Sensor with IPS needs at least one CPU, 1GB
of memory, and 20GB of disk space.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 11 of 116 - CygnaCom Solutions Proprietary
o The ESX host for the Virtual Defense Center needs at a minimum 2 CPUs, 1GB
of memory, and 80GB of disk space.
The following Operational Environment components are optional for the evaluated
configuration of the TOE.
 An external Syslog Server for administrator alert notifications and external storage of
audit log records
 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-3: 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
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
SSL Secure Sockets Layer
ST Security Target
TCP/IP Transmission Control Protocol/Internet Protocol
TLS Transport Security Layer
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 12 of 116 - CygnaCom Solutions Proprietary
Acronym Definition
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-4: Product and CC Terminology
Terminology Definition
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.
Access List A list of computers can access a 3D System component 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
(Virtual) 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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 13 of 116 - CygnaCom Solutions Proprietary
Terminology Definition
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 (appliance-based and virtual) 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 (Virtual) Defense Center when a specific
health event occurs.
Health Event An event that is generated when one of the components 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 components 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 (Virtual) 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 (appliance-based or
virtual) 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.
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 (Virtual) 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 (Virtual) 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 (Virtual)
3D Sensor with IPS is the sensor component of the TOE.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 14 of 116 - CygnaCom Solutions Proprietary
Terminology Definition
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.
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 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).
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 15 of 116 - CygnaCom Solutions Proprietary
Terminology Definition
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 that 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.
Virtual 3D Sensor with IPS An software-only sensor that, as part of the Sourcefire 3D System,
can run the IPS component. The Virtual 3D Sensor with IPS includes
the same Sourcefire application software, Linux derived operating
system, and supporting 3rd party software as the appliance-based 3D
Sensor with IPS but is installed on a VMware ESX host platform.
Virtual Defense Center The software-only component of the Sourcefire 3D System that allows
the management of the 3D Sensors (appliance-based and virtual) and
automatically aggregates the events they generate. The Virtual
Defense Center consists of the same the Sourcefire application
software, Linux derived operating system, and supporting 3rd party
software as the appliance-based Defense Center, but is installed on a
VMware ESX host platform.
Virus A program that can "infect" other programs by modifying them to
include a, possibly evolved, copy of itself.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 16 of 116 - CygnaCom Solutions Proprietary
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 Virtual 3D Sensor licensed for IPS) and the Sourcefire
Defense Center (the appliance-based Sourcefire Defense Center and the Sourcefire Virtual
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
(appliance-based or virtual) 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 sensor or through a central Defense Center (either
appliance-based or virtual).
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 and Sourcefire Virtual 3D
Sensors. Each sensor licensed for IPS uses rules, decoders, and preprocessors to look for the
broad range of exploits that attackers have developed. The 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 Virtual 3D Sensor licensed for IPS
 The Sourcefire Defense Center
 The Sourcefire Virtual Defense Center
1.4.3.1 Sourcefire 3D Sensor licensed for IPS (3D Sensor with IPS)
The Sourcefire 3D Sensor licensed for IPS is an appliance-based component of the TOE and
includes both software and hardware.
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: 2.8.6-43 is included in the CC evaluated version of the
Sourcefire 3D System.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 17 of 116 - CygnaCom Solutions Proprietary
 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. 3D Sensors with 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 only being 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 of the 3D Sensor with IPS 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 18 of 116 - CygnaCom Solutions Proprietary
PEP is an optional feature available only for the 3D9900 model of the sensor appliance. PEP
allows users to create policies that drop or fastpath (send through the sensor without analysis)
network traffic for user specified targets. The PEP feature therefore allows the user to override
the normal collection and analysis functions of the sensor.
An additional option only available on the 3D9900 sensors is the Enable Fail-Safe option. The
Enable Fail-Safe option is only available on inline interface configurations. When enabled,
traffic is allowed to bypass detection and continue through the sensor. 3D9900 sensors
monitor internal traffic buffers and bypass detection engines if those buffers are full.
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.
The models of the 3D Sensor with IPS included in the evaluation 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 (appliance-based or virtual) 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 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 (Virtual) Defense Center that manages the sensor, send the events to the (Virtual)
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 and all the sensor appliances in the evaluated configuration run the SFLinux
Version 4.9 operating system. SFLinux is a Sourcefire proprietary operating system built from
open-source Linux code. Only services and packages required by the TOE for secure
operation are enabled in this OS. The 3D9900 model of the sensor runs a 64-bit version of the
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 19 of 116 - CygnaCom Solutions Proprietary
SFLinux v4.9 operating system. The source files are the same for all sensors; however, the
files for the 3D9900 are compiled with a makefile that uses 64-bit compilers and, in some
cases, 64-bit libraries. The 3D Sensors with IPS can therefore be categorized by the Linux-
derived operating system installed on the appliance as follows:
Table 1-5: 3D Sensor with IPS Categories
Sourcefire 3D Sensor Category Sourcefire 3D Sensor Appliance Model
SFLinux v4.9 (64-bit)
Sourcefire Proprietary Linux-derived OS
3D Sensor 9900
SFLinux v4.9 (32-bit)
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
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.8k)
 Protocol standards including HTTPS, SMTP, SSH, and SNMP (v1, v2 or v3)
implementations
 Perl (v5.8.3)
 Shell access through OpenSSH (v5.1pl)
 Web Server (Tomcat Apache Version 2.2.13)
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 Virtual 3D Sensor licensed for IPS (Virtual 3D Sensor with IPS)
The Sourcefire Virtual 3D Sensor licensed for IPS is a software-only version of the Sourcefire
3D Sensor licensed for IPS that runs within a VMware virtual environment. The Virtual 3D
Sensor with IPS runs on any platform that supports VMware‟s ESX/ESXi Version 3.5 or 4.0
hypervisor.
The installation files for the Virtual 3D Sensor with IPS are delivered in VMware‟s Open Virtual
Format (OVF). The installation files are downloaded from the Sourcefire Support Site
(https://support.sourcefire.com/). The installation package contains the same Sourcefire
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 20 of 116 - CygnaCom Solutions Proprietary
application code, SFLinux v4.9 operating system, MySQL database, and third-party
applications that are installed on the appliance-based 3D Sensors with IPS. Once loaded on
the hypervisor and started, CLI initial configuration for the management interface is required
using the Virtual 3D Sensor with IPS‟s root account.
The Virtual 3D Sensor‟s sensing interface must be associated with a port on a hypervisor
virtual switch that has promiscuous mode enabled.
A Virtual 3D Sensor can be managed by an appliance-based or Virtual Defense Center but
IPS events cannot be collected from that sensor until the Virtual 3D Sensor IPS license is
added to the managing (Virtual) Defense Center. Maximum throughput and processing
capacity for the Virtual 3D Sensor with IPS (and Virtual Defense Center) are heavily influenced
by a number of factors, such as:
 Amount of memory and CPU capacity of the ESX host
 Number of total virtual machines running on the ESX host
 Amount of resources assigned to each virtual machine
 Level of activity of other virtual machines sharing the platform
There are a number of performance measurement and resource allocation tools provided by
VMware on the ESX host. Sourcefire recommends that these tools be used while running the
Virtual 3D Sensor with IPS and monitoring traffic to determine throughput. If the throughput is
not satisfactory, the resources assigned to the Virtual 3D Sensor with IPS or to other virtual
machines that share the ESX host can be adjusted.
Virtual 3D Sensors with IPS differ from the appliance-based 3D Sensors with IPS by the
following features and limitations:
 Appliance-based versions of the 3D Sensor with IPS can inspect traffic going into and
out of a VMware virtual environment, but they cannot inspect traffic that passes
between two or more virtual machines (VMs). The Virtual 3D Sensor with IPS, on the
other hand, can monitor the network activity between any two VMs.
 The IPS feature for a Virtual 3D Sensor is licensed through a Defense Center
(appliance-based or virtual). An IPS feature license for a Virtual 3D Sensor must be
added to the managing Defense Center to process and store IPS events from the
Virtual 3D Sensor with IPS.
 There is no embedded graphical user interface (WebUI) on the Virtual 3D Sensor with
IPS. It must be managed with a Defense Center (appliance-based or virtual).
 Having no management interface, the Virtual 3D Sensor with IPS does not record user
events to an audit log.
 There is no event storage on a Virtual 3D Sensor with IPS; a Defense Center
(appliance-based or virtual) must be used to store the events from the sensor.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 21 of 116 - CygnaCom Solutions Proprietary
 There is no backup and restore on a Virtual 3D Sensor; a Defense Center (appliance-
based or virtual) must be used for backup and restoration.
 The Virtual 3D Sensor with IPS has a limit of three detection engines, a maximum rate
of 250 Mbps per detection engine, and three detection resources.
1.4.3.3 Sourcefire Defense Center (Defense Center)
The Sourcefire Defense Center is an appliance-based component of the TOE and includes
both software and hardware.
The 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. A Defense Center can manage from 3 to 100 sensors depending on
the appliance model.
The Defense Center provides the following functionality through a web-based GUI (WebUI):
 An interface which displays all the data collected by the managed sensors 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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 22 of 116 - CygnaCom Solutions Proprietary
The Defense Center includes the Sourcefire proprietary Linux-derived OS, SFLinux v4.9, 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
SEU releases may also contain new and updated decoders and preprocessors, and updates
to the sensor 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 371 (which in
turn includes Snort Version 2.8.6-43).
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 3rd
party software is included in
the Defense Center TOE component:
 Network connectivity provided through third-party encryption software (OpenSSL
v0.9.8k)
 Protocol standards including HTTPS, SMTP, SSH, and SNMP (v1, v2 or v3)
implementations
 Perl (v5.8.3)
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 23 of 116 - CygnaCom Solutions Proprietary
 Shell access through OpenSSH (v5.1pl)
 Web Server (Tomcat Apache Version 2.2.13)
The Sourcefire software, operating system, database, and 3rd
party products are the same for
all models of the Defense Center appliances (Defense Center Models DC500, DC1000 and
DC3000).
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.4 Sourcefire Virtual Defense Center (Virtual Defense Center)
The Sourcefire Virtual Defense Center is a software-only version of the Sourcefire Defense
Center that runs within a VMware virtual environment. The Virtual Defense Center runs on any
platform that supports VMware‟s ESX/ESXi Version 3.5 or 4.0 hypervisor.
The installation files for the Virtual Defense Center are delivered in VMware‟s Open Virtual
Format (OVF). The installation files are downloaded from the Sourcefire Support Site
(https://support.sourcefire.com/). The installation package contains the same Sourcefire
application code, SFLinux v4.9 operating system, MySQL database, and third-party
applications that are installed on the appliance-based Defense Center. Once loaded on the
hypervisor and started, CLI initial configuration for the management interface is required using
the Virtual Defense Center‟s root account.
Virtual Defense Center can manage both physical and virtual sensors. The Virtual Defense
Center supports local event storage and can manage up to 25 sensors, physical or virtual, in
any combination.
Virtual Defense Centers differ from the appliance-based Defense Centers only by the following
features and limitations:
 A Virtual Defense Center can store up to 10 million intrusion events and 10 million flow
events.
 A Virtual Defense Center provides the ability to manage up to 25 3D Sensors.
 A Virtual Defense Center does not support RADIUS authentication.
 A Virtual Defense Center cannot be used as a Master Defense Center but it can be
managed by a Master Defense Center. (A Master Defense Center is not included in the
evaluated configuration.)
 A Virtual Defense Center cannot be used in a High Availability configuration with either
a physical Defense Center or another Virtual Defense Center. (The High Availability
feature is not included in the evaluated configuration.)
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 24 of 116 - CygnaCom Solutions Proprietary
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
 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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 25 of 116 - CygnaCom Solutions Proprietary
 “Policy and Response Administrator” Role: this role can create, modify, and
implement intrusion policies and intrusion rules for the IDS.
Maintenance of the TOE also requires the CLI root user role. The 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. 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.
This role is required to set up the audit suppression mechanism. The audit suppression lists
are created or modified at installation or during maintenance; this functionality is not part of the
run-time operation of the TOE available through the WebUI.
1.4.6 Product Guidance
The Sourcefire 3D System documentation set includes online help and PDF files.
The following product guidance documents are provided with the TOE on the Documentation
CD included with the product:
Table 1-6: User Guidance Documents
Sourcefire 3D System - Sourcefire 3D System Administrator Guide, Version 4.9.1
Sourcefire 3D System - Sourcefire 3D System Analyst Guide, Version 4.9.1
Sourcefire 3D System – Defense Center Installation Guide, Version 4.9.1
Sourcefire 3D System - 3D Sensor Installation Guide, Version 4.9.1
Sourcefire 3D System - Virtual Defense Center and 3D Sensor Installation Guide, Version 4.9.1
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.9.1.4 (SEU 371) also
includes Sourcefire 3D System - CC Supplement for Version 4.9.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 components described in Section 1.4.3. The physical boundary of the
TOE is:
 The Sourcefire 3D Sensor licensed for IPS appliance
 The Sourcefire Defense Center appliance
The appliance based components are installed with the Sourcefire 3D System
Version 4.9.1.4 (SEU 371) software, Linux-derived operating system, MySQL
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 26 of 116 - CygnaCom Solutions Proprietary
database, and supporting 3rd party software as commercially available from the
developer; and
 The Sourcefire Virtual Defense Center
 The Sourcefire Virtual 3D Sensor licensed for IPS
The virtual components consist of all software that is on the installation media
including Sourcefire 3D System Version 4.9.1.4 (SEU 371) software, Linux-
derived operating system, MySQL database, and supporting 3rd party software.
The TOE Boundary is depicted in the following figures.
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Management Network
(Private Network among TOE components)
WebUI
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
DNS
Server
SNMP
Server
SNMP
Server
Syslog
Server
Syslog
Server
LDAP /
RADIUS
Server
NTP
Server
NTP
Server
3D System
Software MySQL
Virtual 3D Sensor
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
Virtual 3D Sensor
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
Virtual 3D Sensor
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
VMware Platform OS
Virtual Defense Center
MySQL
3rd Party Software Applications
Linux-Derived Operating System
Virtual Defense Center
MySQL
3rd Party Software Applications
Linux-Derived Operating System
3D System
Software
DC
EMAIL
Server
EMAIL
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 27 of 116 - CygnaCom Solutions Proprietary
Monitored Network
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Network
Asset
Management Network
(Private Network among TOE components)
WebUI
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
3D Sensor Appliance
3rd
Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
DNS
Server
SNMP
Server
SNMP
Server
Syslog
Server
Syslog
Server
LDAP
Server
LDAP
Server
NTP
Server
NTP
Server
3D System
Software MySQL
Virtual 3D Sensor
3rd Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
Virtual 3D Sensor
3rd Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
3D System
Software MySQL
Virtual 3D Sensor
3rd Party Software Applications
Linux-Derived Operating System
IPS RNA RUA
VMware Platform OS
VMware Platform OS
Virtual Defense Center
MySQL
3rd Party Software Applications
Linux-Derived Operating System
Virtual Defense Center
MySQL
3rd Party Software Applications
Linux-Derived Operating System
3D System
Software
DC
EMAIL
Server
EMAIL
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 2: Sourcefire 3D System with Virtual Defense Center
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 28 of 116 - CygnaCom Solutions Proprietary
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
Figure 3: Sourcefire 3D System using a stand-alone 3D Sensor with IPS
The Sourcefire application software for the Defense Center and 3D Sensor with IPS
components is physically installed on the Sourcefire appliances that run Linux-derived
operating systems. As such, the physical interfaces for these components are based on and
limited by services provided by the appliance 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 Virtual Defense Center and Virtual 3D Sensor with IPS components are physically
installed on platforms that support VMware. The physical interfaces for these components are
based on and limited by services provided by the platform hardware. The application software
depends on both the Sourcefire SFLinux OS and 3rd
party software included in the virtual
components and on the underlying VMware and platform OS for process, disk, and memory
management services and network services.
The Operational Environment of the TOE includes:
 The web browsers that are used for the management interfaces of the TOE
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 29 of 116 - CygnaCom Solutions Proprietary
 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
 The platform hardware, software and VMware to support the Virtual Defense Center
and Virtual 3D Sensor with IPS
 An optional external Syslog Server for administrator alert notifications and warnings,
and external storage of the audit log
 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 and Virtual 3D Sensors with IPS combined with a single
Defense Center or Virtual Defense Center.
1.4.7.1 Included in the TOE:
The evaluated configuration includes the following:
 The Sourcefire 3D Sensor, Version 4.9.1.4 (SEU 371), licensed to use the Sourcefire
Intrusion Prevention System (IPS)
 The Sourcefire Defense Center, Version 4.9.1.4 (SEU 371)
 The Sourcefire Virtual 3D Sensor, Version 4.9.1.4 (SEU 371)licensed to use the
Sourcefire Intrusion Prevention System (IPS)
 The Sourcefire Virtual Defense Center, Version 4.9.1.4 (SEU 371)
All typical deployments as described in Chapter 1 of [SENS-INSTALL] and Chapter 2 of
[VIRTUAL-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 includes configurations that:
 Test the 3D Sensor with IPS for each category of appliance: SFLinux v4.9 and SFLinux
v4.9 (64-bit)
 Test a stand-alone 3D Sensor with IPS configuration.
 Test one or more 3D Sensors with IPS and one or more Virtual 3D Sensors with IPS
managed by a single Defense Center or Virtual Defense Center.
 Test both inline and passive deployments of the 3D Sensors with IPS.
Therefore, there are three test configurations:
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 30 of 116 - CygnaCom Solutions Proprietary
1. One Defense Center managing at least one Virtual 3D Sensor with IPS and at least
one 3D Sensor with IPS from each operating system category, with at least one sensor
deployed inline and at least one deployed passively.
2. One Virtual Defense Center managing at least one Virtual 3D Sensor with IPS and at
least one 3D Sensor with IPS.
3. One 3D Sensor with IPS run in a stand-alone configuration.
1.4.7.2 Excluded from the TOE:
The following product components and functionality are not included in the scope of the
evaluation:
 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
 Clustered configuration of 9900 model sensors
 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, routers, and other external
devices, 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 patch management systems
 Xen Hypervisor platforms for virtual components.
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:
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 31 of 116 - CygnaCom Solutions Proprietary
 The Web Browser for the Defense Center, Virtual Defense Center and 3D Sensor with
IPS Management Interfaces as specified in Table 1-2: Supported Web Browsers
 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 external Syslog Server
 An optional external SNMP Trap Server
 An optional external LDAP or RADIUS Authentication Server
 The platforms for the Virtual Defense Center and Virtual 3D Sensor with IPS including
the platform hardware, the underlying platform operating system and the VMware ESX
implementation
Important: The customer is responsible for using a VMware version that is not subject to
vulnerabilities and for patching their VMware server accordingly as vulnerabilities are
identified.
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.
Audit records may optionally be recorded in the internal syslog of the TOE components or sent
to an external Syslog Server depending on the configuration of the System Policy of the TOE.
The audit data is protected by the access control mechanisms of the database and OS of the
TOE components 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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 32 of 116 - CygnaCom Solutions Proprietary
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 may optionally rely on an external
Syslog Server depending on the TOE configuration. Security Audit 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 or Virtual Defense Center.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 33 of 116 - CygnaCom Solutions Proprietary
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.
1.4.8.7 System Data Analysis
To analyze the data collected by the 3D Sensors with IPS and Virtual 3D Sensors with IPS,
the TOE uses statistical analysis, signatures, decoders, and preprocessors. Statistical analysis
uses rate-base attack prevention features to detect and block denial-of-service (DoS) and
distributed denial of service (DDoS) attacks. 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
statistical analysis, signatures, decoders, and preprocessors in rules that can be designed and
exercised by the TOE.
The TOE administrators can manage the data analysis capabilities of the TOE 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. System Data Analysis has
a dependency on the Operational Environment to provide the user with updated rules and
signature information that they can manually input. 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 34 of 116 - CygnaCom Solutions Proprietary
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
 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 patch management systems
o Sending alerts through trouble ticket systems
 IPS for Crossbeam Systems Security Switches (software-only sensors)
1.4.9 Differences between Versions 4.8 and Versions 4.9
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)
was Common Criteria certified by NIAP at EAL 2 augmented with ALC_FLR.2; Validation
Report Number: CCEVS-VR-VID10334-2010; Date Issued; 23 June 2010. The following is a
summary of the major differences between the Sourcefire 3D System versions 4.8 and 4.9:
 Virtual Components Added to TOE: Sourcefire Virtual Defense Center & Sourcefire
Virtual 3D Sensor licensed for IPS
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 35 of 116 - CygnaCom Solutions Proprietary
 Statistical Analysis Enhancements: Rate-Based Attack Analysis
 Custom Policies‟ Feature Enhancements: Policy Layering, Filtering policies by subnet /
VLAN
 Reporting Enhancements: Intrusion Policy Reports and Intrusion Policy Difference
Reports
 WebUI Menu Options have been reconfigured for ease of use in version 4.9
 New 3D Sensor Model 9900 with the PEP feature has been added for version 4.9
 3D Sensor Models 3D3800, 3D5800 and 3D9800 are no longer supported
 Support for both IPv4 & IPv6 is available in version 4.9
 Issues reported for version 4.8 have been resolved in version 4.9.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 36 of 116 - CygnaCom Solutions Proprietary
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
R3. This Security Target conforms to the Common Criteria Version 3.1 R3.
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 R3 is defined as follows:
demonstrable conformance - relation between an ST and a PP, where the ST
provides a solution which solves the generic security problem in the PP
The PP and the ST may contain entirely different statements that discuss different
entities, use different concepts etc. Demonstrable conformance is also suitable for a
TOE type where several similar PPs already exist, thus allowing the ST author to claim
conformance to these PPs simultaneously, thereby saving work. [CC Part 1 p. 15]
Where there is a clear subset-superset type relation between PP and ST in the case of
strict conformance, the relation is less clear-cut in the case of demonstrable
conformance. STs claiming conformance with the PP must offer a solution to the
generic security problem described in the PP. but can do so in any way that is
equivalent or more restrictive to that described in the PP. [CC Part1 p. 92]
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 37 of 116 - CygnaCom Solutions Proprietary
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 38 of 116 - CygnaCom Solutions Proprietary
OE.XAUTH stating that the services provided by the Operational Environment are
secure and reliable.
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 39 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 40 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 41 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 42 of 116 - CygnaCom Solutions Proprietary
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.
6 A.VMXMIT All packets coming in to the physical ports of the VMware hosts are
transmitted unchanged to the virtual ports in the VMware environment.
Table 3-6: TOE Personnel Assumptions
TOE Personnel Assumptions
7 A.MANAGE There will be one or more competent individuals assigned to manage the
TOE and the security of the information it contains.
8 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.
9 A.NOTRST The TOE can only be accessed by authorized users.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 43 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 44 of 116 - CygnaCom Solutions Proprietary
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.
25 OE.VMXMIT The Operational Environment must ensure that all packets coming in
to the physical ports of the VMware hosts are transmitted unchanged
to the virtual ports in the VMware environment.
* 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 45 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 46 of 116 - CygnaCom Solutions Proprietary
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
OE.VMXMIT
A.ACCESS X
A.DYNMIC X X
A.ASCOPE X
A.PROTCT X
A.LOCATE X
A.VMXMIT 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 47 of 116 - CygnaCom Solutions Proprietary
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 objective 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 objective provides for the physical protection of the TOE.
A.VMXMIT: All packets coming in to the physical ports of the VMware hosts are transmitted
unchanged to the virtual ports in the VMware environment.
The OE.VMXMIT objectives provides for secure transmission of data between the
physical ports and virtual ports on the VMware host machine.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 48 of 116 - CygnaCom Solutions Proprietary
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.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 49 of 116 - CygnaCom Solutions Proprietary
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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 50 of 116 - CygnaCom Solutions Proprietary
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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 51 of 116 - CygnaCom Solutions Proprietary
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.
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 52 of 116 - CygnaCom Solutions Proprietary
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 R3. 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 Analyser analysis
4 IDS_RCT_EXT.1 Analyser 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 July 2009 Version 3.1 Revision 3.
5.1.2 Family: User authentication (FIA_UAU)
5.1.3 Family Behaviour
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 53 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 54 of 116 - CygnaCom Solutions Proprietary
 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 55 of 116 - CygnaCom Solutions Proprietary
Component Event Details
IDS_SDC.1 Start-up and shutdown of audit
functions
none
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 Analyser analysis
5.3.1 Class IDS: Intrusion Detection System
5.3.2 Family: Analyser 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 Analyser analysis
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 56 of 116 - CygnaCom Solutions Proprietary
Hierarchical to: No other components
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 Analyser react
5.4.1 Class IDS: Intrusion Detection System
5.4.2 Family: Analyser 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 57 of 116 - CygnaCom Solutions Proprietary
5.4.6 Definition
IDS_RCT_EXT.1 Analyser 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 58 of 116 - CygnaCom Solutions Proprietary
Dependencies: IDS_SDC_EXP.1
IDS_RDR_EXT.1.1 The TSF shall provide [assignment: authorised 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 59 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 60 of 116 - CygnaCom Solutions Proprietary
IDS_STG_EXT.2.1 The TSF shall [selection: 'ignore system data', 'prevent system
data, except those taken by the authorised 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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 61 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 62 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 63 of 116 - CygnaCom Solutions Proprietary
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 64 of 116 - CygnaCom Solutions Proprietary
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 65 of 116 - CygnaCom Solutions Proprietary
FAU_STG.2.2 The TSF shall be able to detect unauthorized modifications to the audit records
in the audit trail.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 66 of 116 - CygnaCom Solutions Proprietary
Dependencies: FIA_UID.1 Timing of identification
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 or Virtual 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].
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 67 of 116 - CygnaCom Solutions Proprietary
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 *
* 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
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 *
(Virtual) 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 68 of 116 - CygnaCom Solutions Proprietary
User Security Role Operations TSF Data
Create, edit, delete, import,
export, apply, disable (blacklist a
sensor) *
Health policies
Push to sensors * Health policies
View * Health status of sensors and (Virtual)
Defense Center
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
Create, edit, delete, apply,
schedule application of, import,
export
Intrusion policies
Push to sensors * Intrusion policies
Generate, view Intrusion policy reports, Intrusion
policy difference reports
Enable, disable Intrusion rules
Add * IPS license for Virtual 3D Sensors
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
Create, edit, delete ** PEP policies
Create, edit, delete ** PEP rules
Configure Preprocessors, Preprocessor options
Enable, disable Preprocessor rules
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 Sensor system settings
Modify * (Virtual) Defense Center system
settings
Create, edit, delete * Sensor groups
View Sensor and system statistics
View * (Virtual) Defense Center statistics
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 69 of 116 - CygnaCom Solutions Proprietary
User Security Role Operations TSF Data
View, add, delete, stop (shut-
down), restart (reboot), set time
on, disable communications of *
Sensors
Verify Sensor licenses
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
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 sensors and (Virtual)
Defense Center
Schedule application of Intrusion policies
View IPS performance statistics
Change Own password
Configure, delete Recurring tasks
Delete Scheduled tasks
View Sensor and system statistics
View * (Virtual) 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 sensors and (Virtual)
Defense Center
View, edit, create Incidents
View Intrusion event statistics
View, edit, export Intrusion event workflows
View, search, delete Intrusion events
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 70 of 116 - CygnaCom Solutions Proprietary
User Security Role Operations TSF Data
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 sensors and (Virtual)
Defense Center
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
(Read Only)
View, edit, create, delete, export Custom workflows
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
Generate, view Intrusion policy reports, Intrusion
policy difference reports
Enable, disable Intrusion rules
Enable, disable, configure Latency Thresholding
Import Local rule file
Change Own password
Configure Preprocessors, Preprocessor options
Enable, disable Preprocessor rules
Classify, view, create, edit,
delete, search, filter
Rules
Push to sensors * Rules
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 71 of 116 - CygnaCom Solutions Proprietary
User Security Role Operations TSF Data
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 and Virtual Defense Center
WebUI; they cannot be run from the management interface of a stand-alone 3D Sensor with
IPS.
** These functions only apply to the 3D9900 model of the 3D Sensor with IPS appliance.
*** 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 Sensor Licenses
 Add IPS License for Virtual 3D Sensors
 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 sensor To and Delete sensor From (Virtual) 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 72 of 116 - CygnaCom Solutions Proprietary
 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 sensors
 View Health Status of sensors and (Virtual) Defense Center
 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
 Generate, View Intrusion Policy and Intrusion Policy Difference Reports
 Push Intrusion Policies to sensors
 Enable and Disable Intrusion Rules
 View IPS Performance Statistics
 Configure Maximum Number of Records of the Component Databases
 Configure Network Interfaces
 Configure Network Settings
 Configure Preprocessors and Preprocessor Options
 Enable and Disable Preprocessor Rules
 Configure and Delete Recurring Tasks
 View, Edit, Create, and Delete Report Profiles
 View, Move, Download, and Delete Reports
 View Reviewed Intrusion Events
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 73 of 116 - CygnaCom Solutions Proprietary
 Classify, View, Create, Edit, Delete, Search, and Filter Rules
 Push Rules to sensors
 Delete Scheduled Tasks
 Modify sensor System Settings
 Modify (Virtual) Defense Center System Settings
 Create, Edit, and Delete sensor Groups
 View sensor, (Virtual) Defense Center, and System Statistics
 View, Add, Delete, Stop (shut-down), Restart (reboot), Set Time on, and Disable
Communications of sensors
 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 sensors
 Configure System Settings
 Create, Edit, and Delete System Variables
 Synchronize Time on Components
 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
].
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 74 of 116 - CygnaCom Solutions Proprietary
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 or Virtual Defense Center
and the 3D Sensor(s) with IPS or Virtual 3D Sensor(s) with IPS by using a
secure, SSL-encrypted TCP tunnel that uses OpenSSL Version 0.9.8k 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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 75 of 116 - CygnaCom Solutions Proprietary
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorised 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 Analyser analysis
Hierarchical to: No other components
Dependencies: IDS_SDC_EXP.1 System Data Collection
IDS_ANL_EXT.1.1 The TSF shall perform the following analysis function(s) on all IDS data
received:
a) [statistical, signature]; and
b) [
o DCE/RPC Configuration
o DNS Configuration
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 76 of 116 - CygnaCom Solutions Proprietary
o FTP & Telnet Configuration
o HTTP Configuration
o Sun RPC Configuration
o SMTP Configuration
o SSH Configuration
o SSL Configuration
o Checksum Verification
o IP Defragmentation
o Packet Decoding
o TCP Stream Configuration
o UDP Stream Configuration
o Back Orifice Detection
o Portscan Detection
o Rate-Based Attack Prevention
o Sensitive Data
].
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 Analyser 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 [
 no actions for passive deployment of 3D Sensors with IPS
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 77 of 116 - CygnaCom Solutions Proprietary
 no actions if the automatic application bypass feature is on and the configured
bypass threshold time has been exceeded
 no actions if the PEP feature has been configured to drop or fastpath network
traffic
 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 78 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 79 of 116 - CygnaCom Solutions Proprietary
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
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:
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 80 of 116 - CygnaCom Solutions Proprietary
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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 81 of 116 - CygnaCom Solutions Proprietary
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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 82 of 116 - CygnaCom Solutions Proprietary
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.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 83 of 116 - CygnaCom Solutions Proprietary
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:
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 84 of 116 - CygnaCom Solutions Proprietary
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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 85 of 116 - CygnaCom Solutions Proprietary
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.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 86 of 116 - CygnaCom Solutions Proprietary
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.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
AVA_VAN.2.2E The evaluator shall perform a search of public domain sources to
identify potential vulnerabilities in the TOE.
AVA_VAN.2.3E The evaluator shall perform an independent vulnerability analysis of the
TOE using the guidance documentation, functional specification, TOE
design and security architecture description to identify potential
vulnerabilities in the TOE.
AVA_VAN.2.4E The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the TOE is resistant to attacks
performed by an attacker possessing Basic attack potential.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 87 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 88 of 116 - CygnaCom Solutions Proprietary
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_PRO
TECTION
O.AUDIT_SOR
T
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].
The TSF must be protected from interference that would prevent it from performing its
functions [ADV_ARC.1].
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 89 of 116 - CygnaCom Solutions Proprietary
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
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].
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 90 of 116 - CygnaCom Solutions Proprietary
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
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 91 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 92 of 116 - CygnaCom Solutions Proprietary
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.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 93 of 116 - CygnaCom Solutions Proprietary
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, Virtual Defense Centers, and 3D Sensors with IPS log read-only auditing
information for user activity in the Sourcefire 3D System audit log. The Virtual 3D Sensor with
IPS, having no administrative GUI, does not record information to the audit log.
The audit log stores a maximum of 100,000 entries in the MySQL database of each
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.
Administrators can also configure a setting in the System Policy that forces users to enter
comments for the audit log each time they edit an intrusion policy.
If so configured in the System Policy, audit log records will be sent to the internal syslog of the
TOE component or sent to an external Syslog Server as they are generated.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 94 of 116 - CygnaCom Solutions Proprietary
In addition to the audit log described above, the TOE records audit information in the system
log (syslog) of each component. 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
 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 may rely on an external Syslog Server if external
logging is configured in the System Policy. AU-1 also relies on the Operational Environment to
provide secure communications between the TOE and the external Time Server and optionally
between the TOE and an external Syslog 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, Virtual 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 95 of 116 - CygnaCom Solutions Proprietary
root account. The audit suppression lists are created or modified at installation or during
maintenance; this functionality is not part of the run-time operation of the TOE 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.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 96 of 116 - CygnaCom Solutions Proprietary
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
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 system of the 3D Sensors with IPS, Defense Center and
Virtual Defense Center. The only way to access the audit records is through the Defense
Center, Virtual Defense Center, or 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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 97 of 116 - CygnaCom Solutions Proprietary
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
component‟s disk capacity is allotted for record storage) or the database limit of 100,000
records 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 disk capacity. 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.
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 or Virtual Defense Center
GUI.
 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 98 of 116 - CygnaCom Solutions Proprietary
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 0, which indicates that the password never expires. This
attribute cannot be changed after the user account is created.
 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 99 of 116 - CygnaCom Solutions Proprietary
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 or Virtual Defense Center; a stand-alone 3D Sensor with IPS configuration
cannot use external authentication. The Virtual Defense Center does not support RADIUS
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
 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. The Administrator uses the Defense Center or Virtual 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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 100 of 116 - CygnaCom Solutions Proprietary
entirely controls shell access on the appliance. Shell users are configured as local users on
the appliance when the system policy is applied.
The TOE‟s implementation of RADIUS supports the use of SecurID® tokens. When
authentication is implemented by a server using SecurID, users authenticated against that
server append the SecurID token to the end of their SecurID pin and use that as their
password when they log in. As long as SecurID is configured correctly to authenticate users
outside the Sourcefire 3D System, those users can log in using their pin plus the SecurID
token without any additional configuration.
Note: Both LDAP and RADIUS servers require TCP/IP access from the TOE 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)
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, Virtual 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, Virtual Defense Center and 3D Sensor with IPS WebUI requires a
management console with a properly configured web browser as specified in Table 1-2:
Supported Web Browsers.
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 the „User Account Privileges‟ Section of Chapter 8
of [ADMIN].
A stand-alone 3D Sensor with IPS configuration has the same user account types as a
configuration that uses a Defense Center or Virtual Defense Center. The stand-alone sensor
GUI has the same functionality as the Defense Center and Virtual 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 and Virtual Defense
Center GUI.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 101 of 116 - CygnaCom Solutions Proprietary
 Health monitoring is a Defense Center and Virtual 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 or Virtual
Defense Center configuration.
The management functions available only through the Defense Center and Virtual 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.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 102 of 116 - CygnaCom Solutions Proprietary
 “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.
Maintenance of the TOE also requires the CLI root user role. The 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. 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.
This role is required to set up the audit suppression mechanism. The audit suppression lists
are created or modified at installation or during maintenance; this functionality is not part of the
run-time operation of the TOE available through the WebUI.
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.
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.8k and can be configured for Internet Protocol Version 6
(IPv6) Internet Layer protocol or IPv4 for packet-switched internetworks.
There are four types of communications that can occur between TOE components:
 event transmission
 status updates
 remote copy
 remote execution
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 103 of 116 - CygnaCom Solutions Proprietary
All communications between TOE components use the Management Network: a private
protected network used only by the Defense Center (or Virtual Defense Center) and the 3D
Sensors with IPS and Virtual 3D Sensors with IPS it manages. All communications go through
a single channel in the SFLinux operating system used by the TOE components, 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 a Defense Center or 3D Sensor with IPS on the login page of the 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.
There is no limit to the number of character 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 and Virtual 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 sensors run
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 104 of 116 - CygnaCom Solutions Proprietary
decoders and preprocessors against detected network traffic to normalize traffic and detect
malicious packets.
The following features can affect the collection of network traffic:
 All evaluated sensors (virtual and appliance-based) support the automatic application
bypass feature. This feature allows the administrators to balance packet processing
delays with the network‟s tolerance for packet latency. Automatic application bypass
can be applied on an interface set basis. The feature functions with both passive and
inline interface sets; however, it is most valuable in inline deployments. Automatic
application bypass limits the time allowed to process packets through an IPS detection
engine and allows packets to bypass the detection engine if the time is exceeded. The
automatic application bypass option is off by default. If the option is on, the
administrator can configure the bypass threshold. The default setting is 750
milliseconds (ms). The valid range is from 250 ms to 60,000 ms.
 PEP is an optional feature available only for the 3D9900 model of the sensor
appliance. PEP allows users to immediately drop or fastpath (send through the sensor
without analysis) network traffic thereby bypassing the data collection rules for
specified targets.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 105 of 116 - CygnaCom Solutions Proprietary
Administrators can create, edit and delete detection engines through the WebUI management
functions.
To analyze the network data collected, the TOE uses policies, signatures, statistical analysis,
decoders and preprocessors.
POLICIES
Sourcefire provides default intrusion policies for both passive and inline deployments.
However, users may find that the rules and preprocessor options configured in those policies
do not address the security needs of their network. In these cases, administrators can tune the
policy by enabling or disabling preprocessor options and rules. Tuning preprocessor options
and rule sets allows configuration, at a very granular level, of how the system processes and
inspects the traffic on the network. Intrusion policies provide the following ways to tune
preprocessors:
 Deactivate preprocessors that do not apply to the traffic on the subnet that is
monitored.
 Specify ports, where appropriate, to focus the activity of the preprocessor.
 Determine whether the preprocessor will generate an event when it acts on a packet.
 Configure preprocessors to generate events when they encounter certain features in
packets, for example, state problems or certain combinations of TCP flags.
Sourcefire 3D System Version 4.9.1.4 has the capability of constructing intrusion policies in
building blocks, called policy layers. By editing a company-wide policy layer, all intrusion
policies that incorporate that policy layer can be updated instantly. Further, a hierarchy exists
among policy layers. Sourcefire-defined policies form the foundation, and can be superseded
by user-defined policy layers. Users can define their own policy layers by company, by
department, by network, or even by user. Settings in higher policy layers take precedence over
settings in lower policy layers.
For example, an intrusion rule can be set to generate an event in the Company-Wide layer, but
the set to be disabled in the Site-Specific layer. In this case, the rule is disabled in the overall
intrusion policy as the higher configuration layer takes precedence. Administrators can add,
rename, rearrange, and share policy layers and can view whether a rule or preprocessor
setting is configured in a layer or in a layer above or below it in the stack.
In Sourcefire 3D System Version 4.9.1.4, a policy can be associated with a detection engine or
set of detection engines as is it created. Administrators can also customize intrusion policies to
inspect traffic for one or more VLANs or subnets. This capability affords greater flexibility by
enabling organizations to inspect traffic differently for distinct network segments. It also allows
the ability to leverage multiple policies on a single detection engine, and prevents the mixing of
intrusion events from multiple network segments.
Note: A policy can be filtered by network or VLAN, but not by both.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 106 of 116 - CygnaCom Solutions Proprietary
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.
SIGNATURES
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 that 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.
Note: Sourcefire cannot guarantee the correctness of signatures available on public Snort
forums and websites.
The WebUI provides a graphical rule editor, which 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 28: Understanding and
Writing Intrusion Rules, of [ANALYST].
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.
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 107 of 116 - CygnaCom Solutions Proprietary
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)
o CIDR blocks - Executes against packets whose destination IP address falls
within the specified CIDR block. For example, in the following rule, the
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 108 of 116 - CygnaCom Solutions Proprietary
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. The Section
„Understanding Keywords and Arguments in Rules‟ in Chapter 28 of [ANALYST] lists the
keywords and how to use them when writing or modifying a rule.
STATISTICAL ANALYSIS
Sourcefire 3D System Version 4.9.1.4 includes a limited capability to detect and block rate-
based denial-of-service (DoS) and distributed denial of service (DDoS) attacks (for example,
SYN floods). Rate-base attack prevention identifies abnormal traffic patterns and attempts to
minimize the impact of that traffic on legitimate service requests. Sourcefire‟s IPS functionality,
without the use of a TCP proxy function, can detect hosts attempting to initiate or receive a
configured number of connection attempts in a given time period, as well as hosts that have
already established or received a configured number of connections in a given time period.
(Virtual) 3D Sensors with IPS deployed in passive mode can detect certain kinds of rate-based
attacks, while (Virtual) 3D Sensors with IPS deployed in inline mode can block such attacks.
Intrusion policies can be configured to include a rate-based filter which detects when too many
matches for a rule occur in a given time period. This filter identifies excessive rule matches in
traffic going to a particular destination IP address(es) or coming from a particular source IP
address(es). Intrusion policies can also be configured to respond to excessive matches for a
particular rule across all traffic detected by the detection engine.
A rate-based filter can be configured for any intrusion or preprocessor rule in an intrusion
policy. The rate-based filter contains three components:
 The rule matching rate, which is configured as a count of rule matches within a specific
number of seconds
 A new action to be taken when the rate is exceeded, with three available actions:
o do not alert
o alert
o alert and drop
 The duration of the action, which is configured as a timeout value
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 109 of 116 - CygnaCom Solutions Proprietary
Note that once started, the new action occurs until the timeout is reached, even if the rate falls
below the configured rate during that period. When the timeout is reached, if the rate has fallen
below the threshold, the action for the rule reverts to that initially configured for the rule.
Rate-based attack prevention can be configured in an inline deployment to block attacks,
either temporarily or permanently. Without rate-based configuration, enabled rules generate
events, but IPS does not drop packets for those rules. However, if the attack traffic matches
rules that have rate-based criteria configured, the rate action can cause packet dropping to
occur for the period of time that the rate action is active, even if those rules are not initially set
to drop.
DECODERS and PREPROCESSORS
Sourcefire 3D System Version 4.9.1.4 includes preprocessor rules. Just as users can enable,
disable, and set to drop any Snort-based intrusion rule, they can also use those same
concepts to control preprocessor behavior. A detection engine or set of detection engines can
be associated with a policy as it is created.
The following decoders and preprocessors are available for the detection of stateful or
malformed intrusions:
 DCE/RPC Configuration - Examines DCE/RPC traffic for fragmented request packets,
and reassembles them so the rules engine can inspect the complete packets.
 DNS Configuration - 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
 FTP & Telnet Configuration - Decodes Telnet traffic and the FTP command channel
for analysis against signatures (similar to HTTP Normalization).
 HTTP Configuration - (HTTP Decode and Normalization) Responsible for:
o Decoding the URI portion of HTTP requests into non-obfuscated ASCII
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
 Sun RPC Configuration - Decodes RPC traffic for analysis against signatures (similar
to HTTP Normalization).
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 110 of 116 - CygnaCom Solutions Proprietary
 SMTP Configuration - Decodes SMTP traffic for analysis against signatures (similar to
HTTP Normalization).
 SSH Configuration - Detects and alerts on the Challenge-Response Buffer Overflow
exploit, the CRC-32 exploit, the SecureCRT SSH Client Buffer Overflow exploit,
protocol mismatches, and incorrect SSH message direction. The preprocessor also
alerts on any version string other than version 1 or 2.
 SSL Configuration – 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.
 Checksum Verification - Verifies the size of packets being sent to the network,
detecting malformed packets that may be used in various attacks.
 IP Defragmentation - Enables the TOE to rebuild packets that have been fragmented
by the network prior to inspection against other decoders, preprocessors, and
signatures.
 Packet Decoding - Performs the initial decoding so that it can be processed by the
other decoders, preprocessors, and intrusion rules. The primary packet decoder for
traffic from the NIC.
 TCP Stream Configuration - Provides stateful inspection of packets for TCP traffic,
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.
 UDP Stream Configuration - Provides stateful inspection of packets for UDP traffic,
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.
 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.
 Portscan Detection- 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.
 Rate-Based Attack Prevention – Enables detection of rate-based attacks as
described in the Statistical Analysis description above.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 111 of 116 - CygnaCom Solutions Proprietary
 Sensitive Data - Detects and Generates events on sensitive data in ASCII text (Social
Security numbers, credit card numbers, driver‟s license numbers …) which can be
used to detect accidental data leaks.
ID-2: System Data Analysis has a dependency on the Operational Environment to provide the
user with updated rules and signature information that can then be input manually.
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 of an
TOE component. 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 component‟s operating system.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 112 of 116 - CygnaCom Solutions Proprietary
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
intrusion events it detects to the syslog facility on the component 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.
Note: Sourcefire 3D System Version 4.9.1.4 supports SNMP v1, v2 and v3.
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.
However, no actions to drop or replace traffic when a possible intrusion has been detected will
be taken if the following conditions hold true:
 passive deployment of 3D Sensors with IPS
 automatic application bypass feature is on and the bypass threshold time configured
has been exceeded
 the PEP feature has been configured to drop or fastpath network traffic
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
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 113 of 116 - CygnaCom Solutions Proprietary
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 and Virtual 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
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.
Event data log records are stored by the Defense Center, Virtual Defense Center and 3D
Sensor with IPS in their corresponding MySQL database. The Virtual 3D Sensor with IPS does
not store event data; rather the data is passed for storage to the sensor‟s managing Defense
Center (or Virtual Defense Center).
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 TOE component‟s database. The TSF overwrites the oldest
events when it reaches the defined database limit or disk 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. The limit is 10 million intrusion events on the Virtual Defense Center. When the disk
space of the component 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 that users assigned to the Administrator Role will receive an
email warning when the event data is automatically overwritten.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 114 of 116 - CygnaCom Solutions Proprietary
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 which are installed on the
appliances and which comprise the Virtual 3D Sensor with IPS and Virtual Defense Center
components).
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 MySQL
database and the Linux-derived operating system that are part of the TOE components.
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
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 each component‟s 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 system of each TOE component. Communications between the
(Virtual) 3D Sensors with IPS and the (Virtual) 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 encryption mechanisms (OpenSSL) included in
the TOE. The interfaces between TOE components can be configured to use either IPv6 or
IPv4 protocol.
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.
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 115 of 116 - CygnaCom Solutions Proprietary
The TOE also implements health policies that allow administrators to monitor the health and
performance (CPU, disk, memory, temperature) of all TOE components both (Virtual) 3D
Sensors with IPS and (Virtual) Defense Centers.
The 3D Sensor with IPS and Defense Center rely on the appliance hardware that is part of
these components for protection. Besides the security features of the TOE itself, the Virtual 3D
Sensor with IPS and Virtual Defense Center TOE components rely on the hardware of their
host platform and the security features of the platform OS and VMware ESX implementation,
which are part of the Operational Environment, for protection.
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. Only the Defense Center
(appliance-base and virtual) and the 3D Sensors with IPS offer web-based administrative
interfaces; the Virtual 3D Sensor with IPS does not. 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 user 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/or [VIRTUAL-
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 [ADMIN] in order to properly configure and manage the
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,
Sourcefire 3D System Version 4.9.1.4 Security Target
Sourcefire, Inc. Proprietary - 116 of 116 - CygnaCom Solutions Proprietary
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.