Gates

GATES Hunt Detection Validator

Apply GATES (Generalizable, Additive, Tunable, Exposure-tested, Sustainable) method to hunt KEEP phase outputs.

When to Use

• After completing any hunt (with or without explicit detection logic)
• To identify which hunt findings would make good detections
• To validate detection quality meets operational thresholds
• To determine if hunt should produce detections vs. advisories vs. recurring playbook

Usage

/gates --hunt H-XXXX

Hunt Output Types & GATES Applicability

GATES adapts to different hunt outcomes:

Key insight: Not every hunt produces detections. GATES identifies which hunts should → detections vs. advisories vs. playbooks.

Framework Reference

GATES 5+5: 5 BASE (assert from hunt) + 5 ADVANCED (demonstrate operationally)

The acronym expands differently per tier, on purpose. Each letter names a concern; each tier asks a different question about it, so A and S take a different word in ADVANCED than in BASE. The table below is the canonical naming — no other expansion of GATES is current. In particular "Accuracy", "Telemetry" and "Executability" are not GATES gates; if you see them, they're stale.

An unqualified gate name in this skill is always the BASE word, because BASE is what GATES scores. ADVANCED is assessed after deployment and is never scored here.

"BASE score" means the BASE tier's score and nothing else: the sum of those five gates, 0.0–5.0. ADVANCED contributes zero to it — which is exactly why the score carries a tier name rather than being called "the GATES score".

Failure modes, listed in the order they are evaluated — Step 4 holds the binding rule; when two gates fail, the one higher in this list decides:

1. A fail → DROP (duplicates existing coverage — nothing to add)
2. G fail → TIME_BOX (IOC or one-off, 90-day review)
3. E fail → HOLD — expand the detection to cover bypasses, then re-assess
4. S fail → RECURRING_HUNT or eng ticket (can't sustain it)
5. T fail → CONDITIONAL (tunable with watchlist, deploy after tuning)
6. no gate failed → the score band decides (4.0–5.0 PROMOTE, 3.0–3.9 CONDITIONAL, 0.0–2.9 HOLD)

Rows 2 and 4 both mean carry the rule anyway, on a cycle. If the hunt found zero instances of the behavior, neither cycle is worth its maintenance → HOLD. Row 6 is the carve-out: with no gate failed, 0 TPs over a clean baseline is a proactive PROMOTE.

Workflow

Pre-Flight: Determine Hunt Output Type

Before scoring, classify the hunt:

1. Read full hunt file (all phases: LEARN → OBSERVE → CHECK → KEEP)
2. Identify hunt goal:
   • Detect active threat? → Behavioral detection hunt
   • Assess security posture? → Risk assessment hunt
   • Understand environment? → Baseline/inventory hunt
   • Investigate specific finding? → May be multi-step investigation
3. Check KEEP phase:
   • Detection rules explicitly proposed? → Score those (Step 2)
   • Findings without detection logic? → Extract candidates (Step 1.5)
   • Configuration/exposure findings only? → Non-GATES workflow
   • Multi-query correlation required? → RECURRING_HUNT classification

Decision tree:

Does KEEP propose explicit detections?
├─ YES → Score those detections (Step 2)
└─ NO → Are findings behavioral patterns?
    ├─ YES → Extract detection candidates (Step 1.5)
    └─ NO → Are findings configuration/risk issues?
        ├─ YES → Non-GATES workflow (advisory output)
        └─ NO → Multi-step investigation?
            ├─ YES → RECURRING_HUNT playbook
            └─ NO → Baseline/inventory (knowledge capture)

Step 0.5: Check Hunt Status

Read hunt frontmatter status field:

• planning → Generate planning assessment (not full GATES)

  • Hunt hypothesis exists but not yet executed
  • Provide execution guidance and detection potential assessment
  • Output: H-XXXX_PLANNING_ASSESSMENT.md

• completed → Proceed to full GATES validation

  • Hunt has CHECK and KEEP phases documented
  • Findings and detections are ready for scoring

• in-progress → Wait for completion

  • Hunt is actively being executed
  • Return: "Hunt not ready for GATES validation. Complete CHECK and KEEP phases first."

Planning Assessment Output:

For planning-phase hunts, generate H-XXXX_PLANNING_ASSESSMENT.md:

# H-XXXX Planning Assessment

**Status:** Planning (not executed)

## GATES Applicability

NOT READY FOR GATES VALIDATION

Hunt is in planning phase. GATES requires completed CHECK/KEEP phases with findings.

## Pre-Assessment (Detection Potential)

Based on hypothesis, the *potential* of each gate once the hunt has run. This is a
pre-flight sketch, **not a score** — a planning hunt has no evidence, so it gets no
BASE score at all. Write what each gate is blocked on:

- G (Generalizable): [plausible | doubtful] — why
- A (Additive): [plausible | doubtful] — why
- T (Tunable): blocked on — needs a baseline
- E (Exposure-tested): blocked on — needs bypass testing
- S (Sustainable): blocked on — needs volume data

Do **not** write PASS/PARTIAL/FAIL here, and do not sum anything. Those are scoring
tokens and using them pre-execution invites someone to total the row into a verdict.

## Recommendations for Execution

1. Execute hunt queries
2. Document findings in KEEP phase
3. Return to GATES for full validation

Step 0.6: Telemetry Sufficiency Check (CRITICAL)

Before scoring BASE criteria, verify telemetry can distinguish attack from legitimate activity.

Ask these questions:

1. Can telemetry differentiate malicious from benign?

   • Example FAIL: Process telemetry cannot distinguish "user-typed command" from "AI agent-generated command"
   • Example PASS: Process + command-line args distinguish "browser → legitimate extension" from "browser → malicious extension"

2. Are critical attack phases observable?

   • Example FAIL: EDR sees preparation (file write) but not execution (pre-boot rootkit)
   • Example PASS: EDR captures full attack chain (initial access → credential dump → lateral movement)

3. Can FP rate be tuned below sustainable threshold?

   • Example FAIL: 40,000 suspicious events, 100% FP rate, no distinguishing field available
   • Example PASS: 1,000 suspicious events → 10 after filters (dev tool allowlist applied)

If NO to Question 3 — the events exist and are visible, but no field separates attack from benign at a workable rate — that is a T FAIL, not a telemetry gap. Score it and let Step 4 return CONDITIONAL: the data is there, the baseline isn't.

Answer per behavior, not per hunt. A hunt's hypothesis is usually broader than any one detectable behavior in it, so Q1 and Q2 are frequently PARTIAL at the hypothesis level and PASS for some narrower behavior inside it. Example: the remote-control session of a KVM-over-IP device is served off-box and invisible (Q2 PARTIAL for "detect misuse of the device"), while the device connecting — T1200, a USB enumeration event — is fully observable. That hunt is scoreable.

So before classifying a hunt as a telemetry gap, ask whether any scoped behavior in it is fully observable:

• Yes → scope the candidate to that behavior and proceed to BASE scoring. The unobservable part is not a blocker; it is a stated limit on what the detection claims, plus a telemetry recommendation in the narrative. Do not inflate the candidate's scope back to the hypothesis — that is the T scope-drift failure below.
• No → the hunt is a telemetry gap, as follows.

If NO to Question 1 or 2 for every candidate behavior:

• Classification: non-GATES (telemetry gap hunt) — a classification, not a verdict; the hunt never reaches the verdict enum because there is nothing scoreable yet
• Output: .md assessment documenting visibility limitations
• Recommendations: Infrastructure improvements (new data source, field population, correlation engine)
• DO NOT proceed to BASE scoring - detection is not feasible with current telemetry

Examples:

• H-0001 (ATHF Showcase): macOS information stealer detection → Strong EDR telemetry coverage for process execution, file access, and AppleScript events
• Reference: https://github.com/Nebulock-Inc/agentic-threat-hunting-framework/blob/main/hunts/H-0001.md

Note: Example references public ATHF showcase hunt. Your results will vary based on environment telemetry coverage.

Why check first: a telemetry gap is uncommon but not rare, and catching it here avoids scoring five gates on a detection that cannot be built at all.

Step 1: Hunt Discovery & Content Extraction

# Find and load the hunt file. Search every hunt location, not just production —
# hunts move test/ → production/, and a planning hunt (which routes to the
# not-ready-for-GATES path) is usually still in test/.
find hunts -name "${HUNT_ID}.md" -type f

Parse YAML frontmatter: hunt_id, techniques, tactics, findings_count, true_positives, false_positives (if present)

Load hunt content from all phases:

• KEEP phase (## KEEP: Findings & Response):
  • Executive Summary
  • Findings (table format OR prose descriptions)
  • Detection Logic (if explicitly proposed)
  • Follow-up Actions (may contain detection recommendations)
  • Lessons Learned
• CHECK phase (## CHECK: Execute & Analyze):
  • ### Hunting Queries → #### Initial Query, #### Refined Query (SQL, process searches, network patterns). The refined query is usually the better detection candidate: it is the initial one after FP tuning
  • #### Query Performance (result counts, time window, volumes)
  • Behavioral patterns observed
• OBSERVE phase (## OBSERVE: Expected Behaviors):
  • "What Suspicious Looks Like" (detection candidates)
  • Expected observables (what telemetry would show)
• LEARN phase (## LEARN: Prepare the Hunt):
  • Hypothesis statement (attack behaviors)
  • Threat context (TTPs, tools, techniques)

Flexible evidence extraction:

• ✅ If Findings table exists with TP/FP counts → use directly
• ✅ If prose findings without counts → extract behavioral patterns
• ✅ If detection logic explicitly proposed in KEEP → score those
• ✅ If NO detection logic proposed → identify opportunities from queries/observations
• ✅ If multi-step investigation → still a candidate; it will fail S on the automation check and Step 4 resolves that to RECURRING_HUNT

Step 1.5: Detection Opportunity Identification

If hunt explicitly proposes detections in KEEP → skip to Step 2 (score those)

If hunt does NOT explicitly propose detections → identify opportunities:

Extract detection candidates from hunt content by analyzing:

1. Behavioral patterns observed:

   • Process execution chains (parent → child relationships)
   • Command-line patterns (suspicious flags, encoded payloads)
   • File operations (writes to sensitive paths, unusual extensions)
   • Network connections (unusual ports, suspicious domains, C2 patterns)
   • Registry modifications (persistence mechanisms, configuration changes)
   • API calls or system events (unusual combinations, privilege escalation)

2. Query patterns that returned results:

   • Which queries found suspicious activity? (even if FP)
   • What volumes were observed? (helps assess sustainability)
   • What filters were applied during hunt? (shows tuning potential)
   • What exclusions were documented? (seed for allowlists)

3. "What Suspicious Looks Like" section:

   • Each bullet point may be a detection candidate
   • Behavioral descriptions → Sigma/SQL rule patterns
   • Tool/technique names → detection signatures

4. Findings without TP/FP counts:

   • Risk findings: Configuration issues, exposure → NOT detections (document as non-detectable)
   • Behavioral findings: Attack patterns, suspicious activity → Detection candidates
   • Hygiene findings: Cleartext creds, deprecated protocols → Informational signals

5. Multi-step investigations:

   • Does finding require: Query 1 → analyst review → Query 2 → correlation?
   • If yes: score it — S FAILs the automation check, which Step 4 turns into RECURRING_HUNT. Score it rather than dropping it, so the reason is on record
   • If no: Can be reduced to single alert → Detection candidate

For each candidate, document:

• Pattern: What behavior would the detection look for?
• Telemetry: What data source(s) provide visibility?
• Volume: What's the expected alert rate? (from hunt queries if available)
• Tuning: What filters/exclusions would reduce FPs? (from hunt observations)
• Hunt outcome: TPs observed (if documented), FPs observed, or unknown

Detection Decomposition (Hybrid Rules):

If detection mixes behavioral + IOC components, split into independent layers:

1. Identify hybrid pattern:

   • Example: PowerShell download cradle (behavioral) + URI pattern /api/installer/script (IOC)
   • Example: Python→OpenSSL chain (behavioral) + C2 domain list (IOC)

2. Split into layers:

   • Behavioral layer → Score as standalone detection (typically CONDITIONAL/PROMOTE)
   • IOC layer → Score separately (typically TIME_BOX with 90-day refresh)

3. Score each independently:

   • Behavioral: G=PASS (repeatable pattern), T/S depend on volume
   • IOC: G=FAIL (campaign-specific), but may TIME_BOX if operationally useful

4. Output both detections — one candidate_id each, sharing a stem and suffixed with the layer (-behavioral / -ioc). Never 1a/1b: ordinals are not stable across runs, see "Candidate identity" in AGENT_MEMORY_SCHEMA.md.

   detections:
     - candidate_id: powershell-download-cradle-behavioral
       name: "PowerShell Download Cradle (Behavioral)"
       gates_assessment:
         verdict: CONDITIONAL
         
     - candidate_id: powershell-download-cradle-ioc
       name: "Suspicious URI Pattern (IOC)"
       gates_assessment:
         verdict: TIME_BOX
         refresh_cycle: 90_days

Why split? IOC shelf life (90 days) ≠ behavioral logic (durable). Separate verdicts enable proper lifecycle management.

Hybrid patterns seen in practice:

• Download cradle behavior (CONDITIONAL) + Known malicious URIs (TIME_BOX)
• Suspicious process chain (PROMOTE) + C2 domain IOCs (TIME_BOX)
• High-volume npm operations (RECURRING_HUNT) + C2 infrastructure IOCs (TIME_BOX)

Why this matters: a hybrid that is scored as one candidate gets one verdict, and that verdict is wrong for one of its two halves — either the behavioral logic inherits the IOC's expiry, or the IOC inherits the behavioral rule's permanence.

External Reference Extraction:

If hunt KEEP phase references external detection artifacts (commit hash, PR, file):

1. DO NOT just link - Extract actual detection logic
2. Read referenced source:
   • Detection repository commits (if accessible)
   • Signal rule YAML files
   • GitHub PRs with detection logic
3. Document logic in output - Include selection, condition, filters
4. Score what's documented - Don't score placeholder references

Example: Hunt references "detection repo commit abc1234" → Agent must read commit, extract detection rules, document logic (selection criteria, conditions, filters), then score each rule independently.

When the reference is unreadable and it is the deployable candidate. "Don't score placeholder references" and "detection_logic.query is REQUIRED for a deployable candidate" collide exactly here: the hunt cites rule files that don't exist yet (local uncommitted work, a private repo, a dead link) and that citation is the only statement of the logic. Resolve it this way:

1. Score what the hunt itself documents — the CHECK queries, the observed behavior, the FP sources named in KEEP. That is evidence; the unreadable file is not.
2. Write detection_logic.query from that evidence, not from the reference. A query you derived from a documented hunt query is a real query. Never emit a placeholder, a TODO, or the reference string itself as the query — a deployable candidate whose query can't be run is the fictional coverage this assessment exists to prevent.
3. Name the unreadable reference in the narrative as an unverified premise, with what you could not read (e.g. the exact allowlist entries). An unread detail that would change tuning or volume caps T and S at PARTIAL — you have the behavior but not the baseline it was tuned against.
4. If the hunt documents nothing beyond the reference, there is no candidate to score. Say so and recommend re-running GATES once the artifact is reachable; do not mint a candidate out of a file path.

Output: List of 1-N detection candidates OR determination that hunt produces no detection artifacts (risk assessment, baseline study, inventory)

Step 2: BASE Criteria Evaluation

Fast path — IOC with zero prevalence:

An IOC-based candidate (G = FAIL) in a hunt that found 0 instances resolves to HOLD by the zero-prevalence rule in Step 4: a watchlist for a campaign that has never touched this environment is clutter, not early warning. You can recognize that case up front.

Score the other four gates anyway. The verdict is already known, but the scores are the record of why, and a candidate with no base_score can't be compared against the next one that looks like it. Output is a .md assessment, and activation is contingent on threat intel showing the campaign in scope.

Contrast H-0906_EXAMPLE.yaml: also an IOC watchlist, also a G FAIL, but the campaign is present — so it is TIME_BOX, not HOLD. Prevalence is the whole difference. Note the extension too: TIME_BOX is deployable, so it emits .yaml; the HOLD case above emits .md.

For each detection candidate (explicit or identified), score all 5 BASE criteria as ✅ PASS, ⚠️ PARTIAL, or ❌ FAIL. There is no fourth value — an unevidenced gate is PARTIAL, never UNKNOWN, because only these three have point values.

A (Additive) User Verification: If detection repository is not accessible (no ATHF/ADEF integration, external repo, etc.), prompt user:

A - Additive Verification:

Do you have existing detection coverage for:
- Technique: [T1XXX from hunt]
- Behavior: [detection pattern]
- Data source: [EDR/CloudTrail/etc.]

Questions:
1. Does this detection duplicate any existing rule? (Y/N)
2. Does this fill a gap in your current detection portfolio? (Y/N)
3. If similar detection exists, what's different about this one?

→ User input required to score A criterion

If detection repository IS accessible (ATHF/ADEF integrated), automatically check for overlaps.

BASE Scoring

Each gate scores:

• PASS = 1.0 point (criterion fully met)
• PARTIAL = 0.5 points (criterion partially met with caveats)
• FAIL = 0.0 points (criterion not met)

BASE Score = Sum of gate scores (0.0 to 5.0). Record it as a float — 4.5, not "4.5/5" — because consumers average and threshold it.

Verdict Mapping: see Step 4: Verdict & Output, which is the single authoritative statement of how a score and the gate results become a verdict. Do not score a verdict from this section; the score alone is not sufficient to decide one.

Examples:

• All PASS: 5.0
• 4 PASS + 1 PARTIAL: 4.5
• 3 PASS + 1 PARTIAL + 1 FAIL: 3.5
• 4 PASS + 1 FAIL: 4.0 — a high score with a FAIL. The FAIL decides the verdict, not the 4.0; see Step 4.

When to score PARTIAL:

• Detection has the concept but incomplete (T: tunable but needs allowlist)
• Coverage exists but has gaps (E: tested main path, not bypasses)
• Meets threshold with caveats (S: sustainable IF maintenance plan exists)
• Gate is mostly satisfied but has known limitations

Handling Missing Data:

When hunt doesn't provide explicit TP/FP counts or detection logic:

Key principle: missing data means PARTIAL, not an automatic FAIL. It does not imply a verdict — the verdict is still Step 4's. Note that PARTIALs do not accumulate into CONDITIONAL: an all-PARTIAL candidate scores 2.5, which is HOLD. Document what is unmeasured and name the validation step that would resolve it.

Rule type impact on the G gate — rule type determines G and nothing else; the other four gates and the verdict still come from the evidence:

• BEHAVIORAL: process patterns, TTPs → G PASS
• TOOL: tool signatures → G PASS
• IOC: IPs, domains, hashes → G FAIL (→ TIME_BOX, or HOLD at zero prevalence)
• HYBRID: mixed → split into behavioral + IOC candidates and score each
• MULTI-STEP INVESTIGATION: Detection requires multiple queries with intermediate results that must be manually correlated → not reducible to a single alert, so S FAILs the automation check → RECURRING_HUNT (quarterly hunt playbook, not a standing detection)
  • Examples: Query 1 outputs list → Query 2 uses that list → Query 3 correlates results → Analyst decides if suspicious
  • Cannot be reduced to one alert with clear action
  • Requires hunt methodology, not alerting

Step 3: ADVANCED Criteria (Operational Validation)

ADVANCED criteria are PENDING until deployment. Provide recommendations:

These are the ADVANCED words (A = Actionable, S = Soaked), per the Framework Reference. They are recommendations only — ADVANCED is never scored into the BASE score.

Step 4: Verdict & Output

Exactly one verdict per candidate, from the canonical enum: PROMOTE | CONDITIONAL | TIME_BOX | RECURRING_HUNT | HOLD | DROP.