Firepower Threat Defense Virtual Cryptographic Module

Certificate

Approved Algorithms (48)

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

flowchart LR
  %% Deterministic review-risk graph for Firepower Threat Defense Virtual Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</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>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Firepower Threat Defense Virtual Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</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>operating system<br/>linux<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 C3,C5,C6 clueLow;

Security Policy, page by page

Cisco Systems, Inc. ISO/IEC 19790 and FIPS 140-3 Non-Proprietary Security Policy for Firepower Threat Defense Virtual Cryptographic Module Last Updated: June 13, 2024, Version 0.4 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Table of Content List of Figures List of Tables

Cryptographic Module (hereinafter referred to as FTDv or the Module), software version 7.0.5. The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and The security requirements cover areas related to the design and implementation of a cryptographic mitigation of other attacks. The following table indicates the actual security levels for each area of the Table 1 Security Levels The module has an overall security level of 1. The Module is a multi-chip standalone software module deployed as the virtualized version of the Cisco Firepower Threat Defense which houses ASA, FX-OS and Firepower solutions with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FX-OS throughout this document). The module can be used in single context mode, and in routed or transparent mode to support TLSv1.2 (RFC7627), SSHv2, IPsec/IKEv2 and Cryptographic Cipher Suite B, which delivers enterprise-class security for business-to-enterprise networks in a virtual environment. The module has been tested on the following Operational Environments.

Table 2 Tested Operational Environment Figure 1 UCS C220 M5 front view with Bezel Figure 2 UCS C220 M5 front view without Bezel Figure 3 UCS C220 M5 rear view Figure 4 ENCS 5412 front view1 Figure 5 ENCS 5412 rear view https://www.cisco.com/c/dam/global/da_dk/assets/training/seminariamaterials/enterprise_network_compute_system_encs_.pdf

Table 3 Vendor Affirmed Operational Environments The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Mode of operation The module has one approved mode of operation and is always in the approved mode of operation after initial operations are performed (See Section 11). The module does not claim implementation of a degraded mode of operation. Section 4 provides details on the service indicator implemented by the module. The table below lists all Approved or Vendor-affirmed security functions of the module, including specific key size(s) -in bits unless otherwise noted- employed for approved services, and implemented modes of operation. 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.

Table 4 Approved Algorithms Notes:

• Algorithm Cert. #A3376 was tested for the OE without PAA.
• The module’s AES-GCM implementation conforms to FIPS 140-3 IG C.H scenario #1 following RFC 5288 for TLS. The module is compatible with TLSv1.2 and provides support for the acceptable GCM cipher suites from SP 800-52 Rev1, Section 3.3.1. The operations of one of the two parties involved in the TLS key establishment scheme were performed entirely within the cryptographic boundary of the module being validated. The counter portion of the IV is set by the module within its cryptographic boundary. 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 uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. 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.
• No parts of SSH, TLS and IKE protocols, other than the KDFs, have been tested by the CAVP and CMVP.

As the module can only be operated in the Approved mode of operation, and any algorithms not listed in table 4 above will be rejected by the module while in the approved mode, the tables defined in SP800140B for the following categories are missing from this document:

• Non-Approved Algorithms Allowed in Approved Mode of Operation
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in Approved Mode of Operation Cryptographic boundary The module is defined as a multi-chip standalone software module (inside red dashed area). The cryptographic boundary includes all of the module’s software components, including Guest OS, API and FOM Crypto Library (Cisco FIPS Object Module). The physical perimeter is the Tested Operational Environment’s Physical Perimeter (TOEPP) on which the module runs. Tested Platform TOEPP Processor API Hypervisor Guest OS / FTD API FOM Figure 6 Block Diagram The Block Diagram above is comprised of the following components:
• Processor: Chip on the tested platforms handle all processes
• API: Host API between hypervisor and processor
• Hypervisor: VMWare ESXi 6.7, 7.0 or NFVIS 4
• Guest OS/FTD: Linux 4 (FX-OS)
• API = Guest API between the FMC Module and FOM Crypto library
• FOM = Cisco FIPS Object Module (FOM) Crypto Library

The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The module’s logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, control output and status output) as follows.

Table 5 Ports and Interfaces

The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Table 6 Roles and Services Table 7 below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module. 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. N/A = The service does not access any SSP during its operation.

As the module can only be operated in the Approved mode of operation, and as such any algorithms not listed in Table 4 above will be rejected by the module while in the approved mode, the required table defined in SP800-140B for Non-Approved Services is missing from this document.

Integrity techniques The module is provided in the form of binary executable code. To ensure the software security, the module is protected by RSA 2048 modulus with SHA2-512 (RSA and SHA2-512 Cert. #A2952 and #A3376) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary by/ at the factory and used for software integrity test only at the pre-operational self-test. At crypto module library initialization, the signature is recalculated and compared to the hardcoded build-time generated signature value. If at load time the signature does not match, the crypto module library exits with error. If failure occurs during self-test, all crypto functionality is disabled. Integrity test on-demand Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power cycle or reboot the tested platform to initiate the software integrity test on-demand.

The module is a software module, which is operated in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module’s software version running on each tested platform is 7.0.5. The module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators.

The FIPS 140-3 physical security requirements do not apply to the Module since it is a software module.

Currently, non-invasive security is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module.

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module.

Table 8 SSPs Table 9 Non-Deterministic Random Number Generation Specification

When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs preoperational self-tests. The operating system is responsible for the initialization process and loading of the library. The module is designed with a default entry point (DEP) which ensures that the self-tests are initiated automatically when the module is loaded. Prior to the module providing any data output via the data output interface, the module performs and passes the pre-operational self-tests. Following the successful pre-operational self-tests, the module executes the Conditional Cryptographic Algorithm Selftests (CASTs). The self-test success or failure results are an output of the return value of the library load API call, which is functioning as the self-test status indicator. If any one of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled.

The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state. Below are the details of the self-tests conducted by the module. Pre-operational self-tests:

• Pre-operational software integrity test
• RSA 2048 modulus sigver with SHA2-512 KAT
• Software Integrity Test (RSA 2048 modulus sigver with SHA2-512) Conditional self-test:
• Conditional cryptographic algorithm self-tests (CASTs)
• AES-CBC Encrypt KATs
• AES-CBC Decrypt KATs
• AES-GCM Authenticated Encrypt KATs
• AES-GCM Authenticated Decrypt KATs
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: CTR_DRBG Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1
• ECDSA P-256 with SHA-256 SigGen KAT
• ECDSA P-256 with SHA-256 SigVer KAT
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-384 KAT
• HMAC-SHA2-512 KAT
• KAS-ECC-SSC Primitive Z KAT
• KAS-ECC-SSC Primitive Z KAT
• RSA 2048 modulus with SHA-512 SigGen KAT
• RSA 2048 modulus with SHA-512 SigVer KAT
• SHA-1 KAT
• SP800-135 SSH-KDF KAT
• SP800-135 TLS-KDF KAT
• SP800-135 IKE-KDF KAT
• Conditional pair-wise consistency tests (PCTs)
• RSA PCT
• ECDSA PCT
• KAS-ECC PCT
• KAS-FFC PCT Periodic/On-demand self-tests The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. In addition, it is recommended for the Crypto Officer to perform the periodic tests a minimum of once every 60 days to ensure all components are functioning correctly.

Secure operations The module meets all the Level 1 requirements for FIPS 140-3. The validated module’s executable file Cisco_Firepower_Threat_Defense_Virtual-7.0.5-72.vmdk is the only allowable software image file running on the respective test platform listed in Table 2 above while in the Approved Mode. The Crypto Officer must configure and enforce the following initialization steps:

1. Review the Setup wizard settings. Defaults or previously entered values appear in brackets. To accept previously entered values, press Enter.
2. Complete the system configuration as prompted.
3. The VMware console may display messages as your settings are implemented. When finished, the device reminds you to register this device to a Cisco Firepower Management Center, and displays the CLI prompt.
4. Verify the setup was successful when the console returns to the firepower # prompt. Note: To successfully register the Firepower Threat Defense Virtual with the Cisco Licensing Authority, the Firepower Threat Defense Virtual requires Internet access.
5. Log into FTDv SSH and enter show network.
6. Register the module into Firepower Management Center (FMC) for the further configuration.
7. System >Licenses>Smart Licenses, add and verify licenses.
8. Install AES SMART license to use AES (for data traffic and SSH).
9. On FMC, go to Device >> Platform setting associated to the FTD IP. Then create and select CC option and save. This sets the approved mode of operation.
10. Reboot the module.

The requirements under INCITS+ISO+IEC 19790+2012[2014], section 7.12 “Mitigation of other attacks”, are not applicable to the module since the module currently does not support any mitigation of other attacks services.