Skip to content
downpipes docs

Forward the downpipes audit trail to Cortex XSIAM

Cortex XSIAM (Palo Alto) receives the downpipes audit trail as an HTTP push; it does not poll a feed. You set up an HTTP collector on the Cortex side, which generates an ingestion URL and a token, then point the console push at that URL. On the scheduler tick the engine POSTs each batch of audit events to Cortex with the token in the Authorization header.

The one-time step is to create that collector: the HTTP Log Collector applet on a Broker VM, or the cloud Custom - HTTP Collector. Either issues the URL and token the engine posts to. There is no pull credential for this path, because Cortex is the receiver, not the poller.

Because the engine makes the outbound call, a Cloudflare Access perimeter on your console hostname never blocks this: there is no inbound request for Access to turn away.

What you need

  • A Cortex XSIAM account that can add an HTTP collector, either the HTTP Log Collector on a Broker VM or the cloud Custom - HTTP Collector.
  • Owner access to the downpipes console, and the ingestion URL and token that Cortex issues for that collector.

Set it up

  1. In Cortex XSIAM, add an HTTP collector: the HTTP Log Collector on a Broker VM, or the cloud Custom - HTTP Collector. Note the ingestion URL it generates and the token it issues.
  2. In the downpipes console, open Integrations, choose this vendor’s tile, and set up the SIEM audit push there (owner-only, asks for a fresh step-up sign-in).
  3. Set Delivery to HTTP endpoint, Format to JSON array (Elastic, Panther) or NDJSON (generic, one event per line) (pick whichever your collector is set to read), and paste the Cortex ingestion URL into Endpoint URL.
  4. Leave Auth header name as Authorization, and paste the Cortex token as the Auth secret. Enter the token exactly as the Cortex collector screen shows it, including any scheme prefix it expects; if in doubt, copy it verbatim from that screen rather than adding a prefix.
  5. Choose Test send. The engine posts one synthetic audit-shaped event to Cortex and reports the response. A test send never advances the delivery cursor. With the event visible in Cortex, choose Enable, and from the next tick the engine forwards every audit event above the cursor.

What lands in Cortex

The engine POSTs the raw audit events, either as a JSON array or one object per line for NDJSON. Each event looks like:

{"seq":4097,"ts":"2026-06-19T02:14:08.221Z","actorEmail":"ops@acme.example","actorMethod":"access","sourceIp":"203.0.113.7","action":"restore-approve","outcome":"success","target":{"kind":"restore","runId":"run_01H...","approverEmail":"lead@acme.example"},"prevHash":"sha384:11ab...90","hash":"sha384:22cd...01"}

Cortex parses the JSON on ingest, so the action, outcome, actorEmail and sourceIp fields are queryable without a mapping step on your side.

Good to know

  • Cortex receives, it does not poll. The token you paste is the one Cortex issued for its own HTTP collector, and the engine posts to Cortex on the scheduler tick, so there is no pull credential and no Access exemption to arrange for this path.
  • Delivery is at-least-once, not exactly-once. Every event carries a stable seq and a hash; dedup on either and a re-sent event lands as a duplicate you can drop rather than a second incident. The feed carries operator identity (member emails, source IPs, roles and approver emails) and no backup data or secret values, so apply your Cortex data-handling rules to it as you would any access log. For the shared push mechanics, see Forwarding the audit log to your SIEM.

Last updated .