SIEM Fundamentals & Security Monitoring Architecture ออกแบบระบบเฝ้าระวังภัยไซเบอร์ด้วย SIEM, Windows Event Forwarding, Sysmon, Log Correlation และ Alert Triage

8 พ.ย. 2569 Cyber Security DFIR Security Monitoring SIEM SOC Sysmon Threat Detection WEC WEF

SIEM Fundamentals & Security Monitoring Architecture — ออกแบบระบบเฝ้าระวังภัยไซเบอร์ด้วย WEF/WEC, Sysmon และ Log Correlation

สมมติว่าองค์กรมีคอมพิวเตอร์พนักงาน 100 เครื่อง Windows Server 10 เครื่อง Firewall 2 ชุด และระบบฐานข้อมูล ที่ให้บริการตลอด 24 ชั่วโมง

คืนหนึ่งมีบัญชีผู้ดูแลระบบ ถูกพยายามเข้าสู่ระบบหลายครั้ง ตามด้วยการเข้าสู่ระบบสำเร็จ และมีการสร้าง Service ใหม่ บน Server ที่สำคัญ

หากข้อมูลทั้งหมดกระจายอยู่ ใน Event Viewer ของแต่ละเครื่อง Security Analyst จะค้นพบความสัมพันธ์ ของเหตุการณ์เหล่านี้ได้อย่างไร?

นี่คือเหตุผลที่องค์กรต้องมี Security Information and Event Management หรือ SIEM เพื่อรวบรวม วิเคราะห์ และเชื่อมโยงเหตุการณ์ จากหลายระบบเข้าด้วยกัน

ในบทความนี้ Techerest จะอธิบายการออกแบบระบบ SIEM ตั้งแต่ Log Collection, Windows Event Forwarding (WEF), Windows Event Collector (WEC), Sysmon, Log Normalization, Correlation Rules, Alert Triage และ Monitoring Dashboard

พร้อม Hands-on Safe Lab ที่ใช้ PowerShell และข้อมูลจำลอง เพื่อฝึกสร้าง Detection Pipeline โดยไม่จำเป็นต้องโจมตีระบบจริง

1. SIEM คืออะไร?

Security Information and Event Management (SIEM) เป็นระบบที่รวบรวมและจัดการข้อมูล ด้านความปลอดภัยจากหลายแหล่ง เพื่อช่วยตรวจจับ วิเคราะห์ และสนับสนุนการตอบสนองต่อภัยคุกคาม

SIEM ไม่ใช่เพียงสถานที่เก็บ Log แต่เป็นแพลตฟอร์มที่เชื่อมโยง ข้อมูลเข้ากับ Detection Logic และกระบวนการทำงานของ Security Team

1.1 ความสามารถหลักของ SIEM

Centralized Log Collection
Log Parsing และ Normalization
Security Event Search
Event Correlation
Threat Detection และ Alerting
Investigation และ Case Management
Monitoring Dashboard
Compliance และ Audit Support

1.2 SIEM ต่างจาก Log Server อย่างไร?

Log Server โดยทั่วไปมุ่งเน้น การรับและจัดเก็บ Log เพื่อค้นหาหรือตรวจสอบย้อนหลัง

ส่วน SIEM เพิ่มความสามารถ ในการวิเคราะห์ความปลอดภัย เช่น Correlation Rules, Threat Intelligence Enrichment และการจัดการ Security Alerts

1.3 SIEM ต่างจาก EDR และ SOAR อย่างไร?

Technology	หน้าที่หลัก
SIEM	รวบรวม วิเคราะห์ และเชื่อมโยง Security Events
EDR	ตรวจจับและตอบสนองต่อภัยคุกคามบน Endpoint
NDR	ตรวจสอบและวิเคราะห์กิจกรรมเครือข่าย
SOAR	ประสานงานและทำงานตอบสนองอัตโนมัติ

เทคโนโลยีเหล่านี้สามารถทำงานร่วมกันได้ แต่ไม่ได้ทดแทนกันทั้งหมด

2. SIEM Architecture — โครงสร้างระบบ Security Monitoring

ระบบ SIEM ที่ใช้งานจริง ควรออกแบบให้สามารถรับข้อมูล จากหลายแหล่ง และทำให้ข้อมูล มีรูปแบบที่สามารถนำมาวิเคราะห์ร่วมกันได้

2.1 Architecture Overview

Windows Endpoints
Windows Servers
Firewall / VPN
DNS / Proxy
Cloud / Identity
       |
       v
Log Collection Layer
  WEF / WEC
  Agents
  Syslog
  API Connectors
       |
       v
Parsing / Normalization
       |
       v
SIEM Storage & Search
       |
       v
Detection / Correlation
       |
       v
Alerts / SOC Dashboard
       |
       v
Incident Investigation
       |
       v
Response & Improvement

2.2 Log Sources

Log Sources เป็นระบบต้นทาง ที่สร้างข้อมูลเหตุการณ์

Windows Security Event Logs
Sysmon
PowerShell Operational Logs
Firewall Logs
DNS Logs
VPN Authentication Logs
Cloud Audit Logs
Application และ Database Logs

2.3 Collection Layer

Collection Layer รับข้อมูล จากระบบต้นทางผ่านวิธีต่าง ๆ เช่น WEF/WEC, Syslog, Agent หรือ API

รูปแบบการเก็บข้อมูล ต้องเลือกให้เหมาะสมกับ ประเภทระบบและข้อกำหนดด้านความปลอดภัย

2.4 Processing Layer

Processing Layer ทำหน้าที่ตรวจสอบรูปแบบข้อมูล Parsing, Normalization, Enrichment และจัดการข้อมูลที่ผิดพลาด

2.5 Storage และ Detection Layer

SIEM จัดเก็บข้อมูล เพื่อค้นหาและวิเคราะห์ พร้อมใช้ Detection Rules ตรวจสอบรูปแบบเหตุการณ์ที่น่าสงสัย

2.6 SOC และ Incident Response

เมื่อพบ Alert ระบบควรส่งข้อมูล ให้ Security Analyst ตรวจสอบ ก่อนตัดสินใจ Escalate หรือดำเนินการตาม Incident Response Plan

3. Log Collection — รวบรวมข้อมูลจากหลายระบบ

การออกแบบ Log Collection ควรเริ่มจากคำถามว่า องค์กรต้องการตรวจจับภัยคุกคามประเภทใด และต้องใช้ข้อมูลอะไรเพื่อพิสูจน์เหตุการณ์

3.1 Agent-Based Collection

ติดตั้ง Agent บน Endpoint หรือ Server เพื่ออ่านและส่ง Log ไปยังระบบกลาง

ข้อดีคือสามารถกำหนด การประมวลผลหรือการกรองข้อมูล ตามความสามารถของ Agent

แต่ต้องมีการบริหารจัดการ Agent, Version, Configuration และสิทธิ์

3.2 Agentless Collection

ใช้ความสามารถของระบบต้นทาง หรือ Protocol สำหรับส่ง Log โดยไม่จำเป็นต้องติดตั้ง Agent เพิ่มเติมทุกเครื่อง

ตัวอย่างเช่น Windows Event Forwarding สำหรับ Windows Events

3.3 Syslog Collection

Syslog เป็นกลไกที่ใช้กันแพร่หลาย สำหรับส่งเหตุการณ์จาก Network Devices, Firewall และ Linux Systems

ควรพิจารณาการรับส่งแบบปลอดภัย เช่น Syslog over TLS เมื่อระบบต้นทางและปลายทางรองรับ

3.4 API-Based Collection

Cloud และ SaaS Services มักมี Audit APIs สำหรับให้ระบบ Monitoring เรียกข้อมูลเหตุการณ์

ต้องจัดการ API Credentials, Pagination, Rate Limits และความล่าช้าของข้อมูล

3.5 Log Collection ไม่เท่ากับ Log Completeness

การติดตั้ง Collector สำเร็จ ไม่ได้หมายความว่าได้รับข้อมูลครบทุกประเภท

ต้องตรวจสอบว่าระบบต้นทาง สร้าง Events ที่ต้องการ และไม่มีข้อมูลสูญหาย ระหว่างการรวบรวม

4. Windows Event Forwarding (WEF) คืออะไร?

Windows Event Forwarding (WEF) เป็นความสามารถของ Windows ที่ช่วยส่ง Events จากเครื่องต้นทาง ไปยัง Windows Event Collector

WEF ช่วยรวม Windows Events โดยไม่จำเป็นต้องเปิด Event Viewer แยกทีละเครื่อง

4.1 WEF และ WEC ต่างกันอย่างไร?

WEF: กลไกส่งต่อ Windows Events
WEC: Windows Event Collector ที่รับ Events ตาม Subscription
WinRM: เทคโนโลยีการจัดการระยะไกล ที่ใช้สนับสนุนการสื่อสาร

4.2 WEF Architecture

Windows Client 01 ----+
                      |
Windows Client 02 ----+
                      |
Windows Server 01 ----+----> WEC Server
                      |        |
Windows Server 02 ----+        v
                           ForwardedEvents
                                |
                                v
                          SIEM Collector
                                |
                                v
                          Security Analytics

4.3 Source-Initiated Subscription

ในรูปแบบ Source-Initiated เครื่องต้นทางได้รับการตั้งค่า ให้เชื่อมต่อกับ Collector และส่ง Events ตาม Subscription ที่ Collector กำหนด

วิธีนี้เหมาะกับองค์กร ที่มีเครื่องจำนวนมาก และใช้ Group Policy จัดการ Configuration

4.4 Collector-Initiated Subscription

Collector กำหนดรายชื่อ เครื่องต้นทางที่จะรับ Events ภายใน Subscription

เหมาะกับบางสภาพแวดล้อม ที่มีจำนวนเครื่องจำกัด หรือมีข้อกำหนดเฉพาะ

4.5 WEF ไม่เปิด Audit Policy ให้โดยอัตโนมัติ

WEF อ่าน Events ที่ระบบต้นทางสร้างอยู่แล้ว

หากไม่ได้เปิด Audit Process Creation เครื่องต้นทางอาจไม่มี Event 4688 ที่ต้องการส่งต่อ

ต้องจัดการ Audit Policy แยกจาก WEF Subscription

5. การออกแบบ WEF/WEC สำหรับ Windows Domain

สำหรับองค์กรที่ใช้ Active Directory สามารถออกแบบ Source-Initiated WEF โดยให้ Group Policy กำหนด Subscription Manager ให้เครื่องในขอบเขตที่อนุญาต

5.1 Prerequisites

Windows Server สำหรับ WEC
Windows Endpoints ที่รองรับ WEF
DNS Resolution ที่ถูกต้อง
Time Synchronization
Group Policy หรือการจัดการค่าที่เทียบเท่า
WinRM และ Firewall Rules ที่เหมาะสม
บัญชีและสิทธิ์ตามหลัก Least Privilege

5.2 เตรียม Collector

บน Windows Collector Lab ที่ได้รับอนุญาต ผู้ดูแลระบบสามารถใช้คำสั่ง ต่อไปนี้จาก Elevated Command Prompt

winrm quickconfig

wecutil qc

คำสั่งเหล่านี้มีผลต่อการตั้งค่าบริการ และอาจเปลี่ยน Firewall Configuration จึงไม่ควรรันบน Production โดยไม่มีการอนุมัติ

5.3 สร้าง Subscription

บน Collector เปิด Event Viewer แล้วเลือก Subscriptions

เลือก Create Subscription
กำหนดชื่อ เช่น Techerest-Baseline
เลือก Source computer initiated
กำหนดกลุ่มเครื่องที่อนุญาต
เลือก Events ที่ต้องการรวบรวม
กำหนด Destination Log
กำหนด Delivery Optimization
บันทึกและตรวจสอบ Runtime Status

5.4 Subscription Manager ผ่าน GPO

สำหรับ Domain Environment ไปยัง Group Policy ในเส้นทาง

Computer Configuration
  Administrative Templates
    Windows Components
      Event Forwarding
        Configure target Subscription Manager

ตัวอย่างค่าของ Collector สำหรับ Domain Lab ที่รองรับ Kerberos

Server=http://wec.lab.example.com:5985/wsman/SubscriptionManager/WEC,Refresh=900

lab.example.com เป็นชื่อสมมติ ต้องแทนด้วย FQDN จริง ที่สามารถ Resolve ได้ และตรงกับสภาพแวดล้อม Lab

ตัวอย่าง HTTP Port 5985 ใช้ในบริบท Domain Authentication ที่มีการตั้งค่า WinRM อย่างเหมาะสม ไม่ใช่คำแนะนำให้เปิด HTTP สู่ Public Internet

สำหรับระบบนอก Domain หรือสภาพแวดล้อมที่ต้องใช้ HTTPS ต้องออกแบบ Certificate Authentication และ Trust Relationships เพิ่มเติม

5.5 สิทธิ์สำหรับ Security Log Forwarding

การ Forward Security Log อาจต้องกำหนดสิทธิ์ ให้ Account ที่ทำหน้าที่ Forward อ่าน Security Events ได้

ตามแนวทาง Microsoft สำหรับรูปแบบ Source-Initiated มีข้อกำหนดเกี่ยวกับ NETWORK SERVICE และ Event Log Readers

ควรตรวจสอบสิทธิ์ Audit Configuration และ Security Policy ของ Windows Version ที่ใช้งานจริงก่อนเปลี่ยนค่า

5.6 Baseline และ Suspect Subscriptions

แนวทางหนึ่งที่ Microsoft อธิบาย คือแยก Subscription สำหรับ Baseline Monitoring ออกจาก Suspect Monitoring

Baseline: เก็บ Security Events ที่จำเป็น จากเครื่องในขอบเขตทั่วไป
Suspect: เก็บ Events เพิ่มเติม จากเครื่องที่ต้องตรวจสอบเชิงลึก

แนวทางนี้ช่วยควบคุมปริมาณ Log และลดภาระของ Collector

6. ตรวจสอบสถานะ WEC และ Forwarded Events

หลังตั้งค่า Subscription ต้องตรวจสอบทั้ง Connection, Subscription Runtime และข้อมูลที่ถูกส่งมาจริง

6.1 แสดง Subscription ทั้งหมด

wecutil es

คำสั่งนี้แสดงรายชื่อ Subscriptions ที่ Collector มีอยู่

6.2 ตรวจสอบ Subscription Configuration

wecutil gs "Techerest-Baseline"

6.3 ตรวจสอบ Runtime Status

wecutil gr "Techerest-Baseline"

ต้องเปลี่ยนชื่อ Subscription ให้ตรงกับที่สร้างจริง

6.4 ตรวจสอบ ForwardedEvents

Get-WinEvent -LogName ForwardedEvents `
  -MaxEvents 20 |
Select-Object TimeCreated,
              MachineName,
              Id,
              ProviderName

หากพบ Events ให้ตรวจสอบว่า MachineName ตรงกับเครื่องต้นทางที่คาดหวัง

6.5 ตรวจสอบ Log ที่เครื่องต้นทาง

สำหรับ Source Computer สามารถตรวจสอบ Channel

Microsoft-Windows-Eventlog-ForwardingPlugin/Operational

Channel นี้ช่วยตรวจสอบ การเชื่อมต่อ Subscription Manager และปัญหาที่เกี่ยวข้องกับ WEF

6.6 ข้อจำกัดของ WEC

WEC เป็น Event Collector ไม่ใช่ SIEM ที่มี Detection Engine และ Case Management ครบถ้วน โดยอัตโนมัติ

หากต้องการ Security Analytics ต้องเชื่อมต่อ SIEM หรือระบบประมวลผลเพิ่มเติม

7. Windows Security Events ที่ควรรวบรวม

Windows Security Events เป็นข้อมูลสำคัญในการตรวจสอบ Authentication, Account Changes และกิจกรรมด้านสิทธิ์

7.1 Event IDs สำหรับ Baseline

Event ID	ความหมาย	Use Case
4624	Logon Success	Authentication Monitoring
4625	Logon Failure	Failed Login Investigation
4672	Special Privileges	Privileged Logon Review
4688	Process Creation	Process Investigation
4720	User Account Created	Account Change Monitoring
4732	Local Group Member Added	Group Membership Monitoring
4740	Account Lockout	Account Security Monitoring
4698	Scheduled Task Created	Persistence Investigation
1102	Security Log Cleared	Log Integrity Investigation

Event IDs บางรายการเกิดเฉพาะ เครื่องที่มีบทบาทเกี่ยวข้อง และต้องเปิด Audit Subcategory ที่เหมาะสม

7.2 Log Volume และ Signal Quality

ไม่ควรเลือกเก็บทุก Event โดยไม่วิเคราะห์ความจำเป็น

ควรจัดลำดับข้อมูล ตาม Detection Use Cases และประเมิน Events Per Second, Retention และ Storage Capacity

7.3 หลีกเลี่ยง Data Blind Spots

หาก Detection Rule ต้องใช้ Event 4688 แต่ระบบต้นทาง ไม่ได้เปิด Process Creation Auditing Rule จะไม่สามารถตรวจจับ ตามที่ออกแบบไว้

จึงต้องตรวจสอบ Required Telemetry ก่อนนำ Detection Rule ใช้งานจริง

8. Sysmon Integration กับ SIEM

Sysmon เพิ่ม Telemetry เกี่ยวกับกิจกรรมระดับ Process, Network และ File ตามการตั้งค่าที่ใช้งาน

การส่ง Sysmon Events เข้า SIEM ช่วยขยายมุมมองจาก Authentication ไปสู่ Endpoint Behavior

8.1 Sysmon Event IDs ที่สำคัญ

ID	Event	ประโยชน์
1	Process Create	Process Tree และ Command Line
3	Network Connection	Network Activity Investigation
7	Image Loaded	Module Loading Analysis
11	File Create	File Activity Investigation
12–14	Registry Events	Registry Monitoring
22	DNS Query	DNS Activity Investigation
25	Process Tampering	Suspicious Process Activity

8.2 Process GUID และ Correlation

Sysmon Process GUID ช่วยเชื่อมโยง Events ที่เกี่ยวข้องกับ Process เดียวกัน ภายในบริบทของเครื่องและช่วงเวลา

ตัวอย่างเช่น

Sysmon ID 1
Process Created
        |
        v
Sysmon ID 22
DNS Query
        |
        v
Sysmon ID 3
Network Connection

หากมีข้อมูลครบและสัมพันธ์กัน จะช่วยสร้าง Process Timeline สำหรับ Investigation

8.3 Sysmon Configuration

Sysmon ไม่ได้บันทึกทุก Event ในทุกสภาพแวดล้อมโดยอัตโนมัติ

ต้องตรวจสอบ Configuration, Event Filtering และ Windows Version รวมถึงวิธีติดตั้ง Sysmon ที่ใช้อยู่จริง

8.4 ข้อควรระวัง

Event ID 3 และ Event ID 7 อาจสร้างข้อมูลจำนวนมาก จึงควรทดสอบ Log Volume ก่อนเปิดใช้งานใน Production

9. Log Parsing และ Normalization

ปัญหาสำคัญของระบบ SIEM คือแต่ละผลิตภัณฑ์ใช้ชื่อฟิลด์ และรูปแบบข้อมูลแตกต่างกัน

9.1 ตัวอย่าง Log ที่แตกต่างกัน

Windows:
EventID=4625
TargetUserName=alice
IpAddress=192.0.2.10

Firewall:
action=deny
srcip=192.0.2.10
dstip=198.51.100.25

หากต้องการ Correlate ข้อมูล จำเป็นต้องกำหนด Common Fields ที่เหมาะสม

9.2 Normalized Event Schema

ตัวอย่าง Schema กลางแบบง่าย

{
  "timestamp": "2026-11-08T10:00:00Z",
  "host": "LAB-PC01",
  "source": "windows-security",
  "event_code": 4625,
  "category": "authentication",
  "outcome": "failure",
  "user": "alice",
  "source_ip": "192.0.2.10"
}

ข้อมูลนี้เป็นตัวอย่างสมมติ ไม่ใช่ Windows Event ต้นฉบับ

9.3 Normalization ช่วยอะไร?

ทำให้ Query ใช้งานข้าม Log Sources ได้ง่ายขึ้น
ลดความแตกต่างของ Field Names
ช่วยสร้าง Correlation Rules
สนับสนุน Dashboard และ Reporting

9.4 Parsing Failure และ Data Quality

หาก Log ไม่สามารถ Parse ได้ ไม่ควรทิ้งข้อมูลโดยอัตโนมัติ โดยไม่มีการตรวจสอบ

ควรเก็บ Raw Event ตามนโยบายและแจ้ง Parsing Errors เพื่อให้ทีมตรวจสอบความผิดพลาด

9.5 Event Time กับ Ingestion Time

Event Time คือเวลาที่เหตุการณ์เกิด ส่วน Ingestion Time คือเวลาที่ SIEM ได้รับหรือบันทึกข้อมูล

ทั้งสองอาจแตกต่างกัน จาก Network Delay, Buffering หรือ Collector Backlog

การทำ Correlation ต้องคำนึงถึง Time Zone และ Clock Synchronization เพื่อหลีกเลี่ยงการเรียง Timeline ผิด

10. Correlation Rules — ตรวจจับจากหลายเหตุการณ์

Correlation Rule ใช้เชื่อมโยง Events จากแหล่งข้อมูลเดียวกัน หรือหลายแหล่งข้อมูล เพื่อค้นหารูปแบบที่มีความหมาย ด้านความปลอดภัย

10.1 ตัวอย่าง Multiple Failed Logons

Data Source:
Windows Security

Event ID:
4625

Group By:
Host + Account + Source IP

Threshold:
5 Failed Logons

Time Window:
10 Minutes

Action:
Create Investigation Alert

ค่า Threshold ในตัวอย่าง ไม่ใช่มาตรฐานสากล ต้องปรับตาม Authentication Baseline และความเสี่ยงขององค์กร

10.2 Failed Logons Followed by Success

หากพบ Failed Logons หลายครั้ง และตามด้วย Successful Logon จากบัญชีและ Source เดียวกัน อาจเป็นเหตุผลให้เริ่ม Investigation

แต่ยังไม่สามารถยืนยันว่าเป็น Brute Force เพราะอาจเป็นการใช้งานปกติ หรือระบบที่ใช้ Credentials ไม่ถูกต้อง

10.3 Privileged Account Monitoring

ตัวอย่าง Use Case: พบบัญชีผู้ดูแลระบบเข้าสู่ระบบ จาก Host ที่ไม่เคยใช้งาน และมีการเปลี่ยน Group Membership ภายในช่วงเวลาที่ใกล้เคียงกัน

ควรตรวจสอบ Change Ticket, Account Owner และ Expected Activity ก่อนยกระดับเหตุการณ์

10.4 Correlation Keys

Host และ Domain
User Account
Source IP
Event Timestamp
Logon ID
Process GUID
Asset Criticality

10.5 ข้อจำกัดของ Correlation

การพบ Events ใกล้เคียงกัน ไม่ได้พิสูจน์ว่าเหตุการณ์หนึ่ง เป็นสาเหตุของอีกเหตุการณ์หนึ่ง

ต้องใช้ Context และ Evidence เพิ่มเติมก่อนสรุป

11. Detection Engineering และ Sigma Rules

Detection Engineering เป็นกระบวนการออกแบบ ทดสอบ และปรับปรุง Logic สำหรับตรวจจับภัยคุกคาม

11.1 Detection Lifecycle

กำหนด Threat Hypothesis
ระบุ Required Telemetry
ออกแบบ Detection Logic
ทดสอบด้วยข้อมูลที่ทราบผล
ตรวจสอบ False Positives
กำหนด Severity และ Triage Steps
Deploy ภายใต้ Change Control
Monitor และ Tune อย่างต่อเนื่อง

11.2 Sigma Rule ตัวอย่าง

ตัวอย่างนี้ใช้เลือก Failed Logon Events สำหรับการวิเคราะห์ต่อ

title: Techerest Windows Failed Logon
id: 39154e4e-49b3-4cf4-b519-6675d2c9301a
status: experimental
description: Windows failed authentication event
author: Techerest

logsource:
  product: windows
  service: security

detection:
  selection:
    EventID: 4625
  condition: selection

fields:
  - TargetUserName
  - IpAddress
  - LogonType

falsepositives:
  - User password mistakes
  - Misconfigured services

level: low

11.3 Sigma Base Rule ไม่ใช่ Correlation Rule

Rule ตัวอย่างนี้เลือก Event 4625 เท่านั้น ยังไม่ได้กำหนด การนับห้าครั้งภายในสิบนาที

หากต้องการ Time-Based Correlation ต้องใช้ Sigma Correlation ที่รองรับ หรือ Query ของ SIEM ที่สามารถทำ Aggregation ได้

11.4 Detection Validation

ก่อนใช้งานจริงต้องตรวจสอบ Field Mapping, Event Source, Threshold และความสามารถ ของ Detection Engine

ไม่ควรถือว่า Rule ใช้งานได้ เพียงเพราะ Syntax ถูกต้อง

12. Alert Triage — การประเมิน Security Alerts

เมื่อ SIEM สร้าง Alert ทีม SOC ต้องประเมินว่า เหตุการณ์นั้นควรได้รับ การตอบสนองระดับใด

12.1 Alert Triage Workflow

SIEM Alert
    |
    v
Validate Data Source
    |
    v
Review Event Context
    |
    v
Check Asset Criticality
    |
    v
Correlate Evidence
    |
    v
Assess Confidence & Impact
    |
    v
Close / Monitor / Escalate

12.2 Severity กับ Confidence

Severity สะท้อนความสำคัญหรือผลกระทบ ที่อาจเกิดขึ้น

Confidence สะท้อนระดับความเชื่อมั่น ว่าหลักฐานสนับสนุนข้อสรุปมากเพียงใด

Alert ที่มี Severity สูง อาจยังมี Confidence ต่ำ หากข้อมูลไม่เพียงพอ

12.3 ข้อมูลที่ Analyst ควรตรวจสอบ

Alert Name และ Rule ID
First Seen และ Last Seen
Affected Host และ User
Source IP และ Destination
Related Events
Asset Criticality
Change Records
Known False Positive Conditions

12.4 ตัวอย่าง Triage Decision

พบ Failed Logons ห้าครั้ง ตามด้วย Successful Logon บนเครื่องทดสอบภายใน

หากตรวจสอบแล้วพบว่า ผู้ดูแลระบบกำลังทดสอบ Authentication ตาม Change Ticket อาจปิด Alert เป็น Authorized Activity หลังบันทึกหลักฐาน

แต่หากเกิดกับบัญชีสำคัญ จากแหล่งที่มาไม่รู้จัก ต้องตรวจสอบเพิ่มเติม ตาม Incident Response Procedure

13. Monitoring Dashboard — วัดอะไรจึงมีประโยชน์?

Dashboard ที่ดีควรช่วย ให้ทีม Security ตัดสินใจได้ ไม่ใช่เพียงแสดงจำนวน Events ให้ดูสวยงาม

13.1 Security Monitoring KPIs

KPI	ความหมาย
Events Per Second	ปริมาณ Events ที่รับต่อวินาที
Log Source Coverage	สัดส่วนระบบที่ส่ง Log ตามแผน
Ingestion Latency	ความล่าช้าของข้อมูล
Parsing Success Rate	สัดส่วน Events ที่ Parse สำเร็จ
Open Alerts	Alerts ที่ยังรอจัดการ
Mean Time to Detect	ระยะเวลาเฉลี่ยในการตรวจพบ
Mean Time to Respond	ระยะเวลาเฉลี่ยในการตอบสนองตามนิยามที่กำหนด

13.2 Dashboard Panels ที่แนะนำ

Log Sources Online / Offline
Event Ingestion Trend
Top Detection Rules
Alert Severity Distribution
Authentication Failure Trend
High-Risk Assets with Open Alerts
Collector Health และ Queue Backlog

13.3 Dashboard ต้องแสดง Data Freshness

หาก Collector หยุดรับ Events Dashboard อาจดูเหมือนไม่มีภัยคุกคาม

ดังนั้นควรแสดง Last Event Received, Data Freshness และ Missing Sources ให้ Analyst เห็นชัดเจน

14. Hands-on Safe Lab — สร้าง Mini SIEM ด้วย PowerShell

Lab นี้จำลองกระบวนการ Log Collection, Normalization, Correlation และ Alert Generation

ใช้ข้อมูล Synthetic CSV ไม่แก้ไข Security Policy ไม่สร้างการโจมตีจริง และไม่ต้องเชื่อมต่อเครื่องอื่น

14.1 Lab Objectives

สร้าง Synthetic Log Sources สองเครื่อง
จำลอง Log Ingestion
Normalize Fields
ตรวจจับ Failed Logons ภายใน Time Window
สร้าง Alert พร้อม Evidence
ตรวจสอบ Alert Triage

14.2 สร้าง Lab Directory

$Lab = Join-Path $HOME "Techerest-SIEM-Lab"

New-Item -ItemType Directory `
  -Path $Lab -Force | Out-Null

14.3 สร้าง Synthetic Windows Events

สร้างข้อมูลตัวอย่าง สำหรับเครื่อง LAB-PC01 และ LAB-PC02

$Base = [datetime]"2026-11-08T10:00:00Z"

$Events = @(
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(0).ToString("o")
    Host = "LAB-PC01"
    EventID = 4625
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(30).ToString("o")
    Host = "LAB-PC01"
    EventID = 4625
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(60).ToString("o")
    Host = "LAB-PC01"
    EventID = 4625
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(90).ToString("o")
    Host = "LAB-PC01"
    EventID = 4625
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(120).ToString("o")
    Host = "LAB-PC01"
    EventID = 4625
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(150).ToString("o")
    Host = "LAB-PC01"
    EventID = 4624
    User = "alice"
    SourceIP = "192.0.2.10"
  },
  [PSCustomObject]@{
    Timestamp = $Base.AddSeconds(180).ToString("o")
    Host = "LAB-PC02"
    EventID = 4624
    User = "bob"
    SourceIP = "198.51.100.20"
  }
)

$RawPath = Join-Path $Lab "raw-events.csv"

$Events | Export-Csv `
  -LiteralPath $RawPath `
  -NoTypeInformation -Encoding UTF8

ตัวอย่างนี้สร้างข้อมูลเจ็ดรายการ และใช้ IP สำหรับเอกสาร ไม่ใช่ข้อมูลจากผู้ใช้งานจริง

14.4 Simulate Log Ingestion

$RawLogs = Import-Csv `
  -LiteralPath $RawPath

$RawLogs |
Select-Object Timestamp, Host, EventID, User |
Format-Table -AutoSize

Expected Result: อ่านข้อมูลเจ็ด Events ได้ โดยไม่เกิด Parsing Error

14.5 Normalize Events

$Normalized = foreach ($E in $RawLogs) {

  $EventCode = [int]$E.EventID

  $Outcome = switch ($EventCode) {
    4624 { "success" }
    4625 { "failure" }
    default { "unknown" }
  }

  [PSCustomObject]@{
    timestamp = [datetimeoffset]::Parse($E.Timestamp)
    host = $E.Host
    source = "windows-security-synthetic"
    event_code = $EventCode
    category = "authentication"
    outcome = $Outcome
    user = $E.User
    source_ip = $E.SourceIP
  }
}

$Normalized |
Export-Csv `
  -LiteralPath (Join-Path $Lab "normalized.csv") `
  -NoTypeInformation -Encoding UTF8

คำสั่งนี้สร้าง Common Schema สำหรับ Authentication Events ใน Lab

14.6 สร้าง Correlation Rule ด้วย Sliding Window

เงื่อนไขคือพบ Failed Logons อย่างน้อยห้าครั้ง จาก Host, User และ Source IP เดียวกัน ภายในสิบนาที

$Threshold = 5
$Window = [timespan]::FromMinutes(10)

$Failures = @(
  $Normalized | Where-Object {
    $_.event_code -eq 4625
  }
)

$Alerts = @(
  foreach ($Group in (
    $Failures |
    Group-Object host, user, source_ip
  )) {

    $Sorted = @(
      $Group.Group | Sort-Object timestamp
    )

    $Left = 0

    for ($Right = 0; $Right -lt $Sorted.Count; $Right++) {

      while (
        $Left -le $Right -and
        ($Sorted[$Right].timestamp -
         $Sorted[$Left].timestamp) -gt $Window
      ) {
        $Left++
      }

      $Count = $Right - $Left + 1

      if ($Count -eq $Threshold) {

        [PSCustomObject]@{
          rule = "Multiple Failed Logons"
          group = $Group.Name
          first_seen = $Sorted[$Left].timestamp
          last_seen = $Sorted[$Right].timestamp
          event_count = $Count
          severity = "medium"
          status = "Review Required"
        }

        break
      }
    }
  }
)

$Alerts | Format-Table -AutoSize

Rule นี้สร้าง Alert สูงสุดหนึ่งรายการ ต่อกลุ่ม Host/User/Source IP ภายใน Dataset ที่วิเคราะห์

สำหรับ Production SIEM ต้องออกแบบให้รองรับ การรับ Events แบบต่อเนื่อง, Out-of-Order Events และการแบ่ง Time Windows อย่างถูกต้อง

14.7 Export Detection Alerts

$AlertPath = Join-Path $Lab "alerts.csv"

$Alerts |
Export-Csv -LiteralPath $AlertPath `
  -NoTypeInformation -Encoding UTF8

ผลที่คาดหวังคือ Alert หนึ่งรายการสำหรับ LAB-PC01 / alice / 192.0.2.10

14.8 Verify Successful Logon หลัง Alert

$Successes = @(
  $Normalized | Where-Object {
    $_.event_code -eq 4624
  }
)

$Correlations = @(
  foreach ($Login in $Successes) {

    $Recent = @(
      $Failures | Where-Object {
        $_.host -eq $Login.host -and
        $_.user -eq $Login.user -and
        $_.source_ip -eq $Login.source_ip -and
        $_.timestamp -lt $Login.timestamp -and
        $_.timestamp -ge $Login.timestamp.AddMinutes(-10)
      }
    )

    if ($Recent.Count -ge 5) {
      [PSCustomObject]@{
        host = $Login.host
        user = $Login.user
        source_ip = $Login.source_ip
        failed_before_success = $Recent.Count
        success_time = $Login.timestamp
        disposition = "Investigate"
      }
    }
  }
)

$Correlations | Format-Table -AutoSize

ผลที่คาดหวังคือ พบ Successful Logon หลัง Failed Logons ห้าครั้ง บน LAB-PC01

เหตุการณ์นี้เป็น Synthetic Pattern จึงไม่ควรจัดสถานะว่า Confirmed Compromise

14.9 Verification ของ Lab

Test	Expected Result
Raw Log Ingestion	7 Events
Normalization	7 Normalized Events
Correlation Rule	1 Alert
Failed Logons	5 Events on LAB-PC01
Success Correlation	1 Matching Sequence
Malware Execution	None

15. SIEM Verification — ตรวจสอบระบบใช้งานจริง

เมื่อพัฒนา SIEM บนระบบจริง ต้องตรวจสอบว่าทั้ง Collection, Processing และ Detection ทำงานตามที่ออกแบบ

15.1 Collection Verification

เครื่องต้นทางส่ง Log ได้
Collector รับข้อมูลจาก Source ที่กำหนด
ไม่พบ Missing Log Sources ที่ไม่ได้จัดการ
Collector Queue ไม่มี Backlog ผิดปกติ
Source และ Collector ใช้เวลาที่สอดคล้องกัน

15.2 Processing Verification

Parser อ่านข้อมูลได้ตาม Schema
Normalization ไม่ทำให้ข้อมูลสำคัญสูญหาย
สามารถเข้าถึง Raw Events ตามนโยบาย
ข้อมูลที่ Parse ไม่ผ่านถูกติดตาม

15.3 Detection Verification

Rule ตรวจพบ Synthetic Test Cases
False Positive Scenarios ผ่านการทดสอบ
Alert มี Evidence และ Context เพียงพอ
Alert ถูกส่งถึงผู้รับผิดชอบ
Analyst สามารถเปิด Investigation ได้

15.4 Security Monitoring Health

ต้องติดตามสถานะของ SIEM Platform เองด้วย

Collector Availability
Storage Capacity
Event Ingestion Latency
Log Source Freshness
Detection Rule Failures
License และ Capacity Limits

16. Troubleshooting — ปัญหาที่พบบ่อยใน SIEM และ WEF/WEC

16.1 WEC ไม่ได้รับ Events

ให้ตรวจสอบตามลำดับ

Source สร้าง Event ที่ต้องการจริงหรือไม่
Subscription Enabled หรือไม่
WinRM Configuration ถูกต้องหรือไม่
DNS และ Network Connectivity ใช้งานได้หรือไม่
Firewall อนุญาตการสื่อสารที่จำเป็นหรือไม่
Authentication และ Permissions ถูกต้องหรือไม่
Subscription Runtime Status มี Error หรือไม่

16.2 ทดสอบ Connection ไป Collector

Test-NetConnection `
  -ComputerName wec.lab.example.com `
  -Port 5985

สำหรับ Lab ที่ใช้ HTTPS ให้ตรวจสอบ Port ที่กำหนดจริง เช่น 5986

การเชื่อมต่อ TCP สำเร็จ ไม่ได้ยืนยันว่า WEF Authentication และ Subscription ทำงานถูกต้อง

16.3 ไม่พบ Security Events บน Source

ตรวจสอบ Audit Policy และว่าเหตุการณ์เกิดบนเครื่อง หรือ Channel ที่คาดหวังจริงหรือไม่

auditpol /get /category:*

16.4 ForwardedEvents มีข้อมูล แต่ SIEM ไม่มี

ตรวจสอบ SIEM Agent, Input Configuration, Parsing และ Ingestion Pipeline

ต้องยืนยันว่า Agent อ่าน Channel หรือไฟล์ Event ที่ถูกต้อง

16.5 Detection Rule ไม่สร้าง Alert

ตรวจสอบว่า Events มี Required Fields ครบ และ Rule ใช้ Field Names ที่ตรงกับ Normalized Schema

ตรวจสอบ Time Window และ Query Execution รวมถึง Suppression หรือ Exclusions

16.6 Alert จำนวนมากเกินไป

เริ่มจากตรวจสอบ False Positive และพฤติกรรมการใช้งานปกติ

ปรับ Threshold และเงื่อนไขยกเว้น โดยไม่ทำให้เกิด Detection Blind Spots

16.7 Event Timestamps ไม่ตรงกัน

ตรวจสอบ Time Synchronization, UTC Conversion และ Parsing ของ Event Timestamp

อย่าสมมติว่าเวลาที่ SIEM รับข้อมูล เท่ากับเวลาที่เหตุการณ์เกิด

16.8 Collector ใช้ Storage สูง

ตรวจสอบ Events Per Second, Retention, Subscription Filtering และ Log Rotation

ไม่ควรลด Log Retention โดยไม่ประเมินความต้องการ ด้าน Incident Investigation และข้อกำหนดที่เกี่ยวข้อง

17. Security Best Practices สำหรับ SIEM Architecture

17.1 Least Privilege

Collector และ SIEM Agents ควรได้รับสิทธิ์เท่าที่จำเป็น สำหรับการอ่านและส่งข้อมูล

หลีกเลี่ยงการใช้ Domain Administrator หรือบัญชีสิทธิ์สูง หากไม่มีความจำเป็นทางเทคนิค

17.2 Secure Transport

การส่ง Log ควรใช้ Authentication และ Encryption ที่เหมาะสมกับสภาพแวดล้อม

ตรวจสอบ Certificate Management, Key Rotation และ Trust Configuration ตาม Protocol ที่ใช้

17.3 Log Integrity และ Retention

จำกัดสิทธิ์การแก้ไขและลบ Log
ใช้ Centralized Storage ที่มีการป้องกัน
พิจารณา Immutable Storage ตามความเสี่ยง
กำหนด Retention ตามข้อกำหนดที่เกี่ยวข้อง
บันทึกการเปลี่ยนแปลง Configuration

17.4 Data Privacy

Security Logs อาจมีข้อมูลส่วนบุคคล ชื่อผู้ใช้ IP Address และข้อมูลระบบภายใน

ต้องกำหนดสิทธิ์การเข้าถึง การเก็บรักษา และการเปิดเผย ตามนโยบายองค์กรและกฎหมายที่เกี่ยวข้อง

17.5 High Availability

สำหรับระบบที่สำคัญ ควรประเมินความจำเป็นของ Collector Redundancy, Storage Resilience และ Disaster Recovery

การออกแบบต้องคำนึงถึง Failure Modes และ Dependencies ของระบบ Monitoring

17.6 Detection as Code

Detection Rules ควรมี Version Control, Review, Test Cases และ Change History

แนวทางนี้ช่วยลดความเสี่ยง จากการแก้ Rule โดยไม่มีหลักฐาน และช่วยตรวจสอบย้อนหลัง

17.7 Security Monitoring ต้องมี Owner

ทุก Alert ต้องมีผู้รับผิดชอบ และขั้นตอน Escalation ที่ชัดเจน

ระบบที่สร้าง Alerts แต่ไม่มีผู้ตรวจสอบและตอบสนอง ไม่สามารถถือว่ามีการเฝ้าระวัง ที่มีประสิทธิภาพได้

18. SIEM Deployment Roadmap — เริ่มจากเล็กแล้วขยาย

สำหรับองค์กรขนาดเล็ก หรือผู้ที่ต้องการสร้าง Security Lab ควรพัฒนาระบบเป็นขั้นตอน

18.1 Phase 1 — Identify Detection Use Cases

กำหนดระบบที่มีความสำคัญ
เลือก Threat Scenarios
ระบุ Log Sources
กำหนด Data Retention

18.2 Phase 2 — Build Log Collection

เริ่มจาก Windows Security Events
ติดตั้ง WEC Lab
เชื่อมต่อ Windows Sources
ตรวจสอบ Event Delivery

18.3 Phase 3 — Add Endpoint Telemetry

ประเมิน Sysmon Configuration
เลือก Events ที่เหมาะสม
ทดสอบ Log Volume
เชื่อมต่อข้อมูลเข้าสู่ระบบกลาง

18.4 Phase 4 — Develop Detection Rules

สร้าง Authentication Detection
สร้าง Privileged Access Detection
ตรวจสอบ Process Creation Activity
ทดสอบ Correlation ด้วย Synthetic Data

18.5 Phase 5 — SOC Operations

กำหนด Alert Severity
จัดทำ Triage Playbooks
สร้าง Monitoring Dashboard
กำหนด Incident Escalation
ติดตาม Detection Performance

19. Mini SIEM Lab Report — ตัวอย่างรายงาน

หลังทำ Safe Lab สามารถจัดทำรายงาน สำหรับบันทึกผลการฝึก และใช้เป็น Portfolio ด้าน Defensive Security

Case ID:
TECHEREST-SIEM-LAB-007

Project:
Mini SIEM Detection Pipeline

Environment:
Windows 11 / PowerShell

Data Source:
Synthetic Windows Security Events

Hosts:
LAB-PC01
LAB-PC02

Total Events:
7

Normalization:
Completed

Detection Rule:
Multiple Failed Logons

Threshold:
5 failures within 10 minutes

Correlation:
Failed logons followed by success

Alerts Generated:
1

Threat Status:
Not Confirmed

Malware Executed:
No

External Systems Accessed:
No

Verification:
Synthetic test passed if expected results match

Limitations:
No live WEF/WEC deployment tested
No production SIEM integration
No real incident analyzed

Next Steps:
- Build WEC lab
- Validate forwarding
- Add Sysmon data
- Test detection on collected events

19.1 สิ่งที่ควรมีในรายงาน Production

Architecture Diagram
Asset Inventory และ Log Source Coverage
Collector Configuration
Parsing และ Schema Documentation
Detection Rules และ Test Results
Alert Triage Procedure
Operational Metrics
Known Issues และ Remediation Plan

20. FAQ — คำถามที่พบบ่อย

20.1 SIEM จำเป็นสำหรับทุกองค์กรหรือไม่?

ไม่จำเป็นต้องเริ่มจาก SIEM ขนาดใหญ่เสมอไป องค์กรควรประเมินความเสี่ยง ขนาดระบบ และความพร้อมของบุคลากร

องค์กรขนาดเล็กอาจเริ่มจาก Centralized Logging และ Detection Use Cases ที่สำคัญก่อน

20.2 WEF/WEC ใช้งานฟรีหรือไม่?

WEF/WEC เป็นความสามารถ ที่มีใน Windows รุ่นที่รองรับ โดยไม่จำเป็นต้องซื้อ SIEM เพิ่มเพื่อใช้ฟังก์ชันนี้

แต่ยังมีต้นทุนด้าน Windows Licensing, Infrastructure, Storage และการบริหารจัดการ ตามสภาพแวดล้อมจริง

20.3 WEC แทน SIEM ได้หรือไม่?

WEC สามารถรวบรวม Windows Events แต่ไม่ได้มีความสามารถ ด้าน Security Analytics ครบถ้วนเท่ากับ SIEM โดยอัตโนมัติ

20.4 Sysmon จำเป็นต้องติดตั้งทุกเครื่องหรือไม่?

ขึ้นอยู่กับความต้องการด้าน Telemetry และนโยบายองค์กร

ควรประเมิน Windows Version, Configuration และ Log Volume ก่อนเปิดใช้งาน

20.5 SIEM ตรวจจับ Hacker ได้ 100% หรือไม่?

ไม่สามารถรับประกันได้ เพราะ SIEM พึ่งพาข้อมูลที่เก็บได้ Detection Logic และการวิเคราะห์ ของบุคลากร

20.6 Log จำนวนมากหมายถึงความปลอดภัยสูงหรือไม่?

ไม่เสมอไป ข้อมูลจำนวนมากที่ไม่มี Detection Use Case อาจสร้างภาระค่าใช้จ่าย และเพิ่มความยากในการตรวจสอบ

20.7 ผู้เริ่มต้นควรใช้ SIEM ตัวใด?

สามารถศึกษาระบบอย่าง Wazuh, Elastic Security, Security Onion หรือ Microsoft Sentinel ตามสถาปัตยกรรมและงบประมาณ

ต้องตรวจสอบ License, Deployment Requirements และความสามารถของเวอร์ชัน ที่เลือกก่อนใช้งาน

21. Conclusion — จาก Logs สู่ Security Monitoring ที่ตรวจสอบได้

SIEM เป็นหัวใจสำคัญส่วนหนึ่ง ของ Security Operations เพราะช่วยรวบรวมข้อมูล จากระบบที่กระจายอยู่ และเชื่อมโยงเหตุการณ์เข้าด้วยกัน

Windows Event Forwarding และ WEC ช่วยสร้างพื้นฐาน ในการรวบรวม Windows Events

Sysmon เพิ่มรายละเอียด สำหรับการวิเคราะห์ Endpoint ขณะที่ Normalization และ Correlation Rules ช่วยเปลี่ยนข้อมูลดิบ ให้เป็น Security Findings ที่สามารถตรวจสอบได้

อย่างไรก็ตาม ระบบ Monitoring จะมีคุณค่าก็ต่อเมื่อ มีข้อมูลที่ถูกต้อง Detection ที่ผ่านการทดสอบ และกระบวนการตอบสนอง ที่มีผู้รับผิดชอบ

Collect the Right Data. Normalize the Events. Correlate the Evidence. Investigate with Confidence.

Techerest มุ่งพัฒนา Cyber Security Knowledge Base ที่ผู้อ่านสามารถเรียนรู้ ออกแบบ ทดลอง และแก้ปัญหา ด้าน Security Monitoring ได้อย่างเป็นระบบ

22. References — แหล่งข้อมูลอ้างอิง

หมายเหตุ: NIST SP 800-92 ฉบับเดิม เผยแพร่ในปี 2006 ใช้เป็นพื้นฐาน Log Management โดยควรติดตามความคืบหน้า ของ Revision 1 จาก NIST เพิ่มเติม

TECHEREST COMMUNITY

Share your thoughts here

Join the conversation and share your perspective on this article.

Comments will load when you reach this section.