Within an access control policy,
access control rules provide a granular method of handling
network traffic across multiple managed devices.
Hardware-based fast-path rules, Security Intelligence-based
traffic filtering, SSL inspection, user identification, and some decoding and
preprocessing occur before access control rules evaluate network traffic.
The system matches traffic to access control rules in the order
you specify. In most cases, the system handles network traffic according to the
first access control rule where
all the rule’s conditions match the traffic.
Each rule also has an
action, which determines whether you monitor, trust, block,
or allow matching traffic. When you allow traffic, you can specify that the
system first inspect it with intrusion or file policies to block any exploits,
malware, or prohibited files before they reach your assets or exit your
network.
The following scenario summarizes the ways that traffic can be
evaluated by access control rules in an inline, intrusion prevention
deployment.
In this scenario, traffic is evaluated as follows:
-
Rule 1: Monitor evaluates traffic first. Monitor rules track
and log network traffic but do not affect traffic flow. The system continues to
match traffic against additional rules to determine whether to permit or deny
it.
-
Rule 2: Trust evaluates traffic next. Matching traffic is
allowed to pass to its destination without further inspection. Traffic that
does not match continues to the next rule.
-
Rule 3: Block evaluates traffic third. Matching traffic is
blocked without further inspection. Traffic that does not match continues to
the final rule.
-
Rule 4: Allow is the final rule. For this rule, matching
traffic is allowed; however, prohibited files, malware, intrusions, and
exploits within that traffic are detected and blocked. Remaining
non-prohibited, non-malicious traffic is allowed to its destination. Note that
you might have additional Allow rules that perform only file inspection, or
only intrusion inspection, or neither.
-
Default Action handles all traffic that does not match any
of the rules. In this scenario, the default action performs intrusion
prevention before allowing non-malicious traffic to pass. In a different
deployment, you might have a default action that trusts or blocks all traffic,
without further inspection. (You cannot perform file or malware inspection on
traffic handled by the default action.)
Traffic you allow, whether with an access control rule or the
default action, is automatically eligible for inspection for host, application,
and user data by the network discovery policy. You do not explicitly enable
discovery, although you can enhance or disable it. However, allowing traffic
does not automatically guarantee discovery data collection. The system performs
discovery only for connections involving IP addresses that are explicitly
monitored by your network discovery policy; additionally, application discovery
is limited for encrypted sessions.
Note that access control rules handle encrypted traffic when
your SSL inspection configuration allows it to pass, or if you do not configure
SSL inspection. However, some access control rule conditions require
unencrypted traffic, so encrypted traffic may match fewer rules. Also, by
default, the system disables intrusion and file inspection of encrypted
payloads. This helps reduce false positives and improve performance when an
encrypted connection matches an access control rule that has intrusion and file
inspection configured.
Access Control Rule
Management
The
Rules tab of the access control policy editor allows
you to add, edit, categorize, search, move, enable, disable, delete, and
otherwise manage access control rules in the current policy.
For each access control rule, the policy editor displays its
name, a summary of its conditions, the rule action, plus icons that communicate
the rule’s inspection and logging options. Other icons represent comments
(),
warnings (),
errors (),
and other important information ().
Disabled rules are dimmed and marked
(disabled) beneath the rule name.
To create or edit a
rule, use the access control rule editor. You can:
-
Configure basic properties such as the rule’s name, state,
position, and action in the upper portion of the editor.
-
Add conditions using the tabs on the left side of the lower
portion of the editor.
-
Use the tabs on the right side of the lower portion to configure
inspection and logging options, and also to add comments to the rule. For your
convenience, the editor lists the rule’s inspection and logging options
regardless of which tab you are viewing.
Note |
Properly creating and ordering access control rules is a complex
task, but one that is essential to building an effective deployment. If you do
not plan your policy carefully, rules can preempt other rules, require
additional licenses, or contain invalid configurations. To help ensure that the
system handles traffic as you expect, the access control policy interface has a
robust warning and error feedback system for rules.
|
Access Control Rule
Inheritance
Each access control
policy has two system-provided rule sections: Mandatory and Default. All access
control rules must belong to one of those sections. An access control policy’s
rules are nested between its parent policy’s Mandatory and Default rule
sections.
You can only add and
edit rules in the policy you are currently editing, which appears as the
innermost policy. You cannot view or edit rules in descendant policies; you can
view but not edit the rules in ancestor policies.
In a typical
deployment, where you deploy the innermost access control policy, the system
matches traffic against Mandatory rules in every policy, staring with the
outermost and working inwards. If traffic does not match any Mandatory rules,
the system uses the Default rules in every policy, starting with the innermost
and working outwards.
Although you can
strictly enforce other settings on descendant policies, you cannot enforce
Default rules or the default action:
-
Mandatory access
control rules preempt rules in descendant policies. The system matches traffic
against the Mandatory rules in every ancestor policy before it matches traffic
against the rules in the deployed policy. Place a rule in the Mandatory section
if you want the rule to handle traffic before any descendant policy’s rules.
-
Default access
control rules preempt rules in ancestor policies. Place a rule in the Default
section if you want to allow descendant policies’ rules to handle the target
traffic a different way.
-
If traffic matches
none of the (non-Monitor) rules in either the deployed policy or the deployed
policy’s ancestors, the system uses the deployed policy’s default action.
Although an access control policy can inherit its default action from an
ancestor policy, you cannot enforce this inheritance.
For example, nested
access control policies might display the following rule evaluation order while
editing the innermost policy:
-
Mandatory rules -
Global Policy
-
Default rules -
Global Policy
-
Default action -
Subdomain Policy