Enterprise Firewall Policy Design Best Practices

Enterprise Firewall Policy Design

Poor firewall policies are the #1 cause of security incidents. This guide covers design principles that work at enterprise scale.

The Golden Rules

1. Default deny: Block everything, whitelist what's needed
2. Rule ordering matters: First match wins — put specific rules before general
3. Name every rule: "allow-web-servers-to-db" beats "rule-47"
4. Log everything you block (and sample what you allow)
5. Review quarterly: Dead rules accumulate; clean them out

Rule Structure Template

Rule Name: [ZONE-SRC]-to-[ZONE-DST]-[SERVICE]
Source: Specific IP/group (not "any")
Destination: Specific IP/group (not "any")
Service: Named service object (not port number)
Action: Accept | Deny
Log: Yes (always on deny; on accept for sensitive)

Zone-Based Architecture

Internet → [Fortigate/Firewall]
                |
    ┌───────────┼───────────┐
    ▼           ▼           ▼
  DMZ         CORP        SERVER
(Web/Mail)  (Staff)    (DB/App)

Traffic flows:

• Internet → DMZ: Only ports 80/443 to web servers
• DMZ → CORP: Never
• CORP → SERVER: Only needed ports (1433 for SQL, etc.)
• CORP → Internet: HTTP/HTTPS via proxy, deny all else

Fortigate Policy Example

Policy: CORP-to-SERVER-SQL
Source Zone: CORP
Destination Zone: SERVER
Source: Corp-Workstations (address group)
Destination: SQL-Servers (address group)
Service: MS-SQL (TCP/1433)
Action: Accept
Log: All Sessions
IPS: Enable

Common Mistakes

• "Any-any" rules left from initial setup
• Overlapping rules causing unintended allow
• No logging = no forensics when incidents happen
• Missing egress filtering (attackers love this)
• Not testing after changes

Quarterly Cleanup Checklist

• [ ] Remove rules with zero hit count > 90 days
• [ ] Verify all address objects still exist
• [ ] Check for shadow rules (rules that never match)
• [ ] Review admin access rules
• [ ] Update documentation