1 Acumen Security, LLC. Document Version: 1.8 FireEye X-Agent Application Security Target 2 Table Of Contents 1 Security Target Introduction.................................................................................................................5 1.1 Security Target and TOE Reference ..............................................................................................5 1.2 TOE Overview................................................................................................................................5 1.3 TOE Architecture...........................................................................................................................5 1.3.1 Physical Boundaries ..............................................................................................................5 1.3.2 Security Functions provided by the TOE...............................................................................5 1.3.2.1 Cryptographic Support......................................................................................................6 1.3.2.2 Identification and Authentication.....................................................................................6 1.3.2.3 Secure Software Update ...................................................................................................6 1.3.2.4 Privacy...............................................................................................................................6 1.3.2.5 Protection of the TSF ........................................................................................................6 1.3.2.6 Trusted Path/Channels......................................................................................................6 1.3.3 TOE Documentation..............................................................................................................6 1.3.4 Other References..................................................................................................................7 2 Conformance Claims.............................................................................................................................7 2.1 CC Conformance ...........................................................................................................................7 2.2 Protection Profile Conformance ...................................................................................................7 2.3 Conformance Rationale ................................................................................................................7 2.3.1 Technical Decisions...............................................................................................................7 3 Security Problem Definition..................................................................................................................9 3.1 Threats ..........................................................................................................................................9 3.2 Assumptions..................................................................................................................................9 3.3 Organizational Security Policies....................................................................................................9 4 Security Objectives..............................................................................................................................10 4.1 Security Objectives for the TOE ..................................................................................................10 4.2 Security Objectives for the Operational Environment................................................................10 5 Security Requirements........................................................................................................................12 5.1 Conventions ................................................................................................................................12 5.2 Security Functional requirements...............................................................................................13 5.2.1 Cryptographic Support (FCS)...............................................................................................13 5.2.2 User Data Protection (FDP).................................................................................................14 5.2.3 Identification and Authentication (FIA) ..............................................................................15 5.2.4 Security Management (FMT) ..............................................................................................15 5.2.5 Privacy (FPR)........................................................................................................................16 3 5.2.6 Protection of TSF (FPT)........................................................................................................16 5.2.7 Trusted Path/Channel (FTP)................................................................................................17 5.3 TOE SFR Dependencies Rationale for SFRs .................................................................................17 5.4 Security Assurance Requirements ..............................................................................................18 5.5 Rationale for Security Assurance Requirements ........................................................................18 5.6 Assurance Measures...................................................................................................................18 6 TOE Summary Specification................................................................................................................20 4 Revision History Version Date Description 1.0 June 2018 Publication 1.1 September 2018 Updated based on internal review and vendor feedback 1.2 September 2018 Added detail 1.3 October 2018 Updated based on internal review 1.4 December 2018 Updated based on ECR comments 1.5 February 2019 Updated based on functional testing 1.6 May 2019 Updates for project check-out 1.7 July 2019 Updated based on ECR comments 1.8 July 2019 Updated to include TD0427 and TD0434 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 X-Agent Security Target ST Version 1.8 ST Date July 2019 ST Author Acumen Security, LLC. TOE Identifier FireEye X-Agent TOE Software Version 28.8.3 TOE Developer FireEye, Inc. Key Words Software Table 1 TOE/ST Identification 1.2 TOE Overview The TOE is a software agent that resides on a host platform. The software exclusively interacts with the NIAP validated FireEye HX Series Appliances (NIAP VID 10892). This interaction consists of the TOE receiving policies from an external HX series appliance (validated separately) and sending any alerts that are found as a result of these scans. This is done via polling. The TOE is an enterprise managed agent that runs in the background of an endpoint platform. It is intended that the user will have no interaction with the software and will not be alerted of communications with the external HX appliance. The frequency at which the agent communicates with the HX appliance is set by the enterprise. By default, each agent polls the HX appliance every 600 seconds (10 minutes) to obtain information and task requests and polls the appliance every 30 minutes to obtain the latest indicators. When new policies are received, they are used to identify potential intrusions on the host platform. 1.3 TOE Architecture 1.3.1 Physical Boundaries The TOE boundary is the application software which runs on the host platform. The software is pushed to the host platform from a FireEye HX series and installs natively as a kernel and user space application. The software runs on Microsoft Operating Systems. The following Operating Systems are included in this evaluation, • Windows Server 2012R2 x64 running on an Intel Xeon E5 processor • Windows Server 2008R2 (SP1) x64 running on an Intel Xeon E5 processor • Windows 10 Version 1507 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1511 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1607 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1703 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1709 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1803 x86 and x64 running on an Intel Xeon E5 processor • Windows 10 Version 1809 x86 and x64 running on an Intel Xeon E5 processor • Windows Server 2016 Version 1607 on an Intel Xeon E5 processor 1.3.2 Security Functions provided by the TOE The TOE provides the security functionality required by [SWAPP]. 6 1.3.2.1 Cryptographic Support The TOE provides cryptographic support for the following features, • TLS connectivity with the following entities: o HX Series Appliance (NIAP VID 10892) • Digital certificate validation Each of these cryptographic algorithms have been validated for conformance to the requirements specified in their respective standards, as identified below. Each of these algorithms are implemented as part of the FireEye OpenSSL Cryptographic Library version 2.0.10-fe1 which is part of the TOE. Algorithm Standard Mode/Keysize CAVP Cert. # AES FIPS 197 SP 800-38A CBC 128, CBC 256 C779 (AES) SHA FIPS 180-4 SHA-1, SHA-256 C779 (SHS) RSA FIPS 186-4 n = 2048 SHA-256 C779 (RSA) HMAC FIPS 198-1 HMAC-SHA-1, HMAC-SHA-256 C779 (HMAC) DRBG SP 800-90A CTR_DRBG(AES-256) C779 (DRBG) Table 2 CAVP Certificate References 1.3.2.2 Identification and Authentication The TOE uses X.509v3 certificates as defined by RFC 5280 to authentication the TLS connection to the HX Series appliance. The TOE validates the X.509 certificates using the certificate path validation algorithm defined in RFC 5280. 1.3.2.3 Secure Software Update The TOE is distributed as a Microsoft .MSI file providing a consistent and reliable versioning. After initial installation, all updates to the X-Agent are distributed as .MSI. Each TOE installation and update is signed by FireEye and can only come from the HX Series appliance associated with the TOE. 1.3.2.4 Privacy The TOE does not transmit Personally Identifiable Information (PII) over the network. This aids in protecting the privacy of users of the host platform. 1.3.2.5 Protection of the TSF The TOE employs several mechanisms to ensure that it is secure on the host platform. The TOE never allocates memory with both write and execute permission. The TOE is designed to operate in an environment in which the following security techniques are in effect, Data execution prevention, Mandatory address space layout randomization (no memory map to an explicit address), Structured exception handler overwrite protection, Export address table access filtering, and Anti-Return Oriented Programming. This allows the TOE to operate in an environment in which the Enhanced Mitigation Experience Toolkit is also running. During compilation the TOE is built with several flags enabled that check for engineering flaws. The TOE is built with the /GS flag enabled. This reduces the possibilities of stack-based buffer overflows in the product. The compiler enables ASLR by default. The TOE is not built with the /DYNAMICBASE:NO which would disable ASLR. 1.3.2.6 Trusted Path/Channels The TOE receives scanning policies from the associated HX Series appliance over the network which it uses on the host platform. This connection is always secured using TLS. 1.3.3 TOE Documentation • [ST] FireEye X-Agent Application Security Target, version 1.8 • [AGD] Common Criteria FireEye Endpoint Agent Addendum, Release 28 Revision 2 7 1.3.4 Other References Protection Profile for Application Software, version 1.2, dated, 22 April 2016 [SWAPP]. 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 extended 2.2 Protection Profile Conformance This TOE is conformant to: • Protection Profile for Application Software, version 1.2, dated, 22 April 2016 [SWAPP]. 2.3 Conformance Rationale This Security Target provides exact conformance to Version 1.2 of the Protection Profile for Application Software, version 1.2. 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. 2.3.1 Technical Decisions All NIAP Technical Decisions (TDs) issued to date that are applicable to [SWAPP] have been addressed. The following table identifies all applicable TD: Identifier Applicable Exclusion Rationale (if applicable) 0434 – Windows Desktop Applications Test Yes 0427 – Reliable Time Source Yes 0392 – FCS_TLSC_EXT.1.2 Wildcard Checking Yes 0390 – Cryptographically Secure RNG Yes 0389 – Handling of SSH EP claim for platform Yes 0385 – FTP_DIT_EXT.1 Assurance Activity Clarification No This TD applies to the VPN Client Module. 0382 – Configuration Storage Options for Apps Yes 0380 – Linux Keyring Requirement in FCS_STO_EXT.1 No This TD applies to the Linux platform. The TOE operations on Windows platforms. 0364 – Android mmap testing for FPT_AEX_EXT.1.1 No This TD applies to the Android platform. The TOE operations on Windows platforms. 0359 – Buffer Protection Yes 0358 – Cipher Suites for TLS in SWApp v1.2 Yes 0327 – Default file permissions for FMT_CFG_EXT.1.2 Yes 0326 – RSA-based key establishment schemes Yes 0305 – Handling of TLS connections with and without mutual authentication No The TOE does not claim conformance to FCS_TLSC_EXT.2 0304 – Update to FCS_TLSC_EXT.1.2 Yes 0300 – Sensitive Data in FDP_DAR_EXT.1 Yes 0296 – Update to FCS_HTTPS_EXT.1.3 No The TOE does not claim conformance to FCS_HTTPS_EXT.1 0295 – Update to FPT_AEX_EXT.1.3 Assurance Activities Yes 0293 – Update to FCS_CKM.1(1) No This TD has been archived 0283 – Cipher Suites for TLS in SWApp v1.2 No This TD has been archived 8 Identifier Applicable Exclusion Rationale (if applicable) 0269 – Update to FPT_AEX_EXT.1.3 Assurance Activity No This TD has been archived 0268 – FMT_MEC_EXT.1 Clarification Yes 0267 – TLSS testing - Empty Certificate Authorities list No The TOE does not claim conformance to FCS_TLSS_EXT.1 0244 – FCS_TLSC_EXT - TLS Client Curves Allowed No The TOE does not claim conformance to FCS_TLSC_EXT.4 0241 – Removal of Test 4.1 in FCS_TLSS_EXT.1.1 No The TOE does not claim conformance to FCS_TLSS_EXT.1 0238 – User-modifiable files FPT_AEX_EXT.1.4 Yes 0221 – FMT_SMF.1.1 - Assignments moved to Selections No This TD only applies to the SWFE EP. 0218 – Update to FPT_AEX_EXT.1.3 Assurance Activity No This TD has been archived 0217 – Compliance to RFC5759 and RFC5280 for using CRLs Yes 0215 – Update to FCS_HTTPS_EXT.1.2 No The TOE does not claim conformance to FCS_HTTPS_EXT.1 0192 – Update to FCS_STO_EXT.1 Application Note No This TD has been archived 0178 – Integrity for installation tests in AppSW PP Yes 0177 – FCS_TLSS_EXT.1 Application Note Update No Superseded by TD0389 0174 – Optional Ciphersuites for TLS Yes 0172 – Additional APIs added to FCS_RBG_EXT.1.1 No Replaced by TD0390 0163 – Update to FCS_TLSC_EXT.1.1 Test 5.4 and FCS_TLSS_EXT.1.1 Test Yes 0131 – Update to FCS_TLSS_EXT.1.1 Test 4.5 No The TOE does not claim conformance to FCS_TLSS_EXT.1 0122 – FMT_SMF.1.1 Assignments moved to Selections No This TD has been archived 0121 – FMT_MEC_EXT.1.1 Configuration Options No This TD only applies to the SWFE EP. 0119 – FCS_STO_EXT.1.1 in PP_APP_v1.2 Yes 0107 – FCS_CKM - ANSI X9.31-1998, Section 4.1.for Cryptographic Key Generation No Superseded by TD0326 Table 3 Technical Decisions 9 3 Security Problem Definition The security problem definition has been taken from [SWAPP] and is reproduced here for the convenience of the reader. The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce. 3.1 Threats The following threats are drawn directly from the [SWAPP]. ID Threat T.NETWORK_ATTACK An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with the application software or alter communications between the application software and other endpoints in order to compromise it. T.NETWORK_EAVESDROP An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the application and other endpoints. T.LOCAL_ATTACK An attacker can act through unprivileged software on the same computing platform on which the application executes. Attackers may provide maliciously formatted input to the application in the form of files or other local communications. T.PHYSICAL_ACCESS An attacker may try to access sensitive data at rest. Table 4 Threats 3.2 Assumptions The following assumptions are drawn directly from the [SWAPP]. ID Assumption A.PLATFORM The TOE relies upon a trustworthy computing platform with a reliable time clock for its execution. This includes the underlying platform and whatever runtime environment it provides to the TOE. A.PROPER_USER The user of the application software is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy A.PROPER_ADMIN The administrator of the application software is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy Table 5 OSPs 3.3 Organizational Security Policies There are no OSPs for the application. 10 4 Security Objectives The security objectives have been taken from [SWAPP] and are reproduced here for the convenience of the reader. 4.1 Security Objectives for the TOE The following security objectives for the TOE were drawn directly from the [SWAPP]. ID TOE Objective O.INTEGRITY Conformant TOEs ensure the integrity of their installation and update packages, and also leverage execution environment-based mitigations. Software is seldom if ever shipped without errors, and the ability to deploy patches and updates to fielded software with integrity is critical to enterprise network security. Processor manufacturers, compiler developers, execution environment vendors, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Application software can often take advantage of these mechanisms by using APIs provided by the runtime environment or by enabling the mechanism through compiler or linker options. Addressed by: FDP_DEC_EXT.1, FMT_CFG_EXT.1, FPT_AEX_EXT.1, FPT_TUD_EXT.1 O.QUALITY To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs Addressed by: FMT_MEC_EXT.1, FPT_API_EXT.1, FPT_LIB_EXT.1 O.MANAGEMENT To facilitate management by users and the enterprise, conformant TOEs provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration. This also includes providing control to the user regarding disclosure of any PII. Addressed by: FMT_SMF.1, FPT_IDV_EXT.1, FPT_TUD_EXT.1.5, FPR_ANO_EXT.1 O.PROTECTED_STORAGE To address the issue of loss of confidentiality of user data in the event of loss of physical control of the storage medium, conformant TOEs will use data-at-rest protection. This involves encrypting data and keys stored by the TOE in order to prevent unauthorized access to this data. This also includes unnecessary network communications whose consequence may be the loss of data Addressed by: FDP_DAR_EXT.1, FCS_STO_EXT.1, FCS_RBG_EXT.1 O.PROTECTED_COMMS To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant TOEs will use a trusted channel for sensitive data. Sensitive data includes cryptographic keys, passwords, and any other data specific to the application that should not be exposed outside of the application Addressed by: FTP_DIT_EXT.1, FCS_TLSC_EXT.1, FCS_DTLS_EXT.1, FCS_RBG_EXT.1 Table 6 Objectives for the TOE 4.2 Security Objectives for the Operational Environment The following security objectives for the operational environment assist the TOE in correctly providing its security functionality. These track with the assumptions about the environment. ID Objective for the Operational Environment OE.PLATFORM The TOE relies upon a trustworthy computing platform for its execution. This includes the underlying operating system and any discrete execution environment provided to the TOE. 11 OE.PROPER_USER The user of the application software is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy OE.PROPER_ADMIN The administrator of the application software is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy Table 7 Objectives for the environment 12 5 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. Requirement Auditable Event FCS_CKM_EXT.1 Cryptographic Key Generation Services FCS_CKM.2 Cryptographic Key Establishment FCS_COP.1(1) Cryptographic Operation - Encryption/Decryption FCS_COP.1(2) Cryptographic Operation - Hashing FCS_COP.1(3) Cryptographic Operation - Signing FCS_COP.1(4) Cryptographic Operation - Keyed-Hash Message Authentication FCS_RBG_EXT.1 Random Bit Generation Services FCS_RBG_EXT.2 Random Bit Generation from Application FCS_STO_EXT.1 Storage of Credentials FCS_TLSC_EXT.1 TLS Client Protocol FDP_DEC_EXT.1 Access to Platform Resources FDP_NET_EXT.1 Network Communications FDP_DAR_EXT.1 Encryption Of Sensitive Application Data FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FMT_MEC_EXT.1 Supported Configuration Mechanism FMT_CFG_EXT.1 Secure by Default Configuration FMT_SMF.1 Specification of Management Functions FPR_ANO_EXT.1 User Consent for Transmission of Personally Identifiable Information FPT_API_EXT.1 Use of Supported Services and APIs FPT_AEX_EXT.1 Anti-Exploitation Capabilities FPT_TUD_EXT.1 Integrity for Installation and Update FPT_LIB_EXT.1 Use of Third Party Libraries FTP_DIT_EXT.1 Protection of Data in Transit Table 8 SFRs 5.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. 13 5.2 Security Functional requirements 5.2.1 Cryptographic Support (FCS) FCS_CKM_EXT.1 Cryptographic Key Generation Services FCS_CKM_EXT.1.1 The application shall [generate no asymmetric cryptographic keys]. FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.2.1 The application shall [implement functionality] to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [RSA-based key establishment schemes] that meets the following: [NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”]. FCS_COP.1(1) Cryptographic Operation - Encryption/Decryption FCS_COP.1.1(1) The application shall perform encryption/decryption in accordance with a specified cryptographic algorithm • AES-CBC (as defined in NIST SP 800-38A) mode and [no other modes] and cryptographic key sizes 256-bit key sizes and [128-bit key sizes]. FCS_COP.1(2) Cryptographic Operation - Hashing FCS_COP.1.1(2) The application shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256] and message digest sizes [160, 256] bits that meet the following: FIPS Pub 180-4. FCS_COP.1(3) Cryptographic Operation - Signing FCS_COP.1.1(3) The application shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4]. FCS_COP.1(4) Cryptographic Operation - Keyed-Hash Message Authentication FCS_COP.1.1(4) The application shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm • HMAC-SHA-256 and [SHA-1] with key sizes [256 bits, 160 bits] and message digest sizes 256 and [160] bits that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard. FCS_RBG_EXT.1 Random Bit Generation Services FCS_RBG_EXT.1.1 The application shall [implement DRBG functionality] for its cryptographic operations. 14 FCS_RBG_EXT.2 Random Bit Generation Services FCS_RBG_EXT.2.1 The application shall perform all deterministic random bit (DRBG) services in accordance with NIST Special Publication 800-90A using [CTR_DRBG(AES)]. FCS_RBG_EXT.2.2 The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a platform- based DRBG and [ no other noise source ] with a minimum of [ 256 bits ] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. FCS_STO_EXT.1 Storage of Credentials FCS_STO_EXT.1.1 The application shall [implement functionality to securely store [digital certificates]] to non-volatile memory. FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 The application shall [implement TLS 1.2 (RFC 5246)] supporting the following ciphersuites: • [TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246]. FCS_TLSC_EXT.1.2 The application shall verify that the presented identifier matches the reference identifier according to RFC 6125. FCS_TLSC_EXT.1.3 The application shall establish a trusted channel only if the peer certificate is valid. 5.2.2 User Data Protection (FDP) FDP_DEC_EXT.1 Access to Platform Resources FDP_DEC_EXT.1.1 The application shall restrict its access to [network connectivity]. FDP_DEC_EXT.1.2 The application shall restrict its access to [system logs, [RAM, filesystem]]. FDP_NET_EXT.1 Network Communications FDP_NET_EXT.1.1 The application shall restrict network communication to [polling and downloading new scanning policies to be used to identify potential intrusions on the host OS from the associated FireEye HX appliance, sending information to the associated FireEye HX appliance as defined in the downloaded scanning policies]. 15 FDP_DAR_EXT.1 Encryption Of Sensitive Application Data FDP_DAR_EXT.1.1 The application shall [leverage platform provided functionality to encrypt sensitive data] in non-volatile memory. 5.2.3 Identification and Authentication (FIA) FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.1.1 The application shall [implement functionality] to validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certificate path validation. • The certificate path must terminate with a trusted CA certificate. • The application shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates. • The application shall validate the revocation status of the certificate using [a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3]. • The application shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. o S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the extendedKeyUsage field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. o Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. FIA_X509_EXT.1.2 The application shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 The application shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [TLS]. FIA_X509_EXT.2.2 When the application cannot establish a connection to determine the validity of a certificate, the application shall [not accept the certificate]. 5.2.4 Security Management (FMT) FMT_MEC_EXT.1 Supported Configuration Mechanism FMT_MEC_EXT.1.1 The application shall [invoke the mechanisms recommended by the platform] vendor for storing and 16 setting configuration options. FMT_CFG_EXT.1 Secure by Default Configuration FMT_CFG_EXT.1.1 The application shall only provide enough functionality to set new credentials when configured with default credentials or no credentials. FMT_CFG_EXT.1.2 The application shall be configured by default with file permissions which protect the application's binaries and data files from modification by normal unprivileged user. FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions [no management functions]. 5.2.5 Privacy (FPR) FPR_ANO_EXT.1 User Consent for Transmission of Personally Identifiable Information FPR_ANO_EXT.1.1 The application shall [not transmit PII over a network]. 5.2.6 Protection of TSF (FPT) FPT_API_EXT.1 Use of Supported Services and APIs FPT_API_EXT.1.1 The application shall use only documented platform APIs. FPT_AEX_EXT.1 Anti-Exploitation Capabilities FPT_AEX_EXT.1.1 The application shall not request to map memory at an explicit address except for [no exceptions]. FPT_AEX_EXT.1.2 The application shall [not allocate any memory region with both write and execute permissions]. FPT_AEX_EXT.1.3 The application shall be compatible with security features provided by the platform vendor. FPT_AEX_EXT.1.4 The application shall not write user-modifiable files to directories that contain executable files unless explicitly directed by the user to do so. FPT_AEX_EXT.1.5 The application shall be compiled with stack-based buffer overflow protection enabled. FPT_TUD_EXT.1 Integrity for Installation and Update FPT_TUD_EXT.1.1 The application shall [leverage the platform] to check for updates and patches to the application software. FPT_TUD_EXT.1.2 17 The application shall be distributed using the format of the platform-supported package manager. FPT_TUD_EXT.1.3 The application shall be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events. FPT_TUD_EXT.1.4 The application shall not download, modify, replace or update its own binary code. FPT_TUD_EXT.1.5 The application shall [provide the ability] to query the current version of the application software. FPT_TUD_EXT.1.6 The application installation package and its updates shall be digitally signed such that its platform can cryptographically verify them prior to installation. FPT_LIB_EXT.1 Use of Third Party Libraries FPT_LIB_EXT.1.1 The application shall be packaged with only [api-ms-win-core-console-l1-1-0.dll, api-ms-win-core- datetime-l1-1-0.dll, api-ms-win-core-debug-l1-1-0.dll, api-ms-win-core-errorhandling-l1-1-0.dll, api-ms- win-core-file-l1-1-0.dll, api-ms-win-core-file-l1-2-0.dll, api-ms-win-core-file-l2-1-0.dll, api-ms-win-core- handle-l1-1-0.dll, api-ms-win-core-heap-l1-1-0.dll, api-ms-win-core-interlocked-l1-1-0.dll, api-ms-win- core-libraryloader-l1-1-0.dll, api-ms-win-core-localization-l1-2-0.dll, api-ms-win-core-memory-l1-1- 0.dll, api-ms-win-core-namedpipe-l1-1-0.dll, api-ms-win-core-processenvironment-l1-1-0.dll, api-ms- win-core-processthreads-l1-1-0.dll, api-ms-win-core-processthreads-l1-1-1.dll, api-ms-win-core-profile- l1-1-0.dll, api-ms-win-core-rtlsupport-l1-1-0.dll, api-ms-win-core-string-l1-1-0.dll, api-ms-win-core- synch-l1-1-0.dll, api-ms-win-core-synch-l1-2-0.dll, api-ms-win-core-sysinfo-l1-1-0.dll, api-ms-win-core- timezone-l1-1-0.dll, api-ms-win-core-util-l1-1-0.dll, api-ms-win-crt-conio-l1-1-0.dll, api-ms-win-crt- convert-l1-1-0.dll, api-ms-win-crt-environment-l1-1-0.dll, api-ms-win-crt-filesystem-l1-1-0.dll, api-ms- win-crt-heap-l1-1-0.dll, api-ms-win-crt-locale-l1-1-0.dll, api-ms-win-crt-math-l1-1-0.dll, api-ms-win-crt- multibyte-l1-1-0.dll, api-ms-win-crt-private-l1-1-0.dll, api-ms-win-crt-process-l1-1-0.dll, api-ms-win-crt- runtime-l1-1-0.dll, api-ms-win-crt-stdio-l1-1-0.dll, api-ms-win-crt-string-l1-1-0.dll, api-ms-win-crt-time- l1-1-0.dll, api-ms-win-crt-utility-l1-1-0.dll, audits.dll, concrt140.dll, libeay32.dll, libuv.dll, msvcp140.dll, mxcore.dll, ssleay32.dll, ucrtbase.dll, vcruntime140.dll, zlib1.dll]. 5.2.7 Trusted Path/Channel (FTP) FTP_DIT_EXT.1 Protection of Data in Transit FTP_DIT_EXT.1.1 The application shall [ encrypt all transmitted data with [TLS] ] between itself and another trusted IT product. 5.3 TOE SFR Dependencies Rationale for SFRs The Protection Profile for Application Software contains all the requirements claimed in this Security Target. As such, the dependencies are not applicable since the PP has been approved. 18 5.4 Security Assurance Requirements The TOE assurance requirements for this ST are taken directly from the Protection Profile for Application Software 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 AGD_PRE.1 Preparative User Guidance Life Cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM Coverage ALC_TSU_EXT.1 Timely Security Updates Tests ATE_IND.1 Independent Testing – Conformance Vulnerability Assessment AVA_VAN.1 Vulnerability Analysis Table 9 Security Assurance Requirements 5.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. 5.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). 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 and ALC_CMS.1 19 SAR Component How the SAR will be met how potential changes are incorporated. ALC_TSU_EXT.1 Users of the FireEye X-Agent should report any security related issues via the FireEye webpage (https://www.fireeye.com/support.html), which provides a secure channel. Software updates/fixes are also provided via the FireEye webpage. Public availability of an update for a publicly disclosed vulnerability is typically 90 days or less and a maximum of 180 days. ATE_IND.1 FireEye will provide the TOE for testing. AVA_VAN.1 FireEye will provide the TOE for testing. Table 10 TOE Security Assurance Measures 20 6 TOE Summary Specification This chapter identifies and describes how the Security Functional Requirements identified above are met by the TOE. TOE SFR Rationale FCS_CKM_EXT.1 The TOE does not generate RSA keys as it is not required for TLS sessions as the TOE acts as a receiver of keys from the server. FCS_CKM.2 For RSA Key Establishment, the TOE implements sections 7.1 and 7.2.1 of SP 800-56B. The TOE does not perform any operation marked as “Shall Not” or “Should not” in SP 800-56B. Additionally, the TOE does not omit any operation marked as “Shall.” The TOE is a TLS client (i.e. sender), so it does not perform RSA decryption. FCS_COP.1(1) The TOE provides symmetric encryption and decryption capabilities using AES in CBC mode (128 and 256 bits) as described in NIST SP 800-38A. See Table 2 for validation details. FCS_COP.1(2) The TOE provides cryptographic hashing services using SHA-1 and SHA-256 with message digest sizes 160 and 256 bits respectively, as specified in FIPS Pub 180-4 “Secure Hash Standard.” These hashes are used as part of TLS session negotiation and with HMACs used to verify the integrity of TLS traffic. The hash functions are also used in conjunction with RSA as part of the HX server certificate verification. See Table 2 for validation details. FCS_COP.1(3) The TOE provides cryptographic signature services using RSA Digital Signature Algorithm with key size of 2048 and greater as specified in FIPS PUB 186-4, “Digital Signature Standard”. See Table 2 for validation details. FCS_COP.1(4) The TOE provides keyed-hashing message authentication services using HMAC-SHA-1 and SHA-256 with key size and message digests sizes of 160 and 256 bits respectively, as specified in FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code,” and FIPS 180-4, “Secure Hash Standard.” See Table 2 for validation details. FCS_RBG_EXT.1 The TOE implements DRBG functionality. FCS_RBG_EXT.2 The TOE provides random bit generation services using an SP 800-90A CTR_DRBG using AES-256. The DRBG is seeded with at least 256 bits of entropy from the DRBG provided by the Windows platform through the CryptGenRandom API. See Table 2 for validation details. FCS_STO_EXT.1 The TOE stores an X.509 CA certificate (and embedded public key) in a JSON structure stored in non-volatile memory. The JSON structure is encrypted using the TOE provided AES algorithm and is not accessible to any external entity. The CA certificate is used to validate the HX server certificate. The TOE does not store other secret keys, PKI private keys, passwords or other public keys. FCS_TLSC_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, • HX Series Appliances • The TOE only communicates with the HX appliance using TLS_RSA_WITH_AES_128_CBC_SHA X.509 certificates used for this connection are validated using the certificate path validation algorithm defined in RFC 5280. The TOE supports CN-ID (with a DNS name) and DNS-ID (i.e. DNS name in the SAN) reference identifiers. For both types of identifiers, the TOE supports exact matching and wildcard when the wildcard is the entire left-most label. The TOE does not support IP address referenced identifiers or support certificate pinning. FDP_DEC_EXT.1 FDP_NET_EXT.1 The TOE never processes or sends PII data outside the boundary of the host platform. The only external communication that is supported by the TOE is with the associated HX appliance. The communication consists of a fast-polling channel on port 80 which is used to receive a Boolean value about whether there are further instructions to receive. If there are, a TLS-protected channel on Port 443 is initiated with the HX and instructions or 21 TOE SFR Rationale updates are transferred via the TLS session. This channel is used to download new scanning policies. The TOE then acts on these policies (e.g., performing scans on the platform). These downloaded policies may also include instructions to send the results of the scanning to the associated HX. In these cases, the TOE again initiates a TLS-protected channel on Port 443 as before. The TOE never accesses any other host platform hardware functionality besides network connectivity. Depending upon the contents of the policies the TOE receives from the associated HX appliance, the TOE may access the host OS syslog. The contents of memory and the filesystem are scanned as well, leveraging the functionality provided by a kernel driver (fekern.sys) which is installed with the TOE. FDP_DAR_EXT.1 The only information that is stored by the TOE are the policies, the TOE identity, and associated HX identity which are downloaded from the associated HX series appliance. This data is protected by the Windows platform using the OS provided services. The provided guidance documentation provides instructions to ensure that BitLocker is enabled in the evaluated configuration. No other data is stored by the X-Agent. FIA_X509_EXT.1 The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for TLS connections. The X.509 certificates are validated by the FireEye OpenSSL Cryptographic Library during the TLS handshake when it received the TLS server certificate from the HX server. The X.509 certificates are validated using the certificate path validation algorithm defined in RFC 5280, which can be summarized as follows: • the public key algorithm and parameters are checked • the current date/time is checked against the validity period • revocation status is checked • issuer name of X matches the subject name of X+1 • name constraints are checked • policy OIDs are checked • policy constraints are checked; issuers are ensured to have CA signing bits • path length is checked • critical extensions are processed The TOE does not support intermediate CAs. The HX server certificate must be issued by the CA trusted by the TOE. The TOE accepts only CRL files managed by the PKI service on the HX Management Console to determine whether HX certificates have been revoked. If the PKI service is down and the CRL is unavailable, the TOE rejects the connection. FIA_X509_EXT.2 FMT_MEC_EXT.1 The X-Agent software does not provide any Security Relevant configuration options for the software. The software is an agent that installs on the host systems OS. Once installed, the product only allows very limited interaction with the host OS user. The TOE stores the settings configured during installation in the C:\ProgramData\FireEye\xagt directory. FMT_CFG_EXT.1 The TOE does not require any credentials to be configured. The TOE does not authenticate the users of the host OS and the HX server certificate is provided in each TLS connection. The TOE utilizes a CA certificate that is part of the TOE installation. No other functionality is available until after the TOE is installed on the host platform. No modifications may be made to the X-Agent or its associated data by any unprivileged user of the host platform. FMT_SMF.1 The TOE is pushed to the host platform by the HX appliance completely configured. At no time does the TOE user perform any management of the software. FPR_ANO_EXT.1 The TOE does not transmit PII over the network. FPT_API_EXT.1 The TOE leverages the following platform provided Application Programing Interfaces (APIs): ADVAPI32.dll, apphelp.dll, bdcore.dll, CFGMGR32.dll, CLBCatQ.dll, comctl32.dll, 22 TOE SFR Rationale credssp.dll, CRYPT32.dll, CRYPTBASE.dll, CRYPTSP.dll, cscapi.dll, dbghelp.dll, DEVOBJ.dll, dhcpcsvc.dll, DNSAPI.dll, fastprox.dll, FLTLIB.dll, fwpuclnt.dll, GDI32.dll, imagehlp.dll, IMM32.dll, IPHLPAPI.dll, kernel32.dll, KERNELBASE.dll, LPK.dll, MSASN1.dll, MSCTF.dll, msi.dll, mssprxy.dll, msvcrt.dll, mswsock.dll, NETAPI32.dll, netutils.dll, NSI.dll, ntdll.dll, NTDSAPI.dll, ntmarta.dll, ntshrui.dll, ODBC32.dll, odbcint.dll, ole32.dll, OLEAUT32.dll, pcwum.dll, pdh.dll, perfdisk.dll, profapi.dll, PROPSYS.dll, PSAPI.dll, rasadhlp.dll, RPCRT4.dll, RpcRtRemote.dll, rsaenh.dll, sechost.dll, Secur32.dll, SETUPAPI.dll, SHELL32.dll, SHLWAPI.dll, slc.dll, srvcli.dll, SspiCli.dll, tdh.dll, USER32.dll, USERENV.dll, USP10.dll, VERSION.dll, wbemcomn.dll, wbemprox.dll, wbemsvc.dll, webio.dll, winhttp.dll, WINNSI.dll, WINSTA.dll, WINTRUST.dll, wkscli.dll, WLDAP32.dll, WS2-32.dll, wship6.dll, wshtcpip.dll, and WTSAPI32.dll. FPT_AEX_EXT.1 The TOE never allocates memory with both write and execute permission. Write execution is always separate from execute. The TOE is designed to operate in an environment in which the following security techniques are in effect, Data execution prevention, Mandatory address space layout randomization (no memory map to an explicit address), Structured exception handler overwrite protection, Export address table access filtering, and Anti-Return Oriented Programming. This allows the TOE to operate in an environment in which the Enhanced Mitigation Experience Toolkit is also running. TOE executables are written to “C:\Program Files (x86)\FireEye\xagt”, in which no other files are written. In particular, no executable files are co-located in the directory in which the software is installed. During compilation the TOE is built with several flags enabled that check for engineering flaws. The TOE is built with the /GS flag enabled. This reduces the possibilities of stack-based buffer overflows in the product. The compiler enables ASLR by default. The TOE is not compiled with the /DYNAMICBASE:NO which would disable ASLR. FPT_TUD_EXT.1 The TOE, initial installation as well as updates, is distributed as a Microsoft .MSI file. The TOE software version can be queried via the Microsoft command prompt by invoking X- Agent with the -v parameter. TOE updates are signed using digital certificates. The MSI packages are signed using certificates with a public trust chain which leads to Entrust. Some components of the installation package (for instance, containment driver), are signed using the Mandiant/FireEye internal CA. Updates are distributed as .MSI files provided by the associated HX appliances. The TOE provides the ability to completely remove all application files when uninstalled. The user can use the platform provided web browser to query the HX series appliance to determine if an update is available. Users of the FireEye X-Agent should report any security related issues via the FireEye webpage (https://www.fireeye.com/support.html), which provides a secure channel. Software updates/fixes are also provided via the FireEye webpage. Public availability of an update for a publicly disclosed vulnerability is typically 90 days or less and a maximum of 180 days. FPT_LIB_EXT.1 The following supporting DLLs are brought with the TOE into the installation directory: • api-ms-win-core-console-l1-1-0.dll • api-ms-win-core-datetime-l1-1-0.dll • api-ms-win-core-debug-l1-1-0.dll • api-ms-win-core-errorhandling-l1-1-0.dll • api-ms-win-core-file-l1-1-0.dll • api-ms-win-core-file-l1-2-0.dll • api-ms-win-core-file-l2-1-0.dll • api-ms-win-core-handle-l1-1-0.dll • api-ms-win-core-heap-l1-1-0.dll • api-ms-win-core-interlocked-l1-1-0.dll • api-ms-win-core-libraryloader-l1-1-0.dll • api-ms-win-core-localization-l1-2-0.dll 23 TOE SFR Rationale • api-ms-win-core-memory-l1-1-0.dll • api-ms-win-core-namedpipe-l1-1-0.dll • api-ms-win-core-processenvironment-l1-1-0.dll • api-ms-win-core-processthreads-l1-1-0.dll • api-ms-win-core-processthreads-l1-1-1.dll • api-ms-win-core-profile-l1-1-0.dll • api-ms-win-core-rtlsupport-l1-1-0.dll • api-ms-win-core-string-l1-1-0.dll • api-ms-win-core-synch-l1-1-0.dll • api-ms-win-core-synch-l1-2-0.dll • api-ms-win-core-sysinfo-l1-1-0.dll • api-ms-win-core-timezone-l1-1-0.dll • api-ms-win-core-util-l1-1-0.dll • api-ms-win-crt-conio-l1-1-0.dll • api-ms-win-crt-convert-l1-1-0.dll • api-ms-win-crt-environment-l1-1-0.dll • api-ms-win-crt-filesystem-l1-1-0.dll • api-ms-win-crt-heap-l1-1-0.dll • api-ms-win-crt-locale-l1-1-0.dll • api-ms-win-crt-math-l1-1-0.dll • api-ms-win-crt-multibyte-l1-1-0.dll • api-ms-win-crt-private-l1-1-0.dll • api-ms-win-crt-process-l1-1-0.dll • api-ms-win-crt-runtime-l1-1-0.dll • api-ms-win-crt-stdio-l1-1-0.dll • api-ms-win-crt-string-l1-1-0.dll • api-ms-win-crt-time-l1-1-0.dll • api-ms-win-crt-utility-l1-1-0.dll • audits.dll • concrt140.dll • libeay32.dll • libuv.dll • msvcp140.dll • mxcore.dll • ssleay32.dll • ucrtbase.dll • vcruntime140.dll • zlib1.dll FTP_DIT_EXT.1 The TOE communicates externally with one trust IT entity, the FireEye HX Series appliances. The X-Agent periodically polls the HX appliance for policy updates. To do this the TOE initiates a TLS 1.2 secured tunnel using the TOE cryptographic implementation. Updates to the scanning policies are sent through this TLS 1.2 tunnel. No additional information is sent from the TOE. Table 11 TOE Summary Specification SFR Description 24 End of Document