Cisco Cisco FirePOWER Appliance 7020
14-28
FireSIGHT System User Guide
Chapter 14 Understanding and Writing Access Control Rules
Working with Different Types of Conditions
The FireSIGHT System allows you to write access control rules that determine the traffic that can
traverse your network based on URLs requested by monitored hosts, correlated with information about
those URLs, which is obtained from the Collective Security Intelligence Cloud by the Defense Center.
This feature is called URL filtering.
traverse your network based on URLs requested by monitored hosts, correlated with information about
those URLs, which is obtained from the Collective Security Intelligence Cloud by the Defense Center.
This feature is called URL filtering.
Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block.
However, before you can perform category and reputation-based URL filtering, you must not only enable
URL Filtering licenses on your target devices, but also explicitly allow the Defense Center to contact the
Cisco cloud. Note that neither the DC500 Defense Center nor Series 2 devices support URL filtering
using category and reputation data, and Series 2 devices do not support specifying individual URLs or
URL groups. For more information on URL filtering prerequisites, see
However, before you can perform category and reputation-based URL filtering, you must not only enable
URL Filtering licenses on your target devices, but also explicitly allow the Defense Center to contact the
Cisco cloud. Note that neither the DC500 Defense Center nor Series 2 devices support URL filtering
using category and reputation data, and Series 2 devices do not support specifying individual URLs or
URL groups. For more information on URL filtering prerequisites, see
Using URL Category and Reputation Data
When the Defense Center contacts the Cisco cloud, it retrieves data on many commonly visited URLs,
and saves that data to local databases on your appliances. Each of these URLs has an associated category
and reputation:
and saves that data to local databases on your appliances. Each of these URLs has an associated category
and reputation:
•
The URL category is a general classification for the URL. For example, ebay.com belongs to the
Auctions
category, and monster.com belongs to the
Job Search
category. A URL can belong to more
than one category.
•
The URL reputation represents how likely the URL is to be used for purposes that might be against
your organization’s security policy. A URL’s risk can range from
your organization’s security policy. A URL’s risk can range from
High risk
(level 1) to
Well known
(level 5).
URL categories and reputations allow you to quickly create URL conditions for access control rules;
these rules can group and combine URL categories and risks. For example, you could create a URL
condition that blocks all
these rules can group and combine URL categories and risks. For example, you could create a URL
condition that blocks all
High risk
URLs in the
Abused Drugs
category. Then, if someone on your monitored
network attempts to browse to any URL with that category and reputation, the session is blocked.
Note
To display URL category and reputation data for URLs in connection logs, intrusion events, and
application details, you must create at least one access control rule with a URL condition.
application details, you must create at least one access control rule with a URL condition.
Note that if the cloud does not know the category or reputation of a URL, or if the Defense Center cannot
contact the cloud, the URL does not trigger access control rules with category or reputation-based URL
conditions. You cannot assign categories or reputations to URLs manually.
contact the cloud, the URL does not trigger access control rules with category or reputation-based URL
conditions. You cannot assign categories or reputations to URLs manually.
Limitations on URL Detection and Blocking
The system cannot filter URLs before a connection is established between the client and the server.
Therefore, when a packet matches all the other conditions in a rule containing a URL condition, if URL
identification has not been completed, the packet is allowed to pass. This behavior allows a connection
to be established so that URLs can be identified.
Therefore, when a packet matches all the other conditions in a rule containing a URL condition, if URL
identification has not been completed, the packet is allowed to pass. This behavior allows a connection
to be established so that URLs can be identified.
When the system processes an access control rule containing a URL condition, packets that otherwise
match that rule are allowed and inspected using the default intrusion policy until the HTTP application
is identified in the session. After the HTTP application is identified, the system applies the action from
the rule to the remaining session traffic matching the URL conditions. HTTP identification should occur
within 3 to 5 packets. If it does not, confirm that your network discovery policy is up-to-date and applied
to all devices and does not exclude any of the networks and ports configured in the access control rule.
match that rule are allowed and inspected using the default intrusion policy until the HTTP application
is identified in the session. After the HTTP application is identified, the system applies the action from
the rule to the remaining session traffic matching the URL conditions. HTTP identification should occur
within 3 to 5 packets. If it does not, confirm that your network discovery policy is up-to-date and applied
to all devices and does not exclude any of the networks and ports configured in the access control rule.
When creating a URL condition, selecting a reputation level behaves differently depending on the rule
action:
action: