Vectra RUX Best Practices for Microsoft Sentinel CCF

This guide covers operational best practices for running the Vectra RUX integration with Microsoft Sentinel. It assumes the connector, analytics rules, workbook, and playbooks are already deployed and

Data & Queries

Use Parsers First

Always use the included parser functions for operational queries, workbooks, analytics rules, and hunting. Query the raw tables directly only when validating ingestion or troubleshooting a data transformation issue.

Parser	Use For
VectraRUXDetections	Detection investigation, analytics rules, hunting
VectraEntities	Entity scoring, assignment state, prioritization
VectraLockdown	Lockdown status and audit trail

Querying raw tables (Detections_Data_CCF_CL, Entities_Data_CCF_CL, Lockdown_Data_CCF_CL) directly bypasses normalization and field aliasing, which can produce inconsistent results in dashboards and rules.

Analytics Rules

Enable Both Analytics Rules

Enable both the host and account analytics rule templates. Two separate rules are required to ensure correct entity mapping within Sentinel — host detections map to hostname, account detections map to username. Running only one rule means incidents will not be created for one of the two entity types.

Connector Operations

Seed the Detections Checkpoint

When deploying, always provide a starting checkpoint value when configuring the Detections data stream. Omitting this value causes the connector to request all historical detection events from the beginning of the event log, which can result in a large ingestion backlog on the first poll that is difficult to recover from.

For guidance on determining the correct starting checkpoint value, see the Microsoft Sentinel SIEM Codeless Connector Framework (RUX) guide.

Monitor Connector Health

Enable Sentinel data connector health monitoring and review the SentinelHealth table regularly for ingestion errors, authentication failures, and polling gaps. The CCF connector does not use Azure Function Apps, so Function App alerts do not apply — use SentinelHealth as the authoritative health signal.

SentinelHealth
| where TimeGenerated > ago(24h)
| where SentinelResourceType == "Data connector"
| extend DestinationTable = tostring(ExtendedProperties.DestinationTable)
| where DestinationTable in (
    "Detections_Data_CCF_CL",
    "Entities_Data_CCF_CL",
    "Lockdown_Data_CCF_CL"
  )
| where Status != "Success"
| order by TimeGenerated desc

Incident Operations

The Vectra RUX integration creates Sentinel incidents from prioritized and escalated detections. The following practices describe how to manage those incidents effectively using the available playbooks and automation rules, and how SOC operations map to the Vectra metrics that measure investigation performance.

Understanding Vectra SOC Metrics

Vectra tracks two key performance metrics that are driven directly by how analysts interact with incidents. Understanding these metrics is essential for configuring automation rules correctly — the sequencing of playbook execution has a direct impact on metric accuracy.

Mean Time to Resolve (MTTR) measures the full alert lifecycle from the moment an entity is prioritized to the moment its detections are resolved. It captures everything: queue time, wait time, and active investigation. MTTR starts automatically in Vectra when the entity crosses the prioritization threshold and ends when detections are closed and the entity is deprioritized.

Mean Time to Investigate (MTTI) measures analyst efficiency — specifically, how long it takes to work and close an alert after someone actively picks it up. MTTI starts when the entity is assigned to an analyst or team member in Vectra, and ends at the same point as MTTR: when detections are resolved and the entity is deprioritized.

Metric	Timer Starts	Timer Ends
MTTR	Entity crosses prioritization threshold (automatic)	Detections resolved, entity deprioritized
MTTI	Entity assigned to analyst in Vectra	Detections resolved, entity deprioritized

The gap between MTTR and MTTI represents queue and wait time before the SOC picks up the alert. Keeping this gap small is a direct reflection of SOC responsiveness.

Important: Assignment must occur in Vectra — not just in Sentinel — for MTTI to be tracked. A Sentinel assignment has no effect on Vectra metrics. Use VectraAssignStaticUserToEntity via an automation rule to ensure assignment is recorded in Vectra promptly.

Recommended Incident Lifecycle

The following workflow describes the recommended automation rule configuration and analyst actions across the full incident lifecycle. Automation rules that require no analyst input are preferred; Teams-based interactive playbooks are reserved for cases where analyst judgment is explicitly required.

Stage 1 — Incident Created (New)

When a new incident is created, the timeline should be populated immediately and kept synchronized as new alert details are added throughout the investigation.

Action	Trigger	Playbook
Attach Detection Timeline Link	Incident created	VectraDetectionTimelineLink
Synchronize timeline as investigation progresses	New alert added to incident	VectraIncidentTimelineUpdate

The playbook VectraIncidentTimelineUpdate is not compatible with any Sentinel (Log Analytics) workspace that is connected to Microsoft Defender XDR. This is a limitation of Defender XDR and not something that can be supported in the playbook.

Stage 2 — Incident Accepted (New → Active)

When an analyst accepts the incident and moves it to Active, two automated actions should fire: acknowledging detections in Vectra and recording assignment. Both are critical — acknowledgment signals to Vectra that the SOC is actively working the alert, and assignment starts the MTTI timer.

Action	Trigger	Playbook
Assign entity to SOC team in Vectra — starts MTTI	Status changed to Active	VectraAssignStaticUserToEntity
Acknowledge all associated detections in Vectra	Status changed to Active	VectraSetDetectionStatus

Use VectraAssignStaticUserToEntity configured with a SOC team identity or queue account. This ensures MTTI begins at the moment the SOC accepts the incident rather than waiting for individual analyst assignment, giving a consistent and defensible start time for the metric. Configure VectraAssignStaticUserToEntity to execute before VectraSetDetectionStatus so that assignment is recorded before the acknowledgment state is written — this preserves the most accurate MTTI timestamp.

Configure automation rules to trigger on "status changed to Active" rather than "status is Active" to prevent repeated execution on subsequent incident updates.

Stage 3 — During Investigation (Active)

During active investigation, analysts may take the following actions manually from the incident. None of these require automation rules.

These are optional and are dependant on each specific environment. Environments that include external managed services (that perhaps has access to the Vectra UI but not the Sentinel instance) may benefit from context being written back to Vectra using these playbooks. Where possible however, only a single console should be the source of truth which in this case is the Sentinel interface.

Action	Playbook	Notes
Document initial assessment and findings	VectraAddNoteToEntity	Add a note when accepting the incident to record the analyst's initial read
Document per-detection findings	VectraAddNoteToDetections	Use for specific evidence or rationale tied to individual detections
Classify or tag the entity	VectraAddTagToEntity	Useful for cross-incident visibility in Vectra (e.g., in-investigation, escalated)
Collect network evidence	VectraDownloadPcapFileToStorage	Run early for network detections — PCAP availability is time-limited

Stage 4 — Incident Closed (Active → Closed)

When the analyst closes the Sentinel incident, an automation rule should fire to close the associated detection in Vectra. VectraSetDetectionStatus maps the Sentinel closure classification to the appropriate Vectra reason automatically, and closing detections deprioritizes the entity in Vectra — stopping both the MTTI and MTTR timers.

Action	Trigger	Playbook
Close all associated detections in Vectra	Status changed to Closed	VectraCloseDetectionsOnIncidentClose

Sentinel Classification	Vectra Detection Status
True Positive	Closed — Remediated
All other classifications	Closed — Benign

Closure should be driven by an automation rule rather than manual analyst action to ensure consistent metric capture across all incidents.

Reducing Queue Time (MTTR Gap)

Because MTTR includes all time from prioritization through closure — including queue time before any analyst picks up the alert — a large gap between incident creation and the New → Active transition will inflate MTTR without reflecting any active investigation work.

Consider creating a scheduled analytics rule or workbook view that surfaces incidents that have remained in New status beyond an acceptable threshold. This creates operational visibility into queue pressure without requiring changes to the automation model.

SecurityIncident
| where Status == "New"
| where TimeGenerated < ago(30m)
| where Title has "Vectra"
| project IncidentNumber, Title, TimeGenerated, Severity
| order by TimeGenerated asc

Recommended Automation Rule Summary

Trigger	Condition	Playbook	Purpose
Incident created	Applies to Vectra Analytics Rules	VectraDetectionTimelineLink	Clean and populate timeline at creation
Incident updated	Applies to Vectra Analytics Rules & New alert added to incident	VectraIncidentTimelineUpdate	Keep timeline synchronized throughout investigation
Incident updated	Applies to Vectra Analytics Rules & Status changed to Active	VectraAssignStaticUserToEntity VectraSetDetectionStatus	Record assignment in Vectra — starts MTTI (run first) Acknowledge detections in Vectra (run second)
Incident updated	Applies to Vectra Analytics Rules & Status changed to Closed	VectraCloseDetectionsOnIncidentClose	Close detections in Vectra — stops MTTI and MTTR