1 FireEye, Inc. Common Criteria Security Target Document Version: 1.0 Prepared By: Acumen Security 18504 Office Park Dr Montgomery Village, MD 20886 www.acumensecurity.net FireEye MX Series Appliances 2 Table Of Contents 1 Security Target Introduction ............................................................................................................5 1.1 Security Target and TOE Reference ..........................................................................................5 1.2 TOE Overview ..........................................................................................................................5 1.2.1 TOE Product Type.............................................................................................................5 1.3 TOE Description .......................................................................................................................5 1.3.1 MX Series Appliances: MX 900 Appliance and MX 8400 Appliance....................................5 1.4 TOE Evaluated Configuration....................................................................................................6 1.5 TOE Architecture......................................................................................................................7 1.5.1 Physical Boundaries..........................................................................................................7 1.5.2 Logical Boundaries............................................................................................................7 1.5.2.1 Security Audit...............................................................................................................7 1.5.2.2 Cryptographic Support..................................................................................................8 1.5.2.3 User Data Protection ....................................................................................................8 1.5.2.4 Identification and Authentication .................................................................................8 1.5.2.5 Security Management...................................................................................................9 1.5.2.6 Protection of the TSF ....................................................................................................9 1.5.2.7 Trusted Path/Channels ...............................................................................................10 1.5.2.8 TOE Access .................................................................................................................10 2 Conformance Claims......................................................................................................................11 2.1 CC Conformance ....................................................................................................................11 2.2 Protection Profile Conformance .............................................................................................11 2.3 Conformance Rationale..........................................................................................................11 3 Security Problem Definition ...........................................................................................................12 3.1 Assumptions ..........................................................................................................................12 3.1.1 A.NO_GENERAL_PURPOSE..............................................................................................12 3.1.2 A.PHYSICAL.....................................................................................................................12 3.1.3 A.TRUSTED_ADMIN........................................................................................................12 3.2 Threats...................................................................................................................................12 3.2.1 Communications with the TOE (T.UNAUTHORIZED_ACCESS)...........................................12 3.2.2 Malicious Updates (T.UNAUTHORIZED_UPDATE)............................................................13 3.2.3 Undetected System Activity (T.ADMIN_ERROR, T.UNDETECTED_ACTIONS, T.UNAUTHORIZED_ACCESS)...........................................................................................................13 3.2.4 Accessing the TOE (T.UNAUTHORIZED_ACCESS)..............................................................14 3 3.2.5 User Data Disclosure (T.USER_DATA_REUSE)..................................................................14 3.2.6 TSF Failure (T. TSF_FAILURE)...........................................................................................14 3.3 Security Objectives for the TOE ..............................................................................................14 3.3.1 Protected Communications (O.PROTECTED_COMMUNICATIONS)...................................14 3.3.2 Verifiable Updates (O.VERIFIABLE_UPDATES) .................................................................15 3.3.3 System Monitoring (O.SYSTEM_MONITORING)...............................................................15 3.3.4 TOE Administration (O.TOE_ADMINISTRATION)..............................................................16 3.3.5 Residual Information Clearing (O.RESIDUAL_INFORMATION_CLEARING) ........................16 3.3.6 TSF Self-Test (O.TSF_SELF_TEST).....................................................................................16 3.3.7 O.DISPLAY_BANNER .......................................................................................................16 3.3.8 O.SESSION_LOCK............................................................................................................16 3.4 Security Objectives for the Operational Environment.............................................................16 3.4.1 OE.NO_GENERAL_PURPOSE ...........................................................................................16 3.4.2 OE.PHYSICAL ..................................................................................................................17 3.4.3 OE.TRUSTED_ADMIN......................................................................................................17 4 Security Requirements...................................................................................................................18 4.1 Conventions...........................................................................................................................18 4.2 TOE Security Functional Requirements...................................................................................18 4.2.1 Class: Security Audit (FAU)..............................................................................................19 4.2.2 Class: Cryptographic Support (FCS) .................................................................................20 4.2.3 Class: User Data Protection (FDP) ...................................................................................22 4.2.4 Class: Identification and Authentication (FIA) .................................................................22 4.2.5 Class: Security Management (FMT).................................................................................22 4.2.6 Class: Protection of the TSF (FPT)....................................................................................23 4.2.7 Class: TOE Access (FTA)...................................................................................................23 4.2.8 Class: Trusted Path/Channels (FTP).................................................................................24 4.3 TOE SFR Dependencies Rationale for SFRs..............................................................................24 4.4 Security Assurance Requirements ..........................................................................................24 4.5 Rationale for Security Assurance Requirements .....................................................................25 4.6 Assurance Measures ..............................................................................................................25 5 TOE Summary Specification ...........................................................................................................26 5.1 Key Zeroization ......................................................................................................................31 Annex A: References..............................................................................................................................32 4 Revision History Version Date Description 1.0 1/194/2016 Revisioned in preparation for posting 5 1 Security Target Introduction 1.1 Security Target and TOE Reference This section provides information needed to identify and control this ST and its TOE. Category Identifier ST Title FireEye MX Series Appliances Security Target ST Version 1.0 ST Date January 19, 2016 ST Author Acumen Security, LLC. TOE Identifier FireEye MX Series Appliances TOE Hardware Versions MX 900, MX 8400 TOE Software Version 2.0.3 TOE Developer FireEye, Inc. Key Words Network Device, Security Appliance, Table 1 TOE/ST Identification 1.2 TOE Overview The TOE consists of the FireEye MX series appliances. These products provide real-time visibility of threats on mobile devices, displays play-by-play analysis of suspicious apps, provides an index of pre- analyzed apps, and generates threat assessments for custom apps. 1.2.1 TOE Product Type FireEye MX series appliances are network devices that implement mobile device protection and are comprised of 1RU or 2RU appliances. The FireEye MX series appliances run a custom-built hardened version of Linux with only the required services enabled. 1.3 TOE Description This section provides a description of the FireEye MX series appliances Target of Evaluation (TOE). The following section provides an overview of the functionality provided by the TOE and its physical characteristics. 1.3.1 MX Series Appliances: MX 900 Appliance and MX 8400 Appliance The FireEye MX series appliances are mobile management platforms that may work in conjunction with other FireEye products to assimilate, and disperse threat information to mobile endpoints, and offer integration with MDM solutions for a true detect to fix solution. The following table identifies the physical characteristics of each of the appliances. MX 900 MX 8400 Network Ports 1x 10/100/1000BASE-T Ports 2 x 10/100/1000 base-T Ports Storage 1 x 500 GB HDD, internal fixed 2 x 600 GB HDD, RAID 1, 2.5 inch FRU Enclosure 1RU, Fits 19 inch Rack 2 RU, Fits 19 inch Rack Power Supply Non-redundant, non-FRU, internal 200 W @ 100-240 VAC 3-1.5 A, 50/60HZ, IEC60320-C14 inlet Redundant (1+1), FRU, 750 W @100-240 VAC 4.5-9 A 50.60 Hz IEC60320-C14 inlet Operating Temp 10 C to 35 C 10 C to 35 C Processor AMD Opteron 6328 AMD Opteron 6380 Operating System CentOS 6.5 (kernel version 3.10.53) CentOS 6.5 (kernel version 3.10.53) Application Software image-msm.img image-msm.img 6 MX 900 MX 8400 Crypto Algorithm Implementation FireEye Algorithms Implementation, version 1.0 (used for general cryptography) FireEye Image Signature Verification, version 1.0 (used for secure software update) FireEye Algorithms Implementation, version 1.0 (used for general cryptography) FireEye Image Signature Verification, version 1.0 (used for secure software update) Table 2 MX Series Appliances 1.4 TOE Evaluated Configuration The TOE evaluated configuration consists of the MX 900 or MX 8400 appliance listed above. The TOE also supports (sometimes optionally) secure connectivity with several other IT environment devices, including, Component Required Usage/Purpose Description for TOE performance Management Workstation with SSH Client Yes This includes any IT Environment Management workstation with a SSH client installed that is used by the TOE administrator to support TOE administration through SSH protected channels. Any SSH client that supports SSHv2 may be used. Time Server No The TOE supports communications with an NTP server to synchronize date and time. Audit server No The syslog audit server is used for remote storage of audit records that have been generated by and transmitted from the TOE. Table 3 IT Environment Components The following figure provides a visual depiction of an example of the TOE. The TOE boundary is surrounded with hashed red lines. Each TOE interconnection is through an SSH secured channel. 7 1.5 TOE Architecture 1.5.1 Physical Boundaries The TOE is a hardware and software solution that is comprised of the security appliance models described above in Section 1.3. The TOE guidance documentation that is considered to be part of the TOE can be found listed in the FireEye FIPS Mode and Common Criteria Addendum document and is downloadable from the http://fireeye.com web site. The network on which the TOE resides is considered part of the environment. The software is pre- installed and is comprised of only the software versions identified in Section 1.1. In addition, the software images are also downloadable from the FireEye website. A login ID and password is required to download the software image. 1.5.2 Logical Boundaries The TOE is comprised of several security features. Each of the security features identified above consists of several security functionalities, as identified below.  Security Audit  Cryptography Support  User Data Protection  Identification & Authentication  Security Management  Protection of the TSF  Trusted Path/Channel  TOE Access These features are described in more detail in the subsections below. In addition, the TOE implements all RFCs of the [NDPP] as necessary to satisfy testing/assurance measures prescribed therein. 1.5.2.1 Security Audit The FireEye MX Series Appliances provide extensive auditing capabilities. The TOE generates a comprehensive set of audit logs that identify specific TOE operations. For each event, the TOE records the date and time of each event, the type of event, the subject identity, and the outcome of the event. Auditable events include: failure on invoking cryptographic functionality such as establishment, termination and failure of a TLS session; establishment, termination and failure of an SSH session; modifications to the group of users that are part of the authorized administrator roles; all use of the user identification mechanism; any use of the authentication mechanism; any change in the configuration of the TOE, changes to time, initiation of TOE update, indication of completion of TSF self- test, maximum sessions being exceeded, termination of a remote session; and initiation and termination of a trusted channel. The TOE is configured to transmit its audit messages to an external syslog server. Communication with the syslog server is protected using TLS and the TOE can determine when communication with the syslog server fails. The logs for all of the appliances can be viewed on the TOE via the TOE CLI. The records include the date/time the event occurred, the event/type of event, the user ID associated with the event, and additional information of the event and its success and/or failure. The TOE does not have an interface to modify audit records, though there is an interface available for the authorized administrator to clear audit data stored locally on the TOE. 8 1.5.2.2 Cryptographic Support The TOE provides cryptographic support for the following features,  TLS connectivity with the following entities: o Audit Server  SSH connectivity with the following entities: o Management SSH Client  Secure software update The cryptographic services provided by the TOE are described below. Cryptographic Method Use within the TOE TLS Establishment Used to establish initial TLS session. SSH Establishment Used to establish initial SSH session. ECDSA Signature Services Used in TLS session establishment. RSA Signature Services Used in TLS session establishment. Used in SSH session establishment Used in secure software update SP 800-90 DRBG Used in TLS session establishment. Used in SSH session establishment SHS Used in secure software update HMAC-SHS Used to provide TLS traffic integrity verification Used to provide SSH traffic integrity verification AES Used to encrypt TLS traffic Used to encrypt SSH traffic Table 4 TOE Provided Cryptography This cryptography has been validated by the CAVP for conformance to the individual algorithm standards, as identified below. Algorithm CAVP Certificate # RSA Cert. #1759, 1758 ECDSA Cert. #696 SP 800-90 DRBG Cert. #843 SHS Cert. #2837, 2836 HMAC-SHS Cert. #2195 AES Cert. #3447 Table 5 CAVP Algorithm Testing References Each of the above referenced algorithms are implemented within the FireEye Algorithms Implementation, version 1.0 and FireEye Image Signature Verification, version 1.0 cryptographic libraries. Each service requiring cryptography directly calls the cryptographic libraries. 1.5.2.3 User Data Protection The TOE ensures that all information flows from the TOE do not contain residual information from previous traffic. Packets are padded with zeros. Residual data is never transmitted from the TOE. 1.5.2.4 Identification and Authentication The TOE performs two types of authentication: device-level authentication of remote IT Environment devices (e.g., audit servers) and user authentication for the Authorized Administrator of the TOE. Device-level authentication of remote IT Environment devices allows the TOE to establish a secure 9 channel with an IT Environment trusted peer. The secure channel is established only after each device authenticates the other. This device-level authentication is performed via TLS authentication. The TOE provides authentication services for administrative users to connect to the TOEs CLI administrator interface. The TOE requires Authorized Administrators to authenticate prior to being granted access to any of the management functionality. In the Common Criteria evaluated configuration, the TOE is configured to require a minimum password length of 15 characters, as well as, mandatory password complexity rules. The TOE provides administrator authentication against a local user database. Password-based authentication can be performed on any TOE administrative interface including local CLI and remote CLI over SSH. 1.5.2.5 Security Management The TOE provides secure administrative services for management of general TOE configuration and the security functionality provided by the TOE. Management can take place over a variety of interfaces including:  Local console command line administration at each of the appliances  Remote command line administration via SSHv2 at each of the appliances The TOE provides the ability to securely manage:  All TOE administrative users;  All identification and authentication;  All audit functionality of the TOE;  All TOE cryptographic functionality;  The timestamps maintained by the TOE; and  Update to the TOE. The TOE supports several administrator roles, including,  Admin: The system administrator is a “super user” who has all capabilities.  Monitor: The system monitor has read-only access  Operator: The system operator has a subset of the capabilities associated with the admin role.  Analyst: The system analyst focuses on data plane analysis.  Auditor: The system auditor reviews audit logs and performs forensic analysis. These roles are collectively known as the “Authorized Administrator” The TOE supports the configuration of login banners to be displayed at time of login and inactivity timeouts to terminate administrative sessions after a set period of inactivity. 1.5.2.6 Protection of the TSF The TOE protects against interference and tampering by untrusted subjects by implementing identification, authentication, and access controls to limit configuration to Authorized Administrators. The TOE prevents reading of cryptographic keys and passwords. Additionally the TOE software is a custom-built hardened version of Linux and access to memory space is restricted to only required software services. The TOE internally maintains the date and time. This date and time is used as the timestamp that is applied to audit records generated by the TOE. Administrators can update the TOE’s clock manually, or can configure the TOE to use NTP to synchronize the TOE’s clock with an external time source. Finally, the TOE performs testing to verify correct operation of the security appliances themselves. 10 The TOE verifies all software updates via digital signature and requires administrative intervention prior to the software updates being installed on the TOE to avoid the installation of unauthorized software. 1.5.2.7 Trusted Path/Channels The TOE supports several types of secure communications, including,  Trusted paths with remote administrators over SSH,  Trusted channels with remote IT Environment audit servers over TLS, Each of these trusted paths/channels are secured using either TLS or SSH. 1.5.2.8 TOE Access The TOE can terminate inactive sessions after an Authorized Administrator configurable time-period. Once a session has been terminated the TOE requires the user to re-authenticate to establish a new session. The TOE also displays an Authorized Administrator configured banner on the CLI management interfaces prior to allowing any administrative access to the TOE. 11 2 Conformance Claims 2.1 CC Conformance This TOE is conformant to:  Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 4, September 2012  Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 4, September 2012: Part 2 extended  Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 4, September 2012: Part 3 2.2 Protection Profile Conformance This TOE is conformant to:  Protection Profile for Network Devices, Version 1.1, 08 June 2012 [NDPP].  Security Requirements for Network Devices Errata #3, 3 November 2014 [ERRATA#3] 2.3 Conformance Rationale This Security Target provides exact conformance to Version 1.1 of the Network Device Protection Profile. The security problem definition, security objectives and security requirements in this Security Target are all taken from the Protection Profile performing only operations defined there. 12 3 Security Problem Definition The security problem definition has been taken from [NDPP] and is reproduced here for the convenience of the reader. 3.1 Assumptions 3.1.1 A.NO_GENERAL_PURPOSE It is assumed that there are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. 3.1.2 A.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environment. 3.1.3 A.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. 3.2 Threats 3.2.1 Communications with the TOE (T.UNAUTHORIZED_ACCESS) Network devices communicate with other network devices, as well as administrators, over the network. The endpoints of the communication can be both geographically and logically distant from the TOE, and pass through a variety of other systems. These intermediate systems may be under the control of the adversary, and offer an opportunity for communications with the TOE to be compromised. While these communications fall into three distinct categories (the TOE communicating with a remote administrator; the TOE communicating in a distributed processing environment with another instance or instances of itself; and the TOE communicating with another IT entity that is not another instance of the TOE (e.g., an NTP server or a peer router)), the threats to the communication between these endpoints are the same. Plaintext communication with the TOE may allow critical data (such as passwords, configuration settings, and routing updates) to be read and/or manipulated directly by intermediate systems, leading to a compromise of the TOE. Several protocols can be used to provide protection; however, each of these protocols have myriad options that can be implemented and still have the overall protocol implementation remain compliant to the protocol specification listed in the RFC. Some of these options can have negative impacts on the security of the connection. For instance, using a weak encryption algorithm (even one that is allowed by the RFC, such as DES) can allow an adversary to read and even manipulate the data on the encrypted channel, thus circumventing countermeasures in place to prevent such attacks. Further, if the protocol is implemented with little-used or non-standard options, it may be compliant with the protocol specification but will not be able to interact with other, diverse equipment that is typically found in large enterprises. Even though the communication path is protected, there is a possibility that the external entity (be it a remote administrator, another instance of the distributed TOE, or a trusted IT entity such as a peer router) could be duped into thinking that a malicious third-party user or system is the TOE. For instance, a middleman could intercept a connection request to the TOE, and respond to the external entity as if it were the TOE. In a similar manner, the TOE could also be duped into thinking that it is establishing communications with a legitimate remote entity when in fact it is not. An attacker could also mount a malicious man-in-the-middle-type of attack, in which an intermediate system is compromised, and the traffic is proxied, examined, and modified by this system. This attack can even be mounted via encrypted communication channels if appropriate countermeasures are not applied. These attacks are, 13 in part, enabled by a malicious attacker capturing network traffic (for instance, an authentication session) and "playing back" that traffic in order to fool an endpoint into thinking it was communicating with a legitimate remote entity. 3.2.2 Malicious Updates (T.UNAUTHORIZED_UPDATE) Since the most common attack vector used involves attacking unpatched versions of software containing well-known flaws, updating network device firmware is necessary to ensure that changes to threat environment are addressed. Timely application of patches ensures that the system is a "hard target", thus increasing the likelihood that product will be able to maintain and enforce its security policy. However, the updates to be applied to the product must be trustable in some manner; otherwise, an attacker can write their own "update" that instead contains malicious code of their choosing, such as a rootkit, bot, or other malware. Once this "update" is installed, the attacker then has control of the system and all of its data. Methods of countering this threat typically involve hashes of the updates, and potentially cryptographic operations (e.g., digital signatures) on those hashes as well. However, the validity of these methods introduces additional threats. For instance, a weak hash function could result in the attacker being able to modify the legitimate update in such a way that the hash remained unchanged. For cryptographic signature schemes, there are dependencies on 1. the strength of the cryptographic algorithm used to provide the signature, and 2. the ability of the end user to verify the signature (which typically involves checking a hierarchy of digital signatures back to a root of trust (a certificate authority)). If a cryptographic signature scheme is weak, then it may be compromised by an attacker and the end user will install a malicious update, thinking that it is legitimate. Similarly, if the root of trust can be compromised, then a strong digital signature algorithm will not stop the malicious update from being installed (the attacker will just create their own signature on the update using the compromised root of trust, and the malicious update will then be installed without detection). 3.2.3 Undetected System Activity (T.ADMIN_ERROR, T.UNDETECTED_ACTIONS, T.UNAUTHORIZED_ACCESS) While several threats are directed at specific capabilities of the TOE, there is also the threat that activity that could indicate an impending or on-going security compromise could go undetected. Administrators can unintentionally perform actions on the TOE that compromise the security being provided by the TOE; for instance, a mis-configuration of security parameters. Processing performed in response to user data (for example, the establishment of a secure communications session, cryptographic processing associated with a protected session) may give indications of a failure or compromise of a TOE security mechanism (e.g., establishment of a session with an IT entity when no such sessions should be taking place). When indications of activity that may impact the security of the TOE are not generated and monitored, it is possible for harmful activity to take place on the TOE without responsible officials being aware and able to correct the problem. Further, if no data are kept or records generated, reconstruction of the TOE and the ability to understand the extent of any compromise could be negatively affected. While this PP requires that the TOE generates the audit data, these data are not required to be stored on the TOE, but rather sent to a trusted external IT entity (e.g., a syslog server). These data may be read or altered by an intervening system, thus potentially masking indicators of suspicious activity. It may also be the case that the TOE could lose connectivity to the external IT entity, meaning that the audit information could not be sent to the repository. 14 3.2.4 Accessing the TOE (T.UNAUTHORIZED_ACCESS) In addition to the threats discussed in Section 2.1 dealing with the TOE communicating with various external parties that focus on the communications themselves, there are also threats that arise from attempts to access the TOE, or the means by which these access attempts are accomplished. For example, if the TOE does not discriminate between administrative users that are allowed to access the TOE interactively (through a locally connected console, or with a session-oriented protocol such as SSH) and an administrative user with no authority to use the TOE in this manner, the configuration of the TOE cannot be trusted. Assuming that there is this distinction, there is still the threat that one of the allowed accounts may be compromised and used by an attacker that does not otherwise have access to the TOE. One vector for such an attack is the use of poor passwords by authorized administrators of the TOE. Passwords that are too short, are easily-guessed dictionary words, or are not changed very often, are susceptible to a brute force attack. Additionally, if the password is plainly visible for a period of time (such as when a legitimate user is typing it in during logon) then it might be obtained by an observer and used to illegitimately access the system. Once a legitimate administrative user is logged on, there still are a number of threats that need to be considered. During the password change process, if the TOE does not verify that it is the administrative user associated with the account changing the password, then anyone can change the password on a legitimate account and take that account over. If an administrative user walks away from a logged-in session, then another person with no access to the device could sit down and illegitimately start accessing the TOE. 3.2.5 User Data Disclosure (T.USER_DATA_REUSE) While most of the threats contained in this PP deal with TSF and administrative data, there is also a threat against user data that all network devices should mitigate. Data traversing the TOE could inadvertently be sent to a different user; since these data may be sensitive, this may cause a compromise that is unacceptable. The specific threat that must be addressed concerns user data that is retained by the TOE in the course of processing network traffic that could be inadvertently re-used in sending network traffic to a user other than that intended by the sender of the original network traffic. 3.2.6 TSF Failure (T. TSF_FAILURE) Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g., memory management, privileged modes of process execution) to more complex sets of mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex mechanisms, resulting in a compromise of the TSF. 3.3 Security Objectives for the TOE The security objectives have been taken from [NDPP] and are reproduced here for the convenience of the reader. 3.3.1 Protected Communications (O.PROTECTED_COMMUNICATIONS) To address the issues concerning transmitting sensitive data to and from the TOE described in Section 2.1, "Communications with the TOE", compliant TOEs will provide encryption for these communication paths between themselves and the endpoint. These channels are implemented using one (or more) of three standard protocols: IPsec, TLS/HTTPS, and SSH. These protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack. While compliant TOEs must support all of the choices specified in the ST, they may 15 support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they are not evaluated. In addition to providing protection from disclosure (and detection of modification) for the communications, each of the protocols described in this document (IPsec, SSH, and TLS/HTTPS) offer two-way authentication of each endpoint in a cryptographically secure manner, meaning that even if there was a malicious attacker between the two endpoints, any attempt to represent themselves to either endpoint of the communications path as the other communicating party would be detected. The requirements on each protocol, in addition to the structure of the protocols themselves, provide protection against replay attacks such as those described in Section 2.1, usually by including a unique value in each communication so that replay of that communication can be detected. (FCS_CKM.1, FCS_CKM_EXT.4, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_RBG_EXT.1, FPT_SKP_EXT.1, FTP_ITC.1, FTP_TRP.1, (FCS_IPSEC_EXT.1, FCS_SSH_EXT.1, FCS_TLS_EXT.1, FCS_HTTPS_EXT.1), (FPT_ITT.1(1), FPT_ITT.1(2))) 3.3.2 Verifiable Updates (O.VERIFIABLE_UPDATES) As outlined in Section 2.2, "Malicious Updates", failure by the Security Administrator to verify that updates to the system can be trusted may lead to compromise of the entire system. A first step in establishing trust in the update is to publish a hash of the update that can be verified by the System Administrator prior to installing the update. In this way, the Security Administrator can download the update, compute the hash, and compare it to the published hash. While this establishes that the update downloaded is the one associated with the published hash, it does not indicate if the source of the update/hash combination has been compromised or can't be trusted. So, there remains a threat to the system. To establish trust in the source of the updates, the system can provide cryptographic mechanisms and procedures to procure the update, check the update cryptographically through the TOE-provided digital signature mechanism, and install the update on the system. While there is no requirement that this process be completely automated, administrative guidance documentation will detail any procedures that must be performed manually, as well as the manner in which the administrator ensures that the signature on the update is valid. (FPT_TUD_EXT.1, FCS_COP.1(2), FCS_COP.1(3)) 3.3.3 System Monitoring (O.SYSTEM_MONITORING) In order to assure that information exists that allows Security Administrators to discover intentional and unintentional issues with the configuration and/or operation of the system as discussed in Section 2.3, "Undetected System Activity", compliant TOEs have the capability of generating audit data targeted at detecting such activity. Auditing of administrative activities provides information that may hasten corrective action should the system be configured incorrectly. Audit of select system events can provide an indication of failure of critical portions of the TOE (e.g., a cryptographic provider process not running) or anomalous activity (e.g., establishment of an administrative session at a suspicious time, repeated failures to establish sessions or authenticate to the system) of a suspicious nature. In some instances there may be a large amount of audit information produced that could overwhelm the TOE or administrators in charge of reviewing the audit information. The TOE must be capable of sending audit information to an external trusted entity, which mitigates the possibility that the generated audit data will cause some kind of denial of service situation on the TOE. This information must carry reliable timestamps, which will help order the information when sent to the external device. Loss of communication with the audit server is problematic. While there are several potential mitigations to this threat, this PP does not mandate that a specific action takes place; the degree to 16 which this action preserves the audit information and still allows the TOE to meet its functionality responsibilities should drive decisions on the suitability of the TOE in a particular environment. (FAU_GEN.1, FAU_GEN.2, FAU_STG_EXT.1, FPT_STM.1) 3.3.4 TOE Administration (O.TOE_ADMINISTRATION) In order to provide a trusted means for administrators to interact with the TOE, the TOE provides a password-based logon mechanism. The administrator must have the capability to compose a strong password, and have mechanisms in place so that the password must be changed regularly. To avoid attacks where an attacker might observe a password being typed by an administrator, passwords must be obscured during logon. Session locking or termination must also be implemented to mitigate the risk of an account being used illegitimately. Passwords must be stored in an obscured form, and there must be no interface provided for specifically reading the password or password file such that the passwords are displayed in plain text. (FIA_UIA_EXT.1, FIA_PMG_EXT.1, FIA_UAU.7, FMT_MTD.1, FMT_SMF.1, FMT_SFR.1, FPT_APW_EXT.1, FTA_SSL_EXT.1, FTA_SSL.3) 3.3.5 Residual Information Clearing (O.RESIDUAL_INFORMATION_CLEARING) In order to counter the threat that user data is inadvertently included in network traffic not intended by the original sender, the TSF ensures that network packets sent from the TOE do not include data "left over" from the processing of previous network information. (FDP_RIP.2) 3.3.6 TSF Self-Test (O.TSF_SELF_TEST) In order to detect some number of failures of underlying security mechanisms used by the TSF, the TSF will perform self-tests. The extent of this self-testing is left to the product developer, but a more comprehensive set of self-tests should result in a more trustworthy platform on which to develop enterprise architecture. (FPT_TST_EXT.1) 3.3.7 O.DISPLAY_BANNER The TOE will display an advisory warning regarding use of the TOE. (FTA_TAB.1) 3.3.8 O.SESSION_LOCK (The TOE shall provide mechanisms that mitigate the risk of unattended sessions being hijacked.) (FTA_SSL_EXT.1, FTA_SSL.3, FTA_SSL.4) 3.4 Security Objectives for the Operational Environment The security objectives have been taken from [NDPP] and are reproduced here for the convenience of the reader. 3.4.1 OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. 17 3.4.2 OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. 3.4.3 OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner 18 4 Security Requirements This section identifies the Security Functional Requirements for the TOE and/or Platform. The Security Functional Requirements included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, dated: September 2012 and all international interpretations. 4.1 Conventions The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document uses the following font conventions to identify the operations defined by the CC:  Assignment: Indicated with italicized text;  Refinement: Indicated with bold text;  Selection: Indicated with underlined text;  Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3).  Where operations were completed in the PP itself, the formatting used in the PP has been retained. Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs. Formatting conventions outside of operations matches the formatting specified within the PP. 4.2 TOE Security Functional Requirements This section identifies the Security Functional Requirements for the TOE. The TOE Security Functional Requirements that appear below in Table 11 are described in more detail in the following subsections. Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None. FAU_GEN.2 None. FAU_STG_EXT.1 None. FCS_CKM.1 None. FCS_CKM_EXT.4 None. FCS_COP.1(1) None. FCS_COP.1(2) None. FCS_COP.1(3) None. FCS_COP.1(4) None. FCS_TLS_EXT.1 Failure to establish a TLS Session. Establishment/Termination of a TLS session. Reason for failure Non-TOE endpoint of connection (IP address) for both successes and failures. FCS_SSH_EXT.1 Failure to establish an SSH session Establishment/Termination of an SSH session Reason for failure Non-TOE endpoint of connection (IP address) for both successes and failures. FCS_RBG_EXT.1 None. FDP_RIP.2 None. FIA_PMG_EXT.1 None. FIA_UIA_EXT.1 All use of the authentication mechanism. Provided user identity, origin of the attempt authentication mechanism. (e.g., IP address) FIA_UAU_EXT.2 All use of the authentication mechanism. Origin of the attempt (e.g., IP address). 19 Requirement Auditable Events Additional Audit Record Contents FIA_UAU.7 None. FMT_MTD.1 None. FMT_SMF.1 None. FMT_SMR.2 None. FPT SKP EXT.1 None. FPT APW EXT.1 None. FPT_STM.1 Changes to the time. The old and new values for the time. Origin of the attempt (e.g., IP address). FPT TUD EXT.1 Initiation of update. No additional information. FPT TST EXT.1 None. FTA_SSL_EXT.1 Termination of the session. No additional information. FTA_SSL.3 The termination of a remote session by the session locking mechanism. No additional information. FTA_SSL.4 The termination of an interactive session. No additional information. FTA_TAB.1 None. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. FTP_TRP.1 Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Identification of the claimed user identity. Table 6 TOE Security Functional Requirements and Auditable Events 4.2.1 Class: Security Audit (FAU) FAU_GEN.1 Audit Data Generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shut-down of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrative actions; d) [Specifically defined auditable events listed in Table 1]. FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [information specified in column three of Table 1]. FAU_GEN.2 User Identity Association FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_STG_EXT.1 External Audit Trail Storage FAU_STG_EXT.1.1 The TSF shall be able to [transmit the generated audit data to an external IT entity] using a trusted channel implementing the [TLS] protocol. 20 4.2.2 Class: Cryptographic Support (FCS) FCS_CKM.1 Cryptographic Key Generation (For Asymmetric Keys) FCS_CKM.1.1: Refinement: The TSF shall generate asymmetric cryptographic keys used for key establishment in accordance with • NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for finite field-based key establishment schemes; • NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic curve-based key establishment schemes and implementing “NIST curves” P-256, P-384 and [selection: P-521, no other curves] (as defined in FIPS PUB 186-4, “Digital Signature Standard”) • NIST Special Publication 800-56B, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography" for RSA-based key establishment schemes] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. FCS_CKM_EXT.4 Cryptographic Key Zeroization FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs when no longer required. FCS_COP.1(1) Cryptographic Operation (for data encryption/decryption) FCS_COP.1.1(1) Refinement: The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm [AES operating in [CBC, GCM]] and cryptographic key sizes 128- bits and 256-bits that meets the following:  FIPS PUB 197, "Advanced Encryption Standard (AES)"  [NIST SP 800-38D] FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) FCS_COP.1.1(2) Refinement: The TSF shall perform cryptographic signature services in accordance with a [ 1. RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048 bits or greater, or 2. Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater] that meets the following: Case: RSA Digital Signature Algorithm  FIPS PUB 186-2 or FIPS PUB 186-3, "Digital Signature Standard” Case: Elliptic Curve Digital Signature Algorithm  FIPS PUB 186-3, “Digital Signature Standard”  The TSF shall implement "NIST curves" P-256, P-384 and [P-521] (as defined in FIPS PUB 186-3, "Digital Signature Standard"). FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing) 21 FCS_COP.1.1(3) Refinement: The TSF shall perform [cryptographic hashing services] in accordance with a specified cryptographic algorithm [SHA-1, SHA-224, SHA-256, SHA-384, SHA-512] and message digest sizes [160, 224, 256, 384, 512] bits that meet the following: FIPS Pub 180-3, "Secure Hash Standard. FCS_COP.1(4) Cryptographic Operation (for keyed-hash message authentication) FCS_COP.1.1(4) Refinement: The TSF shall perform [keyed-hash message authentication] in accordance with a specified cryptographic algorithm HMAC-[ SHA-1, SHA-224, SHA-256, SHA-384, SHA-512], key size [512 or 1024 bits], and message digest sizes [160, 224, 256, 384, 512] bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPS Pub 180-3, "Secure Hash Standard. FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation) FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with [selection, choose one of: NIST Special Publication 800-90 using [CTR_DRBG (AES)] seeded by an entropy source that accumulated entropy from [a software-based noise source; a TSF-hardware-based noise source]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at least equal to the greatest security strength of the keys and authorization factors that it will generate. FCS_TLS_EXT.1 Explicit: TLS FCS_TLS_EXT.1.1 The TSF shall implement one or more of the following protocols [selection: TLS 1.0 (RFC 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246)] supporting the following ciphersuites: Mandatory Ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA Optional Ciphersuites: [TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_ SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ]. FCS_SSH_EXT.1 Explicit: SSH FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and [no other RFCs]. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, password-based. FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [65,535 bytes] bytes in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms: AES-CBC-128, AES-CBC-256, [AEAD_AES_128_GCM, AEAD_AES_256_GCM]. 22 FCS_SSH_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses [SSH_RSA] and [no other public key algorithms,] as its public key algorithm(s). FCS_SSH_EXT.1.6 The TSF shall ensure that data integrity algorithms used in SSH transport connection is [hmac-sha1, hmac-sha2-256, hmac-sha2-512]. FCS_SSH_EXT.1.7 The TSF shall ensure that diffie-hellman-group14-sha1 and [no other methods] are the only allowed key exchange methods used for the SSH protocol. 4.2.3 Class: User Data Protection (FDP) FDP_RIP.2 Full Residual Information Protection FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] all objects. 4.2.4 Class: Identification and Authentication (FIA) FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: 1. Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: ["!", "@", "#", “$”, “%”, “ ”, “&”, “*”, “(“, ”)”]; 2. Minimum password length shall settable by the Security Administrator, and support passwords of 15 characters or greater; FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.1.1 The TSF shall require the following actions prior to allowing the non-TOE entity to initiate the identification and authentication process:  Display the warning banner in accordance with FTA_TAB.1;  [no other actions] FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [none] to perform administrative user authentication. FIA_UAU.7 Protected Authentication Feedback FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console. 4.2.5 Class: Security Management (FMT) FMT_MTD.1 Management of TSF Data (for general TSF data) FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF data to the Security Administrators FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: 23  Ability to administer the TOE locally and remotely;  Ability to update the TOE, and to verify the updates using [digital signature] capability prior to installing those updates;  [No other capabilities] FMT_SMR.2 Restrictions on Security Roles FMT_SMR.2.1 The TSF shall maintain the roles:  Authorized Administrator FMT_SMR.2.2 The TSF shall be able to associate the user with roles FMT_SMR.2.3 The TSF shall ensure that the conditions  Authorized Administrator role shall be able to administer the TOE locally;  Authorized Administrator role shall be able to administer the TOE remotely; are satisfied. 4.2.6 Class: Protection of the TSF (FPT) FPT_SKP_EXT.1 Extended: Protection of TSF Data (for reading of all symmetric keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys and private keys. FPT_APW_EXT.1 Extended: Protection of Administrator Passwords FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords. FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. FPT_TUD_EXT.1 Extended: Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide security administrators the ability to query the current version of the TOE firmware/software. FPT_TUD_EXT.1.2 The TSF shall provide security administrators the ability to initiate updates to TOE firmware/software. FPT_TUD_EXT.1.3 The TSF shall provide a means to verify firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates. FPT_TST_EXT.1: TSF Testing FPT_TST_EXT.1.1 The TSF shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct operation of the TSF. 4.2.7 Class: TOE Access (FTA) FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session] after a Security Administrator-specified time period of inactivity. 24 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after a [Security Administrator-configurable time interval of session inactivity]. FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 Refinement: Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE. 4.2.8 Class: Trusted Path/Channels (FTP) FTP_ITC.1 Inter-TSF trusted channel FTP_ITC.1.1 Refinement: The TSF shall use [TLS] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. FTP_ITC.1.2 The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [audit]. FTP_TRP.1 Trusted Path FTP_TRP.1.1 Refinement: The TSF shall use [SSH] provide a trusted communication path between itself and remote administrators that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and detection of modification of the communicated data. FTP_TRP.1.2 Refinement: The TSF shall permit remote administrators to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. 4.3 TOE SFR Dependencies Rationale for SFRs The Protection Profile for Network Devices with Errata #3 contains all the requirements claimed in this Security Target. As such, the dependencies are not applicable since the PP has been approved. 4.4 Security Assurance Requirements The TOE assurance requirements for this ST are taken directly from the Protection Profile for Network Devices with Errata #3 which are derived from Common Criteria Version 3.1, Revision 4. The assurance requirements are summarized in the table below. Assurance Class Components Components Description Development ADV_FSP.1 Basic Functional Specification Guidance Documents AGD_OPE.1 Operational User Guidance 25 Assurance Class Components Components Description AGD_PRE.1 Preparative User Guidance Life Cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM Coverage Tests ATE_IND.1 Independent Testing – Conformance Vulnerability Assessment AVA_VAN.1 Vulnerability Analysis Table 7 Security Assurance Requirements 4.5 Rationale for Security Assurance Requirements The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). The development evidence also contains a tracing of the interfaces to the SFRs described in this ST. 4.6 Assurance Measures The TOE satisfies the identified assurance requirements. This section identifies the Assurance Measures applied by FireEye to satisfy the assurance requirements. The table below lists the details. SAR Component How the SAR will be met ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). The development evidence also contains a tracing of the interfaces to the SFRs described in this ST. AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of how the administrative users of the TOE can securely administer the TOE using the interfaces that provide the features and functions detailed in the guidance. AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so that the users of the TOE can put the components of the TOE in the evaluated configuration. ALC_CMC.1 The Configuration Management (CM) documents describe how the consumer identifies the evaluated TOE. The CM documents identify the configuration items, how those configuration items are uniquely identified, and the adequacy of the procedures that are used to control and track changes that are made to the TOE. This includes details on what changes are tracked, how potential changes are incorporated, and the degree to which automation is used to reduce the scope for error. ALC_CMS.1 ATE_IND.1 FireEye will provide the TOE for testing. AVA_VAN.1 FireEye will provide the TOE for testing. Table 8 TOE Security Assurance Measures 26 5 TOE Summary Specification This chapter identifies and describes how the Security Functional Requirements identified above are met by the TOE. TOE SFR Rationale FAU_GEN.1 The TOE generates a comprehensive set of audit logs that identify specific TOE operations whenever an auditable event occurs. Auditable events include: failure on invoking cryptographic functionality such as establishment, termination and failure of a TLS session; establishment, termination and failure of an SSH session; modifications to the group of users that are part of the authorized administrator roles; all use of the user identification mechanism; any use of the authentication mechanism; any change in the configuration of the TOE, changes to time, initiation of TOE update, indication of completion of TSF self-test, maximum sessions being exceeded, termination of a remote session; and initiation and termination of a trusted channel. Each of the events is specified in the audit record is in enough detail to identify the user for which the event is associated, when the event occurred, where the event occurred, the outcome of the event, and the type of event that occurred. The audit trail consist of the individual audit records; one audit record for each event that occurred. As noted above, the information includes [at least] all of the required information. The log buffer is circular, so newer messages overwrite older messages after the buffer is full. Administrators are instructed to monitor the log buffer to view the audit records. The first message displayed is the oldest message in the buffer. The TOE can be configured to transmit its audit messages to an external syslog server. Communication with the syslog server is protected using TLS and the TOE can determine when communication with the syslog server fails. The logs for all of the appliances can be viewed on the TOE via the TOE CLI. The TOE does not have an interface to modify audit records, though there is an interface available for the authorized administrator to clear audit data stored locally on the TOE. FAU_GEN.2 The TOE ensures that each auditable event is associated with the user that triggered the event. For example, a human user, user identity or related session ID would be included in the audit record. For an IT entity or device, the IP address, MAC address, host name, or other configured identification is included in the audit record. FAU_STG_EXT.1 The TOE may be configured to export syslog records to a specified, external syslog server. The TOE also stores a limited set of audit records locally on the TOE, and continues to do so if the communication with the syslog server goes down. The TOE protects communications with an external syslog server via TLS. The TOE transmits its audit events to all configured syslog servers at the same time logs are written locally. The local logging buffer size can be configured from a range of 4096 (default) up to 2147483647 bytes. The log buffer is circular, so newer messages overwrite older messages after the buffer is full. If the TLS connection fails, the TOE will store audit records locally on the TOE, and will transmit any locally stored contents when connectivity to the syslog server is restored. Only Authorized Administrators are able to clear the local logs, and local audit records are stored in a directory that does not allow administrators to modify the contents. FCS_CKM.1 In support of secure cryptographic protocols, the TOE supports several key generation schemes, including,  FFC Diffie-Hellman as specified in NIST SP 800-56A, 27 TOE SFR Rationale  ECDH Diffie-Hellman as specified in NIST SP 800-56A,  RSA Key Transport as specified in SP NIST 800-56B. The TOE is fully compliant to both SP 800-56A and SP 800-56B. FCS_CKM_EXT.4 The TOE meets all requirements for destruction of keys and Critical Security Parameters (CSPs). All keys within the TOE are zeroizable. See below for more information on how and when key zeroization takes place. FCS_COP.1(1) The TOE provides symmetric encryption and decryption capabilities using 128 and 256 bit AES in CBC mode and 128 and 256 bit AES in GCM mode as described in NIST SP 800-38A and NIST SP 800-38D. AES is implemented in the following protocols: TLS and SSH. The relevant CAVP certificate numbers are listed in Table 10, Section 1.5.2.2. FCS_COP.1(2) The TOE provides cryptographic signature services using  RSA Signature Algorithm with key size of 2048 and greater,  ECDSA Signature Algorithm with curve 384. The relevant CAVP certificate numbers include, RSA #1759, #1758 ECDSA #696. FCS_COP.1(3) The TOE provides cryptographic hashing services using SHA-1, SHA-256, SHA-384, and SHA- 512 as specified in FIPS Pub 180-3 “Secure Hash Standard.” SHS is implemented in the following protocols: TLS and SSH. The relevant CAVP certificate numbers are listed in Table 10, Section 1.5.2.2. FCS_COP.1(4) The TOE provides keyed-hashing message authentication services using HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 as specified in FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code,” and FIPS 180-3, “Secure Hash Standard.” HMAC is implemented in the following protocols: TLS and SSH. The relevant CAVP certificate numbers are listed in Section 1.5.2.2. FCS_SSH_EXT.1 The TOE uses SSH for multiple purposes, including, communications between remote TOE components and remote administrative communications. The TOE's SSH implementation supports the following,  Compliance with RFCs 4251, 4252, 4253, and 4254;  Dropping SSH packets greater than 65,535 bytes. This is accomplished by buffering all data for a particular SSH packet transmission until the buffer limit is reached and then dropping the packet;  Encryption algorithms AES-CBC-128, AES-CBC-256, AEAD_AES_128_GCM, and AEAD_AES_256_GCM to ensure confidentiality of the session;  Use of the SSH_RSA public key algorithms for authentication;  Password based authentication;  Hashing algorithm hmac-sha1, hmac-sha2-256, hmac-sha2-512 to ensure the integrity of the session;  Enforcement of DH Group 14 as the only allowed key exchange method. FCS_TLS_EXT.1 In support of secure communication with external entities, the TOE supports the TLS protocol. TLS is used to facilitate communication with the following entities,  Remote audit servers The TOE supports the following ciphersuites for communications with remote entities:  TLS_RSA_WITH_AES_128_CBC_SHA  TLS_RSA_WITH_AES_256_CBC_SHA  TLS_DHE_RSA_WITH_AES_128_CBC_SHA 28 TOE SFR Rationale  TLS_DHE_RSA_WITH_AES_256_CBC_SHA  TLS_RSA_WITH_AES_128_CBC_SHA256  TLS_RSA_WITH_AES_256_CBC_ SHA256  TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256  TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 FCS_RBG_EXT.1 The TOE implements a NIST-approved AES-CTR Deterministic Random Bit Generator (DRBG), as specified in SP 800-90. The entropy source used to seed the Deterministic Random Bit Generator is a random set of bits or bytes that are regularly supplied to the DRBG by from a combined hardware/software source. All RNG entropy source samplings are continuously health tested by the NIST DRBG as per SP 900-90A before using them as a seed. FDP_RIP.2 The TOE ensures that packets transmitted from the TOE do not contain residual information from previous packets. Packets that are not the required length are padded with zeros. Residual data is never transmitted from the TOE. Once packet handling is complete, its content is overwritten before memory buffer which previously contained the packet is reused. FIA_PMG_EXT.1 The TOE supports the local definition of users with corresponding passwords. The passwords can be composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “’”, “+”, “- “, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “?”, “[“, “\”, “]”, “^”, “_”, “`”, “{“, “|”, “}”, and “~”. The minimum password length is settable by the Authorized Administrator. When the TOE is configured for "Common Criteria Compliance" the minimum password length is set to 15 characters. FIA_UIA_EXT.1 The TOE requires all users to be successfully identified and authenticated before allowing any TSF mediated actions to be performed. Administrative access to the TOE is facilitated through one of several interfaces,  Directly connecting to the TOE  Remotely connecting via SSHv2 Regardless of the interface at which the administrator interacts, the TOE prompts the user for a user name and password. Only after the administrative user presents the correct authentication credentials will access to the TOE administrative functionality be granted. No access is allowed to the administrative functionality of the TOE until an administrator is successfully identified and authenticated. The TOE provides a local password based authentication mechanism. The process for authentication is the same for administrative access whether administration is occurring via direct connection or remotely. At initial login, the FIA_UAU_EXT.2 29 TOE SFR Rationale administrative user is prompted to provide a username. After the user provides the username, the user is prompted to provide the administrative password associated with the user account. The TOE then either grant administrative access (if the combination of username and password is correct) or indicate that the login was unsuccessful. The TOE does not provide a reason for failure in the cases of a login failure. FIA_UAU.7 For all authentication, regardless of the interface, the TOE displays only "*" characters when the administrative password is entered so that the password is obscured. FMT_MTD.1 The TOE provides the ability for the administrative user to manage the TOE including accessing TOE data, such as audit data, configuration data, security attributes, session thresholds and updates. The TOE supports several types of administrative user roles. Collectively this sub-roles comprise the Authorized administrator. The supported roles include,  Admin: The system administrator is a “super user” who has all capabilities. The primary function of this role is to configure the system.  Monitor: The system monitor has read-only access to some things the admin role can change or configure.  Operator: The system operator has a subset of the capabilities associated with the admin role. Its primary function is configuring and monitoring the system  Analyst: The system analyst focuses on data plane analysis and possesses several capabilities, including setting up alerts and reports.  Auditor: The system auditor reviews audit logs and performs forensic analysis to trace how events occurred. Together these roles are collectively known as the “Authorized Administrator” Each of the predefined administrative sub-roles have a set of permissions that will grant them access to the TOE data, though with some sub-roles, the access is limited. The TOE performs role-based authorization, using TOE platform authorization mechanisms, to grant access to the privileged and semi-privileged levels. The term “Authorized Administrator” is used in this ST to refer to any user which has been assigned a sub-role that is permitted to perform the relevant action; therefore has the appropriate privileges to perform the requested functions. Management functionality of the TOE is only available after successful authentication. No functionality is available prior to authentication. FMT_SMF.1 The TOE provides all the capabilities necessary to securely manage the TOE. The administrative user can connect to the TOE via CLI to perform these functions. The specific management capabilities available from the TOE include:  Local and remote administration of the TOE services and security characteristics;  The ability to update the TOE software (image integrity verification is provided using RSA 2048-bit SHA-256 digital signature);  Ability to configure the TLS and SSH functionality;  Ability to enable, disable, determine and modify the behavior of all the security functions of the TOE via the GUI. FMT_SMR.2 The TOE maintains Authorized Administrators that are comprised of the sub-roles described above in the FMT_MTD.1 row of this table. The TOE performs role-based authorization, using TOE platform authorization mechanisms, 30 TOE SFR Rationale to grant access to each of the sub-roles supported by the TOE. The term “Authorized Administrator” is used in this ST to refer to any user which has been assigned to a privilege level that is permitted to perform the relevant action; therefore has the appropriate privileges to perform the requested functions. The assigned sub-role determines the functions the user can perform; hence the Authorized Administrator with the appropriate privileges. The TOE authenticates all access to the administrative interfaces using a username and password. The TOE supports both local administration and remote authentication. FPT SKP EXT.1 The TOE stores all private keys in a secure directory that is not readily accessible to administrators; hence no interface access. All passwords are stored in a secure directory that is not readily accessible to administrators. The passwords are stored SHA-512 hashed and not in plaintext. FPT APW EXT.1 FPT_STM.1 The TOE provides a source of date and time information used in audit event timestamps. The clock function is reliant on the system clock provided by the underlying hardware. The TOE can optionally be set to receive clock updates from an NTP server. This date and time is used as the time stamp that is applied to TOE generated audit records and used to track inactivity of administrative sessions. FPT TUD EXT.1 Authorized Administrator can query the software version running on the TOE, and can initiate updates to software images. When software updates are made available by FireEye an administrator can obtain, verify the integrity of, and install those updates. Software updates are downloaded to the TOE via an image fetch command. However, the software image will never be installed without explicit administrative intervention. The TOE image files are digitally signed so their integrity can be verified during the upgrade process, and an image that fails an integrity check will not be loaded. FPT TST EXT.1 The TOE runs a suite of self-tests during initial start-up to verify its correct operation. If any of the tests fail, the TOE will enter into an error state until an Administrator intervenes. During the system bootup process (power on or reboot), all the Power on Startup Test (POST) components for all the cryptographic modules perform the POST. The Software Integrity Test is run automatically whenever the system images are loaded and confirms through use of a hash verification that the image file to be loaded hash not been corrupted and has maintained its integrity. The KATs ensure that the cryptographic functionality is operating correction and has not been comprised and the integrity test ensures that the software has not been modified/corrupted. FTA_SSL_EXT.1 The configuration of inactivity periods are applied on a per interface basis. A configured inactivity period will be applied to both local and remote sessions in the same manner. The session will be terminated and will require authentication to establish a new session. FTA_SSL.3 FTA_SSL.4 An Authorized Administrator is able to exit out of both local and remote administrative sessions. FTA_TAB.1 Authorized administrators can define a custom login banner that will be displayed at the following interfaces,  Local CLI  Remote CLI This banner will be displayed prior to allowing Authorized Administrator access through those interfaces. 31 TOE SFR Rationale FTP_ITC.1 The TOE supports communications with Audit Servers. Each of these connections are protected via a TLS connection. This protects the data from disclosure by encryption and by MACs that verify that data has not been modified. FTP_TRP.1 All remote administrative communications take place over a secure encrypted session. Remote CLI connections take place over an SSHv2 tunnel. The SSHv2 session is encrypted using AES encryption. Table 9 TOE Summary Specification SFR Description 5.1 Key Zeroization The following table describes the key zeroization referenced by FCS_CKM_EXT.4 provided by the TOE. Keys Type Zeroization Description Diffie Hellman private key DH Key Keys are overwritten with zeros at power cycle. Diffie Hellman public key DH Key Keys are overwritten with zeros at power cycle. SSH Private Key RSA Private Key Key is overwritten by zeros when the “msm common compliance declassify zeroized” command is issued. SSH Public Key RSA Public Key Key is overwritten by zeros when the “msm common compliance declassify zeroized” command is issued. SSH Session Key AES Key Keys are overwritten with zeros at power cycle. TLS Private Key RSA Private Key Key is overwritten by zeros when the “msm common compliance declassify zeroized” command is issued. TLS Public Key RSA Public Key Key is overwritten by zeros when the “msm common compliance declassify zeroized” command is issued. TLS Session Encryption Key AES Key Keys are overwritten with zeros at power cycle. TLS Session Integrity Key HMAC Key Keys are overwritten with zeros at power cycle. Table 10 Key Zeroization 32 Annex A: References The following documentation was used to prepare this ST: Identifier Description [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-001 [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009- 002 [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009- 003 [CEM] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-004 [NDPP] Protection Profile for Network Devices, version 1.1, June 8, 2012 [ERRATA#3] Security Requirements for Network Devices Errata #2, 3 November 2014 [800-38A] NIST Special Publication 800-38A Recommendation for Block 2001 Edition Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 [800-56A] NIST Special Publication 800-56A, March, 2007 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) [800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009 Key Establishment Schemes Using Integer Factorization Cryptography [FIPS PUB 186-2] FIPS PUB 186-2 Federal Information Processing Standards Publication 2000 January 27 [FIPS PUB 186-3] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital Signature Standard (DSS) June, 2009 [FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message Authentication Code (HMAC) July 2008 [800-90] NIST Special Publication 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators January 2012 [FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash Standard (SHS) October 2008 Table 11: References