Investigating Cortex Incidents - A Deep Dive into Cases and Alerts

Understanding the Incident Lifecycle

In Cortex XDR, visibility isn't just about logs; it's about the lifecycle of an attack. This lifecycle is represented through Alerts (singular events) and Incidents (correlated groups of alerts).

To master case management, you need to be able to query the incidents and alerts datasets with precision. This guide covers detailed XQL patterns for managing and auditing your SOC's response.

1. Incident Analysis Queries

A. Finding High-Priority Incidents with Multiple Alerts

Incidents with many alerts often indicate a broad or successful attack.

dataset = incidents
| filter severity = "high" or severity = "critical"
| filter alert_count > 5
| fields incident_id, description, severity, status, alert_count, creation_time
| sort desc alert_count

B. Tracking Mean Time to Acknowledge (MTTA)

A critical metric for SOC efficiency. This calculates how long it takes for a case to be touched by an analyst.

dataset = incidents
| filter status != "pending"
| alter mtta_seconds = (acknowledgement_time - creation_time) / 1000
| comp avg(mtta_seconds) as avg_mtta_seconds by severity

C. Identifying "Long-Running" Cases

Cases that have been open for an unusual amount of time may require escalation.

dataset = incidents
| filter status = "under_investigation"
| alter open_duration_hours = (timestamp() - creation_time) / 3600000
| filter open_duration_hours > 48
| fields incident_id, assignee, open_duration_hours

2. Alert Deep-Dive Queries

D. Mapping Alerts to Specific MITRE ATT&CK Techniques

Understanding how the attack is happening is vital for containment.

dataset = alerts
| filter mitre_technique_id != null
| comp count(alert_id) as technique_count by mitre_technique_name, mitre_technique_id
| sort desc technique_count

E. Finding "Noisiest" Alert Sources

Identifying which endpoints or users are triggering the most alerts to reduce false positives.

dataset = alerts
| comp count(alert_id) as alert_count by source_endpoint_name
| sort desc alert_count
| limit 20

F. Correlating Alerts without Incidents

Sometimes alerts fail to group into an incident correctly. Finding these "orphaned" alerts can surface hidden threats.

dataset = alerts
| filter incident_id = null
| fields _time, alert_name, severity, source_endpoint_name

3. Case Escalation & Logic Issues

G. Detecting Flapping Alerts

Alerts that resolve and then re-open frequently can point to misconfigured policies or recurring automated threats.

dataset = alerts
| comp count(alert_id) as instance_count by alert_name, source_endpoint_name
| filter instance_count > 50

H. Analyzing Resolution Rationale

If you want to see why analysts are closing cases as "False Positive," you can audit the resolution comments.

dataset = incidents
| filter status = "resolved" and resolution_status = "false_positive"
| fields incident_id, resolution_comment, resolved_by

I. Identifying Overloaded Analysts

Check the workload distribution across your SOC team.

dataset = incidents
| filter status = "under_investigation"
| comp count(incident_id) as assigned_cases by assignee
| sort desc assigned_cases

4. Advanced Case Correlating

J. The "Full Story" Query

Combine incident metadata with the actual process details that started the mess.

dataset = incidents
| join (dataset = alerts) as a on a.incident_id = incidents.incident_id
| fields incidents.incident_id, incidents.description, a.alert_name, a.actor_process_command_line
| limit 50

Summary Table: Key Datasets for Cases

Conclusion

Effective case management in Cortex XDR requires shifting from "viewing screens" to "querying data." By using these XQL patterns, you can identify bottlenecks in your SOC, find orphaned alerts that missed correlation, and ensure that critical threats are acknowledged in minutes, not days.

Stay vigilant!