Forcepoint NGFW Cryptographic Kernel Module

Certificate

Approved Algorithms (15)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Forcepoint NGFW Cryptographic Kernel Module
  %% 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["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input 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["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 Forcepoint NGFW Cryptographic Kernel Module
  %% 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["[high] Unauthenticated / self-test / status service surface<br/><i>Show status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Forcepoint NGFW Cryptographic Kernel Module 10900-A Stonelake Blvd, Ste. 350, Austin, TX 78759, USA www.forcepoint.com

Revision History A Initial release. B CMVP comment responses. C CMVP comment responses. © 2024 Forcepoint. This document may be freely reproduced and distributed whole and intact including this

Acronyms and Abbreviations Term Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface CBC Cipher Block Chaining CFB Cipher FeedBack CMVP Cryptographic Module Validation Program CO Crypto Officer CSP Critical Security Parameter ECB Electronic Code Book FIPS Federal Information Processing Standard GCM Galois Counter Mode HMAC Keyed-Hash Message Authentication Code IG Implementation Guidance ISO/IEC International Organization for Standardization / International Electrotechnical Commission I/O Input/Output IV Initialization Vector KAT Known Answer Test MAC Message Authentication Code NIST National Institute of Science and Technology N/A Not Applicable

Term Definition OFB Output FeedBack POST Power-on Self-Test SHA Secure Hash Algorithm SSP Sensitive Security Parameter Preface This is a non-proprietary Cryptographic Module Security Policy for the Forcepoint NGFW Cryptographic Kernel Module (Software Version: 3.0) from Forcepoint. This Security Policy describes how the Forcepoint NGFW Cryptographic Kernel Module (referred as crypto module, module, library) meet the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) website at https://csrc.nist.gov/projects/cryptographicmodule-validation-program This document also describes how to run the module in a secure Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-3 validation of the module.

The Forcepoint NGFW Cryptographic Kernel Module meets overall level 1 security requirements for FIPS 140-3 as summarized in the table below: TABLE 1: SECURITY LEVELS N/A N/A [Number Below]

N/A [Number Below] 2. Cryptographic Module Specification 2.1.Module Overview The Forcepoint NGFW Cryptographic Kernel Module is a module that provides general-purpose cryptographic algorithms for Forcepoint applications. The binary of the module and the integrity check file are qcl_fips.ko and checksums.fips. Assembly language optimizations are used in the cryptographic module implementation. The module contains the following cryptographic functionality:

• Cryptographic hash functions
• Message authentication code functions
• Symmetric key encryption and decryption 2.2.Approved Mode The cryptographic module supports only an approved mode. The cryptographic module is initialized and set in the approved mode when the kernel module is loaded. The calling application can call the ssh_crypto_get_certification_mode function to confirm the current mode of operation. It returns SSH_CRYPTO_CERTIFICATION_FIPS_140_2 to indicate that the module is indeed in the approved mode.

The module supports the following approved functions:

• AES: ECB, CBC, OFB, CFB128 and GCM modes
• SHS: hashing
• HMAC: message integrity 2.3.Module Description The cryptographic module is a software module of type multi-chip standalone. This cryptographic module performs cryptographic operations for the Forcepoint Next Generation Firewall kernel. The cryptographic boundary of the module is the compiled, binary code of the module itself. The Tested Operational Environment’s Physical Perimeter (TOEPP) of the module is the edges of the enclosure of the appliance that the module is running on. Figure 1 and Figure 2 provide an illustration of the description above.

The following block diagram provides an illustration of the following Operational environments: NGFW OS 10 on Linux 4.19 running on NGFW 3410 with Intel Xeon Gold 6230N with PAA; NGFW OS 10 on Linux 4.19 running on NGFW N120W with Intel Atom C3338 with PAA; NGFW OS 10 on Linux 4.19 running on NGFW N120W with Intel Atom C3338 without PAA FIGURE 1: SOFTWARE BLOCK DIAGRAM 1

The following block diagram provides an illustration of the following Operational environment: NGFW OS 10 on Linux 4.19 on ESXi 7.0 running on Dell PowerEdge R440 with Intel Xeon Silver 4208 with PAA FIGURE 2. SOFTWARE BLOCK DIAGRAM 2

2.4.Test Configuration The following tested configurations are covered in this security policy: TABLE 2: TESTED OPERATIONAL ENVIRONMENTS # AES-NI AES-NI AES-NI None

TABLE 3: VENDOR AFFIRMED OPERATIONAL ENVIRONMENTS # NGFW 3401 NGFW 2210 NGFW 2205 NGFW 2201 NGFW N120 NGFW N60 Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when the module is ported to the vendor affirmed platforms that are not listed on the validation certificate.

2.5.Approved Algorithms The following associated CAVP certificates are used by the cryptographic module:  Forcepoint NGFW Cryptographic Kernel Module (Cert. #A2166) The approved algorithms implemented by the module alongside their mapping to the certificates above alongside algorithms use by services are listed in the table below. TABLE 4: APPROVED ALGORITHMS #A2166 Used for encryption and decryption services

#A2166 Used for secure hashing services Message Authentication Code #A2166 Used for message authentication services and module integrity

The module does not implement any non-approved algorithms allowed in the approved mode of operation. The module does not implement any non-approved algorithms allowed in the approved mode of operation with no security claimed. 3. Cryptographic Module Interfaces 3.1.Ports and Interface Overview The figures in section Module Description identify the physical interfaces to the cryptographic module. The following table maps the physical interface to logical interfaces and supported data. TABLE 5: PORTS AND INTERFACES N/A N/A N/A N/A N/A N/A

4. Roles, Services, and Authentication 4.1.Roles The mapping of the cryptographic module’s roles services is in the table below: TABLE 6: ROLES, SERVICE COMMANDS, INPUT AND OUTPUT Crypto officer Crypto officer User User Indicator of success or failure User User Version User Encrypted or decrypted User Encrypted or decrypted User Message digest User authentication code

Roles and Authentication All roles are assumed implicitly based on the API that is currently being executed. TABLE 7: ROLES AND AUTHENTICATION N/A N/A All services listed in the table below can be accessed in approved mode and when in this mode exclusively use the security functions listed in Approved Algorithms. Notes on the content of Table 8: Approved Services:  In the ‘Access Rights to Keys and/or SSPs’ column:

• 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 = Zeroize: The module zeroizes the SSP. In the ‘Keys and/or SSPs’ column: For a complete description of SSP referenced from the table, see section Sensitive Security Parameter Management.

Roles, Services, and Authentication TABLE 8: APPROVED SERVICES

• Show status
• N/A N/A N/A (0) from associated API N/A N/A N/A (0) from associated API N/A N/A (0) from associated API N/A

Roles, Services, and Authentication Perform selftests

• AESCBC, AESCFB128, AESECB, AESOFB, AESGCM, SHA2256, SHA2512, HMACSHA-1, HMACSHA2256, HMACSHA2512 E (0) from associated API

Roles, Services, and Authentication Perform zeroization

• Show module versioning information N/A N/A Z (0) from associated API N/A N/A (0) from associated API

Roles, Services, and Authentication encryption and decryption

• AESCFB128, W, E SSH_CRYPTO_OK (0) from associated API

Roles, Services, and Authentication authenticated W, E SSH_CRYPTO_OK (0) from associated API secure hash (SHS) SHA2224, SHA2256, SHA2384, N/A N/A SSH_CRYPTO_OK (0) from associated API

Roles, Services, and Authentication message authentication

• HMACSHA-1, HMACSHA2224, HMACSHA2256, HMACSHA2384, HMACSHA2-512 W, E SSH_CRYPTO_OK (0) from associated API

Software/Firmware Security

5. Software/Firmware Security 5.1.Software Integrity The Forcepoint NGFW Cryptographic Kernel Module’s software integrity is checked on startup as described in section Self-Tests. The module runs the self-test functions to check the software integrity as well as the cryptographic algorithms used. Any failures during these tests will result in the module entering an error state where it will provide an error indicator. The module is stored along with a ‘checksums.fips’ file which contains an HMAC-SHA-256 MAC of the module binary. The module checks its own integrity upon every load, and the operator can trigger an on-demand check of the module by either re-loading the module or executing the dedicated API function ‘ssh_crypto_library_run_self_tests’.
6. Operational Environment The module supports a modifiable operating environment as defined in ISO/IEC 19790:2012. The module operates on the NGFW OS 10 operating system, which is a hardened operating system based on GNU/Linux 4.19.
7. Physical Security The module was tested on a Dell PowerEdge R440, the Forcepoint NGFW 3410, and NGFW 120W appliances. These appliances consist of production-grade components with standard passivation and a production-grade enclosure.
8. Non-Invasive Security N/A: Section 8, Non-invasive security is non-Applicable as there are currently no requirement in SP 800-140F.
9. Sensitive Security Parameter Management 9.1.Sensitive Security Parameters The following table lists Sensitive Security Parameters (SSP) used to perform approved security function supported by the cryptographic module. The following notes should be observed when reading the table: • When reading the ‘strength’ column, the listed security strength is calculated using methods in FIPS 140-3 IG D.B, ‘Strength of SSP Establishment Methods’. • When reading the ‘Security Function and Cert Number’ column, this is the security function that will consume the SSP. • When reading the ‘Use and Related Keys’ column, this will contain the other SSPs that are either established via the SSP, other SSPs that are used to establish the SSP, or if it is a key pair the associated public or private component will be listed as well.

Sensitive Security Parameter Management TABLE 9: SSPS HMAC-SHA2224, HMACSHA2-256, HMAC-SHA2384, HMACSHA2-512 AES Symmetric N/A AES keys used for general encryption and decryption services HMAC keys used for general message authentication services N/A N/A Related SSPs: None Related SSPs: None N/A

Sensitive Security Parameter Management Module Integrity Check N/A N/A Related SSPs: None 7.5, this key is only used for the approved integrity technique, and as such is not considered an SSP. However, it has been included in this table for completeness.

Self-Tests 10. Self-Tests 10.1. Pre-Operational Tests The pre-operational self-tests are run automatically when the module is loaded to confirm the software integrity, and to check the continued correct operation of each of the implemented cryptographic algorithms used in support of the integrity checks. User may initiate the on-demand pre-operational self-tests by calling the API function ssh_crypto_library_self_tests. While the module is running these self-tests, all data output interfaces are disabled until the successful completion of the self-tests. If one of the pre-operational self-tests fails or a conditional self-test fails, the module enters an error state. Error indicators are output on the status output interface specifying which self-test failed within the module. In this state, all cryptographic functions and data output via the module’s data output interfaces is inhibited. If the module is re-loaded, it will rerun all self-tests. Successful completion of the self-tests will clear the error state, and the module will return to the approved mode of operation. For any consecutive failure of the self-tests during reload, the module will remain in an error state. If the problem persists, CO intervention is required to either perform a restore to factory default settings and reinstall, or power-off the Forcepoint NGFW and contact Forcepoint Customer Support. TABLE 10: PRE-OPERATIONAL SELF-TESTS Kernel Module Integrity Test SSH_CRYPTO_TEST_INTEG_DI GEST or SSH_CRYPTO_TEST_INTEG_IN VALID and error state entry 10.2. Conditional Tests The module automatically performs conditional self-tests based on the module operation. These self-tests do not require operator input to initiate. Implemented conditional tests are in one of the following forms:

• Known Answer Test (KAT) All KATs are performed immediately following the pre-operational self-tests when the module is loaded, and can be performed on-demand by the User by calling the API function ssh_crypto_library_self_tests. TABLE 11: CONDITIONAL SELF-TESTS (SOFTWARE) KAT test for SSH_CRYPTO_TEST_CIPHER and error state entry KAT test for SSH_CRYPTO_TEST_CIPHER and error state entry

Life-Cycle Assurance KAT test for authenticated SSH_CRYPTO_TEST_CIPHER and error state entry KAT test for authenticated SSH_CRYPTO_TEST_CIPHER and error state entry KAT test for SSH_CRYPTO_TEST_HASH and error state entry KAT test for SSH_CRYPTO_TEST_MAC and error state entry 11. Life-Cycle Assurance 11.1. Installation The cryptographic module is delivered as part of the Forcepoint NGFW firmware for appliances and Forcepoint NGFW software installation package for virtualization platforms. The FIPS 140-3 validated Forcepoint NGFW Cryptographic Kernel Module version 3.0 is included in Forcepoint NGFW firmware and software installation package version 6.10.3.26158. The Forcepoint NGFW component providing the firewall and VPN capabilities on a Linux-based operating system is referred to as NGFW Engine. When NGFW Engine is initialized in approved mode of operation, the Forcepoint NGFW Cryptographic Kernel Module is loaded. Once loaded, the Forcepoint NGFW Cryptographic Kernel Module supports only the approved mode of operation. The following sections detail how to ensure that the validated version of the module is installed and being utilized by the Forcepoint NGFW. 11.1.1. Downloading the Forcepoint NGFW Cryptographic Kernel Module Forcepoint NGFW appliances are delivered in an operational state with the most recent firmware preinstalled. The NGFW firmware must be upgraded to a NGFW firmware version containing the FIPS 140-3 validated Forcepoint NGFW Cryptographic Kernel Module version 3.0 to be placed in the approved mode of operation. Note: Upgrading an appliance to a Forcepoint NGFW firmware version is necessary even if the same version was installed previously. This is required because the file system checksum is stored during the upgrade process. A method to update the firmware image with a SHA2-512 checksum signed with ECDSA P-521 is provided. Prior to installing the new image, its associated checksum is checked. If the signature check fails, the new firmware is ignored, and the current firmware remains loaded. If the signature check passes, the new image will be installed and executed after the appliance is restarted. Failure to follow this will result in the module operating in a non-compliant state.

Life-Cycle Assurance Forcepoint NGFW may also be installed on supported virtualization platforms. An existing virtual machine must be upgraded to a Forcepoint NGFW software version containing the FIPS 140-3 validated Forcepoint NGFW Cryptographic Kernel Module version 3.0 to be placed in the approved mode of operation by reinstalling the Forcepoint NGFW software. The installation file is downloaded as follows:

1. Login to the Forcepoint Support https://support.forcepoint.com
2. Proceed to the Forcepoint NGFW downloads section.
3. Download the installation file a. For upgrading the NGFW appliance firmware, download the .zip file b. For installing the NGFW software on a virtual machine, download the .iso file
4. Verify the SHA checksum Note: The correct checksums are shown on the download page and can also be found in the release notes. 11.1.2. Upgrading on a Forcepoint NGFW Appliance After downloading the firmware, the operator can upgrade the NGFW appliance to a version containing the validated module:
5. Save the NGFW firmware version upgrade .zip file to the root directory of a USB drive. Note – The firmware upgrade .zip file must be in the root directory of the media.
6. Connect to the appliance using a monitor and keyboard.
7. Power on the appliance and start the NGFW Configuration Wizard.
8. Select the Firewall/VPN option.
9. Select Upgrade. The Select Source Media dialog opens.
10. Select the appropriate media type and select OK. The firmware update signature is verified.
11. Select OK. The upgrade starts.
12. Select Set kernel in FIPS mode after restart. Select OK.
13. The NGFW appliance restarts and displays the upgraded version.
14. Verify the NGFW firmware version to ensure that the correct NGFW firmware version is loaded. This process also results in the NGFW appliance being configured to load the Forcepoint NGFW Cryptographic Kernel Module. 11.1.3. Installing on a Virtual Machine After downloading the installation package, the operator can install the NGFW software containing the validated module on a virtual machine: 1. 2. 3.
15. Connect the DVD drive of the virtual machine to the .iso file. Restart the virtual machine. The License Agreement appears. Type YES, then press Enter to accept the license agreement and continue with the configuration. Select the type of installation: a. Type 1 for the normal Full Install. b. Type 2 for the Full Install in expert mode if you want to partition the hard disk manually
16. Enter the number of processors: a. For a uniprocessor system, type 1, then press Enter.

Life-Cycle Assurance 6. 7. 8. 9. b. For a multiprocessor system, type 2, then press Enter. Continue in one of the following ways: a. If you selected Full Install, type YES, then press Enter to accept automatic hard disk partitioning. b. If you selected Full Install in expert mode, install the engine in expert mode. The installation process starts. When the installation is ready press Enter to reboot. The virtual machine restarts and displays the installed version. Verify the NGFW software version to ensure that the correct NGFW software version is loaded. 11.2. Setting up a FIPS-Compatible Configuration on the Engine To configure the NGFW Engine:

1. Start the NGFW Configuration Wizard as instructed in the Configuring the Engine in the Engine Configuration Wizard section of the NGFW Installation Guide.
2. Configure the Operating System settings as instructed in the Configuring the Operating System Settings section of the NGFW Installation Guide. Select Restricted FIPS-compatible operating mode. The SSH daemon and root password options are automatically disabled in the Engine Configuration Wizard. Select FIPS 140-3 compatible mode as well.
3. Configure the network interfaces according to your environment as instructed in the Configuring the Network Interfaces section of the NGFW Installation Guide.
4. Contact the Management Server as instructed in the Contacting the Management Server section of the NGFW Installation Guide. Enter node IP address manually is selected by default and other IP address options are disabled when FIPS-compatible operating mode is enabled. The engine restarts. Note: To migrate from FIPS-compatible operating mode to FIPS 140-3 compatible mode, the engine must be reset to factory default settings and reinstalled. 11.3. Verifying Activation of FIPS 140-3 Compatible Operating Mode Restricted FIPS 140-3 compatible operating mode must be enabled during the initial configuration of the engine. The following steps describe how to verify that FIPS 140-3 compatible operating mode has been activated. To verify activation of FIPS 140-3 compatible operating mode:
5. Verify that the following messages are displayed on the console when the engine restarts: FIPS: rootfs integrity check OK (Displayed after the root file system integrity test has been executed successfully) FIPS power-up tests succeeded (Displayed after the FIPS 140 power-up tests have been executed successfully)
6. Continue as instructed in the After Successful Management Server Contact section of the NGFW Installation Guide. Note: If the engine does not enter FIPS-compatible operating mode even though it is configured to do so, or if the power-up tests fail (a power-up test error message is displayed or the success message is not displayed), the engine must be reset to factory default settings and reinstalled.

Life-Cycle Assurance 11.4. Secure Initialization The cryptographic module is initialized by loading the kernel module before any cryptographic functionality is available. The kernel module is loaded as follows: # modprobe qcl_fips.ko • qcl_fips.ko is the name of the kernel module The operation is performed automatically by the Forcepoint NGFW engine when configured to operate in the approved mode. 11.5. Secure Sanitization The stored keys and CSPs are zeroized when the application calls the appropriate API function: ssh_cipher_free and ssh_mac_free. It is the calling application’s responsibility to call the zeroization API function to zeroize the keys and CSPs. Temporary key material is zeroized automatically by the module when no longer needed. All keys and CSPs can be zeroized by powering off the platform where the module is running. 11.6. Guidance 11.6.1. Identifying the Module Version The version of the module (3.0) is stored within the module binary itself (qcl_fips.ko), and is made available to a calling application via the API call ssh_crypto_library_get_version. 11.6.2. Non-Approved Mode of Operation The module does not support a non-approved mode of operation. 11.6.3. Resetting the Engine to Factory Default Settings Resetting the engine to factory default settings is not part of the normal installation procedure. There is no need to reset the engine to factory default settings before starting to use it for the first time. These instructions can be used to reset the engine to factory default settings when necessary, such as when initial configuration has been completed without enabling the Restricted FIPS-compatible operating mode, during use, or when the engine is being removed from use. To reset the engine to factory default settings:

1. Reboot the engine and select System restore options from the boot menu. Forcepoint NGFW System Restore starts.
2. Enter 2 for Advanced data removal options.
3. Enter one of the following options: • •

If you selected Custom, enter the number of overwrite passes. A larger number of overwrites is more secure, but it may take a considerable amount of time depending on the engine storage capacity. 11.6.4. Recovering from a FIPS 140 Self-test Failure If the FIPS 140 power-up self-tests fail, or the engine does not enter FIPS-compatible operating mode, the engine must be reset to factory default settings and reinstalled according to these instructions. Begin by Resetting the engine to factory default settings.

Mitigation of Other Attacks To recover from a FIPS 140 self-test failure:

1. Reset the engine to factory default settings as instructed in Error! Reference source not found.
2. Repeat the engine version installation/upgrade as instructed in sections 11.1.1, 11.1.2 and 11.1.3 of this document. Note: The firmware upgrade step from Section 11.1.2 is only applicable to hardware engines.
3. Configure the firewall engine and enable FIPS-compatible operating mode as instructed in Setting up a FIPSCompatible Configuration on the Engine
4. Verify that FIPS-compatible operating mode is activated as instructed in Verifying Activation of FIPS 140-3 Compatible Operating Mode 11.6.5. User Guidance The notes below provide additional guidance and policies that must be followed by module operators: • Use of AES GCM: o The module complies with Scenario 3 from FIPS 140-3 IG C.H via the module’s ssh_cipher_generate_iv_ctr API. The module maintains a deterministic 64-bit non-repetitive counter that increments by 1 any time the API is called. The API will return ‘SSH_CRYPTO_INVALID_OPERATION’ and fail if the 64-bit counter has wrapped around. The IV’s total length is 96 bits, with 32 of the bits being the ‘name’ and 64 bits being the described deterministic non-repetitive counter. o If the module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be redistributed. • Zeroization: When a cryptographic key is no longer used, the key must be zeroized and freed using the ssh_cipher_free and ssh_mac_free functions for symmetric key encryption/decryption and message authentication keys, respectively. 11.6.6. External Guidance Documents Forcepoint NGFW Installation Guide: https://help.forcepoint.com/docs/ngfw/v610/install/ngfw_6100_ig_a_en-us.pdf Forcepoint NGFW Product Guide: https://help.forcepoint.com/docs/ngfw/v610/mgmt/ngfw_6100_pg_a_en-us.pdf
5. Mitigation of Other Attacks This section is not applicable. The modules do not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation.

Referenced URLs

• www.forcepoint.com
• https://csrc.nist.gov/projects/cryptographic-
• https://support.forcepoint.com
• https://help.forcepoint.com/docs/ngfw/v610/install/ngfw_6100_ig_a_en-us.pdf
• https://help.forcepoint.com/docs/ngfw/v610/mgmt/ngfw_6100_pg_a_en-us.pdf