1 of 49 National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Validation Report 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) Report Number: CCEVS-VR-VID10334-2010 Dated: June 23, 2010 Version: 1.0 National Institute of Standards and Technology National Security Agency Information Technology Laboratory Information Assurance Directorate 100 Bureau Drive 9800 Savage Road STE 6757 Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6757 2 of 49 ACKNOWLEDGEMENTS Validation Team Mr. Daniel P. Faigin, CISSP The Aerospace Corporation El Segundo California Dr. Patrick Mallett The MITRE Corporation, McLean, Virginia Common Criteria Testing Laboratory Mr. Deepak Somesula CygnaCom Solutions McLean, Virginia Much of the material in this report was extracted from evaluation material prepared by the CCTL. The CCTL team deserves credit for their hard work in developing that material. Many of the product descriptions in this report were extracted from the Sourcefire 3D System, Version 4.8.2.1 (SEU 259) Security Target. 3 of 49 Table of Contents 1 Executive Summary ................................................................................................... 6 2 Identification.............................................................................................................. 8 3 Security Policy............................................................................................................ 9 3.1 Security Audit Functions............................................................................................. 9 3.2 Identification and Authentication Functions............................................................. 9 3.3 Security Management Functions .............................................................................. 10 3.4 Protection of Security Functions............................................................................... 11 3.5 TOE Access Functions............................................................................................... 11 3.6 System Data Collection Functions............................................................................ 11 3.7 System Data Analysis Functions............................................................................... 11 3.8 System Data Review, Availability and Loss Functions........................................... 12 3.9 Summary..................................................................................................................... 12 3.9.1 Security Functional Requirements.........................................................................................12 3.9.2 Operational Environment Objectives.....................................................................................15 4 Assumptions and Clarification of Scope................................................................. 17 4.1 Usage Assumptions .................................................................................................... 17 4.2 Assumptions................................................................................................................ 17 4.3 Clarification of Scope................................................................................................. 18 5 Architectural Information ....................................................................................... 21 6 Documentation......................................................................................................... 25 6.1 Guidance Documentation.......................................................................................... 25 6.2 Security Target (ST) .................................................................................................. 25 6.3 Development (ADV) Evidence Documentation ....................................................... 25 6.4 Life-Cycle (ALC) Evidence Documentation ............................................................ 26 6.5 Testing (ATE) and Vulnerability Analysis (AVA) Documentation....................... 26 6.6 Evaluation Technical Report (ETR) ........................................................................ 26 7 IT Product Testing ................................................................................................... 27 7.1 Developer Testing....................................................................................................... 27 7.1.1 Overall Test Approach and Results: ......................................................................................27 7.1.2 Depth and Coverage ..............................................................................................................27 7.1.3 Results ...................................................................................................................................28 7.2 Evaluator Independent Testing ................................................................................ 28 7.2.1 Execution the Developer‘s Functional Tests .........................................................................28 7.2.2 Team-Defined Functional Testing.........................................................................................29 7.2.3 Vulnerability/Penetration Testing..........................................................................................30 8 Evaluated Configuration ......................................................................................... 31 4 of 49 9 Results of Evaluation............................................................................................... 36 10 Validators Comments and Recommendations ........................................................ 38 11 Security Target......................................................................................................... 39 12 Glossary.................................................................................................................... 40 12.1 Acronyms.................................................................................................................... 40 12.2 Terminology................................................................................................................ 41 13 Bibliography............................................................................................................. 49 5 of 49 List of Figures Figure 1: TOE: Boundary - Sourcefire 3D System with Defense Center......................... 23 Figure 2: TOE: Boundary - Sourcefire 3D System using a stand-alone 3D Sensor with IPS............................................................................................................................. 24 Figure 3 : A DC3000 Defense Center managing three sensors deployed in inline mode (Configuration 1) ...................................................................................................... 32 Figure 4: A DC3000 Defense Center managing a 3D2500 Intrusion Sensor deployed in inline mode (Configuration 2a)................................................................................. 32 Figure 5: A DC3000 Defense Center managing a 3D2500 Intrusion Sensor deployed in passive mode............................................................................................................. 33 Figure 6: A standalone 3D2500 Intrusion Sensor deployed in inline mode (Configuration 3a) ............................................................................................................................. 33 Figure 7: A standalone 3D2500 Intrusion Sensor deployed in passive mode (Configuration 3b) .................................................................................................... 34 Figure 8: A DC3000 Defense Center managing a SVLinux Intrusion Sensor deployed in inline mode (Configuration 4) .................................................................................. 34 Figure 9: A DC3000 Defense Center managing a SBLinux Intrusion Sensor deployed in inline mode (Configuration 5) .................................................................................. 35 6 of 49 1 Executive Summary This Validation Report (VR) documents the evaluation and validation 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). This VR is not an endorsement of the IT product by any agency of the U.S. Government and no warranty of the IT product is either expressed or implied. The Target of Evaluation (TOE) is an Intrusion Detection System, which consists of the Sourcefire Defense Center and Sourcefire 3D Sensor licensed for IPS appliances and Sourcefire 3D System Version 4.8.2.1 (SEU 259) software. The TOE is an Intrusion Detection System that combines open-source and proprietary technology. The TOE is used to monitor incoming (and outgoing) network traffic, from either inside or outside a firewall. All packets on the monitored network are scanned, decoded, processed and compared against a set of rules to determine whether inappropriate traffic, such as system attacks, is being passed over the network. The system then notifies a designated TOE administrator of these attempts. The system generates these alerts when deviations of the expected network behavior are detected and when there is a match to a known attack pattern. Note: The evaluation team did not evaluate the Sourcefire supplied rule sets that are bundled with the TOE for suitability to task—only that the tests included in the rule sets work correctly The Sourcefire 3D Sensor is based on the open source Snort IDS. Snort is used to read all the packets on the monitored network, and then analyze them against the rule set that has been created by the TOE administrators. The Sourcefire-modified Snort, version 2.8.3, is included in the TOE. 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 information; and system data collection, analysis, review, availability and loss. Note: The TOE does not meet all the technical requirements of 800-53; interested readers should refer to the validators comments in Section 10 for identified specifics. Note: The cryptography used in this product has not been FIPS certified nor has it been analyzed or tested to conform to cryptographic standards during this evaluation. All cryptography has only been asserted as tested by the vendor. The TOE is intended for use in computing environments where there is a low level threat of malicious attacks. The assumed level of expertise of the attacker for all the threats is unsophisticated. 7 of 49 The evaluation was performed by the CygnaCom Common Criteria Testing Laboratory (CCTL), and was completed in June 2010. The information in this report is derived from the Evaluation Technical Report (ETR) and associated test reports, all written by the CygnaCom CCTL. The evaluation team determined that the product is Common Criteria version 3.1 R2 [CC] Part 2 extended and Part 3 conformant, and meets the assurance requirements of EAL 2 augmented with ALC_FLR.2 from the Common Methodology for Information Technology Security Evaluation, Version 3.1 R2, [CEM]. This Security Target 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). The evaluation and validation were consistent with National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) policies and practices as described on their web site www.niap-ccevs.org. The Security Target (ST) is contained within the document Sourcefire 3D System Security Target (Sourcefire Defense Center: models DC500, DC1000, and DC3000; and Sourcefire 3D Sensor licensed for IPS: models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800) Version 4.8.2.1 (SEU 259) 8 of 49 2 Identification Target of Evaluation: 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) Evaluated Software and Hardware: Sourcefire 3D System Version 4.8.2.1 (SEU 259) consisting of the following components: The Sourcefire 3D Sensor licensed for IPS models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800 The Sourcefire Defense Center models DC500, DC1000, and DC3000 Developer: Sourcefire, Inc. CCTL: CygnaCom Solutions 7925 Jones Branch Dr, Suite 5200 McLean, VA 22102-3321 Evaluators: Deepak Somesula Validation Scheme: National Information Assurance Partnership CCEVS Validators: Daniel P. Faigin, Dr. Patrick Mallett CC Identification: Common Criteria for Information Technology Security Evaluation, Version 3.1 R2, September 2007 CEM Identification: Common Methodology for Information Technology Security Evaluation, Version 3.1 R2, September 2007 9 of 49 3 Security Policy The TOE‘s security policy is expressed in the security functional requirements identified in Section 6.1 of the ST. Potential users of this product should confirm that functionality implemented is suitable to meet the user‘s requirements. The TOE provides the following security features: 3.1 Security Audit Functions The TOE is able to audit the use of the administration/management functions of the IDS. This audit is separate from the IDS functionality (recording network traffic), and relates specifically to the management functions of the TOE. This function records attempts to access the system itself, such as successful and failed authentication, as well as the actions taken by TOE users once they are authenticated. Auditable actions include changes to the IDS rules and viewing/modifying the audit records of both the system access and the IDS event log. The audit data is protected by the access control mechanisms of the database and OS of the appliances and by the TOE management interface. Only users with the Administrator Role have access to the audit records. Users having the Administrator Role can view and sort the audit records. Suppression lists may be configured during installation and maintenance to limit the events recorded. When the available audit storage is exhausted, the TOE automatically overwrites the oldest audit events. This ensures that the availability of the most recent audit events is limited only by the size of the audit trail. It is the responsibility of the administrator to perform periodic backups of the audit data (via the WebUI backup function) to prevent loss of data. Security Audit depends on the Operational Environment to provide reliable time for the audit records. It depends on an Email Server in the Operational Environment to provide warnings to administrators when the audit records are overwritten. It also depends on the Operational Environment to provide a secure communications path between the TOE and the external servers. 3.2 Identification and Authentication Functions 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 through the use of an external authentication server (LDAP or RADIUS) for configurations that include a 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. The user account also contains a password strength check attribute. If selected the user‘s 10 of 49 password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. It cannot be a word that appears in a dictionary or include consecutive repeating characters. The strength check applies only to user authentication done by the TOE for access to the management GUI; it does not apply to user authentications done by an external LDAP or RADIUS server. 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. 3.3 Security Management Functions 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. 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 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 also perform system level maintenance related actions. ―Intrusion Event Analyst‖ Role: this role can view, analyze, review, and delete intrusion events and can also create incidents and generate reports. ―Intrusion Event Analyst (Read Only)‖ Role: this role has read-only access to IPS analysis features, including intrusion event views, incidents, and reports. ―Restricted Event Analyst‖ Role: this role provides access to the same features as the Intrusion Event Analyst role, but is restricted to only those events that match specified search criteria (specific IP Addresses or subsets of data). ―Restricted Event Analyst (Read Only)‖ Role: this role is the same as the Restricted Event Analyst role except that users have read-only access to the intrusion events that match the specified search criteria. ―Policy and Response Administrator‖ Role: this role can create, modify, and implement intrusion policies and intrusion rules for the IDS. 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. 11 of 49 Security management relies on a management console in the Operational Environment with a properly configured Web Browser to support the web-based management interfaces. 3.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 through strong encryption during both setup and the transition of data. 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. 3.5 TOE Access Functions The TOE enhances the functionality of user session establishment by displaying a warning banner upon user login. 3.6 System Data Collection Functions 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. Note: The evaluation team did not evaluate the Sourcefire supplied rule sets that are bundled with the TOE for suitability to task—only that the tests included in the rule sets work correctly 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 physically secure communications path between the TOE and the external time server. 3.7 System Data Analysis Functions To analyze the data collected by the 3D Sensors with IPS, the TOE uses signatures, decoders, and preprocessors. Signatures are patterns of traffic that can be used to detect potential attacks or exploits. Since many attacks or exploits require several network connections to work, the IDS also provides the ability to detect these more complex patterns through decoders and preprocessors that are included in the TOE. The TOE embodies signatures, decoders, and preprocessors in rules that can be designed and exercised by the TOE. 12 of 49 The TOE administrators can manage the signature identification capabilities by adding and editing rules to respond to the latest exploits. In addition, based upon results of analysis, the TOE administrators can trigger alarms for the notification of a problem. The Snort engine is used to read all the packets on the monitored network, and then analyze them against the rule set that has been created by the TOE administrators. System Data Analysis relies on the Operational Environment to support the notification of administrators via email and (optionally) SNMP (v2 or v3) and syslog alarms. It also depends on the Operational Environment to provide a secure communications path between the TOE and the external servers. 3.8 System Data Review, Availability and Loss Functions IDS event logs can only be viewed by authorized TOE users (users with the Administrator or Intrusion Event Analyst Roles). The data stores of the raw collection data are constantly monitored and if they become too full, new records will replace the oldest records to prevent active/current data loss. It is the responsibility of the administrator to 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. 3.9 Summary 3.9.1 SECURITY FUNCTIONAL REQUIREMENTS A summary of the SFRs for the TOE follows. Note that _EXT in the SFR ID indicates extended requirements. 1. FAU_GEN.1: Audit data generation The TOE generates 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 The TOE records at least the following information: date and time of the event, type of event, subject identity, the outcome (success or failure) of the event and additional information depending on the event type, within each audit record. 2. FAU_SAR.1: Audit review The TOE provides users with the Administrator Role the ability to read all audit information. 3. FAU_SAR.2: Restricted audit review 13 of 49 Unless a user has been granted read-access, the TOE prohibits access to the audit records. 4. FAU_SAR.3: Selectable audit review The TOE provides the ability to sort the audit data based on date and time, subject identity, type of event, and success or failure of related event. 5. FAU_SEL.1: Selective audit The TOE allows events to be included or excluded from the audit record based on: event type, [IP address, message, subsystem, and username. 6. FAU_STG.2: Guarantees of data availability The TOE protects the stored audit records from unauthorized deletion. The TSF is able to detect unauthorized modifications to the audit records. 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. 7. FAU_STG.4: Prevention of audit data loss The TOE overwrites the oldest stored audit records and sends an alarm if the audit trail storage is full. 8. FIA_ATD.1: User attribute definition User account information is stored in the TOE and contains the following attributes: o User Name o Authentication Data (password) o Assigned Role(s) (authorizations) 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 9. FIA_UAU_EXT.1: Timing of authentication Each user must be successfully authenticated either by the TOE or by an authentication service (LDAP or RADIUS) in the Operational Environment invoked by the TOE before the TOE allows any actions aside from entry of the user‘s login data. 14 of 49 10. FIA_UID.1: Timing of identification Each user must be successfully identified before the TOE allows any actions aside from entry of the user‘s login data. 11. FMT_MOF.1: Management of security functions behavior The TOE restricts the ability to modify the system data collection, analysis and reaction and audit data generation functions of the TOE by user role. 12. FMT_MTD.1: Management of TSF data The TOE restricts the management functions of the TOE by user role. 13. FMT_SMF.1 Specification of Management Functions The TOE is capable of performing security management functions through the TOE user interfaces. 14. FMT_SMR.1: Security roles The TOE maintains the user roles: o Administrator o Maintenance o Intrusion Event Analyst o Intrusion Event Analyst (Read Only) o Restricted Event Analyst o Restricted Event Analyst (Read Only) o Policy and Response Administrator 15. FPT_ITT.1: Basic internal TSF data transfer protection The TOE protects data from disclosure and modification when it is transmitted between the Defense Center and the 3D Sensor(s) with IPS by using a secure, SSL-encrypted TCP tunnel. 16. FTA_TAB.1: Default TOE access banners The TOE has the capability to display a warning message regarding unauthorized use of the TOE on the user login screen. 17. IDS_SDC_EXT.1: System Data Collection The TOE is able to collect network traffic information from targeted IT System resource(s). The TOE collects and records the following network traffic information: date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; Protocol Source address Destination address. 18. IDS_ANL_EXT.1: Analyzer analysis The TOE uses signatures, decoders and preprocessors to analyze the network data collected. 15 of 49 19. IDS_RCT_EXT.1: Analyzer react When an intrusion is detected, the TOE is able to send an alarm to a designated email administrative address, an external syslog server, and/or an external trap server. When an intrusion is detected the TOE is able to drop or replace packets containing suspicious network traffic according to the administrator configured rules for inline deployment of 3D Sensors with IPS. (The TOE will take no actions for sensors passively configured.) 20. IDS_RDR_EXT.1: Restricted Data Review The TOE provides only users with the Administrator or Intrusion Event Analyst Role with the capability to read all captured IDS data from the system data 21. IDS_STG_EXT.1: Guarantee of System Data Availability The TOE protects the stored audit records from unauthorized modification and deletion. When the available system storage is exhausted, the TOE automatically overwrites the oldest system event data. 22. IDS_STG_EXT.2: Prevention of System data loss The TSF will overwrite the oldest stored system data and send an alarm if the storage capacity has been reached. 3.9.2 OPERATIONAL ENVIRONMENT OBJECTIVES The TOE‘s operating environment must satisfy the following objectives. 1. 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. 2. Those responsible for the TOE must ensure that those parts of the TOE critical to security policy are protected from any physical attack. 3. 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. 4. Personnel working as authorized administrators shall be carefully selected and trained for proper operation of the system. 5. The TOE is interoperable with the IT System it monitors. 6. The Operational Environment will provide reliable timestamps to the TOE. 7. The Operational Environment will provide mechanisms to notify responsible personnel of a possible problem. 8. The Operational Environment must provide a mechanism to establish a trusted communications path which provides for the protection of the data from 16 of 49 modification or disclosure while being exchanged between TOE components and external entities. 9. The Operational Environment must provide an authentication service for user identification and authentication that can be invoked by the TSF to control a user‘s logical access to the TOE. Note: This objective is only applicable when the TOE is configured to use an external LDAP or RADIUS authentication service. 17 of 49 4 Assumptions and Clarification of Scope 4.1 Usage Assumptions For secure usage, the operational environment must be managed in accordance with the documentation associated with the following EAL 2 assurance requirements. AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.2 Use of a CM system ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery procedures 4.2 Assumptions TOE Intended Usage Assumptions: The administrators must make sure that the Defense Center and 3D Sensors with IPS have full access to the networks and external servers in the Operational Environment. Administrators must make sure that they use the administrative functions of the WebUI and the CLI to modify the TOE configuration in response to any Operational Environment changes. 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. TOE Physical Assumptions: Access to the Defense Center and the 3D Sensors with IPS must be physically restricted. (e.g. located within controlled access facilities, which will prevent unauthorized physical access) TOE Personnel Assumptions: Administrators of the TOE must be carefully selected and be properly trained to manage the TOE and ensure the security of the information it contains. Only required personnel should have user accounts on the system and they must protect their authentication information (username and password). 18 of 49 4.3 Clarification of Scope All evaluations (and all products) have limitations, as well as potential misconceptions that need clarifying. This text covers some of the more important limitations and clarifications of this evaluation. Note that: 1. As with any evaluation, this evaluation only shows that the evaluated configuration meets the security claims made, with a certain level of assurance (EAL 2 in this case). 2. This evaluation only covers the specific version of the product identified in this document, and not any earlier or later versions released or in process. 3. As with all EAL 2 evaluations, this evaluation did not specifically search for, nor seriously attempt to counter, vulnerabilities that were not ―obvious‖ or vulnerabilities to objectives not claimed in the ST. The CEM defines an ―obvious‖ vulnerability as one that is easily exploited with a minimum of understanding of the TOE, technical sophistication and resources. 4. The following are not included in the Evaluation Scope: Real-Time Network Awareness (RNA) – RNA is a separate product that requires additional licensing Vulnerability Assessment (VA) - VA requires integration with Nessus and NMAP and is only applicable with RNA license Network Behavior Analysis (NBA) – NBA requires an RNA license Collection of data from NetFlow devices– requires Cisco NetFlow and an RNA license Adaptive IPS – uses information from RNA Real-Time User Awareness (RUA) – RUA is a separate product that requires additional licensing NAC and Network Usage Control (NUC) – requires RUA license Intrusion Agents - Requires an existing installation of Snort Estreamer Application Programming Interface (API) - Estreamer integration requires custom programming Security Enhancement Updates (SEU) – The updates may include binary updates to the TOE software, which will take the product out of the evaluated configuration when installed A Master Defense Center (MDC) – requires a multiple Defense Center configuration The High Availability feature - requires a multiple Defense Center configuration IPS for Crossbeam Systems Security Switches (software-only sensors) 19 of 49 Switched Stack System Interconnect (―stack‖) configuration (installation of an additional chassis using a stack cable) Integration with and remediation of traffic to firewalls, including: Integration with Cisco PIX and Checkpoint firewalls Integration with and remediation of traffic to external 3rd-party products, including: Sending alerts through trouble ticket systems Interfaces with the Shavlik patch management system 5. The Operational Environment needs to provide the following capabilities: The Web Browser for the Defense Center and 3D Sensor with IPS Management Interfaces. Only the following are supported for Sourcefire 3D System Version 4.8.2.1: Firefox Version (Minimum) 2.x Microsoft Internet Explorer Version 6.0 with Service Pack 2 Microsoft Internet Explorer Version 7.0 The protected network(s) used for communications between the TOE components The network(s) that are to be monitored Network Authentication Services A trusted DNS Server An external NTP Server An external Email Server An optional Syslog Server An optional SNMP (v2 or v3) Trap Server An optional LDAP or RADIUS Authentication Server The ST provides additional information on the assumptions made and the threats countered. Note: The evaluation team did not evaluate the Sourcefire supplied rule sets that are bundled with the TOE for suitability to task—only that the tests included in the rule sets work correctly Note: The cryptographic functions used by the TOE are not FIPS certified. Correctness of the encryption mechanisms used by the TOE is by Vendor Assertion. Note: The following TOE components were used in testing: DC3000 (SFLinux) 20 of 49 3D2500 sensor (SFLinux) 3D5800 sensor (SBLinux) 3D9800 sensor (SVLinux) Because of their identical functionality and behavior only one 3D Sensor appliance from each category of 3D Sensors was used in testing. Note: The sensors were located in the same physical location as the Defense Center in the testing scenarios. This is equivalent to deployment scenarios where the sensors are in multiple physical locations because the same SSL-encrypted communications channel is used between the sensors and Defense Center, except that it is transmitted over a VPN in the multi-site scenario. 21 of 49 5 Architectural Information 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. A detection engine is the mechanism on a Sourcefire 3D Sensor that is responsible for analyzing the traffic on the network segment where the sensor is connected. A detection engine has two main components: an interface set, which can include one or more sensing interfaces a detection resource, which is a portion of the sensor‘s computing resources Depending on which components are licensed on the sensor, Sourcefire 3D Sensors can support three types of detection engines: Intrusion Prevention System (IPS) Real-Time Network Awareness (RNA) Real-Time User Awareness (RUA) Only IPS is included in the scope of this evaluation. Each 3D Sensor with IPS uses rules, decoders, and preprocessors to look for the broad range of exploits that attackers have developed. Sourcefire 3D Sensors that are licensed to use IPS are packaged with a set of intrusion rules developed by the Sourcefire Vulnerability Research Team (VRT). The TOE administrators can choose to enable rules that would detect the attacks most likely to occur on the monitored network. Custom intrusion rules and policies can also be created for a customer‘s operating environment. Note: The evaluation team did not evaluate the Sourcefire supplied rule sets that are bundled with the TOE for suitability to task—only that the tests included in the rule sets work correctly When a 3D Sensor with IPS identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. 3D Sensors with IPS can be deployed either inline, where "live" traffic passes through the appliance, or passively, in which case traffic is being only monitored. When used inline, IPS can block malicious code and attacks in real-time so that the 3D Sensor with IPS is used as an intrusion prevention device. In a passive deployment, the sensing interfaces connected to the network are configured in stealth mode so that, to other devices on the network, the sensor itself does not appear to be connected to the network at all. A benefit of passive deployment is that almost all of the sensor bandwidth and computational power are devoted to monitoring traffic, reconstructing datagrams and streams, normalizing packets, detecting anomalies, and sending alerts of possible intrusions. Moreover, because the sensor is deployed out of 22 of 49 band and operates in stealth mode, attackers are unlikely to know of its existence, which renders it less of a target for attacks. However, in a passive deployment the 3D Sensor with IPS can only perform passive intrusion detection and send alerts when it detects malicious traffic packets, but it cannot affect the flow of network traffic. Both the inline and passive deployments are included in the evaluated configuration. In addition, 3D Sensors with IPS run decoders and preprocessors against detected network traffic to normalize traffic and detect malicious packets. If the 3D Sensor with IPS is deployed inline on the network and creates what is called an inline detection engine, the 3D Sensor with IPS can be configured to drop or replace packets that are known to be harmful. The Sourcefire Defense Center provides a centralized management interface for the Sourcefire 3D System. The Defense Center is used to manage the full range of sensors that are a part of the Sourcefire 3D System, and to aggregate, analyze, and respond to the threats they detect on the monitored network. In a Sourcefire 3D System deployment that includes 3D Sensors with IPS and a Defense Center, the sensors transmit events and sensor statistics to the Defense Center where the aggregated data can be viewed. Some models of the 3D Sensor with IPS provide a local web interface (WebUI) to create intrusion policies and review the resulting intrusion events and therefore can be run stand-alone, without using a Defense Center for management. The Defense Center provides the following functionality through a web-based GUI (WebUI): An interface which displays all the data collected by the managed 3D Sensors with IPS allowing: monitoring of the information that the sensors are reporting in relation to one another 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 TOE consists of the Defense Center and 3D Sensor with IPS components described above. The physical boundary of the TOE is the Sourcefire 3D Sensor licensed for IPS and the Sourcefire Defense Center appliances installed with the Sourcefire 3D System Version 4.8.2.1 software, Linux-derived operating system, MySQL database, and 23 of 49 supporting 3rd party software as commercially available from the developer. The TOE Boundary is depicted in Figure 1 and Figure 2. Figure 1: TOE: Boundary - Sourcefire 3D System with Defense Center Monitored Network Network Asset Network Asset Network Asset Network Asset Network Asset Management Network (Private Network among TOE components) WebUI Defense Center Appliance 3D System Software DC MySQL 3rd Party Software Applications Linux-Derived Operating System 3D System Software MySQL 3D Sensor Appliance 3rd Party Software Applications Linux-Derived Operating System IPS RNA RUA MySQL 3rd Party Software Applications Linux-Derived Operating System RNA RUA 3D Sensor Appliance 3D System Software IPS NTP Server EMAIL Server SNMP Server LDAP / RADIUS Server DNS Server Syslog Server Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE Monitored Network Network Asset Network Asset Network Asset Network Asset Network Asset Management Network (Private Network among TOE components) WebUI Defense Center Appliance 3D System Software DC MySQL 3rd Party Software Applications Linux-Derived Operating System 3D System Software MySQL 3D Sensor Appliance 3rd Party Software Applications Linux-Derived Operating System IPS RNA RUA MySQL 3rd Party Software Applications Linux-Derived Operating System RNA RUA 3D Sensor Appliance 3D System Software IPS NTP Server EMAIL Server SNMP Server LDAP / RADIUS Server DNS Server Syslog Server Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE 24 of 49 Figure 2: TOE: Boundary - Sourcefire 3D System using a stand-alone 3D Sensor with IPS Monitored Network Network Asset Network Asset Network Asset Network Asset Network Asset WebUI 3D Sensor Appliance 3D System Software MySQL 3rd Party Software Applications Linux-Derived Operating System NTP Server EMAIL Server SNMP Server DNS Server Syslog Server RUA RNA IPS Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE Monitored Network Network Asset Network Asset Network Asset Network Asset Network Asset Network Asset Network Asset Network Asset Network Asset Network Asset WebUI 3D Sensor Appliance 3D System Software MySQL 3rd Party Software Applications Linux-Derived Operating System NTP Server EMAIL Server SNMP Server DNS Server Syslog Server RUA RNA IPS Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE Network Asset Environment Component (required) Environment Component (optional) TOE Component Product Component Not in TOE 25 of 49 6 Documentation This section details the documentation that is (a) delivered to the customer, and (b) was used as evidence for the evaluation of the Network Security Platform and methodology for delivery of the evaluated configuration. In these tables, the following conventions are used: Documentation that is delivered to the customer is shown with bold titles. Documentation that was used as evidence but is not delivered is shown in a normal typeface. The TOE is physically delivered to the End-User. The guidance is part of the TOE and is delivered in printed form and as PDFs on the installation media. 6.1 Guidance Documentation The following documents are developed and maintained by Sourcefire and delivered to the end user of the TOE: [1] Sourcefire 3D System - 3D Sensor Installation Guide, Version 4.8.2, 2009-Oct- 02. [2] Sourcefire 3D System - Defense Center Installation Guide, Version 4.8, 2008- Jul-23. [3] Sourcefire 3D System - Sourcefire 3D System User Guide, Version 4.8.2, 2009-Sep-01. [4] Sourcefire 3D System - CC Supplement for Version 4.8.2.1, 2010-Jun-08. 6.2 Security Target (ST) Security Target (ST) [1] Sourcefire 3D System Security Target (Sourcefire Defense Center: models DC500, DC1000, and DC3000; and Sourcefire 3D Sensor licensed for IPS: models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800), Version 4.8.2.1 (SEU 259), Version 1.15, 2010- Jun-10. 6.3 Development (ADV) Evidence Documentation [1] Sourcefire 3D System Version 4.8.2.1 Functional Specification, Version 1.1, 2010-Apr-26. [2] Sourcefire 3D System Version 4.8.2.1 TOE Design, Version 1.1, 2010-Apr-26. [3] Sourcefire 3D System Version 4.8.2.1 Security Architecture, Version 1.1, 2010- Apr-26. 26 of 49 6.4 Life-Cycle (ALC) Evidence Documentation [1] Sourcefire 3D System Configuration Management Plan, Version 0.5, 2010-Apr- 21. [2] Sourcefire Intrusion Detection System Delivery Procedures, Version 1.1, 2010- Apr-27. [3] Sourcefire 3D System Version 4.8.2.1 Flaw Reporting Procedures, Version 1.0, 2010-Apr-26. 6.5 Testing (ATE) and Vulnerability Analysis (AVA) Documentation [1] Sourcefire Evaluator Test Plan and Report, Version 0.4, 2010-Jun-09. [2] Sourcefire 3D System Version 4.8.2.1 - Test Coverage Document, Version 1.0, 2010-Apr-29. [3] Sourcefire, Inc. - EAL2 Test Case Document v1.3 (3D 4.8.2.1 & SEU 259), 2010- Apr-26. 6.6 Evaluation Technical Report (ETR) [1] Evaluation Technical Report For a Target of Evaluation, Volume 1: Evaluation of the ST, Sourcefire, Incorporated, Sourcefire 3D System Version 4.8.2.1, Version 1.4, 2010-Jun-16. [2] Evaluation Technical Report For a Target of Evaluation, Volume 2: Evaluation of the TOE, Sourcefire, Incorporated, Sourcefire 3D System Version 4.8.2.1, Version 1.3, 2010-Jun-16. 27 of 49 7 IT Product Testing At EAL 2, the overall purpose of the testing activity is ―independently testing a subset of the TSF, whether the TOE behaves as specified in the design documentation, and to gain confidence in the developer's test results by performing a sample of the developer's tests‖ (ATE_IND.2, 14.6.2.1 [CEM]) At EAL 2, the developer‘s test evidence must ―show the correspondence between the tests provided as evaluation evidence and the functional specification. However, the coverage analysis need not demonstrate that all TSFI have been tested, or that all externally-visible interfaces to the TOE have been tested. Such shortcomings are considered by the evaluator during the independent testing.‖ (ATE_COV.1, 14.3.1.3 [CEM]) This section describes the testing efforts of the vendor and the evaluation team. The objective of the evaluator‘s independent testing sub-activity is ―to demonstrate that the security functions perform as specified. Evaluator testing includes selecting and repeating a sample of the developer tests‖ (ATE_IND.2, Independent testing – sample [CC]). 7.1 Developer Testing The developer testing effort that is described in detail in the Developer Test Plan involved executing the test sets in the test configurations described in Section 8: Evaluated Configuration. 7.1.1 OVERALL TEST APPROACH AND RESULTS: Sourcefire testing consisted of the following types of tests: Manual Tests: All the developer tests except the IDS/IPS tests were performed manually. All expected results are mentioned as part of the Developer‘s test procedure description and all actual results are observations to ensure that expected results match actual results. IDS Functionality Tests (Semi-Automated): Testing the IDS/IPS functionality of the product consisted of generating known attack traffic, in the form of PCAP files, using the tcpreplay tool. PCAP (packet capture) consists of an application programming interface (API) for capturing network traffic. Unix-like systems implement PCAP in the libpcap library.The traffic is collected by the TOE and based on the policy that is applied on the TOE, alerts are generated. The expected results for each test include the alert that must be generated based on the PCAP file. The actual results included verification of the generated alert. 7.1.2 DEPTH AND COVERAGE All developer test cases test TOE security functions by stimulating an external interface. 28 of 49 Although the developer tests are performed using the WebUI, the evaluator determined that the test cases as described in the test documentation adequately exercise the internal interfaces. TOE testing directly tests external TSF interfaces. The behavior of the TSF is realized at its interfaces. Hostile intent will be expressed at the Network Asset Interface. The evaluator ensured that the test sample included the tests such that: All Security Functions are tested All External interfaces are exercised All Security Functional Requirements are tested. More emphasis is laid on the Network Interface being tested. All relevant security relevant features mentioned in the Administration/User Guides are covered in testing. Since the product is primarily an Intrusion Detection functionality product, it is difficult to gauge the extent of coverage for the network interfaces. Evaluators worked with Sourcefire to determine the adequate extent of coverage required at EAL 2. 7.1.3 RESULTS The evaluator checked the test procedures and the Test Evidence and found that the expected test results are consistent with the actual test results provided. For each test case examined, the evaluator checked the expected results in the test procedures with the actual results provided in the Test Evidence and found that the actual results were consistent with the expected results. The evaluator checked all of the test procedures. Given the Evaluation Assurance level (EAL 2), the evaluator determined that Sourcefire‘s TOE testing is adequate. All the external TSF interfaces are tested. TOE testing exercises all security functions identified in the Functional Specification. 7.2 Evaluator Independent Testing The evaluator performed the following activities during independent testing: Execution the Developer‘s Functional Tests (ATE_IND.2) Team-Defined Functional Testing (ATE_IND.2) Vulnerability/Penetration Testing (AVA_VAN.2) 7.2.1 EXECUTION THE DEVELOPER’S FUNCTIONAL TESTS The evaluator selected portions of Sourcefire‘s tests as the set of developer tests to execute. The evaluator re-ran the set of developer manual test procedures which are listed in the Evaluator‘s Test Report. The evaluator selected this approach in order to: Ensure the coverage of the principle security features of the TOE 29 of 49 Gain confidence in the developer‘s test results Ensure TOE is in a properly configured state The evaluator ensured that the test sample included the tests such that: All Security Functions were tested All External interfaces were exercised All Security Functional Requirements were tested. Since the product is an Intrusion Detection System testing emphasis was on the IDS functionality along with the Security Management (SM) and Identification and Authentication (I&A) functionality. The sample of the developer tests selected to be re- run exercised the security functions at an appropriate level of rigor commensurate with EAL 2. The evaluator augmented the IDS_* SFR tests to test the signature based detection and protocol behavior detection functionality. Testing emphasis was also laid on the Network Interface (where the IDS functionality is implemented) being tested. The evaluator ensured that the test sample contained a good representative sample of the protocols and policy violations referenced in the Functional Specification and User Guidance Documents. The test configurations used by the evaluator were the same as that used by the developer. The test results and screenshots for the test cases were recorded during the Evaluator testing. Overall success of the testing was measured by 100% of the retests being consistent with expected results. Anomalies were documented along with suggested / required solutions. All of the Developer‘s Functional Tests rerun by the Evaluator received a ‗Pass‘ verdict. 7.2.2 TEAM-DEFINED FUNCTIONAL TESTING The Evaluator selected individual test procedures from the set of Developer Functional Tests, and modified the input parameters to ensure fuller coverage of security functions and correctness of developer reported results (ensuring that the results were not canned). Additional tests were developed for the purpose of verifying that the product operates in accordance with Vendor claims, i.e. that a bug is fixed or a capability operates as described in the product documentation. The test results and screenshots for the test cases were recorded during the Evaluator testing. Overall success of the testing was measured by 100% of the tests being consistent with expected results. Anomalies were documented along with suggested / required solutions. The Evaluator developed the following additional tests: 1. Test that the TOE maintains the following attribute for each user: Password Strength Check 30 of 49 2. Test that the following information is recorded in each audit record ―data and time of event‖ with the event in this case being a login failure 3. Audit Log Suppression by UserName 4. Test that the TOE can perform the following analysis functions on all IDS data received: SSL Inspection – Test to be performed on a 3D Sensor 3800 (SBLinux V4.8) 5. Test the TOE‘s capability to configure a port with capture role and verify that this port can be used to capture packets 6. Test the automatic conversion from internal to external authentication when external authentication is enabled All of the Team-Defined Tests received a ‗Pass‘ verdict. 7.2.3 VULNERABILITY/PENETRATION TESTING The Vulnerability / Penetration tests covered hypothesized vulnerabilities and potential misuse of guidance. Given that the product is an IDS/IPS product offering Intrusion Detection functionality, the Evaluator found that the functional testing performed by the developer encompassed a great area of vulnerability and penetration testing. Several PCAP files with various malicious/malformed traffic, worms, viruses, etc. were tested to show that the product triggers appropriate rules, is resistant to them, and, when configured, mitigates them. Instead of devising individual penetration tests, the evaluator felt that testing different interfaces of the product against network penetration attacks offered by the latest set of Nessus plug-ins and re-running the fuzz tests that Sourcefire uses for their SEU testing were apt were apt. Hence all penetration testing for this product was conducted using Nessus to test the resistance of the product to publicly available attacks which include Denial of Service attacks. The evaluator ran the following test on a Defense Center (DC3000) and on 3D Sensor with IPS (running SFLinux) appliance (3D2500), 3D Sensor with IPS (running SBLinux) appliance (3D5800) and 3D Sensor with IPS (running SVLinux) appliance (3D9800) Set up the Nessus Laptop such that a ping from the laptop can reach the Management Ports of the appliance. Make sure that there are no routers between the TOE and the Nessus Laptop. Run a Nessus Scan with all plugins turned on against one of the Management Ports. The test results and screenshots for the test cases were recorded during the evaluator testing. Overall success of this testing was measured by 100% of the tests being consistent with expected results. All identified vulnerabilities were ruled out in the evaluated configurations. 31 of 49 8 Evaluated Configuration The TOE was tested the following test bed components: DC3000 (SFLinux) 3D2500 sensor (SFLinux) 3D5800 sensor (SBLinux) 3D9800 sensor (SVLinux) The Operational Environment includes the following test bed components: Host 1 Host 2 LDAP Server RADIUS Server Syslog Server SNMP Server Email Server NTP Server DNS Server WebUI station Note: The following TOE components were used in testing: DC3000 (SFLinux) 3D2500 sensor (SFLinux) 3D5800 sensor (SBLinux) 3D9800 sensor (SVLinux) Because of their identical functionality and behavior only one 3D Sensor appliance from each category of 3D Sensors was used in testing. Note: The sensors were located in the same physical location as the Defense Center in the testing scenarios. This is equivalent to deployment scenarios where the sensors are in multiple physical locations because the same SSL-encrypted communications channel is used between the sensors and Defense Center, except that it is transmitted over a VPN in the multi-site scenario. The following figures illustrate the main components required for running all test cases. They describe all the different test configurations described in the ST. 32 of 49 The first figure shows the three sensor types (SFLinux, SBLinux and SVLinux) deployed in inline mode managed by a Defense Center. This is configuration 1. DC3000 3D2500 3D9800 Host Host Host Host 3D5800 Host Host DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Web Browser Protected Management Network Figure 3 : A DC3000 Defense Center managing three sensors deployed in inline mode (Configuration 1) The next figure shows a Sourcefire Intrusion Sensor deployed in inline mode managed by a Defense Center. This is configuration 2a. DC3000 3D2500 Host Host DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Protected Management Network Web Browser Figure 4: A DC3000 Defense Center managing a 3D2500 Intrusion Sensor deployed in inline mode (Configuration 2a) 33 of 49 The next figure shows a Sourcefire Intrusion Sensor deployed in passive mode managed by a Defense Center. This is configuration 2b. 3D2500 DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Host Host DC3000 Web Browser Sensing Network Protected Management Network Figure 5: A DC3000 Defense Center managing a 3D2500 Intrusion Sensor deployed in passive mode The next figure shows a standalone Sourcefire Intrusion Sensor deployed in inline mode. This is configuration 3a. 3D2500 Host Host DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Web Browser Protected Management Network Figure 6: A standalone 3D2500 Intrusion Sensor deployed in inline mode (Configuration 3a) 34 of 49 The next figure shows a standalone Sourcefire Intrusion Sensor deployed in passive mode. This is configuration 3b. 3D2500 DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Host Host Sensing Network Protected Management Network Web Browser Figure 7: A standalone 3D2500 Intrusion Sensor deployed in passive mode (Configuration 3b) The next figure shows a SVLinux Intrusion Sensor deployed in inline mode managed by a Defense Center. This is configuration 4. DC3000 3D9800 Host Host DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Web Browser Protected Management Network Figure 8: A DC3000 Defense Center managing a SVLinux Intrusion Sensor deployed in inline mode (Configuration 4) 35 of 49 The next figure shows a SBLinux Intrusion Sensor deployed in inline mode managed by a Defense Center. This is configuration 5. DC3000 3D5800 Host Host DNS Server SNMP & Syslog Server NFS Server Email Server LDAP Server NTP Server Protected Management Network Web Browser Figure 9: A DC3000 Defense Center managing a SBLinux Intrusion Sensor deployed in inline mode (Configuration 5) 36 of 49 9 Results of Evaluation A verdict for an assurance component is determined by the resulting verdicts assigned to the corresponding evaluator action elements. The evaluation was conducted based upon version 3.1 R2 of the CC and the CEM. The Evaluation Team assigned a Pass, Fail, or Inconclusive verdict to each work unit of each EAL 2 assurance component. For Fail or Inconclusive work unit verdicts, the Evaluation Team advised the developer of issues requiring resolution or clarification within the evaluation evidence. In this way, the Evaluation Team assigned an overall Pass verdict to the assurance component only when all of the work units for that component had been assigned a Pass verdict. The details of the evaluation are recorded in the Evaluation Technical Report (ETR), which is controlled by CygnaCom CCTL. Below lists the assurance requirements the TOE was required meet to be evaluated and pass at Evaluation Assurance Level 2 augmented with ALC_FLR.2. The following components are taken from CC part 3. The components in the following section have no dependencies unless otherwise noted. ADV_ARC.1 Security architecture description ADV_FSP.2 Security-enforcing functional specification ADV_TDS.1 Basic design AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures 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 ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST Introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample 37 of 49 AVA_VAN.2 Vulnerability analysis The evaluators concluded that the overall evaluation result for the target of evaluation is Pass. The evaluation team reached PASS verdicts for all applicable evaluator action elements and consequently all applicable assurance components. The TOE is CC Part 2 Extended The TOE is CC Part 3 Conformant. The validators reviewed the findings of the evaluation team, and have concurred that the evidence and documentation of the work performed support the assigned rating. 38 of 49 10 Validators Comments and Recommendations 1. The appliances include a Linux-derived OS, which is not configured in a STIG- compliant manner. DISA performs the evaluation of the OS against the STIG. The only information Sourcefire receives from DISA are their recommendations which Sourcefire incorporates in their subsequent releases. Since the TOE doesn‘t claim STIG conformance, Sourcefire does not have the information on how the underlying OS of the TOE differs from the current STIG confirmation. The web server in the TOE is not evaluated against the STIG either by DISA or Sourcefire. 2. The product generates reports in PDF. Customers are cautioned to use the latest version of Acrobat and to keep it patched due to all the reported vulnerabilities (see http://www.schneier.com/blog/archives/2010/03/pdf_the_most_co.html, which notes that PDF is now the most common Malware vector). 3. When the available audit storage is exhausted, the TOE overwrites the oldest stored audit records and sends an alarm that the audit trail storage is full. The audit trail is backed up by mirroring it to a syslog server. There should be periodic backups of that syslog record in accordance with the customer‘s applicable IA control (e.g., ECTB in DOD 8500.2 or AU-9 in NIST 800-53r3). 4. There is a lack of tamper-evident packaging for the TOE. If tamper-evident packaging is a concern of the customer, this should be conveyed to the vendor at the time the order is placed. 5. The evaluation did not assess whether the Sourcefire supplied rule sets that are bundled with the TOE for suitability to task—only that the tests included in the rule sets work correctly 6. The cryptographic functions used by the TOE are not FIPS certified. Correctness of the encryption mechanisms used by the TOE is by Vendor Assertion. 39 of 49 11 Security Target The security target is Sourcefire 3D System Security Target (Sourcefire Defense Center: models DC500, DC1000, and DC3000; and Sourcefire 3D Sensor licensed for IPS: models 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D3800, 3D4500, 3D5800, 3D6500, and 3D9800) Version 4.8.2.1 (SEU 259), Version 1.15, June 10, 2010. The ST is compliant with the Specification of Security Targets requirements found within Annex B of Part 1of the CC. 40 of 49 12 Glossary 12.1 Acronyms The following are product specific and CC specific acronyms. Not all of these acronyms are used in this document. 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 PCAP Packet Capture PP Protection Profile RPC Remote Procedure Call SEU Security Enhancement Updates SF Security Function SFIDS Sourcefire Intrusion Detection System SFP Security Function Policy SFR Security Functional Requirements SNMP Simple Network Management Protocol ST Security Target TCP/IP Transmission Control Protocol/Internet Protocol TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Functions TSFI TOE Security Functions Interface 41 of 49 TSP TOE Security Policy UDP User Datagram Protocol UI User Interface URI Uniform Resource Identifier 12.2 Terminology This section defines the product-specific and CC-specific terms. Not all of these terms are used in this document. Access List A list of computers can access the appliance on specific ports. Analyzer Data Data collected by the analyzer functions. Analyzer Functions The active part of the analyzer responsible for performing intrusion analysis of information that may be representative of vulnerabilities in and misuse of IT resources, as well as reporting of conclusions. The 3D Sensor with IPS performs the analyzer functions of the TOE. Assets Information or resources to be protected by the countermeasures of a TOE. Assignment The specification of an identified parameter in a component. Assurance Grounds for confidence that an entity meets its security objectives 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. Attack Potential The perceived potential for success of an attack, should an attack be launched, expressed in terms of a threat agent‘s expertise, resources and motivation. 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 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. Audit Trail See Audit Log 42 of 49 Augmentation The addition of one or more assurance component(s) to a package Authentication To establish the validity of a claimed user or object. Authentication Data Information used to verify the claimed identity of a user Authentication Object An object that contains the settings for connecting to and retrieving user data from an external authentication server. Authorised User A user who may, in accordance with the SFR, perform an operation. Authorized 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. Class A grouping of families that share a common focus. Component The smallest selectable set of elements on which requirements may be based. Compromise An intrusion into an IT System where unauthorized disclosure, modification or destruction of sensitive information may have occurred. Confidentiality Assuring information will be kept secret, with access limited to appropriate persons. Connectivity The property of the TOE that allows interaction with IT entities external to the TOE. This includes exchange of data by wire or by wireless means, over any distance in any environment or configuration. Defense Center The Sourcefire 3D System Defense Center appliance and the software installed upon it. A central management point that allows the management of the 3D Sensors and automatically aggregates the events they generate. Dependency A relationship between components such that if a requirement based on the depending component is included in a PP, ST or package, a requirement based on the component that is depended upon must normally also be included in the PP, ST or package. Detection Engine The mechanism that is responsible for analyzing the traffic on the network segment where a sensor is connected. Element An indivisible security requirement. Evaluation Assessment of a PP, an ST, or a TOE against defined criteria. Evaluation Assurance Level (EAL) A package consisting of assurance components from Part 3 that represents a point on the CC predefined assurance scale. 43 of 49 Evaluation Authority A body that implements the CC for a specific community by means of an evaluation scheme and thereby sets the standards and monitors the quality of evaluations conducted community. Evaluation Scheme The administrative and regulatory framework under which the CC is applied by an evaluation authority within a specific community. Extension The addition to an ST or PP of functional requirements not contained in Part 2 and/or assurance requirements not contained in Part 3 of the CC. External Entity Any entity (human or IT) outside the TOE that interacts (or may interact) with the TOE. Family A grouping of components that share security objectives but may differ in emphasis or rigor. Formal Expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts. Health Alert An alert generated by the Defense Center when a specific health event occurs. Health Event An event that is generated when one of the appliances in a deployment meets (or fails to meet) performance criteria specified in a health module. Health events indicate which module triggered the event and when the event was triggered. Health Module A test of a particular performance aspect of one of the appliances in a deployment. Health Policy The criteria used when checking the health of an appliance in a deployment. Health policies use health modules to indicate whether Sourcefire 3D System hardware and software are working correctly. Identity A representation (e.g. a string) uniquely identifying an authorized user, which can either be the full or abbreviated name of that user or a pseudonym. IDS Analyzer (analyzer) The component of an IDS that accepts data from sensors, scanners and other IT System resources, and then applies analytical processes and information to derive conclusions about intrusions (past, present, or future). The 3D Sensor with IPS is the analyzer component of the TOE. IDS Component A sensor, scanner, or analyzer. The 3D Sensor with IPS is the IDS component of the TOE. IDS 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 44 of 49 intrusion of an IT System. The 3D Sensor with IPS is the scanner component of the TOE. IDS Sensor (sensor) The component of an IDS that collects real-time events that may be indicative of vulnerabilities in or misuse of IT resources. The 3D Sensor with IPS is the sensor component of the TOE. Incident One or more intrusion events that are suspected of being involved in a possible violation of a security policy. Informal Expressed in natural language. Integrity Assuring information will not be accidentally or maliciously altered or destroyed. Interface Set One or more sensing interfaces on a 3D Sensor that can be used to monitor network segments for one or more detection engines. Internal Communication Channel A communication channel between separated parts of TOE. Internal TOE Transfer Communicating data between separated parts of the TOE. Inter-TSF Transfers Communicating data between the TOE and the security functions of other trusted IT products. 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 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. 45 of 49 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. IT System May range from a computer system to a computer network. Iteration The use of the same component to express two or more distinct requirements. Network Two or more machines interconnected for communications. Object A passive entity in the TOE, that contains or receives information, and upon which subjects perform operations. Organizational Security Policies A set of security rules, procedures, or guidelines imposed (or presumed to be imposed) now and/or in the future by an actual or hypothetical organization in the operational environment. Package A named set of either functional or assurance requirements (e.g. EAL 3). 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. Prove This term refers to a formal analysis in its mathematical sense. It is completely rigorous in all ways. Typically, ―prove‖ is used when there is a desire to show correspondence between two TSF representations at a high level of rigor. Refinement The addition of details to a component. 46 of 49 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. Role A predefined set of rules establishing the allowed interactions between a user and the TOE. 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). Secret Information that must be known only to authorized users and/or the TSF in order to enforce a specific SFP. Secure State A state in which the TSF data are consistent and the TSF continues correct enforcement of the SFRs. 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 Attribute A property of subjects, users (including external IT products), objects, information, sessions and/or resources that is used in defining the SFRs and whose values are used in enforcing the SFRs. Security Function Policy (SFP) A set of rules describing specific security behavior enforced by the TSF and expressible as a set of SFRs. Security Objective A statement of intent to counter identified threats and/or satisfy identified organization security policies and/or assumptions. 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. Selection The specification of one or more items from a list in a component. Semiformal Expressed in a restricted syntax language with defined semantics. Sensor (3D Sensor with IPS) An appliance-based sensor that, as part of the Sourcefire 3D System, can run the IPS component. The 3D Sensor with IPS includes the appliance hardware and the Sourcefire application software, Linux derived operating system, and supporting 3rd party software installed on the appliance. 47 of 49 Sensor Data Data collected by the Sensor functions. Sensor Functions The active part of the Sensor responsible for collecting information that may be representative of vulnerabilities in and misuse of IT resources (i.e., Sensor data). Signatures Patterns of network traffic that can be used to detect attacks or exploits. Subject An active entity in the TOE that performs operations on objects. 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) A set of software, firmware and/or hardware possibly accompanied by guidance. 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 Administrator See Authorized Administrator TOE Resource Anything useable or consumable in the TOE. 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. Transfers outside TSF TSF mediated communication of data to entities not under control of the TSF. Trojan Horse An apparently useful and innocent program containing additional hidden code that allows the unauthorized collection, exploitation, falsification, or destruction of data. Trusted Channel A means by which a TSF and a remote trusted IT product can communicate with necessary confidence. Trusted Path A means by which a user and a TSF can communicate with necessary confidence. TSF Data Data created by and for the TOE, which might affect the operation of the TOE. TSF Interface (TSFI) A means by which external entities (or subjects in the TOE but outside of the TSF) supply data to the TSF, receive data from the TSF and invoke services from the TSF. 48 of 49 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 See External Entity User Data Data created by and for the user that does not affect the operation of the TSF. 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. 49 of 49 13 Bibliography URLs [1] Common Criteria Evaluation and Validation Scheme (CCEVS): (http://www.niap-ccevs.org/cc-scheme). [2] CygnaCom Solutions CCTL (http://www.cygnacom.com). CCEVS Documents [1] Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model, September 2006 Version 3.1 Revision 1, CCMB- 2006-09-001. [2] Common Criteria for Information Technology Security Evaluation - Part 2: Security functional components, September 2007 Version 3.1 Revision 2, CCMB- 2007-09-002. [3] Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components, September 2007, Version 3.1 Revision 2, CCMB-2007-09-003. [4] Common Methodology for Information Technology Security Evaluation - Evaluation methodology, September 2007, Version 3.1 Revision 2, CCMB-2007- 09-004.