The city SOC matches a quarantined file hash to an Enterprise Security threat list. Unless a blocking control is also in the path, what does that match provide?
Select an answer to reveal the explanation.
Short Explanation
A threat list is a wanted poster, not a locked door. Matching a hash in ES tells you the city has seen that indicator; it does not by itself stop the file unless a control is also in the path. Wanted posters do not tackle people.
Full Explanation
Matching a quarantined file hash to an Enterprise Security threat list provides analytic enrichment: it answers whether civic telemetry has seen that hash and raises investigative confidence. Unless a blocking control is also in the path—EDR quarantine already performed, firewall or proxy deny, and so on—the threat-list match itself is not a network block. Municipal analysts must not confuse an intelligence hit with enforcement.
An automatic perimeter deny that replaces the need for EDR or firewall rules fails by overstating threat-list power—lists enrich investigations; blocking products enforce policy. Proof that the hash was quarantined on every county endpoint fails by scope; one match does not equal universal quarantine across the estate. A completed SOAR playbook that isolates the host without any analyst action fails by assuming automation the stem does not provide—matching a list does not by itself run isolation.
Exam caveat: threat-intel match equals enrichment unless paired with an explicit control action described in the question.
Operational check: note the Enterprise Security threat-list hit on the hash, verify whether EDR already quarantined the file, confirm or request blocking controls if still needed, and document enrichment versus enforcement separately in the case file.