Firewall Rule Reference and Governance

Purpose

Tell a new on-call engineer everything they need to know about how firewall rules are governed at Cirius Group, without giving them the power (or the ammunition) to change them.

This document is a governance reference, not a rule list. The live rule set is in Panorama. This document covers:

1. Who can change rules, and how.
2. Why rules are not duplicated into this repo.
3. The known rule categories, so a responder can understand a log line.
4. Where the actual rules live when someone needs to look.

Related:

• security/firewall-change-procedure.md — the Palo-specific mechanics
• security/panorama-operations.md — Panorama backup/restore/commit
• architecture/two-firewall-architecture.md — what the rules defend
• architecture/network-topology.md — zones and IP ranges

---

Governance

Rory is the sole approver

There is exactly one person authorized to approve a Palo Alto rule change in the Cirius environment: Rory. This is not a staffing artifact — it is an intentional control aligned with HIPAA §164.308(a)(3) (workforce security) and the single-admin risk acceptance registered with the compliance program.

Never touched without explicit instruction from Rory:

• PublicFW policy (azure-prod-firewall)
• PrivateFW policy (when live)
• Panorama device groups, shared objects, security profile groups
• NAT policy, QoS policy, security profile bindings
• Any address object, address group, service, or tag referenced by a security policy

Kobe (this agent) is explicitly forbidden from:

• Running configure commands on any firewall or Panorama
• Committing a Panorama candidate config
• Editing palo-alto-configs/ Terraform with the intent to change policy (pan-os terraform provider is read-only in this environment pending Rory's future decision on GitOps)
• Adding "just the one rule" because a ticket says so. The answer is always raise it to Rory.

How a rule change is requested

1. Requester files a ticket in SecOps (or sends Rory a direct message for urgent cases). Ticket must include: problem statement, proposed source/destination/service, proposed security profile, business justification, compensating control if the ticket is for a temporary exception.
2. Rory reviews. If approved, Rory either (a) makes the change himself in Panorama, or (b) delegates a specific targeted change to Kobe with explicit natural-language instruction ("add a rule on PrivateFW allowing ...").
3. Change is committed to Panorama. Panorama auto-backs the running config to paloaltobackupsa/firewall-configs in Azure Blob.
4. A CM ticket is opened in SecOps per security/firewall-change-procedure.md, capturing the delta and suppression window.
5. A PR is raised on bedrock-docs if the change affects documented architecture, topology, or governance.

What never happens

• No auto-approval. Break-glass cases still wait for Rory or for a pre-registered break-glass rule that Rory has already sanctioned.
• No "I'll add the rule and check with Rory after." If the rule would be approved after the fact, it will still be approved before the fact — there is no time pressure that justifies inverting this.
• No rule is suppressed by adding it to a "known good" list without Rory's approval. The known-good mechanism is documented in compliance/three-layer-access-architecture.md.

---

Why Rules Are Not Duplicated into This Repo

The live rules live in Panorama. This repo does not contain a cloned rule list for three reasons:

1. Drift. A rule in source control that disagrees with Panorama invites incorrect incident triage. The backup XML from Azure Blob is always authoritative.
2. Blast radius. If this repo were the "rule spec", a rogue PR could alter the audit record without touching the firewall.
3. Review surface. Rory reviews the Panorama candidate config pre-commit. Putting the same review on a Git diff is duplicated effort that fails Kobe's audit-evidence goal.

What this repo does contain:

• Architecture (what the policy should enforce at a design level)
• Categories of rules (below) to aid responders
• The commit diff for the Palo Alto backup XML via the backup job
• Change management procedure and evidence mapping

---

Known Rule Categories

These are the rule categories that exist across PublicFW and PrivateFW. Counts and exact rule text live in Panorama; the category is what a responder needs to understand a log line in LAW.

On PublicFW

Category	Purpose	Zones	Notes
inbound-gp-portal	GP portal TCP/443 reachable from untrust	untrust → dmz	Source = any, dest = GP portal FQDN. CEO/CTO use. Hits on allowlisted countries only where practical.
outbound-dmz-to-twingate	DMZ connectors reach Twingate cloud	dmz → untrust	Destination = Twingate FQDN list. URL filtering + WildFire on.
outbound-internal-egress	Server patching / telemetry	dmz → untrust	Chained via PrivateFW; PublicFW does the internet-facing inspection.
outbound-rodc-patching	RODC updates	dmz → untrust	Scoped to Windows Update FQDNs.
mgmt-access	Panorama ↔ firewall mgmt plane	management	Not user traffic.
deny-all-inbound	Implicit deny bottom rule	any → any	Explicit hit counter; spikes here drive incidents.

On PrivateFW

Category	Purpose	Zones	Notes
gp-gateway-landing	GP tunnel landing on DMZ-facing interface	dmz → vpn-users	Per-user allow-list via Entra group.
vpn-users-to-trust	GP users reaching PHI	vpn-users → trust-prod/-identity/-dev	Narrowly scoped per role. CEO/CTO only in the Entra group.
twingate-resource-access	Twingate resource IPs reach PHI	dmz → trust-*	Source restricted to the two Twingate connector IPs (see twingate-connector-ips.md).
ad-replication	Identity ↔ Prod/Dev DC replication	trust-identity ↔ trust-prod/dev	Specific ports per Microsoft docs.
inter-vnet-policy	Named flows Prod ↔ Identity	trust-prod ↔ trust-identity	Deny-by-default; each permit documented in Panorama description field.
outbound-internet-egress	Servers to internet via PublicFW	trust-* → dmz	Chained to PublicFW for the actual internet-facing inspection.
rodc-auth	DMZ services reaching the DMZ RODC	dmz → dmz-auth	Scoped to the RODC.
deny-all-east-west	Implicit deny bottom rule	any → any	Spikes here drive incidents.

These are rule categories, not rules. A single category typically maps to 1-6 Panorama rules.

---

Where the Actual Rules Live

Artifact	Location	How to access
Live running config	Panorama (azure-prod-panorama)	Rory only; not Kobe-accessible for write
Backed-up running config XML	Azure Blob paloaltobackupsa/firewall-configs/<device>/running-config.xml	Read via az storage blob download --auth-mode login; read-only
Historical backups	Same container, timestamped paths	Backed up nightly per security/palo-alto-config-backup.md
Audit findings	SecOps (ingested by scripts/prod-palo-audit.py + sibling scripts)	secops.bedrockcybersecurity.org
pan-analyzer exemptions (audit)	palo-alto-configs/pan-analyzer-exemptions.yaml	PR via palo-alto-configs, Rory-approved
Rule categories (this doc)	runbooks/firewall-rule-reference.md	PR via bedrock-docs

The Panorama running config is the only authoritative source. Any disagreement between this document and the running config should be resolved by updating this document — it is the documented description, not the enforced policy.

---

On-call Responder Cheat Sheet

If an incident references a firewall log line:

1. Which firewall was it? Device name in the log (azure-prod-firewall = PublicFW). PrivateFW logs carry its device name.
2. Which rule hit? Panorama rule name is in the log. Look it up in Panorama (read-only view) or in the backup XML.
3. Which category does that rule fall under? Use the tables above.
4. Is the rule expected to match this flow? If yes, continue triage. If no — and this is the important case — the rule may be misordered or the object set may have drifted. This is a change review event: escalate to Rory before touching anything.

Do not modify Panorama to "fix" a misorder during an incident without Rory's explicit go-ahead. An incorrect permit is recoverable; an unreviewed permit-all is not.