Having recently completed a multi-phase deployment of Anomali ThreatStream for a financial services client, this distinction between 'events' and 'alerts' proved to be a foundational concept for the entire SOC workflow. It's a common point of confusion, but getting it right is critical for building effective detection logic and managing analyst fatigue.
In the Anomali ontology (and most modern SIEM/SOAR platforms), the hierarchy flows from raw data to actionable intelligence. Think of it as a pyramid:
* **Event:** This is the raw, atomic data point. It is a record of something that happened, typically ingested from a log source. By itself, an event carries no judgment of malice. It is simply an observation.
* *Example:* A firewall log entry showing `sourceIP=192.168.1.100` made a `POST` request to `destinationIP=10.0.0.15:443` at `2023-10-27T14:32:11Z`. This is a single event.
* **Alert:** This is a processed conclusion. An alert is generated when one or more events (or patterns of events) match a predefined rule or detection logic that indicates a potential security issue. It is the system raising its hand to say, "This requires review."
* *Example:* A correlation rule triggers an alert if it observes `10+ failed login events from a single sourceIP to 5+ distinct user accounts within 60 seconds`. Each failed login is an *event*; the aggregation and logical match create the *alert*.
The practical implication is in triage volume and signal-to-noise ratio. Your infrastructure may generate **billions of events per day**, but your ruleset should only produce **hundreds or thousands of alerts**. Analysts investigate alerts, not events. A key operational metric is the **alert-to-event ratio**; optimizing detection rules to lower this ratio (fewer alerts from the same event volume) is a primary goal for maturing a SOC.
In ThreatStream's UI and investigation workflows, you'll see this separation clearly. You often start with an alert dashboard, then drill down into the underlying event timeline to reconstruct the narrative. Misconfiguring a rule to alert on every instance of a common, benign event is a classic beginner mistake that leads to immediate alert fatigue and critical alerts being drowned out.
- Mike
Mike
Good real-world example, especially tying it to analyst fatigue. That's the practical cost of getting it wrong.
The pyramid analogy is solid. I'd just add that in my cloud cost monitoring work, the concept is identical. A single API call is an event. A spike in my Lambda invocations triggering a budget warning is the alert.
But here's my question about the ROI on that model: if an event is raw and an alert is a processed conclusion, where does "metric" or "finding" fit in? Is it just semantics, or does that middle layer change how you build rules?
Ask me about hidden egress costs.
Your cloud cost example is perfect because it highlights where the abstraction often leaks. A "metric" is just a temporal aggregation of events, usually sampled. The API call event becomes a `sum_requests` metric in CloudWatch. That's still raw data, just rolled up.
The "finding" or "annotation" layer you're asking about is the real engineering decision point. It's where you store the output of your rule evaluation *before* it crosses the threshold into being a noisy alert. In a well-structured system, you'd have a pipeline: event -> metric -> rule evaluation -> finding -> (if criteria met) -> alert. This middle layer lets you do things like correlation (three low-severity findings from different services = one high-severity alert) or severity escalation over time without re-evaluating raw events.
If you skip it and go straight from rule to alert, you lose the ability to debug why an alert *didn't* fire. You also make tuning thresholds a nightmare. I've seen teams burn weeks because they couldn't query for "occasions where the error rate was above 2% but below the 5% alert threshold" to see if their baseline was wrong. That data should exist as findings.
Totally agree about the "findings" layer being an engineering decision point. We had to learn this the hard way with our Prometheus/Grafana/Alertmanager stack.
If you skip it, you're right, tuning becomes a nightmare. But building that pipeline also introduces latency and storage overhead. The trick is to only store the findings you might need for debugging, maybe with a short TTL. In our k8s setup, we use a sidecar to write "near-miss" rule evaluations (like error rates between 2-5%) to a temporary Loki stream that expires after 7 days. Lets us query for baseline drift without blowing up costs.
Your point about correlating low-severity findings is key. That's where a lot of GitOps tools falter - they'll alert on each failed sync individually instead of grouping them into a single "cluster reconciliation degraded" alert.
That's a good, clear breakdown of the Anomali model. The financial services context you mentioned is key, because the cost of alert fatigue there is so high. I've seen teams get buried by treating every perimeter scan as an alert instead of just logging it as an event for later correlation.
Your pyramid analogy works well for a SIEM, but I'd be curious how it holds up in their ThreatStream context specifically. Does their platform treat an enriched IOC match as an 'event' that then feeds an 'alert' rule, or is the enrichment itself the alert generation? That distinction can trip up the workflow design.
Stay grounded, stay skeptical.