Describes how system-provided and custom network analysis and intrusion policies work together in access control policies to examine and process network traffic for security threats.
Network analysis and intrusion policies are security mechanisms that
examine traffic through preprocessing and intrusion prevention phases,
provide system-provided default configurations for immediate deployment, and
allow custom policy creation for tailored security requirements.
Default policy behavior in access control deployments
By default, a newly created access control policy invokes system-provided network analysis and intrusion policies to examine traffic.
This diagram shows how a newly created access control policy in an inline, intrusion-prevention deployment initially handles traffic:
The traffic flow demonstrates these characteristics:
A default network analysis policy governs the preprocessing of all traffic handled by the access control policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default.
The default action of the access control policy allows all non-malicious traffic, as determined by the system-provided Balanced Security and Connectivity intrusion policy. Because the default action allows traffic to pass, the discovery feature can examine it for host, application, and user data before the intrusion policy can examine and potentially block malicious traffic.
The policy uses default Security Intelligence options (global Block and Do Not Block lists only), does not decrypt encrypted traffic with an SSL policy, and does not perform special handling and inspection of network traffic using access control rules.
A simple step you can take to tune your intrusion prevention deployment is to use a different set of system-provided network analysis and intrusion policies as your defaults. Cisco delivers several pairs of these policies with the system.
Or, you can tailor your intrusion prevention deployment by creating and using custom policies. You may find that the inspector options, intrusion rule, and other advanced settings configured in those policies do not address the security needs of your network. By tuning your network analysis and intrusion policies, you can control at a very granular level how the system processes and inspects traffic on your network for intrusions.
System-provided network analysis and intrusion policies
System-provided network analysis and intrusion policies are security configurations that
leverage the experience of the Cisco Talos Intelligence Group (Talos) for intrusion and inspector rule states and advanced settings,
provide starting points for well tuned defensive policies covering common network setups, and
receive automatic updates through Lightweight Security Package (LSP) releases for new vulnerabilities.
Key characteristics and usage
No system-provided policy covers every network profile, traffic mix, or defensive posture. Each covers common cases and network setups that provide a starting point for a well-tuned defensive policy. Although you can use system-provided policies as-is, Cisco strongly recommends that you use them as the base for custom policies that you tune to suit your network.
Tip
Even if you use system-provided network analysis and intrusion policies, you should configure the system's intrusion variables to accurately reflect your network environment. At a minimum, modify key default variables in the default set.
As new vulnerabilities become known, Talos releases intrusion rule updates, also known as Lightweight Security Package (LSP). These rule updates can modify any system-provided network analysis or intrusion policy, and can provide new and updated intrusion rules and inspector rules, modified states for existing rules, and modified default policy settings. Rule updates may also delete rules from system-provided policies and provide new rule categories, as well as modify the default variable set.
If a rule update affects your deployment, the web interface marks affected intrusion and network analysis policies as out of date, as well as their parent access control policies. You must re-deploy an updated policy for its changes to take effect.
For your convenience, you can configure rule updates to automatically re-deploy affected intrusion policies, either alone or in combination with affected access control policies. This allows you to easily and automatically keep your deployment up-to-date to protect against recently discovered exploits and intrusions.
To ensure up-to-date preprocessing settings, you must re-deploy access control policies, which also deploys any associated SSL, network analysis, and file policies that are different from those currently running, and can also update default values for advanced preprocessing and performance options.
Cisco delivers the system-provided network analysis and intrusion policies:
Balanced Security and Connectivity network analysis and intrusion policies — These policies are built for both speed and detection. Used together, they serve as a good starting point for most organizations and deployment types. The system uses the Balanced Security and Connectivity policies and settings as defaults in most cases.
Connectivity Over Security network analysis and intrusion policies — These policies are built for organizations where connectivity (being able to get to all resources) takes precedence over network infrastructure security. The intrusion policy enables far fewer rules than those enabled in the Security over Connectivity policy. Only the most critical rules that block traffic are enabled.
Security Over Connectivity network analysis and intrusion policies — These policies are built for organizations where network infrastructure security takes precedence over user convenience. The intrusion policy enables numerous network anomaly intrusion rules that could alert on or drop legitimate traffic.
Maximum Detection network analysis and intrusion policies — These policies are built for organizations where network infrastructure security is given even more emphasis than is given by the Security Over Connectivity policies, with the potential for even greater operational impact. For example, the intrusion policy enables rules in a large number of threat categories including malware, exploit kit, old and common vulnerabilities, and known in-the-wild exploits.
No Rules Active intrusion policy — In the No Rules Active intrusion policy, all intrusion rules, and all advanced settings except intrusion rule thresholds, are disabled. This policy provides a starting point if you want to create your own intrusion policy instead of basing it on the enabled rules in one of the other system-provided policies.
Note
Depending on the system-provided base policy that is selected, the settings of the policy vary. To view the policy settings, click the Edit icon next to the policy and then click the Base Policy drop-down menu.
Benefits of custom network analysis and intrusion policies
Custom network analysis and intrusion policies are security configurations that:
improve system performance in your specific environment,
provide a focused view of malicious traffic and policy violations occurring on your network, and
allow granular configuration of how the system processes and inspects network traffic for intrusions.
Custom policy structure
You may find that the inspector options, intrusion rules, and other advanced settings configured in the system-provided network analysis and intrusion policies do not fully address the security needs of your organization.
All custom policies have a base policy, also called a base layer, which defines the default settings for all configurations in the policy. A layer is a building block that you can use to efficiently manage multiple network analysis or intrusion policies.
In most cases, you base custom policies on system-provided policies, but you can use another custom policy. However, all custom policies have a system-provided policy as the eventual base in a policy chain. Because rule updates can modify system-provided policies, importing a rule update may affect you even if you are using a custom policy as your base. If a rule update affects your deployment, the web interface marks affected policies as out of date.
Custom network analysis policy benefits
Custom network analysis policies:
enable tuning preprocessing to match specific traffic characteristics and monitoring requirements,
reduce system processing overhead by disabling unnecessary inspectors, and
allow tailored preprocessing for different security zones, networks, or VLANs in complex deployments.
By default, one network analysis policy preprocesses all unencrypted traffic handled by the access control policy. That means that all packets are decoded and preprocessed according to the same settings, regardless of the intrusion policy (and therefore intrusion rule set) that later examines them.
Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default. A simple way to tune preprocessing is to create and use a custom network analysis policy as the default.
Tuning options available vary by inspector, but some of the ways you can tune inspectors and decoders include:
You can disable inspectors that do not apply to the traffic you are monitoring. For example, the HTTP Inspect inspector normalizes HTTP traffic. If you are confident that your network does not include any web servers using Microsoft Internet Information Services (IIS), you can disable the inspector option that looks for IIS-specific traffic and thereby reduce system processing overhead.
Note
If you disable an inspector in a custom network analysis policy, but the system needs to use that inspector to later evaluate packets against an enabled intrusion or inspector rule, the system automatically enables and uses the inspector although the inspector remains disabled in the network analysis policy web interface.
Specify ports, where appropriate, to focus the activity of certain inspectors. For example, you can identify additional ports to monitor for DNS server responses, encrypted SSL sessions, or ports on which you decode telnet, HTTP, and RPC traffic.
If you are an advanced user with a complex deployment, you can create multiple network analysis policies, each tailored to preprocess traffic differently. Then, you can configure the system to use those policies to govern the preprocessing of traffic using different security zones, networks, or VLANs. (Note that ASA FirePOWER modules cannot restrict preprocessing by VLAN.)
Note
Tailoring preprocessing using custom network analysis policies—especially multiple network analysis policies—is an advanced task. Because preprocessing and intrusion inspection are so closely related, you must be careful to allow the network analysis and intrusion policies examining a single packet to complement each other.
Benefits of custom intrusion policies
Custom intrusion policies are security configurations that
enable tailored traffic inspection through multiple specialized intrusion policies
manage which intrusion and inspector rules are enabled and how they are configured, and
allow access control rules to specify which policy inspects which traffic based on multiple criteria.
In a newly created access control policy initially configured to perform intrusion prevention, the default action allows all traffic, but first inspects it with the system-provided Balanced Security and Connectivity intrusion policy. Unless you add access control rules or change the default action, all traffic is inspected by that intrusion policy.
To customize your intrusion prevention deployment, you can create multiple intrusion policies, each tailored to inspect traffic differently. Then, configure an access control policy with rules that specify which policy inspects which traffic. Access control rules can be simple or complex, matching and inspecting traffic using multiple criteria including security zone, network or geographical location, VLAN, port, application, requested URL, or user.
The main function of intrusion policies is to manage which intrusion and inspector rules are enabled and how they are configured, as follows:
Within each intrusion policy, you should verify that all rules applicable to your environment are enabled, and improve performance by disabling rules that are not applicable to your environment. You can specify which rules should drop or modify malicious packets.
Cisco recommendations allow you to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets.
You can modify existing rules and write new standard text rules as needed to catch new exploits or to enforce your security policies.
Other customizations you might make to an intrusion policy include:
The sensitive data preprocessor detects sensitive data such as credit card numbers and Social Security numbers in ASCII text. Note that other inspectors 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.
Global thresholds cause the system to generate events based on how many times traffic matching an intrusion rule originates from or is targeted to a specific address or address range within a specified time period. This helps prevent the system from being overwhelmed with a large number of events.
Suppressing intrusion event notifications and setting thresholds for individual rules or entire intrusion policies can also prevent the system from being overwhelmed with a large number of events.
In addition to the various views of intrusion events within the web interface, you can enable logging to syslog facilities or send event data to an SNMP trap server. For each 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.
Limitations of custom policies
Because preprocessing and intrusion inspection are so closely related, you must be careful that your configuration allows the network analysis and intrusion policies processing and examining a single packet to complement each other.
By default, the system uses one network analysis policy to preprocess all traffic handled by managed devices using a single access control policy. This diagram shows how a newly created access control policy in an inline intrusion-prevention deployment initially handles traffic. The preprocessing and intrusion prevention phases are highlighted.
Notice how a default network analysis policy governs the preprocessing of all traffic handled by the access control policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default.
You can tune preprocessing by creating and using a custom network analysis policy as the default. However, if you disable a inspector in a custom network analysis policy but the system needs to evaluate preprocessed packets against an enabled intrusion or inspector rule, the system automatically enables and uses the inspector although it remains disabled in the network analysis policy web interface.
Note
In order to get the performance benefits of disabling an inspector, you must make sure that none of your intrusion policies have enabled rules that require that inspector.
An additional challenge arises if you use multiple custom network analysis policies. For advanced users with complex deployments, you can tailor preprocessing to specific security zones, networks, and VLANs by assigning custom network analysis policies to preprocess matching traffic. (Note that ASA FirePOWER cannot restrict preprocessing by VLAN.) To accomplish this, you add custom network analysis rules to your access control policy. Each rule has an associated network analysis policy that governs the preprocessing of traffic that matches the rule.
Tip
You configure network analysis rules as an advanced setting in an access control policy. Unlike other types of rules, network analysis rules invoke network analysis policies, rather than being contained by them.
The system matches packets to any configured network analysis rules in top-down order by rule number. Traffic that does not match any network analysis rule is preprocessed by the default network analysis policy. While this allows you a great deal of flexibility in preprocessing traffic, keep in mind that all packets, regardless of which network analysis policy preprocessed them, are subsequently matched to access control rules—and thus to potential inspection by intrusion policies—in their own process. In other words, preprocessing a packet with a particular network analysis policy does not guarantee that the packet will be examined with any particular intrusion policy. You must carefully configure your access control policy so it invokes the correct network analysis and intrusion policies to evaluate a particular packet.
The diagram shows in detail how the network analysis policy (preprocessing) selection phase occurs before and separately from the intrusion prevention (rules) phase. For simplicity, the diagram eliminates the discovery and file or malware inspection phases. It also highlights the default network analysis and default-action intrusion policies.
In this scenario, an access control policy is configured with two network analysis rules and a default network analysis policy:
Network Analysis Rule A preprocesses matching traffic with Network Analysis Policy A. Later, you want this traffic to be inspected by Intrusion Policy A.
Network Analysis Rule B preprocesses matching traffic with Network Analysis Policy B. Later, you want this traffic to be inspected by Intrusion Policy B.
All remaining traffic is preprocessed with the default network analysis policy. Later, you want this traffic to be inspected by the intrusion policy associated with the default action of the access control policy.
After the system preprocesses traffic, it can examine the traffic for intrusions. The diagram shows an access control policy with two access control rules and a default action:
Access Control Rule A allows matching traffic. The traffic is then inspected by Intrusion Policy A.
Access Control Rule B allows matching traffic. The traffic is then inspected by Intrusion Policy B.
The default action of the access control policy allows matching traffic. The traffic is then inspected by the default action's intrusion policy.
Each packet's handling is governed by a network analysis policy and intrusion policy pair, but the system does not coordinate the pair for you. Consider a scenario where you misconfigure your access control policy so that Network Analysis Rule A and Access Control Rule A do not process the same traffic. For example, you could intend the paired policies to govern the handling of traffic on a particular security zone, but you mistakenly use different zones in the two rules' conditions. This could cause traffic to be incorrectly preprocessed. For this reason, tailoring preprocessing using network analysis rules and custom policies is an advanced task.
Note that for a single connection, although the system selects a network analysis policy before an access control rule, some preprocessing (notably application layer preprocessing) occurs after access control rule selection. This does not affect how you configure preprocessing in custom network analysis policies.
