1 Version 1.2 Prepared by: Acumen Security 2400 Research Blvd Rockville MD 20850 FireEye HX Series Appliances v5.0.1 Common Criteria 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.2.1 TOE Product Type......................................................................................................................5 1.3 TOE Description ...............................................................................................................................5 1.4 TOE Evaluated Configuration...........................................................................................................6 1.5 TOE Architecture..............................................................................................................................6 1.5.1 Physical Boundaries...................................................................................................................6 1.5.2 Logical Scope of the TOE ...........................................................................................................7 1.5.3 TOE Documentation ..................................................................................................................8 2 Conformance Claims...........................................................................................................................10 2.1 CC Conformance ............................................................................................................................10 2.2 Protection Profile Conformance ....................................................................................................10 2.3 Conformance Rationale .................................................................................................................10 2.3.1 Technical Decisions .................................................................................................................10 3 Security Problem Definition................................................................................................................12 3.1 Threats ...........................................................................................................................................12 3.2 Assumptions...................................................................................................................................13 3.3 Organizational Security Policies.....................................................................................................14 4 Security Objectives..............................................................................................................................16 4.1 Security Objectives for the Operational Environment...................................................................16 5 Security Requirements........................................................................................................................18 5.1 Conventions ...................................................................................................................................19 5.2 Security Functional requirements..................................................................................................19 5.2.1 Security Audit (FAU) ................................................................................................................19 5.2.2 Cryptographic Support (FCS)...................................................................................................21 5.2.3 Identification and Authentication (FIA)...................................................................................27 5.2.4 Security Management (FMT)...................................................................................................29 5.2.5 Protection of the TSF (FPT)......................................................................................................30 5.2.6 TOE Access (FTA) .....................................................................................................................31 5.2.7 Trusted path/channels (FTP)...................................................................................................32 5.3 Dependency Rationale for SFRs.....................................................................................................32 5.4 Security Assurance Requirements .................................................................................................32 3 5.5 Assurance Measures......................................................................................................................33 6 TOE Summary Specification................................................................................................................34 6.1 Key Storage and Zeroization ..........................................................................................................44 7 Terms and Definitions.........................................................................................................................45 4 Revision History Version Date Description 1.0 April 2021 Initial Release 1.1 May 2021 Updated to address ECR comments 1.2 June 2021 Updated document versions 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 HX Series Appliances v5.0.1 Common Criteria Security Target ST Author Acumen Security, LLC ST Version 1.2 TOE Identifier FireEye HX Series Appliances v5.0.1 TOE Hardware For physical appliances: HX 4402, HX 4502, HX 4502D TOE Software Virtual appliance: HX 4502V Physical and virtual appliance software: 5.0.1 TOE Developer FireEye, Inc. Key Words Network Device, Security Appliance Table 1 TOE/ST Identification 1.2 TOE Overview The FireEye HX Series Appliances are network devices providing organizations with the ability to continuously monitor endpoints for advanced malware and indicators of compromise. Note: Endpoint monitoring has not been evaluated as part of the Common Criteria evaluation. 1.2.1 TOE Product Type FireEye HX series appliances are network devices that provide a managed solution for managing the security posture of connected end points. Please see Section 1.3 for the specific TOE type of each model. 1.3 TOE Description The TOE is comprised of four models of the FireEye HX Series Appliances as shown in Table 2 and Table 3. HX 4402 HX 4502 HX 4502D Management Ports 2x 1GigE BaseT 2x 1GigE BaseT 2x 1GigE BaseT Addon Ports N/A 2x 1GigE BaseT 2x 1GigE BaseT Storage 4x 1.8 TB disk, 3.6 TB virtual disk RAID 10 4x 4TB disk / 8TB virtual disk RAID 10 4x 4TB disk / 8TB virtual disk RAID 10 Enclosure 1RU rack server 1RU rack server 1RU rack server Processor AMD Opteron 6328 (Piledriver) Intel Xeon E3-1240 v6 (Kaby Lake) Intel Xeon E3-1240 v6 (Kaby Lake) TOE Type Stand-alone physical network device Stand-alone physical network device Stand-alone physical network device Table 2 HX Series Appliances HX 4502V Network Ports 2x 1GigE interfaces CPU Cores 8 Memory 64 GB Storage 3600 GB Processor Intel Xeon E5-4620 v4 (Broadwell) Hypervisor VMware vSphere ESXi 6.7 TOE Type Stand-alone virtual network device Table 3 Virtual HX Series Appliances 6 1.4 TOE Evaluated Configuration The TOE evaluated configuration consists of one of the CM series appliances listed above. The TOE has been evaluated to work with the following devices in the IT environment. Some components are required to operate the TOE, while other components may be included at the discretion of the administrator. Component Required Usage/Purpose Description for TOE performance Virtual Hardware Yes (for HX 4502V) Virtual hardware provided by VMware vSphere ESXi 6.7 and Intel Xeon E5-4620 v4 (Broadwell). Management Workstation with Web Browser/SSH Client Yes This includes any IT Environment Management workstation with a Web Browser and an SSH client installed that is used by the TOE administrator to support TOE administration through HTTPS and SSH protected channels. Any SSH client that supports SSHv2 may be used. Any web browser that supports TLS 1.1 or TLS 1.2 may be used. Syslog server No The syslog audit server is used for remote storage of audit records that have been generated by and transmitted from the TOE. The syslog server must support communications using TLS 1.1 or TLS 1.2. NTP Server No NTP server supporting SHA-1 integrity verification. Table 4 IT Environment Components The HX4502V was tested on a Dell PowerEdge R830. The following figure provides a visual depiction of an example of a typical TOE deployment. The TOE boundary is surrounded with hashed red lines. 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. The TOE guidance documentation that is considered to be part of the TOE is the FireEye HX Series Appliances v5.0.1 Common Criteria Guidance Addendum document and is downloadable from the FireEye website. 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 above. In addition, software updates are downloadable from the FireEye website. A login ID and password is required to download the software update. 7 1.5.2 Logical Scope of the TOE The TOE provides the following security functions: • Protected Communications. The TOE protects the integrity and confidentiality of communications as follows: o TLS connectivity with the following entities: ▪ Audit Server ▪ Management Web Browser o SSH connectivity with the following entities: ▪ Management SSH Client • Secure Administration. The TOE enables secure local and remote management of its security functions, including: o Local console CLI administration o Remote CLI administration via SSHv2 o Remote GUI administration via HTTPS/TLS o Administrator authentication using a local database o Timed user lockout after multiple failed authentication attempts o Password complexity enforcement o Role Based Access Control - the TOE supports several types of administrative user roles. Collectively these sub-roles comprise the “Security Administrator” o Configurable banners to be displayed at login o Timeouts to terminate administrative sessions after a set period of inactivity o Protection of secret keys and passwords • Trusted Update. The TOE ensures the authenticity and integrity of software updates through digital signatures and requires administrative intervention prior to the software updates being installed. • Security Audit. The TOE keeps local and remote audit records of security relevant events. The TOE internally maintains the date and time which can be set manually or using authenticated NTP. • Self-Test. The TOE performs a suite of self-tests to ensure the correct operation and enforcement of its security functions. • Cryptographic Operations. The TOE provides cryptographic support for the services described in Table 5. The related CAVP validation details are provided in Table 6 and Table 7. 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 Random Bit Generation Used in TLS session establishment Used in SSH session establishment Hashing Used in secure software update Used in NTP integrity verification HMAC Used to provide TLS traffic integrity verification Used to provide SSH traffic integrity verification 8 Cryptographic Method Use within the TOE AES Used to encrypt TLS traffic Used to encrypt SSH traffic Table 5 TOE Provided Cryptography The TOE utilizes two cryptographic libraries. Version 5.0.1 of the TOE includes the same FireEye OS v9.0 that is used by other FireEye devices. The FireEye Cryptographic Implementation version 9.0 provides the majority of cryptographic operations. Algorithm CAVP Cert # Standard Operation SFR RSA C1720 C1749 FIPS 186-4 Key Generation Signature Generation/Verification FCS_CKM.1 FCS_COP.1/SigGen ECDSA C1720 C1749 FIPS 186-4 Key Generation Signature Generation/Verification FCS_CKM.1 FCS_COP.1/SigGen DRBG C1720 C1749 SP 800-90A Random Bit Generation FCS_RBG_EXT.1 SHS C1720 C1749 ISO/IEC 10118-3:2004 Hashing FCS_COP.1/Hash HMAC C1720 C1749 ISO/IEC 9797-2:2011 Keyed-Hashing FCS_COP.1/KeyedHash AES C1720 C1749 AES specified in ISO 18033-3 CBC specified in ISO 10116 GCM specified in ISO 19772 CTR specified in ISO 10116 Encryption/Decryption FCS_COP.1/DataEncryption CVL C1720 C1749 SP 800-56A Key Establishment FCS_CKM.2 RSA N/A RSAES-PKCS1-v1_5 Key Establishment FCS_CKM.2 Table 6 CAVP Algorithm Testing References The FireEye Cryptographic implementation version 9.0 runs in the Kernel and provides cryptographic operations related to entropy. Algorithm CAVP Cert # Standard Operation SFR DRBG C1934 C2043 SP 800-90A Random Bit Generation FCS_RBG_EXT.1 SHS C1934 C2043 ISO/IEC 10118-3:2004 Hashing FCS_COP.1/Hash HMAC C1934 C2043 ISO/IEC 9797-2:2011 Keyed-Hashing FCS_COP.1/KeyedHash Table 7 CAVP Algorithm Testing References 1.5.3 TOE Documentation The table below lists the TOE guidance documentation. AGD and ST are provided in .pdf form on the NIAP portal. Reference Title Version [AGD] FireEye HX Series Appliances v5.0.1 Common Criteria Guidance Addendum 1.2 9 Reference Title Version [ST] FireEye HX Series Appliances v5.0.1 Common Criteria Security Target 1.2 Table 8 TOE Documents 10 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 5, April 2017 • Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5, April 2017: Part 2 extended • Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5, April 2017: Part 3 conformant 2.2 Protection Profile Conformance This TOE claims exact conformance to: • collaborative Protection Profile for Network Devices, Version 2.2e [NDcPP] 2.3 Conformance Rationale The security problem definition, security objectives and security requirements in this Security Target are all taken from the [NDcPP]. All of the mandatory security requirements are included and selection-based SFRs are included based on the instructions in the [NDcPP]. 2.3.1 Technical Decisions All NIAP Technical Decisions (TDs) issued to date that are applicable to [NDcPP] have been considered. The following table identifies all applicable TD: Identifier Applicable Exclusion Rationale (if applicable) 0581 – NIT Technical Decision for Elliptic curve-based key establishment and NIST SP 800-56Arev3 Yes 0580 – NIT Technical Decision for clarification about use of DH14 in NDcPPv2.2e Yes 0572 – NiT Technical Decision for Restricting FTP_ITC.1 to only IP address identifiers Yes 0571 – NiT Technical Decision for Guidance on how to handle FIA_AFL.1 Yes 0570 – NiT Technical Decision for Clarification about FIA_AFL.1 Yes 0569 – NIT Technical Decision for Session ID Usage Conflict in FCS_DTLSS_EXT.1.7 Yes 0564 – NiT Technical Decision for Vulnerability Analysis Search Criteria Yes 0563 – NiT Technical Decision for Clarification of audit date information Yes 0556 – NIT Technical Decision for RFC 5077 question Yes 0555 – NIT Technical Decision for RFC Reference incorrect in TLSS Test Yes 0547 – NIT Technical Decision for Clarification on developer disclosure of AVA_VAN Yes 0546 – NIT Technical Decision for DTLS - clarification of Application Note 63 No The ST does not include DTLS SFRs. 0538 – NIT Technical Decision for Outdated link to allowed-with list Yes 0537 – NIT Technical Decision for Incorrect reference to FCS_TLSC_EXT.2.3 Yes 0536 – NIT Technical Decision for Update Verification Inconsistency Yes 11 Identifier Applicable Exclusion Rationale (if applicable) 0528 – NIT Technical Decision for Missing EAs for FCS_NTP_EXT.1.4 Yes 0527 – Updates to Certificate Revocation Testing (FIA_X509_EXT.1) Yes Table 9 Technical Decisions 12 3 Security Problem Definition The security problem definition has been taken from [NDcPP] 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 [NDcPP]: ID Threat T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the- middle attacks, which would provide access to the administrative session, or sessions between Network Devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the Network Device itself. T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints, e.g. a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the Network Device itself could be compromised. T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the Network Device without 13 Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the Network Device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak administrative passwords to gain privileged access to the device. Having privileged access to the device provides the attacker unfettered access to the network traffic and may allow them to take advantage of any trust relationships with other Network Devices. T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device. Table 10 Threats 3.2 Assumptions The following assumptions are drawn directly from the [NDcPP]: ID Assumption A.PHYSICAL_PROTECTION The Network Device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security or interfere with the device’s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cPP does not include any requirements on physical tamper protection or other physical attack mitigations. The cPP does not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. For vNDs, this assumption applies to the physical platform on which the VM runs. A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). In the case of vNDs, the VS is considered part of the TOE with only one vND instance for each physical hardware platform. The exception being where components of the distributed TOE run inside more than one virtual machine (VM) on a single VS. There are no other guest VMs on the physical platform providing non-Network Device functionality. A.NO_THRU_TRAFFIC_PROTECTION A standard/generic Network Device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the Network Device to protect data that originates on or is destined to the 14 ID Assumption device itself, to include administrative data and audit data. Traffic that is traversing the Network Device, destined for another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of Network Devices (e.g., firewall). A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device are assumed to be trusted and to act in the best interest of security for the organization. This includes appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The Network Device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are expected to fully validate (e.g. offline verification) any CA certificate (root CA certificate or intermediate CA certificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CA Key Store', or similar) as a trust anchor prior to use (e.g. offline verification). A.REGULAR_UPDATES The Network Device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to access the Network Device are protected by the platform on which they reside. A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. A.VS_TRUSTED_ADMINISTRATOR The Security Administrators for the VS are assumed to be trusted and to act in the best interest of security for the organization. This includes not interfering with the correct operation of the device. The Network Device is not expected to be capable of defending against a malicious VS Administrator that actively works to bypass or compromise the security of the device. A.VS_REGULAR_UPDATES The VS software is assumed to be updated by the VS Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.VS_ISOLATON For vNDs, it is assumed that the VS provides, and is configured to provide sufficient isolation between software running in VMs on the same physical platform. Furthermore, it is assumed that the VS adequately protects itself from software running inside VMs on the same physical platform. A.VS_CORRECT_CONFIGURATION For vNDs, it is assumed that the VS and VMs are correctly configured to support ND functionality implemented in VMs. Table 11 Assumptions 3.3 Organizational Security Policies The following Organizational Security Policies are drawn directly from the [NDcPP]: 15 ID OSP P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE. Table 12 OSPs 16 4 Security Objectives The security objectives have been taken from [NDcPP] and are reproduced here for the convenience of the reader. 4.1 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 Operation Environment OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. 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. Note: For vNDs the TOE includes only the contents of the its own VM, and does not include other VMs or the VS. OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For vNDs, this includes the VS Administrator responsible for configuring the VMs that implement ND functionality. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove any certificate from the TOE’s trust store in case such certificate can no longer be trusted. OE.UPDATES The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. OE.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vNDs, this applies when the physical platform on which the VM runs is removed from its operational environment. OE.VM_CONFIGURATION For vNDs, the Security Administrator ensures that the VS and VMs are configured to o reduce the attack surface of VMs as much as possible while supporting ND functionality (e.g., remove unnecessary virtual hardware, turn off unused inter-VM communications mechanisms), and o correctly implement ND functionality (e.g., ensure virtual networking is properly configured to support network traffic, management channels, and audit reporting). 17 The VS should be operated in a manner that reduces the likelihood that vND operations are adversely affected by virtualisation features such as cloning, save/restore, suspend/resume, and live migration. If possible, the VS should be configured to make use of features that leverage the VS’s privileged position to provide additional security functionality. Such features could include malware detection through VM introspection, measured VM boot, or VM snapshot for forensic analysis. Table 13 Objectives for the Operational Environment 18 5 Security Requirements This section identifies the Security Functional Requirements for the TOE. The SFRs included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5, dated: April 2017 and all international interpretations. Requirement Description FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association FAU_STG_EXT.1 Protected Audit Event Storage FCS_CKM.1 Cryptographic Key Generation FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_HTTPS_EXT.1 HTTPS Protocol FCS_NTP_EXT.1 NTP Protocol FCS_RBG_EXT.1 Random Bit Generation FCS_SSHS_EXT.1 SSH Server Protocol FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication FCS_TLSS_EXT.1 TLS Server Protocol Without Mutual Authentication FIA_AFL.1 Authentication Failure Management FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU.7 Protected Authentication Feedback FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.3 X.509 Certificate Requests FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour FMT_MTD.1/CoreData Management of TSF Data FMT_SMF.1 Specification of Management Functions FMT_SMR.2 Restrictions on Security Roles FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys) FPT_APW_EXT.1 Protection of Administrator Passwords FPT_TST_EXT.1 TSF Testing FPT_TUD_EXT.1 Trusted Update FPT_STM_EXT.1 Reliable Time Stamps FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_TAB.1 Default TOE Access Banners FTP_ITC.1 Inter-TSF Trusted Channel FTP_TRP.1/Admin Trusted Path Table 14 SFRs 19 5.1 Conventions The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document follows the conventions used in NDcPP v2.2e in order to comply with exact conformance. Within selections and assignments made in the ST 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; • Selection within a selection: Indicated by an additional set of [brackets]; • Iteration: Indicated by appending the iteration identifier after a slash, e.g., /SigGen. • Where operations were completed in the PP itself, the formatting used in the PP has been retained. Extended SFRs are identified by having a label ‘EXT’ after the requirement name. Formatting conventions outside of operations matches the formatting specified within the PP. 5.2 Security Functional requirements 5.2.1 Security Audit (FAU) 5.2.1.1 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 comprising: • Administrative login and logout (name of user account shall be logged if individual user accounts are required for Administrators). • Changes to TSF data related to configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). • Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). • Resetting passwords (name of related user account shall be logged). • [no other actions]; d) Specifically defined auditable events listed in Table 15. 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 cPP/ST, information specified in column three of Table 15. Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None. None. 20 Requirement Auditable Events Additional Audit Record Contents FAU_GEN.2 None. None. FAU_STG_EXT.1 None. None. FCS_CKM.1 None. None. FCS_CKM.2 None. None. FCS_CKM.4 None. None. FCS_COP.1/DataEncryption None. None. FCS_COP.1/SigGen None. None. FCS_COP.1/Hash None. None. FCS_COP.1/KeyedHash None. None. FCS_HTTPS_EXT.1 Failure to establish a HTTPS Session. Reason for failure FCS_NTP_EXT.1 • Configuration of a new time server • Removal of configured time server Identity if new/removed time server FCS_RBG_EXT.1 None. None. FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure FCS_TLSC_EXT.1 Failure to establish a TLS Session Reason for failure FCS_TLSS_EXT.1 Failure to establish a TLS Session Reason for failure FIA_AFL.1 Unsuccessful login attempts limit is met or exceeded. Origin of the attempt (e.g., IP address). FIA_PMG_EXT.1 None. None. FIA_UIA_EXT.1 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU_EXT.2 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU.7 None. None. FIA_X509_EXT.1/Rev • Unsuccessful attempt to validate a certificate • Any addition, replacement or removal of trust anchors in the TOE’s trust store. • Reason for failure of certificate validation • Identification of certificates added, replaced or removed as trust anchor in the TOE’s trust store FIA_X509_EXT.2 None None FIA_X509_EXT.3 None. None. FMT_MOF.1/Functions None. None. FMT_MOF.1/ManualUpdate Any attempt to initiate a manual update None. FMT_MTD.1/CoreData None. None. FMT_SMF.1 All management activities of TSF data. None. FMT_SMR.2 None. None. FPT_SKP_EXT.1 None. None. FPT_APW_EXT.1 None. None. FPT_TST_EXT.1 None. None. FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure) None. FPT_STM_EXT.1 Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time 21 Requirement Auditable Events Additional Audit Record Contents logged. See also application note on FPT_STM_EXT.1) for success and failure (e.g., IP address). FTA_SSL_EXT.1 (if “terminate the session” is selected) The termination of a local session by the session locking mechanism. None. FTA_SSL.3 The termination of a remote session by the session locking mechanism. None. FTA_SSL.4 The termination of an interactive session. None. FTA_TAB.1 None. 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/Admin • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. None. Table 15 Security Functional Requirements and Auditable Events 5.2.1.2 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. 5.2.1.3 FAU_STG_EXT.1 Protected Audit Event 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 according to FTP_ITC.1. FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition [ • The TOE shall consist of a single standalone component that stores audit data locally]. FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [overwrite oldest record first]] when the local storage space for audit data is full. 5.2.2 Cryptographic Support (FCS) 5.2.2.1 FCS_CKM.1 Cryptographic Key Generation FCS_CKM.1.1 22 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ • RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3; • ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4; • FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special Publication 800- 56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [RFC 3526]. ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. 5.2.2.2 FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ • RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specification Version 2.1”; • Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”; • FFC Schemes using “safe-prime” groups that meet the following: ‘NIST Special Publication 800- 56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [groups listed in RFC 3526]]. ] that meets the following: [assignment: list of standards]. 5.2.2.3 FCS_CKM.4 Cryptographic Key Destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method • For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite consisting of [zeroes]], • For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that: [ o logically addresses the storage location of the key and performs a [single] overwrite consisting of [zeros]] that meets the following: No Standard. 5.2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CBC, CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: 23 AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as specified in ISO 19772]. 5.2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ • RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048, 3072 bits] • Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256, 384, 512 bits] ] that meet the following: [ • For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, • For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST curves” [P-256, P-384, P-521]; ISO/IEC 14888-3, Section 6.4 ]. 5.2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 10118- 3:2004. 5.2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, implicit] and cryptographic key sizes [160 bits, 256 bits, 384 bits, 512 bits] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. 5.2.2.8 FCS_HTTPS_EXT.1 HTTPS Protocol FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS. FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [not require client authentication] if the peer certificate is deemed invalid. 24 5.2.2.9 FCS_NTP_EXT.1 NTP Protocol FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [NTP v3 (RFC 1305), NTP v4 (RFC 5905)]. FCS_NTP_EXT.1.2 The TSF shall update its system time using [ • Authentication using [SHA1] as the message digest algorithm(s); ]. FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or multicast addresses. FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time sources in the Operational Environment. 5.2.2.10 FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [HMAC_DRBG (any), CTR_DRBG (AES)]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[one] software-based noise source] with a minimum of [256 bits] of entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of the keys and hashes that it will generate. 5.2.2.11 FCS_SSHS_EXT.1 SSH Server Protocol FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol in accordance with: RFC(s) 4251, 4252, 4253, 4254, [5656, 6187, 6668]. FCS_SSHS_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_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [65,536] bytes in an SSH transport connection are dropped. FCS_SSHS_EXT.1.4 25 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256-cbc, aes128-ctr, aes256-ctr, aes128- gcm@openssh.com, aes256-gcm@openssh.com]. FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication implementation uses [ssh-rsa] as its public key algorithm(s) and rejects all other public key algorithms. FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [hmac-sha1, hmac-sha2-256, hmac- sha2-512, implicit] as its MAC algorithm(s) and rejects all other MAC algorithm(s). FCS_SSHS_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. FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session keys are used for a threshold of no longer than one hour, and each encryption key is used to protect no more than one gigabyte of data. After any of the thresholds are reached, a rekey needs to be performed. 5.2.2.12 FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [ • TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 • TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 • TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 • TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 • TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 • TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 • TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 • TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC4492 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC4492 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC4492 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC4492] and no other 26 ciphersuites. FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the reference identifier per RFC 6125 section 6, IPv4 address in SAN, IPv6 address in the SAN]. FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the server certificate is invalid. The TSF shall also [ • Not implement any administrator override mechanism ]. FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Elliptic Curves/Supported Groups Extension with the following curves/groups: [secp256r1, secp384r1, secp521r1] and no other curves/groups] in the Client Hello. 5.2.2.13 FCS_TLSS_EXT.1 TLS Server Protocol FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [ ● TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 ● TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 ● TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 ● TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 ● TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 ● TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 ● TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 ● TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 ● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 ● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 ● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 ● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 ● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 ● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 ● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC4492 ● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC4492 ● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC4492 ● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC4492] and no other ciphersuites. FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0 and [none]. 27 FCS_TLSS_EXT.1.3 The TSF shall perform key establishment for TLS using [RSA with key size [2048 bits, 3072 bits], Diffie- Hellman parameters with size [2048 bits], ECDHE curves [secp256r1, secp384r1, secp521r1] and no other curves]]. FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session tickets according to RFC 5077]. 5.2.3 Identification and Authentication (FIA) 5.2.3.1 FIA_AFL.1 Authentication Failure Management FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1 to 4,294,967,295] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using a password. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [prevent the offending Administrator from successfully establishing remote session using any authentication method that involves a password until [unlocks the user] is taken by an Administrator; prevent the offending Administrator from successfully establishing remote session using any authentication method that involves a password until an Administrator defined time period has elapsed]. 5.2.3.2 FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [ “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [“’”1 , “+”, “-“, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “?”, “\”, “[“, “]”2 , “^”, “_”3 , “`”4 , “{“, “|”5 , “}”, and “~”]; b) Minimum password length shall be configurable to between [15] and [32] characters. 5.2.3.3 FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process: 1 Single-quote character 2 Left and right square brackets (the bottom part of the square bracket hidden by the underlying convention of the selection operation). 3 Underscore, which is hidden by the underlining convention of the selection operation. 4 Backtick character 5 Vertical bar/pipe character 28 • 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. 5.2.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based] authentication mechanism to perform local administrative user authentication. 5.2.3.5 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. 5.2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certification path validation supporting a minimum path length of three certificates. • The certification path must terminate with a trusted CA certificate designated as a trust anchor. • The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. • The TSF shall validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 6960]. • The TSF 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 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. FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 5.2.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 29 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [HTTPS, TLS], and [no additional uses]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [not accept the certificate]. 5.2.3.8 FIA_X509_EXT.3 X.509 Certificate Requests FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name, Organization, Organizational Unit, Country]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. 5.2.4 Security Management (FMT) 5.2.4.1 FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the functions [transmission of audit data to an external IT entity, handling of audit data] to Security Administrators. 5.2.4.2 FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators. 5.2.4.3 FMT_MTD.1/CoreData Management of TSF Data FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security Administrators. 5.2.4.4 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: • Ability to administer the TOE locally and remotely; • Ability to configure the access banner; • Ability to configure the session inactivity time before session termination or locking; • Ability to update the TOE, and to verify the updates using [digital signature] capability prior to installing those updates; • Ability to configure the authentication failure parameters for FIA_AFL.1; • [ 30 o Ability to configure audit behaviour (e.g. changes to storage locations for audit; changes to behaviour when local audit storage space is full); o Ability to modify the behaviour of the transmission of audit data to an external IT entity; o Ability to configure the cryptographic functionality; o Ability to re-enable an Administrator account; o Ability to set the time which is used for time-stamps; o Ability to configure NTP; o Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors; o Ability to import X.509v3 certificates to the TOE's trust store]. 5.2.4.5 FMT_SMR.2 Restrictions on security roles FMT_SMR.2.1 The TSF shall maintain the roles: • Security Administrator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions • The Security Administrator role shall be able to administer the TOE locally; • The Security Administrator role shall be able to administer the TOE remotely are satisfied. 5.2.5 Protection of the TSF (FPT) 5.2.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 5.2.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords. 5.2.5.3 FPT_TST_EXT.1 TSF Testing FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on)] to demonstrate the correct operation of the TSF: [POST, Cryptographic Tests, Software Integrity Test]. 31 5.2.5.4 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [the most recently installed version of the TOE firmware/software]. FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [no other update mechanism]. FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates. 5.2.5.5 FPT_STM_EXT.1 Reliable Time Stamps FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use. FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time, synchronise time with an NTP server]. 5.2.6 TOE Access (FTA) 5.2.6.1 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. 5.2.6.2 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity. 5.2.6.3 FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. 5.2.6.4 FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 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. 32 5.2.7 Trusted path/channels (FTP) 5.2.7.1 FTP_ITC.1 Inter-TSF trusted channel FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, [no other capabilities] 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 logging]. 5.2.7.2 FTP_TRP.1/Admin Trusted Path FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, TLS, HTTPS] to provide a communication path between itself and authorized 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 provides detection of modification of the channel data. FTP_TRP.1.2/Admin The TSF shall permit remote Administrators to initiate communication via the trusted path. FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. 5.3 Dependency Rationale for SFRs [NDcPP] contains all the requirements claimed in this Security Target. As such, the dependencies are not applicable since the PP has been approved. 5.4 Security Assurance Requirements The TOE assurance requirements for this ST are taken directly from [NDcPP] which are derived from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in the table below. Assurance Class Components Component Description Development ADV_FSP.1 Basic Functional Specification Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures Life Cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM Coverage 33 Assurance Class Components Component Description Security Target evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification Tests ATE_IND.1 Independent Testing – Conformance Vulnerability Assessment AVA_VAN.1 Vulnerability Survey Table 16 Security Assurance Requirements 5.5 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 how potential changes are incorporated. ALC_CMS.1 ATE_IND.1 FireEye will provide the TOE for testing. AVA_VAN.1 FireEye will provide the TOE for testing. FireEye will provide a document identifying the list of software and hardware components. Table 17 TOE Security Assurance Measures 34 6 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 are specified in section 5.2.1, Table 15. 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. For generating/importing of, changing, and deleting of certificates and associated keys, the TOE logs the certificate ID which directly maps to a unique key pair. The audit trail consists 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 does not have an interface to modify audit records. 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 generated and written locally to non-volatile storage. If the TLS connection fails, the TOE continues to store audit records locally on the TOE and will transmit any locally stored contents when connectivity to the syslog server is restored. Local audit records are stored in a directory that does not allow administrators to modify the contents. The amount of audit data that can be stored locally is configurable by setting the local log rotation parameters (e.g. see the logging files rotation CLI commands). The TOE defaults to rotating the log file when it reaches 256MB and retaining 40 compressed archives. This results in storing 10.25GB of uncompressed logs. When the local log is full, the oldest archive file is deleted to allow a new log to be created. FCS_CKM.1 In support of secure cryptographic protocols, the TOE supports RSA key generation schemes as specified in FIPS 186-4, with key sizes of 2048 and 3072 bits. These keys are used in support of digital certificates and keyed authentication for TLS and SSH. The TOE supports Elliptic Curve key generation of P-256, P-384, P-521. The keys are used in support of ECDH key exchange as part of TLS. The TOE supports DHG14 key generation in support of DH key exchanges as part of TLS and SSH. The relevant NIST CAVP certificate numbers are listed in Table 6. 35 TOE SFR Rationale FCS_CKM.2 In support of secure cryptographic protocols, the TOE supports several key establishment schemes, including: • RSA based key exchange based on RSAES-PKCS1-v1_5; • ECC based key exchange based on NIST SP 800-56Ar2; • FFC based key exchange based on NIST SP 800-56Ar3/Diffie-Hellman Group 14 (RFC 3526, Section 3); Scheme SFRs Service RSA FCS_TLSC_EXT.1 FCS_TLSS_EXT.1 Syslog Remote Administration ECC FCS_TLSC_EXT.1 FCS_TLSS_EXT.1 Syslog Remote Administration FFC/DHG14 FCS_TLSC_EXT.1 FCS_TLSS_EXT.1 FCS_SSHS_EXT.1 Syslog Remote Administration The relevant NIST CAVP certificate numbers are listed in Table 6. FCS_CKM.4 Table 19 identifies the keys used by the TSF. All keys are stored plaintext and are protected from unauthorized access as described in FPT_SKP_EXT.1 and the Storage/Protection column. The TSF meets all requirements specified in the NDcPPv2.2e for destruction of keys. All keys within the TSF are securely destroyed as per the descriptions given in Table 19 below. FCS_COP.1/DataEncry ption The TOE provides symmetric encryption and decryption capabilities using 128 and 256 bit AES in CBC mode, CTR mode and GCM mode as described in NIST SP 800-38A and NIST SP 800-38D, respectively. AES is implemented in the following protocols: TLS and SSH. The relevant NIST CAVP certificate numbers are listed in Table 6. FCS_COP.1/SigGen The TOE provides cryptographic signature generation and verification services using: • RSA Signature Algorithm with key size of 2048 bits or 3072 bits, • ECDSA Signature Algorithm with NIST curves P-256, P-384 and P-521. RSA signature generation and verification are used for the TLS and SSH protocols. Additionally, ECDSA signature verification is used in TLS. The relevant NIST CAVP certificate numbers are listed in Table 6. FCS_COP.1/Hash The TOE provides cryptographic hashing services using SHA-1, SHA-256, SHA-384, and SHA- 512 as specified in FIPS Pub 180-4 “Secure Hash Standard.” SHS is implemented in the following parts of the TSF: • NTP – SHA1 • TLS and SSH - SHA1, SHA-256, SHA-384, SHA-512; • Digital signature verification as part of trusted update validation - SHA-256 • Hashing of passwords in non-volatile storage - SHA-512 • Conditioning entropy data – SHA-512 The relevant NIST CAVP certificate numbers are listed in Table 6 and Table 7. 36 TOE SFR Rationale FCS_COP.1/KeyedHashThe TOE provides keyed-hashing message authentication services using HMAC-SHA-1, 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-4, “Secure Hash Standard.” HMAC is implemented in the following protocols: TLS and SSH. The characteristics of the HMACs used in the TOE are given in the following table: Algorithm Hash function Block size Key size Digest size HMAC-SHA-1 SHA-1 512 bits 160 bits 160 bits HMAC-SHA-256 SHA-256 512 bits 256 bits 256 bits HMAC-SHA-384 SHA-384 1024 bits 384 bits 384 bits HMAC-SHA-512 SHA-512 1024 bits 512 bits 512 bits The relevant NIST CAVP certificate numbers are listed in Table 6 and Table 7. FCS_HTTPS_EXT.1 The TOE provides management functionality over an HTTPS connection using the TLS implementation described above and is therefore subject to claiming FCS_HTTPS_EXT.1 in a server capacity. The TOE does not use HTTPS in a client capacity. The TOE’s HTTPS protocol complies with RFC 2818. RFC 2818 is HTTP over TLS. The majority of RFC 2818 is spent on discussing practices for validating endpoint identities and how connections must be setup and torn down. The TOE web GUI operates on an explicit TCP port designed to natively speak TLS. The web server attempts to send closure Alerts prior to closing a connection in accordance with section 2.2.2 of RFC 2818. FCS_NTP_EXT.1 The TOE supports time updates using NTPv3 and NTPv4. The TOE authentications updates using an administrator configured symmetric key and SHA1. The TOE rejects broadcast and multicast time updates. The TOE does not place a limit on the number of NTP time sources that can be configured. FCS_RBG_EXT.1 The TOE implements a NIST-approved CTR_DRBG(AES) and HMAC_DRBG, as specified in SP 800-90A. The entropy source used to seed the Deterministic Random Bit Generator is a random set of bits supplied from one software noise source. (This ST considers the sources ‘software’ simply because the entropy sources are not considered True Random Number Generators (TRNGs) based on random properties of physical processes.) The 512-bit seed value contains at least 256 bits of entropy. The relevant NIST CAVP certificate numbers are listed in Table 6 and Table 7. FCS_SSHS_EXT.1 The TOE is an SSH server, enabling administrators to remotely manage the TOE using the CLI. The SSH server is capable of using both RSA public keys and passwords for client authentication to the remote server. The TOE uses the username presented by the client as the user’s identity. The TOE then authorizes the connection if the presented public key matches an authorized public key for the claimed identity. The TOE drops large SSH packets (i.e. those greater than 65,536 bytes). This is accomplished by tracking the number of bytes read from the network while receiving an SSH packet. If the number of bytes exceeds 35,536 without reaching the end of the SSH packet, the TOE stops reading data and discards the data that has been read. 37 TOE SFR Rationale The TOE supports the following cryptographic algorithms: • ssh-rsa (RSA with SHA-1); • AES-CBC-128, AES-CBC-256, AES-CTR-128, AES-CTR-256, aes128- gcm@openssh.com, and aes256-gcm@openssh.com; • HMAC-SHA1, HMAC-SHA2-256, and HMAC-SHA2-512; • diffie-hellman-group14-sha1. The TOE SSH server is capable of rekeying. The TOE implements two thresholds: • When 1 GB of data is transferred between using an encryption key; and • When 1 hour has elapsed. The TOE continuously checks both conditions. When either of the conditions are met, the TOE will initiate a rekey. All session keys are rekeyed at the same time (e.g. confidentiality and integrity keys). The TOE server maintains an SSH server hostkey fingerprint which can be used by an SSH client to detect server authenticity. FCS_TLSC_EXT.1 The TOE has a single trusted channel which make use of TLS, Syslog. The syslog channel client allows TLS protocol versions 1.1 and 1.2 and are restricted to the following ciphersuites by default: • TLS_RSA_WITH_AES_128_CBC_SHA • 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_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA Ciphersuites can be restricted through administrator configuration. The reference identifier for the syslog server is configured by the administrator using the available administrative commands in the CLI. The reference identifiers must be an IPv4 address, IPv6 address, or a hostname. When the reference identifier is a hostname, the TOE compares the hostname against all of the dNSName entries in the Subject Alternative Name extension. If the hostname does not match any of the dNSName entries, then the verification fails. If the certificate does not 38 TOE SFR Rationale contain any dNSName entries, the TSF will compare the hostname against the Common Name (CN). If the hostname does not match the CN, then the verification fails. For both dNSName and CN matching, the hostname must be an exact match or wildcard match. In the case of a wildcard match; the wildcard must be the left-most component, wildcard matches a single component, and there are at least two non-wildcard components. When the reference identifier is an IP address, the TOE converts the IP address to a binary representation in network byte order. IPv4 addresses are converted directly from decimal to binary, IPv6 addresses are converted as specified in RFC 5952. The TOE compares the binary IP address against all of the iPAddress entries in the Subject Alternative Name extension. If there is not an exact binary match, then the verification fails. The TLS channel is terminated if verification fails. The TOE does not support certificate pinning. The syslog TLS client will transmit the Supported Elliptic Curves extension in the Client Hello message by default with support for the following NIST curves: secp256r1, secp384r1, and secp521r1. The non-TOE server can choose to negotiate the elliptic curve from this set for any of the mutually negotiable elliptic curve ciphersuites no additional configuration is required. The TOE also supports key agreement using the server’s RSA public key or DHG14 (2048 bits). FCS_TLSS_EXT.1 The TOE has a single trusted path over the remote web GUI which acts as a TLS server. The server only allows TLS protocol versions 1.1 and 1.2 (rejecting any other protocol version, including SSL 2.0, SSL 3.0 and TLS 1.0 and any other unknown TLS version string supplied) and is restricted to the following ciphersuites by default: • TLS_RSA_WITH_AES_128_CBC_SHA • 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_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA Ciphersuites can be restricted through administrator configuration. The TLS server is capable of negotiating ciphersuites that include RSA, DHE, and ECDHE key agreement schemes. The RSA key agreement parameters are provided by the associated RSA certificate loaded to the server. The server certificate is restricted to 39 TOE SFR Rationale being 2048 bits or 3072 bits. The DHE key agreement parameters are restricted to DHG14 (2048 bits) and are hardcoded into the server. The ECDHE key agreement parameters are restricted to secp256r1, secp384r1, and secp521r1. The TOE supports session resumption of the single HTTPS context using session tickets. Session tickets are structured as specified in Section 4 of RFC 5077 and encrypted using AES with a 128-bit key. FIA_AFL.1 The TOE is capable of tracking authentication failures for each of the claimed authentication mechanisms (username/password, SSH public key). The administrator can configure the maximum number of failed attempts using the CLI interface via the aaa authentication attempts command. The configurable range is between 1 and 4,294,967,295 attempts (e.g. a 32-bit integer). When a user account has sequentially failed authentication the configured number of times, the account will be locked. The locking mechanism can be configured to remain locked until an administrator unlocks the account, or it can be configured to unlock after a specified period of time. If the administrator is required to intervene to unlock an account, this is done using the CLI via the aaa authentication attempts reset CLI command. The aaa authentication attempts commands apply to authentication attempts through both SSH and the GUI. The failed authentication lockout does not apply to the local console, ensuring administrative access is always available. If the unlocking mechanism is automatically applied after a specified time period, then the user account will be unlocked when the specified number of seconds have elapsed since the locking mechanism was engaged. Irrespective of whether an administrator intervened or whether the elapsed time occurred, when a locked account is unlocked, the failure counter associated with that user is reset to 0. If a user succeeds at authenticating before the locking mechanism has been enabled, the failure counter is reset to 0. If the lockout attempts is set to, for example, 5 attempts, then the user will be locked out after the 5th consecutive failed login attempt. This means that the 6th and subsequent attempts will fail to gain access to the TOE even if the credential being offered is correct. 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 and can range from 15 to 32 characters. FIA_UIA_EXT.1 FIA_UAU_EXT.2 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 each TOE appliance • Remotely connecting to each appliance via SSHv2 • Remotely connecting to appliance GUI via HTTPS/TLS Regardless of the interface at which the administrator interacts, the TOE prompts the user for a credential. Only after the administrative user presents the correct authentication 40 TOE SFR Rationale credentials will they be granted access to the TOE administrative functionality. No TOE administrative access is permitted 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 administrative user is prompted to provide a username. After the user provides the username, the user is prompted to provide the administrative credential associated with the user account (e.g., password or SSH public/private key response). The TOE then either grants administrative access (if the combination of username and credential is correct) or indicates that the login was unsuccessful. The TOE does not provide a reason for failure in the cases of a login failure. The TOE does not permit any administrative function to be accessible until after an administrator is successfully identified and authenticated. FIA_UAU.7 For all authentication at the local CLI the TOE does not echo any characters when the administrative password is entered so that the password is obscured. FIA_X509_EXT.1/Rev FIA_X509_EXT.2 FIA_X509_EXT.3 The TOE performs X.509 certificate validation at the following points: • TOE TLS client authentication of server X.509 certificates; • When certificates are loaded into the TOE, such as when importing CAs, certificate responses and other device-level certificates (such as the web server certificate presented by the TOE TLS web GUI). In all scenarios, certificates are checked for several validation characteristics: • If the certificate ‘notAfter’ date is in the past, then this is an expired certificate which is considered invalid; • If the certificate ‘notBefore’ date is in the future, then the certificate is considered invalid; • The certificate chain must terminate with a trusted CA certificate; • Server certificates consumed by the TOE TLS client must have a ‘serverAuthentication’ extendedKeyUsage purpose; A trusted CA certificate is defined as any certificate loaded into the TOE trust store that has, at a minimum, a basicConstraints extension with the CA flag set to TRUE. Certificate revocation checking is performed using OCSP responders. The OCSP signing certificate must have the OCSP signing purpose in the extendedKeyUsage extension. As X.509 certificates are not used for either trusted updates or firmware integrity self-tests, the code-signing purpose is not checked for in the extendedKeyUsage. The TOE has a trust store where root CA and intermediate CA certificates can be stored. The trust store is not cached: if a certificate is deleted, it is immediately untrusted. If a certificate is added to the trust store, it is immediately trusted for its given scope. The TOE compares each certificate presented as part of a communication to every certificate included in the trust store. If the presented certificate matches a certificate chain included in the trust store, the connection is validated and allowed to proceed. If a presented certificate does not match a certificate chain within the trust store, the connection is immediately rejected. 41 TOE SFR Rationale The X.509 certificates for each of the given scenarios 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 If, during the entire trust chain verification activity, any certificate under review fails a verification check, then the entire trust chain is deemed untrusted and the TLS connection is terminated. As part of the verification process, OCSP is used to determine whether the certificate is revoked or not. If the OCSP responder cannot be contacted, then the TOE will choose to automatically reject the certificate in this case. Instructions for configuring the trusted IT entities to supply appropriate X.509 certificates are captured in the guidance documents. The TOE is capable of generating certificate signing requests (CSRs). The user can select the size of the key as 2048 or 3072 bits. In addition to adding the public key to the certificate details, the user can provide information for the Common Name, Organization, Organizational Unit, and Country. No device-specific details are collected and added to the certificate request to be signed. FMT_MOF.1/FunctionsThe TOE restricts the ability to modify the behavior of transmission of audit data to an external IT entity (OCSP responder, TLS ciphersuites), handling of audit data (number of logs to retain) to Security Administrators. FMT_MOF.1/ManualU pdate The TOE restricts the ability to perform software updates to the Admin role. FMT_MTD.1/CoreData The TOE implements role-based access control. Administrative users are required to login before being provided with access to any administrative functions. The TOE supports several types of administrative user roles. Collectively these sub-roles comprise the Security 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. 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, 42 TOE SFR Rationale to grant access to the privileged and semi-privileged levels. The term “Security 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. Users without the appropriate privilege level do not have access to TOE functionality including administration of X.509 certificates. FMT_SMF.1 The TOE may be managed via the CLI (console & SSH) or GUI (HTTPS). The specific management capabilities include: • Ability to administer the TOE locally (CLI); • Ability to administer the TOE remotely (GUI & CLI); • Ability to configure the access banner (GUI & CLI); • Ability to configure the session inactivity time before session termination (CLI); • Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates (CLI); • Ability to configure the authentication failure parameters (CLI); • Ability to modify the behavior of the transmission of audit data to an external IT entity and the handling of local audit data; • Ability to configure the cryptographic functionality; • Ability to re-enable an Administrator account (CLI); • Ability to set the time which is used for time-stamps; • Ability to configure NTP; • Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors; • Ability to import X.509v3 certificates to the TOE's trust store. FMT_SMR.2 See FMT_MTD.1/CoreData. FPT_APW_EXT.1 The TOE stores Security Administrator passwords. 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_SKP_EXT.1 The TOE stores all private keys in a secure directory that is not readily accessible to administrators; hence no interface access. Refer to section 6.1 for key storage details. 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 on start-up, and whenever the system images are loaded. A hash verification is used to confirm the image file to be loaded has not been corrupted and has maintained its integrity. These tests are sufficient to verify that the correct version of the TOE software is running as well as that the cryptographic operations are all performing as expected. Both of these functions are required to ensure that the TOE is operating as expected and data that the user expects to be encrypted in not transferred in plaintext. FPT_TUD_EXT.1 The Security Administrator can query the software version running on the TOE and the most recently downloaded software version. When software updates are made available by FireEye the Security Administrator can obtain, verify the integrity of, and install those 43 TOE SFR Rationale updates. Software updates are downloaded to the TOE via an fenet image fetch command on the CLI. Software images will not be installed without explicit administrative intervention. The TOE image files are digitally signed (2048-bit RSA/SHA-256) so their integrity can be verified during the upgrade process. An image that fails an integrity check will not be installed. Once the image is installed, it remains inactive until the TOE is rebooted from the image. FPT_STM_EXT.1 The clock function is reliant on the system clock provided by the underlying hardware. 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. The time can be manually updated by a Security Administrator or automatically updated using NTP synchronization. FTA_SSL_EXT.1 FTA_SSL.3 A Security Administrator can configure maximum inactivity times for administrative sessions through the TOE GUI and CLI interfaces. The configuration of inactivity periods can be configured to be anywhere from 0.25-35791 minutes and are applied on a per user interface basis. A configured inactivity period will be applied to both local and remote sessions in the same manner. When the interface has been idle for more than the configured period of time, the session will be terminated and will require authentication to establish a new session. FTA_SSL.4 A Security Administrator is able to exit out of both local and remote administrative sessions. FTA_TAB.1 Security Administrators can define a custom login banner that will be displayed at the following interfaces: • Local CLI • Remote CLI • Remote GUI This banner will be displayed prior to allowing Security Administrator access through those interfaces. FTP_ITC.1 The TOE supports communications with several types of authorized IT entities, including: • Audit Servers This connection is protected via a TLS connection (the TOE acts as a TLS client). This protects the data from disclosure by encryption using AES and by HMACs that verify that data has not been modified. TLS provides assured identification of the non-TSF endpoint by validating X.509 certificates. The TOE retains a trusted store of certificate authorities which it uses to verify digital signatures on those non-TSF certificates. The TOE is responsible for initiating the trusted channel with the external trusted IT entities. FTP_TRP.1/Admin 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 to protect confidentiality and uses HMACs to protect integrity of traffic. Remote GUI connections take place over a TLS connection. The TLS session is encrypted using AES encryption and uses HMACs to protect integrity. The remote administrators can initiate both SSHv2 and TLS communications with the TOE. Table 18 TOE Summary Specification SFR Description 44 6.1 Key Storage and Zeroization The following table describes the origin, storage and zeroization of keys as relevant to FCS_CKM.4 and FPT_SKP_EXT.1 provided by the TOE. Key Type Origin Storage/Protection Zeroization Diffie Hellman private key DH Key TOE generated RAM Keys are overwritten with zeros when session closes. Diffie Hellman public key DH Key TOE generated RAM Keys are overwritten with zeros when session closes. SSH Private Key RSA Private Key TOE generated ACL protected directory Key is overwritten by zeros when the compliance declassify zeroize command is issued. SSH Public Key RSA Public Key TOE generated n/a - public Key is overwritten by zeros when the compliance declassify zeroize command is issued. FW Integrity Public Key RSA Public Key Installed with TOE software n/a - public Key is overwritten by zeros when the compliance declassify zeroize command is issued. SSH Session Key AES Key TOE generated RAM Keys are overwritten with zeros when session closes. TLS Private Key RSA Private Key TOE generated ACL protected directory Key is overwritten by zeros when the compliance declassify zeroize command is issued. TLS Private Key ECDSA Private Key Administrator Configured ACL protected directory Key is overwritten by zeros when the compliance declassify zeroize command is issued. TLS Public Key RSA Public Key TOE generated n/a - public Key is overwritten by zeros when the compliance declassify zeroize command is issued. TLS Public Key ECDSA Public Key Administrator Configured n/a - public Key is overwritten by zeros when the compliance declassify zeroize command is issued. TLS Session Encryption Key AES Key TOE generated RAM Keys are overwritten with zeros when session closes. TLS Session Integrity Key HMAC Key TOE generated RAM Keys are overwritten with zeros when session closes. NTP Key NTP Key Administrator Configured ACL protected directory Key is overwritten by zeros when the compliance declassify zeroize command is issued. Table 19 Key Storage & Zeroization Non-volatile keys are overwritten with zeros using a single pass when the administrator disables CC mode. As part of the disablement function, the device is power cycled to zeroize keys in volatile memory. 45 7 Terms and Definitions Abbreviations/Acronyms Description AEAD Authenticated Encryption with Associated Data AES Advanced Encryption Standard API Application Programming Interface ASLR Address Space Layout Randomization CA Certificate Authority CBC Cipher Block Chain CM Configuration Management CMC CBC-mask-CBC CN Common Name CO Cryptographic Officer COTS Commercial off the Shelf CRL Certificate Revocation List CTR Counter (mode) DEP Data Executable Prevention DFB Distributed Feedback DHE Diffie-Hellman Ephemeral DN Distinguished Name DNS Domain Name Service DMZ Demilitarized Zone DoD Department of Defense DRBG Deterministic Random Bit Generator DSS Digital Signature Standard DVI Digital Video Interface DWDM Dense Wave Division Multiplexing ECB Electronic Codebook (mode) ECC Elliptic Curve Cryptography ECDHE Elliptic Curve Diffie-Hellman Ephemeral ECDSA Elliptic Curve Digital Signature Algorithm FFC Finite Field Cryptography FIPS Federal Information Processing Standards FQDN Fully Qualified Domain Name FTPS File Transfer Protocol Secure Gb Gigabit GCM Galois/Counter Mode HDMI High Density Multimedia Interface HID Human Interface Device HMAC Hash-based Message Authentication Code HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure I/O Input / Output IAW In Accordance With IEC International Electrotechnical Commission IKE Internet Key Exchange IP Internet Protocol IPTV IP Television IPX Internet Protocol Crosspoint ISO International Organization for Standardization IT Information Technology 46 Abbreviations/Acronyms Description km Kilometer(s) LAN Local Area Network LDAP Lightweight Directory Access Protocol MAC Message Authentication Code max Maximum NIST National Institute of Standards and Technology NLE Non Linear Editor, Non Linear Editing nm Nanometer(s) NMS Network Management System NSA National Security Agency NTP Network Time Protocol OCSP Online Certificate Status Protocol OE Operational Environment OID Object Identifier OS Operating System PKCS Public-Key Cryptography Standards POST Power On Self-Test PPS Ports. Protocols, and Services PSS Probabilistic Signature Scheme RA Registration Authority RBAC Role Based Access Control RFC Request For Comment RJ-45 Registered Jack (45) RS-232 Recommended Standard 232 RSA Rivest-Shamir-Adelman RU Rack Unit (1.75”) SAN Subject Alternative Name SDI Serial Digital Interface SDVN Software Defined Video Networking SFP Small Form-Factor Pluggable SHA Secure Hash Algorithm SHS Secure Hash Standard SMF Single Mode Fiber SMTP Simple Mail Transport Protocol SNMP Simple Network Management Protocol SPD Security Policy Database SQL Structured Query Language SSH Secure Shell SSL Secure Sockets Layer TCP Transmission Control Protocol TLS Transport Layer Security TRNG True Random Number Generator UDP User Datagram Protocol URI Uniform Resource Identifier URL Uniform Resource Locator USB Universal Serial Bus VGA Video Graphics Array VLAN Virtual Local Area Network WAN Wide Area Network 47 Abbreviations/Acronyms Description WLAN Wireless Local Area Network WRT With Respect To Table 20 TOE Abbreviations and Acronyms Abbreviations/Acronyms Description CC Common Criteria CCRA Arrangement on the Recognition of Common Criteria Certificates in the field of IT Security CCUF Common Criteria Users Forum EAR Entropy Assessment Report ECD Extended Components Definition iTC International Technical Community NDcPP Network Device collaborative Protection Profile NIAP National Information Assurance Partnership NIT Network Interpretation Team OSP Organizational Security Policy PP Protection Profile PPAS Protection Profile for Application Security RfI Request for Interpretation SAR Security Assurance Requirement SFR Security Functional Requirement SFP Security Function Policy SPD Security Problem Definition ST Security Target TD Technical Decision TR Technical Recommendation TOE Target of Evaluation TRRT Technical Rapid Response Team TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification Table 21 CC Abbreviations and Acronyms 48 End of Document