SIEM, SOC và Detection Engineering là gì? Hướng dẫn log, cảnh báo, Sigma và MITRE ATT&CK

SIEM, SOC và Detection Engineering là gì? Hướng dẫn log, cảnh báo, Sigma, MITRE ATT&CK và vận hành SOC

Ảnh preview/raster đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho Sigma rule repository. Không dùng SVG.¹

Ảnh preview/raster đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho nền tảng SIEM/XDR mã nguồn mở Wazuh. Không dùng SVG.²

Ảnh preview/raster đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho dữ liệu MITRE ATT&CK. Không dùng SVG.³

Tóm tắt nhanh

SIEM là viết tắt của Security Information and Event Management: nền tảng thu thập, chuẩn hóa, lưu trữ, tương quan và phân tích dữ liệu bảo mật từ nhiều nguồn như endpoint, firewall, cloud, identity provider, ứng dụng, database, Kubernetes, SaaS và network devices. Mục tiêu của SIEM là phát hiện hành vi đáng ngờ, tạo cảnh báo, hỗ trợ điều tra, lưu bằng chứng và đáp ứng yêu cầu audit/compliance.

SOC là viết tắt của Security Operations Center: đội hoặc chức năng vận hành an ninh, chịu trách nhiệm giám sát, triage cảnh báo, điều tra sự cố, threat hunting, response, reporting và cải tiến detection. SOC không chỉ là một phòng có màn hình lớn; SOC là quy trình, con người, dữ liệu, công cụ và quyền hành động.

Detection Engineering là thực hành thiết kế, viết, kiểm thử, triển khai, đo lường và cải tiến các logic phát hiện mối đe dọa. Detection engineer không chỉ viết rule; họ phải hiểu log source, attacker behavior, false positive, severity, runbook, MITRE ATT&CK mapping và phản hồi sau cảnh báo.

Elastic mô tả SIEM là nền tảng trung tâm của security operations, thu thập và tương quan dữ liệu trong môi trường, phát hiện mối đe dọa và cho analyst khả năng điều tra/phản hồi.⁴ Splunk mô tả SIEM là công nghệ thu thập, tập trung và phân tích dữ liệu bảo mật theo thời gian thực để phát hiện, điều tra và phản hồi threat.⁵ MITRE ATT&CK là knowledge base toàn cầu về adversary tactics and techniques dựa trên quan sát thực tế.⁶ Sigma là định dạng chữ ký mở/generic để mô tả log events liên quan theo cách dễ viết và có thể chuyển đổi sang nhiều SIEM query language.⁷

Nói ngắn gọn: SIEM là nền tảng dữ liệu và cảnh báo; SOC là đội vận hành; Detection Engineering là cách biến hiểu biết về attacker thành cảnh báo có thể hành động.

Vì sao SIEM/SOC quan trọng?

Hệ thống hiện đại có quá nhiều nguồn log:

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

Nếu dữ liệu nằm rải rác, đội IT khó trả lời:

• ai đăng nhập bất thường?
• tài khoản nào vừa được cấp admin?
• endpoint nào chạy PowerShell đáng ngờ?
• API key nào vừa bị dùng từ location lạ?
• service account nào vừa đọc secret?
• có lateral movement không?
• alert này là false positive hay incident thật?
• sự kiện nào xảy ra trước và sau cảnh báo?
• cần cô lập endpoint, revoke token hay khóa tài khoản?

SIEM/SOC giúp gom dữ liệu, tạo ngữ cảnh, phát hiện pattern và điều phối phản ứng.

SIEM không phải là gì?

SIEM tốt cần dữ liệu đúng, rule đúng, người xử lý đúng và quy trình response rõ.

SOC không phải là gì?

SOC không hiệu quả nếu chỉ nhận alert nhưng không có quyền yêu cầu hành động như revoke token, isolate host, block IP, rollback deployment hoặc khóa tài khoản.

SIEM hoạt động thế nào?

Luồng SIEM điển hình:

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

1. Thu thập log

Nguồn thường gặp:

• 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. Chuẩn hóa dữ liệu

Các nguồn log có format khác nhau. SIEM cần parse và map field:

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

Nếu field không chuẩn, rule khó viết và dễ sai.

3. Enrichment

Enrichment thêm ngữ cảnh:

• 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 có thể là:

• rule đơn giản;
• correlation nhiều sự kiện;
• threshold;
• anomaly;
• sequence detection;
• machine learning;
• threat intel match;
• behavior analytics;
• Sigma rule converted sang SIEM query.

5. Triage và response

Alert chỉ có giá trị nếu có người hoặc automation xử lý:

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

NIST SP 800-61 Rev. 2 là hướng dẫn xử lý incident response phổ biến, chia hoạt động thành các giai đoạn như preparation, detection and analysis, containment/eradication/recovery, và post-incident activity.⁸

MITRE ATT&CK dùng trong SOC thế nào?

MITRE ATT&CK mô tả các tactics và techniques mà adversary dùng trong thực tế. MITRE nói ATT&CK là globally-accessible knowledge base về adversary tactics and techniques dựa trên real-world observations.⁶

Trong SOC, ATT&CK dùng để:

• map detection rule với technique;
• đo coverage theo tactics;
• ưu tiên log source;
• thiết kế threat hunting;
• viết use case;
• làm detection gap analysis;
• hỗ trợ purple team;
• viết báo cáo cho quản lý;
• liên kết alert với hành vi attacker.

Ví dụ:

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

Không nên dùng ATT&CK chỉ để trang trí report. Nó nên giúp trả lời: “chúng ta đang phát hiện được hành vi nào và còn mù ở đâu?”.

Sigma rules là gì?

Sigma là định dạng rule dùng YAML để mô tả log-based detections theo cách vendor-neutral. SigmaHQ mô tả Sigma là generic and open signature format, cho phép mô tả relevant log events theo cách straightforward; mục tiêu là làm detection methods có cấu trúc và shareable.⁷

Ví dụ Sigma đơn giản:

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

Ưu điểm:

• dễ chia sẻ;
• không phụ thuộc một SIEM duy nhất;
• map được MITRE ATT&CK;
• thuận lợi cho detection-as-code;
• có thể convert sang Splunk, Elastic, Sentinel, QRadar và nhiều backend.

Nhược điểm:

• vẫn cần tuning theo log source thật;
• field mapping có thể lệch;
• không thay thế hiểu biết analyst;
• rule copy từ internet có thể tạo nhiều false positive.

Detection Engineering là gì?

Detection Engineering là vòng đời kỹ thuật của detection:

Threat research
  ↓
Data source mapping
  ↓
Detection logic
  ↓
Test bằng dữ liệu thật/mô phỏng
  ↓
Deploy
  ↓
Triage feedback
  ↓
Tune
  ↓
Measure coverage
  ↓
Retire rule khi không còn giá trị

Một detection tốt cần có:

• giả thuyết rõ;
• log source đáng tin;
• rule logic có thể giải thích;
• severity hợp lý;
• MITRE ATT&CK mapping;
• false positive expectation;
• triage steps;
• response recommendation;
• owner;
• test case;
• version control.

Use case SIEM nên viết thế nào?

Mẫu use case:

Tên: Suspicious Admin Role Assignment
Mục tiêu: phát hiện tài khoản được cấp quyền admin ngoài quy trình
Nguồn log: IdP audit log, cloud IAM log
Logic: role admin được gán cho user không thuộc nhóm break-glass/admin-approved
Severity: High
MITRE ATT&CK: Persistence / Privilege Escalation
Triage: kiểm tra ticket, người phê duyệt, source IP, user agent
Response: revoke role, reset session, điều tra user bị compromise
False positives: change window hợp lệ, onboarding admin mới
Owner: IAM/SOC

Use case nên gắn với rủi ro thật, không chỉ copy rule.

Nguồn log ưu tiên cho SOC nhỏ

Nếu đội nhỏ, không nên thu mọi thứ ngay. Ưu tiên:

Chất lượng log quan trọng hơn số lượng log.

Triage alert như thế nào?

Mẫu triage:

1. Alert nói gì?
2. Asset/user có quan trọng không?
3. Có thay đổi hợp lệ hoặc ticket không?
4. Sự kiện có lặp lại không?
5. Có dấu hiệu trước/sau không?
6. Có liên quan MITRE technique nào?
7. Có indicator khác cùng host/user/IP không?
8. Có cần containment ngay không?
9. False positive hay true positive?
10. Rule cần tuning không?

Thông tin cần có trong alert:

• title rõ;
• severity;
• user/host/IP;
• timestamp;
• raw event link;
• related events;
• MITRE mapping;
• why this fired;
• false positive hints;
• triage runbook;
• suggested response.

Alert không giải thích được vì sao nó fired sẽ làm analyst mất thời gian.

False positive và alert fatigue

False positive nhiều làm SOC mất niềm tin vào SIEM.

Nguyên nhân:

• rule quá rộng;
• log source không chuẩn;
• thiếu allowlist;
• thiếu context asset/user;
• threshold không phù hợp;
• không phân biệt dev/prod;
• không có change window;
• severity quá cao;
• copy rule từ internet không tuning.

Cách giảm:

• thêm field context;
• dùng asset criticality;
• allowlist có review;
• tách severity và confidence;
• suppress alert lặp;
• correlation nhiều tín hiệu;
• tuning theo feedback analyst;
• đo false positive rate;
• retire rule không còn giá trị.

Severity, confidence và priority

Nên tách ba khái niệm:

Ví dụ:

Encoded PowerShell trên laptop dev:
Severity medium, confidence medium, priority medium

Encoded PowerShell trên domain controller:
Severity high, confidence medium, priority high

Successful login impossible travel vào cloud admin:
Severity high, confidence high, priority critical

SIEM, SOAR, XDR khác nhau thế nào?

Splunk mô tả SIEM và SOAR là hai công nghệ khác nhau: SIEM tổng hợp và phân tích dữ liệu từ nhiều nguồn, còn SOAR ưu tiên và phản hồi sự cố bằng automation/orchestration.⁵

Wazuh dùng trong SIEM/SOC thế nào?

Wazuh docs mô tả Wazuh là free and open source security platform, hợp nhất XDR và SIEM capabilities, bảo vệ workload on-premises, virtualized, containerized và cloud-based.⁹

Wazuh thường dùng cho:

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

Phù hợp cho team muốn bắt đầu với open-source SIEM/XDR, lab SOC hoặc môi trường vừa và nhỏ. Tuy nhiên vẫn cần thiết kế log source, tuning rule, storage sizing, retention, backup và quy trình response.

Detection-as-Code

Detection nên được quản lý như code:

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

Quy trình:

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

Lợi ích:

• version control;
• review rõ;
• rollback rule;
• test trước deploy;
• tránh chỉnh rule trực tiếp không audit;
• chia sẻ giữa team.

Threat hunting khác detection thế nào?

Ví dụ hunting hypothesis:

Giả thuyết: attacker dùng valid accounts để truy cập cloud console từ location lạ.
Dữ liệu: IdP logs, cloud audit logs, VPN logs.
Query: admin login success từ quốc gia chưa từng thấy + không có MFA phishing-resistant.
Kết quả: nếu thấy pattern thật, tạo detection rule mới.

KPI cho SOC/SIEM

Không nên chỉ đo số alert. Nhiều alert không đồng nghĩa bảo mật tốt hơn.

Roadmap 30/60/90 ngày

Ngày 1–30: nền tảng dữ liệu

• Xác định mục tiêu SIEM/SOC.
• Chọn 5–10 use case quan trọng.
• Kết nối identity provider logs.
• Kết nối cloud audit logs.
• Kết nối endpoint/EDR logs.
• Kết nối firewall/VPN/ZTNA logs.
• Chuẩn hóa field cơ bản.
• Tạo dashboard log source health.
• Tạo runbook triage cơ bản.
• Bắt đầu đo false positive.

Ngày 31–60: detection engineering

• Map use case với MITRE ATT&CK.
• Viết rule có owner, severity, confidence.
• Dùng Sigma cho rule portable nếu phù hợp.
• Thêm enrichment: asset criticality, user role, geo/IP reputation.
• Tạo workflow review rule.
• Tạo sample events và test.
• Thêm alert routing.
• Tạo incident severity matrix.
• Tuning alert ồn.
• Bắt đầu weekly detection review.

Ngày 61–90: SOC vận hành

• Thiết lập on-call/escalation.
• Tạo playbook response cho top incident.
• Tích hợp ticket/case management.
• Tạo threat hunting backlog.
• Đo ATT&CK coverage.
• Thêm SOAR nhẹ cho action an toàn như enrich IP/hash/user.
• Diễn tập phishing/account takeover.
• Diễn tập cloud key compromise.
• Review retention và storage cost.
• Báo cáo KPI cho quản lý.

Checklist triển khai nhanh

Log source

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

Detection

• Use case rõ.
• 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 alert.
• Storage/retention plan.
• Backup SIEM config.
• Access control.
• Analyst training.
• Rule review cadence.
• KPI dashboard.

Sai lầm phổ biến

• Thu quá nhiều log nhưng không có use case.
• Rule quá nhiều, alert quá ồn.
• Không có người owner alert.
• Không có runbook.
• Không phân biệt severity và confidence.
• Không map rule với rủi ro doanh nghiệp.
• Không kiểm tra log source health.
• Không test rule trước production.
• Không đo false positive.
• Copy Sigma rule nhưng không field mapping.
• Không có case management.
• Không có quyền response.
• Không cải tiến sau incident.
• Dùng ATT&CK chỉ để trang trí dashboard.

Tooling tham khảo

FAQ

SIEM là gì?

SIEM là Security Information and Event Management: nền tảng thu thập, tập trung, phân tích và tương quan dữ liệu bảo mật để phát hiện, điều tra và phản hồi mối đe dọa.⁴⁵

SOC là gì?

SOC là Security Operations Center: đội hoặc chức năng vận hành bảo mật, chịu trách nhiệm giám sát, triage, điều tra, response, hunting và cải tiến detection.

Detection Engineering là gì?

Detection Engineering là thực hành thiết kế, viết, kiểm thử, triển khai và cải tiến detection logic để phát hiện hành vi tấn công có thể hành động được.

Sigma rule là gì?

Sigma rule là detection rule viết bằng định dạng YAML vendor-neutral, giúp mô tả log events đáng chú ý và có thể chuyển đổi sang nhiều ngôn ngữ truy vấn SIEM khác nhau.⁷

MITRE ATT&CK dùng để làm gì trong SOC?

MITRE ATT&CK giúp map detection theo tactics/techniques, đánh giá coverage, thiết kế threat hunting, viết use case và liên kết alert với hành vi attacker.⁶

SIEM có thay thế EDR không?

Không. EDR tập trung vào endpoint telemetry và response. SIEM tổng hợp nhiều nguồn dữ liệu hơn. Hai hệ thống nên bổ sung cho nhau.

Kết luận

SIEM, SOC và Detection Engineering là nền tảng để phát hiện và phản hồi sự cố bảo mật trong môi trường IT hiện đại. SIEM không phải kho log thụ động; nó cần use case rõ, dữ liệu chất lượng, rule được kiểm thử, enrichment, triage runbook và quy trình response. SOC không chỉ nhìn dashboard; SOC phải có quyền điều tra, phối hợp và hành động.

Cách bắt đầu tốt nhất là chọn một nhóm use case có rủi ro thật: account takeover, admin privilege change, suspicious endpoint execution, cloud key abuse, data export, Git/CI/CD abuse. Sau đó kết nối nguồn log tối thiểu, viết detection có owner, map MITRE ATT&CK, đo false positive và cải tiến liên tục. Khi SIEM/SOC được vận hành đúng, đội IT sẽ chuyển từ phản ứng bị động sang phát hiện chủ động và cải thiện khả năng chống chịu trước tấn công.

Nguồn tham khảo

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 ↩