Designing security policies that actually scale
I inherited a Palo Alto rule base with 437 security policies.
- #engineer-series
- #paloaltonetworks
- #networksecurity
- #firewallengineer
- #pcnse
- #securitypolicy
- #cybersecurity
By Mrugesh Patel, Senior Network Security Engineer
Originally posted on LinkedIn — Engineer Series · 2026-06-15
I inherited a Palo Alto rule base with 437 security policies.
No descriptions. No tags. Rules named “test”, “temp-fix”, “NEW RULE 3”, and my personal favourite — “DO NOT DELETE.”
Cleaning it took three months. Building it right takes three habits.
Here’s how to design security policies that don’t collapse under their own weight:
🏗️ Habit 1: Zone-first, then application
The most common mistake: engineers write rules for IPs and ports.
IPs change. Ports lie. Applications tell the truth.
Design your policy matrix around zone pairs first:
→ Trust → Untrust: what apps do users need out?
→ DMZ → Trust: what can your servers call back?
→ Untrust → DMZ: what do you actually publish?
Once you have the matrix, fill in App-IDs — not port numbers.
A policy built on applications survives infrastructure changes. One built on ports doesn’t.
📛 Habit 2: Name rules like you’ll be reading them at 3am
Bad: Rule_147
Bad: allow-web
Bad: TEMP (do not delete)
Good: [SRC-Trust][DST-Untrust] Finance-SAP-to-Cloud
Format: [Source Zone][Dest Zone] Purpose-App-Direction
Every rule should answer three questions in its name:
→ Where is traffic coming from?
→ Where is it going?
→ Why does it exist?
If you can’t answer all three, the rule shouldn’t exist.
🏷️ Habit 3: Tags are not optional
Tag every rule with at minimum:
→ Owner (which team requested it)
→ Ticket number (change request reference)
→ Review date (when this rule should be re-evaluated)
Panorama’s dynamic address groups + tags = policy management that actually scales across 50 firewalls without copy-paste chaos.
No tags = no audit trail = the rule nobody deletes because nobody knows what it does.
The cleanup path if you’re already in the mess:
- Export the rule base to CSV
- Filter for rules with zero hits in the last 90 days (Security > Policy Optimizer)
- Shadow rules — find rules completely covered by a rule above them
- Move candidates to a Review rule group, disable, monitor 30 days
- Delete with evidence, not hope
Policy Optimizer in PAN-OS 9.0+ does most of this analysis for you. If you’re not using it — start today.
The rule base is a living document. Design it like one from day one.
What’s the worst rule you’ve ever inherited?
Found this useful?
Share it on LinkedIn — it tells me what to write about next, and helps other engineers find it.