Security Policy
Network Security

Security Policy

Table of Contents

Security Policy

Where Can I Use This?
What Do I Need?
  • NGFW (Cloud Managed)
  • NGFW (PAN-OS & Panorama Managed)
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
Check for any license or role requirements for the products you're using.
  • Certain features may require Advanced WildFire, Advanced URL Filtering, Advanced Threat Prevention, or DNS Security license
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 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 security 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.

How Does a Security Policy Work?

All network traffic is matched against a session and each session is matched against a Security rule. When a session match occurs, the matching Security 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 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 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 security rule usage to determine when and how many times traffic matches the Security 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 security 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.

Recommended For You