Network Security
Security Policy
Table of Contents
Security Policy
Where Can I Use This? | What Do I Need? |
---|---|
| Check for any license or role requirements for the products you're
using:
|
Every policy is constructed such that it applies to
a specific type of traffic on the network. Security polices give
you precise and granular control of all network traffic.
What Is a Security Policy?
Security policy protects network assets from threats and disruptions and helps to
optimally allocate network resources for enhancing productivity and efficiency in
business processes. Individual Security policy rules determine whether to block or
allow a session based on traffic attributes, such as the source and destination
security zone, the source and destination IP address, the application, the user, and
the service.
Policies allow you to enforce rules and take action. The different types of policy
rules that you can create are: Security, NAT, Quality of Service (QoS), Policy Based
Forwarding (PBF), Decryption, Application Override, Authentication, Denial of
Service (DoS), and Zone protection policies. All these different policies work
together to allow, deny, prioritize, forward, encrypt, decrypt, make exceptions,
authenticate access, and reset connections as needed to help secure your
network.
It's important to understand that in policy rules, the set of IPv4 addresses is
treated as a subset of the set of IPv6 addresses. However, the set of IPv6 addresses
isn't a subset of the set of IPv4 addresses. An IPv4 address can match a set or
range of IPv6 addresses; but an IPv6 address cannot match a set or range of IPv4
addresses.
In all policy types, the keyword
any
for a source or
destination address means any IPv4 or IPv6 address. The keyword
any
is equivalent to ::/0. If you want to express "any
IPv4 address", specify 0.0.0.0/0.During policy matching, an IPv4 address is converted into an IPv6 prefix where the
first 96 bits are 0. An address of ::/8 means, match the rule if the first 8 bits
are 0. All IPv4 addresses will match ::/8, ::/9, ::/10, ::/11, ... ::/16, ... ::/32,
... through ::/96.
If you want to express "any IPv6 address, but no IPv4 addresses", you must configure
two rules. The first rule denies 0.0.0.0/0 to deny any IPv4 address (as the source
or destination address), and the second rule has ::/0 to mean any IPv6 address (as
the source or destination address), to satisfy your requirement.
How Does a Security Policy Work?
All network traffic is matched against a session and each session is matched against
a Security policy rule. When a session match occurs, the matching Security policy
rule is applied and the actions specified in the rule (for example, (allow/deny,
logging, applying profiles) are executed on the bidirectional traffic in that
session (client to server and server to client). For traffic that doesn’t match any
defined rules, the default rules apply. The default rules—displayed at the bottom of
the security rulebase—are predefined to allow all intrazone traffic (within a zone)
and deny all interzone traffic (between zones). Although these rules are part of the
predefined configuration and are read-only by default, you can override them and
change a limited number of settings, including the tags, action (allow or block),
log settings, and security profiles.
For a Security policy rule to allow traffic, the traffic must match the rule exactly.
The traffic must also meet the criteria of every Security profile attached to the
rule or the traffic gets blocked. Security profiles define how
you handle the traffic that matches the Security policy to which you apply the
profiles. Profiles specify how the traffic is inspected (what you look for in the
traffic, for example malware, spyware, exploits, potentially malicious file types).
Security policy rules are evaluated left to right and from top to bottom. A packet is
matched against the first rule that meets the defined criteria. After a match is
triggered, subsequent rules are not evaluated. Therefore, the more specific rules
must precede more generic ones in order to enforce the best match criteria. Traffic
that matches a rule generates a log entry at the end of the session in the traffic
log if you enable logging for that rule. The logging options are configurable for
each rule and can, for example, be configured to log at the start of a session
instead of, or in addition to, logging at the end of a session.
After an administrator configures a rule, you can view policy rule usage to determine
when and how many times traffic matches the Security policy rule to determine its
effectiveness. As your rulebase evolves, change and audit information get lost over
time unless you archived this information at the time the rule is created or
modified. You can enforce policy rule description, tag, and audit comment to ensure
that all administrators enter audit comments so that you can view the audit comment
archive and review comments and configuration log history and can compare rule
configuration versions for a selected rule. Together, you now have more visibility
into and control over the rulebase.