Migrating from Splunk - tactical steps - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM Documentation

Cortex XSIAM
Creation date
Last date published
Administrator Guide

Steps for migrating Splunk

Preparation steps: Identify relevant data sources
Preparation steps: Identity and migrate relevant rules

XSIAM uses machine learning on four types of telemetry:endpoint, cloud, identity, and network sources to create high-fidelity and actionable incidents based off of baseline profiles that are built for the user, entity, peer group, and organization. The correlation rules that many have relied upon for years to protect their environments no longer catch modern threats so it is important to contemplate the following as you identify your existing detection rules.

SPL to XQL Comparison Table



Rule Type

  • Scheduled

    • Data Model Accelerated vs. Non Accelerated

  • Real Time

  • Risk Based Alerting

  • Scheduled

  • Real Time

  • Identity Analytics

  • BIOC



  • Define in SPL

  • Define in Risk Analysis adaptive response action

  • Define in XQL

Trigger Condition

  • Risk Threshold

  • Number of Results

  • Number of Hosts

  • Number of Sources

  • Custom

  • Risk Objects

  • Risk Threshold

  • Number of Results

  • Periodical Time


  • Add to Triggered Alerts

  • Log Event

  • Output Events to Lookup

  • Custom

  • Email Notification

  • Webhook (Ticketing)

  • Create Alert

  • Create Dataset

  • BIOC/ABIOC - Create Alerts Only

To migrate your analytics rules to Cortex XSIAM
  1. Verify that you have a testing system in place for each rule you want to migrate.

    • Prepare a validation process for your migrated rules, including full test scenarios and scripts.

    • Ensure that your team has useful resources to test your migrated rules.

    • Confirm that you have any required data sources connected, and review your data connection methods.

  2. Verify whether your detections are available as built-in BIOC Rules

    • If you have detections that aren't covered by the built in rules you can use the built in SPL to XQL Converter to get started: https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-Administrator-Guide/Translate-to-XQL

    • If neither the built-in rules nor an online rule converter is sufficient, you'll need to create the rule manually. In such cases, use the following steps to start creating your rule:

      1. Identify the data sources you want to use in your rule. Usually you will build rules from the datamodel

      2. Identify any attributes, fields, or entities in your data that you want to use in your rules.

      3. Identify your rule criteria and logic. Use the built in helpers and sample queries to see how XQL uses these in rule sets

      4. Identify the trigger condition and rule action, and then construct and review your XQL query. When reviewing your query, consider XQL optimization guidance resources.

  3. Test the rule with each of your relevant use cases. If it doesn't provide expected results, you may want to review the XQL and test it again.

  4. When you're satisfied, you can consider the rule to have been migrated. Create a playbook for your rule action as needed.

Preparation Steps: Understand the XSIAM Architecture


XSIAM Can ingest logs from many different sources and ALL components of the architecture are not necessarily needed for a working deployment of XSIAM. For example: if a smaller startup has MAC laptops, Okta Directory, and Google Workspaces, then the MAC agent and API data collections for Okta and Google are all that are necessary for a successful deployment of XSIAM. If customers have significant on premise logs and multiple locations then the Broker VM component would be needed for those log sources in addition to the agents and API log collections. The goal is to keep the architecture as simple as possible so that troubleshooting and maintenance can be kept to a minimum.