> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/response/soar/palo-alto-xsoar-xsiam-integration-rux.md).

# Palo Alto XSOAR-XSIAM Integration (RUX)

<p align="center">Events Detection Integration for Cortex XSOAR</p>

<p align="center">Integration Guide</p>

<p align="center">API v3.5 | Pack Version 1.0.0 | May 2026</p>

## Quick Start

The Vectra RUX Events Detection integration creates **one Cortex XSOAR incident per Vectra detection**, providing detection-level visibility while preserving the full context of the affected entity.

#### Deployment Checklist

1. Create a Vectra API Client with the **Security Analyst** role.
2. Install the **Vectra RUX Events Detection** content pack from the Marketplace.
3. Add a new integration instance in Cortex XSOAR.
4. Configure the Server URL, Client ID, and Client Secret Key.
5. Enable **Fetch Incidents**.
6. Configure mirroring as required.
7. Click **Test** and verify an `ok` response.
8. Save the integration instance.

#### Result

Each qualifying Vectra detection creates a dedicated XSOAR incident:

```
Vectra RUX Events Detection: <Category> — <Detection Type> — <Entity UID>
```

This model enables independent investigation, assignment, status tracking, ticket linkage, and lifecycle management for every detection.

## Overview & Methodology

#### Background

This guide covers the Vectra RUX Events Detection integration for Cortex XSOAR — a detection-centric approach that unlocks richer, more targeted automation compared to previous-generation integrations.

By structuring response workflows around individual detections rather than entities, analysts gain the ability to investigate and automate response actions against specific threat behaviors while retaining the full entity context that makes Vectra's attack signal intelligence valuable.

Detection-level incidents enable:

* Precise playbook targeting
* Independent lifecycle management
* Detection-level ticket linkage
* Fine-grained status tracking
* Better operational metrics
* More flexible automation workflows

Organizations migrating from entity-centric workflows typically find that many automation use cases become significantly easier to implement and maintain.

#### Architecture Overview

```
        Vectra Detection
               │
               ▼
      Events Detection API
               │
               ▼
         Fetch Incidents
               │
               ▼
         XSOAR Incident
               │
       ┌───────┴───────┐
       ▼               ▼
   Mirroring       Playbooks
       ▼               ▼
    Vectra      Ticketing Systems
```

The integration consumes detection events from the Vectra Events API and creates one XSOAR incident per detection. Mirroring keeps data synchronized between XSOAR and Vectra throughout the detection lifecycle.

#### The Entity-Centric Model (Previous Approach)

The previous Vectra integration created a single XSOAR incident per entity — a host or account — consolidating all detections associated with that entity into one record.

While this aligned closely with the Vectra platform's AI prioritization model, it introduced several operational challenges:

* A single incident could contain a large and growing collection of detections.
* Detections of different types and severities were grouped together.
* High-priority behaviors could become buried within lower-priority activity.
* Closing or updating the incident affected all associated detections.
* The incident lifecycle was tied to entity state rather than individual detection outcomes.

> **Note**
>
> The previous entity-centric integration (Vectra XDR) remains available in the Cortex XSOAR Marketplace and is currently in sustaining mode. It continues to receive maintenance updates and bug fixes but is no longer the primary focus for new feature development.

#### The Detection-Centric Hybrid Model (This Release)

This release (Vectra RUX) adopts a detection-centric model in which every Vectra detection generates its own XSOAR incident.

The objective is to provide detection-level visibility and control while preserving the broader entity context needed for effective investigations.

#### One Incident Per Detection

Every Vectra detection maps to exactly one XSOAR incident.

Each incident is scoped to a single observed threat behavior, allowing analysts and playbooks to operate on detections independently.

#### Entity Context Is Preserved

Every incident includes context about the source entity, including:

* Entity ID
* Entity Name
* Entity Type
* Importance
* Urgency Score
* Priority Status
* Assignment Information

Analysts never lose visibility into the affected asset.

#### Event-Driven Updates

Detections generate multiple events over their lifecycle.

The integration continuously updates incidents using the latest event data so that detection state, metadata, tags, and investigation status remain current.

#### Cross-Detection Correlation

Incidents can be linked through:

* Shared Entity ID
* Shared External Reference ID

This enables rapid navigation between related detections and investigations.

#### XSIAM Compatibility

The detection-centric model aligns naturally with XSIAM correlation workflows.

Multiple detections from Vectra and other security technologies can be correlated into a single XSIAM case while preserving the integrity of the original detection records.

> **Tip**
>
> Although more individual incidents are created under this model, investigations become significantly easier to manage. The previous entity-centric approach often resulted in a single incident containing many unrelated threat behaviors. The detection-centric approach allows each threat behavior to be tracked independently while preserving entity context.

> **Why "Hybrid"?**
>
> The model is described as *hybrid* because it combines detection-level granularity with entity-level context. Analysts gain the precision to investigate individual detections while retaining visibility into the overall risk posture of the affected entity.

#### The Vectra Events API and `change_type`

All incidents originate from the Vectra Events Detection API endpoint:

```
/api/v3.5/events/detections
```

The endpoint produces a continuous stream of events that describe state changes for individual detections.

Every event includes a `change_type` value.

#### change\_type = `new`

A new detection has been created.

All detection fields are populated for the first time.

#### change\_type = `append`

A new observation has been added to an existing detection.

Summary fields are updated with cumulative activity while event details reflect the new observation.

#### change\_type = `adjust`

A non-observation change has occurred.

Examples include:

* Urgency score changes
* Priority changes
* Tag modifications
* Group updates

#### change\_type = `investigation_status`

The investigation status has changed.

Examples include:

* Open
* Acknowledged
* Escalated
* Paused
* Closed
* Expired

#### change\_type = `state`

The detection has been closed or reopened.

This event ensures detection state remains synchronized between Vectra and XSOAR.

#### change\_type = `triage`

The triage state of the detection has changed.

Triage-related fields and investigation metadata are updated.

#### Event Merging Logic

During each mirror cycle, the integration performs two API lookups:

1. Latest activity event (`new` or `append`)
2. Latest state event (`adjust`, `state, triage`, or `investigation_status`)

When both events are present:

* The most recent event takes precedence for overlapping fields.
* String collections such as tags are merged and de-duplicated.
* A single consolidated view is written into the incident.

When only one event exists, that event alone is used.

The resulting data is applied through the Incoming Mapper, and the incident's `change_type` field reflects the most recent processed event.

#### Incident Creation and the Fetch Cycle

The `fetch-incidents` process continuously polls the Events Detection API.

Each unique `detection_id` creates a new XSOAR incident if that detection has not previously been fetched.

Organizations can control which detections generate incidents:

#### All Detections

Leave both filtering options disabled.

All qualifying detections are imported.

#### Prioritized Detections Only

Enable:

`Create Incidents for Prioritized Detections`

Only detections associated with prioritized entities are imported.

#### Escalated Detections Only

Enable:

`Create Incidents for Escalated Detections`

Only detections whose investigation status is set to Escalated are imported.

#### Prioritized OR Escalated

Enable both options.

Incidents are created whenever either condition is true.

> **Warning**
>
> The Prioritized and Escalated filters operate as **OR logic**, not **AND logic**.
>
> If both options are enabled, detections matching either condition are imported.

#### Incident Naming Convention

Incidents are created using the following format:

```
Vectra RUX Events Detection: <Category> — <Detection Type> — <Entity UID>
```

This naming convention provides immediate visibility into the detection category, behavior type, and affected asset.

## Implementation

This section covers the initial configuration of the integration instance. It assumes the Vectra RUX content pack has already been installed in Cortex XSOAR.

<figure><img src="/files/G80icAMX1Es0GGrXkLOG" alt="" width="246"><figcaption></figcaption></figure>

#### Prerequisites

Before configuring the integration, ensure the following requirements are met:

* Cortex XSOAR 6.10 or later.
* A reachable Vectra platform accessible via HTTPS.
* A Vectra API Client configured with the **Security Analyst** role.
* The API Client's **Client ID** and **Client Secret Key**.
* Network connectivity from the XSOAR server to the Vectra platform.
* Firewall rules permitting outbound HTTPS connections.

#### Creating an API Client

API credentials are created within the Vectra platform:

```
Configuration → Access → API Clients
```

Create a new API Client and assign the **Security Analyst** role.

Record the generated:

* Client ID
* Client Secret Key

These values will be required during integration configuration.

#### Creating the Integration Instance

Navigate to:

```
Settings → Integrations → Instances
```

Search for **Vectra RUX - Network Detection & Response (Partner Contribution)** and click **Add Instance**.

The integration settings are grouped below by function, not by the order presented in the user interface.

#### Recommended Configuration

Most deployments should begin with the following settings:

<table><thead><tr><th width="386.07421875">Setting</th><th>Recommended Value</th></tr></thead><tbody><tr><td>Fetch Incidents</td><td>Enabled</td></tr><tr><td>Max Fetch</td><td>50</td></tr><tr><td>Entity Types</td><td>Host and Account</td></tr><tr><td>Mirroring Direction</td><td>Incoming and Outgoing</td></tr><tr><td>Open Detection on Incident Reopen</td><td>Enabled</td></tr><tr><td>Close Detection on Incident Closure</td><td>Enabled</td></tr><tr><td>Detection Status for Incident Reopen</td><td>Escalated</td></tr><tr><td>Detection Close Reason for Incident Closure</td><td>Remediated</td></tr></tbody></table>

These values provide full bidirectional synchronization while limiting fetch volume to a manageable level.

#### Connection Settings

These settings control authentication and connectivity to the Vectra platform.

<table><thead><tr><th width="244.88671875">Setting</th><th width="112.2890625">Required</th><th>Description</th></tr></thead><tbody><tr><td>Server URL</td><td>Yes</td><td>Base URL of the Vectra platform (for example: <code>https://tenant.portal.vectra.ai</code>). Do not include a trailing slash.</td></tr><tr><td>Client ID</td><td>Yes</td><td>OAuth2 Client ID associated with a Security Analyst API Client.</td></tr><tr><td>Client Secret Key</td><td>Yes</td><td>OAuth2 Client Secret Key associated with the Client ID.</td></tr><tr><td>Trust Any Certificate</td><td>No</td><td>Disables SSL certificate validation. Recommended only for lab or troubleshooting purposes.</td></tr><tr><td>Use System Proxy Settings</td><td>No</td><td>Routes API requests through the XSOAR system proxy if configured.</td></tr></tbody></table>

#### Fetch Settings

These settings control incident creation behavior.

<table><thead><tr><th width="359.30078125">Setting</th><th>Description</th></tr></thead><tbody><tr><td>Fetch Incidents</td><td>Enables incident creation from Vectra detection events.</td></tr><tr><td>Max Fetch</td><td>Maximum number of events retrieved per fetch cycle. Valid range: 1–200.</td></tr><tr><td>First Fetch Time</td><td>Determines how far back to look during the initial fetch. Accepts relative values such as <code>1 hour</code> or <code>2 days</code>.</td></tr><tr><td>Entity Types</td><td>Controls which entity types generate incidents. Host, Account, or both.</td></tr><tr><td>Create Incidents for Prioritized Detections</td><td>Restricts incident creation to detections associated with prioritized entities.</td></tr><tr><td>Create Incidents for Escalated Detections</td><td>Restricts incident creation to detections whose investigation status is Escalated.</td></tr></tbody></table>

> **Warning**
>
> If both **Create Incidents for Prioritized Detections** and **Create Incidents for Escalated Detections** are enabled, the filters operate as **OR logic**, not **AND logic**.
>
> Incidents will be created for detections that are:
>
> * Prioritized
> * Escalated
> * Both Prioritized and Escalated

#### Mirroring Settings

These settings control synchronization between Cortex XSOAR and Vectra.

<table><thead><tr><th width="225.203125">Setting</th><th>Description</th></tr></thead><tbody><tr><td>Mirroring Direction</td><td>Controls whether changes flow from Vectra to XSOAR, XSOAR to Vectra, or both directions.</td></tr><tr><td>Mirror Tag for Notes</td><td>War Room entries containing this tag are synchronized back to Vectra as detection notes. Default: <code>note</code>.</td></tr></tbody></table>

#### Incoming Mirroring

Use Incoming Mirroring when Vectra is the authoritative source of truth.

Changes made in Vectra are synchronized into XSOAR, including:

* Detection metadata
* Investigation status
* Tags
* Entity context
* Detection notes
* Event summaries

Changes made in XSOAR are not written back to Vectra.

#### Outgoing Mirroring

Use Outgoing Mirroring when XSOAR is responsible for driving detection workflow actions.

Changes made in XSOAR are synchronized into Vectra, including:

* Investigation status updates
* Tag updates
* Detection notes
* External reference IDs
* Detection closure
* Detection reopening

Changes made in Vectra are not automatically reflected in XSOAR.

#### Incoming and Outgoing Mirroring (Recommended)

This mode enables full bidirectional synchronization.

Changes are synchronized in both directions and is the recommended production configuration.

> **Note**
>
> Mirroring settings only apply to incidents created after the integration configuration is saved.
>
> Existing incidents are not automatically enrolled in mirroring.

#### Incident Lifecycle Settings

These settings control how incident state changes affect Vectra detections.

<table><thead><tr><th width="300.34375">Setting</th><th>Description</th></tr></thead><tbody><tr><td>Open Detection on Incident Reopen</td><td>Automatically reopens the Vectra detection when the XSOAR incident is reopened.</td></tr><tr><td>Detection Status for Incident Reopen</td><td>Investigation status assigned to reopened detections. Options: Open or Escalated.</td></tr><tr><td>Close Detection on Incident Closure</td><td>Automatically closes the Vectra detection when the XSOAR incident is closed.</td></tr><tr><td>Detection Close Reason for Incident Closure</td><td>Close reason sent to Vectra. Options: Benign or Remediated.</td></tr></tbody></table>

#### Reopening Incidents

When an XSOAR incident is reopened and outbound mirroring is enabled:

1. The corresponding Vectra detection is reopened.
2. The configured Investigation Status is applied.
3. Subsequent mirroring resumes normally.

#### Closing Incidents

When an XSOAR incident is closed and outbound mirroring is enabled:

1. The corresponding Vectra detection is closed.
2. The configured close reason is applied.
3. Closing notes are synchronized to Vectra.
4. The incident and detection lifecycle remain aligned.

#### Incident Configuration

These settings control how incidents are created and mapped.

<table><thead><tr><th width="299.6015625">Setting</th><th>Recommended Value</th></tr></thead><tbody><tr><td>Incident Type</td><td>Vectra RUX Events Detection</td></tr><tr><td>Classifier</td><td>Leave blank</td></tr><tr><td>Mapper (Incoming)</td><td>Vectra RUX - Incoming Mapper</td></tr></tbody></table>

#### Incident Type

All incidents generated by this integration should use:

```
Vectra RUX Events Detection
```

#### Classifier

No classifier is required.

The integration assigns the incident type directly during incident creation.

Leave this field blank unless a custom deployment requires a specialized classifier.

#### Mapper (Incoming)

The integration ships with a built-in mapper:

```
Vectra RUX - Incoming Mapper
```

This mapper is responsible for:

* Initial incident population
* Incoming mirroring
* Field synchronization

Most deployments should use the default mapper without modification.

#### Custom Mappers

If field customization is required:

1. Duplicate the default mapper.
2. Modify the duplicate.
3. Reference the duplicate in the integration settings.

Custom mappers must preserve the following fields or mirroring will not function correctly:

* dbotMirrorDirection
* dbotMirrorId
* dbotMirrorInstance
* dbotMirrorTags

#### Testing the Connection

After completing the configuration:

1. Click **Test**.
2. Wait for the validation to complete.

A successful connection returns:

```
ok
```

#### Common Test Failures

#### Invalid Credentials

Symptoms:

* Authentication errors
* HTTP 401 responses

Resolution:

* Verify the Client ID.
* Verify the Client Secret Key.
* Confirm the API Client has the Security Analyst role.

#### Connectivity Issues

Symptoms:

* Timeouts
* Connection failures

Resolution:

* Verify the Server URL.
* Verify network connectivity.
* Verify firewall rules.

#### SSL Certificate Errors

Symptoms:

* Certificate validation failures

Resolution:

* Verify the certificate chain on the Vectra platform.
* Temporarily enable **Trust Any Certificate** to isolate SSL-related issues.
* Do not leave this setting enabled in production environments.

#### Deployment Validation Checklist

Before enabling the integration in production, verify:

* Test returns `ok`.
* Fetch Incidents is enabled.
* Correct Entity Types are selected.
* Mirroring direction matches operational requirements.
* Incident Type is set correctly.
* Incoming Mapper is configured.
* Max Fetch is appropriate for expected detection volume.
* Detection closure and reopening settings match organizational workflow.

## User Guide — Incident Layout

Each incident created by this integration uses the **Vectra RUX Events Detection** layout.

The layout is organized into two custom tabs:

<table><thead><tr><th width="199.734375">Tab</th><th>Purpose</th></tr></thead><tbody><tr><td>Incident Info</td><td>Incident management, timeline information, linking, and closure details</td></tr><tr><td>Events Detection Info</td><td>Detection details, entity context, assignments, notes, and investigation data</td></tr></tbody></table>

In addition to these custom tabs, standard XSOAR tabs remain available:

* War Room
* Work Plan
* Evidence Board
* Related Incidents
* Canvas

#### Incident Info Tab

The Incident Info tab provides a high-level summary of the incident alongside standard XSOAR management metadata.

#### Case Details Panel

The Case Details panel contains the primary incident metadata, including:

* Incident name
* Status
* Severity
* Owner
* Tags
* External references
* Standard XSOAR incident fields

This panel serves as the primary incident management view.

#### Timeline Information Panel

The Timeline Information panel provides visibility into the incident lifecycle.

<table><thead><tr><th width="200.49609375">Field</th><th>Description</th></tr></thead><tbody><tr><td>Created</td><td>Timestamp when the XSOAR incident was created</td></tr><tr><td>Occurred</td><td>Timestamp of the original detection event</td></tr><tr><td>Due Date</td><td>Configurable SLA due date</td></tr><tr><td>Last Updated</td><td>Timestamp of the most recent incident modification</td></tr><tr><td>Closed</td><td>Timestamp when the incident was closed</td></tr></tbody></table>

The panel also contains incident correlation buttons.

**Link Incidents for this Entity**

Searches XSOAR for open incidents that share the same Vectra Entity ID and links them together.

This allows analysts to quickly identify all active investigations involving the same host or account.

**Link Incidents for this External Reference ID**

Searches XSOAR for open incidents that share the same External Reference ID and links them together.

This is commonly used when multiple detections are associated with the same:

* Jira issue
* ServiceNow ticket
* Vectra MDR ticket
* External investigation

> **Note**
>
> These buttons link XSOAR incidents only. They do not represent all detections that may exist within the Vectra platform for the entity.

#### Closing Information Panel

The Closing Information panel records closure metadata.

<table><thead><tr><th width="199.41796875">Field</th><th>Description</th></tr></thead><tbody><tr><td>Closed Time</td><td>Timestamp when the incident was closed</td></tr><tr><td>Close Reason</td><td>XSOAR closure category selected by the analyst</td></tr><tr><td>Close Notes</td><td>Analyst-provided closure notes</td></tr></tbody></table>

When outbound mirroring is enabled, closure notes are synchronized back to the Vectra detection.

#### Linked Incidents Panel

Displays all incidents currently linked to the incident.

Typical columns include:

* XSOAR Incident ID
* Name
* Status
* Severity
* Detection ID
* Entity Priority Status
* Entity ID
* Entity Type

This panel provides rapid navigation between related investigations.

#### Events Detection Info Tab

The Events Detection Info tab contains the primary Vectra detection and entity information.

Unless otherwise noted, all data displayed in this tab is refreshed during incoming mirror cycles.

#### Detection Information Panel

The Detection Information panel contains the primary detection metadata.

Key information includes:

* Detection ID
* Detection URL
* Detection Type
* Detection Category
* MITRE ATT\&CK mappings
* Investigation Status
* External Reference ID
* Detection Tags
* Triage State
* Detection Close Reason

This panel is typically the starting point for investigation.

#### Entity Information Panel

The Entity Information panel provides context about the affected host or account.

Key information includes:

* Entity ID
* Entity Name
* Entity Type
* Entity URL
* Entity Importance
* Entity Urgency Score
* Entity Priority Status
* Entity UID
* Entity Privilege Category
* Entity IP Address

Entity urgency drives the XSOAR incident severity assigned during incident creation.

> **Important**
>
> Once an entity becomes prioritized in Vectra, all detections associated with that entity are treated as prioritized until the unresolved priority condition is cleared.
>
> A reduction in urgency score alone does not automatically remove unresolved priority status.

> **Note**
>
> Entity External Reference ID support exists within Vectra but display within the XSOAR incident layout is planned for a future release.

#### Entity Assignment Data Panel

Displays assignment information associated with the entity in the Vectra platform.

The panel contains the **Sync Entity Assignment** button.

Assignment fields include:

* Assigned To
* Assigned By
* Assigned Date
* Assignment ID
* Outcome
* Resolved By
* Resolved Date

**Sync Entity Assignment**

Retrieves the current assignment directly from the Vectra platform and populates the assignment fields displayed in the panel.

If no assignment exists, the assignment fields are cleared.

> **Note**
>
> Assignment information displayed in this panel reflects assignment within the Vectra platform only.
>
> If analyst ownership is managed through the XSOAR Owner field, this panel may be ignored.

> **Note**
>
> Assignment data is not automatically refreshed during mirror cycles.
>
> Use the Sync Entity Assignment button to retrieve the latest assignment information.

#### Event Summary Information Panel

The Event Summary Information panel displays cumulative activity associated with the detection.

Unlike observation-specific event fields, these values represent aggregate activity across the entire detection lifecycle.

Available information includes:

* IP addresses
* Domains
* Ports
* DNS values
* Accounts
* Hosts
* External targets
* Protocols

This panel is useful for understanding the overall scope of observed activity.

#### Detection Investigation Data Panel

The Detection Investigation Data panel contains information retrieved from the full detection record rather than the events stream.

The panel contains the **Sync Detection Summary and EDR Process Context** button.

**Sync Detection Summary and EDR Process Context**

Retrieves the full detection object from Vectra and updates:

* Detection Summary
* EDR Process Context information

This provides additional information not available through the Events API, including:

* Grouped session information
* Aggregated detection statistics
* Additional investigation context
* EDR telemetry

#### EDR Process Context Panel

When EDR integrations are available, Vectra may provide process-level telemetry associated with the detection.

The panel can display:

* Query Status
* Query Creation Time
* Investigation Links
* Query Links
* Error Messages
* Process Data

Process records typically include:

* Process Name
* Command Line
* Creation Time
* Account
* Process ID
* Parent Process ID
* SHA256 Hash
* MD5 Hash

> **Note**
>
> EDR Process Context data is only available when process telemetry exists for the detection.

#### Data Source Panel

Displays information about the sensor or integration that generated the detection.

Available fields include:

* Data Source Type
* Sensor Name
* Sensor ID

This information can be useful when troubleshooting detection origin or validating data collection coverage.

#### Destination Information Panels

Several panels provide information about destination entities associated with the detection.

**Destination Host Information**

Displays destination hosts observed during detection activity.

Typical values include:

* Host ID
* Host Name
* IP Address
* Importance
* Urgency Score
* Privilege Category
* Group Membership

**Destination Account Information**

Displays destination accounts associated with the detection.

Typical values include:

* Account ID
* Account Name
* Importance
* Urgency Score
* Privilege Category
* Group Membership

**Destination Domain Information**

Displays destination domains associated with the detection.

Typical values include:

* Domain
* DNS
* External Target

These panels are populated directly from the event payload.

#### Detection Notes Panel

The Detection Notes panel provides visibility into notes associated with the detection.

The panel contains the **Sync Detection Notes** button.

**Sync Detection Notes**

Retrieves notes directly from the Vectra platform using the detection ID.

Any notes not previously retrieved are added to the XSOAR War Room.

The integration maintains an internal note cache to prevent duplicate note creation.

Notes originating from outbound mirroring are automatically excluded from retrieval to prevent note loops.

> **Note**
>
> Detection notes are ultimately surfaced in the XSOAR War Room rather than stored as visible incident fields.

> **Tip**
>
> Use the Sync Detection Notes button whenever collaborative investigation is occurring between XSOAR analysts and Vectra MDR operators to ensure the latest notes are visible.

## Actions

This section documents all actions available in the integration, including both analyst-facing incident layout buttons and programmatic commands that can be executed from XSOAR playbooks or the War Room.

#### Action Types

The integration provides two categories of actions:

<table><thead><tr><th width="224.58984375">Action Type</th><th>Description</th></tr></thead><tbody><tr><td>Incident Layout Buttons</td><td>Analyst-driven actions executed directly from the incident layout</td></tr><tr><td>Integration Commands</td><td>Commands available to playbooks, automations, and the War Room</td></tr></tbody></table>

#### Incident Layout Buttons

The following buttons appear within the incident layout and can be executed by analysts during an investigation.

Each button executes one or more API operations against either Cortex XSOAR or the Vectra platform.

#### Link Incidents for this Entity

**Location**

```
Incident Info → Timeline Information
```

**Automation**

```
VectraRUXLinkEntityDetections
```

Searches XSOAR for all open incidents that:

* Share the same Vectra Entity ID
* Have a different Detection ID
* Are not closed
* Are not job-type incidents

Matching incidents are linked using the built-in XSOAR `linkIncidents` command.

This allows analysts to quickly identify all active investigations involving the same host or account.

> **Note**
>
> This operation links XSOAR incidents only.
>
> It does not represent every detection currently associated with the entity inside the Vectra platform.

#### Link Incidents for this External Reference ID

**Location**

```
Incident Info → Timeline Information
```

**Automation**

```
VectraRUXLinkTicketDetections
```

Searches XSOAR for all open incidents that:

* Share the same External Reference ID
* Have a different Detection ID

Matching incidents are linked together using `linkIncidents`.

Typical use cases include:

* Jira issues
* ServiceNow incidents
* Vectra MDR tickets
* Internal investigation identifiers

This button is useful when multiple detections belong to the same external investigation.

#### Sync Entity Assignment

**Location**

```
Events Detection Info → Entity Assignment Data
```

**Automation**

```
VectraRUXSyncEntityAssignment
```

Executes:

```
vectra-assignment-list
```

using the current incident's:

* Entity ID
* Entity Type

The most recent assignment record is retrieved and mapped into the Entity Assignment fields displayed in the layout.

If no assignment exists, the fields are cleared.

Typical use cases include:

* Verifying current ownership
* Refreshing assignment information after reassignment
* Validating assignment outcomes

> **Note**
>
> Assignment information is not automatically refreshed during mirror cycles.
>
> Use this button whenever assignment accuracy is important.

#### Sync Detection Summary and EDR Process Context

**Location**

```
Events Detection Info → Detection Investigation Data
```

**Automation**

```
VectraRUXSyncDetectionSummary
```

Executes:

```
vectra-detection-describe
```

using the current Detection ID.

The automation:

* Retrieves the full detection object
* Updates the Detection Summary
* Populates EDR Process Context data when available

This provides richer investigation data than is available through the Events API alone.

Additional information may include:

* Grouped session details
* Aggregated detection statistics
* Investigation metadata
* EDR telemetry

#### Sync Detection Notes

**Location**

```
Events Detection Info → Detection Notes
```

**Automation**

```
VectraRUXSyncDetectionNotes
```

Executes:

```
vectra-detection-note-list
```

using the current Detection ID.

Retrieved notes are compared against the internal note cache.

Previously unseen notes are added to the XSOAR War Room as Note entries.

Notes containing:

```
[Mirrored From XSOAR]
```

are automatically excluded to prevent note loops.

The internal note cache is updated after each execution.

> **Tip**
>
> This button is particularly useful when collaboration is occurring between XSOAR analysts and Vectra MDR operators.

## Integration Commands

The integration exposes a comprehensive command set for use within:

* Playbooks
* Automations
* Scripts
* The War Room

All commands require a configured Vectra RUX Events Detection integration instance.

### Detection Commands

Detection commands operate on individual detections and are the primary commands used in playbooks and investigations.

<table><thead><tr><th width="299.9296875">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-detection-list</code></td><td>Returns detections matching the specified filters.</td></tr><tr><td><code>vectra-detections-mark-asclosed</code></td><td>Closes one or more detections using the specified close reason.</td></tr><tr><td><code>vectra-detections-mark-asopen</code></td><td>Reopens one or more previously closed detections.</td></tr><tr><td><code>vectra-detection-describe</code></td><td>Retrieves the full detection record, including summary and EDR context where available.</td></tr><tr><td><code>vectra-detection-pcap-download</code></td><td>Downloads the PCAP associated with a detection and attaches it to the incident.</td></tr><tr><td><code>vectra-detection-investigation-status-update</code></td><td>Updates the investigation status of one or more detections.</td></tr><tr><td><code>vectra-detection-external-id-update</code></td><td>Updates the external reference ID associated with one or more detections.</td></tr><tr><td><code>vectra-detection-tag-list</code></td><td>Returns tags associated with a detection.</td></tr><tr><td><code>vectra-detection-tag-add</code></td><td>Adds one or more tags to a detection.</td></tr><tr><td><code>vectra-detection-tag-remove</code></td><td>Removes one or more tags from a detection.</td></tr><tr><td><code>vectra-detection-note-list</code></td><td>Returns notes associated with a detection.</td></tr><tr><td><code>vectra-detection-note-add</code></td><td>Adds a note to a detection.</td></tr><tr><td><code>vectra-detection-note-update</code></td><td>Updates an existing detection note.</td></tr><tr><td><code>vectra-detection-note-remove</code></td><td>Removes a detection note.</td></tr></tbody></table>

### Entity Commands

Entity commands operate on hosts and accounts within the Vectra platform.

<table><thead><tr><th width="299.83203125">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-entity-list</code></td><td>Returns entities matching the specified filters.</td></tr><tr><td><code>vectra-entity-describe</code></td><td>Retrieves the full entity record.</td></tr><tr><td><code>vectra-entity-detection-list</code></td><td>Returns detections associated with an entity.</td></tr><tr><td><code>vectra-entity-external-id-update</code></td><td>Updates the external reference ID associated with an entity.</td></tr><tr><td><code>vectra-entity-unresolved-priority-reset</code></td><td>Clears unresolved priority status for eligible entities.</td></tr><tr><td><code>vectra-entity-note-add</code></td><td>Adds a note to an entity.</td></tr><tr><td><code>vectra-entity-note-update</code></td><td>Updates an existing entity note.</td></tr><tr><td><code>vectra-entity-note-remove</code></td><td>Removes an entity note.</td></tr><tr><td><code>vectra-entity-note-list</code></td><td>Returns notes associated with an entity.</td></tr><tr><td><code>vectra-entity-tag-add</code></td><td>Adds one or more tags to an entity.</td></tr><tr><td><code>vectra-entity-tag-remove</code></td><td>Removes one or more tags from an entity.</td></tr><tr><td><code>vectra-entity-tag-list</code></td><td>Returns tags associated with an entity.</td></tr><tr><td><code>vectra-entity-detections-mark-asclosed</code></td><td>Closes all active detections associated with an entity.</td></tr></tbody></table>

### Assignment Commands

Assignment commands manage entity ownership and assignment workflows.

<table><thead><tr><th width="298.05078125">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-assignment-list</code></td><td>Returns assignment records matching the specified filters.</td></tr><tr><td><code>vectra-entity-assignment-add</code></td><td>Creates a new assignment for an entity.</td></tr><tr><td><code>vectra-entity-assignment-update</code></td><td>Reassigns an existing assignment to a different user.</td></tr></tbody></table>

### Group Commands

Group commands manage entity membership within Vectra groups.

<table><thead><tr><th width="300.31640625">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-group-list</code></td><td>Returns groups defined in the Vectra platform.</td></tr><tr><td><code>vectra-group-assign</code></td><td>Assigns members to a group.</td></tr><tr><td><code>vectra-group-unassign</code></td><td>Removes members from a group.</td></tr></tbody></table>

### User Commands

User commands provide access to Vectra user information.

<table><thead><tr><th width="300.19921875">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-user-list</code></td><td>Returns Vectra platform users and associated metadata.</td></tr></tbody></table>

### Investigation Commands

Investigation commands provide access to the Vectra Investigation Query service.

<table><thead><tr><th width="299.84765625">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>vectra-investigation-query-send</code></td><td>Submits an investigation query and returns a request ID.</td></tr><tr><td><code>vectra-investigation-result-get</code></td><td>Retrieves the results of a previously submitted investigation query.</td></tr></tbody></table>

> **Note**
>
> All command required and available parameters are documented in **Appendix A — Command Reference.**
>
> Most analysts will only need the descriptions in this section. The appendix provides the complete parameter reference for playbook developers and administrators.

## Best Practices

This section provides operational guidance and recommended usage patterns for the Vectra RUX Events Detection integration.

While every organization operates differently, the practices described here have proven effective for maintaining a clean detection workflow and maximizing the value of the detection-centric incident model.

#### Analyst Actions vs Automation Actions

One of the strengths of the integration is that many detection attributes can be managed in two different ways:

1. Directly by an analyst through the incident layout.
2. Programmatically through integration commands and playbooks.

Both approaches ultimately update the same underlying Vectra detection object.

<table><thead><tr><th width="177.0703125">Capability</th><th width="270.76953125">Incident Layout</th><th>Integration Command</th></tr></thead><tbody><tr><td>Investigation Status</td><td>Vectra RUX Investigation Status field</td><td><code>vectra-detection-investigation-status-update</code></td></tr><tr><td>External Reference ID</td><td>Vectra RUX External Reference ID field</td><td><code>vectra-detection-external-id-update</code></td></tr><tr><td>Detection Tags</td><td>Tags field</td><td><code>vectra-detection-tag-add</code> / <code>vectra-detection-tag-remove</code></td></tr><tr><td>Detection Notes</td><td>War Room note mirroring</td><td><code>vectra-detection-note-add</code> / <code>vectra-detection-note-update</code></td></tr><tr><td>Detection Closure</td><td>Standard XSOAR incident closure</td><td><code>vectra-detections-mark-asclosed</code></td></tr><tr><td>Detection Reopen</td><td>Standard XSOAR incident reopen</td><td><code>vectra-detections-mark-asopen</code></td></tr></tbody></table>

In general:

* Analysts should use the incident layout during normal investigations.
* Playbooks should use commands when actions need to be automated or applied in bulk.
* Both methods participate in the same mirroring workflow and ultimately update the same Vectra detection.

> **Note**
>
> The incident layout is not merely a display of Vectra data. Several fields are intentionally editable and can be used as an alternative to executing integration commands.

#### Using External Reference IDs

External Reference IDs are one of the most powerful capabilities exposed by the integration.

They allow detections and entities to be associated with records in XSOAR or other external systems such as:

* Jira
* ServiceNow
* Vectra MDR
* Internal case management platforms
* SIEM investigations

This creates a durable relationship between Vectra, Cortex XSOAR, and external workflow systems.

#### Detection External Reference ID

The Detection External Reference ID can be managed in either of the following ways:

* Directly through the **Vectra RUX External Reference ID** field in the incident layout.
* Programmatically using:

```
vectra-detection-external-id-update
```

Both approaches update the same value stored on the detection within the Vectra platform.

Common use cases include:

* Associating a detection with a Jira issue.
* Associating a detection with a ServiceNow incident.
* Associating a detection with a Vectra MDR ticket.
* Grouping multiple Vectra detections or XSOAR incidents under a common investigation identifier.

When multiple detections share the same External Reference ID, analysts can use:

```
Link Incidents for this External Reference ID
```

to quickly correlate them within XSOAR.

#### Entity External Reference ID

The Entity External Reference ID is managed using:

```
vectra-entity-external-id-update
```

This allows hosts and accounts to be associated with external investigations independently of any individual detection.

Potential use cases include:

* Associating a host with a long-running investigation.
* Associating a VIP asset with a tracking ticket.
* Reusing existing investigations when new detections are generated.

> **Note**
>
> Entity External Reference IDs are stored within Vectra today. Display of this value within the XSOAR incident layout is planned for a future release.

> **Recommendation**
>
> Establish a standardized naming convention before deploying at scale.
>
> Examples:
>
> * SOC-12345
> * INC-2026-00421
> * JIRA-4211
>
> Avoid free-form text values that may vary between analysts.

#### Investigation Status and Mirroring

The Vectra RUX Investigation Status field can be managed in either of the following ways:

* Directly through the incident layout.
* Programmatically using:

```
vectra-detection-investigation-status-update
```

Both approaches update the same underlying Vectra detection and participate in the mirroring process.

Changes made in either Vectra or XSOAR are synchronized during the next mirror cycle.

Supported values include:

* Open
* Acknowledged
* Escalated
* Paused
* Closed
* Expired

#### Typical Investigation Workflows

The Vectra RUX Investigation Status field supports multiple workflow paths depending on how the organization chooses to manage detections.

**Active Investigation Path**

Use this path when the detection requires analyst review and response.

```
Open
  ↓
Acknowledged
  ↓
Escalated
  ↓
Closed
```

* **Open** — Detection has been generated and awaits review.
* **Acknowledged** — An analyst has reviewed the detection and accepted ownership.
* **Escalated** — The detection requires active investigation or response.
* **Closed** — The detection has been resolved and the investigation is complete.

**Monitoring / Deferred Investigation Path**

Use this path when the detection has been reviewed but does not currently justify active investigation or no response is provided by external teams.

```
Open
  ↓
Acknowledged
  ↓
Paused
  ↓
Expired
  ↓
Closed
```

* **Open** — Detection has been generated and awaits review.
* **Acknowledged** — An analyst has reviewed the detection.
* **Paused** — The detection has been intentionally deferred, deprioritized or most commonly - there has been no response from external teams. No active investigation is currently planned.
* **Expired** — The detection has aged out within the Vectra platform without further investigation activity.
* **Closed** — The detection is formally closed through workflow automation or analyst action.

> **Note**
>
> `Expired` is a Vectra detection state indicating that the detection is no longer actively being investigated. Some organizations choose to leave detections in the Expired state indefinitely, while others implement an automation that periodically identifies expired detections and closes the associated XSOAR incidents.

> **Recommendation**
>
> If your workflow uses the Paused → Expired path, consider creating a scheduled XSOAR job that periodically reviews expired detections and automatically closes the corresponding incidents. This helps maintain a clean incident queue while preserving a clear audit trail of analyst decisions.

Status updates are useful for:

* Tracking analyst progress
* Driving workflow automation
* Coordinating with MDR teams
* Maintaining investigation consistency

> **Important**
>
> Do not set Investigation Status to **Closed** if your intent is to formally close the incident.
>
> Always use the standard XSOAR incident closure workflow.
>
> This ensures:
>
> * The detection is properly closed in Vectra
> * The configured close reason is applied
> * Closing notes are synchronized
> * Audit history is preserved

#### Closing Incidents

When an incident is closed in XSOAR and outbound mirroring is enabled, the following sequence occurs:

1. The XSOAR incident is closed.
2. The corresponding Vectra detection is closed.
3. The configured close reason is applied.
4. Closing notes are synchronized back to Vectra.

> **Recommendation**
>
> Analysts should generally close detections using the standard XSOAR incident closure workflow rather than executing:
>
> ```
> vectra-detections-mark-asclosed
> ```
>
> directly.
>
> The incident closure workflow ensures close reasons, notes, and synchronization behavior remain consistent.

#### Choosing a Close Reason

**Benign**

Use when:

* Activity is legitimate.
* Activity represents a false positive.
* No remediation was required.

**Remediated**

Use when:

* Malicious activity was identified.
* Corrective action was taken.
* Risk has been eliminated.

> **Important**
>
> The integration-level setting:
>
> ```
> Detection Close Reason for Incident Closure
> ```
>
> defines the default close reason applied when incidents are closed.
>
> If different close reasons are required for different workflows, use:
>
> ```
> vectra-detections-mark-asclosed
> ```
>
> within playbooks where the close reason can be explicitly specified.

#### Note Mirroring

Detection notes can be synchronized in both directions.

Notes can be created:

* Directly in Vectra.
* Directly through integration commands.
* Through the XSOAR War Room.

Commands available for note management include:

```
vectra-detection-note-add
vectra-detection-note-update
vectra-detection-note-remove
```

However, most analysts should use War Room notes and allow the mirroring framework to synchronize those notes automatically.

#### Inbound Synchronization

Notes created in Vectra are synchronized into the XSOAR War Room.

Two mechanisms exist:

**Automatic**

New notes are synchronized during incoming mirror cycles.

**Manual**

The analyst clicks:

```
Sync Detection Notes
```

to retrieve the latest notes immediately.

#### Outbound Synchronization

War Room entries tagged with the configured mirror tag are synchronized back to Vectra.

Default tag:

```
note
```

Notes synchronized from XSOAR receive the prefix:

```
[Mirrored From XSOAR]
```

to prevent synchronization loops.

#### Important Constraints

* Notes larger than 1,000 characters are not synchronized.
* Updates to existing XSOAR notes are not synchronized.
* Updates to existing Vectra notes create new War Room entries.
* Only newly created notes participate in synchronization.

#### Tag Management

Tags can be managed in either of the following ways:

* Directly through the incident Tags field.
* Programmatically using:

```
vectra-detection-tag-add
vectra-detection-tag-remove
```

Both approaches ultimately update the same detection tag collection stored within Vectra.

Manual tag management is generally preferred during investigations.

Command-based tag management is most commonly used within automation and enrichment playbooks.

#### Best Practices

* Establish a controlled tag vocabulary.
* Avoid analyst-specific tags.
* Avoid duplicate tags with slightly different spellings.
* Document approved tag values.
* User purpose-built fields such as investigation\_status or external\_reference\_id instead of notes or tags.

#### Tag Synchronization Behavior

Changes made in either platform are synchronized.

When XSOAR performs an outbound synchronization:

* The entire tag list is sent.
* Existing tags are replaced.

> **Warning**
>
> Removing all tags from an XSOAR incident causes all tags on the corresponding Vectra detection to be removed during outbound synchronization.

#### Expire Inactive Detections

Vectra detections that are not attended to may go inactive over time if the bevahior is no longer presenting. A playbook has been created to periodically look for inactive detections that belong to open incidents to set the investigation status to expired. This can assist with accurate metric collection and also provides the SOC Analyst with a clear indicator of alerts that can be closed.

Create a scheduled recurring job to automatically run this playbook:

1. In Cortex XSOAR, navigate to **Jobs** (via the top menu or sidebar).
2. Click **New Job**.
3. Select **Time triggered** and enable **Recurring**.\
   Set the schedule to **Every 24 hours** (or configure a specific daily time using a cron expression such as `0 0 * * *`).
4. Set the **Name** for the job (e.g., `Expire Inactive Detections - Daily`).
5. Under **Playbook**, select **Expire Inactive Detections - Vectra RUX**.
6. Click **Create new job** to activate the job.

#### Fetch Volume and Performance

In high-volume environments, proper fetch tuning is important.

#### Recommended Starting Configuration

<table><thead><tr><th width="200.23046875">Setting</th><th>Value</th></tr></thead><tbody><tr><td>Max Fetch</td><td>50</td></tr><tr><td>Entity Types</td><td>Host and Account</td></tr><tr><td>Mirroring</td><td>Incoming and Outgoing</td></tr></tbody></table>

#### Scaling Considerations

As detection volume increases:

* Increase Max Fetch gradually.
* Monitor incident processing time.
* Monitor XSOAR queue depth.
* Monitor playbook execution times.

#### Reducing Incident Volume

Several options exist for limiting incident creation:

* Prioritized Detections
* Escalated Detections
* Entity Type filtering
* Tag-based pre-processing

> **Tip**
>
> Most organizations should begin with Max Fetch set to 50 and adjust based on observed workload rather than immediately increasing limits.

#### Tag-Based Incident Filtering

In addition to the Prioritized and Escalated filters, XSOAR pre-processing rules provide a flexible alternative for controlling which detections generate incidents.

This approach is particularly useful when the desired filter criterion is a tag applied in Vectra (legacy approach) rather than a prioritization or escalation state (recommended approach).

#### Implementation Pattern

1. Ingest all detections.
2. Apply a pre-processing rule.
3. Create incidents only when a designated tag exists.

Example tag:

```
xsoar-escalate
```

#### Example Rule

<table><thead><tr><th width="215.0625">Field</th><th>Value</th></tr></thead><tbody><tr><td>Rule Name</td><td>Vectra RUX – Tag Filter</td></tr><tr><td>Condition</td><td>Incident Type = Vectra RUX Events Detection AND Tags contains xsoar-escalate</td></tr><tr><td>Action</td><td>Run Rule</td></tr></tbody></table>

Follow with a second rule:

<table><thead><tr><th width="214.97265625">Field</th><th>Value</th></tr></thead><tbody><tr><td>Rule Name</td><td>Vectra RUX – Drop Untagged</td></tr><tr><td>Condition</td><td>Incident Type = Vectra RUX Events Detection</td></tr><tr><td>Action</td><td>Drop and Close</td></tr></tbody></table>

This approach allows Vectra-side tagging to determine whether an incident should exist within XSOAR.

#### Recommended Analyst Workflow

Every SOC operates differently, but the workflow below provides a strong starting point.

#### 1. Take Ownership

Assign the incident to an analyst using the XSOAR Owner field.

If desired, synchronize the Vectra assignment using:

```
Sync Entity Assignment
```

#### 2. Acknowledge the Detection

Update the Investigation Status to:

```
Acknowledged
```

This signals active review.

#### 3. Identify Related Activity

Use:

```
Link Incidents for this Entity
```

to locate additional detections affecting the same entity.

If operating under a common ticket:

```
Link Incidents for this External Reference ID
```

#### 4. Review Detection Context

Review:

* Detection Information
* Entity Information
* Event Summary Information

Understand:

* Threat behavior
* Entity risk
* Network indicators
* MITRE ATT\&CK mappings

#### 5. Retrieve Additional Context

Execute:

```
Sync Detection Summary and EDR Process Context
```

to retrieve the full detection record.

#### 6. Pivot into Vectra

Use:

* Detection URL
* Entity URL

to investigate directly within the Vectra platform.

#### 7. Synchronize Notes

Use:

```
Sync Detection Notes
```

to retrieve the latest collaboration notes.

Document findings in the War Room.

#### 8. Run Investigation Queries

Advanced investigations can use:

```
vectra-investigation-query-send
```

and

```
vectra-investigation-result-get
```

to retrieve additional network telemetry.

#### 9. Close the Incident

Use the standard XSOAR incident closure workflow.

Confirm:

* Close Reason
* Closing Notes
* Detection disposition

The closure will automatically synchronize to Vectra.

## Troubleshooting

#### Test Fails

Verify:

* Server URL
* Client ID
* Client Secret Key
* API Client permissions
* Network connectivity

#### No Incidents Are Created

Verify:

* Fetch Incidents is enabled.
* First Fetch Time is appropriate.
* Detection filters are not excluding all events.
* The Events API is returning data.

#### Notes Are Not Synchronizing

Verify:

* Outgoing mirroring is enabled.
* Notes contain the configured mirror tag.
* Notes are under 1,000 characters.

#### Detection Does Not Close

Verify:

* Outgoing mirroring is enabled.
* Close Detection on Incident Closure is enabled.
* The detection remains active in Vectra.

#### Assignment Information Is Missing

Verify:

* The entity is assigned in Vectra.
* Sync Entity Assignment has been executed.

## Key Takeaways

* One XSOAR incident is created for each Vectra detection.
* Entity context is preserved across all incidents.
* Detection and entity data support bidirectional synchronization.
* External Reference IDs provide powerful ticketing integration capabilities.
* Notes, tags, status, and closures can be synchronized between platforms.
* Tag-based filtering provides a flexible mechanism for controlling incident creation.
* Detection-centric workflows enable significantly more granular automation than entity-centric incident models.

## Appendix A — Command Reference

The following appendix contains the complete command reference, including all supported parameters, requirements, and operational notes.

Commands are grouped by category:

* Detection Commands
* Entity Commands
* Assignment Commands
* Group Commands
* User Commands
* Investigation Commands

This appendix provides the complete reference for all integration commands.

Commands may be executed from:

* Cortex XSOAR playbooks
* Automation scripts
* The War Room

Commands that modify data within the Vectra platform are explicitly identified.

#### Detection Commands

#### vectra-detection-list

Returns detections matching the specified filters.

#### Parameters

<table><thead><tr><th width="204.7265625">Parameter</th><th width="109.70703125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>created_after</code></td><td>No</td><td>Filter by detections created on or after this time. Accepts relative (for example: <code>2 days</code>) or absolute (<code>yyyy-mm-ddTHH:MM:SSZ</code>) formats.</td></tr><tr><td><code>created_before</code></td><td>No</td><td>Filter by detections created on or before this time.</td></tr><tr><td><code>last_detected_after</code></td><td>No</td><td>Filter by detections last observed on or after this time.</td></tr><tr><td><code>last_detected_before</code></td><td>No</td><td>Filter by detections last observed on or before this time.</td></tr><tr><td><code>description</code></td><td>No</td><td>Filter by description containing the specified value.</td></tr><tr><td><code>detection_name</code></td><td>No</td><td>Filter by detection name.</td></tr><tr><td><code>detection_type</code></td><td>No</td><td>Filter by detection type.</td></tr><tr><td><code>detection_category</code></td><td>No</td><td>Filter by category: Command &#x26; Control, Botnet, Reconnaissance, Lateral Movement, Exfiltration, or Info.</td></tr><tr><td><code>include_info_category_detections</code></td><td>No</td><td>Include Info category detections. Default: <code>true</code>.</td></tr><tr><td><code>close_reason</code></td><td>No</td><td>Filter by close reason: <code>benign</code> or <code>remediated</code>.</td></tr><tr><td><code>detection_state</code></td><td>No</td><td>Filter by state: <code>active</code>, <code>inactive</code>, or <code>fixed</code>.</td></tr><tr><td><code>entity_type</code></td><td>No</td><td>Filter by entity type: <code>account</code> or <code>host</code>.</td></tr><tr><td><code>tags</code></td><td>No</td><td>Filter by detection tags. Comma-separated values supported.</td></tr><tr><td><code>is_triaged</code></td><td>No</td><td>Filter by triage status. Default: <code>false</code>.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number. Default: <code>1</code>.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page. Default: <code>50</code>.</td></tr></tbody></table>

#### vectra-detections-mark-asclosed

Marks one or more detections as closed.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="204.92578125">Parameter</th><th width="110.15234375">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_ids</code></td><td>Yes</td><td>Comma-separated list of detection IDs or a single detection ID.</td></tr><tr><td><code>close_reason</code></td><td>Yes</td><td>Close reason. Valid values: <code>benign</code>, <code>remediated</code>.</td></tr></tbody></table>

#### vectra-detections-mark-asopen

Reopens one or more previously closed detections.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="204.70703125">Parameter</th><th width="109.8671875">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_ids</code></td><td>Yes</td><td>Comma-separated list of detection IDs or a single detection ID.</td></tr></tbody></table>

#### vectra-detection-describe

Returns the full detection record, including summary information and EDR context where available.

#### Parameters

<table><thead><tr><th width="204.62109375">Parameter</th><th width="109.89453125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_ids</code></td><td>Yes</td><td>One or more detection IDs (comma-separated).</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number. Default: <code>1</code>.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page. Maximum: <code>5000</code>. Default: <code>50</code>.</td></tr></tbody></table>

#### vectra-detection-pcap-download

Downloads the PCAP associated with a detection and attaches it to the incident.

#### Parameters

<table><thead><tr><th width="205.3984375">Parameter</th><th width="109.90234375">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr></tbody></table>

#### vectra-detection-investigation-status-update

Updates the investigation status of one or more detections.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="204.515625">Parameter</th><th width="110.140625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_ids</code></td><td>Yes</td><td>Comma-separated list of detection IDs.</td></tr><tr><td><code>investigation_status</code></td><td>Yes</td><td>Valid values: <code>open</code>, <code>acknowledged</code>, <code>escalated</code>, <code>paused</code>, <code>closed</code>, <code>expired</code>.</td></tr></tbody></table>

#### vectra-detection-external-id-update

Updates the external reference ID associated with one or more detections.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="205.8203125">Parameter</th><th width="109.78515625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_ids</code></td><td>Yes</td><td>Comma-separated list of detection IDs.</td></tr><tr><td><code>external_reference_id</code></td><td>Yes</td><td>External reference identifier to assign.</td></tr></tbody></table>

#### vectra-detection-tag-list

Returns tags associated with a detection.

#### Parameters

<table><thead><tr><th width="204.703125">Parameter</th><th width="110.62109375">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr></tbody></table>

#### vectra-detection-tag-add

Adds one or more tags to a detection.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="205.2265625">Parameter</th><th width="109.55078125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr><tr><td><code>tags</code></td><td>Yes</td><td>Comma-separated tags to add.</td></tr></tbody></table>

#### vectra-detection-tag-remove

Removes one or more tags from a detection.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="205.3828125">Parameter</th><th width="109.828125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr><tr><td><code>tags</code></td><td>Yes</td><td>Comma-separated tags to remove.</td></tr></tbody></table>

#### vectra-detection-note-list

Returns notes associated with a detection.

#### Parameters

<table><thead><tr><th width="205.109375">Parameter</th><th width="109.58203125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr></tbody></table>

#### vectra-detection-note-add

Adds a note to a detection.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="205.046875">Parameter</th><th width="109.75390625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr><tr><td><code>note</code></td><td>Yes</td><td>Note content.</td></tr></tbody></table>

#### vectra-detection-note-update

Updates an existing detection note.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="205.15234375">Parameter</th><th width="110.05078125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr><tr><td><code>note_id</code></td><td>Yes</td><td>Note ID.</td></tr><tr><td><code>note</code></td><td>Yes</td><td>Updated note content.</td></tr></tbody></table>

#### vectra-detection-note-remove

Removes a detection note.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="204.5">Parameter</th><th width="110.2890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>detection_id</code></td><td>Yes</td><td>Detection ID.</td></tr><tr><td><code>note_id</code></td><td>Yes</td><td>Note ID.</td></tr></tbody></table>

#### Entity Commands

#### vectra-entity-list

Returns entities matching the specified filters.

#### Parameters

<table><thead><tr><th width="231.1171875">Parameter</th><th width="109.64453125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_type</code></td><td>No</td><td>Entity type: <code>account</code> or <code>host</code>.</td></tr><tr><td><code>prioritized</code></td><td>No</td><td>Return only prioritized entities.</td></tr><tr><td><code>name</code></td><td>No</td><td>Partial entity name match.</td></tr><tr><td><code>tags</code></td><td>No</td><td>Entity tags.</td></tr><tr><td><code>state</code></td><td>No</td><td>Entity state: <code>active</code> or <code>inactive</code>.</td></tr><tr><td><code>ordering</code></td><td>No</td><td>Sort order. Prefix with <code>-</code> for descending order.</td></tr><tr><td><code>last_detection_timestamp</code></td><td>No</td><td>Return entities active since this timestamp.</td></tr><tr><td><code>last_modified_timestamp</code></td><td>No</td><td>Return entities modified since this timestamp.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number. Default: <code>1</code>.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page. Maximum: <code>5000</code>. Default: <code>50</code>.</td></tr></tbody></table>

#### vectra-entity-describe

Returns the full entity record.

#### Parameters

<table><thead><tr><th width="204.984375">Parameter</th><th width="110.12890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>host</code> or <code>account</code>.</td></tr></tbody></table>

#### vectra-entity-detection-list

Returns detections associated with an entity.

#### Parameters

<table><thead><tr><th width="205.15625">Parameter</th><th width="110.69140625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>host</code> or <code>account</code>.</td></tr><tr><td><code>detection_category</code></td><td>No</td><td>Detection category filter.</td></tr><tr><td><code>detection_type</code></td><td>No</td><td>Detection type filter.</td></tr><tr><td><code>last_timestamp</code></td><td>No</td><td>Return detections active since this timestamp.</td></tr><tr><td><code>state</code></td><td>No</td><td>Detection state. Default: <code>active</code>.</td></tr><tr><td><code>tags</code></td><td>No</td><td>Detection tags.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page.</td></tr></tbody></table>

#### vectra-entity-external-id-update

Updates the external reference ID associated with an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="209.6953125">Parameter</th><th width="110.1328125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>host</code> or <code>account</code>.</td></tr><tr><td><code>external_reference_id</code></td><td>Yes</td><td>External reference identifier.</td></tr></tbody></table>

#### vectra-entity-unresolved-priority-reset

Clears unresolved priority status for eligible entities.

> **Warning**
>
> This command modifies data in the Vectra platform.

> **Note**
>
> Only entities below the current prioritization threshold can have unresolved priority cleared.

#### Parameters

<table><thead><tr><th width="200.44140625">Parameter</th><th width="110.40625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>host</code> or <code>account</code>.</td></tr></tbody></table>

#### vectra-entity-note-add

Adds a note to an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.265625">Parameter</th><th width="110.12890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>note</code></td><td>Yes</td><td>Note content.</td></tr></tbody></table>

#### vectra-entity-note-update

Updates an entity note.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.5546875">Parameter</th><th width="110.51171875">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>note_id</code></td><td>Yes</td><td>Note ID.</td></tr><tr><td><code>note</code></td><td>Yes</td><td>Updated note content.</td></tr></tbody></table>

#### vectra-entity-note-remove

Removes an entity note.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.3828125">Parameter</th><th width="109.62890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>note_id</code></td><td>Yes</td><td>Note ID.</td></tr></tbody></table>

#### vectra-entity-note-list

Returns notes associated with an entity.

#### Parameters

<table><thead><tr><th width="199.57421875">Parameter</th><th width="109.828125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page.</td></tr></tbody></table>

#### vectra-entity-tag-add

Adds tags to an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.359375">Parameter</th><th width="109.73046875">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>tags</code></td><td>Yes</td><td>Comma-separated tags.</td></tr></tbody></table>

#### vectra-entity-tag-remove

Removes tags from an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="199.6875">Parameter</th><th width="110.078125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>tags</code></td><td>Yes</td><td>Comma-separated tags.</td></tr></tbody></table>

#### vectra-entity-tag-list

Returns tags associated with an entity.

#### Parameters

<table><thead><tr><th width="200.7421875">Parameter</th><th width="109.94140625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr></tbody></table>

#### vectra-entity-detections-mark-asclosed

Closes all active detections associated with an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.421875">Parameter</th><th width="109.98828125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type.</td></tr><tr><td><code>close_reason</code></td><td>Yes</td><td>Valid values: <code>benign</code>, <code>remediated</code>.</td></tr></tbody></table>

#### Assignment Commands

#### vectra-assignment-list

Returns assignment records matching the specified filters.

#### Parameters

<table><thead><tr><th width="199.87109375">Parameter</th><th width="109.94140625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_ids</code></td><td>No</td><td>Comma-separated list of entity IDs.</td></tr><tr><td><code>entity_type</code></td><td>No</td><td>Filter by entity type: <code>account</code> or <code>host</code>.</td></tr><tr><td><code>resolved</code></td><td>No</td><td>Filter by resolution status. Valid values: <code>true</code>, <code>false</code>.</td></tr><tr><td><code>assignees</code></td><td>No</td><td>Comma-separated list of user IDs.</td></tr><tr><td><code>resolution</code></td><td>No</td><td>Comma-separated list of outcome IDs.</td></tr><tr><td><code>created_after</code></td><td>No</td><td>Return assignments created after the specified timestamp.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page.</td></tr></tbody></table>

#### vectra-entity-assignment-add

Creates a new assignment for an entity.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="199.75390625">Parameter</th><th width="109.890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>entity_id</code></td><td>Yes</td><td>Numeric entity ID.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>account</code> or <code>host</code>.</td></tr><tr><td><code>user_id</code></td><td>Yes</td><td>User ID of the assignee.</td></tr></tbody></table>

#### vectra-entity-assignment-update

Reassigns an existing assignment to a different user.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="199.9140625">Parameter</th><th width="110.92578125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>assignment_id</code></td><td>Yes</td><td>Assignment ID.</td></tr><tr><td><code>user_id</code></td><td>Yes</td><td>User ID of the new assignee.</td></tr></tbody></table>

#### Group Commands

#### vectra-group-list

Returns groups defined in the Vectra platform.

#### Parameters

<table><thead><tr><th width="199.73828125">Parameter</th><th width="109.39453125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>page</code></td><td>No</td><td>Page number.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page.</td></tr></tbody></table>

#### vectra-group-assign

Assigns one or more members to a group.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.49609375">Parameter</th><th width="99.95703125">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>group_id</code></td><td>Yes</td><td>Group ID.</td></tr><tr><td><code>entity_ids</code></td><td>Yes</td><td>Comma-separated list of entity IDs.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>account</code> or <code>host</code>.</td></tr></tbody></table>

#### vectra-group-unassign

Removes one or more entities from a group.

> **Warning**
>
> This command modifies data in the Vectra platform.

#### Parameters

<table><thead><tr><th width="200.02734375">Parameter</th><th width="109.3984375">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>group_id</code></td><td>Yes</td><td>Group ID.</td></tr><tr><td><code>entity_ids</code></td><td>Yes</td><td>Comma-separated list of entity IDs.</td></tr><tr><td><code>entity_type</code></td><td>Yes</td><td>Entity type: <code>account</code> or <code>host</code>.</td></tr></tbody></table>

#### User Commands

#### vectra-user-list

Returns Vectra platform users and associated metadata.

#### Parameters

<table><thead><tr><th width="200.63671875">Parameter</th><th width="109.890625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>username</code></td><td>No</td><td>Filter by username.</td></tr><tr><td><code>role</code></td><td>No</td><td>Filter by role. Valid values include: Admin, Read-Only, Restricted Admin, Security Analyst, Settings Admin, and Super Admin.</td></tr><tr><td><code>last_login_timestamp</code></td><td>No</td><td>Return users who logged in at or after the specified timestamp.</td></tr></tbody></table>

#### Investigation Commands

#### vectra-investigation-query-send

Submits an investigation query and returns a request ID that can later be used to retrieve results.

> **Warning**
>
> This command executes an investigation query against the Vectra platform.

#### Parameters

<table><thead><tr><th width="199.79296875">Parameter</th><th width="109.734375">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>query</code></td><td>Yes</td><td>Investigation query string.</td></tr><tr><td><code>version</code></td><td>No</td><td>Query language version. Example: <code>1.0</code>.</td></tr></tbody></table>

#### Example

```json
{
  "query": "SELECT timestamp, id.orig_h, id.resp_h, id.resp_p, orig_ip_bytes, resp_ip_bytes FROM network.isession._all WHERE timestamp > date_add('hour', -24, now()) AND local_orig = true AND local_resp = false ORDER BY timestamp DESC LIMIT 100",
  "version": "1.0"
}
```

#### Typical Workflow

1. Submit the query using:

```
vectra-investigation-query-send
```

2. Record the returned request ID.
3. Retrieve results using:

```
vectra-investigation-result-get
```

#### vectra-investigation-result-get

Retrieves the results of a previously submitted investigation query.

This command is typically executed repeatedly until all desired results have been retrieved.

#### Parameters

<table><thead><tr><th width="200.2265625">Parameter</th><th width="114.09765625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>id</code></td><td>Yes</td><td>Request ID returned by <code>vectra-investigation-query-send</code>.</td></tr><tr><td><code>page</code></td><td>No</td><td>Page number. Default: <code>1</code>.</td></tr><tr><td><code>page_size</code></td><td>No</td><td>Results per page. Default: <code>50</code>.</td></tr></tbody></table>

#### Typical Workflow

1. Submit an investigation query using:

```
vectra-investigation-query-send
```

2. Retrieve results using the returned request ID.
3. Continue paging through results until all records have been collected.

#### Appendix Summary

The Vectra RUX Events Detection integration exposes commands across six functional areas:

| Category               | Command Count |
| ---------------------- | ------------- |
| Detection Commands     | 14            |
| Entity Commands        | 13            |
| Assignment Commands    | 3             |
| Group Commands         | 3             |
| User Commands          | 1             |
| Investigation Commands | 2             |

Total Commands: **36**

Commands may be executed from:

* Cortex XSOAR playbooks
* Automation scripts
* Integration tasks
* The War Room

Commands identified as write operations modify data within the Vectra platform and should be used appropriately within automation workflows.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.vectra.ai/configuration/response/soar/palo-alto-xsoar-xsiam-integration-rux.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.