Cisco Adaptive Security Appliance Virtual Cryptographic Module

Certificate

Approved Algorithms (25)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Cisco Adaptive Security Appliance Virtual Cryptographic 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>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>SSHv2 Session Encrypt/Decrypt<br/>TLSv1.2 Session Encrypt/Decrypt<br/>IPsec/IKEv2 Session Encrypt/Decrypt</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"]
    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 Cisco Adaptive Security Appliance 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)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>SSHv2 Session Encrypt/Decrypt<br/>TLSv1.2 Session Encrypt/Decrypt<br/>IPsec/IKEv2 Session Encrypt/Decrypt</i><br/>src: securityPolicy.services"]
    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 C2,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Cisco Systems, Inc. Cisco Adaptive Security Appliance Virtual Cryptographic Module Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2021-2025 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Appliance Virtual Cryptographic Module (hereinafter referred to as ASAv or the Module), firmware version 9.20(3). The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and ISO/IEC 19790 for a Security Level 1 firmware hybrid The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic indicates the actual security levels for each area of the cryptographic module.

Purpose and Use: This module is a multi-chip standalone firmware hybrid cryptographic module deployed as the virtualized version of the Cisco Adaptive Security Appliance (ASA) with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FXOS throughout this document). The Module’s operational environment is non-modifiable. ASA delivers enterprise-class firewall for businesses, improving security at the Internet edge, high performance and throughput for demanding enterprise data centers. This solution offers the combination of the industry's most deployed stateful firewall with a comprehensive range of next-generation network security services, intrusion prevention system (IPS), content security © 2021-2025 Cisco Systems, Inc.

and secure unified communications, SSHv2, HTTPS/TLSv1.2, IPsec/IKEv2, SNMPv3 and Cryptographic Cipher Suite B. Module Type: Firmware-hybrid Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic module (red dash box) is a non-modifiable, multi-chip standalone firmware hybrid cryptographic module providing cryptographic support which takes data in and out from the host application via the API. The block diagram below shows the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the module (red dash box) and its interfaces with the operational environment. Processor Host Platform API Hypervisor API ASA API FOM Figure 1 Block Diagram The Block Diagram above comprises the following components

• Processor: Chip on the tested platforms handle all processes.
• API: Host API between hypervisor and processor
• Hypervisor: VMWare ESXi 7.0
• API: Host API between hypervisor and the ASA Module
• ASA: Adaptive Security Application
• API: Guest API between the ASA Module and FOM Crypto library
• FOM: Cisco FIPS Object Module (FOM Crypto Library)

Tested Module Identification

• Hardware: N/A for this module. © 2021-2025 Cisco Systems, Inc.

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: 1.0 N/A Table 3: Tested Module Identification
• Hybrid Disjoint Hardware Tested Operational Environments - Software, Firmware, Hybrid: 7.0 Table 4: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Table 5: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid

Modes List and Description: © 2021-2025 Cisco Systems, Inc.

Table 6: Modes List and Description The module has one Approved mode of operation and does not implement a Non-Approved following the steps in section 11 of this document, the module will only operate in the Approved mode of operation. The module doesn’t claim the implementation of a degraded mode

Approved Algorithms: HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 © 2021-2025 Cisco Systems, Inc.

Table 7: Approved Algorithms Vendor-Affirmed Algorithms: N/A © 2021-2025 Cisco Systems, Inc.

Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

AsymKeyPairKeyGen © 2021-2025 Cisco Systems, Inc.

Table 9: Security Function Implementations

• The module’s AES-GCM implementation conforms to Implementation Guidance 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 © 2021-2025 Cisco Systems, Inc.

3.3.1. The keys for the client and server negotiated in the TLSv1.2 handshake process (client_write_key and server_write_key) are compared and the module aborts the session if the key values are identical. 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. Two keys established by IKEv2 for one security association (one key for encryption in each direction between the parties) are not identical and abort the session if they are. 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.
• In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation as per section 5 in SP800-133rev2. The resulting generated seed used in the asymmetric key generation is the unmodified output from SP800-90Arev1 DRBG.
• The module was algorithm tested based on the FIPS 186-4 standard Digital Signatures. According to IG C.K, this module is 186-5 compliant as all 186-4 CAVP tests performed are mathematically identical to the 186-5 CAVP tests. The Module does not support 1864 DSA or RSA X9.31 for Signature Generation or Signature Verification.

Table 10: Entropy Certificates NonPhysical Table 11: Entropy Sources A2810 (SHA3256) The module employs a Deterministic Random Bit Generator (DRBG) implementation based on SP800-90Arev1. This DRBG is used internally by the module (e.g. to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). © 2021-2025 Cisco Systems, Inc.

The DRBG implemented is an AES-256 Counter DRBG, seeded by the entropy source described in the table above. The Counter DRBG utilizes the Derivation Function and employs prediction resistance. The DRBG is instantiated with a 384-bits long entropy input (corresponding to 384 bits of entropy). Additionally, the DRBG is reseeded with a 256-bits long entropy input (corresponding to 256 bits of entropy).

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800- 133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• Direct generation of symmetric keys: compliant with SP 800-133rev2, Section 6.1. Safe primes key pair generation: compliant with SP 800-133rev2, Section 5.2, which maps to SP 800-56Arev3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used. RSA key pair generation: compliant with SP 800-133rev2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.3 of FIPS 186-4 (“Probable Primes”) is used. ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.4 of FIPS 186-4 (“Testing Candidates”) is used. Note that this generation method is also used to generate ECDH key pairs. Additionally, the module implements the following key derivation methods:
• SNMPv3, SSHv2 KDF, TLS 1.2 KDF, IKEv2 KDF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of the SNMPv3, SSHv2, TLSv1.2 and IKEv2 KDF protocols, respectively. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service

The module provides the following key/SSP establishment services in the approved mode of operation: KAS-FFC Shared Secret Computation:

• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-FFC shared secret computation. The shared secret computation provides between 112 and 152 bits of encryption strength.
• The module supports the use of the safe primes defined in RFC 4419 (SSH), RFC

parameter generation, key pair generation and verification, and shared secret computation.

• SSH (RFC 4419):  MODP-2048 (ID = 14) © 2021-2025 Cisco Systems, Inc.

o o  MODP-3072 (ID = 15)  MODP-4096 (ID =

16. TLS (RFC 7919):  ffdhe2048 (ID = 256)  ffdhe3072 (ID = 257)  ffdhe4096 (ID = 258) IKE (RFC 3526):  MODP-2048 (ID = 14)  MODP-3072 (ID = 15)  MODP-4096 (ID =
17. KAS-ECC Shared Secret Computation: • The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-ECC shared secret computation. The shared secret computation provides between 128 and 256 bits of encryption strength. The module also provides the following key transport mechanisms: • Key wrapping using AES-GCM with a security strength of 128 or 256 bits. • Key wrapping using AES-CBC with a security strength of 128 or 256 bits with HMACSHA-1, HMAC-SHA2-256 or HMAC-SHA2-384.

The module supports SSHv2, TLSv1.2, IPsec/IKEv2 and SNMPv3 industrial protocols. No parts of SSHv2, TLSv1.2, IPsec/IKEv2 or SNMPv3 protocols, other than the KDFs, have been tested by the CAVP and CMVP. Please refer to SSPs Table for more information.

N/A N/A N/A N/A N/A N/A Table 12: Ports and Interfaces N/A 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 logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces © 2021-2025 Cisco Systems, Inc.

Table 13: Roles The module supports Crypto Officer (CO) role. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested.

The following tables detail the types of approved services available to each role in approved mode of operation, the types of access for each role and the Keys or SSPs they affect.

• Generate G
• Read Access R
• Write Access W
• Execute Access E
• Zeroize Z n. (Preoperationa © 2021-2025 Cisco Systems, Inc. ondemand the selftests

n al SelfTests) n. Z Z Z Z Z Z SelfTests. © 2021-2025 Cisco Systems, Inc. n

n. n. n. © 2021-2025 Cisco Systems, Inc. with AESGCM) with AESGCM) G,W,E G,R,W G,W,E G,R,W G,W,E G,W,E

n. with AESGCM) with AESGCM) n. with AESGCM) © 2021-2025 Cisco Systems, Inc. G,W,E G,W,E G,R,W G,W,E G,R,W G,W,E G,W,E G,W,E

with AESGCM) n. with AESGCM) with AESGCM) © 2021-2025 Cisco Systems, Inc. G,W,E G,W,E G,W,E G,W,E G,W,E W,E G,W,E

© 2021-2025 Cisco Systems, Inc. with AESGCM) n G,W,E G,R,W G,W,E G,W,E G,R,W W,E G,W,E G,W,E G,R,W G,W,E G,R,W

with AESGCM) © 2021-2025 Cisco Systems, Inc. G,W,E G,W,E G,W,E G,W,E G,W,E G,R,W G,W,E G,W,E G,R,W W,E

The module implements alternating Bypass service. Traffic output from the module’s data output interface can be cryptographically protected via IPSec/IKE VPN, or passed as plaintext (Bypass state), depending on the VPN tunnel establishment on the dedicated data output interface. The operator shall assume Crypto Officer role so as to configure IPSec/IKE VPN capability. If no IPSec/IKE VPN was configured, after running two independent internal actions, Module would enter the Bypass state. Before the module executes the Bypass service (sending out plaintext traffic via the data output interface), the module would conduct two independent internal actions to prevent the inadvertent bypass of plaintext data due to a single error. The Crypto Officer can use commands “show access-list” and “show crypto ipsec sa” to verify the module’s Bypass status. In Bypass tests fail, the module would enter an error state, and drop the traffic.

The module implements Self-initiated cryptographic output capability without external operator request. The Crypto Officer shall configure self-initiated cryptographic output capability. Prior to executing the self-initiated cryptographic output capability, the module conducts two independent internal actions to activate the capability to prevent the inadvertent output due to a single error.

The module supports unauthenticated service. The unauthenticated operator can trigger the self-test service by power-cycling the module.

The module is provided in the form of binary executable code. To ensure firmware security, the library is protected by RSA 2048 SigVer with SHA2-512 (RSA and SHA2-512 Cert. #A4595) © 2021-2025 Cisco Systems, Inc.

signature calculated at build time. 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 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 integrity test on-demand.

Type of Operational Environment: Non-Modifiable The module is a firmware hybrid module, which is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The module’s firmware version running on each tested platform is 9.20(3). The module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevent 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.

N/A Table 15: Mechanisms and Actions Required The module is running on the multi-chip standalone production grade platform to meet physical security requirements from FIPS 140-3 level

1. The module’s Tested Operational Environment’s Physical Perimeter (TOEPP) is drawn at the casing of the tested platforms in Table
2. The module’s tested platforms consist of production-grade components.

N/A for this module. © 2021-2025 Cisco Systems, Inc.

with AESGCM) with AESGCM) © 2021-2025 Cisco Systems, Inc.

with AESGCM) with AESGCM) with AESGCM) Table 17: SSP Input-Output Methods

factorydefault` Table 18: SSP Zeroization Methods n © 2021-2025 Cisco Systems, Inc.

n MODP2048, MODP3072, MODP2048, MODP3072, MODP2048, MODP3072, MODP2048, MODP3072, MODP4096 © 2021-2025 Cisco Systems, Inc. KASFFC

n KASECC © 2021-2025 Cisco Systems, Inc.

n n 8, 2, 8, 2, 8, 2, 8, 2, © 2021-2025 Cisco Systems, Inc. KASFFC )

n KASECC ) © 2021-2025 Cisco Systems, Inc.

n MODP2048, MODP3072, MODP2048, MODP3072, MODP2048, MODP3072, © 2021-2025 Cisco Systems, Inc. KASFFC n n

n MODP2048, MODP3072, © 2021-2025 Cisco Systems, Inc. KASECC

n Table 19: SSP Table 1 t n t t t d © 2021-2025 Cisco Systems, Inc. n

• SHA-1
• The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2031
• FIPS 186-4/186-5
• As of February 5, 2024, the CMVP does not accept module submissions that implement DSA or RSA X9.31 in the approved mode, other than for signature verification which is approved for legacy use. This module does not implement DSA or RSA X9.31 for signature generation and therefore is unaffected by the current transition from 186-4 to 186-5. As detailed in section 2.7, the CAVP testing performed on the 186-4 algorithms is mathematically similar to the testing performed on the 186-5 algorithms and therefore this module claims compliance with 186-5. This means that no timeline exists in which any of the implemented algorithms will transition from approved to non-approved.

Table 21: Pre-Operational Self-Tests The module performs the following self-tests, including Pre-operational and Conditional selftests. 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 Self-tests (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 anyone 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.

d s SHA2256 SHA2256 © 2021-2025 Cisco Systems, Inc.

d s N/A N/A N/A N/A N/A SHA2224 N/A SHA2256 N/A SHA2384 N/A SHA2512 N/A Curve P256 MODP2048 © 2021-2025 Cisco Systems, Inc.

d N/A N/A N/A SHA2256 SHA2256 N/A SHA2256 SHA2256 © 2021-2025 Cisco Systems, Inc. s N/A N/A N/A N/A N/A

d MODP2048 N/A N/A N/A s N/A Table 22: Conditional Self-Tests

N/A Table 23: Pre-Operational Periodic Information © 2021-2025 Cisco Systems, Inc. N/A N/A N/A N/A

N/A Table 24: Conditional Periodic Information 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.

Table 25: Error States If any of the above-mentioned self-tests fail, the module reports the error and enters the Error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to reboot the module and perform the selftests, including the pre-operational integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the pre-operational integrity test and the conditional CASTs. © 2021-2025 Cisco Systems, Inc.

The module meets all the Level 1 requirements for FIPS 140-3. Operating this module without maintaining the following settings will remove the module from the approved mode of operation. Any firmware that is not shown on the module certificate, is out of scope of this validation and requires a separate FIPS 140-3 validation. The Crypto Officer must configure and enforce the following initialization steps: Step 1: Crypto Officer performs the following configurations: ciscoasa# configure terminal Note, the Crypto Officer needs to connect the platform to cisco.com to obtain the license for ASA from Cisco. ciscoasa(config)# license smart register idtoken [token data] ciscoasa(config)#license smart ciscoasa(config-smart-lic)# show license all Smart Licensing Status ====================== Smart Licensing is ENABLED -ORciscoasa(config-smart-lic)# show license summary Smart Licensing is ENABLED Registration: Step 2. Crypto officer shall perform zeroization operation if the module was previously used before the approved mode configuration. configure factory-default Step 3: Enable approved mode of operation by using the following command. ciscoasa(config)# fips enable Note: Startup operational mode will not take effect until you save configuration and reboot the device. Rebooting the device will force new self-test Step 4: Crypto Officer can verify the version installed and running the following command. ciscoasa(config)# show version Step 5: Crypto Officer will need to issue the following commands to configure module. ciscoasa> en ciscoasa# conf t ciscoasa(config)# © 2021-2025 Cisco Systems, Inc.

Step 6: Configure IP address for unit and all distant endpoints. Step 7: Define RADIUS and TACACS+ shared secret keys that are at least 16 characters long and secure traffic between the security module and the RADIUS/ TACACS+ server via secure (IPSec, TLS) tunnel. Note: Perform this step only if RADIUS/TACAS+ is configured, otherwise skip over and proceed to next step. Step 8: Configure the security module so that any remote connections via Telnet are secured through IPSec connection by using the following commands crypto map interface access-list protocol esp encryption aes protocol esp integrity sha-256 Note: If the destined IP address is not within access-list, after running two internal independent actions defined in section 4.6 above, the module would enter the Bypass state. Step 9: Configure the security services by using the algorithms from section 2.5 Approved Algorithms table in this document for all security connections (SSHv2, TLSv1.2, SNMPv3 and IPSec/IKEv2). Note the module will reject any configuration with algorithms not listed in Approved Algorithm Table after the module is operated in approved mode. Here is an example of configuring the approved algorithms for the security services: SSH: ssh cipher encryption custom aes128-gcm@openssh.com ssh cipher integrity custom hmac-sha2-256 ssh key-exchange group ecdh-sha2-nistp256 TLSv1.2: ssl cipher tlsv1.2 ecdhe-rsa-aes128-sha SNMPv3: snmp-server user <SNMP username> <group name> v3 auth sha <auth password> priv aes 128 <priv password> IKEv2: crypto ikev2 policy <policy number> encryption aes integrity sha256 group 14 IPsec: crypto ipsec ikev2 ipsec-proposal <name your proposal> protocol esp encryption aes protocol esp integrity sha-256 Step 10: Disable the TFTP server by following the commands: © 2021-2025 Cisco Systems, Inc.

policy-map global_policy class inspection_default no inspect tftp Step 11: Disable HTTP for performing system management in approved mode of operation by using the command: no http server enable HTTPS with TLSv1.2 should always be used for Web-based management. Step 12: Save the configuration. write memory Step 13: Reboot the module. reload Step 14: Check the Module’s name, version and approved service status by using the following commands: Output the modules name/version: show version Output the modules approved mode of operation status: show fips

No specific administrator guidance.

No specific non-administrator guidance.

N/A for this module. © 2021-2025 Cisco Systems, Inc.