SOC Maturity

องค์กรจำนวนมากลงทุนใน SIEM/EDR/SOAR ก่อนเข้าใจว่า SOC ของตัวเองอยู่ระดับใด สุดท้ายเครื่องมือดี ๆ กลายเป็น shelfware เพราะขาดกระบวนการและกำลังคน บทนำนี้อธิบายว่าทำไม SOC Maturity Assessment จึงเป็นก้าวแรกที่จำเป็น และเล่าถึงการเปลี่ยนแปลงของภูมิทัศน์ภัยคุกคามในภูมิภาคเอเชียตะวันออกเฉียงใต้ รวมถึงแรงผลักจากหน่วยกำกับในประเทศไทย ที่ทำให้ SOC กลายเป็นความสามารถหลักขององค์กรแทนที่จะเป็นส่วนขยายของฝ่าย IT

 

ในช่วงสามปีที่ผ่านมา ลักษณะของภัยคุกคามไซเบอร์ในภูมิภาคเอเชียตะวันออกเฉียงใต้เปลี่ยนแปลงอย่างชัดเจน Mandiant M-Trends ระบุว่า median dwell time ของภูมิภาคลดลงจาก 28 วันในปี 2565 เหลือ 18 วันในปี 2567 ขณะที่กลุ่ม APT ที่มุ่งเป้าต่อประเทศไทยอย่าง Mustang Panda, APT41 และ Lazarus มีการปรับเทคนิคให้ยากต่อการตรวจจับมากขึ้น อาทิ การใช้ living-off-the-land binaries และการซ่อนตัวใน process ที่ถูกลงนาม

 

ขณะเดียวกัน ธนาคารแห่งประเทศไทยและสำนักงาน ก.ล.ต. ได้ออกแนวปฏิบัติที่ระบุให้ธนาคารและบริษัทหลักทรัพย์ต้องมีความสามารถในการตรวจจับและตอบสนองเหตุการณ์ 24 ชั่วโมงต่อวัน พร้อมรายงานเหตุการณ์สำคัญภายในกรอบเวลาที่กำหนด แรงผลักทั้งด้านภัยคุกคามและด้านหน่วยกำกับทำให้ SOC กลายเป็นความสามารถหลัก ที่องค์กรไม่สามารถละเลยหรือดำเนินการในลักษณะส่วนขยายของฝ่าย IT ได้อีกต่อไป

 

67%
ขององค์กรใน APAC ยังคงตรวจพบเหตุการณ์หลังจากผู้โจมตีอยู่ในระบบเกินกว่า 30 วัน (Mandiant M-Trends 2025)

 

18 วัน
Median Dwell Time ของภูมิภาค APAC ปี 2567 (Mandiant M-Trends 2025) — ลดลงจาก 28 วันในปี 2565

 

4.45 M USD
ค่าเฉลี่ยความเสียหายจากเหตุการณ์ข้อมูลรั่วในภูมิภาคอาเซียน (IBM Cost of a Data Breach 2024)

คู่มือเล่มนี้แบ่งออกเป็น 9 บท เรียงลำดับจากพื้นฐานความรู้ความเข้าใจในภัยคุกคาม ไปจนถึงการวางกลยุทธ์ การลงมือปฏิบัติ และการวัดผล แต่ละบทจะสรุปแนวคิดหลัก ศัพท์สำคัญ และข้อควรทำจริงให้อ่านเข้าใจได้โดยไม่ต้องมีพื้นฐานเทคนิคมาก่อน

 

 

CHAPTER ONE · THE STARTING LINE

บทที่ 01 · SOC Maturity Assessment

SOC-CMM (SOC Capability Maturity Model) พัฒนาโดย Rob van Os เป็นกรอบการประเมินที่แบ่งความสามารถของ SOC ออกเป็น 5 โดเมนหลัก ได้แก่ Business, People, Process, Technology และ Services โดยแต่ละโดเมนมีเกณฑ์การวัดระดับ 0 ถึง 5 ที่สะท้อนทั้งความสามารถเชิงโครงสร้างและผลลัพธ์เชิงบริการ การใช้กรอบที่เป็นสากลช่วยให้ทีมและผู้บริหารพูดภาษาเดียวกัน ลดการตีความที่ต่างกันเมื่อรายงานต่อคณะกรรมการ

“ไม่มีองค์กรใดลงทุนใน SOC ได้ถูกจุด ถ้ายังไม่รู้ว่า SOC ตัวเองอยู่ระดับใด”

 

 

CHAPTER TWO · THE TEAM

บทที่ 02 · People & Shift Structure

โครงสร้าง SOC แบบคลาสสิกแบ่งนักวิเคราะห์เป็น Tier 1 (triage), Tier 2 (investigation + response) และ Tier 3 (threat hunting + detection engineering) โดยแต่ละ tier มีภาระงาน ระดับความรู้ และเส้นทางเติบโตที่ต่างกัน ในองค์กรขนาดกลาง นักวิเคราะห์ Tier 1 มักเป็นผู้ที่เพิ่งจบใหม่หรือย้ายมาจากฝ่าย IT operations ขณะที่ Tier 2–3 ต้องการประสบการณ์ 3 ปีขึ้นไปและความเข้าใจใน adversary behavior

“ทีม SOC ที่ดีที่สุดในโลก ไม่ได้ประกอบด้วยอัจฉริยะ แต่คือทีมที่มีโครงสร้างที่ยั่งยืน”

 

 

CHAPTER THREE · THE DETECTION

บทที่ 03 · Use Case Design

use case ส่วนใหญ่ที่มาพร้อม SIEM เป็นกฎทั่วไปที่ vendor ออกแบบให้ใช้ได้กับทุกองค์กร ทำให้ไม่ตรงกับความเสี่ยงเฉพาะของแต่ละธุรกิจ การออกแบบ use case ควรเริ่มจากการระบุ crown jewel — สินทรัพย์ที่สำคัญที่สุด เช่น ฐานข้อมูลลูกค้า, ระบบ core banking, trading system — แล้วถามว่าใครคือภัยคุกคามของสินทรัพย์นั้น และใช้เทคนิคใดใน MITRE ATT&CK

“ถ้า detection rule ของคุณไม่ผูกกับความเสี่ยงธุรกิจ คุณกำลังตรวจจับสิ่งที่ผิดอยู่ทุกวัน”

 

CHAPTER FOUR · THE STACK

บทที่ 04 · Tooling & Stack Decision

Gartner เสนอแนวคิด SOC Visibility Triad ว่า SOC ที่ดีต้องเห็นข้อมูลจากสามแหล่งหลัก — log (SIEM), endpoint (EDR) และ network (NDR) — เพราะผู้โจมตีที่หลบจากแหล่งหนึ่งมักทิ้งร่องรอยที่อีกสองแหล่ง การเน้นเพียงแหล่งเดียวทำให้เกิด blind spot ที่ผู้โจมตีระดับสูงใช้ประโยชน์

ในองค์กรไทยขนาดกลาง EDR เป็นเครื่องมือที่ลงทุนก่อน เพราะให้ visibility ต่อ endpoint ได้ทันที และ cost-per-seat ต่ำกว่า SIEM เต็มรูปแบบ จากนั้นค่อยเพิ่ม SIEM สำหรับ compliance และ NDR สำหรับการตรวจจับ lateral movement

“เครื่องมือที่ดีแต่ไม่มี use case คือเงินที่จ่ายทิ้งและความสามารถที่ไม่ได้ใช้”

 

CHAPTER FIVE · THE ENGINEERING

บทที่ 05 · Detection Engineering Fundamentals

การเขียน detection rule แบบกดปุ่มในหน้า SIEM console ทำให้ทีมเสีย version history, peer review และ rollback capability เมื่อ rule ทำให้ระบบพัง Detection Engineering มองว่า rule ทุกตัวเป็น code ต้องอยู่ใน Git repository มี pull request สำหรับ review และ CI/CD pipeline สำหรับ deploy อัตโนมัติ

“Detection เป็น code รูปแบบหนึ่ง — ต้อง test, review, version ได้เหมือน software”

 

CHAPTER SIX · THE RESPONSE

บทที่ 06 · Incident Handling

NIST SP 800-61 เป็นมาตรฐานสากลที่แบ่ง IR เป็น 4 เฟสหลัก ได้แก่ Preparation, Detection & Analysis, Containment Eradication & Recovery, และ Post-Incident Activity ในเฟส preparation ทีมต้องเตรียม playbook, contact list, tool, และซ้อม tabletop exercise อย่างน้อยไตรมาสละครั้ง เพราะความพร้อมวัดได้เฉพาะเมื่อซ้อม ไม่ใช่เมื่อเขียนเอกสาร

“การตอบสนองที่ดีไม่ใช่การกู้ระบบเร็วที่สุด แต่คือการกู้โดยไม่สร้างปัญหาใหม่”

 

CHAPTER SEVEN · THE MEASUREMENT

บทที่ 07 · Metrics & Reporting

คณะกรรมการไม่สนใจ MTTD/MTTR ในระดับวินาที แต่สนใจว่า SOC ช่วยลดความเสี่ยงทางธุรกิจได้เท่าไร วัดเป็นตัวเงิน การเปลี่ยน technical metric ให้เป็น business metric คือทักษะสำคัญของ SOC Manager ตัวอย่างเช่น การเปลี่ยน 'detect coverage 78% ของ T1059' เป็น 'เรามองเห็น 78% ของเทคนิคที่กลุ่ม APT41 ใช้โจมตีธนาคารในภูมิภาค'

“ถ้าคณะกรรมการฟัง MTTD 47 นาทีแล้วไม่เข้าใจ แปลว่าคุณยังวัดผลผิดกลุ่ม”

 

CHAPTER EIGHT · THE DELIVERY MODEL

บทที่ 08 · MSSP vs In-House

in-house SOC มีข้อดีในด้านความเข้าใจบริบทธุรกิจ การตอบสนองที่ใกล้ชิด และการสร้าง capability ระยะยาว แต่มาพร้อมต้นทุน recruit, retention และ tool license ที่สูง ส่วน MSSP ลดเวลาในการตั้งต้นจาก 12+ เดือนเหลือ 2–3 เดือน และมีความเชี่ยวชาญที่ได้จากการเห็น incident จากหลายองค์กร แต่ความเข้าใจบริบทธุรกิจเฉพาะจะจำกัด

“MSSP ไม่ใช่คำตอบของทุกองค์กร เช่นเดียวกับ in-house ไม่ใช่ทางเลือกเดียวที่ถูกต้อง”

 

CHAPTER NINE · THE ROADMAP

บทที่ 09 · SOC 2026 Roadmap
 
roadmap 3 ปีควรแบ่งเป็น 3 เฟส — Year 1: Stabilize (ปิดช่องโหว่พื้นฐาน, ตั้ง use case หลัก, สร้าง IR playbook), Year 2: Optimize (Detection engineering maturity, automation, metrics maturity), Year 3: Threat-Led (threat hunting program, purple team, CTI-driven operations) การเดินเป็นลำดับช่วยให้ทีมไม่กระโดดไปเร็วเกินจนฐานยังไม่มั่น

“Roadmap ที่ดีไม่ใช่เอกสาร 30 หน้า แต่คือเรื่องเล่าที่คณะกรรมการอ่านจบใน 10 นาทีแล้วอนุมัติ”

 

บทสรุป
เมื่ออ่านมาถึงตรงนี้ ท่านได้เห็นแล้วว่า SOC ที่ยั่งยืนไม่ได้เกิดจากการซื้อ SIEM ที่แพงที่สุด หรือการจ้าง MSSP ที่มีชื่อเสียง แต่เกิดจากการเข้าใจสถานะปัจจุบันของทีม วางแผนการลงทุนที่สอดคล้องกับความเสี่ยงของธุรกิจ และสร้าง capability ในระยะยาวทีละเฟส

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: