Security Policies & Rulebase
Security Policy Rule Components
A PAN-OS security policy rule is a rich object with many fields. Each field narrows down which traffic the rule matches. When all fields match, the rule action is applied.
| Component | Description | Example Value |
|---|---|---|
| Name | Descriptive rule identifier for audit purposes | Allow-Finance-to-SAP |
| Tags | Color-coded labels for organization and search | Finance, SAP, Approved-2026 |
| Source Zone | Zone(s) where traffic originates | trust |
| Source Address | IP, subnet, or address object of sender | Finance-Subnet (192.168.20.0/24) |
| Source User | User or group from User-ID | CN=Finance-Team,OU=Groups |
| Destination Zone | Zone(s) where traffic is destined | dmz |
| Destination Address | IP, subnet, or address object of destination | SAP-Server-VIP |
| Application | App-ID application name | sap, ssl, web-browsing |
| Service | Port/protocol (use application-default) | application-default |
| URL Category | Web category for URL filtering | business-and-economy |
| Action | What to do when rule matches | allow, deny, drop, reset-client, reset-server |
| Profile Group | Security profiles to apply on allowed traffic | Strict-Security-Profile-Group |
| Log Setting | Where to send logs and when | Log at Session End → Panorama |
application-default vs any service
Rule Matching Order
PAN-OS evaluates the security rulebase from top to bottom. The first rule that matches all criteria of the packet is the rule that is applied. No further rules are evaluated after a match — this is called first-match semantics.
Place more specific rules higher in the rulebase. A rule allowing Finance → SAP must appear before any broader rule that might match the same traffic.
The order of rules determines which profile group applies. Two rules could match the same traffic; only the first one wins.
The implicit deny is the invisible last rule — if no rule matches, the traffic is dropped without logging (unless you add an explicit deny-all cleanup rule with logging enabled).
Rule Types
| Rule Type | Direction | Default Behavior |
|---|---|---|
| Universal | Both intrazone and interzone | Matches traffic in both directions between specified zones |
| Intrazone | Within same zone only | Traffic between interfaces in the same zone |
| Interzone | Between different zones only | Traffic crossing from one zone to a different zone |
Universal rules are the most common. They match traffic regardless of whether the source and destination zones are the same or different, as long as both zones appear in the rule definition.
Security Profile Groups
When a security policy rule allows traffic, you attach a security profile group to inspect that traffic for threats. The profile group bundles multiple scanning profiles together for easy reuse.
Profile Types in a Group
- Antivirus — scans file transfers for known malware signatures; blocks malicious files in real time
- Anti-Spyware — detects C2 communication, botnet traffic, and DNS-based threats
- Vulnerability Protection — IPS engine; blocks exploit attempts against known CVEs
- URL Filtering — controls web access by category; requires a URL Filtering license
- File Blocking — blocks specific file types by type or direction (upload/download)
- WildFire Analysis — submits unknown files to the WildFire cloud sandbox for behavioral analysis
Recommended Profile Strategy
Create a Strict profile group for high-risk zones: strict AV, strict IPS (all severities set to block/reset), WildFire on all file types.
Create a Baseline profile group for internal low-risk zones: medium AV coverage, IPS at alert for informational/low severity.
Attach a profile group to every allow rule — an allow rule without a security profile is a missed inspection opportunity.
Rule Shadowing
Rule shadowing occurs when a broader rule earlier in the rulebase matches the same traffic as a more specific rule lower down. The specific rule never gets evaluated — it is shadowed.
Example: A rule on line 5 permits any traffic from the trust zone to any destination on any application. A rule on line 20 tries to block social media for the Engineering group. The line-20 rule never fires because line 5 matches first and allows everything.
Policy Optimizer
Best Practices for Rulebase Design
- Write rules with App-ID, not port-based service — 'allow tcp/443' becomes 'allow ssl + web-browsing + application-default'
- Use address objects and groups instead of raw IPs — objects are reusable and searchable
- Tag every rule with owner, change ticket, and date — makes auditing and cleanup faster
- Put deny rules for specific threats above general allow rules when needed
- Enable log at session end for all rules — log at session start only when you need connection time data
- Create a final cleanup rule: source any, destination any, application any, action deny, with logging enabled
- Use rule groups and tags to organize large rulebases by business function
- Review rules quarterly — remove or disable rules with zero hits for 90 days
- Never use 'any' in source or destination zones unless you truly mean all zones
Migrating from Port-Based to App-ID Rules
Many organizations inherited port-based firewall rules before App-ID became available. Migrating these to App-ID rules improves security significantly — it eliminates the assumption that port 443 is only web traffic.
Step 1: Enable security rule hit count and App-ID logging. Monitor for 30–60 days to understand what applications are actually using each rule.
Step 2: Use Policy Optimizer to identify which applications are seen on each port-based rule.
Step 3: Create new App-ID-based rules for the observed applications. Run them in parallel (above the old rule, with logging) to verify they match expected traffic.
Step 4: After a validation period, disable the old port-based rule. Monitor for broken applications before permanently deleting.