TH0.14 Hunting Program Metrics Dashboard

3-4 hours · Module 0 · Free

Operational Objective

A hunting program without metrics is a program that cannot demonstrate value, cannot identify where it is improving, and cannot justify continued investment. This subsection provides the KQL queries for a hunting program metrics dashboard — deployable in a Sentinel workbook on day one — that tracks the four metrics from TH0.7 plus operational health indicators.

Deliverable: A set of production-ready KQL queries that track hunting program effectiveness, deployable as a Sentinel workbook or run individually for quarterly reporting.

⏱ Estimated completion: 30 minutes

Measure what matters

TH0.7 defined four metrics: detection coverage gap closure rate, hunt discovery rate, dwell time compression, and MTTD trend. This subsection provides the KQL for each, plus three operational health metrics that tell you whether the program itself is functioning.

Metric 1: Detection coverage trend

Track this quarterly. The numerator comes from your Sentinel analytics rules with ATT&CK mappings. The denominator is your relevant technique set (defined once in TH3, updated annually).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// Detection coverage trend — run quarterly and record
// Numerator: distinct ATT&CK techniques with at least one rule
SecurityAlert
| where TimeGenerated > ago(90d)
| where ProviderName == "ASI Scheduled Alerts"
| extend Techniques = tostring(
    parse_json(ExtendedProperties).["Techniques"])
| where isnotempty(Techniques) and Techniques != "[]"
| summarize by Techniques
| summarize CoveredTechniques = count()
// Record this number quarterly alongside your denominator
// Plot: Q1: 22/95 = 23% → Q2: 28/95 = 29% → Q3: 34/95 = 36%
// The upward trend is directly attributable to hunt-derived rules

Metric 2: Hunt-derived detection rules

Count the detection rules that exist because a hunt produced them. This is the tangible output of the program.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
// Hunt-derived detection rule inventory
SecurityAlert
| where TimeGenerated > ago(365d)
| where ProviderName == "ASI Scheduled Alerts"
| where AlertName startswith "HUNT-"
| summarize
    TotalAlerts = count(),
    FirstAlert = min(TimeGenerated),
    LastAlert = max(TimeGenerated),
    TruePositiveEstimate = countif(
        AlertSeverity in ("High", "Medium"))
    by AlertName
| extend DaysActive = datetime_diff(
    'day', now(), FirstAlert)
| sort by FirstAlert asc
// Each row = one detection rule produced by hunting
// DaysActive shows how long each rule has been in production
// TruePositiveEstimate (High+Medium alerts) indicates rule quality
// Target: +1 rule per month, growing over the program lifetime

Metric 3: Hunt discovery rate

What percentage of incidents were discovered through proactive hunting versus automated detection? This metric requires consistent labeling — tag hunt-discovered incidents with “HUNT-” prefix or a “hunt-discovered” label when escalating.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
// Hunt discovery rate — proportion of incidents found by hunting
SecurityIncident
| where TimeGenerated > ago(180d)
| where Status == "Closed"
| extend Discovery = iff(
    Title has "HUNT-" or tostring(Labels) has "hunt",
    "Proactive Hunt", "Automated Detection")
| summarize Count = count() by Discovery
| extend Total = toscalar(
    SecurityIncident
    | where TimeGenerated > ago(180d)
    | where Status == "Closed" | count)
| extend Percentage = round(100.0 * Count / Total, 1)
// Even 5% hunt discovery = 5% of incidents invisible without hunting
// Track quarterly — rate should remain stable or increase as
//   hunts target techniques with no automated detection

Metric 4: Dwell time by discovery source

Compare dwell time for hunt-discovered incidents versus rule-detected incidents. If hunting is working, hunt-discovered incidents should have shorter dwell times on average — because hunting found them before they would have been detected by other means.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Dwell time comparison: hunt-found vs rule-found
SecurityIncident
| where TimeGenerated > ago(365d)
| where Status == "Closed"
| extend EarliestEvidence = todatetime(
    parse_json(tostring(AdditionalData)).firstActivityTimeUtc)
| where isnotempty(EarliestEvidence)
| extend DwellDays = datetime_diff(
    'day', CreatedTime, EarliestEvidence)
| where DwellDays >= 0 and DwellDays < 365
| extend Discovery = iff(
    Title has "HUNT-" or tostring(Labels) has "hunt",
    "Proactive Hunt", "Automated Detection")
| summarize
    MedianDwell = percentile(DwellDays, 50),
    P90Dwell = percentile(DwellDays, 90),
    Count = count()
    by Discovery
// The comparison tells the story:
// Automated: median X days, P90 Y days
// Hunting: median A days, P90 B days
// If A < X, hunting is compressing dwell time as expected

Operational health: program cadence

Is the hunting program actually executing on schedule? Track hunts completed per month.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
// Hunt program cadence — are hunts happening on schedule?
// This query assumes hunt-derived rules are named HUNT-THx-NNN
SecurityAlert
| where TimeGenerated > ago(365d)
| where ProviderName == "ASI Scheduled Alerts"
| where AlertName startswith "HUNT-"
| extend RuleDeployMonth = startofmonth(min_of(TimeGenerated))
| summarize NewRulesDeployed = dcount(AlertName)
    by RuleDeployMonth
| sort by RuleDeployMonth asc
// Each row = new hunt-derived rules deployed that month
// Target: ≥1 per month for a monthly cadence program
// Months with 0 = hunting did not produce a rule (or did not execute)
// Consistent gaps indicate the program is stalling

Figure TH0.14 — Hunting program metrics. Four value metrics for leadership reporting. Three health metrics for internal program management.

Try it yourself

Exercise: Establish your baseline metrics

Run each of the five KQL queries in this subsection against your Sentinel workspace. Record the results as your baseline — the starting point before the hunting program begins (or the current state if hunting has already started).

If hunt-derived rules (HUNT-* naming) do not exist yet, metrics 2–5 will return empty results. That is your HMM0/HMM1 baseline. After executing your first three campaigns, re-run and compare.

If you want to deploy these as a persistent dashboard, create a Sentinel workbook with each query as a separate visualization. TH16 covers workbook creation in detail, but the queries above are ready to paste into workbook query tiles today.

⚠ Compliance Myth: "Hunting metrics are only for internal use — auditors do not care about them"

The myth: Hunting program metrics are operational data. Auditors want policies and procedures, not KQL query outputs.

The reality: Auditors want evidence that controls are operating effectively. A hunting program with documented metrics — hunts completed, coverage improved, incidents discovered, detection rules produced — provides stronger evidence of proactive monitoring than a policy that says “we will conduct threat hunting” without proof of execution. The quarterly metrics report is audit evidence. The hunt records referenced by those metrics are audit evidence. The detection rules deployed from hunts are audit evidence. Metrics are not operational overhead — they are the proof that the program exists beyond a document.

Extend this dashboard

The metrics here are the minimum viable set. Organizations with mature hunting programs often add: hypothesis source distribution (which of the six sources generates the most productive hypotheses?), false positive rate for hunt-derived rules (are hunt-based rules better tuned than non-hunt rules?), analyst skill development tracking (which analysts produce the most findings per hunt hour?), and technique recurrence (do techniques found by hunting reappear after remediation?). Add these as the program matures and the baseline metrics stabilize. Start with the seven described here.

📋 Operational Artifact — Quarterly Hunting Program Report Template

Hunting Program Report — Q[N] [Year]
Coverage: [X]% → [Y]% (+[Z] percentage points). [N] new techniques covered by hunt-derived rules.
Hunts completed: [N] campaigns. [N] confirmed findings, [N] refuted (negative), [N] inconclusive.
Detection rules produced: [N] new HUNT-* rules deployed. [N] total hunt-derived rules in production.
Incidents discovered through hunting: [N] ([%] of all closed incidents this quarter).
Dwell time: Hunt-discovered median [A] days vs automated median [B] days.
Program health: [N] hunts per month vs target of [N]. Backlog depth: [N] hypotheses. Rule deployment time: avg [N] days from hunt to production.
Next quarter focus: [Top 3 hypotheses from backlog with priority rationale].

References Used in This Subsection

Microsoft. “Create Workbooks in Microsoft Sentinel.” Microsoft Learn. https://learn.microsoft.com/en-us/azure/sentinel/monitor-your-data
Course cross-references: TH0.7 (metric definitions), TH16 (workbook deployment), TH15 (reporting)

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← TH0.13 Building the Leadership Case TH0.15 Your First 90 Days: From Zero to Operating →