- Logging into the Firepower System
- Specifying User Preferences
- Firepower System User Management
- Licensing the Firepower System
- System Updates
- Backup and Restore
- Configuration Import and Export
- Task Scheduling
- Data Storage
- Device Management Basics
- Dashboards
- Health Monitoring
- Monitoring the System
- Domain Management
- Policy Management
- Rule Management: Common Characteristics
- Reusable Objects
- Classic Device Management Basics
- IPS Device Deployments and Configuration
- 7000 and 8000 Series Device High Availability
- 8000 Series Device Stacking
- System Configuration
- Platform Settings Policies
- Platform Settings for Classic Devices
- NAT Policy Management
- NAT for 7000 and 8000 Series Devices
- Setting Up Virtual Switches
- Setting Up Virtual Routers
- Aggregate Interfaces and LACP
- Hybrid Interfaces
- Gateway VPNs
- Understanding Access Control
- Best Practices for Access Control
- Access Control Policies
- Access Control Rules
- URL Filtering
- HTTP Response Pages and Interactive Blocking
- Blocking Traffic with Security Intelligence
- DNS Policies
- Intelligent Application Bypass
- Understanding Traffic Decryption
- Start Creating SSL Policies
- Get Started with TLS/SSL Rules
- Decryption Tuning Using TLS/SSL Rules
- Troubleshoot TLS/SSL Rules
- File Policies and Malware Protection
- File and Malware Inspection Performance and Storage Tuning
- An Overview of Intrusion Detection and Prevention
- Layers in Intrusion and Network Analysis Policies
- Getting Started with Intrusion Policies
- Tuning Intrusion Policies Using Rules
- Tailoring Intrusion Protection to Your Network Assets
- Sensitive Data Detection
- Globally Limiting Intrusion Event Logging
- The Intrusion Rules Editor
- Intrusion Prevention Performance Tuning
- Advanced Access Control Settings for Network Analysis and Intrusion Policies
- Getting Started with Network Analysis Policies
- Application Layer Preprocessors
- SCADA Preprocessors
- Transport & Network Layer Preprocessors
- Detecting Specific Threats
- Adaptive Profiles
- Introduction to Network Discovery and Identity
- Host Identity Sources
- Application Detection
- User Identity Sources
- Network Discovery Policies
- Realms and Identity Policies
- Compliance White Lists
- Correlation Policies
- Traffic Profiling
- Remediations
- Working with Reports
- External Alerting with Alert Responses
- External Alerting for Intrusion Events
- Using the Context Explorer
- Using the Network Map
- Incidents
- Workflows
- Searching for Events
- Custom Workflows
- Custom Tables
- Connection Logging
- Connection and Security Intelligence Events
- Working with Intrusion Events
- File/Malware Events and Network File Trajectory
- Using Host Profiles
- Working with Discovery Events
- Correlation and Compliance Events
- Auditing the System
Book Title
Firepower Management Center Configuration Guide, Version 6.0
Getting Started with Intrusion Policies
- PDF - Complete Book (37.68 MB)PDF - This Chapter (1.13 MB) View with Adobe Reader on a variety of devices
Results
Updated: April 5, 2023Chapter: Getting Started with Intrusion Policies
Chapter Contents- Getting Started with Intrusion Policies
- Intrusion Policy Basics
- License Requirements for Intrusion Policies
- Requirements and Prerequisites for Intrusion Policies
- Managing Intrusion Policies
- Custom Intrusion Policy Creation
- Creating a Custom Intrusion Policy
- Intrusion Policy Changes
- Access Control Rule Configuration and Intrusion Policies
- Configuring an Access Control Rule to Perform Intrusion Prevention
- Setting Drop Behavior in an Inline Deployment
Getting Started with Intrusion Policies
The following topics explain how to get started with intrusion policies:
Intrusion Policy Basics
Intrusion policies are defined sets of intrusion detection and prevention configurations that inspect traffic for security violations and, in inline deployments, can block or alter malicious traffic. Intrusion policies are invoked by your access control policy and are the system’s last line of defense before traffic is allowed to its destination.
At the heart of each intrusion policy are the intrusion rules. An enabled rule causes the system to generate intrusion events for (and optionally block) traffic matching the rule. Disabling a rule stops processing of the rule.
The Firepower System delivers several base intrusion policies, which enable you to take advantage of the experience of the Cisco Talos Intelligence Group (Talos) . For these policies, Talos sets intrusion and preprocessor rule states (enabled or disabled), as well as provides the initial configurations for other advanced settings.
System-provided intrusion and network analysis policies are similarly named but contain different configurations. For example, the Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy governs mostly intrusion rules.
If you create a custom intrusion policy, you can:
- Tune detection by enabling and disabling rules, as well as by writing and adding your own rules.
- Use Firepower recommendations to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets.
- Configure various advanced settings such as external alerting, sensitive data preprocessing, and global rule thresholding.
- Use layers as building blocks to efficiently manage multiple intrusion policies.
In an inline deployment, an intrusion policy can block and modify traffic:
- Drop rules can drop matching packets and generate intrusion events. To configure an intrusion or preprocessor drop rule, set its state to Drop and Generate Events.
- Intrusion rules can use the replace keyword to replace malicious content.
For intrusion rules to affect traffic, you must correctly configure drop rules and rules that replace content, as well as correctly deploy managed devices inline, that is, with inline interface sets. Finally, you must enable the intrusion policy’s drop behavior, or Drop when Inline setting.
When tailoring your intrusion policy, especially when enabling and adding rules, keep in mind that some intrusion rules require that traffic first be decoded or preprocessed in a certain way. Before an intrusion policy examines a packet, the packet is preprocessed according to configurations in a network analysis policy. If you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.
Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task.
After you configure a custom intrusion policy, you can use it as part of your access control configuration by associating the intrusion policy with one or more access control rules or an access control policy’s default action. This forces the system to use the intrusion policy to examine certain allowed traffic before the traffic passes to its final destination. A variable set that you pair with the intrusion policy allows you to accurately reflect your home and external networks and, as appropriate, the servers on your network.
Note that by default, the system disables intrusion inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion inspection configured.
License Requirements for Intrusion Policies
FTD License
Classic License
Requirements and Prerequisites for Intrusion Policies
Model Support
Supported Domains
User Roles
- Admin
- Intrusion Admin
Managing Intrusion Policies
On the Intrusion Policy page ( Policies > Access Control > Intrusion ) you can view your current custom intrusion policies, along with the following information:
- the time and date the policy was last modified (in local time) and the user who modified it
- whether the Drop when Inline setting is enabled, which allows you to drop and modify traffic in an inline deployment
- which access control policies and devices are using the intrusion policy to inspect traffic
- whether a policy has unsaved changes, as well as information about who (if anyone) is currently editing the policy
- in a multidomain deployment, the domain where the policy was created
Procedure
Choose Policies > Access Control > Intrusion .
Manage your intrusion policy:
Custom Intrusion Policy Creation
When you create a new intrusion policy you must give it a unique name, specify a base policy, and specify drop behavior.
The base policy defines the intrusion policy’s default settings. Modifying a setting in the new policy overrides—but does not change—the settings in the base policy. You can use either a system-provided or custom policy as your base policy.
The intrusion policy’s drop behavior, or Drop when Inline setting, determines how the system handles drop rules (intrusion or preprocessor rules whose rule state is set to Drop and Generate Events) and other intrusion policy configurations that affect traffic. You should enable drop behavior in inline deployments when you want to drop or replace malicious packets. Note that in passive deployments, the system cannot affect traffic flow regardless of the drop behavior.
Creating a Custom Intrusion Policy
Procedure
Choose Policies > Access Control > Intrusion .
Click Create Policy . If you have unsaved changes in another policy, click Cancel when prompted to return to the Intrusion Policy page.
Enter a unique Name and, optionally, a Description .
Choose the initial Base Policy .
You can use either a system-provided or another custom policy as your base policy.
Set the system’s drop behavior in an inline deployment as described in Setting Drop Behavior in an Inline Deployment.
Create the policy:
- Click Create Policy to create the new policy and return to the Intrusion Policy page. The new policy has the same settings as its base policy.
- Click Create and Edit Policy to create the policy and open it for editing in the advanced intrusion policy editor; see Intrusion Policy Changes.
Editing Snort 2 Intrusion Policies
Procedure
Choose Policies > Access Control > Intrusion .
Click Edit () next to the intrusion policy you want to configure.
If View () appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
Edit your policy:
- Change the base policy—Choose a base policy from the Base Policy drop-down list; see Changing the Base Policy.
- Configure advanced settings—Click Advanced Settings in the navigation panel; see Intrusion Policy Advanced Settings.
- Configure Firepower recommended intrusion rules—Click Firepower Recommendations in the navigation panel; see Generating and Applying Firepower Recommendations.
- Drop behavior in an inline deployment—Check or clear Drop when Inline ; see Setting Drop Behavior in an Inline Deployment.
- Filter rules by recommended rule state—After you generate recommendations, click View next to each recommendation type. Click View Recommended Changes to view all recommendations.
- Filter rules by current rule state—Click View next to each rule state type (generate events, drop and generate events); see Intrusion Rule Filters in an Intrusion Policy.
- Manage policy layers—Click Policy Layers in the navigation panel; see Layer Management.
- Manage intrusion rules—Click Manage Rules ; see Viewing Intrusion Rules in an Intrusion Policy.
- View settings in base policy—Click Manage Base Policy ; see The Base Layer.
To save changes you made in this policy since the last policy commit, choose Policy Information , then click Commit Changes .
If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.
What to do next
- Deploy configuration changes; see Deploy Configuration Changes.
Intrusion Policy Changes
When you create a new intrusion policy, it has the same intrusion rule and advanced settings as its base policy.
The system caches one intrusion policy per user. While editing an intrusion policy, if you choose any menu or other path to another page, your changes stay in the system cache even if you leave the page.
Access Control Rule Configuration to Perform Intrusion Prevention
An access control policy can have multiple access control rules associated with intrusion policies. You can configure intrusion inspection for any Allow or Interactive Block access control rule, which permits you to match different intrusion inspection profiles against different types of traffic on your network before it reaches its final destination.
Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Variables in a set represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions and dynamic rule states.
Even if you use system-provided intrusion policies, Cisco strongly recommends you configure the system’s intrusion variables to accurately reflect your network environment. At a minimum, modify default variables in the default set.
Understanding System-Provided and Custom Intrusion Policies
Cisco delivers several intrusion policies with the Firepower System. By using system-provided intrusion policies, you can take advantage of the experience of the Cisco Talos Intelligence Group (Talos) . For these policies, Talos sets intrusion and preprocessor rule states, as well as provides the initial configurations for advanced settings. You can use system-provided policies as-is, or you can use them as the base for custom policies. Building custom policies can improve the performance of the system in your environment and provide a focused view of the malicious traffic and policy violations occurring on your network.
Connection and Intrusion Event Logging
When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, it saves that event to the Firepower Management Center . The system also automatically logs the end of the connection where the intrusion occurred to the Firepower Management Center database, regardless of the logging configuration of the access control rule.
Access Control Rule Configuration and Intrusion Policies
The number of unique intrusion policies you can use in a single access control policy depends on the model of the target devices; more powerful devices can handle more. Every unique pair of intrusion policy and variable set counts as one policy. Although you can associate a different intrusion policy-variable set pair with each Allow and Interactive Block rule (as well as with the default action), you cannot deploy an access control policy if the target devices have insufficient resources to perform inspection as configured.
Configuring an Access Control Rule to Perform Intrusion Prevention
You must be an Admin, Access Admin, or Network Admin to perform this task.
Changing the total number of intrusion policies used by an access control policy restarts the Snort process when you deploy configuration changes, temporarily interrupting 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 for more information. You change the the total number of intrusion policies by adding an intrusion policy that is not currently used, or by removing the last instance of an intrusion policy. You can use an intrusion policy in an access control rule, as the default action, or as the default intrusion policy.
Procedure
In the access control policy editor, create a new rule or edit an existing rule; see Access Control Rule Components.
Ensure the rule action is set to Allow , Interactive Block , or Interactive Block with reset .
Choose a system-provided or custom Intrusion Policy , or choose None to disable intrusion inspection for traffic that matches the access control rule.
If you want to change the variable set associated with the intrusion policy, choose a value from the Variable Set drop-down list.
Click Save to save the rule.
Click Save to save the policy.
What to do next
- Deploy configuration changes; see Deploy Configuration Changes.
Drop Behavior in an Inline Deployment
If you want to assess how your configuration would function in an inline deployment (that is, where relevant configurations are deployed to devices using routed, switched, or transparent interfaces, or inline interface pairs) without actually affecting traffic, you can disable drop behavior. In this case, the system generates intrusion events but does not drop packets that trigger the drop rules. When you are satisfied with the results, you can enable drop behavior.
Note that in passive deployments or inline deployments in tap mode, the system cannot affect traffic regardless of the drop behavior. In a passive deployment, rules set to Drop and Generate Events behave identically to rules set to Generate Events . The system generates intrusion events but cannot drop packets.
Suppose a file Block action causes a Block or Pending file policy verdict on a packet, and later, an IPS event is generated on the same packet. In that case, the IPS event is marked as Dropped instead of Would have dropped even if the IPS policy is in detection mode (IDS).
To block the transfer of malware over FTP, you must not only correctly configure AMP for Networks , but also enable Drop when Inline in your access control policy’s default intrusion policy.
When you view intrusion events, workflows can include the inline result, which indicates whether traffic was actually dropped, or whether it only would have dropped.
Setting Drop Behavior in an Inline Deployment
Procedure
Choose Policies > Access Control > Intrusion .
Click Snort 2 Version next to the policy you want to edit.
If View () appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
Set the policy’s drop behavior:
- Check the Drop when Inline check box to allow intrusion rules to affect traffic and generate events.
- Clear the Drop when Inline check box to prevent intrusion rules from affecting traffic while still generating events.
Click Commit Changes to save changes you made in this policy since the last policy commit.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.
What to do next
- Deploy configuration changes; see Deploy Configuration Changes.
Drop Behavior in a Dual System Deployment
When there are two systems connected back to back in a network, it is normal to see the first system drop events and still record a drop or "would have dropped" event on the second system. The first system decides to drop the packets by the time it scans the last packet of the file, while the second system also investigates and identifies the traffic as "to be dropped".
For example, a 5 packet HTTP GET request whose first packet triggers a rule is blocked by the first system and only the last packet is dropped. The second system receives only 4 packets and the connection gets dropped, but when the second system finally flushes the partial GET request while it is pruning the session, it triggers the same rule with "would have dropped" as the inline result.
Intrusion Policy Advanced Settings
An intrusion policy’s advanced settings require specific expertise to configure. The base policy for your intrusion policy determines which advanced settings are enabled by default and the default configuration for each.
When you choose Advanced Settings in the navigation panel of an intrusion policy, the policy lists its advanced settings by type. On the Advanced Settings page, you can enable or disable advanced settings in your intrusion policy, as well as access advanced setting configuration pages. An advanced setting must be enabled for you to configure it.
When you disable an advanced setting, the sublink and Edit link no longer appear, but your configurations are retained. Note that some intrusion policy configurations (sensitive data rules, SNMP alerts for intrusion rules) require enabled and correctly configured advanced settings.
Modifying the configuration of an advanced setting requires an understanding of the configuration you are modifying and its potential impact on your network.
Specific Threat Detection
The sensitive data preprocessor detects sensitive data such as credit card numbers and Social Security numbers in ASCII text.
Note that other preprocessors that detect specific threats (back orifice attacks, several portscan types, and rate-based attacks that attempt to overwhelm your network with excessive traffic) are configured in network analysis policies.
Intrusion Rule Thresholds
Global rule thresholding can prevent your system from being overwhelmed with a large number of events by allowing you to use thresholds to limit the number of times the system logs and displays intrusion events.
External Responses
In addition to the various views of intrusion events in the web interface, you can enable logging to system log (syslog) facilities or send event data to an SNMP trap server. Per policy, you can specify intrusion event notification limits, set up intrusion event notification to external logging facilities, and configure external responses to intrusion events.
Note that in addition to these per-policy alerting configurations, you can globally enable or disable email alerting on intrusion events for each rule or rule group. Your email alert settings are used regardless of which intrusion policy processes a packet.
Optimizing Performance for Intrusion Detection and Prevention
If you want the Firepower System to perform intrusion detection and prevention but do not need to take advantage of discovery data, you can optimize performance by disabling new discovery as described below.
Before you begin
To perform this task, you must have one of the following user roles:
- Admin, Access Admin, or Network Admin for access control.
- Admin or Discovery Admin for network discovery.
Procedure
Modify or delete rules associated with the access control policy deployed at the target device. None of the access control rules associated with that device can have user, application, or URL conditions; see Create and Edit Access Control Rules.
Delete all rules from the network discovery policy for the target device; see Configuring Network Discovery Rules.
Deploy the changed configuration to the target device; see Deploy Configuration Changes.
