XSOAR Engineer key terms

The core record in Cortex XSOAR that holds an event's details, labels, custom fields, attachments, and linked evidence. Playbooks and automations run against it, and its lifecycle is tracked from creation to closure.

A configurable template that defines which fields, layouts, and default playbook apply to a category of incident, such as Phishing or Malware. Selecting a type at creation pre-populates the record's structure.

A named attribute on an incident record, either built-in or custom, that stores a value used for display, filtering, and automation logic. Custom fields are defined per incident type with a chosen data type.

The visual arrangement of fields, sections, and tabs shown when viewing or editing an incident. Layouts are bound to incident types so analysts see the most relevant information first.

A visual workflow of tasks, conditions, and scripts that automates incident handling. Tasks can branch on field values, run commands, pause for manual input, or call sub-playbooks, and each run is recorded as a playbook run.

A single node inside a playbook that performs one action, such as executing a command, running a script, evaluating a condition, or awaiting analyst input. Tasks have inputs, outputs, and optional timeouts.

A playbook task that evaluates an expression against incident or task context and routes execution down one of several branches. It is the primary mechanism for decision logic in automated workflows.

A playbook task that halts automated execution and waits for an analyst to complete an action or answer a question before the workflow continues. Useful for approvals and human judgment steps.

A playbook invoked from within another playbook, allowing reusable logic to be shared across workflows. Inputs and outputs are passed explicitly, and the parent waits for the child to finish.

The hierarchical data store, often called context, that holds outputs from commands and scripts during a playbook run. Values are referenced with dotted paths, and the context is merged back into the incident.

A dotted expression such as DBotFindings.Name or incident.labels that points to a specific value inside the context tree. Correct paths are essential when mapping command outputs to fields or task inputs.

The configuration that copies values from a command or script result into incident fields or context keys. Mapping turns raw integration output into structured data usable by later tasks and by analysts.

A configured connection to an external product, created from an integration pack and given credentials, server URL, and parameters. Multiple instances of the same integration can coexist for different tenants or environments.

A packaged connector that defines commands, configuration parameters, and code for talking to an external system. Integrations may be built-in, fetched from the marketplace, or custom-developed in Python or JavaScript.

A named operation exposed by an integration, such as ip or !domain, invoked from playbooks or the CLI. Each command declares arguments and returns outputs that populate context.

The command-line interface inside the XSOAR console where analysts run integration commands and built-in commands directly against an incident. It is the fastest way to test commands and inspect returned context.

A distributable bundle containing content such as integrations, scripts, playbooks, layouts, and incident types, with version metadata and dependencies. Packs are installed from the marketplace or uploaded as custom content.

A pack published to the marketplace that bundles related content for a product or use case. Installing a content pack brings in its integrations, playbooks, and dashboards together with dependency resolution.

The in-product catalog where packs of integrations, playbooks, and scripts are browsed, installed, and updated. It tracks installed versions and flags available updates or dependency conflicts.

Custom code, typically Python, that runs as a playbook task or CLI command and can read and write context. Scripts extend built-in behavior and are stored as versioned content items.

The container image that supplies the runtime and libraries for an integration or script. Choosing the correct image, and pinning its version, prevents dependency and compatibility failures during execution.

A separate host, often called a remote engine, that executes integration and script commands on behalf of the main server. Engines let you isolate load, reach segmented networks, and scale automation horizontally.

A deployment pattern where one XSOAR server hosts multiple isolated tenants, each with its own content, users, and data. It is common in managed security service provider environments.

The permission model that assigns roles to users and determines which incident types, fields, and actions they can access. Roles can restrict visibility by incident type or by field-level permissions.

The sequence of states an incident moves through, from creation and assignment through investigation, containment, and closure. Statuses and closing reasons are configurable and drive reporting.

A service-level agreement setting that defines time targets for incident response, such as time to first assignment or time to closure. Breaches are tracked and shown on dashboards for operational oversight.

A piece of observable threat data, such as an IP address, domain, file hash, or URL, stored with a reputation and relationships. Indicators link incidents to threat intelligence and drive enrichment decisions.

The classification of an indicator, such as IP, Domain, File, or URL, that determines its fields, reputation scale, and enrichment commands. Types control how indicators are extracted and displayed.

A numeric or categorical rating, often from Unknown to Bad, assigned to an indicator based on enrichment results. Playbooks use reputation thresholds to decide whether to block or escalate.

External and internal data about adversaries, campaigns, and observables that enriches incidents and indicators. Integrations pull this data from feeds and services to inform automated decisions.

The automated process of querying external sources for additional context about observables in an incident, such as reputation, geolocation, or related malware. Results are written to context and indicator records.

A rule that dynamically shows, hides, or requires fields based on values in the incident, such as incident type or severity. Rules keep forms relevant without creating many separate layouts.

A configurable view of widgets and charts summarizing incident, indicator, or automation metrics. Dashboards support operational monitoring and can be scoped to specific incident types or time ranges.

A record of user and system activity, including logins, configuration changes, and playbook actions. Audit logs support troubleshooting, compliance review, and investigation of unexpected behavior.

A single execution instance of a playbook against an incident, including task states, inputs, outputs, and errors. Reviewing a run is the primary method for debugging automation failures.

The per-incident view of playbook tasks showing which steps are complete, pending, or failed. It gives analysts a live checklist of automated and manual work still outstanding.

The collaboration area on an incident where analysts chat, run commands, and see playbook entries and evidence in one timeline. It serves as the shared workspace for investigation and response.

Files, emails, and other artifacts attached to an incident for review and analysis. Evidence can be extracted from integrations and referenced by playbook tasks during investigation.

The process that assigns an incoming incident to an incident type and maps its raw fields into the correct schema. It is typically handled by a pre-processing rule or a classifier playbook.

A rule evaluated before an incident is created that can drop, modify, or route incoming events. It reduces noise and ensures only relevant alerts reach analysts.