The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics describe how to manage various policies on the Firepower Management Center:
Any.
Any
Admin
Network Admin
Security Approver
 Caution |
Do NOT push the FMC deployments over a VPN tunnel that is terminating directly on the Firepower Threat Defense. Pushing the FMC deployments can potentially inactivate the tunnel and disconnect the FMC and the Firepower Threat Defense. Recovering the device from this situation can be very disruptive and require executing the disaster recovery procedure. This procedure resets the Firepower Threat Defense configuration to factory defaults by changing manager from FMC to local and configuring the device from beginning. For more information, see Deploying the FMC Policy Configuration over VPN Tunnel. |
After you configure your deployment, and any time you change that configuration, you must deploy the changes to affected devices. You can view deployment status in the Message Center.
Deploying updates the following components:
Device and interface configurations
Device-related policies: NAT, VPN, QoS, platform settings
Access control and related policies: DNS, file, identity, intrusion, network analysis, prefilter, SSL
Network discovery policy
Intrusion rule updates
Configurations and objects associated with any of these elements
You can configure the system to deploy automatically by scheduling a deploy task or by setting the system to deploy when importing intrusion rule updates. Automating policy deployment is especially useful if you allow intrusion rule updates to modify system-provided base policies for intrusion and network analysis. Intrusion rule updates can also modify default values for the advanced preprocessing and performance options in your access control policies.
In a multidomain deployment, you can deploy changes for any domain where your user account belongs:
Switch to an ancestor domain to deploy changes to all subdomains at the same time.
Switch to a leaf domain to deploy changes to only that domain.
The following are guidelines for deploying configuration changes.
You can deploy the FMC policy configuration over a VPN tunnel, only if the deployment is for a device that does not terminate the tunnel. The FMC to Firepower Threat Defense management traffic should be its own secure transport SF tunnel and does not need to be over S2S VPN tunnel for any connectivity.
For policy-based VPN tunnel, choose the protected networks on both side to exclude the FMC to Firepower Threat Defense management traffic. For route-based VPN tunnel, configure the routing to exclude the FMC to Firepower Threat Defense management traffic to the VTI interface.
When you push the FMC deployments over the VPN tunnel with the management traffic that is also passing through the tunnel, in the event of any VPN misconfiguration, it inactivates the tunnel and results in disconnecting the FMC and the Firepower Threat Defense.
To reinstantiate the tunnel configuration, you can either:
Remove the sensor from the Firepower Threat Defense and the FMC (resulting in losing all of its configuration), and then add the sensor again to the FMC.
Or
Contact Cisco TAC.
 Note |
Reinstantiating the tunnel configuration requires overhauling of the system. |
Do not apply inline configurations to devices deployed passively, and vice versa.
The time it takes to deploy depends on multiple factors, including (but not limited to):
The configurations you send to the device. For example, if you dramatically increase the number of Security Intelligence entries you block, deploy can take longer.
Device model and memory. On lower-memory devices, deploying can take longer.
Do not exceed the capability of your devices. If you exceed the maximum number of rules or policies supported by a target device, the system displays a warning. The maximum depends on a number of factors—not only memory and the number of processors on the device, but also on policy and rule complexity. For information on optimizing policies and rules, see Best Practices for Access Control Rules.
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated.
For Firepower Threat Defense devices, the Inspect Interruption column in the Deploy dialog warns you when deploying might interrupt traffic flow or inspection. You can either proceed with, cancel, or delay deployment; see Restart Warnings for the FTD Devices for more information.
Caution |
We strongly recommend you deploy in a maintenance window or at a time when interruptions will have the least impact. |
If you are performing application control but disable required detectors, the system automatically enables the appropriate system-provided detectors upon policy deploy. If none exist, the system enables the most recently modified user-defined detector for the application.
When you deploy changes to a network discovery policy, the system deletes and then rediscovers MAC address, TTL, and hops information from the network map for the hosts in your monitored networks. Also, the affected managed devices discard any discovery data that has not yet been sent to the FMC.
When you deploy, the Inspect Interruption column in the deploy dialog specifies whether a deployed configuration restarts the Snort process on the Firepower Threat Defense device. When the traffic inspection engine referred to as the Snort process restarts, inspection is interrupted until the process resumes. Whether traffic is interrupted or passes without inspection during the interruption depends on how the device handles traffic. Note that you can proceed with the deployment, cancel the deployment and modify the configuration, or delay the deployment until a time when deploying would have the least impact on your network.
When the Inspect Interruption column indicates Yes and you expand the device configuration listing, the system highlights in red along with a Restart icon any specific configuration type that would restart the Snort process. When you hover your mouse over these configurations, a message informs you that deploying the configuration may interrupt traffic.
The following table summarizes how the deploy dialog displays inspection interruption warnings.
|
Type |
Inspect Interruption |
Description |
|---|---|---|
|
FTD |
Inspect
Interruption ( |
At least one configuration would interrupt inspection on the device if deployed, and might interrupt traffic depending on how the device handles traffic. You can expand the device configuration listing for more information. |
|
No |
Deployed configurations will not interrupt traffic on the device. |
|
|
Undetermined |
The system cannot determine if a deployed configuration may interrupt traffic on the device, and displays a Device Warning icon next to the device. Undetermined status is displayed before the first deployment after a software upgrade, or in some cases during a Support call. |
|
|
Errors
( |
The system cannot determine the status due to an internal error. Cancel the operation and click Deploy again to allow the system to redetermine the Inspect Interruption status. If the problem persists, contact Support. |
|
|
sensor |
-- |
The device identified as sensor is not the Firepower Threat Defense device; the system does not determine if a deployed configuration may interrupt traffic on this device. |
For information on all configurations that restart the Snort process for all device types, see Configurations that Restart the Snort Process When Deployed or Activated.
Caution |
Do NOT push the FMC deployments over a VPN tunnel that is terminating directly on the Firepower Threat Defense. Pushing the FMC deployments can potentially inactivate the tunnel and disconnect the FMC and the Firepower Threat Defense. Recovering the device from this situation can be very disruptive and require executing the disaster recovery procedure. This procedure resets the Firepower Threat Defense configuration to factory defaults by changing manager from FMC to local and configuring the device from beginning. For more information, see Deploying the FMC Policy Configuration over VPN Tunnel. |
After you change configurations, deploy them to the affected devices. We strongly recommend that you deploy in a maintenance window or at a time when any interruptions to traffic flow and inspection will have the least impact.
Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
Review the guidelines described in Best Practices for Deploying Configuration Changes.
Be sure all managed devices use the same revision of the Security Zones object. If you have edited security zone objects: Do not deploy configuration changes to any device until you edit the zone setting for interfaces on all devices you want to sync. You must deploy to all managed devices at the same time. See Synchronizing Security Zone Object Revisions.
Note |
Policy deployment process fails if the sensor configuration is being read by the system during deployment. Executing commands such as show running-config from the sensor CLI disturbs the deployment, which results in deployment failure.
|
|
Step 1 |
On the FMC menu bar, click Deploy. The Deploy Policies dialog lists devices with out-of-date configurations. The Version at the top of the dialog specifies when you last made configuration changes. |
|
Step 2 |
Identify and choose the devices where you want to deploy configuration changes.
|
|
Step 3 |
Click Deploy. |
|
Step 4 |
If the system identifies errors or warnings in the changes to be deployed, it displays them in the Errors and Warnings for Requested Deployment window. To view complete details, click the Click to view all details link in the Details column. You have the following choices:
|
(Optional) Monitor deployment status; see Viewing Deployment Messages.
If deploy fails, see Best Practices for Deploying Configuration Changes.
During deployment, if there is a deployment failure due to any reason, there is a possibility that the failure may impact traffic. However, it depends on certain conditions. If there are specific configuration changes in the deployment, the deployment failure may lead to traffic being interrupted. See the following table to know what configuration changes may cause traffic interruption when deployment fails.
|
Configuration Changes |
Exists? |
Traffic Impacted? |
|---|---|---|
|
Threat Defense Service changes in an access control policy |
Yes |
Yes |
|
VRF |
Yes |
Yes |
|
Interface |
Yes |
Yes |
|
QoS |
Yes |
Yes |
Note |
The configuration changes interrupting traffic during deployment is valid only if both the FMC and Firepower Threat Defense are of version 6.2.3 or higher. |
You can force-deploy existing (unchanged) configurations to a single managed device. We strongly recommend you deploy in a maintenance window or at a time when any interruptions to traffic flow and inspection will have the least impact.
Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
Review the guidelines described in Best Practices for Deploying Configuration Changes.
|
Step 1 |
Choose . |
||
|
Step 2 |
Click Edit ( In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch. |
||
|
Step 3 |
Click Device. |
||
|
Step 4 |
Click Edit ( |
||
|
Step 5 |
Click Force Deploy
(
|
||
|
Step 6 |
Click Deploy. The system identifies any errors or warnings with the configurations you are deploying. You can click Proceed to continue without resolving warning conditions. However, you cannot proceed if the system identifies an error. |
(Optional) Monitor deployment status; see Viewing Deployment Messages.
If deploy fails, see Best Practices for Deploying Configuration Changes.
When the traffic inspection engine referred to as the Snort process on a managed device restarts, inspection is interrupted until the process resumes. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information. Additionally, resource demands may result in a small number of packets dropping without inspection when you deploy, regardless of whether the Snort process restarts.
Any of the scenarios in the following table cause the Snort process to restart.
|
Restart Scenario |
More Information |
|---|---|
|
Deploying a specific configuration that requires the Snort process to restart. |
Configurations that Restart the Snort Process When Deployed or Activated |
|
Modifying a configuration that immediately restarts the Snort process. |
|
|
Traffic-activation of the currently deployed Automatic Application Bypass (AAB) configuration. |
Inspect traffic during policy apply is an advanced access control policy general setting that allows managed devices to inspect traffic while deploying configuration changes; this is the case unless a configuration that you deploy requires the Snort process to restart. You can configure this option as follows:
Enabled — Traffic is inspected during the deployment unless certain configurations require the Snort process to restart.
When the configurations you deploy do not require a Snort restart, the system initially uses the currently deployed access control policy to inspect traffic, and switches during deployment to the access control policy you are deploying.
Disabled — Traffic is not inspected during the deployment. The Snort process always restarts when you deploy.
The following graphic illustrates how Snort restarts can occur when you enable or disable Inspect traffic during policy apply.
Caution |
When you deploy, resource demands may result in a small number of packets dropping without inspection. Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior and Configurations that Restart the Snort Process When Deployed or Activated. |
The following tables explain how different devices handle traffic when the Snort process restarts.
|
Interface Configuration |
Restart Traffic Behavior |
|---|---|
|
inline: Snort Fail Open: Down: disabled |
dropped |
|
inline: Snort Fail Open: Down: enabled |
passed without inspection Some packets can be delayed in buffer for several seconds before the system recognizes that Snort is down. This delay can vary depending upon the load distribution. However, the buffered packets are eventually passed. |
|
routed, transparent (including EtherChannel, redundant, subinterface): preserve-connection enabled (configure snort preserve-connection enable ; default) For more information, see Cisco Firepower Threat Defense Command Reference. |
existing TCP/UDP flows: passed without inspection so long as at least one packet arrives while Snort is down new TCP/UDP flows and all non-TCP/UDP flows: dropped Note that the following traffic drops even when preserve-connection is enabled:
|
|
routed, transparent (including EtherChannel, redundant, subinterface): preserve-connection disabled (configure snort preserve-connection disable ) |
dropped |
|
inline: tap mode |
egress packet immediately, copy bypasses Snort |
|
passive |
uninterrupted, not inspected |
|
Interface Configuration |
Restart Traffic Behavior |
|---|---|
|
inline: Failsafe enabled or disabled |
passed without inspection A few packets might drop if Failsafe is disabled and Snort is busy but not down. |
|
inline: tap mode |
egress packet immediately, copy bypasses Snort |
|
passive |
uninterrupted, not inspected |
|
Interface Configuration |
Restart Traffic Behavior |
|---|---|
|
routed or transparent with fail-open |
passed without inspection |
|
routed or transparent with fail-close |
dropped |
Note |
In addition to traffic handling when the Snort process is down while it restarts, traffic can also pass without inspection or drop when the Snort process is busy, depending on the configuration of the Failsafe option (see Inline Sets) or the Snort Fail Open Busy option (see Configure an Inline Set). A device supports either the Failsafe option or the Snort Fail Open option, but not both. |
 Warning |
Do not reboot the system while the Snort Rule Update is in progress. |
Snort-busy drops happen when snort is not able to process the packets fast enough. Lina does not know whether Snort is busy due to processing delay, or if is stuck or due to call blocking. When transmission queue is full, snort-busy drops occur. Based on Transmission queue utilization, Lina will try to access if the queue is being serviced smoothly.
Note |
When the Snort process is busy but not down during configuration deployment, some packets may drop on routed, switched, or transparent interfaces if the total CPU load exceeds 60 percent. |
Deploying any of the following configurations except AAB restarts the Snort process as described. Deploying AAB does not cause a restart, but excessive packet latency activates the currently deployed AAB configuration, causing a partial restart of the Snort process.
Deploy when Inspect Traffic During Policy Apply is disabled.
Add or remove an SSL policy.
Deploy the first or last of any one of the following configurations; note that while otherwise deploying these file policy configurations does not cause a restart, deploying non-file-policy configurations can cause restarts.
Take either of the following actions:
Enable or disable Inspect Archives when the deployed access control policy includes at least one file policy.
Add the first or remove the last file policy rule when Inspect Archives is enabled (note that at least one rule is required for Inspect Archives to be meaningful).
Enable or disable Store files in a Detect Files or Block Files rule.
Add the first or remove the last active file rule that combines the Malware Cloud Lookup or Block Malware rule action with an analysis option (Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option (Malware, Unknown, Clean, or Custom).
Note that access control rules that deploy these file policy configurations to security zones or tunnel zones cause a restart only when your configuration meets the following conditions:
Source or destination security zones in your access control rule must match the security zones associated with interfaces on the target devices.
Unless the destination zone in you access control rule is any, a source tunnel zone in the rule must match a tunnel zone assigned to a tunnel rule in the prefilter policy.
When SSL decryption is disabled (that is, when the access control policy does not include an SSL policy), add the first or remove the last active authentication rule.
An active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive or VPN identity cannot be established selected.
Enable or disable non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols, using the network discovery policy.
MTU: Change the highest MTU value among all non-management interfaces on a device.
Automatic Application Bypass (AAB): The currently deployed AAB configuration activates when a malfunction of the Snort process or a device misconfiguration causes a single packet to use an excessive amount of processing time. The result is a partial restart of the Snort process to alleviate extremely high latency or prevent a complete traffic stall. This partial restart causes a few packets to pass without inspection, or drop, depending on how the device handles traffic.
System update: Deploy configurations the first time after a software update that includes a new version of the Snort binary or data acquisition library (DAQ).
VDB: Deploying configurations the first time after installing a vulnerability database (VDB) update that includes changes applicable to managed devices will require a detection engine restart and may result in a temporary traffic interruption. For these, a message warns you when you select the FMC to begin installing. The deploy dialog provides additional warnings for Firepower Threat Defense devices when VDB changes are pending. VDB updates that apply only to the FMC do not cause detection engine restarts, and you cannot deploy them.
The following changes immediately restart the Snort process without going through the deploy process. How the restart affects traffic depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information.
Take any of the following actions involving applications or application detectors:
Activate or deactivate a system or custom application detector.
Delete an activated custom detector.
Save and Reactivate an activated custom detector.
Create a user-defined application.
A message warns you that continuing restarts the Snort process, and allows you to cancel; the restart occurs on any managed device in the current domain or in any of its child domains.
Create or break a Firepower Threat Defense high availability pair—A message warns you that continuing to create a high availability pair restarts the Snort process on the primary and secondary devices and allows you to cancel.
To review policy changes for compliance with your organization's standards or to optimize system performance, you can examine the differences between two policies or between a saved policy and the running configuration.
You can compare the following policy types:
DNS
File
Health
Identity
Intrusion (Only Snort 2 policies)
Network Analysis
SSL
The comparison view displays both policies in a side-by-side format. Differences between the two policies are highlighted:
Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.
Green indicates that the highlighted setting appears in one policy but not the other.
You can compare policies only if you have access rights and any required licenses for the specific policy, and you are in the correct domain for configuring the policy.
|
Step 1 |
Access the management page for the policy you want to compare:
|
||||
|
Step 2 |
Click Compare Policies. |
||||
|
Step 3 |
From the Compare Against drop-down list, choose the type of comparison you want to make:
|
||||
|
Step 4 |
Depending on the comparison type you choose, you have the following choices:
|
||||
|
Step 5 |
Click OK. |
||||
|
Step 6 |
Review the comparison results:
|
For most policies, you can generate two kinds of reports. A report on a single policy provides details on the policy's current saved configuration, while a comparison report lists only the differences between two policies. You can generate a single-policy report for all policy types except health.
Note |
Intrusion policy reports combine the settings in the base policy with the settings of the policy layers, and make no distinction between which settings originated in the base policy or policy layer. |
You can generate policy reports only if you have access rights and any required licenses for the specific policy, and you are in the correct domain for configuring the policy.
|
Step 1 |
Access the management page for the policy for which you want to generate a report:
|
||
|
Step 2 |
Click Report ( |
The Firepower System marks out-of-date policies with red status text that indicates how many of its targeted devices need a policy update. To clear this status, you must re-deploy the policy to the devices.
Configuration changes that require a policy re-deploy include:
Modifying an access control policy: any changes to access control rules, the default action, policy targets, Security Intelligence filtering, advanced options including preprocessing, and so on.
Modifying any of the policies that the access control policy invokes: the SSL policy, network analysis policies, intrusion policies, file policies, identity policies, or DNS policies.
Changing any reusable object or configuration used in an access control policy or policies it invokes:
network, port, VLAN tag, URL, and geolocation objects
Security Intelligence lists and feeds
application filters or detectors
intrusion policy variable sets
file lists
decryption-related objects and security zones
Updating the system software, intrusion rules, or the vulnerability database (VDB).
Keep in mind that you can change some of these configurations from multiple places in the web interface. For example, you can modify security zones using the object manager (), but modifying an interface type in a device’s configuration () can also change a zone and require a policy re-deploy.
Note that the following updates do not require policy re-deploy:
automatic updates to Security Intelligence feeds and additions to the Security Intelligence global Block or Do Not Block list using the context menu
automatic updates to URL filtering data
scheduled geolocation database (GeoDB) updates
Host, application, and user discovery data allow the system to create a complete, up-to-the-minute profile of your network. The system can also act as an intrusion detection and prevention system (IPS), analyzing network traffic for intrusions and exploits and, optionally, dropping offending packets.
Combining discovery and IPS gives context to your network activity and allows you to take advantage of many features, including:
impact flags and indications of compromise, which can tell you which of your hosts are vulnerable to a particular exploit, attack, or piece of malware
adaptive profile updates and Firepower recommendations, which allow you to examine traffic differently depending on the destination host
correlation, which allows you to respond to intrusions (and other events) differently depending on the affected host
However, if your organization is interested in performing only IPS, or only discovery, there are a few configurations that can optimize the performance of the system.
The discovery feature allows you to monitor network traffic and determine the number and types of hosts (including network devices) on your network, as well as the operating systems, active applications, and open ports on those hosts. You can also configure managed devices to monitor user activity on your network. You can use discovery data to perform traffic profiling, assess network compliance, and respond to policy violations.
In a basic deployment (discovery and simple, network-based access control only), you can improve a device’s performance by following a few important guidelines when configuring its access control policy.
Note |
You must use an access control policy, even if it simply allows all traffic. The network discovery policy can only examine traffic that the access control policy allows to pass. |
First, make sure your access control policy does not require complex processing and uses only simple, network-based criteria to handle network traffic. You must implement all of the following guidelines; misconfiguring any one of these options eliminates the performance benefit:
Do not use the Security Intelligence feature. Remove any populated global Block or Do Not Block list from the policy’s Security Intelligence configuration.
Do not include access control rules with Monitor or Interactive Block actions. Use only Allow, Trust, and Block rules. Keep in mind that allowed traffic can be inspected by discovery; trusted and blocked traffic cannot.
Do not include access control rules with application, user, URL, ISE attribute, or geolocation-based network conditions. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.
Do not include access control rules that perform file, malware, or intrusion inspection. In other words, do not associate a file policy or intrusion policy with any access control rule.
In the Advanced settings for the access control policy, make sure that Intrusion Policy used before Access Control rule is determined is set to No Rules Active.
Select Network Discovery Only as the policy’s default action. Do not choose a default action for the policy that performs intrusion inspection.
In conjunction with the access control policy, you can configure and deploy the network discovery policy, which specifies the network segments, ports, and zones that the system examines for discovery data, as well as whether hosts, applications, and users are discovered on the segments, ports, and zones.
Disabling discovery if you don't need it (for example, in an IPS-only deployment) can improve performance. To disable discovery you must implement all of these changes:
Delete all rules from your network discovery policy.
Use only simple network-based conditions to perform access control: zone, IP address, VLAN tag, and port.
Do not perform any kind of Security Intelligence, application, user, URL, or geolocation control. Although you can disable storage of discovery data, the system still must collect and examine it to implement those features.
Disable network and URL-based Security Intelligence by deleting all Block and Do Not Block lists from your access control policy's Security Intelligence configuration, including the default Global lists.
Disable DNS-based Security Intelligence by deleting or disabling all rules in the associated DNS policy, including the default Global Do-Not-Block List for DNS and Global Block List for DNS rules.
After you deploy, new discovery halts on target devices. The system gradually deletes information in the network map according to your timeout preferences. Or, you can purge all discovery data immediately.
)
)
)
)
)
)
Feedback