This Security Target (ST) defines the Information Technology (IT) security requirements for the FireEye MAS 6.0. FireEye detects malware in web and e-mail traffic by analyzing suspicious network flows in virtual victim machines. The FireEye appliance identifies malicious attacks, including those targeting web browsers. It secures against both widespread and targeted network malware without relying on manual IT analysis. Signature matching is used in the IDS process, but the IDS process does not rely on the signature matching components or updated signatures to function properly. After identifying a targeted malware attack, the FireEye appliance that is integrated into a network blocks the attack, quarantines the infected host and alerts Administrators to the incident.
","evaluation_configuration":"The TOE was evaluated on the following platforms:
\r\nFireEye running on a 1000 Series appliance
\r\nFireEye running on a 2000 Series appliance
\r\nFireEye running on a 4000 Series appliance
\r\nFireEye running on a 5000 Series appliance
\r\nFireEye running on a 7000 Series appliance
\r\nFireEye running on a 8000 Series appliance
\r\nAttack Machine
\r\nThe evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. FireEye was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 3. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 3. It has been determined that the product meets the security criteria in the Security Target, which specifies an assurance level of EAL2 augmented with ALC_FLR.2. Validators, on behalf of the CCEVS Validation Body, monitored the evaluation. The evaluation was completed in September 2011.
","environmental_strengths":"Intrusion Detection System
\r\nThe TOE monitors the network’s web and e-mail traffic for detected malicious code, service requests, and service configuration, among other information. Anything that the TOE determines is malicious becomes an event. General information is recorded for each event, and each type of event has more specific classifications that are recorded. See Section 9.1.6 for more information on the data that is collected by the TOE.
\r\nThe TOE analyzes recorded data on a statistical, signature, virtual machine, and/or heuristic basis. Each analytical result is recorded with basic information, as well as changes in the OS or network, and whether or not a buffer overflow was attempted. Administrators and Monitors are able to view the data via the WebUI or CLI. Once a threat has been detected, the system sends an alarm to the Administrator or Monitor. Depending on the deployment (inline or SPAN/tap), the TOE is also capable of dropping the traffic that was shown to represent a threat.
\r\nData in the system is protected from unauthorized deletion or modification. System data is archived to a local file once the predefined number of events has been recorded to the internal database. An alarm is used to alert Administrators and Monitors of this issue.
\r\nAny malicious e-mail found during analysis is placed into e-Quarantine. Administrators can choose to release items from e-Quarantine which will then forward the message to the original recipient.
\r\nSecurity Management
\r\nThe TOE maintains two roles – Administrator and Monitor. Users under the Administrator role have the ability to perform all administrative functions (e.g. user management, audit management) and monitoring functions.
\r\nUsers under the Monitor role are able to perform all changes pertaining to monitoring functionality, but are not allowed to perform any other administrative functionality (i.e. user management, audit configuration). Users can perform limited configuration functions via the LCD panel. All functions performed from the LCD panel can also be performed from the WebUI or CLI once the user has authenticated to the WebUI or CLI. The LCD panel is meant for initial setup only, and therefore is not included in the evaluated configuration. Additionally, most functions performed from the CLI can also be performed from the Web UI.
\r\nIdentification and Authentication
\r\nAll users must be identified and authenticated to the TOE via username and password before being allowed to perform any actions on the TOE. The exception to this is that users are allowed to perform TOE functions via the password protected LCD panel without identifying themselves to the TOE. Since a username is not required to authenticate to the LCD panel, it is assumed that individuals with physical access to the TOE will also be users of the TOE. The LCD panel is meant for initial setup only, and as such is not part of the TSF for the evaluated configuration. The TOE maintains specific security attributes about users in order to correctly identify them with their TOE-associated abilities as well as for future authentication attempts. If a user enters incorrect credentials multiple times, he or she is forbidden from re-attempting to authenticate until a set amount of time has elapsed. The number of incorrect attempts allowed is pre-determined by the Administrator.
\r\nSecurity Audit
\r\nWhen auditable events occur, such as access to the TOE or access to system data, the TOE generates audit logs for all TOE and user actions that are time stamped and stored in the appropriate internal database(s). Only Administrators have the ability to view these records through the Command Line Interface (CLI) and sort these records based on predetermined criteria. The TOE allows events that are deemed auditable to be either excluded or included from the set of auditable events based on event type. All audit records are protected from unauthorized deletion and modification. When the audit storage location reaches its maximum capacity, the newest record comes in, the oldest record is deleted. Alarms are sent to the appropriate individuals. Old audit records are overwritten as a result of the audit storage meeting its capacity.
\r\nCryptographic Support
\r\nThe TOE is expected to utilize sufficient security measures to protect its data in transmission, which means it needs to utilize cryptographic methods and trusted channels. The TOE generates cryptographic keys to protect transmitted data. The TOE is also responsible for destroying these same keys when they are no longer needed.
\r\nAdministrators and Monitors who access the TOE remotely rely on a trusted path to secure their communication with the TOE via the WebUI. This trusted path is established using OpenSSL 0.9.8e. OpenSSL is also used for protected communication to/from the MAX Network. Additionally, users who access the TOE via the CLI must use OpenSSH 3.8.1p1 functionality to secure their communications with the TOE. OpenSSH functionality is also used for protection of data transferred between TOE components.
\r\nProtection of the TSF
\r\nThe TOE is expected to ensure the security and integrity of all data that is stored locally and accessed remotely. The TOE ensures that all local system data is available to any remote trusted IT products (i.e. other TOE components). Additionally, the transmitted and received data is protected against unauthorized viewing by third parties through the use of encryption. All data transferred is monitored for changes during transmission, and integrity verification measures are taken if modifications have been detected. Time stamps are added to all audit logs and system events in order to maintain accurate records.
","features":[]}