Post-incident review in Cybersecurity - Time & Space Complexity
Analyzing the time complexity of a post-incident review helps us understand how the effort grows as the incident details increase.
We want to know how the time to complete the review changes when there are more logs, alerts, or affected systems.
Analyze the time complexity of the following post-incident review process.
for each alert in incident_alerts:
analyze alert details
for each log_entry in alert.related_logs:
check for anomalies
summarize findings
update incident report
notify stakeholders
This code snippet shows reviewing each alert and its related logs to find issues and report them.
- Primary operation: Nested loops over alerts and their related logs.
- How many times: Outer loop runs once per alert; inner loop runs once per log entry per alert.
As the number of alerts and logs grows, the time to review grows faster because each alert requires checking many logs.
| Input Size (alerts) | Approx. Operations |
|---|---|
| 10 alerts, 10 logs each | ~100 checks |
| 100 alerts, 10 logs each | ~1,000 checks |
| 100 alerts, 100 logs each | ~10,000 checks |
Pattern observation: The total work grows roughly by multiplying alerts and logs, so it increases quickly as both grow.
Time Complexity: O(n * m)
This means the review time grows proportionally to the number of alerts times the number of logs per alert.
[X] Wrong: "The review time only depends on the number of alerts, not the logs inside them."
[OK] Correct: Each alert has many logs to check, so ignoring logs misses the main work inside the review.
Understanding how review time grows helps you explain your approach to handling large incidents efficiently and shows you can think about workload scaling.
"What if the logs were pre-filtered to only suspicious ones? How would the time complexity change?"