FireEye EX Series: EX3500,

EX5500, EX8400, EX8500

FireEye, Inc.
FIPS 140-2 Non-Proprietary Security Policy
Document Version: 1.0

Prepared By:
Acumen Security
2400 Research Blvd, Suite 395
Rockville, MD 20850

www.acumensecurity.net
 Table of Contents

1. Introduction .............................................................................................................................................................. 4
1.1 Purpose ............................................................................................................................................................... 4
1.2 Document Organization ...................................................................................................................................... 4
1.3 Notices ................................................................................................................................................................ 4
2. FireEye EX Series: EX3500, EX5500, EX8400, EX8500 ................................................................................................ 5
2.1 Cryptographic Module Specification ................................................................................................................... 6
2.1.1 Cryptographic Boundary .............................................................................................................................. 6
2.2 Cryptographic Module Ports and Interfaces ..................................................................................................... 10
2.3 Roles, Services, and Authentication .................................................................................................................. 12
2.3.1 Authorized Roles........................................................................................................................................ 12
2.3.2 Authentication Mechanisms ...................................................................................................................... 12
2.3.3 Services ...................................................................................................................................................... 15
2.4 Physical Security ............................................................................................................................................... 20
2.5 Cryptographic Key Management ...................................................................................................................... 21
2.6 Cryptographic Algorithm ................................................................................................................................... 24
2.6.1 FIPS-approved Algorithms ......................................................................................................................... 24
2.6.2 Non-Approved Algorithms Allowed for Use With FIPS-approved services................................................. 27
2.6.3 Non-Approved Algorithms Disallowed for Use With FIPS-approved services ............................................ 28
2.7 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC)...................................................... 29
2.8 Self-Tests........................................................................................................................................................... 30
2.8.1 Power-On Self-Tests .................................................................................................................................. 30
2.8.2 Conditional Self-Tests ................................................................................................................................ 30
2.8.3 Self-Tests Error Handling ........................................................................................................................... 30
2.9 Mitigation of Other Attacks .............................................................................................................................. 31
3. Secure Operation..................................................................................................................................................... 32
3.1 Modes of Operation .......................................................................................................................................... 32
3.2 Installation ........................................................................................................................................................ 32
3.3 Initialization ...................................................................................................................................................... 32
3.3.1 Default Authentication .................................................................................................................................. 32
 3.3.2 Enable compliance configuration options ..................................................................................................... 32
3.3.3 Enable FIPS 140-2 compliance ....................................................................................................................... 32
3.4 Management .................................................................................................................................................... 33
3.4.1 SSH Usage .................................................................................................................................................. 33
3.4.1.1 Symmetric Encryption Algorithms: ......................................................................................................... 33
3.4.1.2 KEX Algorithms: ...................................................................................................................................... 33
3.4.1.3 Message Authentication Code (MAC) Algorithms: ................................................................................. 33
3.4.2 TLS Usage ................................................................................................................................................... 33
3.4.3 SNMP Usage .............................................................................................................................................. 34
3.5 Secure Delivery ................................................................................................................................................. 34
3.6 Switching Modes of operation .......................................................................................................................... 35
3.7 Additional Information...................................................................................................................................... 35
Appendix A: Acronyms .................................................................................................................................................... 36
 1. Introduction
This is a non-proprietary FIPS 140-2 Security Policy for the FireEye EX Series: EX3500, EX5500, EX8400, EX8500. Below
are the details of the product validated:

• Hardware Version: EX3500, EX5500, EX8400, EX8500

• Firmware Version #: 9.0.3
• FIPS 140-2 Security Level: 1

1.1 Purpose
This document was prepared as Federal Information Processing Standard (FIPS) 140-2 validation evidence. The
document describes how the FireEye EX Series: EX3500, EX5500, EX8400, and EX8500 meets the security requirements
of FIPS 140-2. It also provides instructions to individuals and organizations on how to deploy the product in a secure
FIPS-approved mode of operation. Target audience of this document is anyone who wishes to use or integrate this
product into a solution that is meant to comply with FIPS 140-2 requirements.

1.2 Document Organization

The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the
Submission Package contains:

▪ Vendor Evidence document

▪ Finite State Machine
▪ Other supporting documentation as additional references

This Security Policy and the other validation submission documentation were produced by Acumen Security, LLC.
under contract to FireEye, Inc. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission
Package is proprietary to FireEye, Inc. and is releasable only under appropriate non-disclosure agreements.

1.3 Notices
This document may be freely reproduced and distributed in its entirety without modification.
 2. FireEye EX Series: EX3500, EX5500, EX8400, EX8500
The FireEye EX Series: EX3500, EX5500, EX8400, EX8500 (the module) is a multi-chip standalone module validated at
FIPS 140-2 Security Level 1. Specifically, the module meets the following security levels for individual sections in the
FIPS 140-2 standard:

Table 1 - Security Level for Each FIPS 140-2 Section

# Section Title Security Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 3
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A
7 Cryptographic Key Management 1
8 EMI/EMC 1
9 Self-Tests 1
10 Design Assurances 3
11 Mitigation Of Other Attacks N/A
 2.1 Cryptographic Module Specification
The FireEye EX series secures against advanced email attacks. As part of the FireEye Threat Prevention Platform, the
FireEye EX uses signature-less technology to analyze every email attachment and successfully quarantine spear-
phishing emails used in advanced targeted attacks.

With all the personal information available online, a cybercriminal can socially engineer almost any user into clicking a
URL or opening an attachment. The FireEye EX series provides real-time threat prevention for spear-phishing attacks
that evade traditional defenses. The EX also delivers a new level of threat prevention against blended attacks by
working with the FireEye NX platform to quarantine emails with malicious URLs and trace Web-based attacks back to
the original spear-phishing email.

2.1.1 Cryptographic Boundary

The cryptographic boundary for the module is defined as encompassing the "top," "front," "left," "right," and
"bottom" surfaces of the case and all portions of the "backplane" of the case. The following figures provide a physical
depiction of the cryptographic module.

Figure 1: FireEye EX3500 (Front Panel)

Figure 2: FireEye EX3500 (Front Panel (Chassis) without Bezel)

 Figure 3: FireEye EX5500 (Front Panel)

Figure 4: FireEye EX5500 (Rear Panel)

Figure 5: FireEye EX8400 (Front Panel)

Figure 6: FireEye EX8400 (Rear Panel)

Figure 7: FireEye EX8500 (Front Panel)

Figure 8: FireEye EX8500 (Rear Panel)
 2.2 Cryptographic Module Ports and Interfaces
The module provides a number of physical and logical interfaces to the device, and the physical interfaces provided by
the module are mapped to four FIPS 140-2 defined logical interfaces: data input, data output, control input, and status
output. The logical interfaces and their mapping are described in the following table:

Table 2 - Module Interface Mapping – EX3500/EX5500/EX8400/EX8500

FIPS Interface Physical Interface
Data Input 10/100/1000 BASE-T Management Port (EX3500 (1x), EX5500 (1x), EX8400 (2x),
EX8500 (1x))
10/100/1000 BASE-T Monitoring Ports (EX3500 (3x), EX5500 (3x), EX8400 (2x),
EX8500 (3x))
(4x) SFP+ Ports (EX8500)
(1x) 100 BASE-T Management Port (IPMI)
(2x) USB 2.0 Ports
(2x) USB 3.0 Ports (EX3500, EX5500, EX8500)
(1x) PS/2 Mouse Port (EX8400)
(1x) PS/2 Keyboard Port (EX8400)
(1x) Serial Port
Data Output 10/100/1000 BASE-T Management Port (EX3500 (1x), EX5500 (1x), EX8400 (2x),
EX8500 (1x))
10/100/1000 BASE-T Monitoring Ports (EX3500 (3x), EX5500 (3x), EX8400 (2x),
EX8500 (3x))
(4x) SFP+ Ports (EX8500)
(1x) 100 BASE-T Management Port (IPMI)
(1x) Video Port
(2x) USB 2.0 Ports
(2x) USB 3.0 Ports (EX3500, EX5500, EX8500)
(1x) Serial Port
Control Input 10/100/1000 BASE-T Management Port (EX3500 (1x), EX5500 (1x), EX8400 (2x),
EX8500 (1x))
(1x) 100 BASE-T Management Port (IPMI)
(2x) USB 2.0 Ports
(2x) USB 3.0 Ports (EX3500, EX5500, EX8500)
(1x) PS/2 Mouse Port (EX8400)
(1x) PS/2 Keyboard Port (EX8400)
(1x) Serial Port
(1x) Power Button
(1x) Reset Button (EX3500, EX5500, EX8500)
Status Output 10/100/1000 BASE-T Management Port (EX3500 (1x), EX5500 (1x), EX8400 (2x),
EX8500 (1x))
(1x) 100 BASE-T Management Port (IPMI)
(1x) Video Port
(2x) USB 2.0 Ports
 FIPS Interface Physical Interface
(2x) USB 3.0 Ports (EX3500, EX5500, EX8500)
(1x) Serial Port
LEDs (EX3500 (5x), EX5500 (5x), EX8400 (4x), EX8500 (5x))
Power Interface (2x) Power Ports
 2.3 Roles, Services, and Authentication
The following sections provide details about roles supported by the module, how these roles are authenticated and
the services the roles are authorized to access.

2.3.1 Authorized Roles

The module supports several different roles, including multiple Cryptographic Officer roles and a User role. The
module does not support a maintenance role and/or bypass capability.

Configuration of the module can occur over several interfaces and at different levels depending upon the role assigned
to the user. There are multiple types of Cryptographic Officers that may configure the module, as follows:

• 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.
• SNMP: The SNMP role provides system monitoring through SNMPv3.
• WSAPI: The WSAPI role supports system administration via a TLS authenticated interface.

The Users of the module are the remote IT devices and remote management clients accessing the module via
cryptographic protocols. These protocols include, SSH, TLS, and SNMPv3.

Unauthenticated users are only able to access the module LEDs and power cycle the module.

2.3.2 Authentication Mechanisms

The module supports identity-based authentication. Module operators must authenticate to the module before being
allowed access to services, which require the assumption of an authorized role. The module employs the
authentication methods described in the table below to authenticate Crypto-Officers and Users.

Table 3 - Authentication Mechanism Details

Role Type Of Authentication Authentication Strength
Admin Password/Username All passwords must be between 8 and 32
characters. The passwords can consist of
alphanumeric values, {a-z, A-Z, 0-9, and special
characters}, the characters can thus be chosen
Monitor
from the 94 human readable ASCII characters on
Operator
an American QWERTY computer keyboard. Thus,
Analyst
the probability of a successful random attempt is
Auditor
 Role Type Of Authentication Authentication Strength
SNMP 1/94^8 , which is less than 1 in 1,000,000. In the
worst-case scenario, if (8) integers are used for an
eight-digit password, the probability of randomly
guessing the correct sequence is one (1) in
WSAPI
100,000,000 (this calculation is based on the
assumption that the typical standard American
QWERTY computer keyboard has 10 Integer digits.
The calculation should be 10 ^ 8 = 100,000,000).
Therefore, the associated probability of a
successful random attempt is approximately 1 in
100,000,000, which again is less than 1 in
1,000,000 required by FIPS 140-2.

The module enforces a timed access mechanism as

follows: For the first five failed attempts (assuming
0 time to process), no timed access is enforced.
Upon the sixth attempt, the module enforces a 15-
second delay. For the seventh and eight attempts
again, no timed access is enforced. Thereafter this
cycle repeats, i.e., every third failed attempt, the
module enforces a 15-second delay. This would
allow the attacker to perform roughly 15 attempts
per minute. The probability of a success with
multiple consecutive attempts in a one-minute
period is 15/(94^8) (or 15/(10^8) in the worst
case), which is less than 1/1,000,000.
User Password/Username or All passwords must be between 8 and 32
Asymmetric Authentication characters. The passwords can consist of
alphanumeric values, {a-z, A-Z, 0-9, and special
characters}, the characters can thus be chosen
from the 94 human readable ASCII characters on
an American QWERTY computer keyboard. Thus,
the probability of a successful random attempt is
1/94^8 , which is less than 1 in 1,000,000. In the
worst-case scenario, if (8) integers are used for an
eight-digit password, the probability of randomly
guessing the correct sequence is one (1) in
100,000,000 (this calculation is based on the
assumption that the typical standard American
QWERTY computer keyboard has 10 Integer digits.
The calculation should be 10^8 = 100,000,000).
Therefore, the associated probability of a
Role Type Of Authentication Authentication Strength
successful random attempt is approximately 1 in
100,000,000, which again is less than 1 in
1,000,000 required by FIPS 140-2.

The module enforces a timed access mechanism as

follows: For the first five failed attempts (assuming
0 time to process), no timed access is enforced.
Upon the sixth attempt, the module enforces a 15-
second delay. For the seventh and eight attempts
again, no timed access is enforced. Thereafter this
cycle repeats, i.e., every third failed attempt, the
module enforces a 15-second delay. This would
allow the attacker to perform roughly 15 attempts
per minute. The probability of a success with
multiple consecutive attempts in a one-minute
period is 15/(94^8) (or 15/(10^8) in the worst
case), which is less than 1/1,000,000.

When using RSA based authentication, RSA key

pair has modulus size of 2048 bit, thus providing
112 bits of strength. Therefore, an attacker would
have a 1 in 2^112 chance of randomly obtaining
the key, which is much stronger than the one in a
million chance, required by FIPS 140-2.

For RSA-based authentication, to exceed a 1 in

100,000 probability of a successful random key
guess in one minute, an attacker would have to be
capable of approximately 5.19x10^28 attempts per
minute. In the worst-case scenario, an operator
can make 60 failed attempts per minute.
 2.3.3 Services
The services that require operators to assume an authorized role (Crypto-Officer or User) are
listed in the table below. Please note that the keys and Critical Security Parameters (CSPs) listed
below use the following indicators to show the type of access required:
• R (Read): The CSP is read
• W (Write): The CSP is established, generated, modified, or zeroized
• Z (Zeroize): The CSP is zeroized

Table 4 – Services
Service Description Role Key/CSP and Type of Access
SSH to external Secure SSH User • DRBG entropy input (W/R)
IT device connection between • DRBG Seed (W/R)
a CM and other • DRBG V (R/W/Z)
FireEye appliances • DRBG Key (R/W/Z)
using SSH. • Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• SSH Private Key (R/W/Z)
• SSH Public Key (R/W/Z)
• SSH Session Key (R/W/Z)
• SSH Integrity Key (R/W/Z)
Administrative Secure remote CO • Admin Password (R/W/Z)
access over SSH command line • Monitor Password (R/W/Z)
appliance • Operator Password (R/W/Z)
administration over • Analyst Password (R/W/Z)
an SSH tunnel. • Auditor Password (R/W/Z)
• DRBG entropy input (W/R)
• DRBG Seed (W/R)
• DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• SSH Private Key (R/W/Z)
• SSH Public Key (R/W/Z)
• SSH Session Key (R/W/Z)
• SSH Integrity Key (R/W/Z)
Administrative Secure remote GUI CO • Admin Password (R/W/Z)
access over appliance • Monitor Password (R/W/Z)
webGUI administration over a • Operator Password (R/W/Z)
TLS tunnel. • Analyst Password (R/W/Z)
FIPS 140-2 Security Policy v1.3

Service Description Role Key/CSP and Type of Access

• Auditor Password (R/W/Z)
• DRBG entropy input (W/R)
• DRBG Seed (W/R)
• DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
Administrative Secure remote CO • WSAPI Password (R/W/Z)
access over appliance • DRBG entropy input (W/R)
WSAPI administration over a • DRBG Seed (W/R)
TLS tunnel. • DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
Administrative Directly connected CO • Admin Password (R/W/Z)
access over command line • Monitor Password (R/W/Z)
serial console appliance • Operator Password (R/W/Z)
and VGA administration. • Analyst Password (R/W/Z)
• Auditor Password (R/W/Z)
SNMPv3 Secure remote CO • SNMP Session Key (R/W/Z)
SNMPv3-based • SNMPv3 password (R/W/Z)
system monitoring.
DTI connection TLS-based User • DRBG entropy input (W/R)
connection used to • DRBG Seed (W/R)
upload data to the • DRBG V (R/W/Z)
FireEye cloud. • DRBG Key (R/W/Z)

16
FIPS 140-2 Security Policy v1.3

Service Description Role Key/CSP and Type of Access

• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
LDAP over TLS Secure remote User • Admin Password (R/W/Z)
authentication via • Monitor Password (R/W/Z)
TLS protected LDAP • Operator Password (R/W/Z)
• Analyst Password (R/W/Z)
• Auditor Password (R/W/Z)
• DRBG entropy input (W/R)
• DRBG Seed (W/R)
• DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
SAML over TLS Secure remote User • Admin Password (R/W/Z)
(Web GUI) authentication to the • Monitor Password (R/W/Z)
Web GUI via TLS • Operator Password (R/W/Z)
protected SAML • Analyst Password (R/W/Z)
• Auditor Password (R/W/Z)
• DRBG entropy input (W/R)
• DRBG Seed (W/R)
• DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)

17
FIPS 140-2 Security Policy v1.3

Service Description Role Key/CSP and Type of Access

• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
Secure log TLS-based User • DRBG entropy input (W/R)
transfer connection with a • DRBG Seed (W/R)
remote audit server. • DRBG V (R/W/Z)
• DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
• TLS Session Integrity Key (R/W/Z)
TLS to external Secure connection User • DRBG entropy input (W/R)
IT device between a CM and • DRBG Seed (W/R)
other FireEye • DRBG V (R/W/Z)
appliances using TLS. • DRBG Key (R/W/Z)
• Diffie-Hellman Shared Secret (R/W/Z)
• Diffie Hellman private key (R/W/Z)
• Diffie Hellman public key (R/W/Z)
• TLS Private Key (R/W/Z)
• TLS Public Key (R/W/Z)
• TLS Pre-Master Secret (R/W/Z)
• TLS Master Secret (R/W/Z)
• TLS Session Encryption Key (R/W/Z)
Show Status View the operational CO N/A
status of the module
Perform Self- Perform the FIPS 140 CO N/A
Tests start-up tests on
demand
Status LED View status via the Un- N/A
Output Modules LEDs. auth
Cycle Power Reboot of appliance. Un- • DRBG entropy input (Z)
auth • DRBG Seed (Z)
• DRBG V (Z)

18
FIPS 140-2 Security Policy v1.3

Service Description Role Key/CSP and Type of Access

• DRBG Key (Z)
• Diffie-Hellman Shared Secret (Z)
• Diffie Hellman private key (Z)
• Diffie Hellman public key (Z)
• SSH Session Key (Z)
• SSH Integrity Key (Z)
• SNMPv3 session key (Z)
• TLS Pre-Master Secret (Z)
• TLS Master Secret (Z)
• TLS Session Encryption Key (Z)
• TLS Session Integrity Key (Z)
Zeroization via Perform zeroization CO • Admin Password (Z)
“compliance of all persistent CSPs • Monitor Password (Z)
declassify within the module • Operator Password (Z)
zeroize” • Analyst Password (Z)
Command • Auditor Password (Z)
• WSAPI Password (Z)
• SSH Private Key (Z)
• SSH Public Key (Z)
• SNMPv3 password (Z)
• TLS Private Key (Z)
• TLS Public Key (Z)
R – Read, W – Write, Z – Zeroize

19
FIPS 140-2 Security Policy v1.3

2.4 Physical Security

The modules are production grade multi-chip standalone cryptographic modules that meet
Level 1 physical security requirements.

20
 2.5 Cryptographic Key Management
The following table identifies each of the CSPs associated with the module. For each CSP, the following information is provided:
• The name of the CSP/Key
• The type of CSP and associated length
• A description of the CSP/Key
• Storage of the CSP/Key
• The zeroization for the CSP/Key

Table 5 - Details of Cryptographic Keys and CSPs

Key/CSP Type Description Storage Zeroization
DRBG entropy CTR 256-bit,HMAC- This is the entropy for SP 800-90 RNG. DRAM Device power cycle.
input SHA-512
DRBG Seed CTR 256-bit, HMAC- Seed material used to seed or reseed the DRBG. DRAM Device power cycle.
SHA-512
DRBG V CTR 256-bit, HMAC- Internal V value used as part of SP DRAM Device power cycle.
SHA-512 800-90 CTR_DRBG, HMAC_DRBG.
DRBG Key CTR 256-bit, HMAC- Internal Key value used as part of SP DRAM Device power cycle.
SHA-512 800-90 CTR_DRBG, HMAC_DRBG.
Diffie-Hellman DH 2048 – 4096 bits The shared exponent used in Diffie-Hellman (DH) DRAM Device power cycle.
Shared Secret exchange. Created per the Diffie-Hellman
protocol.
Diffie Hellman DH (DSA) 2048 – The private exponent used in Diffie-Hellman (DH) DRAM Device power cycle.
private key 4096 bits exchange.

Diffie Hellman DH 2048 – 4096 bits The p used in Diffie-Hellman (DH) exchange. DRAM Device power cycle.
public key
EC Diffie-Hellman ECDH P-256, P-384, The shared secret used in the EC Diffie-Hellman DRAM Device power cycle.
Shared Secret P-521 (ECDH) exchange.
EC Diffie Hellman ECDH P-256, P-384, The private key used in EC Diffie-Hellman (DH) DRAM Device power cycle.
private key P-521 exchange.
FIPS 140-2 Security Policy v1.3

Key/CSP Type Description Storage Zeroization

EC Diffie Hellman ECDH P-256, P-384, The public key used in EC Diffie-Hellman (DH) DRAM Device power cycle.
public key P-521 exchange.
SSH Private Key RSA (Private Key) The SSH private key for the module used for NVRAM Overwritten w/ “00”
2048 – 3072 bits session authentication. prior to replacement.
SSH Public Key RSA (Public Key) The SSH public key for the module used for session NVRAM Overwritten w/ “00”
2048 – 3072 bits authentication. prior to replacement.
SSH Session Key AES 128, 256 bits The SSH session key. This key is created through DRAM Device power cycle.
SSH key establishment.
SSH Integrity Key HMAC-SHA1, HMAC- The SSH data integrity key. This key is created DRAM Device power cycle.
SHA-256 through SSH key establishment.
HMAC-512
SNMPv3 password Shared Secret, at This secret is used to derive HMAC-SHA1 key for NVRAM Overwritten w/ “00”
least eight SNMPv3 Authentication. prior to replacement.
characters
SNMPv3 session AES 128 bits SNMP symmetric encryption key used to DRAM Device power cycle.
key encrypt/decrypt SNMP traffic.
TLS Private Key RSA (Private Key) This private key is used for TLS session NVRAM Overwritten w/ “00”
2048 – 3072 bits authentication. prior to replacement.
ECDSA (Private Key)
P-256 P-384 P-521
TLS Public Key RSA (Public Key) This public key is used for TLS session NVRAM Overwritten w/ “00”
2048 – 3072 bits authentication. prior to replacement.
ECDSA (Public Key)
P-256 P-384 P-521
TLS Pre-Master Shared Secret, 384 Shared Secret created using asymmetric DRAM Device power cycle.
Secret bits cryptography from which the TLS Master Secret
can be derived.

22
FIPS 140-2 Security Policy v1.3

Key/CSP Type Description Storage Zeroization

TLS Master Secret Shared Secret, 384 Shared Secret created using the TLS Pre-Master DRAM Device power cycle.
bits Secret from which new TLS session keys can be
created.
TLS Session Triple-DES 192-bits Key used to encrypt/decrypt TLS session data. DRAM Device power cycle.
Encryption Key
AES 128, 256 bits
TLS Session HMAC-SHA1 HMAC-SHA used for TLS data integrity protection. DRAM Device power cycle.
Integrity Key HMAC-SHA256
HMAC-SHA384
Admin Password Shared Secret, 8+ Authentication password for the Admin user role. NVRAM Overwritten w/ “00”
characters prior to replacement.
Monitor Password Shared Secret, 8+ Authentication password for the Monitor user NVRAM Overwritten w/ “00”
characters role. prior to replacement.
Operator Password Shared Secret, 8+ Authentication password for the Operator user NVRAM Overwritten w/ “00”
characters role. prior to replacement.
Analyst Password Shared Secret, 8+ Authentication password for the Analyst user role. NVRAM Overwritten w/ “00”
characters prior to replacement.
Auditor Password Shared Secret, 8+ Authentication password for the Audit user role. NVRAM Overwritten w/ “00”
characters prior to replacement.
WSAPI Password Shared Secret, 8+ Authentication password for the WSAPI user role. NVRAM Overwritten w/ “00”
characters prior to replacement.

23
 2.6 Cryptographic Algorithm
2.6.1 FIPS-approved Algorithms
The following table identifies the FIPS-approved algorithms included in the module for use in
the FIPS mode of operation.

Table 6 – FIPS-approved Algorithms

Algorithm CAVP Options Usage
Cert. #
Triple- C1720 TECB(KO 1 e/d), TCBC(KO 1 e/d) Used for
DES1 encryption of TLS
sessions.
KTS 112-bits (paired with HMAC Cert. #C1720)

Per SP800-67 rev2, the user is responsible for

ensuring the module’s limit to 2^20 encryptions
with the same Triple-DES key while being used
in the TLS protocol
TCFB1(KO 1 e/d); TCFB8 (KO 1 e/d); TCFB64(KO Implemented
1 e/d); TOFB(KO 1 e/d) within the module
however never
used by any service
AES C1720 ECB (e/d 128, 256); CBC (e/d 128, Used for
256); OFB (e/d 128); CTR (ext only; 128, 256 ) encryption of SSH,
SNMP, and TLS
GCM2 (KS: AES_128( e/d ) Tag Length(s): 128 sessions. Used in
120 112 104 96 64 32 ) (KS: AES_256( e/d ) Tag support of FIPS-
Length(s): 128 120 112 104 96 64 32 ) approved DRBG.
IV Generated: ( Internal (using Section 8.2.1 ) )
; PT Lengths Tested: ( 0 , 1024 ) ; AAD Lengths
tested: ( 1024 )
; 96BitIV_Supported GMAC_Supported

1
The operator shall ensure that the number of 64-bit blocks encrypted by the same key does not exceed
2^20 with a single Triple-DES key when Triple-DES is the encryption algorithm for TLS.
2
The module’s AES-GCM implementation conforms to IG A.5 scenario #1 following RFC 5288 for TLS and
RFC 5647 for SSH. Per RFC 5246, if the module is the party that encounters this condition it will trigger a
handshake to establish a new encryption key. Per RFC 5647 the module ensures that if the invocation
counter reaches its maximum value 2^64 – 1, the next AES GCM encryption is performed with the
invocation counter set to either 0 or 1, with a maximum of 2^64 – 1 encryptions per session.
FIPS 140-2 Security Policy v1.3

KTS 128, 256-bits (paired with HMAC Cert. #

C1720)

AES GCM is used as part of TLS 1.2 cipher suites

conformant to IG A.5, RFC 5288 and SP 800-52
and as part of SSHv2 cipher suites conformant
to IG A.5 and RFCs 4252, 4253 and 5647.
ECB (e/d 192); CBC (e/d 192); CFB1 (e/d 128, Implemented
192, 256 ); CFB8 (e/d 128, 192, 256); OFB (e/d within the module
192, 256); CTR (ext only; 192) however never
used by any service
CCM (KS: 128 , 192 , 256 ) (Assoc. Data Len
Range: 0 - 32 ) (Payload Length Range: 0 - 32
( Nonce Length(s): 7 13 (Tag Length(s): 4 16 )

GCM (KS: AES_192( e/d ) Tag Length(s): 128

120 112 104 96 64 32 )
HMAC- C1720 HMAC-SHA1 (Key Sizes Ranges Tested:KS=BS, Used for SSH and
SHS KS> BS, KS < BS) TLS traffic
HMAC-SHA256 ( Key Size Ranges Tested: integrity. Used in
KS=BS, KS> BS, KS < BS) support of SSH,
HMAC-SHA384 ( Key Size Ranges Tested: SNMP, and TLS key
KS=BS, KS> BS, KS < BS) derivation.
HMAC-SHA512 ( Key Size Ranges Tested:
KS=BS, KS> BS, KS < BS)

KTS HMAC-SHA1, HMAC-SHA256, HMAC-

SHA384 (paired with either AES cert. #C1720 or
Triple-DES Cert. # C1720)
HMAC-SHA224 ( Key Size Ranges Tested: Implemented
KS=BS, KS> BS, KS < BS) within the module
however never
used by any service
C1934 HMAC-SHA1 (Key Sizes Ranges Tested:KS=BS, Used in support of
KS> BS, KS < BS) random bit
HMAC-SHA256 ( Key Size Ranges Tested: generation.
KS=BS, KS> BS, KS < BS)
HMAC-SHA384 ( Key Size Ranges Tested:
KS=BS, KS> BS, KS < BS)
HMAC-SHA512 ( Key Size Ranges Tested:
KS=BS, KS> BS, KS < BS)

25
FIPS 140-2 Security Policy v1.3

SHS C1720 SHA-1 (BYTE-only) Used for SSH,

SHA-256 (BYTE-only) SNMP, and TLS
SHA-384 (BYTE-only) traffic integrity.
SHA-512 (BYTE-only) Used in support of
SSH, SNMP, and
TLS key derivation.
SHA-224 (BYTE-only) Implemented
within the module
however never
used by any service
C1720 SHA-256 (BYTE-only) Firmware load test
C1934 SHA-1 (BYTE-only) Used in support of
SHA-256 (BYTE-only) random bit
SHA-384 (BYTE-only) generation.
SHA-512 (BYTE-only)
RSA C1720 FIPS186-4: Used for SSH and
186-4KEY(gen): FIPS186-4_Fixed_e ( 10001 ) ; TLS Session
PGM(ProvPrimeCondition) (2048 SHA( 256 )) authentication.
(3072 SHA( 256 ))
ALG[ANSIX9.31] Sig(Gen): (3072 SHA( 256 , 384
, 512 ))
Sig(Ver): (1024 SHA( 1 , 256 , 384 , 512 )) (2048
SHA( 1 , 256 , 384 , 512 )) (3072 SHA( 1, 256 ,
384 , 512 )
ALG[RSASSA-PKCS1_V1_5] SIG(gen) (2048 SHA(
256 , 384 , 512 )) (3072 SHA( 256 , 384 , 512 ))
SIG(Ver) (1024 SHA( 1, 224 , 256 , 384 , 512 ))
(2048 SHA( 1 , 224 , 256 , 384 , 512 )) (3072
SHA( 1 , 224 , 256 , 384 , 512 ))
C1720 FIPS186-4: Firmware load test
ALG[RSASSA-PKCS1_V1_5] SIG(Ver) (2048 SHA(
256 ))
ECDSA C1720 FIPS186-4: Used for TLS
PKG: CURVES( P-256 ExtraRandomBits Session
TestingCandidates ) authentication.
PKV: CURVES( P-256)
SigGen: CURVES( P-256: (SHA-1, 224, 256, 384,
512) P-384: (SHA-1, 224, 256, 384, 512) P-521:
(SHA-1, 224, 256, 384, 512) SIG(gen) with SHA-1
allowed for use with protocols only.
SigVer: CURVES( P-256: (SHA-1, 224, 256, 384)
P-384: (SHA-1, 224, 256, 384) P-521: (SHA-1,
224, 256, 384)
26
FIPS 140-2 Security Policy v1.3

PKG: CURVES(P-384 P-521 ExtraRandomBits Implemented

TestingCandidates ) within the module
PKV: CURVES(P-384 P-521 ) however never
used by any service
DSA C1720 FIPS186-4: Used for Diffie-
KeyPairGen: [ (2048,256) ; (3072,256) ] Hellman Key
Generation
DRBG C1720 CTR_DRBG: [Prediction Resistance Tested: Used in support of
Enabled; BlockCipher_Use_df: (AES-128, AES- SSH and TLS
192, AES-256)] sessions. Used to
BlockCipher_No_df: (AES-128, AES-192, AES- seed RSA key
256)] generation.
DRBG C1934 HMAC_DRBG: [Prediction Resistance Tested: Used to generate
Enabled; Reseed Supported; Modes: SHA-1, the requested
SHA-256, SHA-384, SHA-512] random bits.
CVL C1720 TLS( TLS1.0/1.1 TLS1.2 (SHA 256, 384 ) ) SSH, TLS, and
SSH (SHA 1 , 256 , 512 ) SNMP Key
SNMP SHA1 Derivation.
KAS-SSC Vendor [56Arev3] Diffie-Hellman, EC
Affirmed FFC Diffie-Hellman Key
SCHEME: Ephem: (KARole: Initiator / Responder Agreement
) Safe Primes per Appendix D
ECC
SCHEME: EphemUnified: (KARole: Initiator /
Responder )
EC: P-256 , P-384, P-521
CKG Vendor [133rev2] Section 5.1 Asymmetric Key Generation
Affirmed signature key generation using
unmodified DRBG output
[133rev2] Section 5.2 Asymmetric
key establishment key generation
using unmodified DRBG output
[133rev2] Section 6.1 Direct
symmetric key generation using
unmodified DRBG output
[133rev2] Section 6.2.1 Derivation
of symmetric keys from a key
agreement shared secret

2.6.2 Non-Approved Algorithms Allowed for Use With FIPS-approved services

The module implements the following non-Approved algorithms that are allowed for use with
FIPS-approved services:

27
FIPS 140-2 Security Policy v1.3

• RSA Key Wrapping – provides 112 or 128 bits of encryption strength.

• NDRNG - Internal entropy source providing 256-bits of entropy to the DRBG.

Note: No parts of the SNMP, SSH, and TLS protocols, other than the KDF, have been tested by
the CAVP.

2.6.3 Non-Approved Algorithms Disallowed for Use With FIPS-approved services

The same set of services are supported by the module in the non-FIPS mode as in the FIPS
mode.

In addition to the list of SSH ciphers supported in the FIPS mode (Section 3.4.1), the module
also implements the following non-Approved symmetric algorithm that is allowed for use in the
non-FIPS mode alone:

1. rijndael-cbc@lysator.liu.se

For TLS, the ciphers supported in the FIPS mode (Section 3.4.2) are available except for the
following two ciphers:

1. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
2. TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

28
FIPS 140-2 Security Policy v1.3

2.7 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC)

All EX appliances are FCC (Part 15 Class-A), CE (Class-A), CNS, AS/NZS, VCCI (Class A) certified.

29
FIPS 140-2 Security Policy v1.3

2.8 Self-Tests
Self-tests are health checks that ensure that the cryptographic algorithms within the module
are operating correctly. The self-tests identified in FIPS 140-2 broadly fall within two categories
• Power-On Self-Tests
• Conditional Self-Tests

2.8.1 Power-On Self-Tests

The cryptographic module performs the following self-tests at Power-On:
• Firmware integrity (SHA-256)
• HMAC-SHA1 Known Answer Test
• HMAC-SHA224 Known Answer Test
• HMAC-SHA256 Known Answer Test
• HMAC-SHA384 Known Answer Test
• HMAC-SHA512 Known Answer Test
• AES-128 ECB Encrypt Known Answer Test
• AES-128 ECB Decrypt Known Answer Test
• AES-GCM-256 Encrypt Known Answer Test
• AES-GCM-256 Decrypt Known Answer Test
• TDES ECB Encrypt Known Answer Test
• TDES ECB Decrypt Known Answer Test
• RSA (mod 2048) Sign and Verify Known Answer Tests
• ECDSA (P-256) Sign and Verify Known Answer Tests
• DRBG (CTR) Known Answer Tests
o Generate, Reseed, Instantiate KATs
• DRBG (HMAC) Known Answer Tests
o Generate, Reseed, Instantiate KATs
• DSA Pairwise Consistency Test
• Primitive “Z” Known Answer Tests
o KAS FFC (dhEphem)
o KAS ECC (Ephemeral Unified)

2.8.2 Conditional Self-Tests

The cryptographic module performs the following conditional self-tests:
• Continuous Random Number Generator Test (CRNGT) for FIPS-approved DRBG
• Continuous Random Number Generator (CRNGT) for Entropy Source
• Firmware Load Test (2048-bit RSA, SHA-256)
• Pairwise Consistency Test (PWCT) for RSA
• Pairwise Consistency Test (PWCT) for ECDSA
• Pairwise Consistency Test (PWCT) for DSA

2.8.3 Self-Tests Error Handling

If any of the identified POSTs fail, the module will not enter an operational state and will
instead provide an error message and reboot. If either of the CRNGTs fail, the repeated random
30
FIPS 140-2 Security Policy v1.3

numbers are discarded and another random number is requested. If either of the PWCTs fail,
the key pair or signature is discarded and another key pair or signature is generated. If the
Firmware Load Test fails, the new firmware is not loaded.

Both during execution of the self-tests and while in an error state, data output is inhibited.

2.9 Mitigation of Other Attacks

The module does not claim to mitigate any other attacks beyond those specified in FIPS 140.

31
FIPS 140-2 Security Policy v1.3

3. Secure Operation
The following steps are required to put the module into the FIPS-approved mode of operation.
Prior to performing the steps below, the module is in the non-FIPS mode of operation. The
cryptographic officer shall verify that the firmware image to be loaded on the module is a FIPS
validated image. If any non-validated firmware image is loaded the module will no longer be a
FIPS validated module. Any firmware versions other than version 9.0.3, loaded into the modules
are out of the scope of this validation and require a separate FIPS 140-2 validation.

3.1 Modes of Operation

The module supports one FIPS Approved mode of operation and a non-Approved mode i.e. a
non-FIPS mode of operation. The module must always be zeroized when switching between the
FIPS Approved mode of operation and the non-Approved mode of operation and vice versa.
Prior to performing the steps outlined below, the module will operate in the non-FIPS mode. All
services available in the non-FIPS mode are identical to those in the FIPS approved mode.

3.2 Installation
There are no FIPS 140 specific hardware installation steps required.

3.3 Initialization
3.3.1 Default Authentication
During initial setup, the CO will be prompted to change the default authentication credentials.
These credentials must be changed at this point.

3.3.2 Enable compliance configuration options

Perform the following steps to enable FIPS 140-2 configuration options on the webUI.

1. Enter the CLI configuration mode:

hostname > enable
hostname # configure terminal
2. Enable the compliance configuration options on the webUI:
compliance options webui enable

3.3.3 Enable FIPS 140-2 compliance

There are two methods to enable FIPS 140-2 compliance on the appliance. Compliance may be
enabled either through the webUI or through the CLI. Perform the following to enable FIPS 140-
2 compliance through the webUI.

1. On the Web UI, select the Settings tab.

2. Select Compliance on the sidebar.
3. Click Enable FIPS Compliance.
4. Click Save changes to continue.
5. Click Reboot Now

Alternatively, perform the following to enable FIPS 140-2 compliance through the CLI.
32
FIPS 140-2 Security Policy v1.3

1. Enable the CLI configuration mode:

hostname > enable
hostname # configure terminal
2. Bring the system into FIPS 140-2 compliance:
hostname (config) # compliance apply standard fips
3. Save your changes:
hostname (config) # write memory
4. Restart the appliance:
hostname (config) # reload
5. Verify that the appliance is compliant:
hostname (config) # show compliance standard fips

3.4 Management
3.4.1 SSH Usage
When in FIPS 140-2 compliance mode, only the following algorithms may be used for SSH
communications. Note: The module itself restricts access to algorithms. No other algorithms
are available.

3.4.1.1 Symmetric Encryption Algorithms:

1. AES_128_CBC
2. AES_128_CTR
3. AES_256_CBC
4. AES_256_CTR
5. AES_128_GCM
6. AES_256_GCM

3.4.1.2 KEX Algorithms:

1. diffie-hellman-group14-sha1

3.4.1.3 Message Authentication Code (MAC) Algorithms:

1. hmac-sha1
2. hmac-sha2-256
3. hmac-sha2-512

3.4.2 TLS Usage

When in FIPS 140-2 compliance mode, only the following cipher suites may be used for TLS
communications. Note: The module itself restricts access to algorithms. No other algorithms
are available.
1. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
3. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
4. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
33
FIPS 140-2 Security Policy v1.3

5. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
6. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
7. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
8. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
9. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
10. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
11. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
12. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
13. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
14. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
15. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
16. TLS_DHE_RSA_WITH_AES_128_CBC_SHA
17. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
18. TLS_DHE_RSA_WITH_AES_256_CBC_SHA
19. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
20. TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
21. TLS_RSA_WITH_AES_128_GCM_SHA256
22. TLS_RSA_WITH_AES_256_GCM_SHA384
23. TLS_RSA_WITH_AES_128_CBC_SHA256
24. TLS_RSA_WITH_AES_256_CBC_SHA256
25. TLS_RSA_WITH_AES_128_CBC_SHA
26. TLS_RSA_WITH_AES_256_CBC_SHA

Note: In case the module's power is lost and then restored, a new key for use with the AES GCM
encryption/decryption must be established.

Note: The module is compatible with TLSv1.2 and supports the GCM cipher suites defined SP
800-52 Rev 1, Section 3.3.1. The module implements nonce management logic that ensures
when the nonce_explicit part of the IV exhausts the maximum number of possible values for a
given session key a new encryption key is established.

3.4.3 SNMP Usage

When in FIPS 140-2 compliance mode, only AES_128_OFB may be used for SNMP v3
communications. Note: The module itself restricts access to algorithms. No other algorithms are
available.

3.5 Secure Delivery

The product is delivered via commercial carrier (either FedEx or UPS). The product will contain a
packing slip with the serial numbers of all shipped devices. The Cryptographic Officer must
verify that the hardware serial numbers match the serial numbers listed in the packing slip.
Additionally, the Cryptographic Officer must verify that there is are no signs of
damage/tampering within the delivered package. Any sign of damage/tampering must be
reported to FireEye for guidance.
34
FIPS 140-2 Security Policy v1.3

3.6 Switching Modes of operation

To switch between the FIPS mode and the non-FIPS mode, the “reset factory” command can be
used which essentially resets the module to its factory default configuration i.e., the non-FIPS
mode. Prior to switching between FIPS mode and non-FIPS mode of operation, the CO must
perform the zeroization operation via the “compliance declassify zeroized” command.

3.7 Additional Information

For additional information regarding FIPS 140-2 compliance, see the “FireEye FIPS 140-2 and
Common Criteria Addendum, Release 1.0.”

35
FIPS 140-2 Security Policy v1.3

Appendix A: Acronyms
This section describes the acronyms used throughout the document.

Table 7 - Acronyms
Acronym Definition
CMVP Cryptographic Module Validation Program
CRNGT Continuous Random Number Generator Test
CVL Component Validation List
FIPS Federal Information Processing Standard
KDF Key Derivation Function
NIST National Institute of Standards and Technology
NVRAM Non-Volatile Random Access Memory
POST Power-On Self-Test
PWCT Pairwise Consistency Test

36