Introduction to Access Control
Access control is a hierarchical policy-based feature that allows you to specify, inspect, and log (non-fast-pathed) network traffic. Especially useful in multidomain deployments, you can nest access control policies, where each policy inherits the rules and settings from an ancestor (or base) policy. You can enforce this inheritance, or allow lower-level policies to override their ancestors. Each managed device can be targeted by one access control policy.
The data that the policy’s target devices collect about your network traffic can be used to filter and control that traffic based on:
-
simple, easily determined transport and network layer characteristics: source and destination, port, protocol, and so on
-
the latest contextual information on the traffic, including characteristics such as reputation, risk, business relevance, application used, or URL visited
-
realm, user, user group, or ISE attribute
-
characteristics of encrypted traffic; you can also decrypt this traffic for further analysis
-
whether unencrypted or decrypted traffic contains a prohibited file, detected malware, or intrusion attempt
Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility and performance. For example, reputation-based blacklisting uses simple source and destination data, so it can block prohibited traffic early in the process. In contrast, detecting and blocking intrusions and exploits is a last-line defense.
Although you can configure the system without licensing your deployment, many features require that you enable the appropriate licenses before you deploy. Also, some features are only available on certain device models. Warning icons and confirmation dialog boxes designate unsupported features.
![]() Note |
For the system to affect traffic, you must deploy relevant configurations to managed devices using routed, switched, or transparent interfaces, or inline interface pairs. Sometimes, the system prevents you from deploying inline configurations to passively deployed devices, including inline devices in tap mode. In other cases, the policy may deploy successfully, but attempting to block or alter traffic using passively deployed devices can have unexpected results. For example, the system may report multiple beginning-of-connection events for each blocked connection, because blocked connections are not blocked in passive deployments. |
Access Control Policy Components
A newly created access control policy directs its target devices to handle all traffic using its default action.
In the following graphic, the default action uses the Balanced Security and Connectivity intrusion policy to inspect traffic before allowing it to its final destination.

The following list describes the configurations you can change after you create a simple policy.
![]() Note |
You can only edit access control policies that were created in the current domain. Also, you cannot edit settings that are locked by an ancestor access control policy. |
- Name and Description
-
Each access control policy must have a unique name. A description is optional.
- Inheritance Settings
-
Policy inheritance allows you to create a hierarchy of access control policies. A parent (or base) policy defines and enforces default settings for its descendants, which is especially useful in multidomain deployments.
A policy's inheritance settings allow you to select its base policy. You can also lock settings in the current policy to force any descendants to inherit them. Descendant policies can override unlocked settings.
- Policy Assignment
-
Each access control policy identifies the devices that use it. Each device can be targeted by only one access control policy. In a multidomain deployment, you can require that all the devices in a domain use the same base policy.
- Rules
-
Access control rules provide a granular method of handling network traffic. Rules in an access control policy are numbered, starting at 1, including rules inherited from ancestor policies. The system matches traffic to access control rules in top-down order by ascending rule number.
Usually, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. Conditions can be simple or complex, and their use often depends on certain licenses.
- Default Action
-
The default action determines how the system handles and logs traffic that is not handled by any other access control configuration. The default action can block or trust all traffic without further inspection, or inspect traffic for intrusions and discovery data.
Although an access control policy can inherit its default action from an ancestor policy, you cannot enforce this inheritance.
- Security Intelligence
-
Security Intelligence is a first line of defense against malicious internet content. This feature allows you to blacklist (block) connections based on the latest IP address, URL, and domain name reputation intelligence. To ensure continual access to vital resources, you can override blacklists with custom whitelists.
- HTTP Responses
-
When the system blocks a user’s website request, you can either display a generic system-provided response page, or a custom page. You can also display a page that warns users, but also allows them to continue to the originally requested site.
- Advanced Access Control Options
-
Advanced access control policy settings typically require little or no modification. Often, the default settings are appropriate. Advanced settings you can modify include traffic preprocessing, SSL inspection, identity, and various performance options.
Access Control Policy Default Action
In a simple access control policy, the default action specifies how target devices handle all traffic. In a more complex policy, the default action handles traffic that:
-
is not trusted by Intelligent Application Bypass
-
is not blacklisted by Security Intelligence
-
is not blocked by SSL inspection (encrypted traffic only)
-
matches none of the rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic)
The access control policy default action can block or trust traffic without further inspection, or inspect traffic for intrusions and discovery data.
![]() Note |
You cannot perform file or malware inspection on traffic handled by the default action. Logging for connections handled by the default action is initially disabled, though you can enable it. |
If you are using policy inheritance, the default action for the lowest-level descendant determines final traffic handling. Although an access control policy can inherit its default action from its base policy, you cannot enforce this inheritance.
The following table describes the types of inspection you can perform on traffic handled by each default action.
Default Action |
Effect on Traffic |
Inspection Type and Policy |
---|---|---|
Access Control: Block All Traffic |
block without further inspection |
none |
Access Control: Trust All Traffic |
trust (allow to its final destination without further inspection) |
none |
Intrusion Prevention |
allow, as long as it is passed by the intrusion policy you specify |
intrusion, using the specified intrusion policy and associated variable set, and discovery, using the network discovery policy |
Network Discovery Only |
allow |
discovery only, using the network discovery policy |
Inherit from base policy |
defined in base policy |
defined in base policy |
The following diagram illustrates the table.
The following diagrams illustrate the Block All Traffic and Trust All Traffic default actions.
The following diagrams illustrate the Intrusion Prevention and Network Discovery Only default actions.
![]() Tip |
The purpose of Network Discovery Only is to improve performance in a discovery-only deployment. Different configurations can disable discovery if you are only interested in intrusion detection and prevention. |
Access Control Policy Inheritance
Access control uses a hierarchical policy-based implementation that complements multitenancy. Just as you create a domain hierarchy, you can create a corresponding hierarchy of access control policies. A descendant, or child, access control policy inherits rules and settings from its direct parent, or base, policy. That base policy may have its own parent policy from which it inherits rules and settings, and so on.
An access control policy’s rules are nested between its parent policy’s Mandatory and Default rule sections. This implementation enforces Mandatory rules from ancestor policies, but allows the current policy to write rules that preempt Default rules from ancestor policies.
You can lock the following settings to enforce them in all descendant policies. Descendant policies can override unlocked settings.
-
Security Intelligence — Blacklisting and whitelisting connections based on the latest IP address, URL, and domain name reputation intelligence.
-
HTTP Response pages — Displaying a custom or system-provided response page when you block a user's website request.
-
Advanced settings — Specifying associated subpolicies, network analysis settings, performance settings, and other general options.
Although an access control policy can inherit its default action from an ancestor policy, you cannot enforce this inheritance.
Policy Inheritance and Multitenancy
In a typical multidomain deployment, access control policy hierarchy corresponds to domain structure, and you apply the lowest-level access control policy to managed devices. This implementation allows selective access control enforcement at a higher domain level, while lower-level domain administrators can tailor deployment-specific settings. (You must use roles, not policy inheritance and enforcement alone, to restrict administrators in descendant domains.)
For example, as a Global domain administrator for your organization, you can create an access control policy at the Global level. You can then require that all your devices, which are divided into subdomain by function, use that Global-level policy as a base policy.
When subdomain administrators log into the Firepower Management Center to configure access control, they can deploy the Global-level policy as-is. Or, they can create and deploy a descendant access control policy within the boundaries of the Global-level policy.
![]() Note |
Although the most useful implementation of access control inheritance and enforcement complements multitenancy, you can create a hierarchy of access control policies within a single domain. You can also assign and deploy access control policies at any level. |