14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting
Key Takeaways
- Reactive work starts from an event or a firing detector (queue, IR, emergency containment); proactive work reduces future incidents or future noise (hunting, tabletops, scanning, detection engineering, FP remediation).
- False-positive remediation exists to stop the same junk from training analysts to click Close; the durable output is a detection-engineering ticket, not only a closed alert.
- Detection engineering turns TTPs and past incidents into maintainable rules; vulnerability scanning is a proactive control taught in depth in chapter 13 that also explains some benign SOC alerts.
- Tabletop exercises rehearse decisions without live malware; DFIR answers what happened and how to contain it; threat hunting searches with a hypothesis before an alert exists.
- Alert-queue work is reactive; a purple-team tabletop is proactive even though it talks about attacks.
Proactive versus reactive is a trigger, not a personality
TryHackMe's SAL1 training content (24 March 2025) asks you to classify security activities as proactive or reactive, then to explain false-positive (FP) remediation, detection engineering, vulnerability scanning, tabletop exercises, digital forensics and incident response (DFIR), and threat hunting. This independent section covers that map. The trap is treating "proactive" as a moral upgrade and "reactive" as failure. A SOC that never reacts is asleep. A SOC that only reacts repeats the same 40 junk alerts every Monday.
Reactive work starts because something already happened or a detector already fired. The alert queue, live incident response (IR), emergency isolation, and forensics on a host you already believe is compromised are reactive. The trigger is an event, a ticket, or a user report.
Proactive work tries to reduce future incidents, future dwell time, or future noise before the next page. Threat hunting without a ticket, tabletop practice, scheduled vulnerability scanning, writing new detections, and fixing noisy rules are proactive. The trigger is a hypothesis, a calendar, or a backlog of quality work—not a red badge in the SIEM.
The same human can do both in one week. The classification is about why you started, not about whether the work uses Splunk.
| Activity | Default bucket | Trigger | Success looks like |
|---|---|---|---|
| Alert-queue triage | Reactive | A firing alert or inbound ticket | Correct verdict and next action |
| Emergency containment / IR | Reactive | Declared or suspected incident | Attacker stopped; evidence preserved |
| DFIR casework | Mostly reactive | A case that needs reconstruction | Timeline, scope, and durable lessons |
| FP remediation | Proactive (fed by reactive pain) | Repeated junk or a proven misfire | Rule tuned; queue quieter next week |
| Detection engineering | Proactive | Coverage gap or new TTP | Maintainable rule, not a one-off search |
| Vulnerability scanning | Proactive | Schedule or change window | Weaknesses found before attackers |
| Tabletop exercise | Proactive | Planned scenario | Decisions rehearsed; gaps written down |
| Threat hunting | Proactive | Hypothesis ("if they used X, we would see Y") | Confirm or refute; new detection or a documented miss |
False-positive remediation: stop teaching the queue to lie
An FP is a detection that fired on something that is not the bad thing the rule claims (section 14.4). FP remediation is the follow-through: you do not only close today's alert; you change the system so the same misfire is less likely tomorrow.
Purpose:
- Protect analyst attention. If L1 spends a shift proving the same helpdesk script is not malware, nobody is watching the rare C2.
- Protect trust. A queue that is 90 percent junk trains people to click Close. That is how true positives die.
- Give detection engineering evidence: sample events, the legitimate business process, the host or user that should be excluded with expiry, and the risk if you exclude too broadly.
L1's job in FP remediation is a quality ticket, not a silent allow-list in production. "Ignore all PowerShell" is not remediation; it is a false-negative factory. "Exclude signed Deploy-Helpdesk.ps1 from \\tools.cedar-bank.example\it when parent is msiexec.exe, review in 90 days" is remediation.
Detection engineering: turn pain into rules you can live with
Detection engineering designs, tests, and maintains the logic that creates alerts: SIEM correlation searches, EDR behavioral rules, email-gateway policies. Purpose is coverage of real attacker behavior with a false-positive rate a shift can survive.
Inputs: MITRE ATT&CK techniques, past incidents, threat-intel reports, L1 FP tickets, and purple-team results. Outputs: versioned rules, documentation (what it detects, what it does not), and a plan for telemetry if the rule cannot see the data.
L1 is not the detection engineer. L1 is the customer of detections and the first reporter when they rot. If you never file the FP, engineering never sees the rot.
Vulnerability scanning: proactive finding of weaknesses (pointer)
Vulnerability scanning is a scheduled or on-demand search for known weaknesses: missing patches, exposed services, weak web paths. SAL1 training content treats external versus internal and web versus network scanning in depth in chapter 13. In this chapter, remember two SOC-facing facts:
- Scanning is proactive. You would rather a scanner find SMB signing off than a ransomware crew.
- Scanning creates telemetry that can look like attacks: port sweeps, web probing, sudden connections to newly registered domains in a scan scope. Those alerts are often benign true positives when the source is the approved scanner in the approved window—not proof that scanning "does not belong in a SOC."
Do not re-learn scan types here. Do learn to classify the activity: the scan program is proactive; a 03:00 SOC alert caused by the scanner is still a reactive ticket you must dispose correctly.
Tabletop exercises: practice decisions without detonating malware
A tabletop exercise is a discussion-based rehearsal. A facilitator injects a scenario ("ransomware note on a file server," "CFO wire-fraud email"). Participants say what they would do, whom they would call, and which evidence they would collect. Nobody needs to drop a payload on production.
Purpose: find broken phone trees, missing workbooks, unclear authority to isolate a branch workstation, and assumptions like "IR is always in the building." Tabletops are proactive. They become purple-flavored when red-team operators and detection engineers sit in the same room and the injects match techniques red actually uses in tests.
A tabletop is not DFIR. No disk image is taken. Success is a written after-action: decisions, owners, and gaps—not a malware sandbox report.
DFIR: reconstruct and respond when a case exists
Digital forensics answers what happened, on which systems, with evidence that could survive scrutiny: timelines, artifacts, integrity of images. Incident response contains, eradicates, and recovers. Together, DFIR is how an organization handles a serious case without guessing.
Purpose in a security posture: stop the bleeding and learn. A DFIR report that never becomes a detection or a workbook change wastes the incident. Default bucket is reactive (there is already a case). The lessons should feed proactive work.
L1 does not become a forensic examiner on every High alert. L1 preserves: do not reboot-wipe a host the workbook says to isolate; do not forward malware to random mailboxes; do record exact times so IR is not reconstructing from memory.
Threat hunting: look before the alert exists
Threat hunting is a hypothesis-driven search through telemetry for attacker behavior that current rules may have missed. Example hypothesis: "If an adversary used signed binaries to live off the land, we would see rundll32.exe with unusual network children on branch PCs outside change windows." The hunter searches, confirms or refutes, then either writes a detection, opens an incident, or documents that the hypothesis failed.
Purpose: shrink dwell time—the period an adversary is inside before anyone notices. Hunting is proactive. It uses the same SIEM as the queue, which confuses candidates into calling it reactive. The trigger is the hypothesis, not a notable event.
Hunting is not "scroll Splunk until scared." Unguided scrolling is how people invent stories and miss the queue.
Worked contrast: Monday queue versus Thursday tabletop
Reactive — alert queue. Monday 09:10 UTC, Cedar Bank L1 has 36 "encoded PowerShell" alerts from IT-WKS-04. Each is the documented Monday helpdesk installer. Closing all 36 with the same sentence is still reactive queue work. If L1 stops there, Tuesday will look identical. The proactive twin is an FP-remediation ticket to detection engineering with a sample command line, signer, share path, and a request to exclude that pattern with an expiry.
Proactive — purple-team tabletop. Thursday 14:00 UTC, the facilitator injects: "Red will describe a Word-to-PowerShell beacon on a branch PC; blue, walk your workbook without opening production." Nobody runs malware. Detection engineering admits the encoded-PowerShell rule would have fired on the helpdesk script and on the red technique, so severity-alone cannot be the verdict. IR admits after-hours isolation authority is unclear for branches. The output is a gap list: tune the rule, add a workbook step for parent-process checks, clarify who can isolate BR-WKS-*. That meeting is proactive, even though the story is an attack.
If you mix the buckets on an exam item: "Which of these is reactive?" the Monday queue is the answer. "Which is a proactive exercise involving red and blue?" the Thursday tabletop is the answer. Do not call the tabletop reactive just because people talked about C2. Do not call FP remediation "only reactive" if the durable fix is a better rule—the pain was reactive; the fix is proactive.
Independent coverage of these SAL1 activity topics is the difference between a busy SOC and a SOC that gets quieter and sharper over a quarter.
An L1 spends Monday closing 36 identical 'encoded PowerShell' alerts that match a documented helpdesk installer, then files a ticket asking detection engineering to exclude that signed script with a 90-day review. How should you classify those two actions?
Which pair correctly buckets a purple-team tabletop versus working the live SIEM alert queue?
What is the purpose of threat hunting in improving security posture, as distinct from DFIR?