Section 4 — SIEM In Depth: The Analytical Brain
In the previous section we followed the log pipeline from production all the way to storage. At the end of that pipeline sits a layer that turns data into decisions, and that is where a SIEM lives.
If a log management system is the warehouse, the SIEM is the analytical brain standing on top of it. This section explains what that brain actually does, how it works, and why without it log data is only a large and useless warehouse.
What a SIEM Is: Definition and Origin
SIEM stands for Security Information and Event Management. The term was coined by Mark Nicolett and Amrit Williams of Gartner in 2005.
It grew out of the merger of two older ideas. SIM, Security Information Management, focused on long-term collection and storage of logs for compliance and analysis. SEM, Security Event Management, focused on real-time monitoring of events and on alerting.
The SIEM merged the two into a single platform. The modern definition fits in one sentence: a SIEM collects security data from across the digital environment of an organisation, analyses it to find patterns and anomalies, and raises an alert when it detects suspicious activity. Behind that sentence sit the layers this section unpacks.
The Three Pillars of a SIEM
Every SIEM, whatever the vendor and whatever the architecture, performs three fundamental jobs: aggregation, correlation, and alerting. Those three are the pillars of the platform, and a product that does not do all three well is only an expensive log manager.
Aggregation
A SIEM collects data from diverse sources: firewalls, servers, identity systems such as Active Directory, applications, and endpoint devices. That data is brought into one platform so the analyst can work from a single view instead of checking dozens of separate systems.
Aggregation differs from log management in one subtle way. A log manager collects everything, while a SIEM usually concentrates on the data that matters for security: authentication logs, access-level changes, network communications, and endpoint events. That focus reduces data volume and keeps cost under control.
Correlation
This is the most important and most differentiating job a SIEM does. Correlation means linking events that look harmless on their own into a pattern that is dangerous. A sign-in from one workstation means nothing by itself. Combine it with a sign-in from a suspicious external IP and a bulk file access event, and a story appears: an attacker with stolen credentials is moving files out.
Microsoft uses a simple example in its official training material. A user signing in at an unusual hour is not alarming on its own. But when that same user then downloads a large volume of sensitive files, the combination of the two is worth investigating. That is exactly what a SIEM does and a log manager cannot.
Correlation is implemented in three main ways inside a SIEM:
- Rule-based: predefined rules that fire when a set of conditions is met. This approach is predictable, auditable, and explainable. Example: "alert if 5 failed logins occur within 30 seconds from one IP".
- Statistical: analysis of deviation from the normal pattern. Instead of an explicit rule, the system builds a baseline of normal behaviour and flags any meaningful deviation. Example: "a service account that normally reads two folders a day has read 200 folders in two hours".
- ML-based: models that learn from historical data and detect more complex patterns. This approach can link multi-stage attacks whose every stage looks harmless on its own.
Alerting
Once correlation reaches a conclusion, the SIEM has to tell a human. An alert can arrive by email, SMS, ticket, or dashboard. An alert on its own is not enough though, because it has to be prioritised.
A mature SIEM ranks alerts by severity and confidence so the analyst knows which ones to handle first. Ranking is what separates a warning an analyst actually reads from a warning that disappears into a queue of ten thousand.
A SIEM whose correlation rules are never tuned is just an expensive log manager with a dashboard. The detection logic is the product, not the storage underneath it.
Use Case: Why a SIEM Without One Is Just an Expensive Screen
One concept inside a SIEM is vital and often overlooked: the Use Case. A use case is a defined scenario in which the SIEM detects, investigates, or responds to a particular security condition. Every use case combines log sources, correlation logic, an alert workflow, and a response action.
The difference between a SIEM with use cases and one without is the difference between an intelligent system and a display. Without them it collects data but does not know what to look for. With them it knows exactly which pattern to hunt for, and what to do when it finds it.
ManageEngine gives a clear example in its documentation. A use case is defined for "detecting abnormal service account behaviour": the system builds a baseline of normal behaviour, say two folders a day. When the same account reads 200 folders in two hours, the deviation is detected and an alert is raised. That use case is neither a simple rule nor a raw alert, but a combination of baseline, deviation analysis, and context.
Real Examples of Correlation Rules
To make correlation concrete, this section walks through five classic SIEM correlation rules. They are shared by many platforms, among them Splunk, QRadar, Sentinel, and Wazuh.
Brute Force
Logic: a large number of failed logins from one source in a short window, followed by a successful one.
Why it matters: a single failed login may be a user mistake. Five failed logins in 30 seconds is the pattern of an automated attack. If a success follows them, the attacker most likely found the password.
Response: lock the account temporarily, raise the alert level, and check whether the successful login came from the same IP.
Impossible Travel
Logic: one user account signs in from two geographically distant locations within a short window, such as a sign-in from New York at 08:00 and another from Tokyo at 08:05.
Why it matters: no human travels from New York to Tokyo in five minutes. This almost certainly means the credentials are compromised: an attacker in Tokyo is using the stolen password while the real user signs in from New York at the same time.
Response: force a password reset, revoke all active sessions, review every action taken in the Tokyo session, and start a full investigation of the credential intrusion.
Privilege Escalation
Logic: a standard user account suddenly runs commands at SYSTEM or Administrator level.
Why it matters: ordinary users should not be able to raise their own access level. This pattern signals either a security vulnerability or an attacker who is trying to take more control.
Data Exfiltration
Logic: a workstation transfers an unusual volume of data, more than 1 gigabyte for example, to an unknown external IP.
Why it matters: exfiltration is the end point of most successful intrusions. If it is not caught at this stage, the data is gone and the damage is irreversible.
The challenge: attackers use varied channels, including DNS tunnelling, uploads to legitimate cloud services, encrypted archives sent to file-sharing sites, or slow transfer spread over several days. Every channel leaves a different telemetry in the source log, so the SIEM has to correlate across network, endpoint, and identity data.
Lateral Movement
Logic: one credential is used to authenticate on several different hosts within a short window.
Why it matters: this pattern, also known as Pass-the-Hash, is the signature of an attacker moving from one compromised machine to others across the network in order to gain more control.
Enrichment with Threat Intelligence
A mature SIEM does not stop at the internal data of the organisation. Threat intelligence is data about known threats that comes from external sources: malicious IP lists, phishing domains, malware file hashes, and similar collections.
The SIEM matches this data against internal events. If an internal user connects to an IP that appears on a list of known threats, the SIEM raises an alert. The Splunk documentation shows how its Threat Intelligence framework parses, normalises, and stores raw data in a dedicated database so that matching against environment events becomes possible. Microsoft Sentinel also provides connectors to TAXII/STIX sources and to TIP platforms.
Enrichment is not only for detection, it matters for prioritisation too. A low-severity alert matched against an active and confirmed threat indicator can be promoted to high priority. Conversely, an alert matched against negative or stale threat intelligence can be suppressed. A university study showed that combining real-time CTI correlation with deduplication can cut the number of alerts handed to analysts to a fraction of the baseline, without losing coverage.
The Challenge of Alert Fatigue
If one thing from this section stays with you, let it be this: a SIEM without alert management destroys the security team.
SOC analysts receive thousands of alerts every day. If most of them are false, the analyst gradually becomes desensitised to all of them and may ignore the real one as well. This condition is called Alert Fatigue, and it is one of the most serious threats to SOC effectiveness.
Modern SIEMs counter it with several mechanisms:
- Incident grouping: related alerts from different sources are merged into a single incident, so the analyst reviews one case with all of its context instead of dozens of separate alerts about one attack.
- Severity scoring: every alert is ranked by its potential impact and by the probability that it is a real threat.
- Automatic enrichment: alerts are automatically enriched with extra context, such as the account history, the device compliance status, geolocation data, and threat intelligence. The analyst has what is needed to decide without searching several systems by hand.
- ML-based false positive reduction: machine learning models trained on historical data tell real threat patterns apart from harmless activity and reduce the number of false alerts.
Alert fatigue is not a reporting problem, it is a security problem. A team that stops reading alerts has lost its only real-time defence, and it usually finds out during the incident it would have caught.
There is one honest caveat. These mechanisms only work when the SIEM is properly tuned. A SIEM with default rules and no tuning will probably produce more false alerts than real ones. Continuous tuning is an inseparable part of operating a SIEM.
The Limits of a SIEM
No tool is complete, and the SIEM has limits that deserve to be stated honestly.
Cost and complexity. A SIEM is expensive. Licence cost, infrastructure, and specialist staff can be prohibitive for small organisations. A 2026 industry report showed that only about half of organisations consider their current SIEM "very effective" at reducing mean time to detect and respond (MTTD/MTTR).
Dependence on data quality. A SIEM is only as good as the data it receives. If a critical log source stops sending, or its log format breaks, the SIEM does not "see" that part of the network at all.
The need for skilled people. A SIEM without trained analysts and without tuned correlation rules is just an expensive screen. Rules have to be written, tested, and updated, because new threats demand new patterns.
The SIEM is itself a target. An attacker who gains access to the SIEM can erase the evidence or suppress the alerts. The security of the SIEM itself, through access control, encryption, and network segregation, matters as much as its analytical capability.
Detection is not containment. A subtle point, highlighted in academic analysis: a SIEM applies no control on its own. It detects, but containing an attack requires being connected to another control, whether that is a firewall, an endpoint system, an identity system, or a human team.
A SIEM holds the record of every incident your organisation has, which makes it one of the highest-value targets an attacker can reach. Protect it like the asset it is, not like a tool that happens to sit in the corner.
Detection and containment are two different products. A SIEM without a response capability is only an observer, so the architecture must connect its findings to something that can act.
Summary
The SIEM is the analytical brain of the log architecture. It pulls raw data out of the warehouse, sees patterns, links apparently unrelated events, and warns the human. Without it, log data is only an archive; with it, that data becomes an alerting system.
Three pillars carry that work, and each one has a clear job.
| Pillar | What it does | What you lose without it |
|---|---|---|
| Aggregation | Brings security-relevant data into one platform | The analyst hunts across dozens of systems |
| Correlation | Links harmless events into a dangerous pattern | The story behind an attack stays hidden |
| Alerting | Prioritises findings and delivers them to a human | Findings sit unread in a queue |
Five correlation rules turn that pattern matching into practice, and they cover the shapes an intrusion takes most often.
| Rule | The pattern it catches | Why it matters |
|---|---|---|
| Brute Force | Many failed logins, then one success | The attacker has found a valid password |
| Impossible Travel | One account in two distant places | The credentials are in another pair of hands |
| Privilege Escalation | An ordinary account running admin commands | A vulnerability or a foothold is being used |
| Data Exfiltration | An unusual volume of data leaving the network | The loss becomes irreversible |
| Lateral Movement | One credential on many hosts | The attacker is spreading inside the network |
None of this is enough on its own. A brain without hands cannot stop an attack, which is why a mature architecture combines the SIEM with SOAR for automated response and with the network control systems that can actually act. That is also why the next section turns to operational challenges and privacy, because those are the things that separate a SIEM on paper from a SIEM in practice.
Previous: Section 3 — Technical Architecture · Next: Section 5 — Operational Challenges and Privacy · All sections