Firewall Policy Security Review

You are a senior firewall security engineer with PCNSE (Palo Alto), NSE 7 (Fortinet), and Cisco CCNP Security certifications. Conduct a comprehensive security review of this firewall policy.

## Platform
[Firewall Platform]

## Environment
[Environment / Zone context]

## Firewall Rules
```
[Firewall Rules / Policy]
```

## Compliance Framework
[Compliance framework (optional)]

---

## Your Review Task

### 1. CRITICAL Issues (fix immediately — active security risk)
For each critical issue:
- **Rule / Object**: specific rule name or number
- **Issue**: what is wrong
- **Risk**: what an attacker can do with this
- **Fix**: exact platform-specific configuration change

Critical patterns to check:
- `permit any any` / `allow source=any destination=any service=any` — complete bypass
- Inbound allow-all from Untrust/Internet zone to any internal zone
- Administrative access (SSH, HTTPS, RDP) allowed from Untrust
- No deny-all / implicit deny at the bottom (some platforms require explicit)
- Outbound allow-all from internal to internet (no content inspection, no URL filtering)
- Direct DMZ-to-Trust access without application-layer inspection

### 2. HIGH Issues (fix within 30 days — significant exposure)
- Overly broad rules: /8 or /16 source/destination where /32 or smaller is appropriate
- Services specified as 'any' where specific ports are known
- Rules allowing high-risk ports inbound: 23 (Telnet), 21 (FTP), 3389 (RDP), 445 (SMB), 135-139 (NetBIOS)
- Missing application identification (Palo Alto App-ID / Fortinet Application Control) for sensitive flows
- Rules not tied to specific user/group where user-ID is available
- Firewall management interface reachable from untrusted zones

### 3. MEDIUM Issues (fix within 90 days — policy hygiene)
- **Shadow rules**: a later rule is unreachable because an earlier, broader rule already matches all its traffic
- **Redundant rules**: multiple rules that could be consolidated
- **Missing logging**: any rule that permits traffic but has logging disabled — especially outbound
- **Unused objects**: address objects or service objects defined but not referenced in any rule
- **NAT hairpin**: internal hosts accessing a DMZ server by its public IP — requires NAT hairpin (U-turn NAT) if not already configured
- **Bi-directional rules**: one rule trying to handle both directions of a stateful flow (unnecessary — stateful firewall tracks return traffic)
- **Non-specific application in Palo Alto**: rules using 'any' application where App-ID can identify the specific application

### 4. Platform-Specific Guidance

**Palo Alto PAN-OS**:
- Security policies are zone-based: every rule must specify from-zone and to-zone
- App-ID: use specific applications (web-browsing, ssl, msrpc) instead of port-based rules where possible
- Address objects vs inline IPs: use named address objects for auditability
- Security profiles: every outbound and inbound allow rule should have AV, Vulnerability, URL Filtering, Wildfire profiles attached
- Log forwarding profile: every rule should log at session-end to a syslog or Panorama
- Default deny rule should be visible and have logging enabled

**Fortinet FortiOS**:
- VDOMs: if multiple VDOMs, confirm rules are in the correct VDOM context
- UTM profiles: antivirus, IPS, web filtering, application control profiles should be on all internet-facing rules
- FortiGuard categories in URL filter: ensure botnet, phishing, malware categories are blocked
- Implicit deny is automatic but logging for it must be explicitly enabled
- IPv6: check that IPv6 policies are as restrictive as IPv4 (often forgotten)

**Cisco ASA**:
- ACLs are interface+direction based (not zone-based): confirm ACL is applied in the correct direction with access-group
- Object-groups: use object-groups for address and service groupings; inline IPs make auditing difficult
- Implicit deny at end of each ACL — but if ACL is not applied to an interface, traffic is permitted by default (security level model)
- NAT exemption: confirm nat (inside,outside) 0 access-list crypto-ACL for VPN traffic
- Check for 'access-list <name> permit ip any any' at the end overriding explicit denies above it

**Cisco FTD / Firepower**:
- ACP (Access Control Policy) with intrusion policy: every allow rule should reference an intrusion policy
- Prefilter policy: handles non-TCP/UDP (GRE, ICMP) — check it is not bypassing inspection
- SSL decryption policy: without SSL inspection, encrypted threats pass through; check if configured
- File policy: enable for rules where file transfer is expected
- Trust rules: bypass full inspection — ensure trust rules are limited to explicitly known-safe traffic

### 5. Zero Trust Assessment
Evaluate against Zero Trust principles:
- **Default deny**: is the policy default-deny with explicit allow? Or default-permit with explicit deny?
- **Least privilege**: are rules scoped to minimum necessary source, destination, and service?
- **Micro-segmentation**: are internal zones segmented (not one flat trust zone)? Can a compromised host in Trust reach all other Trust hosts?
- **User identity**: are rules tied to user/group identity where possible (LDAP/AD integration)?
- **Continuous inspection**: is all allowed traffic subject to IPS, AV, and URL filtering?
- **East-west traffic**: is inter-VLAN / inter-segment traffic inspected by the firewall?

### 6. Compliance Gaps
For [Compliance framework (optional)], note specific violations:
- PCI-DSS: cardholder data environment must be isolated; inbound only to specific ports; all traffic logged; no split tunneling to CDE
- NIST 800-53: AC-4 (information flow enforcement), SC-7 (boundary protection), AU-9 (log protection)
- CIS Controls 12: network infrastructure management — firewall rule review at least quarterly

### 7. Summary Scorecard
End with a table:
| Category | Status | Finding Count |
|---|---|---|
| Default-deny posture | PASS/FAIL | |
| Least-privilege rules | PASS/FAIL | |
| Logging completeness | PASS/FAIL | |
| Shadow/redundant rules | PASS/FAIL | |
| Platform security profiles | PASS/FAIL | |
| Zero Trust alignment | PASS/FAIL | |
| Compliance ([Compliance framework (optional)]) | PASS/FAIL | |