Responders believe attackers entered a parks-and-recreation portal via a known CVE. Which investigative context best supports that hypothesis?
Select an answer to reveal the explanation.
Short Explanation
If the story is “they walked in through a known CVE,” pull the scan history that shows that door was unlocked on the parks portal. Asset inventory plus open findings explain opportunity. Rumors and fire-drill rosters are not exploit timelines.
Full Explanation
Investigative context for a suspected CVE-based intrusion comes from evidence that the vulnerability existed on the affected asset at the relevant time. Vulnerability scan history showing the parks-and-recreation portal host as open for that CVE, combined with asset inventory that confirms hostname, ownership, exposure, and software version, supports the hypothesis that attackers entered through that weakness. Timestamps matter: scans before the incident establish exposure; post-incident scans and patch records help show whether the hole remained. This context guides eradication (patch or configuration fix) and prevents treating only malware symptoms while leaving the portal exploitable.
Discarding historical vulnerability scan results after containment throws away proof of the entry condition and weakens RCA. User rumors about which server “felt slow” are anecdotal and uncorrelated with exploitability. Last year’s physical fire-drill roster documents safety attendance, not software flaws on a web portal. Exam tip: when the stem posits entry via a known CVE, look for scan history and asset inventory as supporting context—not hearsay or unrelated safety records. Operationally, retain authenticated scan results with asset IDs for municipal internet-facing systems, map CVEs to owners, and require IR reports to cite whether the exploited CVE was previously detected, ticketed, and overdue—feeding vulnerability-management SLAs after the parks portal incident.