XSIAM Engineer cheat sheet

XSIAM is a cloud-delivered SOC platform built on three planes: data ingestion/storage (the data lake), analytics (detection and correlation engines), and the case/response layer (incidents, playbooks, and the war room).

Deployment is tenant-based: each customer gets a dedicated cloud instance in a region (for example US, EU, or APAC), and data residency is determined by the region selected at provisioning time and cannot be changed after the fact without re-provisioning.

Agents and brokers form the collection tier: Cortex XDR agents on endpoints, Broker VM appliances for on-premises log collection and network sensors, and cloud-to-cloud API collectors for SaaS and cloud workloads.

The Broker VM is a customer-managed virtual appliance that proxies agent traffic, collects syslog and file-based logs, and hosts the local agent content cache; it must reach the XSIAM cloud over TCP 443.

Ingestion capacity is licensed by data volume (GB/day) and by endpoint count; exceeding the contracted ingestion rate causes throttling or dropped data rather than automatic overage billing.

High availability is provided by the cloud service itself; on-premises redundancy applies only to the Broker VM tier, where you deploy multiple brokers and configure HA clustering to avoid a single collection point of failure.

Content updates (analytics, parsers, and playbook packs) are delivered continuously by the cloud, so platform versioning is largely transparent to the customer, unlike on-premises SIEM upgrades.

Deployment order matters: provision the tenant, deploy and register brokers, install agents, onboard log sources, validate parsing, then enable detection rules and automation.

Ingestion paths include agent-collected endpoint telemetry, Broker VM syslog and file collection, cloud-to-cloud API integrations, and direct API ingestion; each path has its own latency and normalization behavior.

Every raw event is normalized into the XSIAM data model, which defines standard fields (for example actor, action, source IP, destination IP, and outcome) so that detections and the query language work consistently across vendors.

Parsers are vendor- and product-specific; a built-in parser exists for common sources, and custom parsers (often built on a parsing language with CIM mapping) are required for unsupported or proprietary formats.

The data model is the CIM equivalent: when a parser fails to map a field to the model, the event is still stored raw but becomes invisible to model-based detections and dashboards.

Dataset types determine retention and query behavior: endpoint telemetry, logs, and audit data have different default retention windows, and long-term storage may be queried but not used for real-time detection.

Broker VM collection supports syslog over UDP/TCP/TLS, and TLS with certificate validation is the recommended transport for any log crossing an untrusted network.

Deduplication and correlation keys are applied at ingestion; duplicate events from overlapping collection paths (for example agent and syslog from the same host) inflate volume and can distort detections.

Validate onboarding with a parsing test: send a known sample, confirm the raw event appears, then confirm the normalized fields populate correctly before enabling detections that depend on them.

Detections in XSIAM are expressed as correlation rules over normalized data, combining a query, a schedule or streaming trigger, and a severity; rule output creates alerts that are grouped into incidents.

Behavioral analytics and machine learning detections run alongside rule-based detections; ML detections require sufficient baseline telemetry (typically days to weeks) before they produce meaningful results.

The detection lifecycle is: hypothesis, data validation, rule authoring, tuning (suppression, exclusions, and thresholds), testing with synthetic or historical data, then promotion to production with a documented owner.

Alert grouping and incident creation rules determine how many alerts become one incident; tuning grouping reduces analyst fatigue more effectively than deleting detections.

MITRE ATT&CK mapping on detections enables coverage analysis; gaps in coverage are identified by comparing technique coverage against the threat model rather than by counting rules.

False positive management uses exclusions scoped narrowly (by user, host, or field value) and time-boxed where possible; broad exclusions silently disable detection coverage.

Threat hunting queries in the XSIAM query language can be saved and converted into scheduled detections, which is the standard path from ad hoc hunt to durable detection.

Detection content should be version-controlled and peer-reviewed; changes to production rules require a rollback plan because a bad rule can generate incident floods.

Playbooks are triggered by incident creation, alert creation, manual execution, or scheduled jobs; trigger type determines whether the playbook runs once per incident or once per alert.

Playbook tasks include commands, conditional branching, data collection, and sub-playbooks; sub-playbooks are the mechanism for reusable logic across multiple parent playbooks.

Integrations are configured as instances with credentials; the same integration can have multiple instances (for example two EDR tenants), and tasks must specify which instance to use.

Command output is stored in the context, and playbook logic references it through context paths; incorrect context paths are the most common cause of silent playbook task failures.

Automation can be scoped by role and by incident type; destructive actions (isolate host, disable user, block hash) should be gated behind approval tasks or conditional checks.

Playbook testing uses a sandbox or test incident with mocked inputs; running untested destructive automation in production is the primary cause of self-inflicted outages.

Timeout and retry settings on integration commands determine behavior when a third-party API is slow or unavailable; without them, playbooks hang and queue incidents.

Playbook performance is visible in task-level execution metrics; long-running or frequently failing tasks should be optimized or moved to asynchronous sub-playbooks.

Incidents aggregate related alerts and carry severity, status, owner, and a timeline; the war room holds the collaboration record, playbook runs, and evidence for each incident.

Incident fields and custom fields drive routing, SLA tracking, and reporting; field values set by playbooks must match the configured field schema or the update fails.

Threat intelligence is ingested as indicators (IP, domain, hash, URL) from feeds and integrated into detections; indicators have TTLs, and expired indicators stop matching unless refreshed.

Indicator scoring and confidence determine whether a match raises severity; low-confidence feed data should not automatically escalate incidents without corroboration.

Attack surface management discovers external-facing assets and exposures; findings are risk-scored and can be converted into incidents or remediation tasks.

Threat intelligence platform integrations allow indicator lookup during investigation and can enrich incidents automatically through playbook tasks.

Incident closure requires documented resolution and root cause; closure without disposition data degrades reporting and prevents detection tuning feedback loops.

SLA and severity definitions should be agreed with stakeholders before go-live; retrofitting SLAs after incidents accumulate creates misleading metrics.

RBAC in XSIAM is role-based and scoped: roles define permissions (view, investigate, respond, administer) and can be restricted by resource scope such as endpoint groups or datasets.

Least privilege applies to automation accounts as well as humans; integration instances should use dedicated service accounts with only the permissions their playbooks require.

Audit logs record administrative actions, logins, and configuration changes; they are the primary evidence source for investigating insider or credential misuse.

Common ingestion troubleshooting sequence: confirm the source is sending, confirm the broker receives, confirm the parser matches the vendor/product, then confirm normalized fields populate.

Agent troubleshooting checks connectivity to the broker or cloud over TCP 443, agent status in the console, content version, and whether the endpoint policy allows the required telemetry.

Playbook troubleshooting checks the trigger, the task input context paths, the integration instance health, and the task execution log for the specific error.

Detection troubleshooting distinguishes data problems (missing or unparsed events) from logic problems (query returns data but rule does not fire) by running the rule query manually against the same time window.

License and capacity monitoring tracks daily ingestion against contracted volume; sustained overage causes throttling, and the fix is either reducing noisy sources or expanding the license.