Access Control Policies

The following topics describe how to work with access control policies:

Access Control Policy Components

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 block connections based on the latest IP address, URL, and domain name reputation intelligence. To ensure continual access to vital resources, you can override Block list entries with custom Do Not Block list entries.

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.

Logging

Settings for access control policy logging allow you to configure default syslog destinations for the current access control policy. The settings are applicable to the access control policy and all the included SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with custom settings in included rules and policies.

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.

Requirements and Prerequisites for Access Control Policies

Model Support

Any

Supported Domains

Any

User Roles

  • Admin

  • Access Admin

  • Network Admin

Managing Access Control Policies

The Firepower System allows you to edit system-provided access control policies and create custom access control policies.

In a multidomain deployment, the system displays policies created in the current domain, which you can edit. It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created in a lower domain, switch to that domain.

Procedure


Step 1

Choose Policies > Access Control .

Step 2

Manage access control policies:


System-Created Access Control Policies

Depending on your devices' initial configurations, system-provided policies can include:

  • Default Access Control—Blocks all traffic without further inspection.

  • Default Intrusion Prevention—Allows all traffic, but also inspects with the Balanced Security and Connectivity intrusion policy and default intrusion variable set.

  • Default Network Discovery—Allows all traffic while inspecting it for discovery data but not intrusions or exploits.

Creating a Basic Access Control Policy

When you create a new access control policy, you must, at minimum, choose a default action.

In most cases, logging of connections handled by a default action is initially disabled. An exception occurs if you create a subpolicy in a multidomain deployment. In that case, the system enables connection logging according to the logging configuration of the inherited default action.

Before you begin

Make sure you've addressed the steps up to this point in Setting Up Basic Policies and Configurations.

Procedure


Step 1

Choose Policies > Access Control .

Step 2

Click New Policy.

Step 3

Enter a unique Name and, optionally, a Description.

Step 4

Optionally, choose a base policy from the Select Base Policy drop-down list.

If an access control policy is enforced on your domain, this step is not optional. You must choose the enforced policy or one of its descendants as the base policy.

Step 5

Specify the initial Default Action:

  • If you chose a base policy, your new policy inherits its default action. You cannot change it here.
  • Block all traffic creates a policy with the Access Control: Block All Traffic default action.
  • Intrusion Prevention creates a policy with the Intrusion Prevention: Balanced Security and Connectivity default action, associated with the default intrusion variable set.
  • Network Discovery creates a policy with the Network Discovery Only default action.

Tip

 

If you want to trust all traffic by default, or if you chose a base policy and do not want to inherit the default action, you can change the default action later.

Step 6

Optionally, choose the Available Devices where you want to deploy the policy, then click Add to Policy (or drag and drop) to add the selected devices. To narrow the devices that appear, type a search string in the Search field.

If you want to deploy this policy immediately, you must perform this step.

Step 7

Click Save.


What to do next


Note


When you deploy an access control policy, its rules are not applied on the existing tunnel sessions. Hence, traffic on an existing connection is not bound by the new policy that is deployed. In addition, the policy hit count is incremented only for the first packet of a connection that matches a policy. Thus, the traffic of an existing connection that could match a policy is omitted from the hit count. To have the policy rules effectively applied, clear the existing tunnel sessions, and then deploy the policy.


Editing an Access Control Policy

Only one person should edit a policy at a time, using a single browser window. If multiple users save the same policy, the last saved changes are retained. For your convenience, the system displays information on who (if anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30 minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.


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.


Procedure


Step 1

Choose Policies > Access Control .

Step 2

Click Edit (edit icon) next to the access control policy you want to edit.

If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 3

Edit your access control policy.

Tip

 

You can edit multiple rules at one time by shift-clicking or control-clicking multiple rules, then right-clicking and choosing Edit. Bulk editing is available for enabling and disabling rules, selecting rule action, and setting most inspection and logging settings.

Settings:

  • Name and Description—Click either field and enter new information.

  • Default Action—Choose a value from the Default Action drop-down list.

  • Default Action Variable Set—To change the variable set associated with an Intrusion Prevention default action, click Variables (variables icon). In the popup window that appears, select a new variable set and click OK. You can also click Edit (edit icon) to edit the selected variable set in a new window. For more information, see Managing Variables.

  • Default Action Logging—To configure logging for connections handled by the default action, click Logging (logging icon); see Logging Connections with a Policy Default Action.

  • HTTP Responses—To specify what the user sees in a browser when the system blocks a website request, click HTTP Responses; see Choosing HTTP Response Pages.

  • Inheritance: Change Base Policy—To change the base access control policy for this policy, click Inheritance Settings; see Choosing a Base Access Control Policy.

  • Inheritance: Lock Settings in Descendants—To enforce this policy's settings in its descendant policies, click Inheritance Settings; see Locking Settings in Descendant Access Control Policies.

  • Policy Assignment: Targets—To identify the managed devices targeted by this policy, click Policy Assignment; see Setting Target Devices for an Access Control Policy.

  • Policy Assignment: Required in Domains—To enforce this policy in a subdomain, click Policy Assignment; see Requiring an Access Control Policy in a Domain.

  • Rules—To manage access control rules, and to inspect and block malicious traffic using intrusion and file policies, click Rules; see Create and Edit Access Control Rules.

  • Rule Conflicts—To show rule conflict warnings, enable Show rule conflicts. Rule conflicts occur when a rule will never match traffic because an earlier rule always matches the traffic first. Because determining rule conflicts is resource intensive, displaying them may take some time. For more information, see Best Practices for Ordering Rules.

  • Security Intelligence—To immediately block connections based on the latest reputation intelligence using a Block list, click Security Intelligence; see Configure Security Intelligence.

  • Advanced Options—To set preprocessing, SSL inspection, identity, performance, and other advanced options, click Advanced; see Access Control Policy Advanced Settings.

  • Warnings—To view a list of warnings or errors in your access control policy (and its descendant and associated policies), click Show Warnings. Warnings and errors mark configurations that could adversely affect traffic analysis and flow or prevent the policy from deploying. If there are no warnings, show warnings does not appear. To view rule conflict warnings, first enable Show rule conflicts.

Step 4

Click Save.


What to do next

Managing Access Control Policy Inheritance

Before you begin

Understand how inheritance works. See Access Control Policy Inheritance and subtopics.

Procedure


Step 1

Edit the access control policy whose inheritance settings you want to change; see Editing an Access Control Policy.

Step 2

Manage policy inheritance:


What to do next

Choosing a Base Access Control Policy

Smart License

Classic License

Supported Devices

Supported Domains

Access

Any

Any

Any

Any

Admin/Access Admin/Network Admin

You can use one access control policy as the base (parent) for another. By default, a child policy inherits its settings from its base policy, though you can change unlocked settings.

When you change the base policy for the current access control policy, the system updates the current policy with any locked settings from the new base policy.

Procedure


Step 1

In the access control policy editor, click Inheritance Settings.

Step 2

Choose a policy from the Select Base Policy drop-down list.

In a multidomain deployment, an access control policy may be required in the current domain. You can choose only the enforced policy or one of its descendants as the base policy.

Step 3

Click Save.


What to do next

Inheriting Access Control Policy Settings from the Base Policy

A new child policy inherits many settings from its base policy. If these settings are unlocked in the base policy, you can override them.

If you later reinherit the settings from the base policy, the system displays the base policy's settings and dims the controls. However, the system saves the overrides you made, and restores them if you disable inheritance again.

Procedure


Step 1

In the access control policy editor, click Security Intelligence, HTTP Responses, or Advanced.

Step 2

Check the Inherit from base policy check box for each setting you want to inherit.

If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to modify the configuration.

Step 3

Click Save.


What to do next

Locking Settings in Descendant Access Control Policies

Lock a setting in an access control policy to enforce the setting in all descendant policies. Descendant policies can override unlocked settings.

When you lock settings, the system saves overrides already made in descendant polices so that the overrides can be restored if you unlock settings again.

Procedure


Step 1

In the access control policy editor, click Inheritance Settings.

Step 2

In the Child Policy Inheritance Settings area, check the settings you want to lock.

If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to modify the configuration.

Step 3

Click OK to save the inheritance settings.

Step 4

Click Save to save the access control policy.


What to do next

Requiring an Access Control Policy in a Domain

You can require that every device in a domain use the same base access control policy or one of its descendant policies.

Before you begin

  • Configure at least one domain other than the Global domain.

Procedure


Step 1

In the access control policy editor, click Policy Assignments.

Step 2

Click Required on Domains.

Step 3

Build your domain list:

  • Add — Select the domains where you want to enforce the current access control policy, then click Add or drag and drop into the list of selected domains.
  • Delete — Click Delete (delete icon) next to a leaf domain, or right-click an ancestor domain and choose Delete Selected.
  • Search — Type a search string in the search field. Click Clear (clear icon) to clear the search.

Step 4

Click OK to save the domain enforcement settings.

Step 5

Click Save to save the access control policy.


What to do next

Setting Target Devices for an Access Control Policy

An access control policy specifies the devices that use it. Each device can be targeted by only one access control policy. In multidomain deployments, you can require that all the devices in a domain use the same base policy.

Procedure


Step 1

In the access control policy editor, click Policy Assignments.

Step 2

On Targeted Devices, build your target list:

  • Add — Select one or more Available Devices, then click Add to Policy or drag and drop into the list of Selected Devices.
  • Delete — Click Delete (delete icon) next to a single device, or select multiple devices, right-click, then choose Delete Selected.
  • Search — Type a search string in the search field. Click Clear (clear icon) to clear the search.

Under Impacted Devices, the system lists the devices whose assigned access control policies are children of the current policy. Any change to the current policy affects these devices.

Step 3

Optionally, click Required on Domains to require that all the devices in the subdomains you choose use the same base policy. See Requiring an Access Control Policy in a Domain.

Step 4

Click OK to save your targeted device settings.

Step 5

Click Save to save the access control policy.


What to do next

Logging Settings for Access Control Policies

Settings for access control policy logging allow you to configure default syslog destinations and syslog alert for the current access control policy. The settings are applicable to the access control policy and all the included SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with custom settings in included rules and policies.

Logging for connections handled by the default action is initially disabled.

Default Syslog Settings

Send using specific syslog alert: If you select this option, the events are sent based on the selected syslog alert as configured using the instruction in Creating a Syslog Alert Response. You can select the syslog alert from the list or add one by specifying the name, logging host, port, facility, and severity. For more information, see Facilities and Severities for Intrusion Syslog Alerts. This option is applicable to all devices.

FTD 6.3 and later: Use the syslog settings configured in the FTD Platform Settings policy deployed on the device: If you select this option and select the severity, connection or intrusion events are sent with the selected severity to syslog collectors configured in Platform Settings. Using this option, you can unify the syslog configuration by configuring it in Platform Settings and reusing the settings in access control policy. Severity selected in this section is applied to all connection and intrusion events. The default severity is ALERT.

This option is applicable only to Firepower Threat Defense devices 6.3 and later.


Note


Behavior of the options is altered when both the options are selected. The dynamic Summary section shows the results of your selections.


File and Malware Settings are effective only after you have selected an option at the top of the page for sending syslog messages generally.

Access Control Policy Advanced Settings

Advanced access control policy settings typically require little or no modification. The default settings are appropriate for most deployments. Note that many of the advanced preprocessing and performance options in access control policies may be modified by rule updates as described in Update Intrusion Rules.

If View (View button) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.


Caution


See Configurations that Restart the Snort Process When Deployed or Activated for a list of advanced setting modifications that restart the Snort process, 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.


General Settings

Option

Description

Maximum URL characters to store in connection events

To customize the number of characters you store for each URL requested by your users, see Limiting Logging of Long URLs.

To customize the length of time before you re-block a website after a user bypasses an initial block, see Setting the User Bypass Timeout for a Blocked Website.

Allow an Interactive Block to bypass blocking for (seconds)

See Setting the User Bypass Timeout for a Blocked Website.

Retry URL cache miss lookup

The first time the system encounters a URL that does not have a locally stored category and reputation, it looks up that URL in the cloud and adds the result to the local data store, for faster processing of that URL in future.

This setting determines what the system does when it needs to look up a URL's category and reputation in the cloud.

By default, this setting is enabled: The system momentarily delays the traffic while it checks the cloud for the URL's reputation and category, and uses the cloud verdict to handle the traffic.

If you disable this setting: When the system encounters a URL that is not in its local cache, the traffic is immediately passed and handled according to the rules configured for Uncategorized and reputationless traffic.

In passive deployments, the system does not retry the lookup, as it cannot hold packets.

Enable Threat Intelligence Director

Disable this option to stop publishing TID data to your configured devices. For more information about TID, see Threat Intelligence Director.

Enable reputation enforcement on DNS traffic

This option is enabled by default, for improved URL filtering performance and efficacy. For details and additional instructions, see DNS Filtering: Identify URL Reputation and Category During DNS Lookup and subtopics.

Inspect traffic during policy apply

To inspect traffic when you deploy configuration changes unless specific configurations require restarting the Snort process, ensure that Inspect traffic during policy apply is set to its default value (enabled).

When this option is enabled, resource demands could 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 Scenarios for more information.

Associated Policies

Use advanced settings to associate subpolicies (SSL, identity, prefilter) with access control; see Associating Other Policies with Access Control.

TLS Server Identity Discovery

The latest version of the Transport Layer Security (TLS) protocol 1.3, defined by RFC 8446, is the preferred protocol for many web servers to provide secure communications. Because the TLS 1.3 protocol encrypts the server's certificate for additional security, and the certificate is needed to match application and URL filtering criteria in access control rules, the Firepower System provides a way to extract the server certificate without decrypting the entire packet.

You can enable this feature, referred to as TLS server identity discovery, when you either:

  • Associate an SSL policy with an access control policy

  • Configure advanced settings for an access control policy


Note


Neither TLS server identity discovery nor the decryption of TLS 1.3 traffic is supported on 8000 Series devices.


To enable TLS server identity discovery, click the Advanced tab and select the check box as the following figure shows.

We strongly recommend enabling it for any traffic you want to match on application or URL criteria, especially if you want to perform deep inspection of that traffic. An SSL policy is not required because traffic is not decrypted in the process of extracting the server certificate.


Note


  • Because the certificate is decrypted, TLS server identity discovery can reduce performance depending on the hardware platform.

  • TLS server identity discovery is not supported in inline tap mode or passive mode deployments.


The following figure shows an example of enabling TLS server identity discovery in an access control policy's advanced settings.

Network Analysis and Intrusion Policies

Advanced network analysis and intrusion policy settings allow you to:

  • Specify the intrusion policy and associated variable set that are used to inspect packets that must pass before the system can determine exactly how to inspect that traffic.

  • Change the access control policy’s default network analysis policy, which governs many preprocessing options.

  • Use custom network analysis rules and network analysis policies to tailor preprocessing options to specific security zones, networks, and VLANs.

For more information, see Advanced Access Control Settings for Network Analysis and Intrusion Policies.

Threat Defense Service Policy

You can use the Threat Defense Service Policy to apply services to specific traffic classes. For example, you can use a service policy to create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications. This policy applies to Firepower Threat Defense devices only, and will be ignored for any other device type. The service policy rules are applied after the access control rules. For more information, see Threat Defense Service Policies.

File and Malware Settings

File and Malware Inspection Performance and Storage Tuning provides information on performance options for file control and AMP for Networks.

Intelligent Application Bypass Settings

Intelligent Application Bypass (IAB) is an expert-level configuration that specifies applications to bypass or test for bypass if traffic exceeds a combination of inspection performance and flow thresholds. For more information, see Intelligent Application Bypass.

Transport/Network Layer Preprocessor Settings

Advanced transport and network preprocessor settings apply globally to all networks, zones, and VLANs where you deploy your access control policy. You configure these advanced settings in an access control policy rather than in a network analysis policy. For more information, see Advanced Transport/Network Preprocessor Settings.

Detection Enhancement Settings

Advanced detection enhancement settings allow you to configure adaptive profiles so you can:

  • Use file policies and applications in access control rules.

  • Use service metadata in intrusion rules.

  • In passive deployments, improve reassembly of packet fragments and TCP streams based on your network’s host operating systems.

For more information, see Adaptive Profiles.

Performance Settings and Latency-Based Performance Settings

About Intrusion Prevention Performance Tuning provides information on improving the performance of your system as it analyzes traffic for attempted intrusions.

For information specific to latency-based performance settings, see Packet and Intrusion Rule Latency Threshold Configuration.

Associating Other Policies with Access Control

Use an access control policy's advanced settings to associate one of each of the following subpolicies with the access control policy:

  • SSL policy—Monitors, decrypts, blocks, or allows application layer protocol traffic encrypted with Secure Socket Layer (SSL) or Transport Layer Security (TLS).


    Caution


    Snort 2 only. Adding or removing an SSL 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.


  • Identity policy—Performs user authentication based on the realm and authentication method associated with the traffic.

  • Prefilter policy—Performs early traffic handling using limited network (layer 4) outer-header criteria.

Before you begin

Before associating an SSL policy with an access control policy, review the information about TLS server identity discovery in Access Control Policy Advanced Settings.

Procedure


Step 1

In the access control policy editor, click Advanced Settings.

Step 2

Click Edit (edit icon) in the appropriate Policy Settings area.

If View (View button) appears instead, settings are inherited from an ancestor policy, or you do not have permission to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Step 3

Choose a policy from the drop-down list.

If you choose a user-created policy, you can click edit that appears to edit the policy.

Step 4

Click OK.

Step 5

Click Save to save the access control policy.


What to do next

Viewing Policy Hit Counts

Hit count indicates the number of times a policy rule has triggered for a matching connection. The policy hit count is incremented only for the first packet of a connection that matches a policy. You can use this information to identify the efficacy of your rules. Hit count information is available only for access control and prefilter rules applied to FTD devices.

For supported policies, the hit count information is displayed even for the default action which is set for the policy.


Note


  • If the Firepower Threat Defense device is rebooted, all the hit count information is reset.

  • You will not be able to derive the hit count information from a device when deployment or a task is in progress on the device.


Procedure


Step 1

Navigate to the access control or prefilter policy page.

Step 2

Click the policy for which you want to view the hit count information.

Step 3

On the policy page, click Analyze Hit Counts on the top-right of the page.

Step 4

On the Hit Count page, select the device from the Select a device drop-down list.

Note

 

If it is not the first time that you are generating hit counts for this device, then notice the last fetched hit count information next to the drop-down box. Also, verify the Last Deployed time to confirm recent policy changes.

Step 5

Click Fetch Current Hit Count to get the hit count data.

If it is not your first attempt in accessing the hit count information for the selected device, you see Refresh instead of Fetch Current Hit Count. Click Refresh to get the latest hit count information.

Step 6

(Optional) Customize the table and the listings within the table by using the Filter Rules/Policy box, or the Filter by and In Last drop-down boxes, along with Cog (cog icon).

The Filter by drop-down box provides important filter options like Hit Rules and Never Hit Rules which help in identifying crucial rules. The In Last drop-down box provides options to filter rules based on preset time periods.

Step 7

(Optional) Click on a rule name to edit it, or click View (View button) in the last column to view the rule details.

Clicking on the rule name highlights it in the policy page where you can edit it.

Note

 

If you have accessed the Hit Count page from the Access Control Policy page, you will not be able to view or edit prefilter rules and vice-versa.

Step 8

(Optional) Clear the hit count information for a rule by right-clicking the rule and selecting Clear Hit Count.

For clearing hit count information of multiple rules, you can select rules by using Ctrl and selecting Clear Hit Count after right-clicking on one of the selected rules.

Note

 

Clearing hit count information will irreversibly set the hit count to zero.

Step 9

(Optional) Generate a CSV report of the details on the page by clicking Generate CSV on the bottom-left of the page.

Step 10

Click Close to return to the policy page.


History for Access Control Policies

Feature

Version

Details

DNS filtering

7.0

6.7 (experimental)

If URL filtering is enabled and configured, a new option to enhance category and reputation filtering efficacy is enabled by default for each new access control policy.

For more information, see DNS Filtering: Identify URL Reputation and Category During DNS Lookup and subtopics.

Modified screens: Advanced tab of access control policy has a new option under General Settings: Enable reputation enforcement on DNS traffic.

Supported Platforms: All

TLS server identity discovery

6.7

Enable access control policies to evaluate URL and application conditions when a client connects to a TLS 1.3-enabled server. TLS server identity discovery enables these conditions to be evaluated without decrypting traffic.

Note: Enabling this feature impacts performance, depending on the managed device model.

Modified screens: Advanced tab page of access control policy has new options:

  • Warning is displayed on the Advanced tab; moving the slider to the right enables TLS server identity discovery.

  • New option on the Advanced tab page: TLS Server Identity Discovery.

New Security Intelligence categories

--

The following categories were introduced at about the time of the 6.6 release, but are not specific to 6.6:

  • banking_fraud

  • high_risk

  • ioc

  • link_sharing

  • malicious

  • newly_seen

  • spyware

New/modified pages: Access control policy > Security Intelligence tab.

Supported platforms: FMC