Security Operations: SIEM, SOC & Threat Intelligence

Understand how Security Operations Centers work — SIEM log aggregation, alert triage, threat intelligence integration, and the daily reality of defending an organization.

Hard 75m 3 tasks

Prerequisites: Incident Response & Digital Forensics

Learning Objectives

→ Describe the SOC team structure and analyst tiers
→ Explain how SIEMs ingest, correlate, and alert on log data
→ Write SIEM correlation rules to detect common attack patterns
→ Integrate threat intelligence feeds (IOCs) into security operations
→ Apply the MITRE ATT&CK framework to map and hunt for threats

The Security Operations Center (SOC)

A SOC is the team and facility responsible for monitoring, detecting, and responding to security incidents 24/7.

SOC Analyst Tiers

Tier 1 – Alert Analyst
  Monitor dashboard, triage alerts, escalate
  Tools: SIEM, EDR, ticketing system
  Goal: decide real vs false positive in <15 min

Tier 2 – Incident Responder
  Investigate escalated incidents, contain threats
  Tools: forensic tools, sandbox, SIEM deep dive
  Goal: root cause analysis, containment

Tier 3 – Threat Hunter / Expert
  Proactively hunt for undetected threats
  Tools: threat intel, MITRE ATT&CK, custom scripts
  Goal: find what automated detection missed

Supporting Roles:
  Security Engineer – builds/maintains tools
  Threat Intel Analyst – tracks actors and TTPs
  SOC Manager – metrics, escalation, reporting

SIEM (Security Information and Event Management)

SIEM aggregates logs from all sources and correlates events to detect attacks:

Sources:
  Firewalls      → connection logs
  IDS/IPS        → alert logs
  Web servers    → access logs
  Auth systems   → login events
  Endpoints      → process/file/network events (EDR)
  DNS            → query logs
  DHCP           → IP assignment logs

SIEM Pipeline:
  Log collection → Normalization → Indexing → Correlation → Alert → Ticket

SIEM Log Normalization

Different log formats must be normalized to a common schema:

Firewall log:
  Jan 15 10:23:01 fw1 kernel: DROPPED IN=eth0 SRC=185.x.x.x DST=10.0.0.5 DPORT=22

Auth log:
  Jan 15 10:23:02 server sshd[1234]: Failed password for root from 185.x.x.x port 54321

Normalized (CEF or ECS format):
  timestamp: 2025-01-15T10:23:01Z
  source.ip: 185.x.x.x
  destination.ip: 10.0.0.5
  destination.port: 22
  event.action: blocked / failed-auth
  event.category: network / authentication

Splunk SPL (Search Processing Language)

-- Find all failed SSH logins
index=linux sourcetype=syslog "Failed password"
| rex "from (?<src_ip>\d+\.\d+\.\d+\.\d+)"
| stats count as failures by src_ip
| where failures > 10
| sort -failures

-- Detect brute force followed by success
index=linux sourcetype=syslog ("Failed password" OR "Accepted password")
| rex "(?<status>Failed|Accepted) password for (?<user>\w+) from (?<src_ip>[\d.]+)"
| stats values(status) as statuses, count by src_ip, user
| where array_contains(statuses, "Failed") AND array_contains(statuses, "Accepted")
| rename src_ip as "Attacker IP"

-- Detect large data transfer
index=network
| stats sum(bytes_out) as total_out by src_ip, dst_ip
| where total_out > 100000000
| sort -total_out

Elastic / ECS Queries

// Failed logins from external IPs
{
  "query": {
    "bool": {
      "must": [
        {"match": {"event.action": "authentication_failure"}},
        {"range": {"@timestamp": {"gte": "now-1h"}}}
      ],
      "must_not": [
        {"term": {"source.ip": "10.0.0.0/8"}}
      ]
    }
  },
  "aggs": {
    "by_ip": {
      "terms": {"field": "source.ip", "size": 10}
    }
  }
}

Correlation Rules

Correlation rules fire alerts when specific patterns occur across multiple events:

# Pseudo-code for common correlation rules

# Rule 1: Brute Force Detection
rule BruteForce:
    if count(event.type == "auth_failure", src_ip, 5 minutes) > 10:
        alert("Brute Force", severity="HIGH", src_ip=src_ip)

# Rule 2: Impossible Travel
rule ImpossibleTravel:
    if user logs in from country_A, then from country_B within 2 hours
    and distance(country_A, country_B) / 2 hours > 1000 km/h:
        alert("Impossible Travel", severity="HIGH", user=user)

# Rule 3: Lateral Movement (SMB from workstation to workstation)
rule LateralMovement:
    if SMB connection from workstation to workstation (not server):
        alert("Possible Lateral Movement", severity="MEDIUM")

# Rule 4: Data Exfiltration
rule DataExfil:
    if bytes_out > 100MB from internal host to external IP in 1 hour:
        alert("Possible Data Exfiltration", severity="HIGH")

# Rule 5: PowerShell encoded command (evasion technique)
rule PowerShellEncoded:
    if process.name == "powershell.exe"
    and process.args contains "-EncodedCommand":
        alert("PowerShell Encoded Command", severity="MEDIUM")

Alert Triage Process

1. Receive alert in ticketing system (Jira, ServiceNow, TheHive)
2. Initial context: what triggered it? What asset? What user?
3. Enrich: lookup source IP in threat intel (VirusTotal, MISP, AbuseIPDB)
4. Pivot: look for related events (same IP, same user, same host)
5. Classify:
   - True Positive → escalate or respond
   - False Positive → close with tuning note
   - True Negative → close
6. Document findings in ticket
7. Update SIEM rule if false positive is chronic (tune threshold)

Threat Intelligence

Types of Threat Intel:
  Strategic   – high-level trends for executives
  Operational – campaigns, actor TTPs, playbooks
  Tactical    – IOCs: IPs, hashes, domains, URLs

Sources:
  Commercial: Recorded Future, CrowdStrike Falcon X
  Open Source: MISP, AlienVault OTX, Shodan, VirusTotal
  Feeds: AbuseIPDB, Emerging Threats, URLhaus

IOC Integration:
  IP blocklist → firewall/proxy
  Domain blocklist → DNS sinkhole
  File hash → EDR blocking rules
  YARA rules → SIEM / AV

MITRE ATT&CK Framework

ATT&CK maps adversary techniques to tactics — used for detection, hunting, and gap analysis:

Tactics (columns) → Techniques (rows)
┌─────────────┬──────────────────────────────────┐
│ Tactic      │ Example Techniques               │
├─────────────┼──────────────────────────────────┤
│ Initial     │ Phishing (T1566), Exploit (T1190) │
│ Access      │                                  │
│ Execution   │ PowerShell (T1059.001), Cron     │
│ Persistence │ Registry Run Key, Cron Job       │
│ Priv Escal  │ SUID/SGID (T1548.001)            │
│ Defense Eva │ Obfuscation, Process Injection   │
│ Credential  │ Keylogging, /etc/shadow dump     │
│ Discovery   │ Network Scan, Account Discovery  │
│ Lateral Mov │ SSH, SMB/PsExec, Pass-the-Hash   │
│ Collection  │ Screen Capture, Clipboard        │
│ Exfiltration│ Over HTTP/DNS, Compressed        │
│ Impact      │ Ransomware, Data Destruction     │
└─────────────┴──────────────────────────────────┘

ATT&CK Navigator for Gap Analysis

1. Map your current detection coverage to ATT&CK cells
2. Identify uncovered techniques (gaps)
3. Prioritize new detection rules for most-used techniques
4. Track improvement over time

Example: if Lateral Movement via SMB is uncovered →
  Write Splunk rule for SMB connections between workstations
  Test against attack simulation (Atomic Red Team)

Threat Hunting

Proactive search for threats that evaded automated detection:

Hunt Process:
1. Hypothesis: "Attacker may have used WMI for persistence"
2. Data: query SIEM for wmiprvse.exe spawning child processes
3. Investigate: is this normal in our environment?
4. Find/Clear: confirm or rule out the threat

Hunting Queries:
-- Processes spawned by Office apps (macro execution)
process.parent.name in ("WINWORD.exe", "EXCEL.exe")
AND process.name not in ("splwow64.exe")

-- DNS queries to newly registered domains (< 30 days old)
dns.question.name in [new_domains_feed]

-- Large PowerShell scripts (> 1000 chars in command line)
process.name == "powershell.exe"
AND length(process.args) > 1000

Metrics and KPIs

Mean Time to Detect (MTTD)    – how long before we notice?
Mean Time to Respond (MTTR)   – how long to contain?
False Positive Rate           – % of alerts that are FP
Alert Volume                  – total daily alerts
Dwell Time                    – how long attacker was in before detection

Goals:
  MTTD < 1 hour for P1
  MTTR < 4 hours for P1
  FP rate < 20%
  Dwell time < 24 hours

Write Splunk SPL (or pseudo-code) detection rules for: (1) brute force: >10 failed logins in 5 min from same IP, (2) brute force success: IP in (1) later has successful login, (3) suspicious PowerShell: -EncodedCommand in process args, (4) data exfiltration: >50MB outbound to single external IP in 1 hour, (5) off-hours admin login: admin login between 10pm-6am. Test each rule against sample log data.

✦ Answer the questions to complete this task

What is a correlation rule?

What is alert fatigue?

Build a Python script that: (1) downloads the AbuseIPDB blocklist (or a CSV of malicious IPs), (2) compares against your server's auth.log for any matches, (3) for each match, enriches with VirusTotal (using their free API tier), (4) outputs: IP, confidence score, number of reports, last seen, matched log lines. This simulates SIEM threat intel enrichment.

✦ Answer the questions to complete this task

What is a threat intelligence feed?

Given this attack sequence: (1) phishing email with malicious macro → (2) PowerShell downloads payload → (3) scheduled task persistence → (4) credential dump from LSASS → (5) SMB lateral movement → (6) data compressed and exfiltrated over HTTPS. Map each step to MITRE ATT&CK tactic and technique ID. Then write one detection rule for each step.

✦ Answer the questions to complete this task

What MITRE ATT&CK tactic does 'scheduled task persistence' belong to?

What ATT&CK technique ID covers credential dumping from LSASS?