Manage Palo Alto PAN-OS firewalls and Panorama in Versus as inventory devices — discover them, snapshot their rulebases, provision security rules through a verified access-request pipeline, run staged PAN-OS upgrades, and reach private devices through outbound-only collectors.
Versus manages Palo Alto firewalls the same way it manages the rest of your estate — as devices in inventory. Once a PAN-OS firewall or a Panorama appliance is added, Versus can discover it, snapshot its rulebase, provision new security rules through a verified change pipeline, run staged software upgrades, and read rule hit counts — all with credentials held in the Versus Vault and all reachable through outbound-only collectors.
Two device kinds are supported:
| Kind | Vendor key | What it targets |
|---|---|---|
| Standalone firewall (direct) | paloalto_fw | A single PAN-OS firewall, changes written to a vsys |
| Panorama | panorama | A Panorama manager, changes written to a device-group |
Both speak PAN-OS's two APIs: the XML API (/api/) for operational commands and the REST API (/restapi/v10.1/) for structured policy objects. Versus uses whichever is appropriate for the task.
Every call authenticates with a PAN-OS API key. Versus obtains one by calling the keygen endpoint with the device's username and password, then reuses that key for the session:
key query parameter and run operational or config commands (for example <show><system><info>).X-PAN-KEY header and operate on policy and object endpoints such as Policies/SecurityRules and Objects/Addresses.Credentials come from the vault-backed device credential. If you have already minted a long-lived API key out of band, you can store it on the device instead (in the device's extra_config.api_key) and Versus will use it directly rather than calling keygen.
Reachability follows the platform's outbound-only model. When the firewall sits on a private segment, Versus routes the call through a collector at that site rather than connecting directly — see Reaching private firewalls below.
paloalto_fw (or panorama for a Panorama manager) and its management IP or hostname.Discovery issues two XML-API operational commands and normalizes the result:
<show><system><info></info></system></show>
<show><high-availability><all></all></high-availability></show>
From these Versus records the hostname, software version, and HA status — normalized to active, standby, or standalone. When HA is enabled it also captures the peer's hostname and management IP, so an HA pair is understood as a pair. A firewall has no virtual-server or pool objects to import, so discovery completes once this device metadata is synced.
For Panorama, the device-group that changes should target is held in the device's extra_config.device_group (defaulting to shared). For a standalone firewall, the target vsys defaults to vsys1.
The core of the integration is a verified access-request pipeline: an operator (or a ServiceNow change) asks for a flow to be permitted — sources, destinations, and services — and Versus works out what has to change, proves it is safe, waits for approval, and only then writes to the firewall. Every phase is recorded in a tamper-evident audit trail with before/after hashes.
An access request moves through these states:
SUBMITTED → PATH_RESOLVED → DESIGNED → VERIFIED → APPROVED → PROVISIONING → COMPLETED
with off-ramps to BLOCKED_TOPOLOGY, NO_CHANGE_REQUIRED, VERIFICATION_FAILED, ROLLED_BACK, and FAILED.
Versus computes which firewalls (policy-enforcement points, or PEPs) the requested flow actually traverses, using device zones and topology. If the path can't be resolved, the request is blocked with a reason rather than guessing.
Before designing anything, Versus makes sure it is reasoning against a current rulebase. It pulls the live security rules from each PEP over the REST API:
GET /restapi/v10.1/Policies/SecurityRules?location=vsys&vsys=vsys1
X-PAN-KEY: ••••••••
Each rule is normalized (name, source/destination zones and addresses, services, action, enabled flag, sequence) and stored as a snapshot. A staleness gate blocks the pipeline if a PEP has no snapshot or the snapshot is older than the allowed age — 24 hours by default, tunable via the fw_max_snapshot_age_hours system setting. This is deliberately fail-closed: Versus refuses to design a change on stale data.
For each PEP, Versus checks whether existing rules already permit the flow. If they do, that PEP is marked ALREADY_PERMITTED and left untouched. Otherwise Versus designs a candidate security rule as a PAN-OS REST payload:
{
"entry": {
"@name": "versus-<generated>",
"from": { "member": ["trust"] },
"to": { "member": ["untrust"] },
"source": { "member": ["10.1.0.0/24"] },
"destination": { "member": ["10.2.0.5"] },
"service": { "member": ["service-https"] },
"action": "allow"
}
}
If every PEP already permits the flow, the request short-circuits to NO_CHANGE_REQUIRED — nothing is written.
Each design is verified before it is allowed to proceed. If any check returns a hard block, the request lands in VERIFICATION_FAILED and no change is made. When a vulnerability scanner is connected, a scanner risk gate runs after policy verification and can veto the change based on the risk of the exposed hosts.
A VERIFIED request creates a ProvisioningJob and waits for a human. On approval, Versus runs a built-in workflow (fw-access-request-provision) with three sections:
| Section | What it does |
|---|---|
| 1 — Pre-Implementation | Pre-change device checks, then a config snapshot |
| 2 — Change Implementation | Provision the security rules |
| 3 — Post-Implementation | Post-change checks, then a snapshot comparison |
Provisioning posts each candidate rule to the firewall:
POST /restapi/v10.1/Policies/SecurityRules?location=vsys&vsys=vsys1&name=<rule>
On Panorama the same rule is written to the configured device-group and then activated with a commit-all push to that device-group; the returned Panorama job id is recorded in the audit trail.
After committing, Versus confirms the change actually took effect. It runs the PAN-OS policy-match test for a representative flow over the XML API:
<test><security-policy-match>
<source>10.1.0.10</source>
<destination>10.2.0.5</destination>
<protocol>6</protocol>
<destination-port>443</destination-port>
</security-policy-match></test>
If the device reports allow, the flow is realized. If any rule fails to provision mid-run, Versus rolls back every rule it already wrote — deleting them by name in reverse order — and moves the request to ROLLED_BACK, so a partial change never lingers.
When the request originated from a ServiceNow change, Versus writes progress back as work notes at each milestone (blocked, awaiting approval, completed, or rolled back).
Most firewalls aren't reachable from the cloud, and Versus never requires an inbound path to them. When a device is bound to a site, Versus dispatches the work to a collector running inside that network, which makes the actual API call and streams the result back.
The collector exposes a FirewallProvider/panos provider with a fixed catalog of named operations, so only vetted commands ever run against a device. These include:
panos.discover (keygen, system info, HA state).rest.ingest_rulebase, rest.resolve_objects, rest.provision_rule, rest.rollback_rule against the REST API.panos.system_info, panos.ha_all, panos.download_software, panos.install_software, panos.content_download_latest, panos.reboot, panos.suspend_ha, and others.Each XML command is built by the collector from a fixed template and its arguments are pattern-validated (version, job id, vsys, and rule name are all regex-checked) — request parameters are never interpolated into a command as free text. Device credentials can be resolved locally on the collector, so they never leave your network. For collector-managed devices the upgrade client opens a raw byte tunnel and performs keygen over it, targeting the device on the collector's LAN.
See Collector Security for how the outbound-only channel and credential handling work.
Versus ships built-in workflows for Palo Alto PAN-OS Upgrade and Palo Alto PAN-OS Backout (standalone firewalls; Panorama-managed upgrade is a separate path). The upgrade workflow handles the parts of a PAN-OS upgrade that are easy to get wrong:
You can drive these workflows from the UI or over the Workflow API — for example, running pre-checks as their own section and gating the install behind your own validation.
Every Palo Alto device page has a Backups card. Create Backup pulls the committed running configuration over the XML API (show config running) and stores it as an importable PAN-OS XML file; Inspect opens it, and Compare with… shows a line-by-line diff between any two backups — the fastest way to see what changed on a firewall since last night. The scheduled backup run and the upgrade workflows take the same backup. See Palo Alto Configuration Backups for the walkthrough with screenshots.
Versus can pull security-rule hit counts from a PAN-OS device over the XML API (show rule-hit-count), including cumulative hits and last-hit timestamps per rule. This feeds rule-usage review — surfacing shadowed, unused, or overly-broad rules — so the firewalls you manage in Versus are also the firewalls you can reason about and clean up.
Palo Alto is also a target for firewall rule migration: Versus can translate a normalized rulebase (from another vendor) into PAN-OS or Panorama security rules and address objects, rule by rule, as part of a migration plan.
Palo Alto integration reuses the same building blocks as the rest of Versus: