บทนำ: ทำไมทุกองค์กรต้องมี SIEM และ Log Management?
ลองนึกภาพว่าองค์กรของคุณมี firewall 3 ตัว, server 20 เครื่อง, switch 15 ตัว, endpoint 200 เครื่อง, cloud workload อีก 50+ instances — ทุกอุปกรณ์เหล่านี้สร้าง log ออกมาทุกวินาที log ที่บอกว่าใครล็อกอิน, มีใครพยายาม brute force, firewall block traffic อะไร, server มี error อะไร — ข้อมูลเหล่านี้มีค่ามหาศาลสำหรับการตรวจจับภัยคุกคาม แต่ถ้าไม่มีระบบรวบรวมและวิเคราะห์ log เหล่านี้อย่างเป็นระบบ มันก็เหมือนมีกล้อง CCTV แต่ไม่เคยดูจอ
สถิติจาก IBM Security X-Force ระบุว่า องค์กรใช้เวลาเฉลี่ย 204 วันในการตรวจพบ data breach และ 73 วันในการ contain ความเสียหาย ถ้ามีระบบ SIEM ที่ดี เวลาตรวจพบสามารถลดลงเหลือ นาทีหรือชั่วโมง แทนที่จะเป็นเดือน ซึ่งหมายถึงความเสียหายที่ลดลงอย่างมหาศาล ค่าเฉลี่ยของ data breach อยู่ที่ $4.45 ล้านต่อเหตุการณ์ (2023) และองค์กรที่มี SIEM ลดค่าเสียหายได้เฉลี่ย $1.76 ล้าน เมื่อเทียบกับที่ไม่มี
บทความนี้จะเป็นคู่มือครบวงจรเกี่ยวกับ SIEM (Security Information and Event Management) และ Log Management — ครอบคลุมตั้งแต่แนวคิดพื้นฐาน, สถาปัตยกรรม, แพลตฟอร์มยอดนิยม, การติดตั้ง Wazuh (open-source), การเขียน correlation rules, use cases จริง, การรวม SOAR, compliance reporting, การ tuning ลด false positives, threat intelligence feeds, SOC operations ไปจนถึง sizing และ architecture สำหรับองค์กรขนาดต่างๆ
ส่วนที่ 1: SIEM คืออะไร? ทำความเข้าใจพื้นฐาน
1.1 SIEM (Security Information and Event Management) คืออะไร?
SIEM ย่อมาจาก Security Information and Event Management คือระบบที่รวบรวม log และ event จากทุกอุปกรณ์ในเครือข่าย นำมา normalize, correlate, วิเคราะห์ และแจ้งเตือนเมื่อตรวจพบพฤติกรรมที่น่าสงสัยหรือเป็นภัยคุกคาม SIEM เกิดจากการรวมสองแนวคิด: SIM (Security Information Management) ที่เน้นเก็บ log ระยะยาว กับ SEM (Security Event Management) ที่เน้น real-time monitoring และ alerting
SIEM ทำอะไรได้บ้าง?
หน้าที่หลักของ SIEM:
├── 1. Log Collection — รวบรวม log จากทุกแหล่ง
│ ├── Firewalls, IDS/IPS
│ ├── Servers (Windows, Linux)
│ ├── Active Directory / LDAP
│ ├── Endpoints (Workstations)
│ ├── Cloud Services (AWS, Azure, GCP)
│ ├── Applications (Web, Database, Email)
│ ├── Network Devices (Switch, Router, AP)
│ └── VPN, Proxy, WAF
│
├── 2. Log Normalization — ทำให้ log เป็นรูปแบบเดียวกัน
│ ├── แต่ละอุปกรณ์ส่ง log คนละ format
│ ├── SIEM แปลงให้เป็น schema มาตรฐาน
│ ├── ง่ายต่อการค้นหาและเปรียบเทียบ
│ └── Enrichment: เพิ่มข้อมูล (GeoIP, DNS, asset info)
│
├── 3. Correlation — เชื่อมโยง event ที่เกี่ยวข้อง
│ ├── Event เดี่ยวๆ อาจไม่ใช่ภัยคุกคาม
│ ├── แต่เมื่อรวมกันอาจเป็น attack pattern
│ ├── เช่น: failed login 50 ครั้ง + success 1 ครั้ง = brute force สำเร็จ
│ └── Rule-based + ML-based correlation
│
├── 4. Alerting — แจ้งเตือนเมื่อพบภัยคุกคาม
│ ├── Real-time notification
│ ├── Email, SMS, LINE, Telegram
│ ├── SNMP Trap
│ ├── Webhook → ticketing system
│ └── Priority levels: Low, Medium, High, Critical
│
├── 5. Dashboards & Visualization — แสดงผลภาพรวม
│ ├── Real-time security overview
│ ├── Top threats, top attackers
│ ├── Geographic attack map
│ ├── Trend analysis
│ └── Custom dashboards per role
│
├── 6. Forensic Investigation — สืบสวนย้อนหลัง
│ ├── ค้นหา log ย้อนหลัง (หลายเดือน-ปี)
│ ├── Timeline reconstruction
│ ├── Drill-down จาก alert → raw log
│ ├── Pivot investigation
│ └── Evidence preservation
│
└── 7. Compliance Reporting — รายงานตาม compliance
├── PCI-DSS, ISO 27001, SOC 2
├── GDPR, PDPA (Thailand)
├── HIPAA, NIST
├── Pre-built report templates
└── Audit trail ครบถ้วน1.2 Log Management vs SIEM — ต่างกันอย่างไร?
หลายคนสับสนระหว่าง Log Management กับ SIEM ซึ่งแม้จะเกี่ยวข้องกันแต่มีจุดประสงค์ต่างกัน:
Log Management vs SIEM:
Log Management:
├── จุดประสงค์หลัก: เก็บ, ค้นหา, จัดการ log
├── หน้าที่:
│ ├── รวบรวม log จากทุกแหล่ง
│ ├── จัดเก็บอย่างเป็นระบบ (centralized)
│ ├── ค้นหา log ได้รวดเร็ว
│ ├── Log rotation และ retention
│ └── Basic alerting (keyword matching)
├── ตัวอย่าง: Graylog, ELK Stack, Fluentd, rsyslog
└── เหมาะสำหรับ: IT operations, troubleshooting
SIEM:
├── จุดประสงค์หลัก: Security monitoring & threat detection
├── หน้าที่:
│ ├── ทุกอย่างที่ Log Management ทำ +
│ ├── Correlation engine (เชื่อมโยง events)
│ ├── Threat detection (ตรวจจับภัยคุกคาม)
│ ├── User & Entity Behavior Analytics (UEBA)
│ ├── Incident response workflow
│ ├── Threat intelligence integration
│ ├── Compliance reporting
│ └── SOAR integration (automated response)
├── ตัวอย่าง: Splunk, Microsoft Sentinel, Wazuh, QRadar
└── เหมาะสำหรับ: Security operations, SOC, compliance
ความสัมพันธ์:
┌──────────────────────────────────────┐
│ SIEM Platform │
│ ┌────────────────────────────────┐ │
│ │ Log Management │ │
│ │ ┌──────────────────────────┐ │ │
│ │ │ Log Collection │ │ │
│ │ │ Storage │ │ │
│ │ │ Search │ │ │
│ │ └──────────────────────────┘ │ │
│ └────────────────────────────────┘ │
│ + Correlation Engine │
│ + Threat Detection │
│ + UEBA │
│ + Compliance │
│ + SOAR │
└──────────────────────────────────────┘
SIEM = Log Management + Security Intelligenceส่วนที่ 2: Syslog Protocol และ Log Collection
2.1 Syslog Protocol — มาตรฐานการส่ง Log
Syslog เป็นมาตรฐานโปรโตคอลสำหรับส่ง log messages ผ่านเครือข่าย ถูกใช้งานอย่างแพร่หลายมาหลายทศวรรษ:
Syslog Protocol Overview:
Syslog Versions:
├── RFC 3164 (BSD Syslog) — เวอร์ชันเก่า, ยังใช้กันมาก
│ ├── Format: <PRI>TIMESTAMP HOSTNAME APP-NAME: MSG
│ ├── ตัวอย่าง: <34>Oct 11 22:14:15 myserver sshd[12345]: Failed password for root
│ ├── Max message: 1024 bytes
│ └── ไม่มี structured data
│
├── RFC 5424 (Modern Syslog) — เวอร์ชันใหม่
│ ├── Format: <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID SD MSG
│ ├── รองรับ structured data
│ ├── UTF-8 support
│ └── Max message: ไม่จำกัด (แนะนำ 2048+)
│
└── Transport:
├── UDP port 514 — ดั้งเดิม, ไม่การันตีส่งถึง
├── TCP port 514 (หรือ 601) — เชื่อถือได้กว่า
├── TLS/TCP port 6514 — เข้ารหัส (RFC 5425)
└── แนะนำ: ใช้ TCP หรือ TLS เสมอสำหรับ SIEM
Syslog Severity Levels (0-7):
├── 0 Emergency — ระบบ crash (emerg)
├── 1 Alert — ต้องดำเนินการทันที (alert)
├── 2 Critical — สภาวะวิกฤต (crit)
├── 3 Error — ข้อผิดพลาด (err)
├── 4 Warning — คำเตือน (warning)
├── 5 Notice — แจ้งให้ทราบ (notice)
├── 6 Informational— ข้อมูลทั่วไป (info)
└── 7 Debug — สำหรับ debug (debug)
Syslog Facility (0-23):
├── 0 kern — Kernel messages
├── 1 user — User-level
├── 3 daemon — System daemons
├── 4 auth — Security/auth
├── 10 authpriv — Security/auth (private)
├── 16-23 local0-7 — Custom/local use
└── PRI = Facility × 8 + Severity2.2 Log Sources — แหล่งข้อมูล Log ที่สำคัญ
SIEM ต้องรวบรวม log จากทุกแหล่งที่สำคัญในเครือข่าย ยิ่งครอบคลุมมาก ยิ่งตรวจจับภัยคุกคามได้ดี:
Log Sources สำหรับ SIEM:
1. Network Security Devices:
├── Firewall (Fortinet, Palo Alto, Sophos, pfSense)
│ ├── Allow/Deny traffic logs
│ ├── VPN connection logs
│ ├── IPS/IDS events
│ ├── URL filtering logs
│ └── Threat intelligence matches
├── IDS/IPS (Snort, Suricata)
│ ├── Signature-based alerts
│ └── Anomaly-based alerts
├── WAF (Web Application Firewall)
│ ├── SQL injection attempts
│ ├── XSS attempts
│ └── OWASP Top 10 violations
└── Proxy Server (Squid, BlueCoat)
├── URL access logs
└── Malware download blocks
2. Server Infrastructure:
├── Windows Server
│ ├── Security Event Log (Event ID 4624-4634: logon/logoff)
│ ├── Event ID 4625: failed logon
│ ├── Event ID 4720: account created
│ ├── Event ID 4732: member added to group
│ ├── Event ID 1102: audit log cleared
│ └── PowerShell logging (Script Block, Module)
├── Linux Server
│ ├── /var/log/auth.log (SSH, sudo)
│ ├── /var/log/syslog (general)
│ ├── /var/log/secure (RHEL/CentOS)
│ ├── auditd logs (file access, syscalls)
│ ├── journald (systemd services)
│ └── Application logs (Apache, Nginx, MySQL)
└── DNS Server
├── Query logs (ตรวจจับ DNS tunneling)
├── NXDOMAIN responses
└── DGA domain detection
3. Active Directory:
├── Domain Controller logs
│ ├── Authentication events
│ ├── Group Policy changes
│ ├── Account modifications
│ ├── Kerberos ticket events
│ ├── LDAP queries
│ └── Replication events
├── Azure AD / Entra ID
│ ├── Sign-in logs
│ ├── Audit logs
│ ├── Conditional Access logs
│ └── MFA events
└── สำคัญมาก: AD เป็น #1 target ของ attacker
4. Endpoints:
├── Antivirus/EDR
│ ├── Malware detection
│ ├── Suspicious process execution
│ ├── File integrity changes
│ └── Behavioral analytics
├── Windows Event Forwarding (WEF)
│ ├── Forward security logs to collector
│ └── ไม่ต้องติดตั้ง agent
└── Sysmon (Microsoft Sysinternals)
├── Process creation with command line
├── Network connections
├── File creation timestamps
├── Registry modifications
├── WMI events
└── DNS queries
5. Cloud Services:
├── AWS
│ ├── CloudTrail (API activity)
│ ├── GuardDuty (threat detection)
│ ├── VPC Flow Logs (network)
│ ├── S3 access logs
│ └── CloudWatch Logs
├── Azure
│ ├── Activity Log
│ ├── Azure Monitor
│ ├── NSG Flow Logs
│ └── Key Vault audit logs
├── Google Cloud
│ ├── Cloud Audit Logs
│ ├── VPC Flow Logs
│ └── Cloud Logging
└── SaaS Applications
├── Microsoft 365 audit logs
├── Google Workspace
└── Salesforce event logsส่วนที่ 3: SIEM Architecture — สถาปัตยกรรมของ SIEM
3.1 องค์ประกอบหลักของ SIEM
SIEM Architecture:
┌─────────────────────────────────────────────────┐
│ SIEM Platform │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Data │ │ Parsing │ │ Correlation │ │
│ │Collection│→ │ Normali-│→ │ Engine │ │
│ │ Layer │ │ zation │ │ │ │
│ └──────────┘ └──────────┘ └──────┬───────┘ │
│ ↑ │ │
│ Log Sources ↓ │
│ (via agent, ┌──────────┐ ┌──────────────┐ │
│ syslog, │ Storage │ │ Alerting │ │
│ API) │ (Index) │ │ & Response │ │
│ └──────────┘ └──────────────┘ │
│ ↕ │ │
│ ┌──────────┐ ↓ │
│ │Dashboard │ ┌──────────────┐ │
│ │Search │ │ SOAR │ │
│ │Reports │ │ Integration │ │
│ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────────┘
Components อธิบาย:
1. Data Collection Layer:
├── Agents: ติดตั้งบน endpoint, ส่ง log + สถานะ
│ ├── Wazuh Agent, Elastic Agent, Splunk UF
│ ├── ติดตั้งง่าย, รวบรวม log ได้ลึก
│ └── รองรับ Windows, Linux, macOS
├── Syslog Receiver: รับ syslog จาก network devices
│ ├── UDP/TCP port 514
│ ├── เหมาะสำหรับ firewall, router, switch
│ └── ไม่ต้องติดตั้ง agent
├── API Collectors: ดึง log จาก cloud/SaaS
│ ├── REST API polling
│ ├── Webhook/push
│ └── AWS S3, Azure Event Hub, etc.
├── File Monitoring: อ่าน log file โดยตรง
│ ├── Tail file (เหมือน tail -f)
│ └── เหมาะสำหรับ application logs
└── Database Audit: ดึง audit logs จาก database
├── SQL audit trail
└── Query logging
2. Parsing & Normalization:
├── Log Parsing: แยก field จาก raw log
│ ├── Regex-based parsing
│ ├── JSON, XML, CSV parsing
│ ├── Custom parser สำหรับ log format เฉพาะ
│ └── Grok patterns (Logstash/Elastic)
├── Normalization: แปลงเป็น schema มาตรฐาน
│ ├── Common Information Model (CIM)
│ ├── Elastic Common Schema (ECS)
│ ├── OCSF (Open Cybersecurity Schema Framework)
│ └── ทำให้ query ข้าม log source ได้ง่าย
└── Enrichment: เพิ่มข้อมูลเสริม
├── GeoIP lookup (IP → country/city)
├── DNS reverse lookup
├── Asset information (IP → hostname, owner, criticality)
├── User information (username → department, role)
└── Threat intelligence (IP → known malicious?)
3. Correlation Engine:
├── Rule-based Correlation:
│ ├── IF condition THEN alert
│ ├── ตัวอย่าง: ถ้า failed login > 10 ครั้ง ใน 5 นาที → alert
│ ├── Pre-built rules (vendor provides)
│ └── Custom rules (organization specific)
├── Statistical Correlation:
│ ├── Baseline behavior → detect anomaly
│ ├── ตัวอย่าง: user ปกติ login จาก Thailand
│ │ แต่วันนี้ login จาก Russia → anomaly
│ └── Threshold-based alerting
└── Machine Learning:
├── UEBA (User & Entity Behavior Analytics)
├── Detect unknown threats
├── Reduce false positives
└── ต้อง baseline training period
4. Storage (Indexing):
├── Hot Storage: ข้อมูลล่าสุด (1-30 วัน)
│ ├── SSD, fast search
│ └── ใช้งาน active
├── Warm Storage: ข้อมูลเก่า (30-90 วัน)
│ ├── HDD, search ได้แต่ช้าลง
│ └── ใช้สำหรับ investigation
├── Cold Storage: ข้อมูลเก็บถาวร (90 วัน - หลายปี)
│ ├── Archive, compressed
│ ├── S3, tape, etc.
│ └── Compliance retention
└── Retention Period ตาม compliance:
├── PCI-DSS: อย่างน้อย 1 ปี (90 วัน readily available)
├── ISO 27001: ตาม risk assessment (มักกำหนด 1-3 ปี)
├── HIPAA: 6 ปี
├── SOX: 7 ปี
└── PDPA (Thailand): ตามที่ระบุใน policyส่วนที่ 4: SIEM Platforms — เปรียบเทียบแพลตฟอร์มยอดนิยม
4.1 SIEM Platforms ในตลาด
มี SIEM หลายตัวในตลาด ทั้งแบบ commercial และ open-source แต่ละตัวมีจุดเด่น-จุดด้อยต่างกัน:
SIEM Platform Comparison:
┌──────────────┬──────────┬────────────┬──────────────┬────────────┐
│ Platform │ Type │ ค่าใช้จ่าย │ จุดเด่น │ เหมาะกับ │
├──────────────┼──────────┼────────────┼──────────────┼────────────┤
│ Splunk │ Commer. │ สูงมาก │ Search ดีสุด │ Enterprise │
│ MS Sentinel │ Cloud │ ปานกลาง │ Azure native │ MS shops │
│ Elastic SIEM │ Open+Com │ ยืดหยุ่น │ ELK ecosystem │ DevOps │
│ Wazuh │ Open-src │ ฟรี │ Agent+HIDS │ SMB/Lab │
│ QRadar │ Commer. │ สูง │ Correlation │ Enterprise │
│ LogRhythm │ Commer. │ สูง │ SOAR built-in │ Mid-Ent. │
│ Graylog │ Open+Com │ ถูก │ Log Mgmt │ Log focus │
│ Sumo Logic │ Cloud │ ปานกลาง │ Cloud-native │ Cloud-1st │
└──────────────┴──────────┴────────────┴──────────────┴────────────┘
1. Splunk Enterprise Security:
├── จุดเด่น:
│ ├── SPL (Search Processing Language) ทรงพลังที่สุด
│ ├── Ecosystem ใหญ่ (apps, add-ons, community)
│ ├── Visualization ยอดเยี่ยม
│ ├── Machine Learning Toolkit
│ ├── SOAR (Splunk SOAR / Phantom)
│ └── ผู้นำตลาด SIEM มาหลายปี
├── จุดด้อย:
│ ├── ราคาแพงมาก (คิดตาม data volume)
│ │ └── ประมาณ $2,000-$5,000/GB/day ต่อปี
│ ├── Complex deployment สำหรับ large scale
│ ├── Resource intensive (ต้อง server แรง)
│ └── Learning curve สำหรับ SPL
├── ราคาตัวอย่าง:
│ ├── 50 GB/day → $100,000-250,000/year
│ ├── 200 GB/day → $400,000-1,000,000/year
│ └── Cloud option ทำให้ flexible ขึ้น
└── เหมาะกับ: Enterprise ที่มี budget, ต้องการ best-in-class
2. Microsoft Sentinel:
├── จุดเด่น:
│ ├── Cloud-native (ไม่ต้อง manage infrastructure)
│ ├── Deep integration กับ Microsoft 365, Azure AD, Defender
│ ├── KQL (Kusto Query Language) ใช้งานง่าย
│ ├── Built-in SOAR (Logic Apps / Playbooks)
│ ├── Free data connectors สำหรับ Microsoft sources
│ ├── Threat Intelligence integration ดีเยี่ยม
│ └── Pay-as-you-go pricing
├── จุดด้อย:
│ ├── ต้องใช้ Azure (lock-in)
│ ├── Non-Microsoft log sources อาจจำกัด
│ ├── Cost ไม่ predictable (ขึ้นกับ data volume)
│ └── ต้อง Azure skills
├── ราคาตัวอย่าง:
│ ├── Pay-as-you-go: ~$2.46/GB ingested
│ ├── Commitment tier 100GB/day: ~$196/day
│ ├── Microsoft 365 E5 security logs: ฟรี
│ └── 90 วัน retention ฟรี, เพิ่มได้
└── เหมาะกับ: องค์กรที่ใช้ Microsoft ecosystem
3. Elastic SIEM (Elastic Security):
├── จุดเด่น:
│ ├── ELK Stack ecosystem (Elasticsearch, Logstash, Kibana)
│ ├── Elastic Agent (all-in-one collection)
│ ├── Detection rules by Elastic Security Research
│ ├── Endpoint protection built-in
│ ├── ยืดหยุ่นสูง, customizable
│ ├── Free tier (Basic license)
│ └── Cloud option (Elastic Cloud)
├── จุดด้อย:
│ ├── Security features จำกัดใน free tier
│ ├── ต้อง tune เยอะ (ไม่ใช่ out-of-box)
│ ├── Resource intensive สำหรับ Elasticsearch
│ └── Complexity สูง ในการ manage cluster
├── ราคาตัวอย่าง:
│ ├── Free (Basic): Log Management + basic detection
│ ├── Gold: $95/month per node
│ ├── Platinum: $125/month per node (SIEM full features)
│ ├── Elastic Cloud: ตาม resource consumption
│ └── Self-managed: ฟรี (hardware + labor cost)
└── เหมาะกับ: องค์กรที่มี in-house skills, DevSecOps
4. Wazuh (Open-Source):
├── จุดเด่น:
│ ├── ฟรีทั้งหมด (GPL v2)
│ ├── HIDS + Log Analysis + Vulnerability Detection
│ ├── Agent-based (Windows, Linux, macOS)
│ ├── File Integrity Monitoring (FIM)
│ ├── Rootkit detection
│ ├── Configuration Assessment (CIS benchmarks)
│ ├── Active Response (auto-block)
│ ├── Integration กับ ELK / OpenSearch
│ ├── Community active + documentation ดี
│ └── Compliance mapping (PCI-DSS, GDPR, HIPAA)
├── จุดด้อย:
│ ├── ไม่มี commercial support (มี Wazuh Cloud)
│ ├── SIEM correlation ไม่ advance เท่า commercial
│ ├── Dashboard ไม่สวยเท่า Splunk/Sentinel
│ ├── Scale ใหญ่ๆ ต้อง tune มาก
│ └── Learning curve สำหรับ rule writing
├── ราคา: ฟรี (self-hosted), Wazuh Cloud เริ่ม $420/month
└── เหมาะกับ: SMB, Lab, องค์กรที่มี budget จำกัด, เริ่มต้น SIEM
5. IBM QRadar:
├── จุดเด่น:
│ ├── Correlation engine แข็งแกร่งมาก
│ ├── Offense-based workflow (จัดกลุ่ม related events)
│ ├── Network flow analysis (NetFlow, sFlow)
│ ├── Vulnerability scanning integration
│ ├── IBM X-Force threat intelligence
│ └── Log source auto-discovery
├── จุดด้อย:
│ ├── ราคาสูง
│ ├── UI ค่อนข้างเก่า
│ ├── Deployment ซับซ้อน
│ └── IBM กำลัง transition ไป cloud (QRadar on Cloud/SIEM as a Service)
├── ราคาตัวอย่าง: $800-$2,400/EPS (events per second) ต่อปี
└── เหมาะกับ: Enterprise ที่ใช้ IBM ecosystem
6. LogRhythm:
├── จุดเด่น:
│ ├── All-in-one: SIEM + UEBA + SOAR + NDR
│ ├── Smart Response (built-in automation)
│ ├── Case management ในตัว
│ ├── AI Engine สำหรับ anomaly detection
│ └── Pre-built compliance packages
├── จุดด้อย:
│ ├── ราคาสูง
│ ├── Windows-centric (server runs on Windows)
│ └── Market share ลดลง
├── ราคาตัวอย่าง: $28,000-$100,000+ (perpetual license)
└── เหมาะกับ: Mid-size enterprise
7. Graylog:
├── จุดเด่น:
│ ├── Log Management ที่ดีที่สุดในราคาถูก
│ ├── Open-source core
│ ├── ใช้งานง่าย, UI ดี
│ ├── Processing pipelines ยืดหยุ่น
│ ├── Sidecar (log collector)
│ └── SIEM features ใน Enterprise version
├── จุดด้อย:
│ ├── SIEM features จำกัด (ไม่เท่า full SIEM)
│ ├── Correlation rules ยังพัฒนาอยู่
│ └── Enterprise features ต้องจ่ายเงิน
├── ราคา: Open $0, Operations ~$1,250/month, Security ~$1,550/month
└── เหมาะกับ: Log Management focus, SMB SIEMส่วนที่ 5: Wazuh — ติดตั้ง Open-Source SIEM
5.1 Wazuh Architecture
Wazuh เป็น SIEM/XDR ที่ได้รับความนิยมสูงสุดในฝั่ง open-source เหมาะมากสำหรับเริ่มต้น SIEM หรือใช้งานจริงในองค์กรขนาดเล็ก-กลาง:
Wazuh Architecture:
┌────────────────────────────────────────────────────┐
│ Wazuh Dashboard │
│ (OpenSearch Dashboards / Kibana) │
│ ┌────────────────────────────────────────────┐ │
│ │ Security Events │ Integrity │ Compliance │ │
│ │ Vulnerability │ SCA │ MITRE ATT&CK │ │
│ └────────────────────────────────────────────┘ │
└────────────────────┬───────────────────────────────┘
│
┌────────────────────▼───────────────────────────────┐
│ Wazuh Indexer │
│ (OpenSearch / Elasticsearch) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ wazuh- │ │ wazuh- │ │ wazuh- │ │
│ │ alerts │ │ archives│ │ stats │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────┬───────────────────────────────┘
│
┌────────────────────▼───────────────────────────────┐
│ Wazuh Manager (Server) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Analysis │ │ Rule │ │ Active │ │
│ │ Engine │ │ Engine │ │ Response │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Syslog │ │ FIM │ │ Vuln │ │
│ │ Collector│ │ Module │ │ Detector │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└────────────────────┬───────────────────────────────┘
│
┌────────────┼────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Wazuh │ │ Wazuh │ │ Wazuh │
│ Agent │ │ Agent │ │ Agent │
│(Windows)│ │ (Linux) │ │ (macOS) │
└─────────┘ └─────────┘ └─────────┘
Components:
├── Wazuh Manager: สมองของระบบ
│ ├── รับ log จาก agents
│ ├── วิเคราะห์ด้วย rules
│ ├── สร้าง alerts
│ ├── Active Response (auto-block)
│ └── API สำหรับ integration
│
├── Wazuh Indexer: เก็บข้อมูล
│ ├── Based on OpenSearch (fork ของ Elasticsearch)
│ ├── Index alerts และ events
│ ├── Full-text search
│ └── Data retention management
│
├── Wazuh Dashboard: แสดงผล
│ ├── Based on OpenSearch Dashboards
│ ├── Security events overview
│ ├── MITRE ATT&CK mapping
│ ├── Compliance dashboards
│ └── Custom visualizations
│
└── Wazuh Agent: ติดตั้งบน endpoints
├── Log collection
├── File Integrity Monitoring (FIM)
├── Rootkit detection
├── System inventory
├── Configuration Assessment
├── Vulnerability detection
└── Active Response execution5.2 ติดตั้ง Wazuh แบบ All-in-One
Wazuh สามารถติดตั้งแบบ all-in-one บน server เครื่องเดียว เหมาะสำหรับองค์กรขนาดเล็กหรือ lab:
Wazuh Installation (All-in-One):
System Requirements (ขั้นต่ำ):
├── OS: Ubuntu 22.04 LTS / CentOS 8+ / Amazon Linux 2
├── CPU: 4 cores (แนะนำ 8 cores)
├── RAM: 8 GB (แนะนำ 16 GB)
├── Disk: 50 GB SSD (แนะนำ 200 GB+)
├── Network: เข้าถึงได้จาก agents
└── Agents 1-50 ตัว: 4 cores, 8 GB RAM พอ
Step 1: ดาวน์โหลด installation script
$ curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
$ curl -sO https://packages.wazuh.com/4.9/config.yml
Step 2: แก้ไข config.yml (กำหนดชื่อ node)
$ nano config.yml
---
nodes:
indexer:
- name: wazuh-indexer
ip: "127.0.0.1"
server:
- name: wazuh-server
ip: "127.0.0.1"
dashboard:
- name: wazuh-dashboard
ip: "127.0.0.1"
Step 3: Generate certificates
$ bash wazuh-install.sh --generate-config-files
Step 4: Install Wazuh Indexer
$ bash wazuh-install.sh --wazuh-indexer wazuh-indexer
Step 5: Initialize cluster
$ bash wazuh-install.sh --start-cluster
Step 6: Install Wazuh Manager
$ bash wazuh-install.sh --wazuh-server wazuh-server
Step 7: Install Wazuh Dashboard
$ bash wazuh-install.sh --wazuh-dashboard wazuh-dashboard
Step 8: เข้า Dashboard
$ URL: https://your-server-ip
$ User: admin
$ Pass: (แสดงตอน install หรือใน /usr/share/wazuh-install-files/wazuh-passwords.txt)
ทั้งหมดใช้เวลาประมาณ 15-30 นาที5.3 ติดตั้ง Wazuh Agent
Wazuh Agent Installation:
Windows Agent:
# Download MSI installer จาก Wazuh website
# หรือใช้ PowerShell:
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi `
-OutFile wazuh-agent.msi
# Install with manager IP
msiexec.exe /i wazuh-agent.msi /q `
WAZUH_MANAGER="192.168.1.100" `
WAZUH_AGENT_NAME="workstation-01" `
WAZUH_AGENT_GROUP="windows-endpoints"
# Start service
NET START WazuhSvc
Linux Agent (Ubuntu/Debian):
$ curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
$ echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
$ apt-get update && apt-get install wazuh-agent
$ nano /var/ossec/etc/ossec.conf
→ เปลี่ยน MANAGER_IP เป็น IP ของ Wazuh Manager
$ systemctl daemon-reload
$ systemctl enable wazuh-agent
$ systemctl start wazuh-agent
Linux Agent (RHEL/CentOS):
$ rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
$ cat > /etc/yum.repos.d/wazuh.repo << 'EOF'
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
EOF
$ yum install wazuh-agent
$ nano /var/ossec/etc/ossec.conf
$ systemctl enable wazuh-agent && systemctl start wazuh-agent
ตรวจสอบ Agent เชื่อมต่อสำเร็จ:
# บน Wazuh Manager:
$ /var/ossec/bin/agent_control -l
→ จะเห็น agent ที่เพิ่ง register
# หรือดูใน Dashboard:
→ Agents tab → จะเห็น agent status: Activeส่วนที่ 6: Correlation Rules — หัวใจของ SIEM
6.1 Correlation Rules คืออะไร?
Correlation Rules คือกฎที่ SIEM ใช้ในการวิเคราะห์ events หลายๆ อัน เพื่อตรวจจับ patterns ที่บ่งบอกถึงภัยคุกคาม event เดี่ยวๆ อาจไม่น่าสนใจ แต่เมื่อรวมกันอาจเป็น attack:
Correlation Rule Concepts:
ตัวอย่างที่ 1: Brute Force Detection
├── Event เดี่ยว: "Failed login for user admin" → ปกติ (พิมพ์ผิด)
├── 50 events ใน 2 นาที: "Failed login × 50" → Brute Force Attack!
├── ตามด้วย: "Successful login for user admin" → Brute Force สำเร็จ!!
└── Correlation Rule:
IF failed_login COUNT > 20 WITHIN 5 minutes
FROM same source_ip TO same destination
THEN alert "Brute Force Attempt" severity HIGH
IF followed_by successful_login WITHIN 10 minutes
THEN alert "Brute Force SUCCESS" severity CRITICAL
ตัวอย่างที่ 2: Lateral Movement
├── Event 1: "User X logged in to Server A" → ปกติ
├── Event 2: "User X logged in to Server B (5 min later)" → อาจปกติ
├── Event 3: "User X logged in to Server C, D, E, F (10 min)" → Lateral Movement!
├── Correlation Rule:
│ IF same_user authenticates_to > 5 different_hosts
│ WITHIN 30 minutes
│ THEN alert "Possible Lateral Movement" severity HIGH
└── เพิ่มเติม: ถ้า user ไม่เคย login hosts เหล่านี้มาก่อน → เพิ่ม severity
ตัวอย่างที่ 3: Data Exfiltration
├── Event 1: "Large file upload to external IP" → อาจปกติ (cloud backup)
├── Event 2: "Upload outside business hours" → น่าสงสัย
├── Event 3: "Upload to newly registered domain" → มาก!
├── Event 4: "User recently accessed sensitive files" → Data Exfiltration!
└── Correlation Rule:
IF outbound_data_transfer > 500MB
AND destination NOT IN whitelist
AND time NOT IN business_hours
AND user accessed sensitive_files WITHIN 24 hours
THEN alert "Possible Data Exfiltration" severity CRITICAL6.2 Wazuh Custom Rules
Wazuh ใช้ XML format สำหรับ rules สามารถเขียน custom rules เพิ่มได้:
Wazuh Rule Writing:
# Rule file location:
/var/ossec/etc/rules/local_rules.xml
# ตัวอย่าง Rule: Brute Force SSH Detection
<group name="custom_ssh_brute_force">
<rule id="100001" level="10" frequency="10" timeframe="120">
<if_matched_sid>5710</if_matched_sid>
<description>SSH brute force attack detected (10+ failures in 2 min)</description>
<mitre>
<id>T1110</id>
</mitre>
<group>authentication_failures,brute_force</group>
</rule>
</group>
# ตัวอย่าง Rule: Windows Admin Account Created
<group name="custom_windows_admin">
<rule id="100010" level="12">
<if_sid>60144</if_sid>
<field name="win.system.eventID">^4720$</field>
<description>New Windows user account created: $(win.eventdata.targetUserName)</description>
<mitre>
<id>T1136.001</id>
</mitre>
<group>account_created,windows</group>
</rule>
<rule id="100011" level="14">
<if_sid>100010</if_sid>
<field name="win.eventdata.targetUserName">admin|administrator</field>
<description>CRITICAL: Admin account created outside of change window</description>
<group>admin_account_created,windows</group>
</rule>
</group>
# ตัวอย่าง Rule: Suspicious PowerShell
<group name="custom_powershell">
<rule id="100020" level="12">
<if_sid>61600</if_sid>
<field name="win.eventdata.scriptBlockText">
Invoke-Mimikatz|Invoke-WebRequest.*-OutFile|
DownloadString|IEX.*Net.WebClient|
-enc[oO]ded[cC]ommand|FromBase64String
</field>
<description>Suspicious PowerShell execution detected</description>
<mitre>
<id>T1059.001</id>
</mitre>
<group>powershell,suspicious_execution</group>
</rule>
</group>
# Rule Levels (Wazuh):
├── 0-3: Informational (ไม่ alert)
├── 4-7: Low severity
├── 8-11: Medium severity
├── 12-14: High severity
└── 15: Critical (maximum)
# Active Response ตัวอย่าง:
# Block IP ที่ brute force อัตโนมัติ
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100001</rules_id>
<timeout>3600</timeout>
</active-response>
# → IP ที่ brute force จะถูก block 1 ชั่วโมงอัตโนมัติส่วนที่ 7: SIEM Use Cases — กรณีศึกษาจริง
7.1 Use Cases ที่พบบ่อย
SIEM ไม่ได้มีไว้แค่เก็บ log แต่ต้องตรวจจับภัยคุกคามจริง ต่อไปนี้คือ use cases ที่สำคัญ:
SIEM Use Cases:
1. Brute Force Detection:
├── Scenario: Attacker พยายาม login ด้วย password หลายตัว
├── Detection:
│ ├── Monitor: Authentication failure events
│ ├── Sources: AD (4625), SSH (auth.log), VPN, Web apps
│ ├── Rule: > 10 failures จาก same source ใน 5 นาที
│ └── Escalation: ถ้ามี success หลัง failures → CRITICAL
├── Response:
│ ├── Auto-block source IP (active response)
│ ├── Lock account ชั่วคราว
│ ├── Notify SOC analyst
│ └── Investigate: credential stuffing? targeted?
└── MITRE ATT&CK: T1110 (Brute Force)
2. Lateral Movement Detection:
├── Scenario: Attacker ใช้ credentials ที่ได้มา login ไปเรื่อยๆ
├── Detection:
│ ├── Monitor: Same user → multiple hosts ในเวลาสั้น
│ ├── Sources: Windows Event 4624 (Type 3, 10), SSH logs
│ ├── Rule: User login > 5 hosts ใน 30 นาที
│ ├── Anomaly: User ไม่เคย login host นี้มาก่อน
│ └── Tools ที่ attacker ใช้: PsExec, WMI, RDP, PowerShell
├── Response:
│ ├── Isolate suspicious workstation
│ ├── Reset user credentials
│ ├── Investigate timeline
│ └── Check for persistence mechanisms
└── MITRE ATT&CK: T1021 (Remote Services)
3. Data Exfiltration Detection:
├── Scenario: ข้อมูลสำคัญถูกส่งออกนอกองค์กร
├── Detection:
│ ├── Monitor: Unusual outbound data volume
│ ├── Sources: Proxy, firewall, DLP, cloud access logs
│ ├── Rule: Upload > 500MB to external ในช่วง off-hours
│ ├── Rule: Access sensitive folder + large upload
│ ├── Rule: Upload to newly registered domain
│ └── DNS: unusual DNS query volume (DNS tunneling)
├── Response:
│ ├── Block destination immediately
│ ├── Identify what data was accessed
│ ├── Preserve evidence (disk image)
│ └── Report to management / legal
└── MITRE ATT&CK: T1041 (Exfiltration Over C2 Channel)
4. Insider Threat Detection:
├── Scenario: พนักงาน authorized ทำสิ่งผิดปกติ
├── Detection:
│ ├── UEBA: User behavior baseline
│ ├── Access pattern changes
│ │ ├── Login นอกเวลาทำงาน
│ │ ├── Access ข้อมูลที่ไม่เคย access
│ │ ├── Download จำนวนมากผิดปกติ
│ │ └── USB device usage
│ ├── HR indicators: resigned, PIP, disgruntled
│ └── Privilege escalation: self-assign permissions
├── Response:
│ ├── Enhanced monitoring
│ ├── Coordinate with HR
│ ├── Restrict access if necessary
│ └── Legal/compliance involvement
└── MITRE ATT&CK: T1078 (Valid Accounts)
5. Malware/Ransomware Detection:
├── Scenario: Malware execution หรือ ransomware encryption
├── Detection:
│ ├── EDR/AV alerts → SIEM correlation
│ ├── File Integrity Monitoring (mass file changes)
│ ├── Suspicious process execution
│ │ ├── cmd.exe spawned by Word/Excel
│ │ ├── PowerShell download cradle
│ │ ├── Certutil decode
│ │ └── Process injection indicators
│ ├── Network: C2 callbacks, beaconing patterns
│ │ ├── Regular interval connections
│ │ ├── DNS to DGA domains
│ │ └── HTTPS to unusual ports
│ └── File extension changes (.encrypted, .locked)
├── Response:
│ ├── Isolate endpoint immediately
│ ├── Block C2 IPs/domains at firewall
│ ├── Identify patient zero
│ ├── Check backup integrity
│ └── Invoke incident response plan
└── MITRE ATT&CK: T1486 (Data Encrypted for Impact)
6. Privilege Escalation:
├── Scenario: User ได้ admin privileges โดยไม่ได้รับอนุญาต
├── Detection:
│ ├── Windows Event 4732: Member added to admin group
│ ├── Windows Event 4672: Special privileges assigned
│ ├── sudo usage on Linux
│ ├── Service account usage anomaly
│ └── Correlate: ไม่มี change ticket → unauthorized
├── Response:
│ ├── Revert privilege change
│ ├── Investigate how access was obtained
│ ├── Check for other compromised accounts
│ └── Review access control policies
└── MITRE ATT&CK: T1078.002 (Domain Accounts)ส่วนที่ 8: SOAR Integration — Automated Response
8.1 SOAR (Security Orchestration, Automation and Response) คืออะไร?
SIEM ตรวจจับภัยคุกคาม แต่ SOAR ช่วยตอบสนองอัตโนมัติ ลดภาระ analyst:
SOAR Integration with SIEM:
SOAR คืออะไร?
├── Security Orchestration: รวม tools หลายตัวทำงานร่วมกัน
├── Automation: ทำงานซ้ำๆ อัตโนมัติ (ไม่ต้องรอคน)
├── Response: ดำเนินการตอบสนองต่อ incident
└── ลดเวลา Mean Time to Respond (MTTR) จากชั่วโมง → นาที
SOAR Platforms:
├── Splunk SOAR (Phantom)
├── Microsoft Sentinel (Logic Apps)
├── Palo Alto XSOAR (Cortex XSOAR)
├── IBM Resilient
├── Swimlane
├── TheHive + Cortex (open-source)
├── Shuffle (open-source)
└── n8n + Wazuh (DIY integration)
ตัวอย่าง Playbook: Phishing Email Response
┌─────────────────────────────────────────┐
│ Trigger: SIEM alert "Phishing email" │
├─────────────────────────────────────────┤
│ Step 1: Extract IOCs │
│ ├── Sender email, subject │
│ ├── URLs in email body │
│ ├── Attachment hashes │
│ └── Source IP │
├─────────────────────────────────────────┤
│ Step 2: Enrich IOCs │
│ ├── Check URL → VirusTotal │
│ ├── Check hash → VirusTotal │
│ ├── Check IP → AbuseIPDB │
│ └── Check domain → WHOIS │
├─────────────────────────────────────────┤
│ Step 3: Decision │
│ ├── IF malicious → auto-respond │
│ └── IF suspicious → escalate to analyst│
├─────────────────────────────────────────┤
│ Step 4: Auto-Response (if malicious) │
│ ├── Block sender in email gateway │
│ ├── Block URLs at proxy/firewall │
│ ├── Search mailboxes: who else got it? │
│ ├── Delete from all mailboxes │
│ ├── Block attachment hash at EDR │
│ └── Notify affected users │
├─────────────────────────────────────────┤
│ Step 5: Document │
│ ├── Create incident ticket │
│ ├── Record all actions taken │
│ └── Update threat intelligence │
└─────────────────────────────────────────┘
ตัวอย่าง Playbook: Brute Force Response
┌─────────────────────────────────────────┐
│ Trigger: SIEM alert "Brute Force" │
├─────────────────────────────────────────┤
│ Step 1: Verify │
│ ├── Check source IP reputation │
│ ├── Is source internal or external? │
│ └── Is target a critical system? │
├─────────────────────────────────────────┤
│ Step 2: Contain │
│ ├── External → Block IP at firewall │
│ ├── Internal → Isolate endpoint │
│ └── Lock target account (if success) │
├─────────────────────────────────────────┤
│ Step 3: Investigate │
│ ├── Check if login succeeded │
│ ├── Check target account activity │
│ ├── Look for lateral movement │
│ └── Check other targets from same src │
├─────────────────────────────────────────┤
│ Step 4: Remediate │
│ ├── Reset password (if compromised) │
│ ├── Enable MFA on target account │
│ ├── Add permanent block (if needed) │
│ └── Update firewall rules │
└─────────────────────────────────────────┘
SOAR Benefits:
├── MTTR ลดลง 80-90% (จาก 4+ ชั่วโมง → 15 นาที)
├── Analyst ไม่ต้องทำงานซ้ำๆ (focus high-value tasks)
├── Response สม่ำเสมอ (ไม่ขึ้นกับ skill ของ analyst)
├── Documentation อัตโนมัติ (audit trail ครบ)
└── Scale ได้: 100 alerts/day → same team handle ได้ส่วนที่ 9: Compliance Reporting — PCI-DSS, ISO 27001
9.1 SIEM กับ Compliance
SIEM เป็นเครื่องมือสำคัญในการทำ compliance เพราะหลายมาตรฐานกำหนดให้ต้องมี log management และ monitoring:
Compliance Requirements ที่ SIEM ช่วยตอบ:
PCI-DSS (Payment Card Industry):
├── Req 10.1: Implement audit trails for all access
│ └── SIEM: เก็บ log ทุก access to cardholder data
├── Req 10.2: Log specific events
│ ├── User access to cardholder data
│ ├── Actions by admin/root
│ ├── Access to audit trails
│ ├── Invalid access attempts
│ ├── Use of authentication mechanisms
│ ├── Initialization of audit logs
│ └── Creation/deletion of system objects
├── Req 10.3: Record audit trail entries
│ ├── User identification, event type
│ ├── Date/time, success/failure
│ ├── Origination of event
│ └── Identity of affected data/resource
├── Req 10.5: Secure audit trails
│ └── SIEM: centralized, tamper-evident storage
├── Req 10.6: Review logs daily
│ └── SIEM: automated review + alerting
├── Req 10.7: Retain logs for 1 year (90 days readily available)
│ └── SIEM: hot storage 90 days + cold archive 1 year
└── Req 11.5: Deploy change-detection mechanisms
└── SIEM/Wazuh: File Integrity Monitoring (FIM)
ISO 27001:
├── A.12.4: Logging and monitoring
│ ├── A.12.4.1: Event logging
│ ├── A.12.4.2: Protection of log information
│ ├── A.12.4.3: Administrator and operator logs
│ └── A.12.4.4: Clock synchronization (NTP)
├── A.16: Information security incident management
│ ├── A.16.1.2: Reporting information security events
│ ├── A.16.1.4: Assessment of information security events
│ └── A.16.1.5: Response to information security incidents
└── SIEM ช่วย: centralized logging, incident detection, evidence
PDPA (Thailand Personal Data Protection Act):
├── ต้อง log การเข้าถึงข้อมูลส่วนบุคคล
├── ต้องตรวจจับ unauthorized access
├── ต้องแจ้งเตือนเมื่อเกิด data breach
├── ต้องเก็บหลักฐานสำหรับ investigation
└── SIEM ช่วย: audit trail ครบถ้วน, detection, alerting
Wazuh Compliance Dashboards:
├── PCI-DSS: built-in dashboard แสดง compliance status
├── GDPR: การป้องกันข้อมูลส่วนบุคคล
├── HIPAA: healthcare data protection
├── NIST 800-53: security controls
├── TSC (SOC 2): trust services criteria
└── CIS Benchmarks: configuration assessmentส่วนที่ 10: Log Retention Policies — นโยบายเก็บ Log
10.1 ออกแบบ Log Retention Policy
การกำหนด retention policy ที่เหมาะสมสำคัญมาก — เก็บน้อยไปอาจไม่ comply, เก็บมากไปเปลือง storage:
Log Retention Policy Design:
ปัจจัยที่ต้องพิจารณา:
├── Compliance requirements (PCI-DSS 1 ปี, HIPAA 6 ปี)
├── Legal requirements (กฎหมายไทย, พ.ร.บ.คอมพิวเตอร์)
│ └── พ.ร.บ.คอมพิวเตอร์ 2560: เก็บ log อย่างน้อย 90 วัน
├── Investigation needs (incident ใช้เวลา discover เฉลี่ย 204 วัน)
├── Storage cost (1 GB/day × 365 วัน = 365 GB/year)
└── Performance impact (ข้อมูลมาก → search ช้า)
Recommended Retention by Log Type:
├── Security Logs (Firewall, IDS, Auth):
│ ├── Hot: 90 วัน (readily searchable)
│ ├── Warm: 180 วัน (searchable, slower)
│ ├── Cold: 1-3 ปี (archived, compliance)
│ └── เหตุผล: สำคัญที่สุดสำหรับ security
│
├── System Logs (OS, application):
│ ├── Hot: 30 วัน
│ ├── Warm: 90 วัน
│ ├── Cold: 1 ปี
│ └── เหตุผล: ใช้สำหรับ troubleshoot + forensics
│
├── Network Flow Logs:
│ ├── Hot: 7 วัน (data volume สูงมาก)
│ ├── Warm: 30 วัน
│ ├── Cold: 90 วัน
│ └── เหตุผล: volume สูง, ใช้สำหรับ network forensics
│
├── Web/Proxy Logs:
│ ├── Hot: 30 วัน
│ ├── Warm: 90 วัน
│ ├── Cold: 1 ปี (PCI-DSS ถ้าเกี่ยวข้อง)
│ └── เหตุผล: tracking user web access
│
└── Audit/Compliance Logs:
├── Hot: 90 วัน
├── Warm: 1 ปี
├── Cold: 3-7 ปี (ตาม requirement)
└── เหตุผล: ต้องเก็บนานตาม compliance
Storage Estimation:
├── ค่าเฉลี่ย log volume:
│ ├── Firewall: 1-10 GB/day (ขึ้นกับ traffic)
│ ├── Windows Server: 50-500 MB/day per server
│ ├── Linux Server: 20-200 MB/day per server
│ ├── Endpoint: 10-100 MB/day per endpoint
│ └── Cloud: 100 MB - 5 GB/day per account
│
├── ตัวอย่าง: SMB 100 users, 10 servers, 3 firewalls
│ ├── Daily log: ~5 GB/day
│ ├── Hot 90 วัน: 450 GB SSD
│ ├── Warm 180 วัน: 900 GB HDD
│ ├── Cold 1 ปี: 1.8 TB (compressed ~500 GB)
│ └── Total: ~2 TB storage
│
└── Compression:
├── Raw → indexed: ~1.5x (index overhead)
├── Warm/Cold → compressed: ~5-10x savings
└── ใช้ ILM (Index Lifecycle Management) จัดการส่วนที่ 11: SIEM Tuning — ลด False Positives
11.1 ปัญหา False Positives และวิธีแก้
False Positive คือ alert ที่ SIEM แจ้งเตือนแต่จริงๆ แล้วไม่ใช่ภัยคุกคาม ถ้ามีมากเกินไป analyst จะเกิด alert fatigue — เมื่อยจน ignore alert จริงๆ ไป:
SIEM Tuning Strategies:
ปัญหา Alert Fatigue:
├── SIEM ใหม่ตั้งค่า default → alert หลายพันต่อวัน
├── 80-90% อาจเป็น false positive
├── Analyst เหนื่อย → เริ่ม ignore alerts
├── True positive หลุด → incident เกิดขึ้น
└── "The Boy Who Cried Wolf" problem
Tuning Process:
1. Baseline (สัปดาห์ที่ 1-2):
├── เปิด SIEM ด้วย default rules
├── อย่า alert ทุกอย่าง — observe ก่อน
├── บันทึกว่า rule ไหน fire บ่อย
├── ระบุ normal behavior ขององค์กร
└── สร้าง whitelist เบื้องต้น
2. Whitelisting (สัปดาห์ที่ 2-4):
├── Whitelist known scanners (vulnerability scanner, Nessus)
├── Whitelist service accounts ที่ login หลาย hosts
├── Whitelist scheduled tasks (backup, patching)
├── Whitelist known admin activities
├── Whitelist monitoring tools (SNMP polling, health checks)
└── สำคัญ: Document ทุก whitelist entry!
3. Threshold Adjustment (สัปดาห์ที่ 3-6):
├── Failed login 5 ครั้ง = false positive เยอะ
│ └── ปรับเป็น 20 ครั้ง ใน 5 นาที
├── Port scan detection sensitivity
│ └── ปรับ threshold ให้เหมาะกับ traffic pattern
├── Data transfer alerts
│ └── ปรับตาม normal business hours volume
└── ทดสอบ: threshold ใหม่ยังจับ true positive ได้?
4. Rule Refinement (ต่อเนื่อง):
├── แยก rules ที่ไม่ applicable ออก
│ └── เช่น Linux rules ถ้าไม่มี Linux
├── เพิ่ม context ให้ rules
│ └── เช่น alert เฉพาะ critical servers
├── สร้าง multi-stage rules
│ └── Alert เมื่อ condition 1 AND condition 2
├── ใช้ risk scoring แทน binary alert
│ └── Low risk events accumulate → alert เมื่อ score สูง
└── Review rules ทุกเดือน
5. Metrics สำหรับวัด SIEM Effectiveness:
├── True Positive Rate: ≥ 80% (alert จริง)
├── False Positive Rate: ≤ 20%
├── Mean Time to Detect (MTTD): target < 1 ชั่วโมง
├── Mean Time to Respond (MTTR): target < 4 ชั่วโมง
├── Alerts per day per analyst: target < 50
├── Rules reviewed per month: target 100%
└── Coverage: % of log sources monitored vs totalส่วนที่ 12: Threat Intelligence Feeds
12.1 Threat Intelligence คืออะไร?
Threat Intelligence (TI) คือข้อมูลเกี่ยวกับภัยคุกคามที่เกิดขึ้นทั่วโลก เช่น IP ของ attacker, domain ที่เป็น malware C2, hash ของ malware ล่าสุด — เมื่อ integrate กับ SIEM จะทำให้ตรวจจับภัยคุกคามได้ก่อนที่จะเกิดขึ้นจริง:
Threat Intelligence Integration:
Types of Threat Intelligence:
├── IOCs (Indicators of Compromise):
│ ├── IP addresses (known malicious)
│ ├── Domain names (C2, phishing)
│ ├── File hashes (malware MD5/SHA256)
│ ├── URLs (malicious links)
│ ├── Email addresses (phishing senders)
│ └── YARA rules (malware signatures)
│
├── TTPs (Tactics, Techniques, and Procedures):
│ ├── MITRE ATT&CK framework
│ ├── Attacker behavior patterns
│ └── Attack methodologies
│
└── Strategic Intelligence:
├── Threat landscape reports
├── Industry-specific threats
└── Geopolitical analysis
Free Threat Intelligence Feeds:
├── AlienVault OTX (Open Threat Exchange):
│ ├── Community-driven
│ ├── Pulses with IOCs
│ ├── API available
│ ├── Wazuh integration built-in
│ └── URL: otx.alienvault.com
│
├── Abuse.ch:
│ ├── URLhaus (malicious URLs)
│ ├── MalwareBazaar (malware samples)
│ ├── ThreatFox (IOCs)
│ ├── Feodo Tracker (botnet C2)
│ └── Free and community-driven
│
├── MISP (Malware Information Sharing Platform):
│ ├── Open-source threat intelligence platform
│ ├── Community sharing
│ ├── STIX/TAXII support
│ └── Self-hosted or join community instances
│
├── VirusTotal:
│ ├── File/URL/IP scanning
│ ├── API (limited free, paid premium)
│ ├── SIEM integration via API
│ └── ใช้ enrich alerts ด้วย VT results
│
└── CrowdSec:
├── Community-based IP blocklist
├── Real-time threat intelligence
├── Easy integration
└── Free tier available
Wazuh + Threat Intelligence:
# ossec.conf configuration
<ossec_config>
<integration>
<name>virustotal</name>
<api_key>YOUR_VT_API_KEY</api_key>
<rule_id>87105</rule_id>
<alert_format>json</alert_format>
</integration>
</ossec_config>
# CDB Lists (IP reputation):
# /var/ossec/etc/lists/blacklist-ip
# Format: key:value
1.2.3.4:malware-c2
5.6.7.8:phishing
9.10.11.12:scanner
# Rule ใช้ CDB list:
<rule id="100050" level="12">
<if_sid>5710</if_sid>
<list field="srcip" lookup="address_match_key">
etc/lists/blacklist-ip
</list>
<description>Connection from known malicious IP</description>
</rule>ส่วนที่ 13: SOC Operations — ปฏิบัติการ Security Operations Center
13.1 SOC คืออะไรและทำงานอย่างไร?
SOC (Security Operations Center) คือทีมที่ใช้ SIEM เป็นเครื่องมือหลักในการ monitor, detect, investigate และ respond ต่อภัยคุกคาม:
SOC Operations:
SOC Team Structure:
├── Tier 1 - Alert Triage (L1 Analyst):
│ ├── หน้าที่: ตรวจสอบ alerts เบื้องต้น
│ ├── ตัดสินใจ: true positive vs false positive
│ ├── Basic investigation (5-15 นาทีต่อ alert)
│ ├── Escalate ไป Tier 2 ถ้าจำเป็น
│ ├── Follow playbooks/runbooks
│ ├── Skills: SIEM basics, networking, OS
│ └── ปริมาณ: 20-50 alerts/shift (8 ชั่วโมง)
│
├── Tier 2 - Incident Investigation (L2 Analyst):
│ ├── หน้าที่: สืบสวนเชิงลึก
│ ├── Threat hunting (proactive search)
│ ├── Malware analysis (basic)
│ ├── Incident response coordination
│ ├── SIEM rule development
│ ├── Skills: advanced SIEM, forensics, scripting
│ └── ปริมาณ: 5-10 escalated cases/day
│
├── Tier 3 - Threat Hunting & Engineering (Senior):
│ ├── หน้าที่: proactive threat hunting
│ ├── Advanced malware analysis
│ ├── SIEM content development (rules, dashboards)
│ ├── Threat intelligence analysis
│ ├── Incident response leadership
│ ├── Red/purple team coordination
│ ├── Skills: deep security, scripting, forensics
│ └── ปริมาณ: strategic work + major incidents
│
└── SOC Manager:
├── Team management
├── Metrics and reporting
├── Process improvement
├── Vendor management
├── Budget and resource planning
└── Executive reporting
SOC Daily Operations:
├── Morning Shift Handover (5 นาที):
│ ├── Review overnight alerts summary
│ ├── Open incidents status
│ ├── Known issues / maintenance windows
│ └── Threat intelligence updates
│
├── Continuous Monitoring:
│ ├── Monitor SIEM dashboard
│ ├── Triage incoming alerts
│ ├── Investigate escalated alerts
│ ├── Update incident tickets
│ └── Execute playbooks
│
├── Daily Tasks:
│ ├── Review top alerts by severity
│ ├── Check SIEM health (agent status, log flow)
│ ├── Review new threat intelligence
│ ├── Update correlation rules (if needed)
│ └── Document findings
│
└── Weekly/Monthly:
├── Metrics review (MTTD, MTTR, false positive rate)
├── Rule tuning session
├── Tabletop exercise (quarterly)
├── SIEM content review
└── Threat landscape briefing
SOC Metrics (KPIs):
├── MTTD (Mean Time to Detect): < 1 hour (target)
├── MTTR (Mean Time to Respond): < 4 hours (target)
├── Alert Volume: trend over time
├── True Positive Rate: > 80%
├── Incidents Closed: per analyst per week
├── Log Source Coverage: % monitored vs total
├── SLA Compliance: % alerts reviewed within SLA
└── Analyst Utilization: balanced workloadส่วนที่ 14: SIEM Sizing and Architecture
14.1 ออกแบบ SIEM สำหรับองค์กรขนาดต่างๆ
ขนาดของ SIEM ขึ้นกับจำนวน log sources, data volume, retention requirements และจำนวน concurrent users:
SIEM Sizing Guide:
Small (SMB: 50-200 users, 5-20 servers):
├── Log Volume: 1-5 GB/day
├── EPS (Events Per Second): 100-500
├── Architecture: All-in-one
│ ├── Single server: Wazuh Manager + Indexer + Dashboard
│ ├── CPU: 8 cores, RAM: 16 GB, Disk: 500 GB SSD
│ └── หรือ VM บน existing Proxmox/VMware
├── Recommended Platform: Wazuh (free) หรือ Graylog
├── Agents: 50-200 endpoints
├── Retention: Hot 30d, Warm 90d, Cold 1y
├── Team: 1-2 คน (part-time SOC)
└── Budget: ฿0 (self-hosted) - ฿50,000/month (cloud)
Medium (200-1,000 users, 20-100 servers):
├── Log Volume: 5-50 GB/day
├── EPS: 500-5,000
├── Architecture: Distributed
│ ├── 1x Wazuh Manager: 8 cores, 16 GB RAM
│ ├── 3x Indexer nodes (cluster): 8 cores, 32 GB RAM, 1 TB SSD each
│ ├── 1x Dashboard: 4 cores, 8 GB RAM
│ ├── Network load balancer (optional)
│ └── Dedicated VLAN สำหรับ SIEM
├── Recommended Platform: Wazuh, Elastic SIEM, หรือ Sentinel
├── Agents: 200-1,000 endpoints
├── Retention: Hot 90d, Warm 180d, Cold 2y
├── Team: 2-5 คน (dedicated SOC หรือ MSSP)
└── Budget: ฿50,000 - ฿200,000/month
Large (1,000+ users, 100+ servers, multi-site):
├── Log Volume: 50-500+ GB/day
├── EPS: 5,000-50,000+
├── Architecture: Multi-tier
│ ├── 2x Wazuh Manager (cluster): 16 cores, 32 GB RAM
│ ├── 5-10x Indexer nodes: 16 cores, 64 GB RAM, 2 TB SSD
│ ├── 2x Dashboard (HA): 8 cores, 16 GB RAM
│ ├── Log forwarders at each site
│ ├── Dedicated network segment
│ ├── Hot-Warm-Cold architecture (ILM)
│ └── Object storage for cold data (S3/MinIO)
├── Recommended Platform: Splunk, Sentinel, QRadar, Elastic
├── Agents: 1,000-10,000+ endpoints
├── Retention: Hot 90d, Warm 1y, Cold 3-7y
├── Team: 5-20+ คน (24/7 SOC)
└── Budget: ฿200,000 - ฿2,000,000+/month
Hardware Sizing Formula:
├── Storage per day = EPS × avg_event_size × 86,400 × 1.3 (index overhead)
│ ├── ตัวอย่าง: 1,000 EPS × 500 bytes × 86,400 × 1.3
│ ├── = 56 GB/day
│ ├── Hot 90 days = 5 TB
│ └── + Warm/Cold ตาม retention
│
├── RAM (Elasticsearch/OpenSearch):
│ ├── JVM Heap = 50% ของ RAM (max 32 GB per node)
│ ├── ที่เหลือ = OS cache
│ ├── Rule of thumb: 1 GB heap per 20 GB hot data
│ └── ตัวอย่าง: 5 TB hot → ≥ 250 GB total heap → 8+ nodes
│
├── CPU:
│ ├── Indexing: 1 core per 5,000 EPS
│ ├── Search: 2-4 cores per concurrent search
│ └── Correlation: 2-4 cores สำหรับ rule engine
│
└── Network:
├── Log ingestion: 1 Mbps per 1,000 EPS (avg)
├── Cluster replication: 10 Gbps between indexer nodes
└── Agent → Manager: ขึ้นกับจำนวน agentsส่วนที่ 15: SIEM Best Practices — คำแนะนำจากผู้เชี่ยวชาญ
15.1 Best Practices สำหรับ SIEM Deployment
SIEM Best Practices:
Phase 1: Planning (สัปดาห์ 1-2):
├── กำหนด scope: ต้องการ monitor อะไร?
├── ระบุ log sources ทั้งหมด
├── กำหนด use cases (เริ่มจาก top 10)
├── กำหนด retention requirements
├── เลือก platform (ตาม budget + skill)
├── Sizing calculation
├── ออกแบบ architecture
└── เตรียม team (training)
Phase 2: Deployment (สัปดาห์ 2-4):
├── ติดตั้ง SIEM infrastructure
├── เชื่อมต่อ log sources (เริ่มจากสำคัญที่สุด)
│ ├── Priority 1: Firewall, AD, VPN
│ ├── Priority 2: Servers, DNS, Proxy
│ ├── Priority 3: Endpoints, Cloud
│ └── Priority 4: Applications, Database
├── ตรวจสอบว่า log เข้า SIEM ครบ
├── ตั้ง NTP synchronization ทุก source
└── Test basic alerting
Phase 3: Tuning (สัปดาห์ 4-12):
├── Enable default rules
├── Observe alert volume (ยังไม่ notify)
├── สร้าง whitelist
├── ปรับ threshold
├── เขียน custom rules
├── สร้าง dashboards สำหรับแต่ละ role
├── ตั้ง notification channels
└── เริ่ม alert notification
Phase 4: Operations (ต่อเนื่อง):
├── Daily monitoring
├── Weekly rule review
├── Monthly metrics review
├── Quarterly rule tuning
├── Annual architecture review
├── Continuous improvement
├── Threat intelligence updates
└── Team training
Common Mistakes to Avoid:
├── ✗ เก็บ log ทุกอย่าง → volume เกิน, cost สูง
│ └── ✓ เก็บเฉพาะ security-relevant logs
├── ✗ Alert ทุก rule ตั้งแต่วันแรก → alert fatigue
│ └── ✓ เริ่มจาก critical rules, tune ก่อน alert
├── ✗ ไม่ tune SIEM → false positive ท่วม
│ └── ✓ Tune สม่ำเสมอ, whitelist legitimate activities
├── ✗ ไม่มี team ดูแล → SIEM กลายเป็น expensive log storage
│ └── ✓ ต้องมี dedicated analyst อย่างน้อย part-time
├── ✗ ไม่ test correlation rules → ไม่มั่นใจว่าทำงาน
│ └── ✓ สร้าง test cases สำหรับทุก rule
├── ✗ ไม่ monitor SIEM health → log หาย ไม่รู้ตัว
│ └── ✓ Monitor agent status, log flow, disk usage
├── ✗ ไม่ document → คนเดิมลาออก ไม่มีใครดูแลได้
│ └── ✓ Document architecture, rules, playbooks, procedures
└── ✗ ไม่ sync NTP → log timestamp ไม่ตรง → correlation ผิด
└── ✓ ทุกอุปกรณ์ต้อง sync NTP กับ server เดียวกันส่วนที่ 16: SIEM สำหรับ Cloud — Cloud SIEM
16.1 Cloud-Native SIEM
เมื่อองค์กรย้ายไป cloud มากขึ้น SIEM ก็ต้องปรับตัว — Cloud SIEM ช่วยให้ไม่ต้อง manage infrastructure:
Cloud SIEM Considerations:
Advantages of Cloud SIEM:
├── ไม่ต้อง manage infrastructure (hardware, OS, updates)
├── Scale ได้อัตโนมัติ (ไม่ต้อง plan capacity)
├── Pay-as-you-go (ไม่ต้องลงทุนล่วงหน้า)
├── Built-in HA/DR (redundancy included)
├── Faster deployment (วัน vs สัปดาห์)
├── Native cloud integration (easy connect cloud logs)
└── Continuous updates (new features, rules, parsers)
Challenges of Cloud SIEM:
├── Cost unpredictable (ขึ้นกับ data volume)
├── Data sovereignty (ข้อมูลอยู่ที่ไหน?)
├── Bandwidth cost (ส่ง log ขึ้น cloud)
├── Vendor lock-in (ย้ายยาก)
├── Customization จำกัด (เทียบกับ self-hosted)
└── On-prem log sources ต้อง forwarder
Cloud SIEM Options:
├── Microsoft Sentinel:
│ ├── Azure-native, ดีสุดสำหรับ Microsoft ecosystem
│ ├── KQL query language
│ ├── Built-in SOAR (Logic Apps)
│ └── Data connector: 200+ integrations
│
├── Google Chronicle:
│ ├── Google-scale search (UD engine)
│ ├── Fixed pricing (ไม่คิดตาม volume)
│ ├── 12 months hot retention
│ └── VirusTotal integration
│
├── Splunk Cloud:
│ ├── Splunk Enterprise ในรูปแบบ SaaS
│ ├── SPL query language
│ ├── Largest ecosystem
│ └── ราคาสูง
│
├── Elastic Cloud:
│ ├── ELK Stack as a Service
│ ├── Flexible sizing
│ ├── Multi-cloud (AWS, Azure, GCP)
│ └── Free tier available
│
├── Wazuh Cloud:
│ ├── Managed Wazuh service
│ ├── เริ่ม $420/month
│ ├── ง่ายสำหรับ SMB
│ └── All features included
│
└── Sumo Logic:
├── Cloud-native analytics
├── Real-time alerting
├── Machine learning
└── DevSecOps focus
Hybrid Architecture (On-Prem + Cloud):
┌─────────────────────┐ ┌─────────────────┐
│ On-Prem Network │ │ Cloud SIEM │
│ ┌───────────────┐ │ │ ┌───────────┐ │
│ │ Log Forwarder │──┼──→ │ │ Ingestion │ │
│ │ (Syslog/Agent)│ │ │ │ Layer │ │
│ └───────────────┘ │ │ └───────────┘ │
│ ┌───────────────┐ │ │ ┌───────────┐ │
│ │ Firewall │ │ │ │ Analysis │ │
│ │ Servers │ │ │ │ Alerting │ │
│ │ Endpoints │ │ │ │ Dashboard │ │
│ └───────────────┘ │ │ └───────────┘ │
└─────────────────────┘ └─────────────────┘
สำหรับ Hybrid:
├── On-prem forwarder เก็บ buffer (กรณี internet ขัดข้อง)
├── Compress log ก่อนส่ง (ลด bandwidth cost)
├── Encrypt transit (TLS)
├── Pre-filter log ที่ไม่จำเป็น (ลด cost)
└── สำรอง log on-prem ด้วย (ไม่พึ่ง cloud 100%)สรุป: SIEM Implementation Checklist
SIEM เป็น หัวใจของ security operations สมัยใหม่ — ไม่ว่าองค์กรจะเล็กหรือใหญ่ การมีระบบรวบรวมและวิเคราะห์ log อย่างเป็นระบบคือสิ่งจำเป็น ไม่ใช่ทางเลือก ด้วยเครื่องมือ open-source อย่าง Wazuh ทำให้แม้แต่องค์กรขนาดเล็กก็สามารถเริ่มต้น SIEM ได้โดยไม่ต้องลงทุนค่า license
SIEM Implementation Checklist:
เริ่มต้น SIEM ให้ตอบคำถามเหล่านี้:
1. Planning:
├── ☐ ระบุ log sources ทั้งหมดในองค์กร
├── ☐ กำหนด top 10 use cases ที่ต้องการ detect
├── ☐ กำหนด compliance requirements (PCI, ISO, PDPA)
├── ☐ คำนวณ log volume (GB/day)
├── ☐ เลือก platform (budget + skill)
└── ☐ Sizing infrastructure
2. Deployment:
├── ☐ ติดตั้ง SIEM (server/cloud)
├── ☐ เชื่อมต่อ log sources ตาม priority
├── ☐ ติดตั้ง agents บน endpoints
├── ☐ ตรวจสอบ log flow ครบถ้วน
├── ☐ ตั้ง NTP sync ทุก source
└── ☐ Test basic search and alerting
3. Configuration:
├── ☐ Enable relevant default rules
├── ☐ สร้าง custom rules ตาม use cases
├── ☐ ตั้ง notification channels (email, LINE, Slack)
├── ☐ สร้าง dashboards
├── ☐ กำหนด retention policy
├── ☐ Integrate threat intelligence
└── ☐ ตั้ง active response (auto-block)
4. Tuning:
├── ☐ Baseline normal behavior (2-4 สัปดาห์)
├── ☐ Whitelist legitimate activities
├── ☐ Adjust thresholds
├── ☐ ลด false positives ให้ < 20%
└── ☐ Document ทุก tuning decision
5. Operations:
├── ☐ กำหนด SOC process (triage, escalation)
├── ☐ สร้าง playbooks/runbooks
├── ☐ กำหนด KPIs (MTTD, MTTR)
├── ☐ ฝึก team ให้ใช้ SIEM
├── ☐ Review metrics ทุกเดือน
└── ☐ Continuous improvement
คำแนะนำสุดท้าย:
├── เริ่มเล็ก, scale ทีหลัง (อย่า boil the ocean)
├── Focus use cases ที่สำคัญที่สุดก่อน
├── SIEM ไม่ใช่ set-and-forget — ต้อง tune ตลอด
├── People + Process สำคัญกว่า Technology
├── ถ้า budget จำกัด → Wazuh + ทีม 1-2 คน ก็เริ่มได้
├── ถ้าไม่มี team → พิจารณา MSSP (Managed SOC)
├── Log ที่ไม่มีคนดู = ไม่มีประโยชน์
└── เริ่มวันนี้ ดีกว่ารอจน perfectการมี SIEM ไม่ได้หมายความว่าองค์กรจะปลอดภัย 100% แต่มันคือ ดวงตาและหูของ security team — เมื่อเกิดเหตุ คุณจะมีข้อมูลที่ต้องการในการตรวจสอบ ตอบสนอง และป้องกันไม่ให้เกิดซ้ำ SIEM ที่ดีไม่ใช่ที่แพงที่สุด แต่เป็นที่ถูก deploy, tune และ operate อย่างถูกต้อง
