Incident Management, Threat Intelligence, and Attack Surface Management
The Incident Management, Threat Intelligence, and Attack Surface Management domain tests the operational workflow: how alerts become incidents, how incidents are prioritized and resolved, how threat intelligence enriches them, and how attack surface findings are triaged.
Core rules
- Incidents are grouped from alerts by incident type and grouping rules. Grouping by entity and time reduces duplicate work; fields such as severity, owner, and status drive queue behavior.
- Incident lifecycle: new, assigned, in progress, resolved or closed, with a resolution reason. SLAs and playbooks depend on accurate timestamps and ownership.
- Threat Intelligence Management ingests feeds, normalizes indicators, and assigns reputation and score. Enrichment informs an incident; it does not automatically prove compromise.
- Attack Surface Management discovers internet-facing assets and exposures. Findings need asset criticality, ownership, and exploitability context before they become incidents.
- Use incident layouts and fields consistently so automation and reporting can consume them.
Worked example
ASM reports an internet-facing RDP service. The analyst confirms the asset owner, checks whether the host is production, and enriches the source IP with TIM. Because the asset is critical and the indicator is malicious, the analyst creates a high-severity incident, assigns the network team, and runs a playbook to restrict access. Reasoning: exposure alone is a finding; asset context and threat intel determine incident priority.
Traps
Creating an incident for every ASM observation; closing an incident without a resolution reason; treating a TI unknown verdict as benign; ignoring asset ownership; letting duplicate alerts inflate SLAs; using incident fields inconsistently across teams.