Your organization might be required to use only equipment and software that comply with security standards established by the U.S. Department of Defense or other governmental certification organizations. Once certified by an appropriate certifying authority, and when configured in accordance with certification-specific guidance documents, threat defense is designed to comply with the following certification standards:

• Common Criteria (CC): a global standard established by the international Common Criteria Recognition Arrangement, defining requirements for security products.

• Department of Defense Information Network Approved Products List (DoDIN APL): a list of products meeting security requirements established by the U.S. Defense Information Systems Agency (DISA).

  Note	The U.S. Government has changed the name of the Unified Capabilities Approved Products List (UCAPL) to the DODIN APL. References to UCAPL in management center documentation and the web interface can be interpreted as references to DoDIN APL.

• Federal Information Processing Standards (FIPS) 140: a requirements specification for encryption modules.

Certification guidance documents are available separately once product certifications have completed; publication of this hardening guide does not guarantee completion of any of these product certifications.

The configuration settings described in this document do not guarantee strict compliance with all current requirements of the certifying entity. For more information on hardening procedures required, refer to the guidelines for this product provided by the certifying entity.

This document provides guidance for increasing the security of your threat defense, but some threat defense features do not support certification compliance even using the configuration settings described herein. For more information see “Security Certifications Compliance Recommendations” in the Cisco Secure Firewall Management Center Administration Guide, 7.2. We have endeavored to ensure that this hardening guide and the Cisco Secure Firewall Management Center Administration Guide, 7.2 do not conflict with certification-specific guidance. Should you encounter contradictions between Cisco documentation and certification guidance, use the certification guidance or consult with the system owner.

Cisco periodically releases management center software updates to address issues and make improvements. Keeping your system software up to date is essential to maintaining a hardened system. Ensure your system software is properly updated. For more information see the “System Updates” chapter of the Cisco Secure Firewall Management Center Administration Guide, 7.2, and the Secure Firewall Management Center Upgrade Guide.

Cisco also periodically issues updates for the databases management center uses to protect your network and assets. To provide optimum protection on threat defense devices managed by the management center, keep the geolocation, intrusion rules, and vulnerabilities databases on the managing management center up to date. Before you update any component of your Secure Firewall deployment you must read the Cisco Secure Firewall Threat Defense Release Notes that accompany the update. These provide critical and release-specific information, including compatibility, prerequisites, new capabilities, behavior changes, and warnings. Some updates may be large and take some time to complete; you should perform these updates during periods of low network use to reduce the impact on system performance.

Geolocation Database

Geolocation Database (GeoDB) is a database of geographical data (such as country and city coordinates) and connection-related data (such as Internet service provider, domain name, connection type) associated with routable IP addresses. When the management center detects GeoDB information that matches a detected IP address, you can view the geolocation information associated with that IP address. To view any geolocation details other than country or continent, you must install the GeoDB on your system.

To update the GeoDB from the management center web interface, use System > Updates > Geolocation Updates, and choose one of the following methods:

• Update the GeoDB on an management center with no internet access.

• Update the GeoDB on an management center with internet access.

• Schedule recurring automatic updates of the GeoDB on an management center with internet access.

For more information, see "Update the Geolocation Database" in the Cisco Secure Firewall Management Center Administration Guide, 7.2.

Intrusion Rules

As new vulnerabilities become known, the Cisco Talos Security Intelligence and Research Group (Talos) releases intrusion rule updates (also known as Snort Rules Updates, or SRUs) that you can import onto your management center, and then implement by deploying the changed configuration to your managed devices. These updates affect intrusion rules, preprocessor rules, and the policies that use the rules.

The management center web interface provides three approaches to updating the intrusion rules, all under System > Updates > Rule Updates:

• Update intrusion rules on an management center with no internet access.

• Update intrusion rules on an management center with internet access.

• Schedule recurring automatic updates of intrusion rules on an management center with internet access.

For more information, see "Update Intrusion Rules" in the Cisco Secure Firewall Management Center Administration Guide, 7.2.

You can also import local intrusion rules using System > Updates > Rule Updates. You can create local intrusion rules using the instructions in the Snort users manual (available at http://www.snort.org). Before importing them to your management center, see "Best Practices for Importing Local Intrusion Rules" in the Cisco Secure Firewall Management Center Administration Guide, 7.2 and make certain your process for importing local intrusion rules complies with your security policies.

Vulnerabilities Database

Vulnerabilities Database (VDB) is a database of known vulnerabilities to which hosts may be susceptible, as well as fingerprints for operating systems, clients, and applications. The system uses the VDB to help determine whether a particular host increases your risk of compromise.

The management center web interface offers two approaches to updating the VDB:

• Manually update the VDB (System > Updates > Product Updates).

• Schedule VDB updates (System > Tools > Scheduling).

For more information, see "Update the Vulnerability Database" in the Cisco Secure Firewall Management Center Administration Guide, 7.2.

Security Intelligence Lists and Feeds

Security Intelligence lists and feeds are collections of IP addresses, domain names, and URLs that you can use to quickly filter traffic that matches an entry on a list or feed.

There are system-provided feeds, and predefined lists. You can also use custom feeds and lists. To view these lists and feeds, choose Objects > Object Management > Security Intelligence. As part of system-provided feeds, Cisco provides the following feeds as Security Intelligence objects:

• Security Intelligence feeds are updated regularly with the latest threat intelligence from Talos:

  • Cisco-DNS-and-URL-Intelligence-Feed (under DNS Lists and Feeds)

  • Cisco-Intelligence-Feed (for IP addresses, under Network Lists and Feeds)

  You cannot delete the system-provided feeds, but you can change the frequency of (or disable) their updates. The management center can now update Cisco-Intelligence-Feed data for every 5 or 15 minutes.

• Cisco-TID-Feed (under Network Lists and Feeds)

  You must enable and configure Threat Intelligence Director to use this feed, which is a collection of TID observables data.

For more information, see "Security Intelligence Lists and Feeds" in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

To apply multiple hardening configuration changes with a single setting, choose CC or UCAPL mode for the threat defense. Apply this setting thorugh the management center web interface in the threat defense platform settings policy, found under Devices > Platform Settings. The change does not take effect on the threat defense until you deploy the new configuration; see “Enable Security Certifications Compliance” in the Cisco Secure Firewall Management Center Administration Guide, 7.2 for full details.

Choosing one of these configuration options puts into effect the changes listed under “Security Certification Compliance Characteristics” in the Cisco Secure Firewall Management Center Administration Guide, 7.2. Be aware that all appliances in your deployment should operate in the same security certifications compliance mode.

Caution

After you enable this setting, you cannot disable it. Consult “Security Certifications Compliance” in the Cisco Secure Firewall Management Center Administration Guide, 7.2 for full information before enabling CC or UCAPL mode. If you need to reverse this setting, contact Cisco TAC for assistance.

Note

Enabling security certifications compliance does not guarantee strict compliance with all requirements of the security mode selected. Additional settings recommended to harden your deployment above and beyond those provided by CC or UCAPL modes are described in this document. For full information on hardening procedures required for complete compliance, refer to the guidelines for this product provided by the certifying entity.

Cisco’s IOS NetFlow enables you to monitor traffic flows in your network in real time. Threat Defense can coordinate with some NetFlow features, such as viewing and resetting runtime counters. See the show flow-export counters and clear flow-export counters CLI commands.

Through the management center web interface you can disable threat defense syslog messages that are redundant with those captured by NetFlow. To do this, create an threat defense platform settings policy under Devices > Platform Settings, and choose Syslog from the menu. On the Syslog Settings tab check the NetFlow Equivalent Syslogs check box (Use the show logging flow-export-syslogs CLI command to determine which syslog messages are redundant.)

You can take advantage of these abilities if you configure network devices with NetFlow. Regardless of whether flow information is exported to a remote collector, you can use NetFlow reactively if needed. See “Netflow Data” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2 for more information.

Your Secure Firewall deployment may interact with other network resources for a number of purposes. Hardening these other services can protect your Secure Firewall system as well as all your network assets. To identify everything that needs to be addressed, try diagramming the network and its components, assets, firewall configuration, port configurations, data flows, and bridging points.

Establish and adhere to an operational security process for your network that takes security issues into account.

The threat defense device can interact with other network devices using a number of protocols; choose configuration settings for network communications to protect the threat defense device as well as the data it sends and receives.

• By default the threat defense device allows up to 24 fragments per IP packet, and up to 200 fragments awaiting reassembly. You might need to allow fragments on your network if you have an application that routinely fragments packets, such as NFS over UDP. However, fragmented packets are often used in Denial of Service (DoS) attacks, so we recommend that you do not allow fragments.

  • To configure the fragments settings for a threat defense device, create an threat defense platform settings policy under Devices > Platform Settings, and choose Fragment Settings from the table of contents.

  • To disallow fragments in the network traffic handled by an threat defense device, set the Chain (Fragment) option to 1.

  For complete instructions, see “Configure Fragment Handling” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

• For threat defense devices managed by a management center, HTTPS connections with the threat defense can be used only to download packet capture files for troubleshooting.

  Configure threat defense to allow HTTPS access only for IP addresses that should be allowed to download packet captures. In the management center web interface create an threat defense platform settings policy under Devices > Platform Settings, and choose HTTP from the table of contents. See “Configure HTTP” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

• By default, the threat defense can receive ICMP packets on any interface using either IPv4 or IPv6 with two exceptions:

  • The threat defense does not respond to ICMP echo requests directed to a broadcast address.

  • The threat defense responds only to ICMP traffic sent to the interface that traffic comes in on; you cannot send ICMP traffic through an threat defense interface to a far interface.

  To protect a threat defense device from ICMP-based attack, you can use ICMP rules to limit ICMP access to selected hosts, networks, or ICMP types. In the management center web interface, create an threat defense platform settings policy under Devices > Platform Settings, and choose ICMP Access from the table of contents. For details, see “Configure ICMP Access Rules” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

• The threat defense can be configured to provide DHCP and DDNS services (see “DHCP and DDNS Services for Threat Defense” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2). By their nature these protocols are vulnerable to attack. If you choose to configure your threat defense for DHCP or DDNS it is important to apply industry best practices for security, provide physical protection for your network assets, and harden user access to the threat defense device.

• You can enable LLDP on Firepower 1000 Series, 2100 Series, and Secure Firewall 3100. This feature enables the threat defense to exchange packets with its LLDP-enabled peers. By default, LLDP transmit and receive is disabled on a port. The information sent through LLDP is vulnerable to attack. If you choose to configure your threat defense device for LLDP, it is important to apply industry best practices for security, and harden user access to the threat defense. We recommend that you only enable the firewall to receive LLDP packets from its peers for enhanced security. This action ensures the firewall gets information about peer devices without revealing its identify to other peer devices. For more information, see "Enable the Physical Interface and Configure Ethernet Settings" in Cisco Secure Firewall Management Center Device Configuration Guide, 7.2

You can configure the threat defense to provide two kinds of Virtual Private Network (VPN) services: Remote Access VPN (RA VPN) and Site-to-site VPN. Depending on your device license, you can apply strong encryption to site-to-site and RA VPN transmissions. VPN with strong encryption requires special licensing; see "Licensing for Export-Controlled Functionality" in the Cisco Secure Firewall Management Center Administration Guide, 7.2.

Remote Access Virtual Private Network

To secure message transmissions to and from remote clients over RA VPN connections, the threat defense can use Transport Layer Security (TLS) or IPsec IKEv2.

Before you deploy an RA VPN configuration to the threat defense, the management center ensures that the license prerequirements are met. For more information, see Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

RA VPN on threat defense supports AD, LDAP, SAML identity providers, and RADIUS AAA servers for authentication. When a user configures AAA settings for RA VPN, we recommend that you use one of the following authentication methods for enhanced security:

• Client Certificate and SAML: Each user is authenticated with both a client certificate and a SAML server.

• Client Certificate and AAA: Each user is authenticated with both a client certificate and a AAA server.

RA VPN supports local authentication and multi-certificate authentication.

• Local Authentication: You can use this authentication method as the primary or secondary authentication method, or as a fallback in case the configured remote server can’t be reached. We recommend that you use a strong password for the local authentication. For more information, see "Associating a Local Realm with a Remote Access VPN Policy" in Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

• Multi-certificate Authentication: You can use this authentication method to validate the machine or device certificate using single certificate authentication. This authentication ensures that the device is a corporate-issued device and authenticates the user identity certificate to allow VPN access. We recommend that use this authentication method. For more information, see "Configuring Multiple Certificate Authentication" in Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

Site-to-site Virtual Private Network

To secure message transmissions to and from remote networks over site-to-site VPN connections, the threat defense can use IPSEC IKEv1 or IPSEC IKEv2.

There are two types of site-to-site VPNs: Policy-based (Crypto Map) and Route-based (Virtual Tunnel Interface (VTI)). We recommend that you use route-based VTI VPN for enhanced security. For more information, see "Site-to-Site VPNs" in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

When you configure the threat defense VPN IKE and IPsec options (Devices > VPN > Site To Site > Add, and click IKE or IPsec tabs), we recommend that you:

• Choose IKEv2.

• Use a strong key for the pre-shared manual key.

• Use the default IKEv2 policy. For example, AES-GCM-NULL-SHA-LATEST.

• Check the Enable Security Association (SA) Strength Enforcement check box.

  This option ensures that the encryption algorithm used by the child IPsec SA isn’t stronger than the parent IKE SA.

• Check the Enable Perfect Forward Secrecy check box.

  This option generates and uses a unique session key for each encrypted exchange. The unique session key protects the exchange from subsequent decryption. If you select this option, select the Diffie-Hellman key derivation algorithm to use when generating the PFS session key from the Modulus Group drop-down list.

For more information about the above threat defense VPN IKE options, see Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

To configure these services, see “VPN Overview” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

The management center supports a wide range of encryption and hash algorithms, and Diffie-Hellman groups from which to choose. Choosing strong encryption can worsen system performance, so you must find the balance between security and performance that provides sufficient protection without compromising efficiency. For more information, see “How Secure Should a VPN Connection Be?” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

The threat defense supports two types of users:

• Internal users—The device checks a local database for user authentication.

• External users—If the user is not present in the local database, the system queries an external LDAP or RADIUS authentication server.

You might consider establishing user access through an external authentication mechanism such as LDAP or RADIUS, to integrate user management with existing infrastructure in your network environment, or leverage capabilities such as two-factor authentication. Establishing external authentication requires creating an external authentication object within the management center web interface; external authentication objects can be shared to authenticate external users for the management center as well as the threat defense.

Be aware that using external authentication requires that you configure a DNS for your deployment. Be sure to follow hardening recommendations for your DNS. See “Secure the Domain Name System (DNS).”

This discussion of user management refers to features available in Version ; not all user account configuration features addressed in this section apply to all threat defense versions. For information specific to your system, see the Cisco Secure Firewall Threat Defense documentation for your version.

Threat Defenses managed by management center provide a single means of user access: a command line interface which can be accessed using an SSH, serial, or keyboard and monitor connection for physical devices. With certain configuration settings in place these users can also access the Linux shell.

To protect system data and its availability, perform regular backups of your threat defense. The backup function appears under System > Tools > Backup/Restore in the management center web interface and is described in “Backup Devices Remotely” in the Cisco Secure Firewall Management Center Administration Guide, 7.2. To restore a saved threat defense configuration, use the threat defense CLI restore command.

The management center provides the ability to automatically store backups on a remote device. Using this feature is not recommended for a hardened system because the connection between the management center and the remote storage device cannot be secured.

You can revert major and maintenance upgrades to threat defense using the management center. Reverting returns the software to its state just before the last major or maintenance upgrade, also called a snapshot. Reverting after patching removes patches. The revert happens only if communications between the management center and device are disrupted. In high availability or scalability deployments, revert is more successful when all units are reverted simultaneously.

Configurations that are reverted include: snort version, device-specific configurations, objects used by your device-specific configurations. Configurations that are not reverted include shared policies that can be used by multiple devices.

If you want to revert after a successful upgrade, choose System > Updates on the management center to upgrade the threat defense, and set the Enable revert after successful upgrade option. By default, this option is enabled. We recommend that you enable this option.

The revert snapshot is saved on the management center and the device for thirty days, after which it is automatically deleted and you can no longer revert. You can manually delete the snapshot from either appliance to save disk space, but this removes your ability to revert. For more details, see "Revert the Upgrade" in the Cisco Secure Firewall Threat Defense Upgrade Guide for Management Center, Version 7.2.

The threat defense CLI provides the ability to download certain files from the threat defense to a local computer. This capability is provided so you can collect information to provide to Cisco TAC when troubleshooting your system, and should not be used casually. Take precautions to protect any files you download from the threat defense; choose the most secure options available when downloading, secure the local computer where you store the data, and use the most secure protocols available when transmitting files to TAC. In particular, be aware of the possible risks when using the following commands:

• show asp inspect-dp snort queue-exhaustion [snapshot snapshot_id] [export location]

  The export option supports TFTP only.

• file copy host_name user_id path filename_1 [filename_2 ... filename_n]

  This command transfers files to remote host using unsecured FTP.

• copy [/noverify] /noconfirm {/pcap capture:/[buffer_name] | src_url | running-config | startup-config} dest_url

  The following options for src_url and dest_url provide methods of securing the data copied:

  • Internal flash memory

  • System memory

  • Optional external flash drive

  • HTTPS secured with password

  • SCP secured with password, specifying target interface on SCP server

  • FTP secured with password

  • TFTP secured with password, specifying target interface on TFTP server

  We recommend against using the following src_url and dest_url options in a hardened system:

  • SMB UNIX server local file system

  • Cluster trace file system. (Systems with security certifications compliance enabled do not support clusters.)

• cpu profile dump dest_url

  The following options for dest_url provide methods of securing the data dump:

  • Internal flash memory

  • Optional external flash drive

  • HTTPS secured with password

  • SMB UNIX server local file system

  • SCP secured with password, specifying target interface on SCP server

  • FTP secured with password

  • TFTP secured with password, specifying target interface on TFTP server

  We recommend against using cluster file systems for src_url and dest_url options in a hardened system.

• file secure-copy host_name user_id path filename_1 [filename_2 ... filename_n]

  Copies file(s) to a remote host using SCP.

The threat defense can send syslog messages to an external syslog server; choose secure options when configuring syslog functionality:

1. Create a threat defense platform settings policy under Devices > Platform Settings, and choose Syslog from the table of contents. When adding a syslog server under the Syslog Servers tab, choose the TCP protocol and check the Enable secure syslog check box. These options apply to syslog messages generated by the threat defense if you do not override them elsewhere in your device configuration.

   Note	By default, when secure syslog is enabled, if a syslog server using TCP is down, the threat defense will not forward traffic. To override this behavior, check the Allow user traffic to pass when TCP syslog server is down check box.

2. Configure logging in your access control policies to inherit the logging settings from the platform settings policy. Choose Policies > Access Control <each policy> > Logging check the Use the syslog settings configured in the FTD Platform Settings policy deployed on the device check box.

With these two configuration settings in place the threat defense syslog behaves as follows:

• The syslog settings in the platform settings policy apply to syslog messages related to device and system health, and network configuration.

• The syslog settings in the platform settings apply to syslogs for connection and security intelligence events unless you override the setting for the access control policy in any of the places listed in “Configuration Locations for Syslogs for Configuration and Security Intelligence Events (All Devices)” in the Cisco Secure Firewall Management Center Administration Guide, 7.2. These overrides do not provide a secure syslog option, so we recommend against using them in a secure environment.

• The syslog settings in the platform settings policy apply to syslogs for intrusion events unless you override the setting for the access control policy in any of the places listed in “Configuration Locations for Syslogs for Intrusion Events” in the Cisco Secure Firewall Management Center Administration Guide, 7.2. These overrides do not provide a secure syslog option, so we recommend against using them in a secure environment.

You can configure the threat defense device to convey essential information to users when they log in to the CLI. From a security perspective, the login banner should discourage unauthorized access; consider text such as this example:

• You have logged into a secure device. If you are not authorized to access this device, log out immediately or risk criminal charges.

To configure the login banner for an threat defense device, create an threat defense platform settings policy under Devices > Platform Settings, and choose Banner from the table of contents. See “Configure Banners” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2 for full instructions.

Identity policies use identity sources to authenticate network users and collect user data for user awareness and control. Establishing user identity sources requires a connection between the management center or a managed device and one of the following types of servers:

• Microsoft Active Directory

• Linux Open LDAP

• RADIUS

Important

Although you can set up a secure connection to LDAP, Microsoft AD, or RADIUS servers from threat defense, the authentication module is not FIPS compliant.

Note	If you choose to use LDAP or Microsoft AD for external authentication, review the information in Harden External User Accounts.

Note	Threat Defense uses each of these servers to support a different combination of the possible user identity features. For full details, see “About User Identity Sources” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

Securing Connections with Active Directory and LDAP Servers

Objects called realms describe connection settings associated with a domain on an Active Directory or LDAP server. For full information on configuring realms see “Create and Manage Realms” in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

When you create a realm (System > Integration > Realms in the management center web interface) keep the following in mind to secure the connections with AD or LDAP servers:

For realms associated with Active Directory servers:

• Choose strong passwords for the AD Join Password and Directory Password.

• When adding a directory to an Active Directory realm:

  • Select STARTTLS or LDAPS for the Encryption mode (do not choose None).

  • Specify an SSL Certificate to use for authentication to the Active Directory domain controller. We recommend using a certificate generated by globally known and trusted certificate authority.

For realms associated with LDAP servers:

• Choose strong passwords for the Directory Password.

• When adding a directory to an LDAP realm:

  • Select STARTTLS or LDAPS for the Encryption mode (do not choose None).

  • Specify an SSL Certificate to use for authentication to the LDAP server. We recommend using a certificate generated by globally known and trusted certificate authority.

Securing Connections with RADIUS Servers

To configure a connection with a RADIUS server, create a RADIUS Server Group object (Objects > Object Management > RADIUS Server Group in the management center web interface) and add a RADIUS server to the group. To secure the connection with the RADIUS server, choose the following options in the New RADIUS Server dialog:

• Supply a Key and Confirm Key to encrypt data between the managed device and the RADIUS server.

• Specify an interface for the connection that can support secure data transmission.

Note

Threat Defense connects with a RADIUS server for user identity only if a managed threat defense device in the deployment is configured to provide Remote Access VPN, which will be used as the user identity source. For information on configuring and securing Remote Access VPN, see “Harden Network Protocol Settings.”.

Configuring Certificate Enrollment Using Enrollment over Secure Transport

You can configure certificate enrollment for threat defense over a secure channel. The device uses Enrollment over Secure Transport (EST) to obtain an identity certificate from the CA. EST uses TLS for secure message transport.

To configure EST:

1. Choose Objects > Object Management > PKI > Cert Enrollment.

2. Click Add Cert Enrollment and click the CA Information tab.

3. From the Enrollment Type drop-down list, choose EST.

If you don’t want threat defense to validate the EST server certificate, we recommend that you don’t check the Ignore EST Server Certificate Validations check box. By default, threat defense validates the EST server certificate. EST enrollment type supports only RSA and ECDSA keys, and doesn’t support EdDSA keys. For more information, see "Certificate Enrollment Object EST Options" in Cisco Secure Firewall Management Center Device Configuration Guide, 7.2.

On management center and threat defense Versions 7.0 and higher, you can’t enroll certificates with RSA key sizes smaller than 2048 bits and keys using SHA-1. To override these restrictions on management center 7.0 managing threat defense running versions lesser than 7.0, the Enable Weak-Crypto option is available (Devices > Certificates). By default, the weak-crypto option is disabled. We don’t recommend you to enable weak-crypto keys as these keys aren’t as secure as the ones with higher key sizes. For management center and threat defense versions 7.0 and higher, you can enable weak-crypto to allow validation of peer certificates and so on. However, this configuration doesn’t apply to the certificate enrollment.

Configuring Certificate Validations

You can use a specific CA certificate to validate SSL or IPSec clients, and use a CA certificate to validate connection from an SSL server. To configure the validation usage types:

1. Choose Objects > Object Management > PKI > Cert Enrollment.

2. Click Add Cert Enrollment and click the CA Information tab.

3. Validation Usage—Choose from the options to validate the certificate during a VPN connection

   • IPsec Client—Validate an IPsec client certificate for a site-to-site VPN connection.

   • SSL Client—Validate an SSL client certificate during a remote access VPN connection attempt.

   • SSL Server—Select to validate an SSL server certificate, like as a Cisco Umbrella server certificate.

The threat defense device expands access control rules into multiple access control list entries based on the contents of any network or interface objects used in the access rule. You can reduce the memory required to search access control rules by enabling object group search (Devices > Device Management > Device > Advanced Settings). With object group search enabled, the system does not expand network or interface objects, but instead searches access rules for matches based on those group definitions.

It is important to note that object group search might also decrease rule lookup performance and thus increase CPU utilization. You should balance the CPU impact against the reduced memory requirements for your specific access control policy. For the low-end Firepower devices such as the 1000 series, 2110, and 2120, the increase in CPU utilization will make the device slow. In most cases, enabling object group search provides a net operational improvement. By default, object group search setting is enabled.

If you enable object group search and then configure and operate the device for a while, disabling the feature might lead to undesirable results. When you disable object group search, your existing access control rules will be expanded in the device’s running configuration. If the expansion requires more memory than is available on the device, your device can be left in an inconsistent state and you might see a performance impact. If your device is operating normally, you should not disable object group search once you have enabled it. For more information, see "Configure Object Group Search" in the Cisco Secure Firewall Management Center Device Configuration Guide, 7.2

The threat defense software depends on complex underlying firmware and operating system software. These underlying software components carry their own security risks that must be addressed:

• Establish an operational security process for your network that takes security issues into account.

• For threat defense models 2100, 4100, and 9300 devices, secure the Firepower eXtensible Operating System the threat defense runs on; see the Cisco Firepower 4100/9300 FXOS Hardening Guide.