ตี 3.47 น.: เบื้องหลังเหตุการณ์จริงที่ถูกจับได้โดย SOC Stack แบบโอเพนซอร์ส

บทความเกี่ยวกับ SOC ส่วนใหญ่มักอธิบายสถาปัตยกรรม แต่บทความนี้จะพาไปดูเหตุการณ์จริงทีละ alert บน stack ที่ใช้งานจริงกับลูกค้าองค์กรขนาดกลาง — Wazuh สำหรับตรวจจับ, DFIR-IRIS สำหรับบริหารเคส และ integrator แบบ FastAPI ที่พัฒนาเองเชื่อมทั้งสองระบบเข้าด้วยกัน ไม่มีค่าไลเซนส์ SaaS ไม่มีค่า cloud SIEM ทุกส่วนเป็นโอเพนซอร์สหรือพัฒนาขึ้นเอง

รายละเอียดเฉพาะของลูกค้าถูกปรับให้เป็นข้อมูลทั่วไปเพื่อรักษาความลับ แต่ตรรกะการตรวจจับ เวลา และพฤติกรรมระบบเป็นเรื่องจริง

หากต้องการดูสถาปัตยกรรมแบบเต็ม เราเคยเขียนแยกไว้แล้ว: การสร้าง stack นี้แบบ commit-by-commit และ สิ่งที่ simpliSOC เฝ้าระวังทั้งหมด บทความนี้คือสิ่งที่เกิดขึ้นเมื่อระบบกำลังเฝ้าดูอยู่

ตี 3.47 น. — Alert แรก

มีการล็อกอินสำเร็จบน VPN concentrator ด้วยบัญชีของแผนกการเงิน ลำพังเหตุการณ์นี้ไม่ผิดปกติ เพราะการทำงานทางไกลทำให้การล็อกอินนอกเวลางานไม่ใช่สัญญาณอันตรายเสมอไป กฎของ Wazuh บันทึกไว้ ให้คะแนนความเสี่ยงต่ำ แล้วผ่านไป

ตี 3.52 น. — ล็อกอินครั้งที่สอง คนละทวีป

ห้านาทีต่อมา บัญชีเดียวกันล็อกอินอีกครั้ง — คราวนี้จาก IP ของบ้านพักอาศัยที่อยู่ห่างจากตำแหน่งล็อกอินแรกประมาณ 9,000 กิโลเมตร ล็อกอินแต่ละครั้งเพียงลำพังอาจไม่ทำให้ SOC ส่วนใหญ่สงสัย แต่เมื่อรวมกันแล้วเป็นไปไม่ได้ทางกายภาพ

จุดนี้คือขีดจำกัดของ rule engine แบบ stateless Wazuh สามารถแจ้งเตือน "ล็อกอินจากตำแหน่งใหม่" เป็น event เดียวได้ แต่ไม่มีความจำเกี่ยวกับล็อกอินเมื่อห้านาทีก่อน และไม่มีวิธีคำนวณระยะทางเทียบกับเวลาที่ผ่านไป ตรรกะนี้อยู่ในชั้น integrator: worker ที่ใช้ PostgreSQL เก็บสถานะการล็อกอินล่าสุดของผู้ใช้แต่ละคน แล้วคำนวณระยะทางแบบ haversine เทียบกับเวลาที่ผ่านไป การล็อกอินสองครั้งที่ต้องใช้ความเร็วเกินเที่ยวบินพาณิชย์จะถูกตั้งค่าสถานะโดยอัตโนมัติ — ไม่ต้องอาศัยนักวิเคราะห์มองเห็นรูปแบบด้วยตาเปล่า

ระบบ correlation เปิดเคสใน DFIR-IRIS ทันที ระดับความรุนแรง: วิกฤต เริ่มจับเวลา SLA: ต้องตอบสนองภายใน 1 ชั่วโมง

ตี 3.53 น. — Enrichment ก่อนที่มนุษย์จะเห็นด้วยซ้ำ

ก่อนที่เคสจะปรากฏในคิวของนักวิเคราะห์ ข้อมูลบริบทถูกแนบมาแล้ว worker ด้าน enrichment ของ integrator สอบถาม IP ต้นทางของการล็อกอินครั้งที่สองกับ VirusTotal และ AbuseIPDB ในเบื้องหลัง — IP นี้ถูกตั้งค่าสถานะจาก blocklist ของชุมชนถึงสามแหล่ง และเคยเกี่ยวข้องกับการโจมตีแบบ credential-stuffing มาก่อน คะแนนความน่าเชื่อถือนี้ถูกบันทึกเป็นฟิลด์ที่มีโครงสร้างในบันทึกของเคส ไม่ใช่ฝังอยู่ในย่อหน้าที่นักวิเคราะห์ต้องไปค้นหาเอง

จุดนี้สำคัญกว่าที่ฟังดู ในหลาย SOC การ enrichment เกิดขึ้น หลัง การคัดกรอง หรือต้องให้นักวิเคราะห์สลับไปใช้เครื่องมืออีกตัว แต่ที่นี่เกิดขึ้นก่อนที่เคสจะถึงมือมนุษย์ เพราะ IOC enrichment ทำงานแบบ async และรันคู่ขนานกับการสร้าง alert — ไม่ต้องรอคิว

ตี 3.58 น. — Alert ที่ไม่ทำให้คิวล้น

IP ต้นทางเดียวกันพยายามล็อกอินอีกสองบัญชีในสี่นาทีถัดมา — ทั้งสองครั้งล้มเหลว ปกติแล้วแต่ละครั้งจะสร้าง alert ของตัวเอง หากไม่มีการ deduplication นี่คือรูปแบบที่ทำให้นักวิเคราะห์เริ่มเพิกเฉยต่อคิว: สาม alert ที่เกี่ยวข้องกันสำหรับเหตุการณ์เดียว แต่ละอันเรียกร้องความสนใจแยกกัน

worker dedup ของ integrator จัดกลุ่ม alert เหล่านี้เข้ากับเคสเดิม โดยใช้ cooldown window เฉพาะแต่ละกฎ — รูปแบบการโจรกรรม credential มี window ต่อผู้ใช้/โฮสต์ที่ปรับจากปริมาณ alert จริงในการใช้งาน ไม่ใช่การเดา หนึ่งเคส หนึ่งนาฬิกา SLA สามจุดข้อมูลแทนที่จะเป็นสาม alert แยกกัน

ตี 4.04 น. — นักวิเคราะห์รับเคส

นักวิเคราะห์เวรถูกเรียกผ่าน PagerDuty — ระดับความรุนแรงวิกฤตจะถูกส่งไปที่นั่นโดยอัตโนมัติ พวกเขาเปิดเคสใน IRIS และพบทุกอย่างในที่เดียว: เหตุการณ์ล็อกอินทั้งสองครั้ง การคำนวณตำแหน่งทางภูมิศาสตร์ ผล enrichment การจับคู่กับ MITRE ATT&CK (T1078 – Valid Accounts) และ checklist การคัดกรองเฉพาะกฎนี้ที่โหลดจากไฟล์ YAML แทนที่จะต้องนึกเอาเองตอนตี 4

บัญชีถูกปิดใช้งาน แผนกการเงินได้รับแจ้ง session token ถูกเพิกถอน เวลารวมจากล็อกอินครั้งที่สองจนถึงการควบคุมสถานการณ์: 23 นาที — อยู่ในกรอบ SLA วิกฤต 1 ชั่วโมง โดย progress bar ยังเป็นสีเขียว

ตี 4.31 น. — ปิด Loop

นี่คือขั้นตอนที่หลาย stack มักข้ามไป นักวิเคราะห์ยืนยันเคสใน IRIS — แต่การยืนยัน correlation ที่อยู่แค่ในเครื่องมือบริหารเคสถือเป็นเพียงครึ่งหนึ่งของการตรวจจับ integrator ส่งข้อความ syslog กลับไปที่ Wazuh เพื่อบันทึกเหตุการณ์ที่ยืนยันแล้วลงใน SIEM เอง ตอนนี้ทั้งสองระบบตรงกัน: correlation ไม่ได้แค่ถูกสอบสวน แต่ถูกจดจำโดยชั้นตรวจจับที่จะเฝ้าระวังรูปแบบเดียวกันจากบัญชีนี้ต่อไปในอนาคต

หากไม่มี Integrator เหตุการณ์นี้จะเป็นอย่างไร

ตัดระบบ correlation ออก นี่จะกลายเป็น alert ความรุนแรงต่ำสองอันที่ดูไม่เกี่ยวข้องกัน อยู่ในคิวแยกกัน — ประเภทที่ถูกคัดกรองทีละอันและปิดเป็น "ผู้ใช้พิมพ์ผิด, VPN client แคชตำแหน่งเก่า" โดยไม่มีใครเชื่อมโยงมันเข้าด้วยกัน

ตัด deduplication ออก จะกลายเป็นห้า alert แทนที่จะเป็นสอง สามในนั้นซ้ำกันสำหรับเหตุการณ์เดียวกัน เพิ่ม alert fatigue ที่ทำให้สัญญาณจริงมองเห็นยากขึ้น

ตัด worker enrichment ออก นักวิเคราะห์ต้องเปิดแท็บที่สองเพื่อเช็ค VirusTotal เอง หน้าต่างเวลาควบคุมสถานการณ์ 23 นาทีจะยาวขึ้นทุกครั้งที่มนุษย์ต้องสลับบริบท

ไม่มีชิ้นส่วนไหนพิเศษเกินไปในตัวเอง สิ่งที่สร้างความแตกต่างคือการเชื่อมทุกส่วนเข้าด้วยกันและทำงานก่อนที่มนุษย์จะเข้ามาเกี่ยวข้อง ไม่ใช่หลังจากนั้น

ตัวเลขเบื้องหลัง Stack นี้

ตัวชี้วัด	ค่า
กฎตรวจจับที่พัฒนาเอง	95 กฎ ครอบคลุม 8 หมวดหมู่
รอบ sync alert (Wazuh → IRIS)	ทุก 5 วินาที
รอบรีเฟรช IOC list	ทุก 4 ชั่วโมง
สถานะ correlation	บันทึกถาวรด้วย PostgreSQL
SLA เหตุการณ์วิกฤต	ตอบสนองภายใน 1 ชั่วโมง
เหตุการณ์นี้: จากตรวจจับถึงควบคุมได้	23 นาที
การติดตั้ง	on-premises 100% ไม่พึ่ง cloud

ทำไมถึงออกแบบมาแบบนี้

กฎตรวจจับทุกข้อใน stack นี้มีสองเวอร์ชัน: กฎจำลองที่ทำงานกับข้อมูลทดสอบสังเคราะห์ และกฎจริงที่ปรับจูนกับฟิลด์ event จริง คู่นี้ทำให้ตรรกะ correlation ข้างต้นผ่านการทดสอบมาแล้วก่อนที่จะเจอการล็อกอินจริง — alert ตี 3.52 น. ไม่ใช่ครั้งแรกที่กฎนี้ทำงาน เพียงแต่เป็นครั้งแรกที่มันสำคัญจริงๆ

นี่ยังเป็นเหตุผลที่ stack นี้รันเป็นบริการ FastAPI แยกต่างหาก แทนที่จะพึ่ง active-response script ในตัว Wazuh: correlation ต้องการสถานะที่คงอยู่ระหว่าง event, enrichment ต้องทำงานแบบ async โดยไม่บล็อกการสร้าง alert และทุกการตัดสินใจต้องสามารถ replay ผ่าน REST endpoint ได้เมื่อต้องปรับจูน threshold หลังเหตุการณ์แบบนี้

สำหรับองค์กรที่อยู่ภายใต้ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA) และมาตรา 59 ของพระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ การที่ log และหลักฐานการตอบสนองเหตุการณ์อยู่บน infrastructure ในประเทศ ไม่ใช่ cloud SIEM ต่างประเทศ ทำให้การรายงานต่อหน่วยงานกำกับดูแลและการตรวจสอบทำได้ตรงไปตรงมากว่า

คำถามที่พบบ่อย

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

ระบบนี้จับเหตุการณ์อื่นนอกจากการโจรกรรม credential ได้ไหม
ได้ — ระบบ correlation เดียวกันจัดการรูปแบบการเคลื่อนไหวในเครือข่าย (lateral movement) และการยกระดับสิทธิ์ด้วยแนวทางสถานะถาวรแบบเดียวกัน credential abuse เป็นเพียงตัวอย่างที่อธิบายได้ชัดเจนที่สุด

ต้องทำอะไรบ้างเพื่อให้ stack แบบนี้ทำงานในองค์กรของเรา
ขึ้นอยู่กับแหล่ง log ที่มีอยู่และข้อกำหนดด้านการปฏิบัติตามกฎหมาย วิธีที่เร็วที่สุดคือดูมันทำงานกับสถานการณ์ที่ใกล้เคียงกับองค์กรของคุณ

stack นี้ทดแทน firewall หรือเครื่องมือ endpoint ที่มีอยู่หรือไม่
ไม่ใช่ stack นี้รับข้อมูลจากแหล่ง perimeter และ endpoint ที่มีอยู่ (firewall syslog, Windows AD, Sysmon, log ของ hypervisor) — มันคือชั้นตรวจจับ correlation และบริหารเคสที่อยู่ด้านบน ไม่ใช่การแทนที่สิ่งที่บันทึก log อยู่แล้ว

---

ชมการทำงานของ Stack นี้กับสถานการณ์จริง

การอ่านเรื่องหน้าต่างเวลาควบคุมสถานการณ์ 23 นาทีเป็นเรื่องหนึ่ง แต่การเห็น correlation engine ตั้งค่าสถานะแบบเรียลไทม์ เคสใน IRIS สร้างตัวเอง และ loop ปิดกลับไปที่ Wazuh เป็นอีกเรื่องหนึ่ง ขอเดโมได้เลย เราจะจำลองสถานการณ์ที่ใกล้เคียงกับสภาพแวดล้อมจริงของคุณ — แหล่ง log ของคุณ ข้อกำหนดการปฏิบัติตามกฎหมายของคุณ ปริมาณ alert ของคุณ

hello@simplico.net