SIEM and Monitoring

Scope

What this is: Security Information and Event Management - log aggregation, correlation, and threat detection through centralized monitoring.

Competition relevance: Defensive operations (blue team). Core defensive skill for threat detection.

Why it matters: SIEM platforms enable detection of complex multi-stage attacks through log correlation. Competition scenarios require creating detection rules and investigating alerts.

WSOS 2026 alignment: This topic directly supports Section 5: Secure systems protection and defence (monitoring for threats) and Section 4: Secure systems operation and maintenance (maintaining security monitoring infrastructure).

Competition area: Core to the defensive operations area, where you configure SIEM rules, correlate security events, and create detection logic for threats.

Offline competence: SIEM platforms (Splunk, ELK, Graylog) work offline with local data. SPL (Splunk Processing Language) and KQL (Kibana Query Language) syntax is available in offline documentation. Maintain offline SIEM query cheat sheets and common detection rule templates.

Competency Matrix

Level	Expectation
Regional	Basic SIEM queries. Filter by time/source.
National	Create detection rules. Correlate multi-source events.
Squad/Team Selection	Tune rules to reduce false positives. Advanced queries.

---

Technical Content

Log Correlation

Multi-source correlation:

1. Windows Event Logs (4624 successful logon)
2. Firewall logs (connection from external IP)
3. Web server logs (POST to /admin)

Timeline:

10:00:00 - Failed login (Windows Event 4625)
10:00:05 - Failed login (Windows Event 4625)
10:00:10 - Successful login (Windows Event 4624) <- Brute force success
10:00:15 - Firewall: Allow 192.168.1.100:443 <- Lateral movement
10:00:20 - Web: POST /admin/upload <- Malicious upload

---

Rule Creation

Splunk SPL:

# Detect brute force
index=windows EventCode=4625
| stats count by user
| where count > 5

# Detect privilege escalation
index=windows EventCode=4672
| search Account_Name!=SYSTEM

# Detect lateral movement
index=firewall action=allow dest_port=445
| search src_ip!=internal_subnet

Elastic Query DSL:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "event.code": "4625" }},
        { "range": { "@timestamp": { "gte": "now-1h" }}}
      ]
    }
  },
  "aggs": {
    "by_user": {
      "terms": { "field": "user.name" },
      "aggs": {
        "failed_count": {
          "value_count": { "field": "user.name" }
        }
      }
    }
  }
}

---

False Positive Reduction

Whitelisting:

# Exclude known scanners
index=firewall action=deny
| search src_ip!=192.168.1.5  # Vulnerability scanner

Threshold tuning:

# Increase threshold from 5 to 10 failed logins
index=windows EventCode=4625
| stats count by user
| where count > 10  # Was 5, too noisy

Time windowing:

# Detect brute force in 5-minute window
index=windows EventCode=4625
| bucket _time span=5m
| stats count by user, _time
| where count > 5

---

Alerting

Alert criteria:

• Severity level
• Frequency (every occurrence vs threshold)
• Recipients
• Automated response (block IP, disable account)

---

Competition Strategy & Marking

What gets marked:

• See specific task requirements

Evidence and reporting requirements: Evidence and reporting requirements:

• Screenshot showing SIEM query used (SPL, KQL, or Elasticsearch DSL syntax visible)

• Screenshot showing query results with matched events and relevant fields

• For detection rule creation: screenshot showing rule definition with detection logic, thresholds, and alert conditions

• For log correlation: screenshot showing timeline of correlated events across multiple log sources (firewall + auth logs + application logs)

• For false positive tuning: before/after alert counts showing noise reduction and explanation of tuning approach

• Written explanation of detection logic, what threats it identifies, and why thresholds were chosen

• Clear file naming: siem_query_bruteforce.png, siem_rule_definition.png, siem_correlation_attack_chain.png

• Start with pre-built dashboards

• Create custom queries for specific IOCs

• Document all queries used

• Time limit: 60 minutes for SIEM tasks

Time-boxed drill suggestion: 50-minute SIEM detection sprint: Given a SIEM instance (Splunk/ELK) with 24 hours of logs (Windows Security, firewall, web server), create queries to detect: failed login brute force (threshold >10 in 5 minutes), lateral movement via SMB (Event 5140 from unusual sources), privilege escalation (Event 4672), suspicious PowerShell execution (Event 4104 with encoded commands), and large outbound data transfers. Create at least 3 production-ready detection rules with tuned thresholds, correlate events to identify a simulated attack campaign, and document findings with query screenshots. This drill should work entirely offline with locally-loaded log files.

---

False Flags / Wrong Paths

Common Traps

Time-consuming rabbit holes If a single approach takes more than the allocated time-box, reassess and try alternative methods or move to next task.

Over-complication Competition scenarios test core skills. If solution seems overly complex, look for simpler approach.

---

Practice Checklist

• Can complete core tasks without documentation
• Understand key concepts and techniques
• Can document findings with proper evidence format
• Can complete realistic scenarios within time limits

---

References

Primary references:

• WSOS 2026: the sections this page supports are listed under Scope
• Competition stage roadmap: See ../../00-roadmaps/[stage].md

Related topics in this knowledge base:

• Cross-reference related topics as appropriate

External resources (for offline preparation):

• Tool documentation: man pages, —help flags, /usr/share/doc
• Maintain offline copies of key references