A municipal SOC notices stealthy persistence may exist even when no high-severity alert fired. Which approach best describes threat hunting in this context?
Select an answer to reveal the explanation.
Short Explanation
Threat hunting is walking the beat looking for odd footprints even when the alarm never rang. Municipal analysts dig through telemetry for persistence tricks that quiet alerts miss. Sitting only on SIEM tickets is pure reaction, not hunting.
Full Explanation
Threat hunting is a proactive, hypothesis-driven search through telemetry for adversary techniques that existing alerts may miss. In a municipal SOC worried about stealthy persistence, hunters query EDR, identity, DNS, and proxy data for living-off-the-land behaviors, unusual scheduled tasks, anomalous service installs, or rare outbound patterns—even when no high-severity ticket exists. Hunting complements alert-driven incident response: IR handles known detections, while hunting reduces dwell time for quiet footholds in city endpoints and servers. Successful hunts either confirm malicious activity (triggering IR) or improve detections and baselines when the hypothesis is disproven.
Waiting exclusively for SIEM tickets is purely reactive monitoring, not hunting. Replacing logging with quarterly vulnerability scans removes continuous behavioral visibility and addresses configuration weakness only periodically—it does not search for active techniques. Disabling EDR to reduce noise while guessing at dwell time destroys the very telemetry hunters need and increases blind spots. Exam caveat: if the stem emphasizes proactive search beyond alerts, choose threat hunting; do not confuse it with vulnerability scanning or ticket queues alone. Operationally, charter recurring hunt sprints with documented hypotheses (for example, persistence on privileged workstations), preserve query notebooks, feed confirmed patterns into SIEM/EDR detections, and measure whether municipal dwell time and silent-persistence findings improve over successive hunt cycles.