Copyright McAfee LLC 2018. May be reproduced only in its original entirety [without revision].
McAfee LLC
Network Security Platform Sensor
NS-3100, NS-3200, NS-5100 and NS-5200
Non-Proprietary Security Policy
Version 2.1
March 5, 2018
Page 2
TABLE OF CONTENTS
1 MODULE OVERVIEW....................................................................................................................................3
2 SECURITY LEVEL ..........................................................................................................................................5
3 MODE OF OPERATION..................................................................................................................................6
3.1 FIPS APPROVED MODE OF OPERATION............................................................................................................6
4 PORTS AND INTERFACES............................................................................................................................8
5 IDENTIFICATION AND AUTHENTICATION POLICY .........................................................................12
6 ACCESS CONTROL POLICY ......................................................................................................................14
6.1 ROLES AND SERVICES ....................................................................................................................................14
6.2 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS)............................................................................15
6.3 DEFINITION OF PUBLIC KEYS .........................................................................................................................16
6.4 DEFINITION OF CSPS MODES OF ACCESS.......................................................................................................17
7 OPERATIONAL ENVIRONMENT ..............................................................................................................19
8 SECURITY RULES.........................................................................................................................................20
9 PHYSICAL SECURITY POLICY.................................................................................................................22
9.1 PHYSICAL SECURITY MECHANISMS ...............................................................................................................22
9.2 OPERATOR REQUIRED ACTIONS.....................................................................................................................22
10 MITIGATION OF OTHER ATTACKS POLICY .......................................................................................24
Page 3
1 Module Overview
The Network Security Platform Sensor NS-3100, NS-3200, NS-5100 and NS-5200 consist of the
following multi-chip standalone platforms/configurations:
 NS-3100 (HW P/N IPS-NS3100 Version 1.00 FIPS Kit P/N IAC-FIPS-KT2)
 NS-3200 (HW P/N IPS-NS3200 Version 1.00; FIPS Kit P/N IAC-FIPS-KT2)
 NS-5100 (HW P/N IPS-NS5100 Version 1.00; FIPS Kit P/N IAC-FIPS-KT2)
 NS-5200 (HW P/N IPS-NS5200 Version 1.00; FIPS Kit P/N IAC-FIPS-KT2)
The following minor differences exist between the hardware configurations:
 Number of CPUs
 Memory configuration
 The NS-3100/NS-3200 have Intel Atom C2538 processors
 The NS-5100/NS-5200 have Intel Xeon E5-2620 processors
 The NS-5100/NS-5200 have an increased number of monitoring ports
All module configurations include FW Version 8.1.17.32
They are Intrusion Prevention Systems (IPS) and Intrusion Detection Systems (IDS) designed for
network protection against zero-day, DoS/DDoS, encrypted and SYN Flood attacks, and real-
time prevention of threats like spyware, malware, VoIP vulnerabilities, phishing, botnets,
network worms, Trojans, and peer-to-peer applications.
The cryptographic boundary of each platform is the outer perimeter of the enclosure, including
the power supplies and fan trays (removable and non-removable), as described below:
 The NS-3100 and NS-3200 do not have removable fans.
 The NS-5100 and NS-5200 have removable fan trays and they are protected by tamper
seals.
 For all modules, the removable power supplies are excluded from FIPS 140-2
requirements as they are non-security relevant.
Figure 1 - Figure 4 show the module configurations and the cryptographic boundaries.
Figure 1 – Image of NS-3100
Page 4
Figure 2 – Image of NS-3200
Figure 3 – Image of NS-5100
Figure 4 – Image of NS-5200
Page 5
2 Security Level
The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS
140-2. Table 1 specifies the levels met for specific FIPS 140-2 areas.
Table 1 - Module Security Level Specification
Security Requirements Section Level
Cryptographic Module Specification 2
Module Ports and Interfaces 2
Roles, Services and Authentication 2
Finite State Model 2
Physical Security 2
Operational Environment N/A
Cryptographic Key Management 2
EMI/EMC 2
Self-Tests 2
Design Assurance 3
Mitigation of Other Attacks N/A
Page 6
3 Mode of Operation
3.1 FIPS Approved Mode of Operation
The FIPS Approved mode of operation is defined by the use of only the FIPS Approved and
allowed algorithms, modes, and key sizes listed below. The module does allow several
algorithms in the Approved mode for which no security is claimed and they are listed below.
The operator must also follow the rules outlined in Sections 8 and 9 of this Security Policy.
Approved Algorithms
The module supports the following FIPS Approved algorithms:
 AES (Cert. #4619) CBC and ECB mode with 128 & 256 bits for encryption and
decryption
 CKG (Vendor Affirmed)
o Asymmetric Key Generation (SP 800-133 § 6)
o Symmetric Key Generation (SP 800-133 § 7.1, 7.2 7.3)
(Note: The resulting symmetric keys and generated seeds are unmodified output from the DRBG)
 (CVL Cert. #1273) TLS v1.2 KDF for TLS session key derivation
 (CVL Cert. #1274) SSH KDF for SSH session key derivation
 (DRBG Cert. #1548) Block Cipher (CTR) DRBG using AES 256
 (HMAC Cert. #3055) HMAC SHA-1, SHA-256, and SHA-512 for message
authentication.
(Note: The minimum HMAC key size is 20 bytes.)
 KTS (AES Cert. # 4619 and HMAC Cert #3055; key establishment methodology
provides 112 bits of encryption strength)
 (RSA Cert. #2514) FIPS 186-4 RSA PSS with 2048 bit keys for key generation,
signature generation with SHA-256, and signature verification with SHA-256
 (RSA Cert. #2525) FIPS 186-4 XYSSL RSA PKCS #1 V1.5 SigVer with 2048 bit
keys using SHA-256 for image verification.
(Note: SHA-1 is CAVP tested but not used.)
 (SHA Cert. #3783) SHA-1, SHA-256, and SHA-512 for hashing
(Note: SHA-1 is CAVP tested but not used.)
 (SHA Cert. #3791) XYSSL SHA-256 for hashing and for use with image verification
(Note: SHA-1 is CAVP tested but not used.)
Allowed Algorithms and Protocols
The module supports the following FIPS allowed algorithms and protocols:
 RSA with 2048-bit keys (key wrapping; key establishment methodology provides 112
bits of encryption strength)
 Diffie-Hellman with 2048-bit keys (key agreement; key establishment methodology
provides 112 bits of encryption strength)
 NDRNG for seeding the Block Cipher (CTR) DRBG. The NDRNG is limited to
instantiating the DRBG with 213 bits of security. The module generates cryptographic
keys whose strengths are modified by available entropy.
Page 7
 TLS v1.2 with the following algorithm tested cipher suites. The protocol algorithms have
been tested by the CAVP (see certificate #s above) but the protocol implementation itself
has not been reviewed or tested by the CAVP or CMVP.
o TLS_RSA_WITH_AES_128_CBC_SHA for communication with Network
Security Platform (NSP) Manager
(Note: This is restricted to RSA-2048)
 SSH v2 with the following algorithm tested cipher suites. The protocol algorithms have
been tested by the CAVP (see certificate #s above) but the protocol implementation itself
has not been reviewed or tested by the CAVP or CMVP.
o Key Exchange methods (i.e., key establishment methods): Diffie-hellman-
group14-SHAl
o Public Key methods (i.e., authentication methods): SSH-RSA
(Note: This is restricted to RSA-2048)
o Encryption methods: AES128-CBC, AES256-CBC
o MAC methods: HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-512
Algorithms and Protocols with No Security Claimed
The module supports the following algorithms and protocols in the Approved mode for which no
security is claimed (per FIPS IG 1.23):
 MD5 (used internal to the module only). No Security Claimed algorithms: MD5 (no
security claimed)
 SNMPv3 is used as a plaintext transport mechanism. All CSP content in this SNMPv3
channel is additionally key wrapped and signed by NSM to ensure integrity and
decrypted in sensor using the sensor TLS private key. Non-CSP SNMPv3 content is
deemed plaintext. No Security Claimed algorithms: AES (no security claimed), SNMP
KDF (no security claimed). Approved algorithms: HMAC (Cert. #3055), SHA (Cert.
#3783).
 The following algorithms are implemented independently from all other cryptographic
code in the module and are used to analyze the network stream for malware and
malicious network attacks in accordance with the functionality of the product.
o Decryption - SSLv2
- Cipher suites:
 SSL_CK_RC4_128_WITH_MD5
 SSL_CK_RC4_128_EXPORT40_WITH_MD5
 SSL_CK_DES_64_CBC_WITH_MD5
 SSL_CK_DES_192_EDE3_CBC_WITH_MD5
- No Security Claimed algorithms: Triple-DES (no security claimed), HMAC (no
security claimed), RC4 (no security claimed), MD5 (no security claimed), DES
(no security claimed)
o Decryption - SSLv3/TLS
- Cipher suites:
 SSL/TLS_NULL_WITH_NULL_NULL
 SSL/TLS_RSA_WITH_NULL_MD5
 SSL/TLS_RSA_WITH_NULL_SHA
 SSL/TLS_RSA_WITH_RC4_128_MD5
 SSL/TLS_RSA_WITH_RC4_128_SHA
 SSL/TLS_RSA_WITH_DES_CBC_SHA
 SSL/TLS_RSA_WITH_3DES_EDE_CBC_SHA
 SSL/TLS_RSA_WITH_AES_128_CBC_SHA
 SSL/TLS_RSA_WITH_AES_256_CBC_SHA
Page 8
- No Security Claimed algorithms: AES (no security claimed), RSA (no security
claimed), SHA (no security claimed), Triple-DES (no security claimed), HMAC
(no security claimed), RC4 (no security claimed), MD5 (no security claimed),
DES (no security claimed)
4 Ports and Interfaces
Figure 5 - Figure 8 show the modules’ front and rear panels and Table 2 - Table
5 list the modules’ ports and interfaces.
Figure 5 – NS-3100/3200 Front Panel
Table 2 – NS-3100/3200 Front Panel Ports and Connectors
Item Description Input/Output Type
1 RS232 Console port (1) Control Input,
Status Output
2 RJ-45 10/100/1000 Management port (MGMT) (1) Control Input, Data Output,
Status Output
3 RJ-45 10/100/1000 Response port (R1) (1) Data Output
4 USB port (1) Data Input
5 RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (8) Data Input/Output
Temp LED Green – Inlet air temperature measured inside the
module is normal
Amber – Inlet air temperature measured inside the
module is too high
Status Output
Fan LED Green – All the fans are operating
Amber – One or more of the fans has failed
Status Output
Status LED Green – Indicates that Sensor is in good health
Amber – System is booting up or something is not in
good health status
Status Output
Management
Port Speed LED
Green – The port speed is 1000 Mbps
Amber – The port speed is 100 Mbps
Off – The port speed is 10 Mbps
Status Output
Management
Port Link LED
Green – The link is up
Off – The link is down
Status Output
Response Port
Speed LED
Green – The port speed is 1000 Mbps
Amber – The port speed is 100 Mbps
Off – The port speed is 10 Mbps
Status Output
Response Port
Link LED
Green – The link is up
Off – The link is down
Status Output
Page 9
Item Description Input/Output Type
Normal/Bypass*
LEDs
Green – The port pair is in Inline Fail-Open/Inline Fail-
Close/Span/Tap Mode
Amber – The Port Pair is in Bypass Mode
Status Output
Ethernet Ports
Link LEDs
Green – The link is up
Off – The link is down
Status Output
Ethernet Ports
Speed LED
Green – The port speed is 1000 Mbps
Amber – The port speed is 100 Mbps
Off – The port speed is 10 Mbps
Status Output
*Bypass does not refer to FIPS 140-2 bypass capabilities
Figure 6 – NS-5100/5200 Front Panel
Table 3 – NS-5100/5200 Front Panel Ports and Connectors
Item Description Input/Output Type
1 RS232 Console port (1) Control Input,
Status Output
2 RJ-11 port (1) for fail-open control of two built-in SFP+
ports in slot G0. The RJ-11 ports support 1 Gbps (SFP)
fiber and 10 Gbps (SFP+) (SR and LR)
Status Output
3 SFP/SFP+ 1/10 fiber Gigabit or SFP 1 Gbps copper
Ethernet monitoring ports (2)
Data Input/Output
4 RJ-11 port (6) for external passive fail-open control of
twelve SFP ports in slot G1. The RJ-11 ports support 1
Gbps (SFP) fiber (SR and LR)
Status Output
5 SFP 1 Gbps copper or fiber Gigabit Ethernet monitoring
ports (12)
Data Input/Output
6 RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (8) Data Input/Output
Status LED Green – Indicates that Sensor is in good health
Amber – System is booting up or something is not in
good health status
Status Output
Fan LED Green – All the fans are operating
Amber – One or more of the fans has failed
Status Output
Temp LED Green – Inlet air temperature measured inside the
module is normal
Amber – Inlet air temperature measured inside the
module is too high
Status Output
Gigabit Ports
Act LEDs
Amber – Data is received or transmitted
Off – No data is being transferred
Status Output
Page 10
Item Description Input/Output Type
Gigabit ports
Link LEDs
Green – The link is up
Off – The link is down
Status Output
Normal/Bypass*
LEDs
Green – The port pair is in Inline Fail-Open/Inline Fail-
Close/Span/Tap Mode
Amber – The Port Pair is in Bypass Mode
Status Output
Gigabit Ports
Speed (Spd)
LEDs
Green – Port speed is 1Gbps
Amber – Port speed is 100 Mbps
Off – Port speed is 10 Mbps
Status Output
*Bypass does not refer to FIPS 140-2 bypass capabilities
Figure 7 – NS-3100/3200 Rear Panel
Table 4 – NS-3100/3200 Rear Panel Ports and Connectors
Item Description Input/Output Type
1 Power Port (1) Power Input
2 Cooling Fans (3) N/A – for identification only
LEDs Note: There are no LEDs on the NS-3100/3200 Rear Panel N/A
Figure 8 – NS-5100/5200 Rear Panel
Table 5 – NS-5100/5200 Rear Panel Ports and Connectors
Item Description Input/Output Type
1 Power Port (2) – second power supply is optional Power Input
2 USB ports (2) Data Input
3 RJ-45 10/100/1000 Management port (MGMT) (1) Control Input, Data Output,
Status Output
4 RJ-45 10/100/1000 Response port (R1) (1) Data Output
Power
LED(s)
Green – Power supply has power feed and is functioning
Amber – Power supply is not functioning
Status Output
Management
Port Speed
LED
Green – The port speed is 1000 Mbps
Amber – The port speed is 100 Mbps
Off – The port speed is 10 Mbps
Status Output
Page 11
Item Description Input/Output Type
Management
Port Link
LED
Green – The link is up
Off – The link is down
Status Output
Response
Port Speed
LED
Green – The port speed is 1000 Mbps
Amber – The port speed is 100 Mbps
Off – The port speed is 10 Mbps
Status Output
Response
Port Link
LED
Green – The link is up
Off – The link is down
Status Output
The module supports the following communication channels with the Network Security Platform
(NSP) Manager:
 Install channel: Only used to associate a Sensor with the NSM. They use a “shared
secret”. NSM listening on port 8501.
 Trusted Alert/Control channel (TLS): NSM listening on port 8502
 Trusted Packet log channel (TLS): NSM listening on port 8503
 Command channel (SNMPv3, plaintext): Sensor listening to NSM and 3rd
Party SNMP
clients on port 8500
 Bulk transfer channel (All output is encrypted): NSM listening on port 8509
 Trusted Authentication Gateway channel (TLS): uses same crypto context as
Alert/Control channel. NSM listening on port 8502.
Page 12
5 Identification and Authentication Policy
The cryptographic module supports three (3) distinct “User” roles (Admin, Sensor Operator(s),
and 3rd
Party SNMP Client(s)) and one “Cryptographic Officer” role (Network Security Platform
Manager). Table 6 lists the supported operator roles along with their required identification and
authentication techniques. Table 7 outlines each authentication mechanism and the associated
strengths.
Table 6 - Roles and Required Identification and Authentication
Role Type of Authentication Authentication Data
Admin Role-based operator
authentication
Username and Password
Sensor Operator(s) Role-based operator
authentication
Username and Password
Network Security Platform Manager
(Cryptographic Officer)
Role-based operator
authentication
Digital Signature
or
Username, Privacy and
Authentication Key
3rd Party SNMP Client(s) Role-based operator
authentication
Username, Privacy and
Authentication key
Table 7 – Strengths of Authentication Mechanisms
Authentication Mechanism Strength of Mechanism
Username and Password The password is an alphanumeric string of a minimum of fifteen (15)
characters chosen from the set of ninety-three (93) printable and
human-readable characters. Whitespace and “?” are not allowed. New
passwords are required to include 2 uppercase characters, 2 lowercase
characters, 2 numeric characters, and 2 special characters. The fifteen
(15) character minimum is enforced by the module.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/{(10^2)*(26^4)*(31^2)*(93^7)} which is
less than 1/1,000,000.
After three (3) consecutive failed authentication attempts, the module
will enforce a one (1) minute delay prior to allowing retry.
Additionally, the module only supports 5 concurrent SSH sessions.
Thus, the probability of successfully authenticating to the module
within one minute through random attempts is
(3*5)/{(10^2)*(26^4)*(31^2)*(93^7)}, which is less than 1/100,000.
Digital Signature RSA 2048-bit keys using SHA-256 are used for the signing (in isolated
McAfee laboratory) and verification (by sensor) of digital signatures.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/2^112, which is less than 1/1,000,000.
The module can only perform one (1) digital signature verification per
second. The probability of successfully authenticating to the module
within one minute through random attempts is 60/2^112, which is less
than 1/100,000.
Page 13
Authentication Mechanism Strength of Mechanism
Username, Privacy and
Authentication key
The privacy key and authentication key together make an alphanumeric
string of a minimum of sixteen (16) characters chosen from the set of
sixty-two (62) numbers, lower case letters, and upper case letters.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/62^16, which is less than 1/1,000,000.
The module will allow approximately one (1) attempt per millisecond,
meaning that 60,000 attempts can be made per minute. The probability
of successfully authenticating to the module within one minute through
random attempts is 60,000/62^16, which is less than 1/100,000.
Page 14
6 Access Control Policy
6.1 Roles and Services
Table 8 lists each operator role and the services authorized for each role.
For additional information of operation of the module, see the Network Security Platform 8.1
CLI Guide.
Table 8 – Services Authorized for Roles
Authorized Services
Admin
Sensor
Operator(s)
NSP
Manager
3rd
Party
SNMP
Client(s)
Show Status: Provides the status of the module, usage statistics, log
data, and alerts.
X X X
Sensor Operator Management: Allows Admin to add/delete Sensor
Operators, set their service authorization level, set their session timeout
limit, and unlock them if needed.
X
Network Configuration: Establish network settings for the module or
set them back to default values. X X* X
Administrative Configuration: Other various services provided for
admin, private, and support levels. X X* X
Firmware Update: Install an external firmware image through SCP or
USB X X* X
Install with NSM: Configures module for use. This step includes
establishing trust between the module and the associated management
station.
X X*
Install with 3rd
Party SNMP Client: Configures module for 3rd
Party
SNMPv3 use. This step includes establishing trust between the module
and the associated 3rd
Party SNMP Client. Trust is provided by NSM.
X
Change Passwords: Allows Admin and Sensor Operators to change
their associated passwords. Admin can also change/reset Sensor
Operators passwords.
X X*
Zeroize: Destroys all plaintext secrets contained within the module.
The “Reset Config” command is used, followed by a reboot.
X X*
Intrusion Detection/Prevention Management: Management of
intrusion detection/prevention policies and configurations through
SNMPv3 and TLS.
X
Intrusion Detection/Prevention Monitoring: Limited monitoring of
Intrusion Detection/Prevention configuration, status, and statistics
through SNMPv3.
X X
Disable SSH/Console Access: Disables SSH/Console access. X X*
* Depending on the authorization level granted by the Admin
Page 15
Unauthenticated Services:
Table 9 lists the unauthenticated services supported by the module.
Table 9 – Unauthenticated Services
Unauthenticated Services
Self-Tests: This service executes the suite of self-tests required by FIPS 140-2. Self-tests can
be initiated by power cycling the module or through the CLI.
Intrusion Prevention Services: Offers protection against zero-day, DoS/DDoS, encrypted and
SYN Flood attacks, and real-time prevention of threats like spyware, malware, VoIP
vulnerabilities, phishing, botnets, network worms, Trojans, and peer-to-peer applications.
Note: This service utilizes the no security claimed algorithms listed above. This includes an
MD5 hash to identify the “fingerprint” of malware and decryption of SSL-encrypted streams
for the purpose of detecting malware and network attacks. See the list above.
Zeroize: Destroys all plaintext secrets contained within the module. The Internal Rescue
process is used.
6.2 Definition of Critical Security Parameters (CSPs)
The following are CSPs contained in the module:
 Administrator Passwords: Password used for authentication of the “admin” role
through Console and SSH login. Extended permissions are given to the “admin” role by
using the “support” or “private” passwords.
 Sensor Operator Passwords: Passwords used for authentication of “user” accounts
through Console and SSH login. Extended permissions are given to the “user” account
by using the “support” or “private” passwords.
 3rd
Party SNMP Client Privacy and Authentication Keys: Passwords used for
authentication of 3rd
Party SNMP Clients.
 NSM SNMP Client Privacy and Authentication Keys: Passwords used for
authentication of NSM SNMP Clients.
 NSM Initialization Secret (i.e., NSM Shared Secret): Password used for mutual
authentication of the sensor and NSM during initialization.
 Bulk Transfer Channel Session Key: AES 128 bit key used to encrypt data packages
across the bulk transfer channel.
 SSH Host Private Keys: RSA 2048 bit key used for authentication of sensor to remote
terminal for CLI access, generated during initialization
 SSH Session Keys: Set of ephemeral Diffie-Hellman (2048 bit), AES (128 or 256 bit),
and HMAC (>=112 bit) keys created for each SSH session.
Page 16
 TLS Sensor Private Key (for NSM): RSA 2048 bit key used for authentication of the
sensor to NSM.
 TLS Session Keys (for NSM): Set of ephemeral AES (128 bit) and HMAC (>=112 bit)
keys created for each TLS session with the NSM.
 Seed for RNG: Seed created by NDRNG and used to seed the Block Cipher (CTR)
DRBG. The Nonce is 128 bits and the Entropy Input is 256 bits for a total seed size of
384 bits.
 DRBG Internal State: V and Key used by the DRBG to generate pseudo-random
numbers
6.3 Definition of Public Keys
The following are the public keys contained in the module:
 McAfee FW Verification Key: RSA 2048 bit key used to authenticate firmware images
loaded into the module.
 SSH Host Public Key: RSA 2048 bit key used to authenticate the sensor to the remote
client during SSH.
 SSH Remote Client Public Key: RSA 2048 bit key used to authenticate the remote
client to the sensor during SSH.
 TLS Sensor Public Key (for NSM): RSA 2048 bit key used to authenticate the sensor
to NSM during TLS connections.
 TLS NSM Public Key: RSA 2048 bit key used to authenticate NSM to sensor during
TLS connections.
Page 17
6.4 Definition of CSPs Modes of Access
Table 10 defines the relationship between access to keys/CSPs and the different module services.
The types of access used in the table are Use (U), Generate (G), Input (I), Output (O), Store (S),
and Zeroize (Z). Z* is used to denote that only the plaintext portion of the CSP is zeroized (i.e.,
the CSP is also stored using an Approved algorithm, but that portion is not zeroized).
Table 10 – Key and CSP Access Rights within Services
Administrator
Passwords
Sensor
Operator
Passwords
3rd
Party
SNMP
Client
P
and
A
Keys
NSM
SNMP
Client
P
and
A
Keys
NSM
Initialization
Secret
Bulk
Transfer
Channel
Session
Key
SSH
Host
Private
Keys
SSH
Session
Keys
TLS
Sensor
Private
Key
(for
NSM)
TLS
Session
Keys
(for
NSM)
Seed
for
RNG
DRBG
Internal
State
McAfee
FW
Verification
Key
SSH
Host
Public
Key
SSH
Remote
Client
Public
Key
TLS
Sensor
Public
Key
(for
NSM)
TLS
NSM
Public
Key
Authentication –
Admin, Sensor
Operator
U U U U G U G O I U
Authentication – NSP
Manager –Digital
Signature
U U U G U G O U
SNMP Authentication –
NSP Manager to Sensor
- Username, Privacy,
and Authentication Key
U I
S
Authentication – 3rd
Party SNMP Client(s)
U I
S
Show Status U U U U U
Sensor Operator
Management
U U
Network Configuration U U
Administrative
Configuration
I UG U U UG
Firmware Update I U U U U I
Install with NSM S I U G U U G U G U G G
Install with 3rd
Party
SNMP Client
S I U U
Change Passwords I S I S
Zeroize
(Authenticated)
Z* Z* Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
Zeroize
(Unauthenticated)
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
Intrusion Detection/
Prevention
Management
U U U U U
Intrusion Detection/
Prevention Monitoring
U U
Disable SSH/Console
Access
U
Page 18
Administrator
Passwords
Sensor
Operator
Passwords
3rd
Party
SNMP
Client
P
and
A
Keys
NSM
SNMP
Client
P
and
A
Keys
NSM
Initialization
Secret
Bulk
Transfer
Channel
Session
Key
SSH
Host
Private
Keys
SSH
Session
Keys
TLS
Sensor
Private
Key
(for
NSM)
TLS
Session
Keys
(for
NSM)
Seed
for
RNG
DRBG
Internal
State
McAfee
FW
Verification
Key
SSH
Host
Public
Key
SSH
Remote
Client
Public
Key
TLS
Sensor
Public
Key
(for
NSM)
TLS
NSM
Public
Key
Self Tests
Intrusion Prevention
Services
Page 19
7 Operational Environment
The device supports a limited operational environment.
Page 20
8 Security Rules
The cryptographic module’s design corresponds to the module’s security rules. This section lists
the requirements of this FIPS 140-2 Level 2 module.
1. The cryptographic module provides four (4) distinct operator roles: Admin, Sensor
Operator(s), Network Security Platform Manager, and 3rd
Party SNMP Client(s).
2. The cryptographic module provides role-based authentication and each change of
operator roles shall be authenticated; previous authentication results are cleared when the
module transitions to a power-off state.
3. When the module has not been placed in a valid role, the operator does not have access to
any cryptographic services.
4. The cryptographic module performs the following tests:
A. Power up Self-Tests are performed without operator input:
1. Firmware Integrity Test: XYSSL RSA 2048 (RSA Cert. #2525) using SHA-256
(SHA Cert. #3791) for hashing
2. Cryptographic algorithm known answer tests (KATs) and pairwise consistency
tests (PCT):
a. AES ECB 128 Encryption KAT and Decryption KAT (AES Cert. #4619)
b. RSA 2048 PSS Key Generation/Sign/Verify with SHA-256 Pairwise
Consistency Test (RSA Cert. #2514)
c. SHA-1 KAT (SHA Cert. #3783)
d. SHA-256 KAT (SHA Cert. #3783)
e. SHA-512 KAT (SHA Cert. #3783)
f. Block Cipher (CTR) DRBG KAT and SP 800-90A DRBG Section 11.3
Health Checks (DRBG Cert. #1548)
g. HMAC SHA-1 KAT (HMAC Cert. #3055)
h. HMAC SHA-256 KAT (HMAC Cert. #3055)
i. HMAC SHA-512 KAT (HMAC Cert. #3055)
j. XYSSL RSA 2048 Signature Verification KAT (RSA Cert. #2525)
(SHA-256 based signatures)
k. XYSSL SHA-1 KAT (SHA Cert. #3791)
l. XYSSL SHA-256 KAT (SHA Cert. #3791)
m. TLS 1.2 KDF KAT (CVL Cert. #1273)
n. SSH KDF KAT (CVL Cert. #1274)
If any of these tests fail the following message will be displayed:
!!! CRITICAL FAILURE !!!
FIPS 140-2 POST and KAT...Failed
REBOOTING IN 15 SECONDS
3. Critical Functions Tests: N/A
Page 21
B. Conditional Self-Tests:
a. Block Cipher (CTR) DRBG Continuous Test
b. SP 800-90A DRBG Section 11.3 Health Checks
c. NDRNG Continuous Test
d. RSA KeyGen/Sign/Verify Pairwise Consistency Test
e. External Firmware Load Test – XYSSL RSA 2048 (Cert. #2525) using SHA-
256 (Cert. #3791) for hashing
If the firmware load test fails the following message will be displayed: "Load
Image with SCP Failed."
5. At any time the cryptographic module is in an idle state, the operator is capable of
commanding the module to perform the power up self-test by power cycling.
6. Data output inhibits during self-tests and error states.
a. All Power Up Self-Test are run before data output ports are initialized.
b. In the case of failed Self Tests, the module enters an error state, inhibits data
output, and reboots.
7. Data output is logically disconnected during key generation and zeroization.
8. For both Zeroize services (authenticated and unauthenticated), the operator must remain
in control of the module or be physically present with the module to assure that the entire
zeroization process completes successfully. This may take up to one minute and 45
seconds.
9. Status information shall not contain CSPs or sensitive data that if misused could lead to a
compromise of the module.
10. If a non-FIPS validated firmware version is loaded onto the module, then the module is
no longer a FIPS validated module.
11. The module only supports five (5) concurrent SSH operators when SSH is enabled.
12. The cryptographic module shall not be configured to transmit files to McAfee Advanced
Threat Detection.
Page 22
9 Physical Security Policy
9.1 Physical Security Mechanisms
The cryptographic module includes the following physical security mechanisms:
 Production-grade components
 Production-grade opaque enclosure with tamper-evident seals. Tamper-evident seals and
further instructions are obtained in the FIPS Kits with the following part numbers:
o NS-3100/3200/5100/5200: IAC-FIPS-KT2
9.2 Operator Required Actions
For the module to operate in a FIPS Approved mode, the tamper seals shall be placed by the
Admin role as specified below. The Admin must clean the chassis of any dirt before applying the
labels and ensure the labels are allowed to cure for 30 minutes following application. Sets of
labels are serialized, however, the usage of the label numbers is not required. Per FIPS 140-2
Implementation Guidance (IG) 14.4, the Admin role is also responsible for the following:
 Securing and having control at all times of any unused seals
 Direct control and observation of any changes to the module, such as reconfigurations,
where the tamper-evident seals or security appliances are removed or installed to ensure
the security of the module is maintained during such changes and the module is returned
to a FIPS Approved state.
The Admin is also required to periodically inspect tamper-evident seals. Table 11 outlines the
recommendations for inspecting/testing physical security mechanisms of the module. If a fan
tray is removed or replaced, then a new seal must be applied in order to be compliant. If the
Admin finds evidence of tampering, then the module is no longer FIPS compliant and must be
taken out of service.
Table 11 – Inspection/Testing of Physical Security Mechanisms
Physical Security Mechanisms Recommended Frequency of
Inspection/Test
Inspection/Test Guidance
Details
Tamper-Evident Seals As specified per end user policy,
annually at a minimum
Visually inspect the seals for
tears, rips, dissolved adhesive,
and other signs of malice.
Opaque Enclosure As specified per end user policy,
annually at a minimum
Visually inspect the enclosure for
broken screws, bent casing,
scratches, and other questionable
markings.
Page 23
Figure 9 depicts the six (6) tamper seal locations (numbered in red) on the cryptographic module
for the NS3100/NS3200 platform.
Figure 9 – Tamper Seal Locations (NS3100/NS3200 Sensor – Top Surface)
Figure 10 depicts the five (5) tamper seal locations (numbered in red) on the cryptographic
module for the NS5100/NS5200 platform.
Figure 10 – Tamper Seal Locations (NS5100/NS5200 Sensor – Top Surface)
Figure 11 below is an example of the tamper-evident seals applied to the modules.
Page 24
Figure 11 – Tamper-Evident Seal
10 Mitigation of Other Attacks Policy
The module has not been designed to mitigate any specific attacks beyond the scope of FIPS
140-2 requirements.