Cortex XSIAM

Cortex XSIAM

Overview

The Cortex XSIAM integration is currently under development.

This document captures the currently understood API access, permissions, and ingestion setup needed to integrate the Praetorian Guard Platform (PGP) with Palo Alto Cortex XSIAM.

For Palo Alto's HTTP collector setup and dataset behavior, see the Cortex XSIAM documentation: Set up an HTTP Log Collector to Receive Logs and Ingest NetFlow flow records as datasets.

Based on the current design, this integration is expected to work in two directions:

  1. Guard to Cortex XSIAM: Guard will send newly identified Guard vulnerabilities to a client-provided Cortex XSIAM HEC webhook URL.

  2. Cortex XSIAM to Guard: Guard will perform a recurring sync to identify Cortex XSIAM alerts that originated from Guard and have since been closed, so Guard can reflect that status.

At this stage, the expected behavior is that Guard will send Guard vulnerability objects to Cortex XSIAM, and Cortex XSIAM will normalize and transform the Guard payload into the alert schema it understands.

What the Integration Does

Guard to Cortex XSIAM

When a new Guard vulnerability is created or becomes eligible for export, Guard will:

  • POST the vulnerability payload to a client-provided HEC URL

  • Send the Guard vulnerability object for Cortex XSIAM-side normalization and transformation

  • Allow Cortex XSIAM to ingest the event as an alert or other mapped object based on the customer's XSIAM pipeline configuration

We currently expect this flow to be push-based and webhook-driven.

Cortex XSIAM to Guard

To keep Guard aligned with the downstream alert lifecycle in Cortex XSIAM, Guard will perform a daily sync of alerts previously sent from Guard.

During that sync, Guard will query Cortex XSIAM alerts and identify records that:

  • originated from Guard

  • were previously sent by the integration

  • are now in a closed state in Cortex XSIAM

Guard can then use that information to update the corresponding Guard vulnerability state accordingly.

API Endpoints Needed

The following Cortex XSIAM interfaces are currently expected to be required:

HTTP Log Collector / HEC Ingest

  • Client-provided HTTP log collector URL

  • Purpose: receive Guard vulnerability payloads from Guard

  • Guard will send data using JSON format only

  • Guard will send data uncompressed

  • Setup notes for Cortex XSIAM:

    • create an HTTP data source under Settings → Data Sources
    • set Compression to uncompressed
    • set Log Format to JSON
    • specify the Vendor and Product values for the dataset Guard will write into

  • Notes:

    • Guard will POST vulnerability data to this endpoint
    • Cortex XSIAM is expected to normalize and transform the incoming Guard object
    • Guard does not require gzip compression, multiline raw parsing, CEF, or LEEF support

Get Alerts

  • Endpoint: /public_api/v1/alerts/get_alerts

  • Purpose: retrieve alerts from Cortex XSIAM during Guard's daily sync to determine whether Guard-originated alerts have been closed

  • Notes: Guard will need to filter or correlate alerts so it only evaluates alerts created from Guard-sent vulnerability payloads

Required Permissions

Because this integration is still under development, the exact permission names may change once implementation and validation are complete. However, the Cortex XSIAM configuration will need enough access to perform the following operations:

For Guard to Cortex XSIAM

  • Create and manage an HTTP Log Collector in Cortex XSIAM

  • Receive HTTP POST requests at the customer-provided collector endpoint

  • Accept and ingest Guard vulnerability payloads in JSON format

  • Configure the collector for uncompressed delivery

  • Configure Vendor and Product values for the dataset Guard will write into

For Cortex XSIAM to Guard Sync

  • Read alerts via /public_api/v1/alerts/get_alerts

  • Access alert status fields needed to determine whether an alert is closed

  • Access sufficient metadata to correlate a Cortex XSIAM alert back to the originating Guard vulnerability

At a minimum, the integration will need:

  • a valid client-provided HTTP log collector URL for outbound delivery from Guard

  • a Cortex XSIAM collector configured for uncompressed JSON

  • API access sufficient to call /public_api/v1/alerts/get_alerts for inbound status reconciliation

Expected Data Handling

We currently expect the following high-level data flow:

  • Guard sends vulnerability payloads to Cortex XSIAM over the HTTP log collector endpoint

  • Cortex XSIAM transforms those payloads into its internal normalized format

  • Cortex XSIAM creates or updates alert records based on customer-side parsing and mapping

  • Guard later queries Cortex XSIAM alert data to detect which Guard-originated alerts have been closed

The exact correlation strategy is still to be finalized, but it will need a reliable way to associate a Cortex XSIAM alert with the original Guard vulnerability.

Notes

  • This integration is not yet finalized.

  • The final implementation may refine the payload shape sent to the HTTP collector and the alert correlation logic used during reconciliation.

  • The outbound flow from Guard is expected to be write-only to the HTTP collector endpoint.

  • The return sync from Cortex XSIAM is expected to be read-only and limited to alert status reconciliation.

  • The initial design assumption is that alerts are the Cortex XSIAM object type that Guard vulnerabilities will become after ingestion and normalization.