Appearance
Firewall Change Request Procedure
Purpose
This document defines the formal process for requesting, approving, implementing, and documenting firewall policy changes across all Palo Alto VM-Series environments. It applies to all four firewalls: Azure production, Azure dashboard, DDE, and AWS DR.
Scope
This procedure applies to:
- Security policy rule additions, modifications, or deletions
- Zone configuration changes
- Address object / address group changes
- Service object changes
- SSL/TLS decryption policy changes
- NAT policy changes
- Admin account changes
- Any Panorama device group or template stack changes
It does not apply to read-only operations (log review, traffic monitoring) or automated config backup processes.
Change Classification
Standard Change (Pre-approved)
Low-risk changes with a well-understood impact that follow an established pattern.
| Example | Approval Required |
|---|---|
| Adding a known application to an existing allow policy | IT Admin self-approval |
| Adding a new internal host to an existing address group | IT Admin self-approval |
| Updating an expiring certificate on the firewall | IT Admin self-approval |
Standard changes may be implemented immediately with documentation completed post-change.
Normal Change (Requires Review)
Changes with moderate impact or risk that require a brief review before implementation.
| Example | Approval Required |
|---|---|
| Creating a new security policy rule | IT Admin + second reviewer where available |
| Opening access to/from the untrust zone | IT Admin + documented justification |
| Any change affecting the DDE customer-facing firewall | IT Admin + brief impact assessment |
| Modifying SSL decryption policy | IT Admin + documented justification |
Normal changes require a change record completed before implementation.
Emergency Change (P1 Incident Response)
Changes required immediately to contain an active incident. Normal approval is bypassed.
| Example | Action |
|---|---|
| Blocking attacker IP during active breach | Implement immediately, document within 24 hours |
| Emergency deny rule during ransomware containment | Implement immediately, document within 24 hours |
Emergency changes must be reviewed post-incident and either formalized or rolled back.
Change Request Process
Step 1: Define the Change
Before opening a change request, document:
- What: The specific rule or object being added/modified/deleted
- Why: The business or security justification
- Scope: Which firewall(s) and zones are affected
- Risk: What could break if the change is incorrect
- Test plan: How to verify the change worked correctly
- Rollback: How to undo the change if needed
Step 2: Create the Change Record
Log the change in the running firewall change log (see template below). For Normal changes, complete this before implementing. For Standard changes, this can be completed the same day.
Create a change management ticket in SecOps:
- Navigate to secops.bedrockcybersecurity.org → Changes → New Change
- Set title, description, and target firewalls
- Set status to Approved (Rory is the approver for all firewall changes)
- Note the CM ticket number for post-change update
This CM ticket suppresses false-positive security alerts during the change window — the SecurityAgent checks for an approved CM ticket before raising incidents related to config changes. Without it, automated config-diff alerts will fire as real incidents.
Step 3: Take a Pre-Change Backup
Before making any change, trigger an on-demand backup of the affected firewall(s) to establish a clean restore point:
- Navigate to the
ops-automationrepo in GitHub - Go to Actions → Palo Alto Config Backup (On-Demand)
- Run the workflow with the target firewall(s) selected
- Wait for completion and confirm the backup appears in the
palo-alto-configsrepo
For emergency changes where time is critical, proceed with the change immediately and trigger the backup retroactively as soon as the incident is contained.
Step 4: Implement the Change
Via Panorama (preferred for changes affecting multiple environments):
- Log into Panorama
- Navigate to the appropriate Device Group or Template Stack
- Make the change
- Preview the push — confirm only the intended devices are in scope
- Commit to Panorama
- Push to managed devices
Via local firewall management (environment-specific changes):
- Log into the firewall management UI via the mgmt zone
- Make the change under Policies → Security (or appropriate section)
- Review the candidate configuration before committing
- Commit the change
Step 5: Verify the Change
After committing, verify the intended behavior:
- For a new allow rule: confirm traffic is now passing where it was previously blocked (check traffic logs)
- For a new deny rule: confirm traffic is now blocked (check traffic logs for deny hits)
- For object changes: confirm rules referencing the object still behave as expected
Check the firewall traffic logs (Monitor → Logs → Traffic) filtered to the affected source/destination to confirm behavior.
Step 6: Document
The automated daily config backup will capture the change in the palo-alto-configs repo diff automatically. If the change detection alert fires, review it to confirm the diff matches the intended change.
For Normal and Emergency changes, complete the change record with:
- Actual implementation time
- Verification result
- Any deviations from the original plan
Update the SecOps CM ticket with the outcome:
- Navigate to the CM ticket created in Step 2
- Add a note with the verification result and config backup diff link
- Set status to Completed (or Rolled Back if the change was reverted)
Change Log Template
Maintain a running change log in the bedrock-docs repository or a shared location. Each entry:
Date: YYYY-MM-DD HH:MM UTC
Change type: Standard / Normal / Emergency
Firewall(s): Azure-Prod / Azure-Dashboard / DDE / AWS-DR
Description: [What was changed]
Justification: [Why the change was needed]
Rule/Object modified: [Specific policy name, address object, etc.]
Implemented by: [Name]
Reviewed by: [Name or "self-approved — Standard change"]
Verification: [How it was verified and result]
Rollback plan: [How to undo if needed]
Config backup diff: [GitHub commit link to palo-alto-configs diff]Special Considerations
DDE Customer-Facing Firewall
The DDE firewall handles live customer AVD sessions. Changes to this firewall carry higher blast radius risk — a misconfigured deny rule could disconnect customers from their sessions with no warning. Extra care:
- Test in a non-customer-impacting window where possible
- Review existing session table before committing to confirm active sessions
- Have rollback steps ready before implementing
- Notify customers if a maintenance window is likely to cause brief interruption
AWS DR Firewall
The AWS firewall has an outstanding FQDN DNS issue — cortex-xdr.paloaltonetworks.com does not resolve correctly, causing Cortex XDR traffic to hit the Containment deny rule. When making changes to the AWS firewall, be aware this is an open known issue and avoid changes that could interfere with its resolution.
Fix: Apply VPC resolver 10.99.0.2 as the DNS server via Panorama device template. See Palo Alto Firewall Overview for details.
Panorama-Managed vs. Locally-Managed Firewalls
Azure production and dashboard firewalls are locally managed (no Panorama). Changes to these must be made directly via their management interfaces. AWS and DDE (when Panorama connection is restored) are Panorama-managed — prefer Panorama for those to maintain centralized audit trail.
Compliance Relevance
| Requirement | How This Procedure Addresses It |
|---|---|
| HIPAA §164.308(a)(1) — Risk management | Structured review process reduces risk of misconfiguration |
| HIPAA §164.312(a) — Access control | All changes to access control policies are documented |
| SOC2 CC6.6 — Change management | Formal change process with pre/post documentation |
| SOC2 CC8.1 — Change control | Review and approval before significant changes |
The automated config backup provides an independent audit trail — every committed change generates a diff in the palo-alto-configs repo regardless of whether a change record was completed. This provides a safety net for compliance audit purposes.
Document History
| Date | Change | Author |
|---|---|---|
| March 2026 | Initial draft — formal change request procedure | Rory |
| April 2026 | Added pre-change backup step and SecOps CM ticket workflow | Kobe |