Cortex XSIAM

Cortex XSIAM

Overview

The Cortex XSIAM integration is currently under development.

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

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:

HEC Webhook Ingest

  • Client-provided HEC URL

  • Purpose: receive Guard vulnerability payloads from Guard

  • Notes: Guard will POST vulnerability data to this webhook endpoint; Cortex XSIAM is expected to normalize and transform the incoming Guard object

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

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

  • Accept and ingest Guard vulnerability payloads

  • Authenticate Guard's requests if the customer's HEC configuration requires authorization headers or tokens

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 HEC URL for outbound delivery from Guard

  • 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 HEC webhook

  • 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 HEC and the alert correlation logic used during reconciliation.

  • The outbound flow from Guard is expected to be write-only to the HEC webhook.

  • 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 HEC ingestion and normalization.