Palo Alto Networks NGFW / Panorama
Pulls security-policy rules, threat / Wildfire / traffic logs, and system health from PAN-OS to derive network-security KRIs for permissive rules, content hygiene, C2 beaconing signal, TLS-inspection coverage, firmware CVE exposure, and blocked-malware volume.
At a glance
| Vendor | Palo Alto Networks — works against a Panorama management server or a standalone NGFW firewall. Cloud-managed Prisma Access is a different integration. |
|---|---|
| Source type | network |
| Vendor ID (slug) | palo-alto-ngfw |
| Base URL | Per-tenant — https://<your-panorama>.company.com or the NGFW's management IP / hostname. No trailing slash or path. |
| Auth method | api-key — PAN-OS expects the API key as a URL query parameter (?key=...), not an Authorization header. The connector composes it on every call. The dispatcher's default Bearer header is harmlessly ignored by PAN-OS. |
| Schedule default | daily — the DNS-sinkhole and Wildfire KRIs are 24h rolling windows, so daily is the natural cadence. Override to hourly if you want tighter response on C2 signals. |
| Licensing | Core KRIs (any-any rules, content-age, software updates) work on any PAN-OS. Log-query KRIs (DNS sinkhole, Wildfire, SSL decrypt %) require Threat Prevention. Wildfire KRI specifically needs a Wildfire subscription. Tenants without those subs get 0 on the affected KRIs with a warn log. |
| Availability | New in 2026.04. |
Required scopes & roles
PAN-OS API keys inherit the role of the admin user they were minted for. For least privilege:
- Built-in: "Superuser (read-only)" — covers every op command, config read, and log query the connector issues. No write or commit capability.
- Custom role (tighter) — create an Admin Role Profile (Device → Admin Roles) with only:
- XML API: Enabled
- Operational Requests: Enabled (read-only op commands —
show system info,show running security-policy,request system software check) - Log: Read-only on threat, traffic, wildfire
- Config: Read-only
- Every other capability: Disabled (no commit, no CLI, no webUI, no reports-write)
Do not mint the API key under your personal admin account. PAN-OS API keys inherit the minting user's role permanently; a key minted from a Superuser account grants full configuration + commit reach if leaked.
Setup steps
- Create a dedicated service user. In the PAN-OS web UI, go to Device → Administrators → Add. Username:
draxis-connector. Authentication Profile: local password (long random). Administrator Type: Role Based, Profile: either superreader (built-in) or the custom role from the Required Scopes section. - Commit the change. PAN-OS admins require a commit before the new user can authenticate.
- Generate the API key by calling the keygen endpoint with the service user's credentials. From a shell with network access to the firewall:
Copy thecurl -sk -X GET \ 'https://<your-panorama>.company.com/api/?type=keygen&user=draxis-connector&password=<password>' \ | grep -oE '<key>[^<]+</key>'<key>value (long base64-ish string). The key value never changes for this user unless you regenerate it; rotating the password does NOT invalidate existing keys. To invalidate, go to Device → Administrators → draxis-connector → Expire API Key. - (Optional) Restrict by source IP. Device → Setup → Management → Permitted IP Addresses can lock the management interface to specific source IPs. Add the Draxis egress range after confirming the connector works.
- Verify you hit Panorama, not a bare firewall if you have both. Panorama gives aggregated data across all firewalls it manages — the KRIs reflect the whole fleet. A standalone NGFW gives you that single device's state. Pick the scope that matches your KRI question.
Wire it into Draxis
- Open Settings → Integrations in your tenant.
- Click Add integration and pick Network Security as the source type.
- Pick Palo Alto Networks NGFW / Panorama from the vendor dropdown. Draxis pre-fills the auth method and daily schedule.
- In API Base URL, paste your Panorama URL (e.g.
https://panorama.acme.com) or firewall management URL. No trailing path; the connector adds/api/?...itself. - In API Key / Token, paste the PAN-OS API key value from step 3. Draxis encrypts it server-side with
encryption.keybefore storage. - Click Test. Green means Draxis ran
show system infoand authenticated successfully. The message includes your device's PAN-OS version, family, and hostname. - Under KRIs to import, tick the KRIs you want Draxis to manage. All seven
panw_*KRIs are checked by default; uncheck the log-query KRIs (DNS sinkhole, SSL decrypt %, Wildfire) if you don't have Threat Prevention + Wildfire subscriptions (those would otherwise report 0, which could be misread as clean). Selected rows are created on save with the seeded thresholds. Unchecking a previously-imported KRI deletes it on save. - Save. The connector runs
dailyby default; use Run now from run history to trigger the first sync immediately.
KRIs produced
| Slug | Meaning | Derivation |
|---|---|---|
panw_high_risk_allowed_apps |
Security rules permitting risk-4/5 applications | show running security-policy → parse each rule; count rules where action=allow AND at least one application member has risk="4" or risk="5". |
panw_content_update_age_days |
Days since last threat-prevention content update | show system info → read threat-release-date (falls back to app-release-date), compute days from today. |
panw_any_any_rules |
Security rules with from=any, to=any, app=any, service=any | Same rule-dump as #1; count rules where all four match elements contain <member>any</member>. |
panw_dns_sinkhole_hits_24h |
Threat-log entries with action=sinkhole in the last 24h | Async log query: type=log&log-type=threat&query=(action eq sinkhole) and (receive_time geq '<now-24h>'). Count from <logs count="N">. |
panw_ssl_decrypt_pct |
% of TLS sessions decrypted (24h) | Two traffic-log counts: decrypted (flags has 'decrypt-ssl-yes') divided by total TLS (app contains 'ssl' OR dport eq 443). 100% if no TLS seen (nothing to measure). |
panw_software_updates_available |
PAN-OS versions available-but-not-installed | request system software check → parse <entry> blocks; count those with <downloaded>no</downloaded>. |
panw_wildfire_malware_24h |
Wildfire verdict=malware submissions in 24h | Async log query: type=log&log-type=wildfire&query=(verdict eq malware) and (receive_time geq '<now-24h>'). Count from <logs count="N">. |
Each row is a slug the connector writes to. Draxis creates the matching kri rows automatically when you check them in the KRIs to import section of the integration form — no manual API call or seed script needed. Thresholds shown in the table are the seeded defaults; you can edit them freely in the KRIs tab afterwards.
Vendor quirks
- API key lives in the URL, not in a header. PAN-OS predates Bearer auth conventions. The connector appends
?key=<token>to every request; the dispatcher's defaultAuthorization: Bearerheader goes out too but PAN-OS ignores it. No configuration needed; documented here because log lines include the URL (with the key redacted by PAN-OS-side logging, but still — avoid copy-pasting run summaries into public channels). - Log queries are asynchronous. PAN-OS's XML API for logs returns a job-id; you poll until the job finishes, then read the count. The connector polls up to 10 seconds per log KRI. Large log volumes or a heavily loaded firewall can push past that — in which case the KRI records 0 with a
log query timed outwarn. Re-run on a lightly loaded window to get real values. - Panorama vs. firewall scope. Pointing the connector at Panorama aggregates data across every managed firewall — usually what you want. Pointing at a single firewall gets you just that device. PAN-OS doesn't error either way; the values just reflect your chosen scope.
- High-risk app detection depends on policy metadata availability. The
show running security-policydump only includesrisk="N"attributes if the firewall has been asked to include application metadata in policy responses. This is typically on by default on PAN-OS 10.1+ but can be absent on older or custom-configured devices. If the KRI always reads 0 but you know you allow high-risk apps, check with your Palo Alto admin whether the policy dump is returning risk attributes. - Any-any detection is a structural match, not a behavioral one. A rule with explicit service-group "any-allowed" and zone members "corp-users → internet" is operationally identical to an any-any rule but doesn't match the filter. The KRI catches the literal shape, which is what policy reviewers actually hunt for — it's not meant to catch every overly-broad rule.
- Content-age uses PAN-OS's own timestamp. If the firewall's clock is wrong (rare but possible on lab devices), the age calculation is wrong too. This is also why we report age in days rather than a more granular unit — resolves any sub-day clock skew.
- Software-updates count is a proxy for CVE exposure. Palo Alto ships CVE fixes in new minor / patch releases. A firewall reporting 3 available updates is 3 releases behind the latest available on the update server — some of those releases likely fix published PSIRTs. A true CVE exposure count would cross-reference the firewall's current version against security.paloaltonetworks.com; that's a roadmap item.
- SSL decryption flag depends on policy configuration. PAN-OS logs
decrypt-ssl-yesin theflagsfield only when a decryption policy matches and succeeds. TLS sessions the firewall doesn't attempt to decrypt (no matching policy, or the session fell through to an undecrypted action) count in the denominator but not the numerator — which is exactly what the KRI measures. - Wildfire requires the Wildfire subscription. Without it, the firewall doesn't submit files, Wildfire log has no entries, and the KRI reports 0. This is a 0-because-no-data rather than 0-because-clean — uncheck the KRI if you don't license Wildfire, otherwise the dashboard reads as a false negative.
- API key rotation is manual. PAN-OS keys don't expire automatically. To rotate: generate a new key for the same user (the old key stays valid until you explicitly expire it), update Draxis, then click Expire API Key in the device UI. A brief overlap is safe.
- XML API vs REST API. PAN-OS 10.0+ offers a REST API (JSON) for config objects. The connector uses the XML API throughout because op commands and log queries are only available there — switching just the config calls to REST would split the codebase without adding value.
Troubleshooting
- Test returns 401 / "invalid credential" — API key is wrong, expired, or the service user was disabled. Regenerate the key with the keygen endpoint.
- Test returns
non-successwith a specificreason— the admin role is missing the XML API or Operational Requests permission. Check Device → Admin Roles profile for the service user. - HTTP 403 on log queries specifically — the role profile allows op commands but not log reads. Enable Log → threat/traffic/wildfire → Read on the profile.
panw_content_update_age_daysis 0 or a very large number — the PAN-OS version may not populatethreat-release-dateinshow system info. The connector falls back toapp-release-date; if both are missing, warns and records 0. Usually indicates an older PAN-OS (<10.1).- All log-query KRIs return 0 with
timed outwarns — the firewall is heavily loaded, or your role profile blocks log access. Schedule the connector todailyat an off-peak time, or check the role profile. panw_ssl_decrypt_pctis 100 but you know you don't decrypt — the denominator is zero (no TLS sessions seen in 24h). Either the firewall isn't seeing outbound TLS traffic (edge-case topology) or the log filter syntax needs tuning for your PAN-OS version. Open a support request with a sample traffic-log entry.rowsSkipped > 0androwsWritten = 0— your tenant hasn't imported any KRIs for this integration yet. Open the integration in Settings → Integrations, tick the KRIs under KRIs to import, and save.- Still stuck? Open a support ticket with the run ID (from Run history) and we'll dig in.