12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts

From Log Files to a SOC Queue

A Security Information and Event Management (SIEM) platform is the searchable memory of a Security Operations Center (SOC). It pulls logs from many systems, turns messy text into consistent fields, stores those events so you can search them months later, and runs correlation logic that raises alerts when a pattern looks like abuse or a policy break.

SAL1 training content groups SIEM with the other “tools of the trade”: deployments, log parsing, how raw logs become alerts, then alert management, hunting, triage, and reporting. This section is the pipeline. Section 12.2 is how you work the queue in Splunk. Section 12.3 is what a Security Orchestration, Automation, and Response (SOAR) playbook should (and should not) do with those alerts.

The TryHackMe SAL1 SOC Simulator puts Splunk on the Analyst VM. That is the console you will actually search during the hands-on scenarios. Employers also run Microsoft Sentinel, IBM QRadar, Google Chronicle, LogRhythm, Sumo Logic, and the Elastic Stack. Learn Splunk field names and search habits for SAL1, then map the same stages — ingest, parse, index, search, alert — onto whatever brand you meet later. Splunk is the simulator SIEM, not the only SIEM in the industry.

SIEM Deployments

A deployment is not “install one box and hope.” Production SIEMs are staged pipelines:

1. Collection — agents, syslog listeners, API pulls, cloud connectors, HTTP event collectors.
2. Transport — encrypted forwarding so logs are not copied in plaintext across jump hosts.
3. Parsing and normalization — extract fields; map vendor names onto a shared schema.
4. Indexing and storage — make events searchable; apply retention (Splunk’s hot / warm / cold / frozen buckets are one way to say “fast recent data, cheaper old data”).
5. Detection — scheduled searches, correlation, notable events / alerts.
6. Presentation — dashboards, incident queues, and reports.

Splunk roles you will hear in a deployment diagram

On-prem Splunk is often UF → (optional HF) → indexers → search head. Splunk Cloud hides the indexer tier; you still own inputs, sourcetype (the parsing contract), and saved searches. Splunk Enterprise Security adds a notable-event incident model; the SAL1 sim is described as Splunk plus dynamic alerts — treat “alert” as a correlation output with properties, not as a guarantee that Enterprise Security is installed.

Elastic Stack as a comparison, not a replacement

The Elastic Stack uses the same mental model with different names: Beats or Elastic Agent collect (Winlogbeat is the closest analogue to a Windows UF); Logstash or Elasticsearch ingest pipelines parse (grok, JSON, date); Elasticsearch stores and searches; Kibana is the search and alerting UI. Elastic Common Schema (ECS) plays a similar role to Splunk’s Common Information Model (CIM) — shared field names such as source.ip / src so one brute-force detection can cover Windows, VPN, and cloud identity. For SAL1, when you see index=wineventlog EventCode=4625, that is Splunk spelling. The idea “filter failed logons by field” is not Splunk-only.

Deployment patterns and what each is good for

Traps in deployments: collecting without parsing (terabytes of _raw and no src_ip field); mixing time zones so a “10-minute burst” is split across clocks; duplicate forwarding so one 4625 is indexed twice and looks like brute force; dropping verbose logs to save ingest cost and then discovering the forensic trail was in the dropped channel.

Log Sources a Junior Analyst Actually Reads

Windows Security (and Sysmon if present). Failed logon is Event ID 4625. Success is 4624. Lockout is 4740. Explicit credentials are 4648. Sysmon Event ID 1 is process create; 3 is network connect; 10 is process access (credential-dumping hunts). Windows events are XML; a Splunk Windows technical add-on turns them into EventCode, TargetUserName, IpAddress, LogonType, Status, FailureReason.

Linux / syslog. sshd may log Failed password for invalid user admin from 203.0.113.44 port 55821 ssh2. Until a parser extracts user, src_ip, and action, the SIEM only has a sentence.

Web proxy. Method, URL, status, bytes, user, destination. Phishing clicks often show status=200 to a young domain; data leaving over HTTPS may appear as CONNECT tunnels.

Firewall. Source, destination, port, action, rule id. A deny storm to TCP/3389 is scanning. An allow from a finance server to a rare country on 443 can matter more than the denies.

Cloud. AWS CloudTrail ConsoleLogin with a failed authentication error; Entra ID sign-in ResultType values for bad password or lockout; Okta user.session.start failures. These are already JSON, but field names still differ (sourceIPAddress vs ipAddress vs src_ip) until CIM/ECS mapping.

LogonType values worth memorizing for 4624/4625

Status 0xC000006A (wrong password, often in SubStatus) and 0xC000006D (generic logon failure) are “tried a password.” 0xC0000064 is unknown user (spray against names). 0xC0000234 is locked out. Correlation rules should not treat every 4625 as equal: unknown-user sprays, one-account brute force, and lockouts tell different stories.

Parsing: Raw Event, Fields, Then a Common Schema

Think in three layers:

1. Raw event — Splunk’s _raw. Always keep it. When a regex is wrong, _raw is the court record.
2. Parsed fields — key-value pairs from sourcetype rules (JSON, XML, CSV, grok-like regex). Example: EventCode=4625, TargetUserName=svc_backup, IpAddress=203.0.113.88, LogonType=3.
3. Normalized fields — CIM (Splunk) or ECS (Elastic) names such as src, user, action, signature_id. Detection searches should prefer these so one rule covers Windows and VPN and Okta.

Sourcetype is the parsing contract: WinEventLog:Security is not linux_secure and not aws:cloudtrail. Onboard a firewall as generic syslog with no props/transforms and you will hunt with * in _raw while the brute-force saved search looks at empty src fields and never fires.

Parsing failures that look like “the SIEM is broken”: using receipt time instead of the log’s own timestamp (forwarder delay); splitting multiline Windows XML; ingesting JSON cloud logs as a single syslog message so quotes never become fields. Index time vs search time extraction both exist in Splunk; you do not need to administer props.conf for SAL1, but you do need to notice when a field is missing and fall back to _raw plus rex (section 12.2) instead of inventing a verdict.

Correlation: Many Events, One Alert

A single 4625 is usually a typo, a cached credential, or a scanner. Correlation is the logic that says this set of events is notable:

• Threshold: 20 failed logons for the same TargetUserName from the same IpAddress in 5 minutes.
• Diversity (password spray): one source, many distinct TargetUserName values, often 0xC0000064.
• Chain: 4625 burst then 4624 LogonType 10 from the same source — guessing that worked.
• First-seen / impossible travel: more often cloud identity than 4625, but the idea is the same: join two successes that cannot both be physical.
• Allow-list gap: process create for a known-bad name where the hash is not in software inventory.

The correlation search writes an alert (saved-search alert, notable, detection alert — product vocabulary varies). That object is not the raw logs. It carries severity (informational, low, medium, high, critical) and status (new, in progress, pending, suppressed, closed). Severity is how loud the queue should shout if the hypothesis is true. Status is whether a human already owns it. A Critical alert in New jumps the queue. A High alert in Suppressed because it is Tuesday’s authorized scanner may be working as designed. You triage with both properties; you do not mentally downgrade every High because the queue is long.

False-positive engineering happens after you understand this pipeline. If morning VPN reconnects trip brute force, tune the threshold or exclude the concentrator IP. Do not stop collecting 4625.

Worked Pipeline: Windows 4625 to a Brute-Force Alert

Environment. A domain controller runs a Splunk Universal Forwarder. Security events land in index wineventlog, sourcetype WinEventLog:Security. CIM maps IpAddress toward src and TargetUserName toward user, but the add-on fields are what you will type first in the simulator.

One raw event (simplified). Event ID 4625, account svc_backup, source IP 203.0.113.88 (documentation TEST-NET), Logon Type 3 (network), Status 0xC000006D, SubStatus 0xC000006A (wrong password), Workstation WIN-SCAN01. _raw still contains the full XML. After parsing you can filter without grepping XML tags.

Fields the correlation search actually uses.

Correlation logic (concept, not a full SPL course). Over 10 minutes, count 4625s where user svc_backup and source 203.0.113.88. If count ≥ 15, create alert Possible brute force against svc_backup. Because the account looks privileged, LogonType is 3, and volume is high, the rule assigns severity High. Status starts as New. The alert record stores a sample event, the count, the first and last _time, and a link back to the search.

What the alert is not. It is not proof of compromise. It is a hypothesis: this source tried many passwords. Your next job (section 12.2) is to search for a following 4624, unusual process activity, or threat-intel on that IP. If 203.0.113.88 is the vulnerability scanner’s jump box running an authorized password audit, the closing verdict may be false positive or benign true positive depending on local policy — but the pipeline still did the right thing: raw → fields → correlation → alert with severity and status.

If parsing had failed. You would only have _raw XML. A human might still find 4625 and svc_backup with a string search. The saved correlation would not see IpAddress as a field, the count would be wrong or zero, and no High/New notable would enter the queue. Deployment quality is detection quality.

Password spray vs brute force on the same 4625 stream. Twenty failures, one user, one IP is brute force (the worked case). Twenty failures, one IP, twenty users, often unknown-user statuses, is a spray. Same log source, different stats shape, possibly different severity (spray against many employees vs hammering one service account). Write the distinction in the case note; do not use the words interchangeably.

Independent OpenExamPrep material covering these SAL1 SIEM topics will keep using Splunk-oriented examples because that is what the SOC Simulator presents. If a future job hands you Kibana, you will still ask: where is collection, where is parse, where is the correlation that created this alert, and what are its severity and status?