SIEM

1📊 What Is a SIEM?

SIEM stands for Security Information and Event Management, and it's one of the central technologies a SOC runs on. Its job is to collect security information from many systems and give analysts one central place to search, correlate, investigate and detect suspicious activity. Microsoft describes Sentinel as a cloud-native SIEM supporting collection, detection, investigation, response and threat hunting; Splunk Enterprise Security centralises security data the same way; Google Security Operations combines SIEM, SOAR and threat intelligence in one platform.

2⚙️ What a SIEM Actually Does

Imagine a company with 80,000 laptops, 15,000 servers, 1,000 network devices, 500 cloud accounts, and 100 SaaS applications — every one generating logs. Without centralisation, an analyst would need to log into hundreds of systems individually just to look for one thing. A SIEM collects those logs centrally instead, then performs two core functions on the way in.

Collection

Logs are pulled in from every security-relevant system — firewall, domain controller, Linux server, AWS, Entra ID, EDR — into the SIEM.

Parsing

Raw logs get converted into meaningful fields. A raw firewall entry like:

2026-08-30T08:13:21Z allow tcp src=10.1.20.34 dst=198.51.100.40 spt=49134 dpt=443

becomes structured data the SIEM can actually query:

timestamp = 2026-08-30 08:13:21
action = allow
protocol = TCP
source_ip = 10.1.20.34
destination_ip = 198.51.100.40
source_port = 49134
destination_port = 443

Once information is structured like this, analysts can search it — instead of grepping through raw text one log file at a time.

3🔄 Log Normalisation

Different vendors describe the same field differently — one firewall calls it src_ip, another sourceAddress, another client_ip, all meaning essentially the same thing. SIEM platforms normalise fields into common schemas to make cross-platform correlation actually workable: CEF (Common Event Format), LEEF (Log Event Extended Format), ECS (Elastic Common Schema), and OCSF (Open Cybersecurity Schema Framework) are the ones you're most likely to encounter.

4🔗 SIEM Correlation

Correlation is one of the most valuable things a SIEM does. Consider:

08:01 - Failed login for alice
08:01 - Failed login for alice
08:02 - Failed login for alice
08:02 - Failed login for alice
08:03 - Successful login for alice

One failed login is normal. Four failures followed by a success is a lot more interesting. A detection rule might say:

IF 5 failed authentication attempts
   from the same IP against the same account
   within 10 minutes
FOLLOWED BY a successful authentication
THEN generate an alert

This threshold-plus-sequence pattern is the basic concept behind a huge share of SIEM detections — Lesson 2 covers the full range of detection approaches in depth.

5🛠️ SIEM Platforms & Query Languages

The SIEM market has genuinely evolved — modern environments may run cloud-native platforms while older enterprises keep long-established on-premises deployments running alongside them.

IBM continues to document both cloud-native QRadar and traditional on-premises QRadar — exactly the kind of current-vs-legacy coexistence you'll encounter in real enterprises. Don't focus on mastering one SIEM's interface; the transferable skills are understanding logs, writing queries, recognising attack patterns, correlating events, and investigating users/devices/networks/authentication. A SOC analyst doesn't need to memorise every query language, but should be comfortable thinking in terms of: find events, where condition = X, between time A and time B, group by user, count events, sort results. Every query language below is just a different syntax for that same shape of question.

6🔍 Reading Real Investigation Queries

Suppose an analyst wants to investigate failed Windows authentications. In KQL (Microsoft Sentinel / Defender):

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts=count() by Account, IpAddress
| order by FailedAttempts desc

Search Windows Security Events, keep only Event ID 4625 (failed logon), group by account and IP, count the failures, sort highest to lowest. Windows Event ID 4625 is a failed logon and 4624 is a successful one — Lesson 4 covers the full Event ID reference. The same investigation in Splunk (SPL):

index=windows EventCode=4625
| stats count by Account_Name, Source_Network_Address
| sort - count

Different syntax, identical investigation concept — which is exactly why understanding the underlying security data matters more than memorising any one SIEM's query grammar.

7⌛ Legacy SIEM Environments

Established financial institutions, government organisations and large manufacturing companies may run SIEM architectures that look nothing like a modern cloud-native deployment:

Servers → Syslog → Local Collector → Regional Collector
   → Central SIEM → Correlation Engine → SOC Console

These environments often involve physical appliances, dedicated database servers, separate correlation servers, local storage, manual log retention policies, and on-premises disaster recovery. Modern systems increasingly use cloud-scale storage and managed analytics — but legacy SIEM stays important, because large companies rarely replace their entire security infrastructure overnight.

Lesson Outcome

You should now be able to explain what collection, parsing, normalisation and correlation each contribute to a SIEM pipeline, recognise the major SIEM platforms and query languages by name, and read a simple KQL or SPL investigation query for what it's actually asking. Lesson 2 moves from the SIEM to the endpoint itself — EDR, XDR, and the different ways a detection can actually spot an attacker.