Access Control Policy Overview

Allowing traffic based on the Layer 3 and Layer 4 source and destination
information is an efficient method for defining traffic, but there are many cases
where more information about the traffic is needed to determine what actions
should be taken on the traffic. Also, just determining whether to allow or deny
the traffic might not be the only decision that needs to be made.
Access Control Policy Operation
An Access Control Policy is a set of rules that are processed by the Layer 3-7
inspection engine (Snort) to determine the actions that the threat defense should
take to secure traffic on the network.
But for traffic to be inspected by the Access Control Policy (also referred to as
Access Control Rules), it must first be processed and allowed by LINA. LINA
performs any VPN decryption, Network Address Translation (NAT), and basic
Layer 3-4 inspections on the traffic before forwarding the traffic to Snort for
deeper Layer 3-7 inspections.

Once the traffic is forwarded to the Layer 3-7 Snort inspection, it is then checked
against Security Intelligence (SI) for source/destination IP addresses. If the traffic
is Transport Layer Security (TLS) protected and the SSL Policy is configured and
enabled, it is processed by the SSL Decrypt policy. Once processed by the SSL
policy, it is then checked against SI for Domain Name System (DNS) and Unified
Resource Location (URL) violations. Any of these processes could determine that
the traffic is not allowed and return a verdict to LINA to drop the traffic.
If the traffic is allowed by the SI and SSL policies, it can then be checked against
an Identity policy. The Identity policy will match internal users and user groups to
the traffic. This information can be used by the ACP rules to make user-based
decisions on how traffic should be handled.
Once the traffic reaches the ACP, it is then compared to a list of rules that define
what traffic should be matched, and how that traffic should be processed. The
ACP rules not only allow for traffic to be denied or permitted based on the rule it
matches, but also determines if allowed traffic will be subject to deeper
inspections, such as File inspections or IPS inspections (Snort rules).
For traffic that is allowed after it is processed by the ACP, it is checked to see if it
requires any Quality of Service (QoS) rules to be applied. Network Discovery can
also be used to build host and optionally user data based on passive discovery. If
the ACP determines that File inspection or IPS needs to be done, the traffic will
be subjected to those processes.
After the traffic is processed by Snort, a verdict is returned to LINA. If the traffic is
not allowed, LINA drops the traffic. If the traffic is allowed, LINA updates the flow
information as to how the traffic should be processed and any NAT/QoS/VPN that
is needed will be applied to the traffic before sending it to the egress interface.
Access Control Policy Management
When the management center is initially deployed, there are no default Access
Control Policies as part of the configuration, and at least one policy will need to
be defined before being applied to the managed devices.
To access the Access Control Policies in the Cisco Secure Firewall Management
Center GUI, navigate to Policies > Access Control.

In the list of defined Access Control Policies, the example shows an Access
Control Policy named FTD-Initial-Policy that was created by an administrator
and assigned to two devices. Notice that all devices are up-to-date, meaning that
what is shown in the policy has been deployed to the devices and is currently
being used to protect network traffic. You can also see the last modification date
was October 28, 2022, by the user “admin.”
Note
The policy that is shown could have been added before the threat defense
devices were registered with the management center, or as part of the
registration process.
At the far right of each policy in the list are the following options:
 Copy the ACP: allows you to create a new ACP with the same base
configuration as the selected policy that you can then modify and apply to
other managed devices.
 Generate a report: creates a PDF file that allows you to view the
contents of the policy offline, outside of management center.
 Edit: opens the ACP allowing you to make any necessary changes.
 Delete: removes the policy from the management center database.
Creating a New Access Control Policy
If you need to create a new policy, click the blue New Policy button in the upper
right-hand corner of the window.

The new Policy will require a name and can optionally have a description.
You have the option to choose one of the existing ACPs as a base policy for the
new policy. The new policy will inherit any of the rules that are included in the
base policy and is used as a starting point for the new policy. This allows you to
define any common rules that are needed for all of your company's managed
devices in the Base policy, use the base policy as a starting point for all policies
that are used by your managed devices, and then add specific organizational
rules to each of the specific policies that are based on the Base policy.
If you do not use a Base policy, you must define the default action for the new
rule. Without setting a Base policy for the new rule there will be no rules defined
other than the default action. You should decide if the new policy should be a
restrictive policy that blocks all traffic that does not have a specific Allow rule
match, a more permissive policy that looks for intrusion events, or a more
permissive policy that is designed for network discovery.
You should also select any managed threat defense devices that are to be
targeted as deployment devices for the new policy. To select targeted devices
select the device from the Available Devices list on the left and click the Add to
Policy button to add the device to the Selected Devices list on the right.
When you are done click Save to save the policy. The new policy will open for
you to manage.
ACP Basics – Rules
To edit an existing policy, navigate to Policies > Access Control, and click the
pencil icon at the far right of the policy, opening the Policy Editor window.
The first tab that you see when you access the ACP is the Rules tab. This is where
you define individual traffic types based on source or destination Security Zones,
source or destination IP address, VLANs, users or user groups, applications,
source or destination ports, URLs, and/or source or destination dynamic
attributes. For each rule that is defined, you also define an action for the
corresponding traffic.

Unless you create the new policy with the use of a Base policy there are no
specific rules defined in an ACP, and only the default action is applied to traffic.
In the example shown, the default action
is Intrusion Prevention: Balanced Security and Connectivity. This option
allows traffic, but also inspects traffic to log security events.
Other options for an ACP default action include:
 Traffic control only:
 Access Control: Block all Traffic
1. Blocks traffic that did not match any ACP rule other than a
‘Monitor’ rule. If applied, you must have a permit traffic rule
created to allow traffic through the firewall.
 Access Control: Trust All Traffic
1. Allows traffic that did not match any ACP rule other than a
‘Monitor’ rule. If applied, you must have a block or inspect
rule created to inspect or stop malicious or undesired traffic.
 Access Control: Network Discovery Only
1. Allows traffic that did not match any ACP rule other than a
‘Monitor’ rule. If applied, the default rule will only direct the
traffic to the network discovery process but will perform no
additional security inspections.
 System Provided (Intrusion) Policies:
  Intrusion Prevention: Maximum Detection
1. Allows traffic that did not match any ACP rule other than a
‘Monitor’ rule and directs the traffic to the Maximum
Detection Intrusion Policy (Not recommended).
 Intrusion Prevention: Security Over Connectivity
1. If applied, uses a policy that is geared toward protecting the
network more than allowing traffic.
 Intrusion Prevention: Balanced Security and Connectivity
1. If applied, uses a policy that is balanced between protecting
the network and allowing connectivity.
 Intrusion Prevention: Connectivity over Security
1. If applied, uses a policy that is geared toward allowing
applications to function, while still applying network
protection with intrusion prevention.
 Any user-created policies (none by default)
 Custom IPS policies

In an ACP that has been modified to control traffic for your network, the rules are
processed in a top-down fashion. Any traffic that does not match a rule in the list
that has a final action of allow, trust, or block (with any options that can also be
associated) is subject to the default action at the bottom of the list.
Failure to set up your access control rules properly can have unexpected results,
including traffic being allowed that should be blocked. In general, application
control rules should be lower in your access control list because it takes longer
for those rules to match than rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP
addresses) should be ordered before rules that use general conditions (such as
applications). If you're familiar with the Open Systems Interconnect (OSI) model,
use similar numbering in concept. Rules with conditions for layers 1, 2, and 3
(physical, data link, and network) should be ordered first in your access control
rules. Conditions for layers 5, 6, and 7 (session, presentation, and application)
should be ordered later in your access control rules.
To organize the rules of an ACP, you can create categories that are named to
indicate what type of rules are included in a given section.
ACP Basics – Security Intelligence
The Security Intelligence tab allows you to define block lists that can be applied
to all traffic that is subject to the ACP before the ACP rules are processed.
Security Intelligence is updated by Cisco to include DNS information that can
identify websites and IP addresses/URL names that are known to be malicious or
contain malware. Enforcement can be accomplished with a Threat Defense DNS
policy or by implementing a Cisco Umbrella Based policy.
DNS policies can also be created that can enforce company policies that deny
access to certain types of websites based on the type of website that the DNS
query is requesting. Since this security is based on DNS, it is not limited to
applications and URLs that are seen in HTTP requests and can protect any
application that is using DNS to resolve a host name to an IP address.
In addition to the DNS or Umbrella DNS policies, you can create manual Block
and Do-Not-Block lists that allow you to control access to specific URLs or IP
addresses that the DNS or Umbrella DNS policies have not identified.
ACP Basics – Prefilter Policy
The ACP rules that process traffic up through Layer 7 can be processor intensive.
To reduce the need for Layer 7 processing, you can define a Prefilter policy that
will make some decisions based on only Layer 3 and Layer 4 information.

By only analyzing Layer 3 and Layer 4 information, quick decisions are made to
reduce the workload of the ACP rules. For example, certain traffic identified by IP
address does not need to be processed by the deeper inspections of the ACP
rules. Trusted traffic, backup traffic, and any other traffic you do not wish to run
through deeper packet inspections can be fastpathed to avoid Snort inspection
altogether. Recall that traffic known to generate elephant flows, false positives,
and performance issues are oftentimes best prefiltered or trusted.
ACP Basics – SSL Decrypt Policy
Many bad actors will hide malicious traffic within encrypted sessions, using SSL
or TLS, to hide attacks caused by malware. For much of this encrypted traffic,
you can deploy an SSL Decrypt policy that will allow the threat defense to
analyze the encrypted traffic and find malicious data.

However, not all traffic is subject to decryption. Financial, healthcare, and other
websites should not typically be decrypted due to the sensitivity of the data
involved. Therefore, many decryption policies will decrypt all traffic on internal
traffic that is destined for internal servers, and only decrypt traffic that is
destined for the internet that is not in potential violation of government
regulatory laws and company policies.
To protect your services from attacks that are hidden within SSL/TLS encrypted
sessions, you must first define an SSL Decrypt policy, helping to ensure that you
are decrypting only services that are allowed for your environment. Once
defined, you then assign the SSL Decrypt policy to your ACP.
ACP Basics – Identity Policy
ACP rules can also be matched to users or user groups, but to do so, the threat
defense must know the identity of the user that is involved in the connection.

An Identity policy allows for threat defense to match a username, and the
associated user group, to the client IP address of the connection. The associated
identity can be learned from an external database, such as Cisco Identity Service
Engine (ISE), or the policy can use active authentication, in which a user logs into
a captive portal to provide their identity.
Once the threat defense knows the identity of the user, it can then use this
information as part of the rules that define how traffic will be handled. For
example, a user that is part of the network administrator group might be allowed
to use Secure Shell (SSH) to access the device management network, while a
Guest user is prohibited from accessing the device management network at all.
By using a user group for identification purposes, you abstract the IP address
from the decision and can have both admins and guests on the same network
while applying their specific security policies accordingly.
Assigning ACPs to Targeted Devices
Access Control Policies must be assigned to the managed devices.

Each managed device can have one ACP assigned, and this can be controlled as
part of the ACP or as part of the device configuration. The example shows that by
clicking on the Policy Assignments hyperlink within a policy, a popup window
opens that allows you to select targeted devices to which the ACP is applied.
If the device is already a target for a different policy and you set it as a target for
a new policy, you will get a warning message informing you that you are about to
change the policy assignment. You are then able to either continue with the
change or cancel the change.

You can also apply an ACP to an individual device from the device’s summary
page at Devices > Device Management. Then, select your device and choose
the Device tab. Once at the Device Summary page, in the Applied Policies
section, click the pencil icon to choose the policy you want to apply to the
device. In addition to the Access Control Policy, you can also assign the device a
NAT Policy, Platform Settings Policy, QoS Policy, and FlexConfig Policy.
Click Save when you are finished and remember that the changes will not go
into effect on the device until the configuration is deployed.
Deploy ACP Changes
As with other configurations that you make on management center for managed
devices, the changes do not take effect until they are deployed to the managed
devices.
When you make any changes to the ACP in the management center you must
first save the changes, then you need to deploy the changes to the managed
device. The managed device will not know about any changes until the
deployment process has completed.
Management center indicates when an ACP has changes that have not been
deployed. The example shows that the FTD-Initial-Policy has two devices that are
out of date and require that the configuration changes be deployed.
Access Control Policy Rules and Rule Actions
The main aspect of Cisco Secure Firewall Threat Defense system’s Access Control
Policy (ACP) is its rules. These rules determine which traffic is subject to access
control and how that traffic is processed.
This training examines how to create ACP rules, configure the actions to be taken
on traffic that matches these rules, and several tools available to manage the
process.

Play Video
Open Transcript
Access Control Policy Implementation
Cisco Secure Firewall Management Center (formerly FMC) can have multiple ACPs
that are applied to different managed devices based on the type of security that
is needed for each device. For example, one ACP might be defined for branch
locations that focuses on protecting traffic from employees and guests that are
accessing the internet, while a different ACP might be defined for protecting the
data center.

To access the Access Control Policies in the management center GUI, navigate
to Policies > Access Control. As shown in the example, the Access Control
page displays four ACPs that have been created.
The first ACP, named Parent Policy defines common settings, and is used for a
base policy that the other ACPs will reference. This policy is not directly targeting
any managed devices and is only being used to define common settings that
should be matched across the entire deployment.
The second policy, named Branch Access Control, is targeted to one device.
This ACP is configured with settings that are designed to control traffic at the
branch office. This policy contains rules that are designed to enforce company
policies for traffic that is accessing the internet from branch users. Since we
typically do not deploy server farms at a branch location, there will not be many
rules defined for inbound traffic from the internet. The rules of the branch ACP
might include DNS-based security intelligence and URL or application-based
policies.
The third policy, named NGFW1, is a policy that is applied at the data center.
Since this policy is protecting the server farm, it has rules that are designed to
control traffic from both internal users, and from the internet. The rules that are
defined in this ACP are designed to protect the servers from bad traffic, and
might include SSL decryption, and port-based rules.
The fourth ACP in the list, named Traffic Generator, may be used for testing.
Although there are four policies defined, it is important to remember that each
managed device can only have a single ACP assigned.
Access Control Rules
To edit an existing policy, from the Access Control page, click the pencil icon at
the far right of a specific policy, opening the Policy Editor window.

The initial tab that is shown is the Rules tab where the basic Layer 2–Layer 7 ACP
rules are defined. By default, the only rule that exists is the Default Action at the
bottom of the list. The list is processed in a top-down fashion. If the traffic that is
being inspected does not match a specific rule with a final action in the list, it will
be subject to the Default Action.
While there are no specific rules defined in the ACP by default, there are two rule
categories provided. As you create rules, they can be added to either of these
categories. Optionally, you can create additional categories that might help you
organize the list in an efficient manner.
Regardless of the number of categories or rules that are defined, the rules will be
processed from top to bottom. If you define rules that conflict, you should help to
ensure that the more-specific rule is higher in the list, and the less-specific rule is
further down the list. If the less-specific rule is higher in the list, and it has a final
action, the traffic will never be processed by the other rule.
Adding an Access Control Rule
To add a rule to a policy, within the Policy Editor, click the blue + Add
Rule button in the upper-right corner of the list of rules and the Add Rule window
will open.

The new rule parameters to configure include the following:

 Name: A name is required to save the rule into the rules table.
 Insert: You can choose the category within the table in which the rule will
be inserted.
 Action: Define the action to be taken on traffic that matches the
corresponding rule.
  Time Range: Optionally, you can also set a time range for which the rule
will be active.
Below the basic settings at the top of the Add Rule window, there are several
tabs that allow you to define the traffic that the rule is to match, as well as
specific inspections and logging that is to be performed. There is also a tab in
which you can leave comments, informing other administrators as to the purpose
of the rule that you are creating, or specifying the changes that were made to
the rule.
Note
A rule will be enabled by default, but for troubleshooting purposes, rules can be
disabled. For example, you can narrow down an issue that you are investigating
if a disabled rule changes how traffic is processed by the ACP.
Access Control Rule Actions

Play Video
Open Transcript
Each Access Control rule must have an associated action.

Every access control rule has an action that determines how the system handles
and logs matching traffic. You can monitor, trust, block, or allow (with or without
further inspection).
The access control policy’s default action handles traffic that does not meet the
conditions of any access control rule with an action other than Monitor.

The actions that allow traffic to continue and how the actions are applied to the
traffic are as follows:
1. Allow – The Allow action allows matching traffic to pass, though it is still
subject to Network Discovery and rate limiting.
Optionally, you can use deep inspection to further inspect and block unencrypted
or decrypted traffic before it reaches its destination. Note it is recommended to
have an Intrusion Policy applied to most if not all Allow traffic. Allow is typically
used for most network traffic as it directs the traffic to be inspected by the IPS
component of the firewall.
1. You can use an intrusion policy to analyze network traffic according
to intrusion detection and prevention configurations and drop
offending packets depending on the configuration.
2. You can perform file control using a file policy. File control allows you
to detect and block your users from uploading (sending) or
 downloading (receiving) files of specific types over specific
application protocols.
3. You can perform network-based advanced malware protection
(AMP), also using a file policy. malware defense can inspect files for
malware, and block detected malware depending on the
configuration.
2. Trust – The Trust action indicates this is traffic you are considering trusted
in your network, and no security inspections are required. A verdict to
allow the traffic to proceed will be handed to LINA for the matching traffic.
No network discovery or additional security inspections will be performed
on the traffic, although rate limiting will still be performed on the traffic.
3. Monitor – The Monitor action is not designed to permit or deny traffic.
Rather, its primary purpose is to force connection logging, regardless of
how matching traffic is eventually handled.
If a connection matches a Monitor rule, the next non-Monitor rule that the
connection matches should determine traffic handling and any further
inspection. If there are no additional matching rules, the system should use the
default action.

The actions that that do not allow traffic to continue and how the actions are
applied to the traffic are as follows:
1. Block – The Block action informs the LINA engine that the traffic is not
allowed. The LINA engine stops processing packets for the indicated
connection, and no further inspections are performed.
2. Block with Reset - The Block with Reset action informs the LINA engine
that the traffic is not allowed. Threat defense sends a TCP reset to both
the client and the server, clearing the connection on the firewall and the
participating endpoints. The LINA engine stops processing packets for the
indicated connection, and no further inspections will be performed.
3. Interactive Block – Interactive Block relies on the user initiating the
connection to determine the action. If a user bypasses the block, the rule
mimics an allow rule. Therefore, you can associate interactive block rules
with file and intrusion policies, and matching traffic is also eligible for
network discovery. If a user does not (or cannot) bypass the block, the rule
mimics a block rule. Matching traffic is denied without further inspection.
4. Interactive Block with Reset - Interactive Block with Reset is the same
as Interactive Block except for the sending of a reset. Use the Interactive
Block with reset action to (non-interactively) block-with-reset all non-web
traffic, while still enabling interactive blocking for web requests.
Access Control Rule - Zones
Defining an ACP rule based on source and destination traffic is a standard
configuration method. But, with the number of IPv4 subnets that might be
subject to access control, or if IPv6 is being used, these configurations can be
hard to manage.
Luckily, threat defense ties the device interfaces with security zones, which
allows pure directional configurations to be defined in a much easier manner.

In the Zones tab of the Add Rule window, there is a list of available security
zones. As shown in the example, zones named zone_dmz, zone_inside,
and zone_outside have been created. The administrator has
added zone_inside to the Source Zones column, and
both zone_dmz and zone_outside to the Destination Zones column.
The result of this configuration is very basic, but also very effective. Any traffic
that is switched from an interface that is part of zone_inside to an interface in
either zone_dmz or zone_outside matches this rule.
When building an ACP rule, it is important to remember that all the criteria of a
rule must match for a rule action to take place. For example, if you are
combining zones with networks in a rule, you must help ensure that any source
networks are located off interfaces that are part of the Source Zones, and
destination networks are located off interfaces that are part of the Destination
Zones. If there are inconsistencies in the configuration, traffic may not match a
rule and result in unexpected results.
Access Control Rule - Networks
While configuring rules with zones might be an easy way to define direction,
there may be situations in which you may still need to define rules based on
network addresses as well. Some rules may apply to individual subnets that are
reachable in the same zones that contain subnets that should not be matched.
An example is when an inside zone matches all 10.0.0.0/8 networks, but the rule
needs to be defined only for the 10.10.10.0/24 subnet.

Using a combination of security zones and network address can also provide a
type of anti-spoofing protection from the outside zone. For example, traffic
entering the firewall from zone_outside with a private address may indicate a
spoofing attack. While this type of configuration does provide a lot of flexibility in
your configuration, it also adds a deal of complexity. It can be used when
needed, but the idea of “a simpler configuration is harder to break” also has
merit.
For any network objects that are part of the management center database,
select them from the Available Networks column on the left and add them to
either the source or destination networks column. To add an IP address or subnet
to a column, type the address in the Enter an IP address box below the
column, then click Add. For host addresses just enter the IP address with no
mask. For a subnet, use the /# format of defining the mask.
Access Control Rule – VLAN Tags
For devices that support VLANs, you can match traffic for individual VLAN tags.

As with zones, you must help ensure that if you are matching by network address
in addition to VLAN tags, that the traffic matches on all the configured
parameters or the rule will not be used.
Access Control Rule – Applications
There are many applications on the internet that are not business appropriate,
and/or contain malicious content. A common Access Control rule is one that
matches applications that are deemed to be unfavorable and block them from
access on your user networks.

Threat defense can identify over 3000 applications, in several categories, as part
of an ACP rule. In the example, several applications from the Very High-Risk
category have been added to a rule. You can select individual applications, or
add an entire category, to the Selected Applications and Filters list on the right.
A rule based on application is typically used with a block, or interactive block,
action. These rules help enforce compliance with company standards. And when
used in conjunction with DNS-based Security Intelligence, these rules can help
ensure that no untoward activity is occurring on the network.
Access Control Rule – IP Protocols and Ports
ACP rule criteria also includes any IP protocol and, for IP protocols that support
them, any relevant port.

The traditional Layer 3-4 access control list uses TCP and UDP ports to define
specific traffic. However, applying specific ports to a rule for a specific
application helps ensure that you are looking for the application on the correct
port. For applications like FTP that are sometimes configured on nonstandard
ports, you can define the nonstandard port here, and help ensure that the FTP
application will function for both the control and data ports.
You can select standard ports by the application name from the Available Ports
column on the left and add them to either the Selected Source Ports or Selected
Destination Ports column. For ports that are not associated with a specific
application, choose the protocol, define the port below the source or destination
table, and then click Add.
Access Control Rule – URLs
It is important to help ensure that company policy is upheld for internet usage.
Filtering URLs based on categories is an easy but effective way to confirm that
employees and guests on your network are not accessing unauthorized content.
URLs, managed by Cisco Talos, can be selected based on a combination of
category and reputation. There are over 100 categories for URLs, and 5 levels of
reputation. You can also choose any reputation within a category to block the
entire category. Note this feature requires the URL-Filtering license to be applied
to the firewall using this feature.
Optionally, you can manually add URLs to the selected URLs list with no
additional license requirements.
Applying Inspection Policies
Intrusion and File policies can also be applied to your ACP rules. Inspection
policies are defined in the Inspection tab of the Add Rule window. From this page,
there are dropdown menus that allow you select which inspection policies you
wish to apply to traffic matching a rule.

Play Video
Open Transcript

Threat defense includes four system-provided Intrusion policies that can be

applied to a rule, or you can create a custom, user-defined policy that can be
applied.
Recall the four system-provided policies:
 Connectivity Over Security: Very few rules are enabled. Not typically
used in a production environment except in areas of the network requiring
only the minimum IPS inspection.
 Security Over Connectivity: Resource-intensive and high security policy
with a large number of rules enabled. Used in networks where the highest
level of security is required.
 Balanced Security and Connectivity: The recommended policy for
most network, providing a balanced approach to the number of rules
enabled.
 Maximum Detection: Not typically used in production networks. Enables
the majority of rules in the system and likely to be significantly disruptive
to both the network and the firewall.

Recall that Variable Sets will be used to determine the Snort rules that will be run
in the associated Intrusion Policy. It is critical to both configure the default
Variable Set in the Objects as well as specify the correct Variable Set in the
Inspection tab.
If a File policy that you wish to apply exists, select it from the dropdown menu.
A File policy must be created before it can be applied to the Access Control rule.
There is no default File policy, and to create a policy, navigate
to Policies > Access Control > Malware & File.
Once you have completed all of the configurations for the ACP rule, including any
Zones, Networks, VLAN Tags, etc., click the Add button to add the rule to the
Access Control Policy.
Quick Reference Icons
Once a rule is created and added to the Access Control Policy, you are able to
see much of the rule’s match criteria in the ACP table. To the right of each rule,
there are quick reference icons to help you determine if advanced parameters,
such as intrusion or file policies, have been defined for the rule. If an icon is
grayed out, then the corresponding parameter has not been configured for the
rule.

The quick reference icons, in order from left to right, are as follows:
1. Time Range – If darkened, a time range has been defined for the rule.
2. Intrusion Policy – If darkened, a specific intrusion policy has been
defined for the rule.
3. File Policy – If darkened, a specific file policy has been defined for the
rule.
4. Safe Search – If darkened, an application has been configured for the rule
that matches the safe search criteria.
5. YouTube EDU – If darkened, an application has been configured for the
rule that matches YouTube education criteria.
6. Logging – If darkened, logging has been enabled for the rule.
7. Comments – Displays the number of administrator comments that have
been added to the rule.
Useful Tools
The Rules tab also provides some tools that are useful for rule management.

The Filter by Device link allows you to display only rules that apply to the
device that is defined in the filter. For example, if the device that is chosen for
the filter only has a subset of the available security zones available, rules that
are defined for security zones that are not applicable will not be displayed.
To perform a more detailed search of the rules list, clicking the Search
Rules box opens a search filter window that allows you to choose the criteria for
any rule you would like to display.
You can easily find any conflicting rules of an ACP by clicking the checkbox
labeled Show Rule Conflicts. This will highlight any rules that have the
potential to conflict with each other and cause unexpected results.
If you need to add a rule category to the policy, click the +Add
Category button, provide a name for the new category and a position to insert
the category into the table.
Complex Search Filter
When you click on the Search Rules box of the Policy Editor, a window opens
that allows you to create a complex filter that will only display rules that contain
the criteria that you specify.

This filter can search the ACP rules for configurations in any of the criteria
columns and can combine the parameters. You can also use the checkboxes at
the top of the filter to find conflicting rules, rules that have intrusion policies
defined, and rules that have time-ranges defined.
Once the filter has been applied, the list will filter out any rules that do not meet
the filter criteria, and the filter criteria will be highlighted in the results for easy
inspection.
To clear a filter, simply click on the Search Rules box to open the complex filter
and click on the Clear button at the bottom of the window.
Access Control Policy Deployment
Saving the Access Control Policy (ACP) configuration in Cisco Secure Firewall
Management Center (formerly FMC) stores the changes in the management
center database but does not automatically push the changes to the managed
Cisco Secure Firewall Threat Defense (formerly FTD) devices. Any changes that
are saved in the management center database must be deployed to the targeted
managed devices.
This training demonstrates how to verify if changes need to be saved, as well as
if saved changes need to be deployed to the managed devices. The training
describes how to verify deployment from both the management center
administrative interface and from the managed device Command Line Interface
(CLI).
Configuration Changes in Management Center
As you make configuration changes to the Access Control Policy in the
management center, they do not take effect immediately. Saving the changes
updates the management center database to include the changes that you have
made, but they will need to be pushed to the managed device with the next
configuration deployment.
Not pushing configuration changes to the managed devices with the save
process in the management center allows you to make several changes to the
configuration without possibly interrupting network services during production
hours. Changes can be deployed at a time when adverse issues have a minimal
effect.
Also, there are several policies that are configured as separate components of
the managed device such as the platform settings, the health policy, the ACP and
others, that are all saved individually within the management center. Changes to
any of these settings need to be deployed, but the process can reduce workload
and downtime to deploy all of the changes as a single deployment operation,
instead of individually with every policy change.
The configuration deployment can be staged. Building the configurations can be
performed in advance of when they need to go into effect. Then at a scheduled
time, optimally during a change window, an administrator can deploy the
changes in-bulk. Staging changes in advance and deploying them at one time
requires a much shorter period to put the changes into effect.
Save Policy Changes
After you have made changes to the Access Control Policy configuration you will
see a message at the top of the Policy Editor page, You have unsaved
changes, informing you that changes need to be saved to the management
center database before you leave the policy configuration page.

To save the changes to the management center database, click the Save button
in the upper-right corner of the page. If you try to navigate away from the Policy
Editor page without saving your changes, you will receive a popup message,
“You have unsaved changes. Are you sure you want to leave without saving?”
Once you save your changes, the message informing you that you have unsaved
changes will no longer be shown. The changes are saved to the management
center database, but they will still need to be deployed to the managed devices.
Deployment Needed
If you have saved changes that have not been pushed to the managed devices,
you will be able to see that a deployment is ready by clicking on the Deploy tab
on the management center taskbar.

The example shows that the Managed High Availability pair FTD-HA has changes
that are ready for deployment. If you are ready to deploy the changes to all
devices that are listed, you can click the blue Deploy All button in the Deploy
tab popup window. If you leave the tab popup open, you will be able to watch the
progress of the deployment process.
If you want to deploy configurations to managed devices individually or want to
see what configuration changes are included as part of the deployment, click
the Advanced Deploy hyperlink.
Advanced Deploy
When you click the Advanced Deploy link in the Deploy tab popup, you are taken
to the management center Deployment page. This page allows you to view what
configuration changes are part of the deployment for each managed device and
select the devices to which you want to deploy changes.

A table displays each managed device that has pending changes that need to be
deployed, along with the last time that a deployment was made to the device.
Click the “>” to the left of a device to see the details about the changes that are
to be deployed. The example shows that the user admin made changes to the
Access Control Policy FTD-Initial-Policy, and to the Intrusion Policy Security
Over Connectivity.

You can also view a change log of the deployment by clicking the preview button.
Only changes to the existing configuration on the device will be part of the
deployment. This preview allows you to see detailed information about what
configuration changes have been made, and which administrator made the
changes.

The number of changes that were made affects the time it takes to deploy, and
therefore, the time it takes for the changes to be implemented. With some
changes, the security policy might experience a small lag while the configuration
is being converted. To get an estimate of the amount of time it will take for a
deployment process to complete, click the Estimate hyperlink to the left of the
blue Deploy button. After a couple of seconds, the hyperlink will be replaced
with an estimate of the time required to complete the deployment for the
devices that have been selected.
Initiate the Deployment
To initiate the deployment, click the blue Deploy button in the upper-right corner
of the Deployment page.

A Deploy Confirmation popup window opens to inform you of how many devices
are selected for the deployment process. From the popup window, you can also
leave notes specific to the deployment. These notes can be useful when
reviewing the deployment history. Notes may be used to inform other
administrators what issue a deployed configuration is attempting to address.
When you are ready to begin the deployment process, click the
blue Deploy button in the Deploy Confirmation popup window.

In the Advanced Deploy window, you can click the icons to show the individual
components that are ready for deployment and the users that saved the
changes. Click the “>” to expand the device you are looking to deploy and
uncheck the items that you do not wish to deploy. The example shows that the
deployment for the managed device named FTD-1 has been expanded, and that
the NAT Group configuration has been deselected.
Track the Deployment Process
After you initiate the deployment, you can track progress from the Deployment
page or, if initiated from it, the Deploy tab popup.

The example shows that the deployment is In Progress and 8 percent complete
(zoom shows 75 percent). As the deployment reaches different stages of the
process, the stages will replace the small text under the progress state.

When the deployment process is complete, you will see the status
as Completed.
Verify Deployment from Management Center
You can verify that configurations have been deployed from the management
center’s Access Control page. If deployment has occurred, the Access Control
Policy status column states that the target devices’ configurations are up to date.

If the devices are up-to-date, the status is shown in green, and if the devices are
Out-of-Date, the status is shown in red. The status is not a hyperlink; it is only
shown in red or green for easy identification of the deployment status of the ACP.
Verify Deployment from a Managed Device
You can also verify that the configuration has been pushed to the managed
device from the managed device’s Command Line Interface (CLI).

Verifying the configuration from the CLI is less intuitive than using the
management center GUI, but it can be useful in helping to ensure that the
configuration that is being used by the managed device is what was deployed
from the management center.
To view the Access Control Policy from the threat defense device’s CLI, log in to
the CLI and enter the show access-control-config command. This command
will display all of the parameters of the ACP, with each part of the ACP listed
under an easy-to-identify heading.
The configuration is controlled by the management center and can only be
viewed from the CLI. No configuration changes can be made at the CLI.
View Deployment History
To view a history of deployments, click the Deploy tab on the management
center taskbar. From the bottom right-hand corner of the Deploy tab popup, click
the Deployment History icon.

The deployment history provides information about past deployments such as

the user who performed the deployment, when the deployment occurred, and
notes that were provided for the deployment. If you were to need to perform a
rollback to a previous deployment version, the notes that were provided can
make it much easier to determine which deployment could have started a
problem that you are encountering.
If needed, you can expand a deployment job in the table to gain access to the
deployment transcript and preview. These items provide details as to what
configuration changes were deployed in a specific job.
Connection Event Reports and Email Notifications
To view information of a particular deployment job, an administrator needs to
look at multiple data points in the management center GUI.

Within the Advanced Deploy window you can click preview to view the
configuration changes that will be pushed as part of the deployment process.
Within the Deployment History window you can click the transcript within each
job to see more details about the policies that are part of the configuration and
what will be on the CLI. Any job notes and other metadata that was added will
also be visible in the deployment history page.
There is a lot of very useful information, but it is spread across multiple windows
within the management center GUI and the Advanced Deploy section and does
not make it easy for an administrator to view it all at the same time.

Beginning with version 7.2 of the management center the deployment history
has added the Deploy Report and Email Notification feature. The Deploy Report
Generator merges data from the Preview, Transcript, and Deployment
information windows into a single PDF file, which can be downloaded and viewed
away from the management center admin GUI. To make sharing the report
easier, the report generation tool can send the report via email.
The report can be viewed from the management center admin GUI
from Notifications > Tasks by clicking on the Click to view job
report hyperlink. The link will open the report in a new browser window or tab
and can then be saved to your local desktop. The report includes information
from all of the relevant windows in a single text-based file, that allows you to
comprehensively review all of the details of the deployment process.
Access Control Policy Best Practices
One of the challenges when managing a system that offers a multitude of tools
and deployment options is how to use these tools and options in a manner that
will best suit your needs. The challenge is no different when managing Cisco
Secure Firewall Threat Defense (formerly FTD) devices with Cisco Secure Firewall
Management Center (formerly FMC).
This training introduces you to several best practices that can be used to help
ensure that your managed threat defense system is configured and monitored
effectively. By the end of this training, you will be familiar with several best
practices, including the use of a prefilter, rule order, rule categories, SSL and
Security Intelligence inspections, logging with inspection policies, Syslog, and the
latest Vulnerability Database (VDB).
ACP Rule Order
The order that you create your ACP rules has a direct impact on how traffic is
processed. Traffic is compared to the rules in the ACP in a top-down fashion. For
rules that are either Allow (Analyze) or Block, traffic matching the rule is
processed according to that rule only and not compared to any other rules in the
list. For this reason, it is important to place your more specific rules at the top of
the list, and the more general rules toward the bottom.

The exception to this philosophy is with any rules that are configured with the
action Monitor. Monitor rules do not have a Block or Allow action associated with
them and are strictly to allow for logging and verifying that traffic is processed
according to the rule. After matching a Monitor rule, the traffic is processed by
the rules below it until it matches an Allow or Block rule, or the default action is
applied.
As you create rules for the list, you can choose to insert a new rule above or
below an existing rule. The default placement is below rule 1, but you can easily
use the dropdown menu to place the rule at the top of the list (above rule 1) or
anywhere that is appropriate for the rule within the list.
For existing rules that are not in the correct place, you can move the rule. Simply
edit the rule and click the Move link to the right of the rule name. You will have
an option to move the rule to a different category, and an option to move the
rule above or below another rule in the list.
Note
You can also use drag-and-drop function in order to move rules in ACP.
Rule Categories
Organizing your rules into categories can help ensure that your rules are applied
in the correct order and that they are applied to the correct traffic. When creating
categories, you should order them as the rules themselves, the more specific
categories should be placed toward the top of the list.

The example shows that the first category in the list is named Mandatory, and it
contains a monitoring rule that will neither block nor allow traffic. This rule allows
the threat defense to collect data for connections that are processed by the rule
itself.
The second category in the example is designed specifically for traffic that is
sourced from the Outside and destined for the DMZ. The rules in this category
should be created with source and destination zones and/or network settings
that help to ensure that they will only match on traffic sourcing from Outside
networks that are being routed to the DMZ networks.
The last category is designed for general traffic that is not going to match the
rules in the categories above it. Keep in mind, traffic that matches a rule in the
Outside to DMZ category will never be processed by any rules in the General
Traffic category.
Note
Categories can be collapsed or expanded depending on your needs and allowing
to find a specific category rules easier.
SSL Policy Processing
For traffic that is forwarded to the Layer 3-7 Snort inspections, note that the SSL
Decrypt policy is enforced before traffic is processed by the ACP. Therefore,
traffic that is blocked by the SSL Decrypt policy is never processed by the ACP,
freeing up CPU and memory for other traffic.

Within the SSL Decrypt policy, you can identify traffic that should be dropped for
violating SSL requirements. Traffic to drop may include self-signed certificates,
invalid validity dates, unsupported encryption cyphers, or any other SSL/TLS
based violations.
Note
It is faster and more efficient to drop TLS traffic by SSL Decryption policy than
doing this within ACP. For example, you can block a specific SSL Category traffic
within the SSL Decryption policy rather than decrypting it and then blocking
inside ACP.
Logging Traffic
Some inspections, such as File Inspection, IPS, Security Intelligence and SSL,
automatically log security events. Therefore, when you are identifying traffic that
needs to be logged, traffic that matches a security event in any of the inspectors
does not need to be identified by an ACP rule to initiate the logging process.

If your service level agreement only calls for inspected traffic to be logged, it
may not be necessary to tag the rules within the ACP for logging because the
traffic will already be logged by the inspectors in which it was matched.
Logging to the management center allows for analysis of the logged data from
the management center admin GUI. Troubleshooting and security event analysis
can then be done from an intuitive interface that a Syslog server might not be
equipped with.

However, large networks can generate a large amount of traffic, which in turn,
can generate a large amount of logged data.
If your policies require logging as much data as possible, or require long storage
retention times, it is a good idea to also log data to Syslog servers. Syslog
servers can have terabytes of storage and allow for very long storage times that
might not be available in the management center database. Logging to both
management center and Syslog servers provides the intuitive management of
the management center and the large, long-term storage of Syslog.
Note
If you need to log all traffic information for compliance, you can uncheck Firewall
Management Center as a logging destination and just leave the Syslog Server
option. This configuration will free up a lot of resources on the FMC as the syslog
is being generated directly from the managed device.
Copy the ACP Before Making Changes
Although the management center rollback feature can save time over manually
reverting a configuration to a prior version, the rollback process takes a bit of
time to complete and may cause a disruption in traffic flow when initiated.

A faster, less disruptive, method for being able to return to an original

configuration is to make a copy of the ACP before you make any changes. If all
goes well, you can delete the copy after the changes have successfully been
deployed.
But, if the changes cause issues with traffic that require you to revert to the
original configuration quickly, you can simply apply the original copy of the ACP
to the managed device, and then deploy the change.
To restore an original, copied ACP, open the copied ACP, and access the target
devices by clicking the Policy Assignments hyperlink. Add the devices to which
you want to apply the original ACP in the Selected Devices area; then click OK. In
the Confirm popup dialog, click Yes to accept the changes, then deploy the
changes to the devices.
Once deployed, the managed devices will have the original ACP configuration,
and there will be less disruption in network services to return them to the original
state.
Install VDB Updates
All the application-aware policy rules identify applications based on the Cisco
Vulnerability and Fingerprint Database (VDB). To help ensure that your Access
Control Policies are matching the correct applications, you should always use the
latest version of the VDB.
To verify that the latest VDB is installed in the management center, navigate
to System > Updates and in the Product Updates tab, click the Download
Updates button in the upper-right corner of the page. After the task has
completed, you can determine if any updates are available by navigating
to Notifications > Tasks.

The example shows that at the time of the check, no new updates were
available. If new updates were available, you should follow the update process to
install the new updates.