> 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/siem/vectra-rux-best-practices-for-microsoft-sentinel-ccf.md).

# Vectra RUX Best Practices for Microsoft Sentinel CCF

## 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

```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

```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        |


---

# 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:

```
GET https://docs.vectra.ai/configuration/response/siem/vectra-rux-best-practices-for-microsoft-sentinel-ccf.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.