SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700

Certificate

Approved Algorithms (27)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>upgrade<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>upgrade<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

SonicWall, Inc. SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700 Firmware Version: SonicOS/X 7.0.1 Date: March 18th, 2025 Prepared for: Prepared by: SonicWall, Inc. Acumen Security, LLC.

Suite 395 Milpitas, CA 95035 Rockville, MD 20850 United States of America United States of America Phone: Phone: +1 703 375 9820 www.sonicwall.com www.acumensecurity.net Public Material – May be reproduced only in its original entirety (without revision).

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This FIPS 140-3 non-proprietary Cryptographic Module Security Policy for the SonicWall, Inc. SonicWALL NSa 4700, Nsa 5700, NSa 6700, NSsp 10700, NSsp 11700 and NSsp 13700 models provides an overview of the product and a high-level description of how it meets the overall Level 2 security requirements of FIPS 140-3. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. SonicWall, Inc. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material
• May be reproduced only in its original entirety (without revision).

List of Figures Figure 10. Tamper-evident seal placements for NSa 4700/5700/6700 and NSsp 10700/11700/13700 ... 35 Public Material – May be reproduced only in its original entirety (without revision).

This document describes the cryptographic module security policy for the SonicWall, Inc. SonicWALL NSa 4700, Nsa 5700, NSa 6700, NSsp 10700, NSsp 11700 and NSsp 13700 models (FW version: SonicOS/X 7.0.1) cryptographic module (also referred to as the “module” hereafter). It contains the specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The Module, a hardware cryptographic module, meets the overall security level 2 requirements. The following table lists the level of validation for each area in FIPS 140-3: Table 1 - Security Levels Public Material – May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification The module is an Internet security appliance, which provides stateful packet filtering firewall, deep packet inspection, virtual private network (VPN), and traffic shaping services. The module is intended for use by US Federal agencies and other markets that require FIPS 140-3 validated cryptographic modules. The appliance Encryption technology uses Suite B algorithms. Suite B algorithms are approved by the U.S. government for protecting both Unclassified and Classified data. Module Description and Cryptographic Boundary The cryptographic module is defined as a multi-chip standalone hardware module. The cryptographic boundary of the module is the surfaces and edges of the device enclosure, inclusive of the physical ports. The physical form of the Module is depicted below. Figure
3. Front view of the NSa 4700 Figure
4. Front view of the NSa 5700 Figure
5. Rear view of the NSa 4700/NSa 5700 Figure
6. Front view of the NSa 6700 Public Material – May be reproduced only in its original entirety (without revision).

Figure

5. Rear view of the NSa 6700 Figure
6. Front view of the NSsp 10700 Figure
7. Front View of the NSsp 11700 Figure
8. Front View of the NSsp 13700 Figure
9. Rear View of the NSsp 10700/NSsp 11700/NSsp 13700 Public Material – May be reproduced only in its original entirety (without revision).

The cryptographic module tested configurations can be found in the table below: Table 2 - Cryptographic Module Tested Configuration Public Material – May be reproduced only in its original entirety (without revision).

Cryptographic Algorithms The Module implements the Approved and Non-Approved but Allowed cryptographic functions listed in the tables below. The module’s AES-GCM implementation conforms to IG C.H scenario #1 following RFC 5288 for TLS. The module is compatible with TLSv1.2 (RFC 7627) and provides support for the acceptable GCM cipher suites from Section 3.3.1 of SP 800-52 Rev1 or SP 800-52 Rev2. The counter portion of the IV is set by the module within its cryptographic boundary. The construction of the 64-bit nonce_explicit part of the IV is deterministic via a monotonically increasing counter. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established. The module’s AES GCM implementation also conforms to IG C.H Scenario #5 following RFC 8446 for TLS 1.3 and provides support for the acceptable GCM cipher suites from Section B.4 of RFC 8446 and confirms that the IV is generated and used within the protocol’s implementation. Public Material – May be reproduced only in its original entirety (without revision).

N/A Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 3

• Approved Algorithms Note: There are some algorithms, modes, moduli and key sizes that have been CAVP tested but are not implemented/used by the module. Only the algorithms, modes, and key sizes shown in this table are implemented by the module. Public Material
• May be reproduced only in its original entirety (without revision).

Operation: Table 5a

• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Public Material
• May be reproduced only in its original entirety (without revision).

Table 6 - Security Relevant Protocols Used in Approved Mode Modes of Operation Approved Mode of Operation The Approved mode configuration can be determined by the operator, by checking the state of the “Approved Mode” checkbox on the System/Settings page over the web interface or issuing “show fips” command over the console. When the “Approved mode” checkbox is selected, the module executes a compliance checking procedure, examining all settings related to the security rules described below. The operator is responsible for appropriately updating these settings during setup and will be prompted by the compliance tool if a setting has been modified taking the module out of compliance. The “Approved mode” checkbox and corresponding system flag (“fips”), which can be queried over the console, will not be set unless all settings are compliant. The “Approved mode” checkbox and fips system flag are indicators that the module is running in the Approved mode of operation. No parts of the TLS or IKE protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Public Material – May be reproduced only in its original entirety (without revision).

The module is not configured to operate in Approved mode by default. The following steps shall be taken during set-up of the module to enable Approved mode of operation:

1. The default Administrator and User passwords shall be immediately changed and be at least eight (8) characters.
2. The RADIUS/TACACS+ shared secrets shall be at least eight (8) characters.
3. Traffic between the module and the RADIUS/TACACS+ server shall be secured via an IPsec tunnel. *Note: This step only needs to be performed if RADIUS or TACACS+ is supported. • LDAP cannot be enabled in Approved mode without being protected by TLS • LDAP cannot be enabled in Approved mode without selecting 'Require valid certificate from server' • LDAP cannot be enabled in Approved mode without valid local certificate for TLS
4. IKE shall be configured with 3rd Party Certificates or Preshared key for IPsec Keying Mode when creating VPN tunnels. o RSA Certificates lengths shall be 2048-bit or greater in size. o ECDSA Certificates curves shall be P-256, P-384 or P-521 only. or o Preshared key lengths shall be no less than 8 characters.
5. When creating VPN tunnels, ESP shall be enabled for IPSec.
6. Approved algorithms shall be used for encryption and authentication when creating VPN tunnels.
7. Group 14, 19, 20 or 21 shall be used for IKE Phase 1 DH Group. SHA-256 and higher shall be used for Authentication 8. “Advanced Routing Services” shall not be enabled. 9. “Group VPN management” shall not be enabled.
8. SNMP or SSH shall not be enabled.
9. The “SonicWALL Read-Only Admins,” group, satisfies neither the Cryptographic Officer nor the User Role and shall not be used in the Approved mode operation. Note: Once the Approved mode of operation is enabled, SonicOSX enforces all of the above items. (Operators will not be allowed to change these features while in Approved mode of operation.) Additionally: The operator shall not enable the following : • USB interface(s) • Wireless interface • 802.11i wireless security Public Material – May be reproduced only in its original entirety (without revision).

Non-Approved Mode of Operation The Cryptographic Module provides the same set of services in the non-Approved mode as in the Approved mode but allows the following additional administration options and non-approved services which are not used in the Approved mode of operation. The following services shall be disabled before placing the module in Approved mode. The module does not transition to Approved mode until the following services are disabled. • AAA server authentication (the Approved mode requires operation of RADIUS or TACACS+ only within a secure VPN tunnel) • SSH • SNMP Security Rules and Guidance This section documents the security rules for the secure operation of the cryptographic module to implement the security requirements of FIPS 140-3.

1. The module provides two distinct operator roles: User and Crypto Officer.
2. The module provides identity-based authentication for the Crypto Officer and for the User.
3. The module clears previous authentications on power cycle.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The module allows the operator to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by power cycling or resetting the module.
6. Self-tests do not require any operator action.
7. Data output is inhibited during, pre-operational self-tests, zeroization, and error states.
8. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the module.
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The module does not support a maintenance interface or role.
11. The module does not support manual key entry.
12. The module does not have any proprietary external input/output devices used for entry/output of data.
13. The module does not enter or output plaintext SSPs.
14. The module does not output intermediate key values.
15. The module does not support a bypass capability.
16. Firmware upgraded in the non-approved mode cannot be used in the approved mode. (The module enforces the deletion of any firmware upgrade before the approved mode can be entered.) Public Material – May be reproduced only in its original entirety (without revision).

Applicable Implementation Guidance 2.4.B Tracking the Component Validation List The key derivation functions for IKEv1, IKEv2, TLS v1.2 RFC7627, and TLS v1.3 are only used in the context of their respective protocols. C.B Validation Testing of Hash Algorithms and Higher Cryptographic Algorithm Using Hash Algorithms Every approved hash algorithm implementation has been CAVP tested as shown in Table

3. C.F RSA Approved Parameter Sizes in FIPS 186-5 The RSA modulus lengths supported by the module for RSA signature generation are 2048, 3072, and 4096 bits. CAVP testing was performed for the implemented RSA signature algorithm implementation. For FIPS 186-5 signature verification, the module supports the allowed mod sizes of 2048, 3072, 4096. The MillerRabin testing rounds are consistent with Table B.1 of FIPS 186-5. C.H Key/IV Pair Uniqueness Requirements from SP 800-38D Please see Footnote #1. D.C References to the Support of Industry Protocols The KDFs implemented are those described in SP 800-135rev1. (IKEv1, IKEv2, TLS v1.2 RFC7627, and TLS v1.3). All implemented KDFs have been CAVP tested under Cert. #A6598. No parts of the protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. D.H Requirements for Vendor Affirmation to SP 800-133r2 The relevant sections of SP 800-133r2 are Section
4. Self-Initiated Cryptographic Output The module implements a self-initiated cryptographic output capability for IPSec VPN. As part of enabling the service, the Crypto Officer shall configure the IPSec VPN client policy and enable it. Following this, the Crypto Officer shall turn on the "Enable Keep Alive" switch under the "Advanced" tab in the VPN Policy settings. Public Material – May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The module’s ports and associated FIPS 140-3 defined logical interface categories are listed in the tables in this section: Table 7 – Ports and Interfaces
4. Roles, Services, and Authentication Assumption of Roles The cryptographic module provides the roles of Crypto Officer and User. The cryptographic module does not provide a Maintenance role. The built-in “Administrator” is a member of “SonicWALL Administrators” group on the module, and the name used to login may be configured by the Cryptographic Officer role; the default username for the “Administrator” is “admin”. The User role is authenticated using the credentials of a member of the “Limited Administrators” group. The configuration settings required to enable the Approved mode of operation is specified in Section
5. The built-in administrator for which the default username is “admin” which is a member of “SonicWALL Administrators” group has full control privilege to query status and configure all firewall configurations including configure other user privilege. Other members of “SonicWALL Administrators” group have the same full control privilege as built-in administrator (part of “SonicWALL Administrators” group). There is another group called “Limited Administrators”. Members of “Limited Administrators” group can query Control Output Interface is omitted as it is Not Applicable. Public Material – May be reproduced only in its original entirety (without revision).

status and non-critical configuration. An operator is granted privilege by the membership of a particular group after login. Public Material – May be reproduced only in its original entirety (without revision).

Table 8 – Roles, Service Commands, Input and Output The Module supports concurrent operators. Separation of roles is enforced by requiring operators to authenticate using either a username and password, or digital signature verification. The User role requires the use of a username and password or possession of the private key of a user entity belonging to the “Limited Administrators” group. The Crypto Officer role requires a username and password for authentication. Multiple users may be logged in simultaneously, but only a single user-session can have full configuration privileges at any time, based upon the prioritized preemption model described below:

1. The Admin user (SonicWALL Administrators) has the highest priority and can preempt any users.
2. The additional operators who are members of the “SonicWALL Administrators” group can preempt any users except for the Admin user.
3. An operator that is a member of the “Limited Administrators” group can only preempt other members of the “Limited Administrators” group. Session preemption may be handled in one of two ways, configurable from the System > Administration page, under the “On admin preemption” setting: 1. “Drop to non-config mode” – the preempting operator will have three choices: a. “Continue” – this action will drop the existing administrative session to a “non-config mode” and will impart full administrative privileges to the preempting user. b. “Non-Config Mode” – this action will keep the existing administrative session intact and will login the preempting user in a “non-config mode”. c. “Cancel” – this action will cancel the login and will keep the existing administrative session intact. 2. “Log-out” – the preempting user will have three choices: a. “Continue” – this action will log out the existing administrative session and will impart full administrative privileges to the preempting user. b. “Non-Config Mode” – this action will keep the existing administrative session intact and will login the preempting user in a “non-config mode”. c. “Cancel” – this action will cancel the login and will keep the existing administrative session intact. “Non-config mode” administrative sessions will have no privileges to cryptographic functions making them functionally equivalent to User role sessions. The ability to enter “Non-config mode” may be disabled altogether from the System > Administration page, under the “On admin preemption” setting by selecting “Log out” as the desired action. Public Material – May be reproduced only in its original entirety (without revision).

Authentication Methods Table 9

• Roles and Authentication Public Material
• May be reproduced only in its original entirety (without revision).

Services The Crypto Officer role is authenticated using the credentials of the “Administrator” user, which is the member of “SonicWALL Administrators” group (also referred to as “Admin”), or the credentials of other members (users) of the “SonicWALL Administrators” group. The use of “SonicWALL Administrators” provides identification of specific users (i.e., by username) upon whom is imparted full administrative privileges. The Cryptographic Officer role can show all status and configure cryptographic algorithms, cryptographic keys, certificates, and servers used for VPN tunnels. The Crypto Officer sets the rules by which the module encrypts, and decrypts data passed through the VPN tunnels. The authentication mechanisms are discussed in Table 9. The modes of access shown in the table is defined as:

• G = Generate: The module generates or derives the SSP.
• R = Read: The SSP is read from the module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the module.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• Z = Zeroise: The module zeroises the SSP The same services are available in the non-Approved mode of operation. In the non-Approved mode of operation, the non-Approved functions listed in Tables 4 and 5 can be utilized. Public Material
• May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 10

• Approved Services Public Material
• May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 11

• non-Approved Services Public Material
• May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The module is a hardware module with firmware (SonicOS/X 7.0.1) running on it. The Module uses SHA2-

256 (Cert. #A6598) performed over all module firmware as the integrity technique/EDC. The operator can

initiate the integrity test on demand by power cycling the module. The temporary values generated during the integrity test are cleared automatically by the module from the memory after the test is completed. The module does not support the external loading of firmware in the Approved mode of operation. 6. Operational Environment The module operates in a non-modifiable operational environment per FIPS 140-3 specifications, as the module does not support external firmware loading. The chassis of the multi-chip standalone cryptographic modules are opaque within the visible spectrum, and direct observation of the modules' internal components is not possible. The chassis are sealed with either 1 or 2 tamper-evident seals (depending on model), applied during manufacturing. The physical Table 12

• Physical Security Inspection Guidelines Table 13 below lists the number of tamper-evident seals applied per model: Public Material
• May be reproduced only in its original entirety (without revision).

The locations of the tamper-evident seals (highlighted by red rectangles) are indicated in Figure 10 (below): Figure 10. Tamper-evident seal placements for NSa 4700/5700/6700 and NSsp 10700/11700/13700 Public Material – May be reproduced only in its original entirety (without revision).

8. Non-Invasive Security Not Applicable. The module does not implement non-invasive security measures. Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management All SSPs used by the Module are described in this section. SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

SonicWall, Inc. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

Table 14

• SSPs Note: The keys are explicitly zeroized by the module when the zeroize service is executed and are implicitly zeroized when power cycling or the SonicWall, Inc. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Table 15

• Non-Deterministic Random Number Generator Specification Public Material
• May be reproduced only in its original entirety (without revision).

10. Self-Tests The module performs self-tests to ensure the proper operation of the module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. The pre-operational self-tests are performed and shall pass successfully prior to the module providing any data output via the data output interface. CASTs are performed on the condition that the pre-operational self-test complete successfully. Other conditional self-tests are performed when an applicable security function or process is invoked. If the module fails a self-test, the module enters the error state and outputs the error message. The module does not perform any cryptographic operations, and data output is inhibited while in the error state. Self–tests (CASTs) are available on demand by power cycling the module. Pre-Operational Self-Tests

• Firmware Integrity Test: SHA2-256 (256-bit EDC) Conditional Self-Tests Cryptographic Algorithm Self Tests
• AES-CBC Decrypt CAST
• AES GCM Encrypt CAST
• AES GCM Decrypt CAST
• CVL: IKEv1 KDF CAST
• CVL: IKEv2 KDF CAST
• CVL: TLS 1.2 KDF CAST
• CVL: TLS 1.3 KDF CAST
• DRBG: SP 800-90A Section 11.3 Health Tests (Instantiate, Generate, Reseed)
• DSA CAST (Pairwise Consistency Test)
• ECDSA Signature Generation CAST
• ECDSA Signature Verification CAST
• HMAC-SHA-1 CAST
• HMAC-SHA2-256 CAST
• HMAC-SHA2-384 CAST
• HMAC-SHA2-512 CAST
• KAS-FFC-SSC Primitive “Z” CAST (SP 800-56Arev3)
• KAS-ECC-SSC Primitive “Z” CAST (SP 800-56Arev3)
• RSA Signature Generation CAST (Key size: 2048)
• RSA Signature Verification CAST (Key size: 2048)
• SHA-1 CAST
• SHA2-256 CAST
• SHA2-384 CAST
• SHA2-512 CAST
• NIST SP 800-90B Start-Up Health Tests
• NIST SP 800-90B Continuous Health Tests Public Material
• May be reproduced only in its original entirety (without revision).

Conditional Pairwise Consistency Tests • ECDSA Pairwise Consistency Test • DSA Pairwise Consistency Test • RSA Pairwise Consistency Test If any of the tests described above fail, the cryptographic module enters the error state. No security services are provided in the error state. No cryptographic output is started until all tests are successfully completed. This effectively inhibits the data output interface. When all tests are completed successfully, the Test LED is turned off.

11. Life-Cycle Assurance Crypto Officer Guidance The following steps shall be performed by the Crypto Officer (CO) to configure the required roles and place the module in the Approved mode of operation:
12. Apply power to the module. On a GPC, connect to the module’s console using the serial port. The network interface drivers/login prompt will only be available once all power-up self-tests have completed successfully.
13. Login using the vendor provided default login and password. The default password and login shall be changed/updated.
14. Configure management IP address and Gateway.
15. Over the web interface, proceed to system settings and update the settings to be consistent with Section 2 of this document with the assistance of compliance checking procedure and then enabling Approved mode using the checkbox. The FIPS checkbox does not place the module in Approved mode until the settings in the Modes of Operation Section are met. Then click OK. The system automatically restarts.
16. Observe that the module self-tests execute automatically before a log in is possible. Observe that the “FIPS enabled checkbox” is checked/enabled to indicate that the module is in the Approved mode of operation. This can be verified in the system/settings page. In addition, on the dashboard, the operator can verify the version of the module.
17. Proceed to create the roles specified in Section 4 of this document. Passwords and Digital signatures required for authentication to each role should be configured or installed as appropriate. *Note 1: When the "Approved mode" checkbox is selected, the module executes a compliance checking procedure, examining all settings related to the security rules described previously in this document. The operator is responsible for updating these settings appropriately during setup and will be prompted by the compliance tool if a setting has been modified, taking the module out of compliance. The "Approved mode" checkbox and corresponding system flag ("fips") which can be queried over the console will not be Public Material – May be reproduced only in its original entirety (without revision).

set unless all settings are compliant. The "Approved mode" checkbox and “fips” system flag are indicators that the module is running in the Approved mode of operation. *Note 2: The keys and SSPs generated in the cryptographic module during Approved mode of operation shall not be used when the module transitions to non-Approved mode and vice versa. While the module transitions from Approved to non-Approved mode or from non-Approved to Approved mode, all SSPs shall be zeroized by the Crypto Officer using the “Zeroize” service. If transitioning from the non-Approved to Approved mode, the CO shall zeroize all plaintext keys and SSPs by issuing “Zeroize” service and then the CO shall follow the CO Guidance (above) in this section to place the module in Approved mode of operation. Configuration Management SonicWall uses Perforce software for the management of source code artifacts and for hardware and documentation version control. KlocWork is used for static code analysis. The module is developed using high level programming languages C++ and C. Assembly code is only used for select performance enhancements. The module is securely delivered from Sonicwall to customers via the mechanism specified by the customer. FedEx, UPS, or any other freight forwarder of their choice can be utilized. Tracking numbers are used to track and confirm delivery to the authorized operator. The Crypto Officer should check the package for any irregular tears or openings. If the Crypto Officer suspects tampering has occurred, they should immediately contact Sonicwall, Inc. The end of life for the module meets the FIPS 140-3 requirements. The sanitization requirements are met by zeroising the module. Public Material – May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks The SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, and NSsp 13700 are capable of mitigating other attacks using the following features (dependent on licensing). Capture ATP The Capture ATP Service revolutionizes advanced threat detection and sandboxing with a cloud-based, multi-engine solution for stopping unknown and zero-day attacks at the gateway. Capture ATP blocks zero-day attacks before they enter your network. It lets you establish advanced protection against the changing threat landscape and analyze a broad range of file types. Gateway Anti-Virus ICSA-certified Gateway Anti-Virus protection combines network-based anti-malware with a dynamically updated cloud database of tens of millions of malware signatures. Dynamic spyware protection blocks the installation of malicious spyware and disrupts existing spyware communications. IPS Cutting-edge IPS technology protects against worms, trojans, software vulnerabilities and other intrusions by scanning all network traffic for malicious or anomalous patterns, thereby increasing network reliability and performance. Comprehensive Anti-Spam Service SonicWall Comprehensive Anti-Spam Service offers small-to medium sized businesses >99% effectiveness against spam, dropping >80% of spam at the gateway, while utilizing advanced anti-spam techniques like Adversarial Bayesian™ and machine-learning filtering. DNS Filtering DNS filtering blocks malicious websites or applications at the DNS layer to filter out harmful or inappropriate content without enabling TLS decryption and adversely affecting performance. Network Access Control Network access control integration provides network access control for SonicWall customers by integrating with Aruba ClearPass, giving you comprehensive and precise profiling, authentication, and authorization for systems and devices trying to access your IT resources. SonicOS provides a RESTful API that will support Aruba ClearPass as NAC to integrate with SonicWall NGFW. This architecture will turn static security into contextual security to provide more flexible and advanced security protection. Content Filtering Service Content Filtering Services (CFS) lets you enforce Internet use policies and control internal access to inappropriate, unproductive and potentially illegal web content with comprehensive content filtering. Reputation-based CFS 5.0 provides a reputation score that forecasts the security risk of a URL across 93 web categories. Public Material – May be reproduced only in its original entirety (without revision).

Other The modules also include basic DNS security, deep packet inspection for SSL, and a botnet service. Public Material – May be reproduced only in its original entirety (without revision).

References and Definitions The following standards are referred to in this Security Policy. Public Material – May be reproduced only in its original entirety (without revision).

Table 16

• References Public Material
• May be reproduced only in its original entirety (without revision).

Table 17

• Acronyms and Definitions Public Material
• May be reproduced only in its original entirety (without revision).