XSIAM Engineer key terms

A dedicated virtual appliance in Cortex XSIAM that mediates communication between the management plane and the log collection or agent components, buffering data so endpoints never talk to the console directly.

A hardened VM that receives syslog, SNMP, or file-based feeds from network and security devices, forwards them to the broker layer, and can be scaled horizontally to absorb ingestion volume.

Lightweight endpoint software installed on Windows, Linux, and macOS hosts that streams process, network, file, and identity telemetry to XSIAM and can execute response actions such as isolate or kill process.

The ordered stages a record passes through after arrival: reception, parsing and normalization, enrichment, indexing, and correlation, with each stage exposing its own health metrics and failure modes.

Mapping vendor-specific raw fields into the Cortex eXtended Data Model so that, for example, every firewall's source IP lands in the same canonical field and detections can be vendor-agnostic.

Configuration that extracts fields from raw log text using delimiters, regex, or JSON/CEL expressions and assigns them to XDM fields; a broken rule typically produces unparsed or partially mapped events.

A named, queryable store of normalized events of a given type, such as authentication or network traffic, addressed in XQL queries and governed by retention and indexing settings.

A platform-raised issue indicating a data problem such as a collector that stopped sending, a parsing failure spike, or a license quota breach, used to detect blind spots before they affect detection coverage.

Cortex Query Language, a pipelined query syntax used to search datasets, join event streams, and build scheduled or streaming queries that feed custom correlation rules and dashboards.

A multi-event detection that matches a sequence or aggregation of normalized events within a time window, such as five failed logins followed by a success from the same user.

A detection built from platform-provided or custom machine-learning and behavioral models rather than a hand-written signature, surfacing anomalies scored against a baseline of normal activity.

Techniques that model baseline behavior for users, hosts, or entities and flag statistically unusual activity, reducing reliance on static signatures and helping catch living-off-the-land techniques.

A numeric value accumulated on an entity such as a user or host when contributing issues fire, used to prioritize which alerts deserve analyst attention and to drive risk-based alerting thresholds.

The end-to-end management of a detection from authoring and testing through tuning, deployment, and retirement, including false-positive review and mapping to coverage frameworks.

A view of which adversary techniques existing detections address, used to find gaps in detection engineering and to justify new rules or data sources.

A visual, versioned workflow of tasks, conditions, and loops that automates investigation or response, triggered manually, by an issue, or on a schedule, and executed by the playbook engine.

The event that starts a playbook automatically, such as a new issue matching a query, an alert from a specific data source, or a scheduled time, evaluated before any task runs.

A configured connection to an external product using a content-pack integration, holding the server address, credentials, and fetch parameters that commands in playbooks and the CLI rely on.

A versioned, installable bundle from the marketplace that packages integrations, playbooks, scripts, layouts, and detection content, with dependencies that must be satisfied before installation.

A single executable step inside a playbook, such as running an integration command, a script, a conditional branch, or a manual input prompt, whose inputs and outputs are mapped to context.

Reusable automation code, commonly Python, run by the engine to transform data, parse artifacts, or perform logic that is awkward to express with playbook tasks alone.

The primary case object in XSIAM, aggregating correlated alerts and evidence about an incident, with severity, status, assignee, and linked playbooks driving the analyst workflow.

A single detection hit produced by a rule or analytics engine; many alerts can be grouped into one issue, and each carries raw evidence and the rule that generated it.

The investigation workspace for an issue, showing the timeline, involved entities, evidence, executed playbook tasks, and a chat-style log of analyst actions and automated results.

An observable such as an IP address, domain, file hash, or user account extracted from evidence and enriched against threat intelligence to judge whether it is malicious.

A subscription or uploaded source of indicators and context, such as vendor or open-source feeds, that XSIAM ingests to enrich observables and to support indicator-based detections.

Continuous discovery and assessment of an organization's externally exposed assets, domains, and services, feeding findings into XSIAM so unknown exposure can be prioritized and remediated.

The permission model that assigns users to roles scoped by object and action, optionally limited to specific resources or datasets, determining what they can view, edit, or respond to.

A restriction attached to a role or user that limits visibility and actions to defined resources, such as a subset of endpoints or a specific dataset, rather than the whole tenant.

A record of user and system actions in the platform, including configuration changes, logins, and playbook executions, used for compliance review and to investigate unexpected changes.

The dashboard and metric set showing whether each configured source is sending data, its last-seen time, volume trend, and parsing success rate, used to catch silent collection failures.

A response action that blocks a compromised host's network communication except for the management channel to the platform, containing the threat while preserving analyst access.

A named operation exposed by an integration, such as querying an endpoint or blocking a hash, which playbooks and the command line invoke with arguments and receive structured results from.

Detection logic focused on user and account behavior, including anomalous logins, privilege changes, and credential misuse, drawing on identity and authentication data sources.

The schema of normalized fields and entity types that all ingested data is mapped into, enabling cross-vendor queries, consistent detections, and reusable enrichment across sources.