Firepower Management Center Virtual VMware Cryptographic Module

Certificate

Approved Algorithms (42)

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

flowchart LR
  %% Deterministic review-risk graph for Firepower Management Center Virtual VMware 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/>HTTPS</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 Management Center Virtual VMware 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/>HTTPS</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

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

Table of Content List of Figures List of Tables

VMware Cryptographic Module (hereinafter referred to as the Module or FMCv) with software version 7.0.5. The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 The security requirements cover areas related to the design and implementation of a cryptographic mitigation of other attacks. Table 1 below 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 Management Center with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FX-OS) throughout this document. The module’s operational environment is non-modifiable. The module is the administrative nerve center for managing critical Cisco network security solutions. It provides complete and unified management over firewalls, application control, intrusion prevention, URL filtering, and advanced malware protection, quickly and easily go from managing a firewall to controlling applications to investigating and remediating malware outbreaks. It is a key part of the broad and integrated Cisco Secure portfolio, delivering in-depth analysis, streamlined security management across the network and cloud, and accelerated incident investigation and response, working across Cisco and third-party technologies. The Firewall Management Center (FMC) discovers real-time information about changing network resources and operations. The Management Center is the centralized point for event and policy management for the following solutions:

• Cisco Firepower Next-Generation Firewall (NGFW)
• Cisco ASA with FirePOWER Services
• Cisco Firepower Next-Generation IPS (NGIPS)
• Cisco FirePOWER Threat Defense

• Cisco Advanced Malware Protection (AMP) The module has been tested on the following Operational Environments. Table 2 Tested Operational Environment Figure 1 UCS C220 M5 Front view without Bezel (top) and with Bezel (bottom)1 Figure 2 UCS C220 M5 Rear view In addition to the platforms listed in Table 2, Cisco has also tested the module on the following platforms and claims vendor affirmation on them. Table 3 Vendor Affirmed Operational Environments https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/c220m5-sffspecsheet.pdf

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 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. #A2952 was tested for the OE with PAA
• 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.
• No parts of SSH and TLS 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 the 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 Hypervisor Guest OS / FMC FOM Figure 3 Block Diagram Note: Block Diagram above comprises the following components:

• Processor = Chip on the tested platform to handle all processes.
• API = Host API between hypervisor and processor
• Hypervisor = VMWare ESXi 6.7 and 7.0
• Guest OS/FMC = 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 logical interfaces (data input, 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 Crypto Officer.

Table 7 below lists all approved services that can be used in the approved mode of operation. The 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, as such any algorithms not listed in Table 4 above will be rejected by the module while in the approved mode, the table required defined in SP800-140B for Non-Approved Services is missing from this document. The module doesn’t support self-initiated cryptographic output capability and cryptographic Bypass capability services.

Integrity techniques The module is provided in the form of binary executable code. To ensure the software security, the module is protected by HMAC-SHA2-512 (HMAC Certs. #A2952 or #A3376) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary the factory and used for software integrity test only at the pre-operational self-test. At Module’s initialization, the integrity of the runtime executable is verified using a HMAC-SHA2-512 digest which is compared to a value computed at build time. If at the load time the MAC does not match the stored, known MAC value, the module would enter to an Error state with all crypto functionality inhibited. Integrity test on-demand Integrity test is performed as part of the pre-operational self-tests. It is automatically executed at poweron. The operator can power-cycle or reboot the tested platform to initiate the software integrity test ondemand.

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 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 Module. 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 would perform and pass the pre-operational self-tests. A software integrity test is performed on the runtime image of the module with HMAC-SHA2-512 algorithm. Prior to the firmware integrity test, the module conducts a HMAC-SHA2-512 Cryptographic Algorithm Self-test (CAST). If the CAST on the HMAC-SHA2-512 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time. Following the successful pre-operational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs) for all approved cryptographic algorithms implemented by the module during powerup as well. The self-test success or failure messages (e.g., Error: Signature RSA test failure or ECDH P-256 test failure) were logged, 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 only method to recover from the error state is to power cycle the device which results in the module being reloaded into memory and reperforming the pre-operational software integrity test and the Conditional CASTs. The module will only enter into the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. Pre-operational self-tests:

• Pre-operational software integrity test
• HMAC-SHA-512 KAT
• Software Integrity Test (using HMAC-SHA-512) Please note that the module conducts HMAC-SHA-512 KAT self-test before the integrity test is performed.

Conditional self-test

• Conditional cryptographic algorithm self-tests (CASTs)
• AES-CBC 256 bits Encrypt KAT
• AES-CBC 256 bits Decrypt KAT
• AES-GCM 256 bits Authenticated Encrypt KAT
• AES-GCM 256 bits Authenticated Decrypt KAT
• 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-SHA-256 KAT
• HMAC-SHA-384 KAT
• HMAC-SHA-512 KAT
• KAS-ECC-SSC Primitive Z KAT
• KAS-ECC-SSC Primitive Z KAT
• RSA 2048 bits modulus with SHA-256 SigGen KAT
• RSA 2048 bits modulus with SHA-256 SigVer KAT
• SHA-1 KAT
• KDF-SSH KAT
• KDF-TLS KAT The module generates RSA, ECDSA, KAS-ECC and KAS-FFC asymmetric keys and performs all required pair-wise consistency tests on the newly generated key pairs as detailed below.
• Conditional pair-wise consistency tests (PCTs)
• RSA PCT
• ECDSA PCT
• KAS-ECC PCT
• KAS-FFC PCT Periodic/Self-tests on-demand The module performs on-demand self-tests initiated by the operator, by power-cycling or rebooting the tested platform. 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.

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

Choose

SSH

or

HTTPS

or a combination of these options to specify

System>Licenses>Smart Licenses, add and verify licenses (

Firepower Management Center

Step 1: For all Management Centers, the setup process must be completed by logging into the Management Center’s web interface and specifying initial configuration options on a setup page. which ports you want to enable for these IP addresses). Configuration Guide provides more detailed information). Install AES SMART license to use AES (for data traffic and SSH). Step 4: System > Configuration; Devices > Platform Settings; STIG Compliance, choose Enable STIG Compliance; Click on save. This sets the approved mode of operation. The CO shall only use approved cryptographic algorithms listed in Section 2.2 above. Step 5: Reboot the security appliances.

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 doesn’t support any mitigation of other attacks services.