Tier 1 — Triage analyst — ยามชั้นนอก#

Tier 1 = นักวิเคราะห์ alert ที่อยู่ ชั้นนอกสุด — เป็นคนแรกที่เห็น alert ใหม่ที่เข้ามาในระบบ

หน้าที่หลักของ Tier 1 ครับ —

• Monitor หน้าจอ alert dashboard ที่ระบบ SIEM ป้อนเข้ามา
• Triage — คือคัดกรองว่า alert ตัวไหน น่าจะจริง vs ตัวไหน false positive ปกติ
• Acknowledge alert ที่ confirm แล้วว่าเป็นปกติ — ปิด ticket
• Escalate alert ที่น่าสงสัยขึ้นไปให้ Tier 2

ลองนึก — Tier 1 = ยามชั้นนอกของเมือง — ใครเดินผ่านป้อมยาม ก็ดูบัตรก่อน. คนที่บัตรปกติ — pass. คนที่บัตรหน้าตาแปลกๆ — เรียกตำรวจระดับสูงมาดู

คุณสมบัติ Tier 1 ในวงการไทย — โดยทั่วไปคือ junior security analyst — มี CompTIA Security+ หรือเทียบเท่า — เงินเดือนเริ่มต้น 30,000-50,000 บาท. ทำงาน shift + ดู alert วันละหลายร้อยตัว. งานซ้ำซาก + มี burnout สูง — turnover rate ของ Tier 1 ทั่วโลกอยู่ที่ 25-30% ต่อปี

Tier 2 — Investigator — นักสืบของ SOC#

Tier 2 = นักสืบสวน — รับ alert ที่ Tier 1 escalate ขึ้นมา + ขุดต่อ เพื่อหาว่าเกิดอะไรขึ้นจริงๆ

หน้าที่ —

• Investigate alert ที่ Tier 1 escalate — ดู context รอบ alert ลึกขึ้น
• Correlate — โยง alert หลายตัวที่เกิดในช่วงเวลาเดียวกันเข้าด้วยกัน
• Hypothesis — ตั้งสมมติฐานว่าเกิดอะไร (phishing? malware? insider?)
• Confirm / Dismiss — ยืนยันว่าเป็น incident จริง หรือไม่
• Initial containment — ถ้า confirm = incident — เริ่ม ตัดเครื่อง / ปิด account / block IP ก่อน escalate ไป Tier 3

Tier 2 ใช้เครื่องมือลึกกว่า Tier 1 — เข้า EDR console ดู process tree, query SIEM log แบบ custom, อ่าน raw packet capture. คนที่อยู่ Tier 2 ส่วนใหญ่มีประสบการณ์ 3-5 ปี + cert ระดับ GCIH / CySA+ / CEH — เงินเดือนระดับ 70,000-120,000 บาท

Tier 3 — Threat hunter + intel — มือเก๋าของวงการ#

Tier 3 = ระดับสูงสุดของ SOC — ทำ proactive hunt + threat intelligence + advanced incident response

หน้าที่ —

• Threat hunting — ไม่รอ alert. ตั้งสมมติฐานเอง + ค้นหาในระบบว่ามี indicator ของ attack ที่ระบบไม่จับไหม (จะคุยลึกใน EP.44)
• Threat intelligence — ติดตาม IOC (Indicator of Compromise) จาก threat feed + report ของ Mandiant / CrowdStrike / Microsoft / Recorded Future
• Advanced incident response — เคสใหญ่ที่ Tier 2 รับไม่ไหว — Tier 3 ลงมือเอง
• Tuning — ปรับ rule ของ SIEM + EDR ให้ลด false positive
• Knowledge transfer — สอน Tier 1 / Tier 2 + เขียน playbook

Tier 3 = ตำรวจระดับ chief detective ของเมือง — ไม่นั่งดูจอตลอดเวลา แต่ลงมือเมื่อเคสซับซ้อน. คนที่อยู่ Tier 3 มีประสบการณ์ 7-10+ ปี + cert ระดับ GCFA / GCTI / OSCP — เงินเดือนระดับ 150,000-300,000+ บาท ในไทย

In-house SOC vs Outsourced (MSSP)#

คำถามที่ผู้บริหารต้องตอบ — บริษัทควรสร้าง SOC ของตัวเอง หรือจ้าง MSSP?

In-house SOC — สร้างทีมเอง

• ข้อดี — ทีมรู้จัก business context ของบริษัทดี / response เร็ว / data ไม่ออกจากบริษัท
• ข้อเสีย — ค่าใช้จ่ายสูงมาก (analyst 3 กะ 24/7 ขั้นต่ำ = 12-15 คน + ค่า tool + ค่า training) / หา talent ยาก / burnout สูง
• ต้นทุนปีแรกของบริษัทไทยขนาดกลาง — 15-30 ล้านบาท

Outsourced SOC (MSSP — Managed Security Service Provider) — จ้างบริษัทภายนอกดูแล

• ข้อดี — เริ่มเร็ว / ลงทุนน้อยกว่า / MSSP เห็น attack pattern จากลูกค้าหลายร้อยบริษัท (cross-customer intelligence)
• ข้อเสีย — MSSP ไม่รู้ business ของบริษัทคุณดีเท่า in-house / response อาจช้า / มี vendor lock-in
• ต้นทุน — บริษัทขนาดกลางใน MSSP ไทย ราคา 200,000-2,000,000 บาท/เดือน ขึ้นกับ scope

ในวงการมี model ที่บริษัทไทยใช้กันบ่อย — Hybrid — มี Tier 1 / Tier 2 outsource ที่ MSSP + เก็บ Tier 3 + Incident Manager ใน in-house. ได้ความครอบคลุม 24/7 + เก็บ control ที่ระดับสูงไว้

มุมผู้บริหาร: การตัดสินใจ in-house vs MSSP — บริษัทไทยที่มี IT staff < 50 คน หรือไม่ใช่ critical infrastructure — เริ่มจาก MSSP ก่อน ROI ดีกว่า 2-3 ปีแรก. ห้ามผู้บริหารตัดสินใจ SOC จาก price ของ tool อย่างเดียว — ต้นทุน 70% ของ SOC คือคน ไม่ใช่ tool. คำถามที่ผู้บริหารต้องถาม vendor MSSP — “analyst per customer ratio เป็นเท่าไหร่?” ถ้าตอบไม่ได้ = ไม่ใช่ vendor ที่ดี

SOC 9 Activities — สิ่งที่ทีม SOC ทำจริง#

เห็นโครงสร้าง 3 ชั้นของ SOC แล้ว แต่ในแต่ละวัน ทีม SOC ทำอะไรบ้าง ที่เป็นกิจกรรมจริง? วงการแบ่งหน้าที่ของ SOC ออกเป็น 9 activity ที่ ISACA และ NIST ใช้เป็น checklist ของ SOC ที่ครบถ้วน ลองนึกครับ ถ้า SOC คือโรงพยาบาล Tier 1/2/3 คือพยาบาล/หมอ/ศัลยแพทย์ แต่ 9 activity คือ หน้าที่ของโรงพยาบาลในแต่ละวัน ตั้งแต่รับคนไข้ ทำ chart ตรวจร่างกาย ผ่าตัด ตามผล จนถึงรายงาน

ที่ผู้บริหารต้องสังเกตคือ SOC ของบริษัทไทยส่วนใหญ่ทำได้แค่ activity 3 (real-time monitoring) + 4 (incident response) เท่านั้น ที่เหลือมักไม่มีเจ้าภาพชัดเจน Asset management มักตกเป็นของทีม IT ops Security testing มักจ้าง vendor ทำปีละครั้ง Compliance monitoring มักโยนให้ทีม internal audit ผลคือเมื่อเกิด incident SOC ไม่รู้ว่า asset ที่โดนสำคัญแค่ไหน (ขาด 1) ไม่รู้ว่า attacker ใช้ technique อะไรใหม่ (ขาด 2) patch ที่ควรปิดช่องไปแล้วยังไม่ deploy (ขาด 7) บทเรียนคือ SOC ที่ทำครบ 9 activity คือ SOC ที่จับ incident ได้ก่อนเกิดความเสียหายจริง

SIM vs SEM — ประวัติของ SIEM ที่ ISACA ยังออกข้อสอบ#

ก่อนจะเข้า SIEM ขอเล่าประวัติสั้นๆ ที่ออกข้อสอบบ่อย ก่อนปี 2005 วงการไม่มี “SIEM” คำเดียว มี 2 ของแยกกัน คือ

• SIM (Security Information Management) — ระบบเก็บ log ระยะยาวเพื่อ compliance reporting + historical analytics เป็น “ห้องเก็บเอกสารย้อนหลัง” ของบริษัท เปิดดูเมื่อ auditor ขอ
• SEM (Security Event Management) — ระบบ correlate event แบบ real-time + alerting เป็น “ห้องควบคุมที่ดูเหตุการณ์ตอนนี้” operational

ปี 2005 Gartner เป็นเจ้าแรกที่บัญญัติคำว่า SIEM = SIM + SEM เพราะวงการเริ่มเห็นว่าการแยก 2 ระบบทำให้ analyst ต้อง switch หน้าจอและข้อมูลซ้ำซ้อน หลังจากนั้น vendor ส่วนใหญ่ผสมรวมเป็น product เดียว

ปัจจุบัน vendor แทบไม่ได้แยก SIM กับ SEM เป็น product แล้ว แต่ ISACA exam ยังออกความต่างของ 2 concept เพราะมันคือรากของ SIEM ถ้าใครถามว่า “SIEM ต่างกับ SIM ยังไง?” คำตอบคือ SIEM = SIM + SEM SIM ดู past, SEM ดู present, SIEM ดูทั้งคู่

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

1. Collect log จากระบบทุกตัวในบริษัท
2. Normalize — แปลง log format ที่ต่างกันให้เป็น format เดียวกัน
3. Store — เก็บใน database ที่ค้นหาได้เร็ว (มักเก็บ 90 วัน — 7 ปีตามข้อกำหนด)
4. Correlate — เชื่อมโยง event หลายตัวด้วย rule ที่ตั้งไว้
5. Alert — ส่งเตือนเมื่อ pattern เข้ากับ rule

ลองนึก — ในเมืองของเรา. มี กล้อง หน้าธนาคาร / เซ็นเซอร์ ที่ประตูตึก / บันทึก ใครเข้าออก parking / ข้อมูล การจ่ายไฟ / log การโทร / GPS ของรถตำรวจ — แต่ละระบบเก็บข้อมูลแยกกัน. SIEM = ห้องที่รวม footage ของทุกระบบ เข้ามาดูบนจอใหญ่ + ระบบที่บอกได้ว่า “อ้าว — เมื่อ 5 นาทีที่แล้ว มีคนเข้าตึก A พร้อมกับมีไฟฟ้าผิดปกติที่ตึก B พร้อมกับมี GPS ของรถปลอมในซอย — น่าจะมีเรื่อง”

ของจริงในวงการ — SIEM รับ log จาก:

บริษัทขนาดกลางในไทย — โดยทั่วไป SIEM รับ log ที่ระดับ 5-20 GB ต่อวัน. บริษัทใหญ่ระดับธนาคาร — 500 GB - 5 TB ต่อวัน. บริษัท global enterprise (Microsoft / Google / JPMorgan) — หลายร้อย TB ต่อวัน

Correlation rule — กฎเชื่อมโยง event#

หัวใจของ SIEM คือ correlation rule — กฎที่เขียนไว้บอกระบบว่า “เมื่อเห็น event A + B + C ในเวลาใกล้กัน — ส่ง alert”

ตัวอย่าง rule คลาสสิคของวงการ —

Rule 1 — Brute force attempt: “ถ้ามี failed login มากกว่า 10 ครั้งใน 5 นาที จาก source IP เดียวกัน → alert Brute Force”

Rule 2 — Impossible travel: “ถ้า user คนเดียวกัน login จาก ประเทศไทย เวลา 14:00 + login จาก รัสเซีย เวลา 14:15 → alert Impossible Travel (เพราะบินจากไทยไปรัสเซียใน 15 นาทีเป็นไปไม่ได้)”

Rule 3 — Data exfiltration: “ถ้า user upload file ออกนอกบริษัทเกิน 500 MB ในชั่วโมงเดียว + ไม่เคยทำมาก่อน → alert Possible Data Exfil”

Rule 4 — Lateral movement: “ถ้ามี failed SMB authentication จากเครื่อง A ไปเครื่อง B + เครื่อง B + เครื่อง C ในเวลา 30 นาที → alert Possible Lateral Movement”

rule เหล่านี้ — ใน SIEM ใหม่ๆ (2023+) เริ่มเป็น machine learning + behavior analytics แทน static rule (จะคุยใน UEBA)

SIEM vendors — 2 ตัวหลัก + 1 ระดับภูมิภาค#

ตลาด SIEM ปี 2025 มีผู้เล่นหลักที่ผู้บริหารต้องรู้ —

• Splunk — เก่าแก่ที่สุด + market share สูงสุด (Cisco ซื้อปี 2024 ด้วย $28B). flexible แต่แพง — enterprise ที่มี legacy ใช้เป็นมาตรฐาน
• Microsoft Sentinel — cloud-native SIEM บน Azure. ราคา pay-per-GB. บริษัทที่ใช้ Microsoft 365 อยู่แล้ว — integrate ง่าย + ราคาสมเหตุสมผล — เติบโตเร็วที่สุดในไทยปี 2025-2026
• IBM QRadar — แข็งใน financial sector ของไทยและภูมิภาค (regional fit)

และตัวอื่นๆ (Elastic Security, Sumo Logic, LogRhythm, Securonix) ก็มีในตลาด — เลือกตาม ecosystem ที่บริษัทใช้อยู่

มุมผู้บริหาร: pattern ของวงการที่ผิดบ่อยที่สุดในการเลือก SIEM — เลือก vendor ก่อนคิด use case. SIEM ที่ “ดีที่สุด” ไม่มี — มีแต่ SIEM ที่เหมาะกับ environment ของคุณ. คำถามที่ผู้บริหารต้องถาม vendor — “ราคา 3 ปี รวม license + storage + tuning + custom rule development เท่าไหร่?” ไม่ใช่ราคา license ปีแรก. TCO ของ SIEM 3 ปี = 3-5 เท่าของราคา license ปีแรก

SIEM Topology — Agent vs Agentless#

วิธีที่ SIEM ดึง log จาก source แบ่งเป็น 2 topology หลัก คือ agent-based กับ agentless ลองนึกครับ agent-based คือ “ฝัง CCTV ในตึก” ติดตั้งอุปกรณ์ในตึกเลย ส่วน agentless คือ “ส่องกล้องจากนอกตึก” ไม่ต้องเข้าไปติดตั้ง

Agent-based — ติดตั้ง agent (โปรแกรม) บน host (server / endpoint) → agent forward log + state ผ่าน secure channel ไปที่ SIEM collector

• ข้อดี — context รวย (เห็น file / process / user activity ลึก) / encrypted transport / มี queue support เมื่อ network ขาด
• ข้อเสีย — มี install overhead / กิน CPU + memory ของ host / ต้องดูเรื่อง OS compatibility
• ตัวอย่าง — Splunk Universal Forwarder, Elastic Beats, Wazuh agent

Agentless — ดึง log จาก source ผ่าน protocol ที่มีอยู่แล้ว (SNMP / SSH / WMI / Syslog) — ไม่ต้องติดตั้งอะไรบน host

• ข้อดี — zero install / deploy ง่าย + เร็ว / ไม่กระทบ host
• ข้อเสีย — context น้อยกว่า / ต้องจัดการ credential ซับซ้อน (ต้องเก็บ password ของหลายระบบ) / fidelity ต่ำกว่า
• ตัวอย่าง — Syslog server, Windows Event Forwarding (WEF), API pull จาก cloud

ของจริงในวงการ — บริษัทขนาดกลางส่วนใหญ่ใช้ hybrid — agent บน critical asset (domain controller, database server, EDR endpoint) + agentless บน network device (router, switch, firewall) ที่ไม่สามารถติดตั้ง agent ได้

SIEM 8 Benefits — ทำไมบริษัทถึงลงทุน#

มาดู benefit 8 ตัว ที่ SIEM ที่ tune ดีให้บริษัท — ที่ ISACA ใช้เป็น checklist ของ value proposition

1. Real-time threat detection — correlate event จากหลาย source เพื่อจับ attack pattern ที่ source เดียวมองไม่เห็น
2. Compliance reporting — รายงานพร้อมใช้สำหรับ PCI DSS, ISO 27001, SOC 2, HIPAA
3. Forensic investigation — สร้าง timeline ของ incident + หา root cause ย้อนหลัง
4. Audit log centralization — single source of truth สำหรับ log ของทั้งบริษัท
5. Performance optimization — automate งานซ้ำๆ + จัดลำดับ alert ตาม priority
6. Past insight — วิเคราะห์ trend ระยะยาว (3 เดือน / 1 ปี ย้อนหลัง)
7. Reduced auditing burden — auto-generate audit report ที่ก่อนหน้าต้องนั่งทำเอง
8. Threat intelligence enrichment — match IoC จาก threat feed กับ event ที่เกิดในระบบ

SIEM 7 Features — ความสามารถหลัก#

ฝั่ง feature ที่ SIEM ทุกตัวต้องมี — มี 7 ตัว ที่ผู้บริหารควรรู้เพื่อเข้าใจว่ากำลังจ่ายเงินซื้ออะไร

1. Aggregation — รวบรวม log จาก source หลายตัว (network / host / application / cloud) มาที่จุดเดียว
2. Normalization — แปลง log format ที่ต่างกันให้เป็น schema เดียว (CEF, LEEF, ECS)
3. Correlation — โยง event จากหลาย source เพื่อจับ pattern ของ attack
4. Threat intelligence integration — match IoC กับ event ปัจจุบัน
5. Alert prioritization — จัดลำดับ alert ตาม severity + ความสำคัญของ asset + บริบท
6. Forensic analysis — pivot, drill-down, สร้าง timeline ย้อนหลัง
7. Compliance dashboard — report สำเร็จรูปสำหรับมาตรฐานที่ใช้บ่อย

SIEM 10 Implementation Best Practices#

ของจริงในวงการ — บริษัทไทยจำนวนมากซื้อ SIEM แล้วใช้ไม่คุ้ม เพราะข้าม best practice ที่ ISACA และ NIST แนะนำ. 10 ข้อต่อไปนี้ คือ checklist ที่ผู้บริหารควรถามทีม IT ก่อนเริ่มและทุก quarter หลังจากนั้น

1. กำหนด use case ก่อน — อย่าซื้อแล้วค่อยคิดว่าจะใช้ทำอะไร. ระบุก่อนเลยว่าจะจับ scenario อะไร (brute force? data exfil? lateral movement?)
2. เริ่มจาก critical asset — top-down — เริ่มที่ domain controller, financial database, payment gateway ก่อน laptop พนักงาน
3. Tune for false positive — ปรับ rule อย่างต่อเนื่อง — ไม่ใช่ deploy แล้วทิ้ง
4. Standardize log format — บังคับ source ให้ส่ง log ใน schema มาตรฐาน (CEF / ECS) — ลดงาน normalization
5. Integrate กับ ticketing — เชื่อม SIEM กับ ServiceNow / JIRA / PagerDuty เพื่อ track work ของ analyst
6. เขียน runbook ต่อ alert type — analyst ต้องมีคู่มือว่า alert แต่ละแบบทำอะไรต่อ — ไม่ใช่คิดเอง
7. สร้าง baseline ก่อนเปิด alert — เก็บ log ดู behavior ปกติ 30 วันก่อนเปิด rule — ไม่งั้น false positive ท่วม
8. วางแผน storage capacity — trade-off ระหว่าง retention period กับ cost. compliance ต้องการ 1-7 ปี — เก็บที่ไหน ราคาเท่าไหร่
9. มองว่า SIEM เป็น compliance artifact เอง — audit trail ของ SIEM เอง (ใครแก้ rule? ใครลบ log?) ต้องเก็บไว้ตรวจได้
10. Review detection coverage ประจำ — map กับ MITRE ATT&CK matrix ทุก quarter — จุดไหนของ kill chain ยังไม่มี detection

EDR — Endpoint Detection and Response#

EDR = Endpoint Detection and Response (ระบบตรวจจับและตอบสนองบน endpoint) — agent ที่ติดตั้งบน ทุก endpoint + ทำหน้าที่

1. Monitor — บันทึก process / file / network / registry activity แบบ real-time
2. Detect — ใช้ behavior analytics + signature + ML detect malicious activity
3. Respond — สั่ง action ได้ตรงที่ endpoint — kill process / quarantine file / isolate machine จาก network

ลองนึก — EDR = กล้อง CCTV ที่ติดตั้งในทุกตึกของเมือง — เห็นทุกอย่างที่เกิดในตึก. ใครเปิดประตู / ใครเดินไปไหน / ใครหยิบของอะไร. ระบบเก่ายุค antivirus (AV) คือแค่ “ตรวจของที่เข้าตึก” — แต่ถ้าโจรเข้าได้แล้ว AV ไม่เห็นต่อ. EDR เห็นทุกการเคลื่อนไหวหลังเข้ามา

EDR ที่ดีจับ pattern ต่างๆ ได้แม้ไม่มี signature ของ malware — เช่น

• PowerShell ที่ encode + download script จาก internet → fileless malware pattern
• Office Word/Excel ที่ spawn cmd.exe → macro malware pattern
• lsass.exe ที่ถูก process แปลกๆ อ่าน memory → credential dumping (Mimikatz pattern)
• Suspicious DLL injection เข้า trusted process

XDR — Extended Detection and Response#

XDR = Extended Detection and Response — รุ่นใหม่ของ EDR ที่ ขยายขอบเขตออกไปนอก endpoint — รวมถึง email / network / cloud / identity ทั้งหมด

ความต่างของ EDR vs XDR — ลองนึก:

• EDR = กล้องในแต่ละตึกแยกกัน. analyst ต้อง switch ดูแต่ละกล้องแยก
• XDR = ห้องควบคุมรวม ที่ดูทุกกล้อง + ทุก sensor (network / email / cloud / identity) ใน timeline เดียว — เห็นภาพรวมของ attack ที่ครอบหลายระบบ

ลองนึก scenario — โจรส่ง phishing email → user คลิก → malware รันบน laptop → connect ออก internet → ขโมย credential → login เข้า cloud storage → ดูดข้อมูล

• EDR เพียวๆ = เห็นแค่ malware รันบน laptop. ไม่รู้ว่าเริ่มจาก email + ไม่รู้ว่าจบที่ cloud
• XDR = เห็น timeline ทั้ง chain — email → endpoint → network → cloud — รวมในจอเดียว

นี่ทำให้ XDR เหมาะกับวงการปี 2024-2026 ที่ attack chain ครอบหลาย domain

EDR/XDR vendors — 3 ตัวหลักที่บริษัทไทยใช้#

ตลาด EDR/XDR ปี 2025 — มี 3 ตัวที่บริษัทใหญ่ในไทยใช้กันมากที่สุด —

• CrowdStrike Falcon — leader ใน Gartner Magic Quadrant. cloud-native + ML-driven. ราคา premium. ใช้ในบริษัทใหญ่ + financial. (มีเคส July 2024 ที่ update ผิดทำให้ Windows ล่มทั่วโลก — บทเรียนของวงการ)
• Microsoft Defender for Endpoint — มาพร้อม Microsoft 365 E5 license. ราคาดีสำหรับบริษัทที่ Microsoft-centric. คุณภาพดีในระดับเทียบกับ leader ได้
• Sophos Intercept X — แข็งในกลุ่ม mid-market + Asia

และตัวอื่นๆ (SentinelOne, Trend Micro, Symantec, McAfee/Trellix) ก็มีในตลาด — เลือกตาม budget tier และ ecosystem ที่บริษัทใช้อยู่

มุมผู้บริหาร: EDR / XDR คือ investment ที่ ROI สูงที่สุดในวงการ detection. บริษัทไทยที่ยังใช้ traditional antivirus (Norton / Kaspersky รุ่นเก่า) แล้วโดน ransomware = เสียหาย 10-100 ล้าน. คำถามที่ต้องถาม — “EDR ของเราเป็น signature-based แบบเก่าหรือ behavior-based แบบใหม่?” ของเก่าจับ malware ที่ยังไม่มี signature ไม่ได้. บทเรียนจากเคส CrowdStrike July 2024 — EDR ทุกตัวต้องมี staged rollout อย่าให้ vendor push update ทั่วทั้งบริษัทพร้อมกัน

Playbook ของ SOAR — ตัวอย่างจริง#

ลองดู playbook คลาสสิคของวงการครับ —

Playbook 1 — Phishing email reported by user:

1. User report email ใน “Report Phishing” button ของ Outlook
2. SOAR รับ trigger → ดึง email + attachment + URL
3. ส่ง URL ไปตรวจที่ VirusTotal + URLScan + PhishTank
4. ส่ง attachment ไปตรวจที่ sandbox (Joe Sandbox / Any.run)
5. ถ้าทุกตัวบอกว่าปลอดภัย → ปิด ticket + ตอบ user “ขอบคุณที่รายงาน — email นี้ปลอดภัย”
6. ถ้าตัวใดตัวหนึ่งบอกว่า malicious → block sender domain + block URL + search SIEM ว่าใครคลิกแล้วบ้าง + isolate endpoint ของคนที่คลิก + create high-priority ticket + ส่ง alert ให้ Tier 2

ขั้นตอน 1-5 = ไม่ต้องมี analyst — แม่บ้าน auto ทำเองทั้งหมดใน 1-2 นาที. ก่อนมี SOAR — Tier 1 ใช้เวลา 15-30 นาทีต่อ phishing report. หลังมี SOAR — analyst แตะเฉพาะเคสที่เข้าข่าย step 6

Playbook 2 — Brute force from external IP:

1. SIEM ส่ง alert “Brute Force” (failed login 50 ครั้งใน 5 นาที)
2. SOAR ดึง source IP
3. Check IP กับ threat intel feed → ถ้าเจอใน blacklist = block ที่ firewall ทันที + ปิด ticket
4. ถ้าไม่เจอใน blacklist → check geolocation → ถ้ามาจากประเทศที่บริษัทไม่ทำธุรกิจ → block + create medium ticket
5. ถ้าจาก geo ปกติ → escalate ไป Tier 1 (อาจเป็น user ลืม password)

Playbook 3 — Compromised credential:

1. Threat intel feed แจ้งว่า credential ของ user X อยู่ใน data leak ใหม่
2. SOAR ดึง user X จาก AD
3. Force password reset + revoke all active session + enable additional MFA factor
4. ส่ง email + SMS ให้ user X เรื่อง incident
5. Create ticket + log incident

SOAR 6 Benefits — ทำไม SOC ที่โต ต้องมี SOAR#

ก่อนคุย vendor — มาดู 6 benefit หลัก ของ SOAR ที่ ISACA จัดเป็น value proposition ของวงการ

1. Visibility — dashboard กลางที่เห็น operation ของทุกเครื่องมือ security ในจอเดียว
2. Cost reduction — automate Tier 1 triage ปลดล็อกเวลาของ analyst ไปทำงานที่ใช้สมอง
3. Advocacy / Standardization — playbook บังคับให้ทุกคนตอบ alert แบบเดียวกัน — ไม่ขึ้นกับว่าใครเข้าเวร
4. Flexibility — ปรับ playbook ตาม threat ใหม่ได้ผ่าน editor — ไม่ต้องเขียน code ใหม่
5. Collaboration — เชื่อม workflow + ticket ระหว่างทีม security, IT ops, network ได้ในที่เดียว
6. Operations efficiency — ลด MTTR + ลด error จาก manual step ที่ทำซ้ำๆ

SOAR vendors — 2 ตัวหลัก#

ตลาด SOAR ปี 2025 —

• Palo Alto Cortex XSOAR (เดิม Demisto) — leader ตลาด. คลังของ playbook + integration พร้อมใช้สูงสุด
• Tines — รุ่นใหม่ no-code. เติบโตเร็วในตลาด mid-market

และตัวอื่นๆ (Splunk SOAR, IBM Resilient, Microsoft Sentinel built-in, Torq) ก็มีในตลาด — เลือกตาม SIEM ที่ใช้อยู่

มุมผู้บริหาร: SOAR คือ investment ที่ ROI วัดง่ายที่สุดในวงการ — SOAR ที่ tune ดี ลด MTTR จาก 30-60 นาที → 2-5 นาที + ลด analyst workload 40-60%. ข้อควรระวังเดียว — อย่าให้ SOAR ทำ destructive action โดยไม่มี approval ในปีแรก. “auto isolate endpoint” ของ executive ที่ false positive = CEO ทำงานไม่ได้ในช่วง board meeting. เริ่มจากโหมด “recommend action” 3-6 เดือนก่อนเปิด auto execute

Alert fatigue — โรคของ SOC ทั่วโลก#

Alert fatigue (ความล้าจาก alert) = สภาวะที่ analyst เห็น alert มากเกินไปในแต่ละวัน — จนเริ่ม ignore alert ที่ดู “ธรรมดา” — และพลาด alert จริง

ตัวเลขที่วงการรายงานปี 2024 — SOC analyst โดยเฉลี่ยเห็น 5,000-10,000 alert/วัน — แต่จัดการได้จริงไม่ถึง 5%. ที่เหลือ — ปิดโดยไม่ดูลึก / ปล่อยให้ค้าง / ปิดเป็น “false positive” โดยไม่ตรวจ

อาการของ alert fatigue —

• Analyst เริ่ม close alert โดยไม่อ่าน detail
• Auto-dismiss rule ถูกตั้งขึ้นกว้างเกินไป — ปิดทั้งกลุ่ม alert โดยไม่แยก
• Burnout + turnover สูง — analyst ทนไม่ไหว ลาออก
• Important alert ถูกฝังในกองทรายของ false positive — แล้วพลาด

False Positive vs False Negative — สมการของวงการ#

ทุก detection system มี trade-off ระหว่าง 2 ค่า —

False Positive (FP) = ระบบ alert เรื่องที่ ไม่ใช่ภัย = แมวเดินผ่าน sensor แล้วแจ้ง burglar alarm

False Negative (FN) = ระบบ ไม่ alert เรื่องที่ เป็นภัยจริง = โจรเข้ามาแต่ sensor ไม่ดัง

ในวงการมี trade-off เสมอครับ —

• ถ้า tune rule ให้ sensitive มาก → FP สูง → alert fatigue + ปิดทั้งหมดโดยไม่ดู
• ถ้า tune rule ให้ลด FP → อาจ tune ไปแบบ “ปิด rule ที่ noise” → FN สูง → พลาดของจริง

ของจริงในวงการ — บริษัททั่วไป FP rate ของ SIEM ปกติ = 95-99% — แปลว่า alert 100 ตัวมีของจริงแค่ 1-5 ตัว. ปัญหาคือ analyst ต้องตรวจทั้ง 100 ตัวกว่าจะหาเจอ

UEBA — User and Entity Behavior Analytics#

ทางออกของวงการในรอบ 5 ปี — UEBA — context-aware detection ที่ใช้ ML

UEBA = User and Entity Behavior Analytics (การวิเคราะห์พฤติกรรมของผู้ใช้และอุปกรณ์) — ระบบที่

1. Learn behavior ปกติของแต่ละ user + แต่ละ device ผ่านการดู log ระยะเวลา 30-90 วัน
2. Baseline — สร้าง “ภาพปกติ” — user X login กี่โมง / จากที่ไหน / access file ประมาณกี่ MB
3. Detect anomaly — เมื่อ behavior เบี่ยงเบนจาก baseline → alert
4. Score risk — แต่ละ anomaly มี risk score — analyst เห็น alert ที่ rank ตาม score

ลองนึก —

• User HR คนหนึ่ง — ปกติ login จากเครื่อง office จันทร์-ศุกร์ 9:00-18:00 + access แค่ HR file
• วันหนึ่ง — login เวลา 2:00 ตี 2 วันเสาร์ จาก IP ในรัสเซีย + access financial database + download 2 GB
• Static rule อาจไม่จับ (เพราะแต่ละ event เดี่ยวๆ ไม่ violate rule) — แต่ UEBA จับได้ เพราะ behavior เบี่ยงจาก baseline ของ user นี้แบบสุดขั้ว

UEBA built-in ใน SIEM ใหม่ — Microsoft Sentinel มี Fusion + UEBA. Splunk มี User Behavior Analytics. Securonix + Exabeam เป็น vendor ที่ focus UEBA โดยเฉพาะ

UEBA ที่ tune ดี ลด FP rate ลง 40-70% + จับ insider threat + compromised account ได้ดีกว่า static rule

เคส Target 2013 — เครื่องมือดี + คนกับ process แย่ = ตาย#

ปิดด้วยเคสที่เป็นบทเรียนคลาสสิคที่สุดของวงการ detection — Target breach 2013

ในช่วง Black Friday 2013 — ห้าง Target ของอเมริกา (1,800+ สาขา) ถูกขโมย บัตรเครดิตของลูกค้า 40 ล้านใบ + ข้อมูลส่วนตัวอีก 70 ล้านราย. ค่าเสียหายรวม $292 ล้าน. CEO + CIO ลาออกจาก เป็นเคสที่ทำให้ Target ปฏิรูปวงการ security ของ retail ทั้งหมด

ที่น่าสะเทือนใจของเคสนี้ — Target มี SOC + มี FireEye ที่เป็น advanced threat detection tool ระดับ premium ที่ติดตั้งไว้แล้ว — FireEye alert ดัง บอกว่าเจอ malware ที่ผิดปกติในระบบ POS (Point of Sale) 2 ครั้ง — ก่อนที่ข้อมูลจะถูกขโมยออก

แต่ — ทีม SOC ใน Bangalore ที่ Target outsource — ดู alert แล้วไม่ตอบ. Alert ถูก mark เป็น “ไม่ต้องดำเนินการ” — ไม่ escalate ไปอเมริกา — ไม่ปิด POS — ไม่แจ้งใคร

ผลคือ — โจรอยู่ในระบบต่ออีก 2 สัปดาห์ — copy บัตรเครดิตของลูกค้า 40 ล้านใบออกนอกบริษัท. กว่า Target จะรู้ว่าโดน — ไม่ใช่จาก FireEye alert ของตัวเอง — แต่จาก US Department of Justice ที่โทรมาบอก

บทเรียนจาก Target สรุปเป็น 4 ข้อครับ —

1. เครื่องมือดี ไม่พอ — Target มี FireEye ที่จับได้. ของจริงในวงการ — เครื่องมือทำงาน + alert ดัง — แต่คนที่นั่งหน้าจอ “ไม่เชื่อ” หรือ “ไม่รู้ว่าควรทำอะไรต่อ”
2. Outsourcing ไม่ใช่ “set and forget” — Target outsource SOC ไป Bangalore — แต่ไม่มี SLA ที่ชัดเจน + ไม่มี escalation path ที่ทำงานได้จริง
3. Alert fatigue ฆ่าเร็วกว่า attack — ทีม SOC ของ Target เห็น alert เป็นพันต่อวัน — alert ของ FireEye ถูกฝังในกอง
4. Network segmentation ที่ดี ลดความเสียหายได้ — POS network กับ corporate network ของ Target ไม่ได้แยกกัน — โจรเข้าผ่าน HVAC vendor → corporate → POS ได้

Target 2013 = บทเรียนที่ผู้บริหารทุกคนต้องจำ — detection tool ไม่ได้รับประกันความปลอดภัย. ต้องมี คน + process + governance ที่ทำงานจริง

KPI ของ SOC — 4 ตัวที่ผู้บริหารต้องถาม IT ทุกเดือน#

4 ตัวเลขเดียวที่ผู้บริหารต้องรู้จาก SOC ของบริษัท ทุกเดือน:

• Alert count ต่อเดือน — เห็น volume จริง
• % ที่ analyst ตรวจจริง (ไม่ใช่ auto-dismiss) — ถ้า < 20% = alert fatigue ระดับวิกฤต
• MTTD (Mean Time To Detect) — เทียบกับ industry benchmark (ค่าเฉลี่ยวงการ = 194 วัน — target ของ enterprise ที่ดี < 72 ชม.)
• Incident confirmed — จาก alert ทั้งหมด มีเรื่องจริงกี่ตัว

ถ้า IT ตอบ 4 ตัวนี้ไม่ได้ทันที = SOC ของคุณยังไม่ mature

มุมผู้บริหาร: Lesson จาก Target 2013 — ทุก quarter ผู้บริหารต้องถาม SOC คำถามเดียว — “alert ที่เข้ามาเดือนที่แล้ว — กี่ % ที่ analyst ตรวจจริง?” ถ้าต่ำกว่า 20% = alert fatigue ระดับวิกฤต = ต้องลงทุน SOAR + tuning ทันที. และจัด tabletop exercise ทุก 6 เดือน — งบ 100,000-300,000 บาท/ครั้ง ถูกกว่า incident จริงเคสเดียวหลายร้อยเท่า

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Detection ไม่ใช่เรื่องของเครื่องมือ เป็นเรื่องของ คน + process + เครื่องมือ

นี่คือบทเรียนใหญ่ที่สุดของ EP.43. ที่ผ่านมา 11 EPs ของ Part 4 + EP.39-42 — เราคุยเรื่อง เทคโนโลยี. แต่ EP.43 — เรื่องของ คน + process มีน้ำหนักเท่ากับเทคโนโลยี

Target 2013 มี FireEye ที่จับได้ — แต่คนที่นั่งหน้าจอไม่ตอบ. เครื่องมือ detection ที่ดีที่สุดในโลก ถ้าไม่มี SOC analyst ที่ตอบ alert + process ที่ escalate ถูก + governance ที่ feedback ผลให้ผู้บริหาร — มันเหมือนกล้อง CCTV ที่ไม่มีใครเปิดดู

Action plan สำหรับบริษัทไทยปี 2026:

1. กำหนด KPI ของ SOC ที่ผู้บริหารดู — MTTD / MTTR / % alert ที่ตรวจจริง / incident confirmed — ดูทุก quarter
2. เลือก MSSP ที่ถามคำถามถูก — analyst per customer ratio / SLA ของ escalation / report cadence
3. อย่าซื้อ tool เพื่อ checklist — ตอบ use case ของบริษัทก่อนเลือก SIEM/EDR
4. Tune rule อย่างต่อเนื่อง — ทุก quarter ต้อง review rule ที่ FP สูง + ปรับ + ดูว่า FN ที่เกิดจากการปรับมีอะไร
5. Tabletop exercise ทุก 6 เดือน — ยิง scenario ของจริงให้ทีม SOC + ผู้บริหารตอบ — จับ gap ของ process
6. ลงทุน SOAR หลัง SIEM/EDR ตั้งตัวได้ — ปีแรกตั้ง SIEM/EDR ก่อน ปีที่ 2-3 ค่อยเพิ่ม SOAR
7. อย่าให้ analyst burnout — ที่ Tier 1 — ถ้า analyst ต้องดู 1,000+ alert/day แสดงว่า tuning + SOAR ไม่พอ — แก้ที่ระบบ ไม่ใช่ “เพิ่มคน”

ข้อสอง — Detection คือ “เวลา” ไม่ใช่ “เห็น/ไม่เห็น”

ในวงการมีคำที่จริงเสมอ — “You will get breached. The question is how quickly you detect it.”

บริษัทยักษ์ระดับ Microsoft / Google / Amazon — ก็โดน. คำถามไม่ใช่ “ป้องกัน 100%” (ไม่มี) — แต่เป็น —

• MTTD ของบริษัทคุณเท่าไหร่? (ค่าเฉลี่ยวงการปี 2024 = 194 วัน)
• MTTR เท่าไหร่? (ค่าเฉลี่ยวงการ = 64 วัน)
• เคสไหนของบริษัทคุณที่ MTTD < 1 ชั่วโมง? (target ที่บริษัทระดับโลก aim ไปถึง)

ของจริงในวงการ — บริษัทไทยขนาดกลางที่ลงทุน SOC + SIEM + EDR + SOAR ดี + มี process ที่ tune มา 2-3 ปี — สามารถลด MTTD จาก 194 วัน → 24-72 ชั่วโมง ได้. ผลคือ — เมื่อเกิด breach ความเสียหายลดลง 70-90% เพราะหยุดได้ก่อนข้อมูลออกหรือ ransomware เข้ารหัสครบ

นี่คือ ROI ของ detection investment ที่บริษัทไทยปี 2026 ต้องเข้าใจ — ไม่ใช่ “ป้องกัน breach” — แต่เป็น “ลดความเสียหายของ breach ที่จะเกิดอย่างหลีกเลี่ยงไม่ได้”