Copyright Musarubra US LLC, 2022 Version 0.9 Page 1 of 25
Musarubra US LLC Public Material – May be reproduced only in its original entirety (without revision).
Network Security Platform Sensor NS9300 P
FIPS 140-2 Non-Proprietary Security Policy
Firmware Version: 10.1.17.63
DATE: JUNE 20, 2022
Trellix
6220 America Center Drive
San Jose, CA 95002
888.847.8766
http://www.trellix.com
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 .................................................................................... 25
11 GLOSSARY ................................................................................................................................................ 25
Page 3
1 Module Overview
The Network Security Platform Sensor NS-9300 P (HW P/N IPS-NS9300 P Version 1.30 and FW
Version 10.1.17.63; FIPS Kit P/N IAC-FIPS-KT2) is a multi-chip standalone cryptographic
module as defined in FIPS 140-2.
The NS9300 is an Intrusion Prevention System (IPS) and Intrusion Detection System (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 NSP Sensors connect with the
Network Security Manager (NSM). The NSM is used to manage and push configuration data and
policies to the Sensors. Communication between NSM and Sensors uses secure channels that
protect the traffic from disclosure and modification. Authorized administrators may access the
NSM via a GUI (over HTTPS) or a CLI (via SSH or a local connection). Sensors may be accessed
via CLI (via SSH or a local connection) for initial setup. Once initial setup is complete, all
management occurs via the NSM.
The cryptographic boundary is the outer perimeter of the enclosure, including the removable power
supplies and fan trays. (The power supplies and fan trays are excluded from FIPS 140-2
requirements, as they are not security relevant.) Optional network I/O modules are not included
in the module boundary.
The Trellix NS-9300 product consists of the NS-9300 P cryptographic module physically
connected with the NS-9300 S cryptographic module. This security policy describes the NS-9300
P only.
Figure 1 shows the module configuration and the cryptographic boundary.
Figure 1 – Image of NS9300 P
Page 4
Figure 2 - Image of the Cryptographic Module connected to its peer NS-9300 S
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 module only supports a FIPS Approved mode of operation. An operator can obtain the FIPS
mode indicator by executing the “show” or “status” CLI command, which returns the module’s
firmware version, HW version, etc. The firmware and hardware versions must match the FIPS
validated versions located on the CMVP website.
The operator must also follow the rules outlined in Sections 8 and 9 of this Security Policy and
consult FIPS 140-2 IG 1.23 for further understanding of the use of functions where no security is
claimed.
Approved Algorithms
The module supports the following FIPS Approved algorithms:
• AES CBC and ECB mode with 128 & 256 bits for encryption and decryption (Cert.
#C1556)
(Note: CBC mode is tested but not used.)
• AES GCM mode with 128 bits for encryption and decryption use within TLS 1.2 (Cert.
#C1556)
• AES GCM mode with 128 & 256 bits for encryption and decryption use within SSH v2
(Cert. #C1556)
• KTS AES (Cert. #C1556) encryption to transport keys and authentication using HMAC
(Cert. #C1556) within TLS 1.2 and SSH. This key establishment methodology provides
128 or 256 bits of encryption strength.
• KTS AES (Cert. #C1556) encryption to transport keys and authentication using GCM
(Cert. #C1556) within TLS 1.2 and SSH. This key establishment methodology provides
128 or 256 bits of encryption strength.
• FIPS 186-4 RSA with 2048-bit keys for key generation and RSA PSS with 2048-bit keys
for signature generation with SHA-256, and signature verification with SHA-256 (Cert.
#C1556)
• SHA-1, SHA-256, SHA-384 and SHA-512 for hashing (Cert. #C1556)
• HMAC SHA-256, and HMAC SHA-512 for message authentication (Cert. #C1556)
(Note: The minimum HMAC key size is 20 bytes. HMAC SHA-1 and HMAC SHA-384 were CAVP tested but
not used)
• Block Cipher (CTR) DRBG using AES 256 (Cert. #C1556)
• KAS-SSC (vendor affirmed)
• ECDSA Key Generation and Key Verification using P-256, P-384, P-521 (Cert. #C1556)
• FIPS 186-4 XYSSL RSA PKCS #1 1.5 SigVer with 2048-bit keys using SHA-256 for
image verification (Cert. #C1555).
(Note: SHA-1 is CAVP tested but not used.)
• XYSSL SHA-256 for hashing and for use with image verification (Cert. #C1555)
(Note: SHA-1 is CAVP tested but not used.)
• TLS v1.2 KDF for TLS session key derivation (CVL Cert. #C1558)
• SSH KDF for SSH session key derivation (CVL Cert. #C1557)
• SP 800-133 CKG (Vendor Affirmed)
Page 7
o Asymmetric Key Generation (SP 800-133 § 5)
o Symmetric Key Generation (SP 800-133 § 6)
(Note: The resulting symmetric keys and generated seeds are unmodified output from the DRBG)
(Note: There are some algorithm modes that were tested but not implemented by the module. Only the algorithms,
modes, and key sizes that are implemented by the module are shown in this table)
Allowed Algorithms
The module supports the following FIPS allowed algorithms and protocols:
• RSA with 2048-bit keys for (key wrapping, key establishment methodology provides 112
bits of encryption strength)
• NDRNG (internal entropy source) for seeding the Block Cipher (CTR) DRBG. The module
generates a minimum of 256 bits of entropy for key generation.
Protocols
• 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_ECDHE_RSA_WITH_AES_128_GCM_SHA256
for communication with Network Security Manager (NSM)
(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): EC Diffie-hellman-P-
256 SHA2
o Public Key methods (i.e., authentication methods): SSH-ECDSA
(Note: This is restricted to ECDSA P-256)
o Encryption methods: AES128-GCM, AES256-GCM
o MAC methods: HMAC-256, HMAC-512
AES GCM is used as part of TLS 1.2 cipher suites conformant to IG A.5, Scenario 1 RFC
5288 and SP 800-52 Rev 2 Section 3.3.1. The construction of the 64-bit nonce_explicit part of
the IV is deterministic via a monotonically increasing counter. The module ensures that that
when the deterministic part of the IV uses the maximum number of possible values and new
session key is established. The module generates new AES-GCM keys if the module loses
power.
AES GCM is also used as part of the SSHv2 cipher suites conformant to the IG A.5 Scenario
1 and RFCs 4252, 4253 and RFC 5647. The GCM re-key limit is set to 1 hour or 1 GB of
payload traffic set as the threshold. Therefore, the invocation counter maximum of 264
– 1 is
never reached nor are that many encryptions performed in a single session. When a session is
terminated for any reason, a new key and new initial IV shall be derived.
Non-Approved Algorithms and Protocols with No Security Claimed
The module supports the following non-Approved but allowed algorithms and protocols with no
security claimed (per FIPS IG 1.23):
Page 8
• MD5 used to identify “fingerprint” of potential malware using Global Threat Information
(GTI) database (used internal to the module only). Non-Approved algorithms (no security
claimed): MD5
• SNMPv3 is used as a transport mechanism between the NSM and the sensor with no
security claimed. All non-CSP content is transported within SNMPv3. All CSP content is
additionally encrypted by NSM and decrypted in sensor using the sensor TLS private
key. In addition, the SNMPv3 protocol between NSM and Sensor is encapsulated within
TLS when adopting CA-signing is turned on (TLS–ECDHE-RSA-AES128_GCM-
SHA256). Non-Approved algorithms (no security claimed): HMAC (non-compliant),
SHA (non-compliant), AES (non-compliant) and SNMP KDF (non-compliant).
• SNMPv3 is used as a Read Only connection and responses to non CSP objects for 3rd
Part
Clients with no security claimed.
• 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. For the
reasoning stated above, this functionality is allowed in the FIPS Approved mode of
operation.
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
- Non-Approved algorithms (no security claimed): Triple-DES (non-
compliant), HMAC (non-compliant), RC4, MD5, DES
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
- Non-Approved algorithms (no security claimed): AES (non-compliant), RSA
(non-compliant), SHA (non-compliant), Triple-DES (non-compliant), HMAC
(non-compliant), RC4, MD5, DES
4 Ports and Interfaces
Table 2 provides the cryptographic module’s ports and interfaces.
Table 2 – Fixed Ports
Fixed Ports Number of ports Input/Output Type
40-Gig QSFP+ Monitoring Ports 2 Data Input/Output
1-GigE Monitoring Ports 8 Data Input/Output
Network I/O slots 2 Data Input/Output
Page 9
Fixed Ports Number of ports Input/Output Type
GigE Management Port 1 Control Input, Data Output, Status Output
GigE Response Port 1 Control Input, Data Output
GigE Aux Port 1 Data Output
RS232 Console 1 Control Input, Status Output
USB Ports 2 Data Input
Power Ports 2 Power Input
LEDs Many Status Output
Notes:
1. The Two fixed QSFP+ 40-GigE ports are used to connect to the peer NS-9300 S unit.
2. The GigE Response Port is connected directly to the peer NS-9300 S unit’s GigE Management
Port.
3. The Network IO Slots each accept interface modules which provide additional monitoring
ports. The interface modules are not included in the cryptographic boundary.
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 (Self-signed certificates) or port 8506 (CA signed certificates).
• Trusted Alert/Control channel (TLS): NSM listening on port 8502 (Self-signed
certificates) or port 8507 (CA signed certificates).
• Trusted Packet log channel (TLS): NSM listening on port 8503 (Self-signed certificates)
or port 8508 (CA signed certificates).
• Command channel (SNMP, plaintext): Sensor listening to 3rd Party SNMP Clients on port
8500 (Self-signed certificates).
• Command channel (TLS): Sensor listening to NSM SNMPv3 client encapsulated in TLS
on port 18500 (CA signed certificates).
• Bulk transfer channel (encrypted): NSM listening on port 8504 (CA signed certificates)
• Bulk transfer channel (TLS): NSM listening on port 8509
• Trusted Authentication Gateway channel (TLS): uses same crypto context as Alert/Control
channel. NSM listening on port 8502 (Self-signed certificates) or port 8507 (CA signed
certificates).
Page 10
Figure 3 - Front Panels of NS-9300 P
Table 3 – NS-9300 P Front Panel Ports and Connectors
Item Description
1 Console ports on the NS-9300 P Sensors (1)
2 QSFP+ 40 Gigabit Ethernet Interconnect ports (2). G0/1 and G0/2 on NS-9300 P Sensor
Sensor.
3 Two slots for Network I/O modules. The Network I/O modules are outside of the
cryptographic boundary. There is no security relevance to using the following Network
I/O modules in any combination.
• QSFP+ 40 Gigabit Ethernet ports (2)
• QSFP+ 40 Gigabit Ethernet ports (1)
• SFP/SFP+ 1/10 Gigabit Ethernet Monitoring ports (4)
• RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (3)
4 RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (8)
Figure 4 - Front panel with no Network I/O Modules or cover plate
Page 11
Figure 5 - Rear Panels of NS-9300 P
Table 4 – NS-9300 P Rear Panel Ports and Connectors
Item Description
1 USB ports (2)
2 Power supply A (Pwr A)
3 Power supply B (Pwr B) (optional on NS9100)
4 RJ-45 100/1000/10000 Management port (Mgmt) (1)
5 RJ-45 100/1000/10000 Response port (R1) (1). R1 on NS-9300 P Sensor is used as an
interconnect port.
6 RJ-45 Auxiliary port (Aux) (1)
Figure 6 - Rear Panel with Power Supplies Removed
Page 12
5 Identification and Authentication Policy
The cryptographic module shall support four distinct “User” roles (Admin, Sensor Operator(s),
NS-9300 S, and 3rd Party SNMP Client(s)) and one “Cryptographic Officer” (CO) role (Network
Security Platform Manager). Table 5 lists the supported operator roles along with their required
identification and authentication techniques. Table 6 outlines each authentication mechanism and
the associated strengths.
Table 5 - Roles and Required Identification and Authentication
Role Type of Authentication Authentication Data
Admin (User) Role-based authentication Username and Password
Sensor Operator(s) (User) Role-based authentication Username and Password
Network Security Platform Manager (CO) Role-based authentication Digital Signature
NS-9300 S (User) Role-based authentication Shared Secret
3rd Party SNMP Client(s) (User) Role-based authentication Username, Privacy and
Authentication key
Table 6 – Strengths of Authentication Mechanisms
Authentication Mechanism Strength of Mechanism
Username and Password
(Admin and Sensor
Operator(s))
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 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.
Page 13
Authentication Mechanism Strength of Mechanism
Shared Secret
(NS-9300 S)
The Shared Secret is an alphanumeric string of a minimum of
six (6) characters chosen from the set of ninety-three (93)
printable and human-readable characters. Whitespace and “?”
are not allowed.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/93^6 which is less than 1/1,000,000.
After setting the Shared Secret, the module requires a reboot in
order to authenticate. The reboot takes longer than one minute
before authentication is achieved, and if authentication fails, the
module automatically reboots a second time. The probability of
successfully authenticating to the module within one minute
through random attempts is 1/93^6 which is less than
1/100,000.
Digital Signature and RSA Key
Wrap
RSA 2048-bit keys using SHA-256 are used for the signing (in
isolated Trellix laboratory or by Certificate Authority (CA)) 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.
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 7 lists each operator role and the services authorized for each role.
For additional information of operation of the module, NSP documentation is at docs.trellix.com:
1. Go to the Trellix Documentation Portal (https://docs.trellix.com/).
2. Scroll to the Products A-Z section at the bottom of the landing page (do not select
Network Security Platform via the pull-down menu).
3. Click Network Security Platform. The NSP documentation list displays.
4. Using the Refine Results filter in the left pane, click NSP 10.1.x to display a list of NSP
10.1 documentation.
Table 7 – Services Authorized for Roles
Authorized Services
Admin
Sensor
Operator(s)
NSP
Manager
3rd
Party
SNMP
Client(s)
NS-9300
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*
Page 15
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
Unauthenticated Services:
Table 8 lists the unauthenticated services supported by the module.
Table 8 – Unauthenticated Services
Unauthenticated Services
Authentication: This service is associated with an unauthorized operator making a
request in order to authenticate themselves to the module.
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 non-Approved 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.
Page 16
• 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.
• NS-9300 Password: Password for authentication of the NS-9300 S.
• 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: ECDSA P-256 bit key used for authentication of sensor to remote
terminal for CLI access, generated during initialization.
• SSH Session Keys: Set of EC Diffie-Hellman private key with P-256, AES 128/256 bit,
and HMAC (SHA-256/512 bit) keys created for each SSH session.
• TLS Sensor Private Key (for NSM): RSA 2048 bit key used for authentication of the
sensor to NSM during TLS connections and generate the sha256WithRSADigitialSignature
embedded within the sensor TLS certificate. This key can also be used only by that sensor
for RSA unwrapping of Trellix defined secrets received from the NSM.
• TLS Session Keys (for NSM): Set of ephemeral EC Diffie Hellman P-256, P-384 or P-
521, AES 128 bit and HMAC (SHA-256bit) keys created for each TLS session with the
NSM.
• Entropy Input String: 8192-bit output string from the hardware NDRNG.
• Seed for DRBG: 384-bit seed created by NDRNG and used to seed the Block Cipher
(CTR) DRBG.
• DRBG Internal State: V and Key used by the DRBG to generate pseudo-random numbers.
(Note: The SNMP authentication data is not considered to be a CSP since the SNMP
connection is tunneled within TLS)
6.3 Definition of Public Keys
The following are the public keys contained in the module:
• Trellix FW Verification Key: RSA 2048-bit key used to authenticate firmware images
loaded into the module.
• SSH Host Public Key: ECDSA P-256 bit key used to authenticate the sensor to the remote
client during SSH.
• SSH Remote Client Public Key: ECDSA P-256 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, embedded within the sensor certificate. This key can also
be used by the NSM for RSA wrapping of Trellix defined secrets sent to the Sensor.
• TLS NSM Public Key: RSA 2048-bit key used to authenticate NSM to sensor during TLS
connections.
• TLS Session Public Key: EC Diffie-Hellman P-256, P-384 or P-521-bit session key
created for each TLS session
Page 17
6.4 Definition of CSPs Modes of Access
Table 9 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).
Page 18
Table 9 – Key and CSP Access Rights within Services
Administrator
Passwords
Sensor
Operator
Passwords
NS-9300
Password
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)
Entropy
Input
String
Seed
for
DRBG
DRBG
Internal
State
Trellix
FW
Verification
Key
SSH
Host
Public
Key
SSH
Remote
Client
Public
Key
TLS
Sensor
Public
Key
(for
NSM)
TLS
NSM
Public
Key
TLS
Session
Public
Key
Authentication – Admin,
Sensor Operator
U U
U
G
U
G
U
G
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
Authentication – 3rd
Party
SNMP Client(s)
Show Status U U
Sensor Operator Management
U U
Network Configuration
U U
Administrative Configuration
I U U
Firmware Update
I U U U U I
Install with NSM
I U G U
U
G
U
G
U
G
U G
G
Install with 3rd
Party SNMP
Client
I U U
Change Passwords
I S I S
R
W
Zeroize
(Authenticated)
Z* 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
U
Intrusion Detection/
Prevention Monitoring
Disable SSH/Console Access
U
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
requirements of this FIPS 140-2 Level 2 module.
• The cryptographic module shall provide five distinct operator roles: Admin, Sensor
Operator(s), Network Security Platform Manager, NS-9300 S and 3rd Party SNMP
Client(s). The cryptographic module shall provide role-based authentication and each
change of operator roles shall be authenticated and previous authentication results are
cleared when the module transitions to a power-off state.
• When the module has not been placed in a valid role, the operator shall not have access to
any cryptographic services that could cause modification to the module’s CSPs.
• The cryptographic module shall perform the following tests:
o Power up Self-Tests are performed without operator input:
• Firmware Integrity Test: XYSSL RSA 2048 (Cert. #C1555) using SHA-256
(Cert. #C1555) for hashing
• Cryptographic algorithm known answer tests (KATs) and pairwise
consistency tests (PCT):
• AES ECB 128 Encryption KAT and Decryption KAT (Cert.
#C1556)
• AES GCM Encryption KAT and Decryption KAT (Cert. #C1556)
• RSA 2048 PSS Key Generation/Sign/Verify Pairwise Consistency
Test (Cert. #C1556)
• SHA-1 KAT (Cert. #C1556)
• SHA-256 KAT (Cert. #C1556)
• SHA-512 KAT (Cert. #C1556)
• Block Cipher (CTR) DRBG KAT and SP 800-90A DRBG Section
11.3 Health Checks (Cert. #C1556)
• HMAC SHA-256 KAT (Cert. #C1556)
• HMAC SHA-512 KAT (Cert. #C1556)
• XYSSL RSA 2048 Signature Verification KAT (Cert. #C1555)
(SHA-256 based signatures)
• XYSSL SHA-256 KAT (Cert. #C1555)
• TLS 1.2 KDF KAT (CVL Cert. #C1558)
• SSH KDF KAT (CVL Cert. #C1557)
• EC Diffie-Hellman Shared Secret Primitive KAT (vendor-affirmed
• ECDSA PCT (Cert. #C1556)
• SP 800-90A DRBG Section 11.3 Health Checks
If any of these tests fail the following message will be displayed:
!!! CRITICAL FAILURE !!!
Page 21
FIPS 140-2 POST and KAT...Failed
REBOOTING IN 15 SECONDS
o Conditional Self-Tests:
▪ Block Cipher (CTR) DRBG Continuous Test
▪ NDRNG Continuous Test
▪ RSA KeyGen/Sign/Verify Pairwise Consistency Test (Cert. #C1556)
▪ ECDSA KeyGen Pairwise Consistency Test
▪ External Firmware Load Test –XYSSL RSA 2048 (Cert. #1555) using
SHA-256 (Cert. #C1555) for hashing
If the firmware load test fails the following message will be displayed: "Load Image
with SCP Failed."
• At any time the cryptographic module is in an idle state, the operator shall be capable of
commanding the module to perform the power up self-test by power cycling.
• Data output shall be inhibited during self-tests and error states.
• All Power Up Self-Test are run before data output ports are initialized.
• In the case of failed Power Up Self Tests, the module enters an error state, and
reboots.
• Data output shall be logically disconnected during key generation and zeroization.
• 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.
• Status information shall not contain CSPs or sensitive data that if misused could lead to a
compromise of the module.
• If a non-FIPS validated firmware version is loaded onto the module, then the module is no
longer a FIPS validated module.
• The module shall only support five concurrent SSH operators when SSH is enabled.
• The cryptographic module shall not be configured to transmit files to Trellix Advanced
Threat Detection.
• During initial configuration of the module via its Console Port, the default admin
password should be changed to a password with characteristics as listed in Table 5. Once
the default password has been changed the module must be rebooted.
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 NS9300 P: 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.
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 10 outlines the
recommendations for inspecting/testing physical security mechanisms of the module. If the Admin
finds evidence of tampering, then the module is no longer FIPS compliant.
Table 10 – 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 labels 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 7 depicts the tamper label locations on the cryptographic module for the NS9300 P
platform. There are 9 tamper labels and they are numbered in red. An example tamper label is
shown in Figure 10.
Figure 7 – Tamper Label Placement Top (NS9300 P sensors)
Figure 8 – Tamper Label Placement Front (NS9300 P sensor)
Page 24
Figure 9 – Tamper Label Placement Front (NS9300 P with NS9300 S)
Figure 10 – Tamper Label
Page 25
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.
11 Glossary
Acronym Definition
AES Advanced Encryption Standard
CKG Cryptographic Key Generation
CMVP Cryptographic Module Validation
Program
CO Cryptographic Officer
CSP Critical Security Parameter
CVL Component Validation List
DRBG Deterministic Random Number
Generator
FIPS Federal Information Processing
Standard
HMAC Keyed-Hash Message
Authentication Code
IG Implementation Guidance
IDS Intrusion Detection Systems
IPS Intrusion Prevention Systems
KAT Known Answer Test
KDF Key Derivation Function
KTS Key Transport Scheme
NDRNG Non-Deterministic Random Number
Generator
NSM Network Security Manager
NSP Network Security Platform
PCT Pairwise Consistency Test
RSA Rivest, Shamir, Adleman algorithm
SHA/SHS Secure Hash Algorithm/Standard
SCP Secure Copy