SIEM alerts are the notifications Security generates when a detection rule matches incoming event data. Every alert represents a single event or pattern the system flagged as worth analyst attention. All alerts — regardless of source — land in the same queue.
How Alerts Are Generated
Alerts come from several sources and land in the queue through different paths:
- Detection rules — Sigma, KQL, and behavioral rules run against normalized events as they arrive. When a rule matches, an alert is created with the matching event data attached.
- IOC matching — the IOC matcher runs every 15 minutes across all tenants, comparing event data against active IOC feeds. Matches produce alerts with the matched indicator attached.
- Endpoint agents — RMM agents push process, network, and file telemetry. Events that trigger behavioral rules generate alerts directly.
- Alert correlation — the correlation engine runs every 5 minutes and groups related alerts into incidents. Individual alerts remain in the queue; a linked incident is created separately when the engine sees a pattern.
Severity Levels
Alerts use four severity levels:
| Severity | Meaning |
|---|---|
| Critical | High-confidence threat requiring immediate action |
| High | Strong indicator of malicious or suspicious activity |
| Medium | Anomalous behavior that warrants review |
| Low | Informational or low-confidence signal |
Severity is set by the detection rule or IOC that produced the alert. You can adjust a rule's severity if the default level does not match your environment's noise level.
The Alert Queue
The alert queue is the primary working view for SOC analysts. Key behaviors:
- Defaults to newest-first sort. Switch to sort by severity to prioritize critical alerts.
- Filter by: severity, status, client org, device, MITRE technique, and source.
- Each row shows: title, severity badge, source, affected device or user, MITRE technique tag, and timestamp.
- Status values: New, Investigating, Closed, False Positive.
Alert Statuses
| Status | When to use |
|---|---|
| New | Default state when an alert arrives |
| Investigating | You have opened the alert and are actively working it |
| Closed | Alert has been reviewed and addressed |
| False Positive | Alert was triggered by benign activity; verdict is logged for tuning |
When you mark an alert as False Positive or Benign, you are prompted to add a note. That verdict is stored and surfaced in Alert Tuning so the rule can be suppressed or adjusted.
Real-Time Stream
A live event stream is available for analysts who want to watch alerts as they land. Open Alerts → Stream to enable it. The stream shows new alerts in real time and does not backfill historical events. For historical analysis, use Threat Hunt.
Managing Alert Volume
A high-volume queue is a sign that rules need tuning. See Threat Detection Rules for how to adjust rule thresholds, and Investigating Alerts for the triage workflow.
If the same alert is flooding the queue repeatedly, go to Alert Tuning to review suggestions. Suppressions can be scoped to a specific rule, client, or asset fingerprint.
FAQ
Why are alerts grouped into an incident without me doing anything? The correlation engine runs every 5 minutes and automatically groups related alerts into an attack storyline. You can review the grouping in the incident detail and unlink any alerts that do not belong.
Can I create an alert manually? No. Alerts are generated by the detection engine. To track an issue that has no matching alert, create a Finding directly, which is a durable record not tied to a detection event.
How do I stop a specific alert from firing? Go to Alert Tuning, find the rule producing the alert, and approve a suppression suggestion — or open the rule and add a suppression manually. See Threat Detection Rules.