Azure Sentinel for SIEM - Time & Space Complexity
We want to understand how the time to analyze security data grows as more data is collected in Azure Sentinel.
Specifically, how does the number of operations change when processing more alerts and logs?
Analyze the time complexity of querying and alerting in Azure Sentinel.
// Pseudo-azure code for Sentinel query and alert
let alerts = SecurityAlert
| where TimeGenerated > ago(1d)
| where Severity == 'High'
| summarize count() by AlertName
alerts
| where count_ > 10
| project AlertName, count_
This sequence queries high severity alerts from the last day, counts them by alert type, and filters for frequent alerts.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Querying logs from the SecurityAlert table.
- How many times: Once per query, but the query scans all alerts in the time range.
- Data aggregation: Counting alerts by type involves scanning all matching records.
As the number of alerts grows, the query scans more records, so the time grows roughly in proportion to the number of alerts.
| Input Size (n alerts) | Approx. Api Calls/Operations |
|---|---|
| 10 | Scan 10 alerts |
| 100 | Scan 100 alerts |
| 1000 | Scan 1000 alerts |
Pattern observation: The work grows linearly as the number of alerts increases.
Time Complexity: O(n)
This means the time to process alerts grows directly with the number of alerts collected.
[X] Wrong: "Querying alerts always takes the same time regardless of data size."
[OK] Correct: The query scans all matching alerts, so more alerts mean more work and longer time.
Understanding how data size affects query time in Azure Sentinel helps you design efficient security monitoring solutions.
"What if we added indexing or partitioning to the SecurityAlert table? How would the time complexity change?"