Understanding SIEM

Security Information and Event Management (SIEM) gives security teams a central place to collect, search, and analyse security data from across an organisation.

What you will learn

By the end, you should be able to explain how an event becomes an alert, trace the main SIEM data path, and choose a suitable lab platform.

What is SIEM?

Core concept

A SIEM collects logs and security events from systems such as endpoints, servers, applications, identity platforms, and network devices. It makes that data searchable and helps analysts detect, investigate, and report on possible security incidents.

LogsEventsContextDetectionsAlerts

Keep in mind: A SIEM supports security operations but does not prevent every breach. Its effectiveness depends on useful data, tuned detections, and analysts who can investigate and respond.

01LogA record created by a system or application 02EndpointA laptop, desktop computer, or server 03Identity platformA service that manages accounts and sign-ins

What a SIEM is not

SIEMCorrelate security data and support investigation

Log managementStore and search machine data

EDRMonitor and respond on endpoints

Network monitoringAnalyse network metadata, alerts, and packets

SOARCoordinate repeatable response tasks

Connected, but not interchangeable

These capabilities often send data to or work alongside a SIEM. A SIEM brings their evidence together, but it does not replace their specialised collection, investigation, or response functions.

Events, alerts, and incidents

01EventA recorded action, such as a login or process start

→

02AlertA signal that selected events require investigation

→

03IncidentA confirmed or managed security issue supported by the investigation

An alert is not proof

Analysts must validate the supporting evidence before declaring an incident. Severity indicates priority, not certainty.

Why SIEM matters

Detect threats earlier

Correlate activity from multiple systems to reveal suspicious behaviour that may be difficult to identify in a single log source.

Improve visibility

Give analysts a central view of security activity instead of requiring them to search each system separately.

Support compliance

Retain searchable audit trails and produce reports that support organisational and regulatory requirements.

Respond consistently

Prioritise alerts, preserve investigation context, and help teams follow repeatable incident-response processes.

How SIEM works

1. Collect Bring logs and events into the SIEM from endpoints, servers, applications, identity services, cloud platforms, and network devices.
2. Organise Extract useful details, such as a user, device, action, and time, then place different log formats into a consistent structure.
3. Add context and store Add useful information about devices, users, known weaknesses, or threats, then keep the data for searching.
4. Detect and connect Apply detection rules and connect events involving the same user, device, address, or time period.
5. Alert and prioritise Create an alert for an analyst to check and rank it using the available context.
6. Investigate Let an analyst check what happened, identify what may be affected, and decide whether the alert is a real concern or a false alarm.
7. Respond and improve Contain confirmed incidents, record the outcome, and tune detections using what the team learned.

Investigate a SIEM alert

Open an alert, inspect the supporting events, and decide what the evidence justifies. An alert starts an investigation; it does not prove that an incident occurred.

Try it: make an evidence-based decision

Select each event in an alert, read the analyst note, and then choose the most defensible next step. Try all three alerts. The goal is not to find the most severe option; it is to choose the action supported by the current evidence.

SIEM alert console 3 open alerts

High10:18 Suspicious account activity Identity, endpoint, and network events Medium09:42 Inbound port scan blocked Firewall denied all connections Low08:15 Administrative login Known support account and device

High priority Suspicious account activity Three sources refer to user j.lee and device FIN-LT-22 within six minutes.

10:12Unusual sign-inIdentity 10:15PowerShell startedEndpoint 10:18New outbound domainNetwork

SourceIdentity provider

Userj.lee

DeviceFIN-LT-22

Key detailSuccessful login from 203.0.113.77 after 8 failures

Confirm whether the address belongs to an approved VPN or expected travel.

Declare incident Continue investigating Close alert Reset exercise

Review the evidence Select each event, then choose the most defensible next step.

Exercise debrief

A high-priority alert is not automatically a confirmed incident. For the suspicious account alert, the evidence supports further investigation: validate the sign-in context, decode the PowerShell command, and assess the destination. The blocked scan and approved administrative activity can be closed after the stated verification is recorded. In every case, the evidence—not the severity label—drives the decision.

What makes a SIEM useful

Start with an evidence question

Can we detect misuse of a privileged account?

1. 1Select dataIdentify the events needed to answer the question.
2. 2Verify qualityCheck fields, timestamps, coverage, and ownership.
3. 3Test detectionConfirm the rule finds the intended behaviour.
4. 4Guide investigationDocument what analysts should validate and record.

! Plan for operational friction

Missing logs Inconsistent fields Clock differences Noisy rules Storage costs Unclear ownership

Automation can reduce repetitive work, but the platform still needs monitoring, tuning, access control, and analyst time.

Security monitoring platforms in this kit

The three platforms in this kit overlap, but they are not equivalent SIEM products. The comparison is a practical guide for choosing a first lab.

Diverse log analytics

Splunk

Choose it when: You need to collect and search many kinds of machine data.

Evidence: Logs and events from business and security systems.

Strength: Flexible searches, dashboards, alerts, and integrations.

Plan for licensing, incoming data volume, and data organisation. Splunk Enterprise Security adds dedicated SIEM features. Endpoint-led monitoring

Wazuh

Choose it when: Endpoint activity, file changes, known weaknesses, compliance, and controlled response are the main goals.

Evidence: Endpoint-agent activity plus selected network and application logs.

Strength: Open-source monitoring, detection rules, vulnerability information, and response actions.

Plan to operate the supporting systems, parse required log formats, tune rules, and test response actions. Network-led investigation

Security Onion

Choose it when: Network evidence, packet visibility, proactive searching, and an integrated analyst workflow are the main goals.

Evidence: Zeek summaries, Suricata alerts, packet captures, and endpoint activity.

Strength: Search, alerts, cases, packet inspection, and custom detections.

Plan sensor placement, retained data volume, and how analysts will use the integrated tools.

Choose one evidence path first

Start with Splunk for diverse logs, Wazuh for endpoint-led monitoring, or Security Onion for network-led investigation. Add integrations only after the first platform has a measurable, working data path.

Continue learning

• Explore Splunk to install a lab, collect network and endpoint events, and practise searches, alerts, reports, and dashboards.
• Explore Wazuh to build an open-source monitoring lab, investigate detections, test response, and complete an independent challenge.
• Explore Security Onion for network security monitoring and investigation.