Vectra RUX Best Practices for Microsoft Sentinel CCF

Operate the Vectra AI integration with Microsoft Sentinel after deploying the connector, analytics rules, workbook, and playbooks.

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

For new deployments, 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 Vectra AI RUX Integration for Microsoft Sentinel 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.

kql

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 AI 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 alerts are added throughout the investigation.

Action	Trigger	Playbook
Populate and synchronize incident timeline	Incident created	VectraIncidentTimelineUpdate
Synchronize timeline as investigation progresses	New alert added to incident	VectraIncidentTimelineUpdate

VectraIncidentTimelineUpdate should run on both triggers. Without the second trigger, the timeline is only cleaned once at creation and becomes stale as Vectra detections update during the investigation.

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.

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
Close specific detections with a chosen reason	VectraCloseDetections	Use when granular per-detection control is needed rather than bulk closure

For PCAP collection, earlier is better. Waiting until closure to retrieve PCAP evidence risks the capture window expiring, particularly for short-lived network sessions.

Stage 4 — Incident Closed (Active → Closed)

When the analyst closes the Sentinel incident, an automation rule should fire to close all associated detections 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	VectraSetDetectionStatus

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.

kql

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	—	VectraIncidentTimelineUpdate	Clean and populate timeline at creation
Incident updated	New alert added to incident	VectraIncidentTimelineUpdate	Keep timeline synchronized throughout investigation
Incident updated	Status changed to Active	VectraAssignStaticUserToEntity	Record assignment in Vectra — starts MTTI (run first)
Incident updated	Status changed to Active	VectraSetDetectionStatus	Acknowledge detections in Vectra (run second)
Incident updated	Status changed to Closed	VectraSetDetectionStatus	Close detections in Vectra — stops MTTI and MTTR