After a permitting-portal incident, the city restored service, documented the case, and closed the notable. What should the SOC still confirm about continuous monitoring?
Select an answer to reveal the explanation.
Short Explanation
The portal is back online, so point the cameras at the hole the attacker used—a new sourcetype or correlation search, whatever was missing. Closing the notable without feeding those lessons into monitoring is how the same trick works next month.
Full Explanation
After recover, continuous monitoring should resume with the gap closed: onboard the missing sourcetype, add or tune a correlation search, or otherwise watch the path that allowed the permitting-portal incident. Restoring service, documenting the case, and closing the notable without that confirmation leaves the city blind to the same technique on the next attempt. Disabling all correlation searches so the queue stays empty fails by concept because empty queues created by silenced detections increase dwell; they do not prove security. Claiming the recover stage forbids adding detections for a year fails by concept because recover explicitly includes improving detection and process from lessons learned. Relying only on a quarterly spreadsheet until the next audit fails by concept because that returns to snapshot compliance instead of continuous monitoring of civic telemetry. Exam caveat: SPLK-5001 ties post-incident recover to detection improvement and resumed monitoring, not to silencing analytics or deferring to audit binders. Operational check: after permitting-portal closure, verify the new or tuned search or sourcetype is enabled, fires on test or historical data for the gap, and appears in continuous monitoring coverage before briefing leadership that the case is truly complete.