What is SIEM?

What SIEM does

SIEM is the central nervous system of a Security Operations Centre. Its job is to ingest log data from every part of an organisation's infrastructure — firewalls, endpoints, Active Directory, DNS servers, cloud environments, web proxies, databases — normalise all of that data into a consistent format, and then apply detection logic to identify suspicious patterns across it.

Without SIEM, a SOC analyst would need to manually review logs from dozens of separate systems to investigate a single alert. SIEM eliminates that by pulling everything into one place and automating the correlation that would take an analyst hours to do manually.

The critical distinction from simple log storage is correlation. A firewall log showing a connection to an unusual IP address is a single data point — it might mean nothing. But when the SIEM correlates that event with an endpoint log showing PowerShell execution, an AD log showing a privilege escalation attempt, and a DNS log showing a query to a known C2 domain — all within the same 10-minute window — that correlation is what triggers the alert that matters.

How SIEM works technically

The data flow through a SIEM follows a consistent pipeline, regardless of the platform:

1. 1
   Log Collection

   Agents or forwarders installed on source systems (endpoints, servers) send log data to the SIEM. Agentless collection is also common — devices like firewalls send logs via syslog directly.

2. 2
   Parsing and Normalisation

   Raw log data arrives in dozens of different formats. The SIEM parser converts everything into a common schema — extracting fields like timestamp, source IP, destination IP, user, action, and outcome — so events from different sources can be compared directly.

3. 3
   Correlation and Rule Matching

   The correlation engine applies detection rules to the normalised stream. A brute force rule might say: "5 or more Event ID 4625 (failed login) events from the same source IP within 2 minutes, followed by a 4624 (successful login)." When that pattern fires, an alert is generated.

4. 4
   Alert and Enrichment

   The alert lands in the analyst dashboard, enriched with threat intelligence context — is the source IP in a known malicious feed? What user account was involved? What was the endpoint's recent behaviour? This enrichment reduces investigation time significantly.

Key SIEM platforms

Several SIEM platforms dominate the enterprise market. Each has its own query language and deployment model — and knowing at least one of these query languages is a core SOC analyst skill.

• Splunk: The market leader. Uses SPL (Splunk Processing Language) for searching and correlating log data. Extremely powerful and highly extensible. On-premises and cloud deployment options.
• Microsoft Sentinel: Cloud-native SIEM built on Azure. Uses KQL (Kusto Query Language). Deep integration with the Microsoft ecosystem (Azure AD, Microsoft 365, Defender) makes it the default choice for Microsoft-heavy environments.
• IBM QRadar: Enterprise-focused SIEM with strong compliance reporting capabilities. Widely deployed in regulated industries (finance, healthcare, government).
• Elastic SIEM: Open-source option built on the Elastic Stack (Elasticsearch, Logstash, Kibana). Lower cost entry point, highly customisable, but requires more engineering effort to maintain.
• LogRhythm: Mid-market SIEM with strong out-of-the-box detection content and built-in case management.

For career purposes: SPL (Splunk) and KQL (Microsoft Sentinel) are the two most in-demand query language skills for SOC analyst roles. Learn one deeply before learning the other.

Writing detection rules

A SIEM use case is a specific detection scenario that the team has decided is worth monitoring for. Good use cases are precise, based on real attack patterns, and tuned to produce low false positive rates. Poor use cases flood the analyst queue with noise and contribute to alert fatigue.

A well-written use case defines four things: the trigger condition (what pattern of events fires the alert), the required data sources (if you don't have those logs, the rule is blind), the severity level (how urgently should an analyst respond), and the tuning criteria (what legitimate activity looks similar and needs to be excluded).

Example — brute force use case: trigger on 5 or more failed authentication events (Windows Event ID 4625) from the same source IP against the same account within 5 minutes. Exclude service accounts and known vulnerability scanners. Alert at medium severity. Escalate to high if the same source IP is in a threat intelligence feed.

SIEM limitations

SIEM is powerful but has real constraints that every SOC analyst needs to understand:

• Alert fatigue: A poorly tuned SIEM generates thousands of low-fidelity alerts per day. Analysts become desensitised and start dismissing alerts without proper investigation — a dynamic that directly contributed to breaches like Target (2013), where SIEM alerts were ignored.
• Log gaps: The SIEM can only see what gets logged. If a system isn't forwarding logs, the SIEM is blind to events on that system. Log coverage is a continuous hygiene task, not a one-time configuration.
• SIEM vs SOAR: SIEM detects threats and generates alerts. It doesn't take response actions automatically. That is the job of SOAR (Security Orchestration, Automation and Response) — which ingests SIEM alerts and automates the triage and response steps that follow.