What Are SIEM, SOC and Detection Engineering? A Practical Guide

What Are SIEM, SOC and Detection Engineering? A Practical Guide to Logs, Alerts, Sigma, MITRE ATT&CK and SOC Operations

Raster/preview image checked for display before being inserted into this Markdown file, used to illustrate the Sigma rule repository. Not SVG.¹

Raster/preview image checked for display before being inserted into this Markdown file, used to illustrate the Wazuh open-source SIEM/XDR platform. Not SVG.²

Raster/preview image checked for display before being inserted into this Markdown file, used to illustrate MITRE ATT&CK data. Not SVG.³

Quick summary

SIEM means Security Information and Event Management: a platform that collects, normalizes, stores, correlates and analyzes security data from sources such as endpoints, firewalls, cloud, identity providers, applications, databases, Kubernetes, SaaS and network devices. Its purpose is to detect suspicious behavior, create alerts, support investigations, preserve evidence and help with audit/compliance.

SOC means Security Operations Center: the security operations function responsible for monitoring, alert triage, incident investigation, threat hunting, response, reporting and detection improvement. A SOC is not just a room with screens; it is people, process, data, tooling and authority to act.

Detection Engineering is the practice of designing, writing, testing, deploying, measuring and improving detection logic. Detection engineers do not only write rules; they must understand log sources, attacker behavior, false positives, severity, runbooks, MITRE ATT&CK mapping and response actions.

Elastic describes SIEM as the center of security operations, collecting and correlating data across an environment, detecting threats and giving analysts visibility to investigate and respond.⁴ Splunk describes SIEM as technology that collects, centralizes and analyzes security data in real time to detect, investigate and respond to threats.⁵ MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.⁶ Sigma is a generic and open signature format for describing relevant log events in a straightforward and shareable way.⁷

Simple version: SIEM is the data and alerting platform; SOC is the operating team; Detection Engineering turns attacker behavior into actionable alerts.

Why SIEM/SOC matters

Modern environments produce too many logs:

Endpoint
Cloud
Identity Provider
VPN/ZTNA
Firewall/WAF
API Gateway
Kubernetes
Database
SaaS
CI/CD
Git
DNS
Email security

If data is scattered, IT teams struggle to answer:

• who logged in abnormally?
• which account received admin rights?
• which endpoint ran suspicious PowerShell?
• which API key was used from an unusual location?
• which service account read secrets?
• is lateral movement happening?
• is this alert false positive or a real incident?
• what happened before and after the alert?
• should the team isolate a host, revoke a token or lock an account?

SIEM/SOC centralizes data, adds context, detects patterns and coordinates response.

What SIEM is not

A good SIEM needs the right data, the right rules, the right responders and clear response process.

What SOC is not

A SOC is weak if it receives alerts but cannot request actions such as token revocation, host isolation, IP blocking, rollback or account lockout.

How SIEM works

Typical SIEM flow:

Log sources
  ↓
Collectors / Agents / API integrations
  ↓
Parsing + normalization
  ↓
Enrichment
  ↓
Storage + indexing
  ↓
Detection rules / correlation / analytics
  ↓
Alerts
  ↓
Triage + investigation
  ↓
Incident response + lessons learned

1. Log collection

Common sources:

• Windows Event Logs;
• Sysmon;
• Linux auditd/auth logs;
• EDR alerts;
• firewall/VPN/WAF logs;
• DNS logs;
• proxy logs;
• identity provider logs;
• cloud audit logs;
• Kubernetes audit logs;
• SaaS audit logs;
• CI/CD logs;
• GitHub/GitLab audit logs;
• database audit logs;
• application logs.

2. Normalization

Different sources use different formats. SIEM pipelines map fields such as:

src_ip
dst_ip
user.name
host.name
process.name
event.action
cloud.account.id
kubernetes.namespace
http.request.method

Without consistent fields, detection rules become fragile.

3. Enrichment

Enrichment adds context:

• asset criticality;
• user department;
• threat intelligence;
• geo/IP reputation;
• known admin accounts;
• cloud account type;
• device compliance;
• vulnerability context;
• business owner;
• MITRE ATT&CK technique mapping.

4. Detection

Detection may use:

• simple rules;
• multi-event correlation;
• thresholds;
• anomalies;
• sequence detection;
• machine learning;
• threat intelligence matches;
• behavior analytics;
• Sigma rules converted to SIEM queries.

5. Triage and response

Alerts matter only when someone or something acts:

Alert
  ↓
Triage
  ↓
Confirm true/false positive
  ↓
Scope impact
  ↓
Contain
  ↓
Eradicate
  ↓
Recover
  ↓
Post-incident improvement

NIST SP 800-61 Rev. 2 is a widely used incident response guide with phases such as preparation, detection and analysis, containment/eradication/recovery and post-incident activity.⁸

How MITRE ATT&CK helps SOC teams

MITRE ATT&CK documents tactics and techniques used by adversaries in real-world observations.⁶

SOC teams use ATT&CK to:

• map detection rules to techniques;
• measure coverage by tactic;
• prioritize log sources;
• design threat hunts;
• write use cases;
• run detection gap analysis;
• support purple team work;
• report to leadership;
• connect alerts to attacker behavior.

Example:

Technique: T1059 Command and Scripting Interpreter
Log source: Windows Event Logs, Sysmon, EDR
Detection idea: PowerShell encoded command + network connection + suspicious parent process
Response: isolate host, collect process tree, revoke tokens if needed

ATT&CK should not be dashboard decoration. It should help answer: “what attacker behavior can we see, and where are we blind?”.

What are Sigma rules?

Sigma is a YAML-based detection format for vendor-neutral log detections. SigmaHQ describes Sigma as a generic and open signature format that allows analysts to describe relevant log events in a straightforward and shareable way.⁷

Simple Sigma example:

title: Suspicious PowerShell Encoded Command
id: 11111111-2222-3333-4444-555555555555
status: test
description: Detects PowerShell execution with encoded command argument
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - '-EncodedCommand'
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1059.001

Benefits:

• shareable rules;
• not tied to one SIEM;
• MITRE ATT&CK mapping;
• detection-as-code friendly;
• can convert to Splunk, Elastic, Sentinel, QRadar and other backends.

Limitations:

• still needs tuning;
• field mapping may differ;
• analyst understanding still matters;
• copied internet rules can create false positives.

What is Detection Engineering?

Detection Engineering is the lifecycle of detections:

Threat research
  ↓
Data source mapping
  ↓
Detection logic
  ↓
Testing with real/simulated data
  ↓
Deploy
  ↓
Triage feedback
  ↓
Tune
  ↓
Measure coverage
  ↓
Retire low-value rules

A good detection has:

• clear hypothesis;
• reliable log source;
• explainable logic;
• reasonable severity;
• MITRE ATT&CK mapping;
• false positive expectations;
• triage steps;
• response recommendation;
• owner;
• test case;
• version control.

How to write a SIEM use case

Example:

Name: Suspicious Admin Role Assignment
Goal: detect admin role assignment outside process
Log sources: IdP audit log, cloud IAM log
Logic: admin role assigned to user not in approved admin/break-glass group
Severity: High
MITRE ATT&CK: Persistence / Privilege Escalation
Triage: check ticket, approver, source IP and user agent
Response: revoke role, reset sessions, investigate compromise
False positives: valid change window, new admin onboarding
Owner: IAM/SOC

Use cases should be tied to real risk, not copied rules.

Priority log sources for small SOC teams

Small teams should not ingest everything at once. Prioritize:

Data quality matters more than volume.

Alert triage workflow

A practical triage checklist:

1. What does the alert claim?
2. Is the asset/user important?
3. Is there a valid change or ticket?
4. Is the event repeated?
5. What happened before and after?
6. Which MITRE technique is related?
7. Are there related indicators on the same host/user/IP?
8. Is immediate containment needed?
9. Is it false positive or true positive?
10. Does the rule need tuning?

A useful alert includes:

• clear title;
• severity;
• user/host/IP;
• timestamp;
• raw event link;
• related events;
• MITRE mapping;
• reason it fired;
• false positive hints;
• triage runbook;
• suggested response.

An alert that cannot explain why it fired wastes analyst time.

False positives and alert fatigue

Too many false positives destroy trust in SIEM.

Causes:

• overly broad rules;
• bad parsing;
• missing allowlists;
• missing asset/user context;
• bad thresholds;
• no dev/prod separation;
• change windows not modeled;
• severity too high;
• copied rules without tuning.

Mitigations:

• add context fields;
• use asset criticality;
• maintain reviewed allowlists;
• separate severity and confidence;
• suppress duplicate noise;
• correlate multiple signals;
• use analyst feedback;
• measure false positive rate;
• retire low-value rules.

Severity, confidence and priority

Separate three concepts:

Examples:

Encoded PowerShell on developer laptop:
Severity medium, confidence medium, priority medium

Encoded PowerShell on domain controller:
Severity high, confidence medium, priority high

Impossible travel login to cloud admin:
Severity high, confidence high, priority critical

SIEM vs SOAR vs XDR

Splunk describes SIEM and SOAR as different technologies: SIEM aggregates and analyzes data from many sources, while SOAR prioritizes and responds through automation and orchestration.⁵

How Wazuh fits SIEM/SOC

Wazuh docs describe Wazuh as a free and open-source security platform that unifies XDR and SIEM capabilities and protects workloads across on-premises, virtualized, containerized and cloud-based environments.⁹

Wazuh is often used for:

• endpoint monitoring;
• file integrity monitoring;
• log analysis;
• vulnerability detection;
• compliance;
• active response;
• cloud security monitoring;
• container/Kubernetes monitoring;
• security alert dashboards.

It fits teams starting with open-source SIEM/XDR, SOC labs or small-to-medium environments. It still needs log-source design, rule tuning, storage sizing, retention, backups and response process.

Detection-as-Code

Detections should be managed like code:

rules/
  windows/
  cloud/
  identity/
  kubernetes/
tests/
  sample-events/
  expected-results/
docs/
  runbooks/

Workflow:

Create rule
  ↓
Peer review
  ↓
Test against sample logs
  ↓
Map ATT&CK
  ↓
Deploy staging
  ↓
Monitor false positives
  ↓
Promote production

Benefits:

• version control;
• clear review;
• rollback;
• tests before deployment;
• no unaudited live edits;
• reusable detections.

Threat hunting vs detection

Example hunting hypothesis:

Hypothesis: attackers use valid accounts to access cloud console from unusual locations.
Data: IdP logs, cloud audit logs, VPN logs.
Query: admin login success from unseen country + no phishing-resistant MFA.
Outcome: if real pattern appears, create detection rule.

SOC/SIEM KPIs

Do not measure alert count alone. More alerts does not mean better security.

30/60/90-day rollout roadmap

Days 1–30: data foundation

• Define SIEM/SOC goals.
• Select 5–10 important use cases.
• Connect identity provider logs.
• Connect cloud audit logs.
• Connect endpoint/EDR logs.
• Connect firewall/VPN/ZTNA logs.
• Normalize key fields.
• Create log-source health dashboard.
• Create basic triage runbooks.
• Start measuring false positives.

Days 31–60: detection engineering

• Map use cases to MITRE ATT&CK.
• Write rules with owner, severity and confidence.
• Use Sigma for portable rules where appropriate.
• Add enrichment: asset criticality, user role, geo/IP reputation.
• Create rule review workflow.
• Add sample events and tests.
• Add alert routing.
• Create incident severity matrix.
• Tune noisy alerts.
• Run weekly detection review.

Days 61–90: SOC operations

• Set on-call and escalation.
• Create response playbooks for top incidents.
• Integrate ticket/case management.
• Build threat hunting backlog.
• Measure ATT&CK coverage.
• Add light SOAR for safe enrichment actions.
• Drill phishing/account takeover.
• Drill cloud key compromise.
• Review retention and storage cost.
• Report KPIs to leadership.

Quick checklist

Log sources

• Identity.
• Endpoint.
• Cloud.
• Network.
• Email.
• DNS/proxy.
• Git/CI/CD.
• Kubernetes.
• Database.
• SaaS.

Detection

• Clear use case.
• MITRE mapping.
• Severity/confidence.
• Rule owner.
• Test event.
• False positive note.
• Triage runbook.
• Response step.
• Version control.

SOC process

• Triage queue.
• Escalation path.
• Incident severity.
• Case management.
• Evidence handling.
• Communication plan.
• Post-incident review.
• Detection improvement loop.

Operations

• Log source health alerts.
• Storage/retention plan.
• SIEM config backups.
• Access control.
• Analyst training.
• Rule review cadence.
• KPI dashboard.

Common mistakes

• Ingesting too much data without use cases.
• Too many noisy rules.
• No alert owner.
• No runbooks.
• Not separating severity and confidence.
• Not mapping rules to business risk.
• No log-source health checks.
• No rule testing before production.
• No false positive measurement.
• Copying Sigma rules without field mapping.
• No case management.
• No authority to respond.
• No post-incident improvement.
• Using ATT&CK only as dashboard decoration.

Reference tooling

FAQ

What is SIEM?

SIEM means Security Information and Event Management: a platform that collects, centralizes, analyzes and correlates security data to detect, investigate and respond to threats.⁴⁵

What is SOC?

SOC means Security Operations Center: the security operations function responsible for monitoring, triage, investigation, response, hunting and detection improvement.

What is Detection Engineering?

Detection Engineering is the practice of designing, writing, testing, deploying and improving detection logic that produces actionable threat alerts.

What is a Sigma rule?

A Sigma rule is a vendor-neutral YAML detection rule format that describes interesting log events and can be converted into many SIEM query languages.⁷

What is MITRE ATT&CK used for in SOC?

MITRE ATT&CK maps detections to tactics and techniques, helps measure coverage, supports threat hunting, improves use cases and connects alerts to adversary behavior.⁶

Does SIEM replace EDR?

No. EDR focuses on endpoint telemetry and response. SIEM aggregates broader data sources. They should complement each other.

Conclusion

SIEM, SOC and Detection Engineering are core capabilities for detecting and responding to security incidents in modern IT environments. SIEM is not passive log storage; it needs clear use cases, high-quality data, tested rules, enrichment, triage runbooks and response workflows. SOC is not dashboard watching; it needs authority to investigate, coordinate and act.

A practical start is to pick real risk use cases: account takeover, admin privilege changes, suspicious endpoint execution, cloud key abuse, data export and Git/CI/CD abuse. Then connect the minimum viable log sources, write owned detections, map to MITRE ATT&CK, measure false positives and improve continuously. When operated well, SIEM/SOC shifts teams from passive reaction to active detection and resilience.

References

Footnotes

1. GitHub Open Graph preview image for SigmaHQ/sigma. https://opengraph.githubassets.com/soc-siem-guide/SigmaHQ/sigma ↩

2. GitHub Open Graph preview image for wazuh/wazuh. https://opengraph.githubassets.com/soc-siem-guide/wazuh/wazuh ↩

3. GitHub Open Graph preview image for mitre-attack/attack-stix-data. https://opengraph.githubassets.com/soc-siem-guide/mitre-attack/attack-stix-data ↩

4. Elastic. “SIEM platform.” https://www.elastic.co/security/siem ↩ ↩²

5. Splunk. “SIEM: Security Information & Event Management Explained.” https://www.splunk.com/en_us/blog/learn/siem-security-information-event-management.html ↩ ↩² ↩³

6. MITRE ATT&CK official website. https://attack.mitre.org/ ↩ ↩² ↩³

7. SigmaHQ Sigma repository. https://github.com/SigmaHQ/sigma ↩ ↩² ↩³

8. NIST SP 800-61 Rev. 2. “Computer Security Incident Handling Guide.” https://csrc.nist.gov/pubs/sp/800/61/r2/final ↩

9. Wazuh documentation. “Getting started with Wazuh.” https://documentation.wazuh.com/current/getting-started/index.html ↩