SOC & การตรวจจับภัย

01ตีสามในห้อง SOC A night shift

ตีสามสิบสองนาที คืนวันศุกร์ ทั้งตึกเงียบจนได้ยินเสียงแอร์ มีห้องเดียวบนชั้นเจ็ดที่ไฟยังเปิด และจอใหญ่บนผนังเพิ่งเปลี่ยนจากสีเทาเป็นสีเหลือง

“ฝน” นักวิเคราะห์กะดึก วางแก้วกาแฟแล้วคลิกเปิดแจ้งเตือน บัญชีอีเมลของ nida พนักงานฝ่ายบัญชี ล็อกอินผิดรหัสติดกันเจ็ดครั้งในเวลาไม่ถึงสี่นาที ยังอ่านไม่ทันจบ แจ้งเตือนอันที่สองก็เด้งตามมา คราวนี้เป็นสีส้ม ล็อกอินสำเร็จ จากประเทศที่บัญชีนี้ไม่เคยใช้มาก่อนเลย

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

ห้องที่ฝนนั่งอยู่เรียกว่า ศูนย์ปฏิบัติการความมั่นคงปลอดภัย (Security Operations Center: SOC อ่านว่า “ซ็อก”) หมายถึงทีมคน กระบวนการ และเครื่องมือ ที่ช่วยกันเฝ้าระบบขององค์กรตลอด 24 ชั่วโมง งานของ SOC สรุปได้สามข้อ คือ มองให้เห็น ว่ากำลังเกิดอะไรขึ้นในระบบ จับให้ได้ ว่าอะไรผิดปกติ และ ส่งต่อให้เร็ว เมื่อเจอของจริง

ถ้าจะเทียบให้เห็นภาพ SOC ก็คือห้องกล้องวงจรปิดของ รปภ.คอนโด รปภ.ไม่ได้ยืนขวางทุกคนที่ประตู แต่คอยดูว่าใครเดินวนหน้าห้องคนอื่นนานผิดสังเกต ใครมาตอนตีสามโดยไม่มีบัตร ต่างกันตรงที่ SOC ไม่ได้ดูภาพจากกล้อง แต่ดู ล็อก (log) คือบันทึกเหตุการณ์ที่คอมพิวเตอร์ทุกเครื่องเขียนเก็บไว้เองตลอดเวลา

ในระดับ 3 เรายืนมองผ่านตาผู้โจมตี เห็นว่าเขาวางแผนเป็นขั้นเป็นตอนอย่างไร ระดับ 4 นี้เราสลับมายืนอีกฝั่ง ข่าวดีคือแทบทุกขั้นของคนร้ายที่เราเรียนมา ทิ้งรอยไว้ให้เห็นเสมอ ขอแค่รู้ว่าต้องมองหาที่ไหน และมองให้เร็วพอ

ศัพท์น่ารู้: SOC, MSSP และ MDR

องค์กรใหญ่มักตั้ง SOC ของตัวเอง ส่วนองค์กรที่ไม่มีคนพอจะเฝ้ากะดึก มักจ้างบริษัทภายนอกเฝ้าแทน เรียกว่าผู้ให้บริการความปลอดภัยแบบดูแลให้ (Managed Security Service Provider: MSSP) ถ้าบริการนั้นเน้นทั้งจับและลงมือรับมือให้ด้วย มักเรียกว่า MDR (Managed Detection and Response)

02ใครทำอะไรในห้อง SOC SOC tiers

คนที่ไม่เคยเห็นห้อง SOC มักนึกว่าทุกคนในห้องทำงานเหมือนกัน ความจริงงานถูกแบ่งเป็นชั้น (tier) คล้ายห้องฉุกเฉินของโรงพยาบาล ที่มีพยาบาลคัดกรองคนไข้ก่อน คนที่อาการหนักถูกส่งต่อให้หมอเวร และเคสยากจริง ๆ ถูกส่งต่อให้หมอเฉพาะทาง คำว่า คัดกรอง (triage) ที่คน SOC พูดกันทุกวัน ก็ยืมมาจากห้องฉุกเฉินนี่เอง

สิ่งที่ทำให้ต้องแบ่งชั้นคือ “ปริมาณ” ระบบขององค์กรหนึ่งสร้างเหตุการณ์ออกมามหาศาลทุกวัน ไม่มีมนุษย์คนไหนอ่านไหว งานแรกจึงเป็นของเครื่องจักร แล้วค่อย ๆ กรองลงมาจนเหลือแต่เรื่องที่ต้องใช้สมองคนจริง ๆ

ชั้นที่ 1 · ด่านหน้า (L1 Triage)

นักวิเคราะห์ L1 รับแจ้งเตือนทุกเรื่องที่ไหลเข้าคิว แล้วตัดสินใจเรื่องละไม่กี่นาทีว่าจะไปทางไหน มีสามทางหลัก ทางแรกคือ ปิด เพราะเป็นสัญญาณหลอก เช่น กฎเข้าใจผิดว่าโปรแกรมอัปเดตเป็นมัลแวร์ ทางที่สองคือ ปิด เพราะเป็นเรื่องจริงแต่ไม่อันตราย เช่น ทีมไอทีกำลังสแกนเครือข่ายตามแผนที่แจ้งไว้แล้ว คนในวงการเรียกกรณีนี้ว่า benign true positive ทางที่สามคือ ยกระดับ (escalate) ส่งต่อให้ชั้นถัดไป

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

ชั้นที่ 2 · นักสืบ (L2 Investigation)

เมื่อเรื่องถูกยกระดับมา L2 จะถามคำถามต่อว่า “แล้วไงต่อ” บัญชีนี้ทำอะไรหลังล็อกอิน เปิดไฟล์ไหน เข้าเครื่องไหนต่อ มีบัญชีอื่นโดนแบบเดียวกันไหม L2 ดึงล็อกย้อนหลังหลายแหล่งมาเรียงต่อกันเป็นเรื่องเล่า และมีอำนาจเริ่มกักวงได้ เช่น ตัดเซสชันที่ล็อกอินอยู่ หรือแยกเครื่องที่ติดออกจากเครือข่าย

ชั้นที่ 3 · ผู้เชี่ยวชาญ (L3 Expert)

L3 รับเหตุใหญ่ที่ลามหลายระบบ วิเคราะห์มัลแวร์ ออกล่าภัยเชิงรุกโดยไม่รอแจ้งเตือน และที่สำคัญมากคือ ป้อนบทเรียนกลับเข้าไปในกรวย ทุกครั้งที่เจอวิธีโจมตีใหม่ ก็เขียนกฎใหม่ให้เครื่องจักรจับเองได้ในครั้งหน้า

รอบ ๆ สามชั้นนี้ยังมีบทบาทอื่นอีก เช่น วิศวกรตรวจจับ (detection engineer) ที่เขียนและดูแลกฎ นักวิเคราะห์ข่าวกรองภัย และผู้จัดการ SOC ที่ดูแลคนและตัวชี้วัด หลายองค์กรเริ่มเลิกแบ่งชั้นแบบตายตัว ให้คนคนเดียวดูเรื่องหนึ่งตั้งแต่ต้นจนจบ แต่หลักคิดยังเหมือนเดิม คือให้เครื่องกรองก่อน แล้วเก็บสมองคนไว้ใช้ตรงที่ต้องใช้วิจารณญาณ

ศัพท์น่ารู้: Playbook และ Runbook

คู่มือที่เขียนไว้ล่วงหน้าว่าเจอแจ้งเตือนแบบนี้ต้องเช็กอะไรบ้าง ตามลำดับไหน และเมื่อไรต้องยกระดับ บางที่เรียก playbook (ภาพรวมของการรับมือ) บางที่เรียก runbook (ขั้นตอนลงมือทีละคำสั่ง) คู่มือที่ดีทำให้คนเพิ่งเข้างานสัปดาห์แรกตัดสินใจได้ใกล้เคียงคนที่ทำมาห้าปี

03ล็อก: หลักฐานที่ระบบทิ้งไว้ Logs as evidence

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

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

Oct 24 03:08:11 web-01 sshd[4121]: Failed password for invalid user oracle from 203.0.113.45 port 50112 ssh2
Oct 24 03:08:14 web-01 sshd[4121]: Failed password for root from 203.0.113.45 port 50119 ssh2
Oct 24 03:09:52 web-01 sshd[4188]: Accepted publickey for deploy from 10.20.0.15 port 41822 ssh2

อ่านจากซ้ายไปขวา: วันและเวลา ชื่อเครื่อง (web-01) โปรแกรมที่เขียนล็อก (sshd คือบริการรีโมตเข้าเครื่อง) ผลลัพธ์ ชื่อบัญชี และ IP ต้นทาง คำว่า invalid user ในบรรทัดแรกแปลว่า “ไม่มีบัญชีชื่อนี้ในเครื่อง” ซึ่งบอกเราว่าอีกฝ่ายกำลังสุ่มเดาทั้งชื่อและรหัส ส่วนบรรทัดที่สามเป็นภาพปกติ คือบัญชี deploy เข้ามาด้วยกุญแจ (publickey) จาก IP ภายในบริษัท

สองบรรทัดแรกน่าตกใจไหม? ไม่เท่าไร เซิร์ฟเวอร์ที่เปิดออกอินเทอร์เน็ตจะโดนบอตสุ่มเคาะประตูแบบนี้ทั้งวันทั้งคืน เหมือนเสียงพื้นหลังของเมือง ถ้าแจ้งเตือนทุกบรรทัด ห้อง SOC จะจมน้ำตายภายในคืนเดียว สิ่งที่ต้องจับตาจริง ๆ คือ บรรทัด Accepted ที่ตามหลังมาจาก IP เดียวกัน เพราะนั่นแปลว่ามีคนเดาถูก

EventID     4625   An account failed to log on
TimeCreated 2026-10-24T03:10:07+07:00
Computer    FIN-PC-07
TargetUser  CORP\nida
LogonType   3      // เข้ามาทางเครือข่าย ไม่ใช่นั่งหน้าเครื่อง
SourceIP    10.20.4.31
SubStatus   0xC000006A  // ชื่อบัญชีถูก แต่รหัสผ่านผิด

Windows ไม่ได้เขียนล็อกเป็นประโยค แต่ใช้ หมายเลขเหตุการณ์ (Event ID) แทน ตัวที่คน SOC จำได้ขึ้นใจมีไม่กี่ตัว เช่น 4624 ล็อกอินสำเร็จ 4625 ล็อกอินล้มเหลว 4688 มีโปรแกรมใหม่เริ่มทำงาน และ 4720 มีการสร้างบัญชีผู้ใช้ใหม่ ส่วนช่อง LogonType บอกว่าเข้ามาแบบไหน เลข 3 คือผ่านเครือข่าย เลข 10 คือรีโมตเดสก์ท็อป ซึ่งถ้าโผล่บนเครื่องที่ไม่เคยมีใครรีโมตเข้าเลย ก็ควรถามต่อว่าใคร

สังเกตช่องเวลาด้วย +07:00 คือเวลาประเทศไทย ถ้าเครื่องในองค์กรตั้งเวลาไม่ตรงกันแม้แค่ไม่กี่นาที การเรียงเหตุการณ์จากหลายเครื่องจะสับสนทันที องค์กรจึงต้องให้ทุกเครื่องซิงก์เวลากับนาฬิกากลางเดียวกัน

{
  "time":       "2026-10-24T03:13:02+07:00",
  "user":       "nida@fasai.example",
  "app":        "webmail",
  "result":     "success",
  "src_ip":     "198.51.100.23",
  "geo":        { "country": "XX" },   // ประเทศที่บัญชีนี้ไม่เคยใช้
  "mfa":        "not_required",
  "user_agent": "python-requests/2.31"
}

นี่คือล็อกที่ทำให้จอของฝนเปลี่ยนเป็นสีส้ม อ่านทีละช่องแล้วจะเห็นว่ามีสามอย่างที่ไม่เข้าที่ ข้อแรก ล็อกอิน สำเร็จ จากประเทศที่ไม่เคยเห็น ข้อสอง ระบบ ไม่ได้ขอการยืนยันสองชั้น (MFA) เลย ซึ่งเป็นช่องโหว่ของนโยบายมากกว่าความผิดของใคร ข้อสาม ช่อง user_agent บอกว่าคนที่ล็อกอินไม่ได้ใช้เบราว์เซอร์ แต่เป็นสคริปต์อัตโนมัติ มนุษย์ที่ลืมรหัสตอนเที่ยวคงไม่เขียนโปรแกรมมาล็อกอินอีเมลตอนตีสาม

ทีละช่องไม่มีอะไรพิสูจน์ได้ แต่ สามช่องรวมกัน เล่าเรื่องที่ชัดเจนมาก นี่คือหัวใจของงานตรวจจับ: ไม่ได้มองหาหลักฐานชิ้นเดียวที่ฟันธงได้ แต่มองหาหลายชิ้นที่ชี้ไปทางเดียวกัน

ล็อกที่ดี ต้องรอดจากมือคนร้ายด้วย

คนร้ายที่เก่งพอรู้ดีว่าล็อกคือพยานปากเอก จึงมักพยายามลบมันทิ้ง วิธีกันง่าย ๆ คือ ส่งล็อกออกจากเครื่องไปเก็บที่ศูนย์กลางทันทีที่เกิด เครื่องโดนยึดก็ยังมีสำเนาอยู่ข้างนอก และอีกเรื่องที่น่ารู้คือ การล้างล็อกบน Windows ก็ทิ้งรอยไว้เอง เป็นเหตุการณ์หมายเลข 1102 (audit log ถูกล้าง) ลบรอยเท้า ก็ยังทิ้งรอยการลบไว้ให้เห็น ล็อกตัวนี้จึงเป็นแจ้งเตือนชั้นดีที่แทบไม่มีเหตุผลปกติให้เกิดตอนตีสาม

ศัพท์น่ารู้: NTP และระยะเวลาเก็บล็อก (Retention)

NTP (Network Time Protocol) คือโปรโตคอลที่ให้ทุกเครื่องเทียบนาฬิกากับแหล่งเวลาเดียวกัน ทำให้เรียงเหตุการณ์ข้ามเครื่องได้ถูก ส่วน retention คือระยะเวลาที่เก็บล็อกไว้ก่อนลบทิ้ง ต้องนานพอจะสืบย้อนได้ เพราะคนร้ายหลายกลุ่มซุ่มอยู่ในระบบนานกว่าที่เราคิด และบางอุตสาหกรรมมีกฎหมายหรือข้อกำหนดบังคับระยะเวลาขั้นต่ำไว้ด้วย

04SIEM: รวมล็อกทุกที่มาคิดทีเดียว The SIEM pipeline

ปัญหาของล็อกคือมันกระจัดกระจาย ไฟร์วอลล์เขียนแบบหนึ่ง เซิร์ฟเวอร์ Linux เขียนอีกแบบ Windows ใช้หมายเลข คลาวด์ใช้ JSON และทั้งหมดอยู่คนละเครื่อง ถ้านักวิเคราะห์ต้องล็อกอินเข้าไปเปิดดูทีละที่ กว่าจะต่อจิ๊กซอว์ครบ คนร้ายก็กลับบ้านไปนอนแล้ว

เครื่องมือที่แก้ปัญหานี้เรียกว่า SIEM (Security Information and Event Management อ่านว่า “ซีม”) หน้าที่ของมันคือดูดล็อกจากทุกแหล่งมารวมไว้ที่เดียว แปลงให้พูดภาษาเดียวกัน แล้วคิดรวมกันว่ามีอะไรผิดปกติไหม ภาพข้างล่างคือเส้นทางของล็อกหนึ่งบรรทัด ตั้งแต่เกิดจนกลายเป็นแจ้งเตือนบนจอของฝน

มาดูทีละขั้นให้ชัดขึ้น การเก็บ (collect) ทำได้สองแบบหลัก คือติดตั้งเอเจนต์ (โปรแกรมเล็ก ๆ) บนเครื่องให้ส่งล็อกออกมา หรือให้อุปกรณ์อย่างไฟร์วอลล์ส่งล็อกผ่านโปรโตคอลมาตรฐานชื่อ syslog ส่วนบริการคลาวด์มักให้ดึงล็อกผ่าน API

การแปลงให้เป็นภาษาเดียวกัน (parse และ normalize) คือการแยกข้อความยาว ๆ ออกเป็นช่อง ๆ ตามแบบฟอร์มกลาง บรรทัด Failed password for root from 203.0.113.45 จาก Linux กับเหตุการณ์ 4625 จาก Windows หน้าตาต่างกันลิบ แต่หลังแปลงแล้วจะกลายเป็นเรื่องเดียวกัน คือ action=login result=fail พอเป็นแบบนี้ กฎข้อเดียวก็ใช้ได้กับทุกระบบ

การเติมบริบท (enrich) เหมือนพนักงานสอบสวนที่เปิดแฟ้มประวัติประกอบคำให้การ ใส่ข้อมูลว่า IP นี้อยู่ประเทศไหน เป็นของผู้ให้บริการคลาวด์หรือเน็ตบ้าน เครื่องนี้เป็นของแผนกไหน สำคัญแค่ไหน และตรงกับรายการภัยที่รู้จักหรือเปล่า

การจับคู่ (correlate) คือจุดที่ SIEM ฉลาดกว่ากองล็อกธรรมดา เหตุการณ์ชิ้นเดียวมักไม่มีความหมาย แต่พอเอามาเรียงต่อกันจะเห็นเรื่องราว เช่น ล็อกอินล้มเหลวจากคลาวด์ ตามด้วยล็อกอินสำเร็จ ตามด้วยการตั้งกฎส่งต่ออีเมลอัตโนมัติไปข้างนอก สามบรรทัดจากสามที่ รวมกันแล้วคือภาพของบัญชีที่ถูกยึด

ในตลาดมี SIEM ให้เลือกหลายเจ้า ทั้งแบบเสียเงินและแบบโอเพนซอร์ส ถ้าอยากลองเล่นเองที่บ้าน ซอฟต์แวร์โอเพนซอร์สอย่าง Wazuh หรือ Elastic Stack ติดตั้งในเครื่องเสมือนได้ แล้วลองส่งล็อกจากคอมพิวเตอร์ของตัวเองเข้าไปดู จะเข้าใจท่อนี้ได้เร็วกว่าอ่านตำราสิบเล่ม

ศัพท์น่ารู้: Correlation และ Enrichment

Correlation คือการเชื่อมเหตุการณ์หลายชิ้นจากหลายแหล่งเข้าด้วยกันตามกฎหรือช่วงเวลา เพื่อดูเรื่องราวทั้งหมด ส่วน enrichment คือการแปะข้อมูลประกอบ เช่น ประเทศของ IP เจ้าของเครื่อง หรือผลเทียบกับข่าวกรองภัย ลงในเหตุการณ์ เพื่อให้คนอ่านไม่ต้องไปค้นเอง

05เขียนกฎตรวจจับข้อแรก Writing a detection rule

กลับไปที่แจ้งเตือนของฝน มันไม่ได้เกิดขึ้นเอง มีคนเขียนกฎไว้ล่วงหน้าว่า “ถ้าเห็นแบบนี้ ให้ปลุกคน” ลองเขียนกฎนั้นด้วยภาษาไทยธรรมดาก่อน ไม่ต้องรู้ภาษาโปรแกรมเลย

“ถ้าบัญชีไหนล็อกอินผิดติดกันหลายครั้งในเวลาสั้น ๆ แล้วจู่ ๆ ก็เข้าได้ จากประเทศที่บัญชีนั้นไม่เคยใช้ ให้แจ้งเตือนทันที”

ประโยคนี้มีสามเงื่อนไขซ่อนอยู่ และแต่ละเงื่อนไขมีเหตุผลของมัน ทีมตรวจจับจะเขียนให้เครื่องอ่านได้ประมาณนี้

rule:      brute_force_then_success_new_country
group_by:  user                          // นับแยกทีละบัญชี
when:
  ① count(login.result == "fail") >= 5  within 10m
  ② followed_by login.result == "success" within 10m
  ③ geo(src_ip).country not in history(user, 30d).countries
severity:  high
then:      alert(queue = "L1"), attach(login_history(user, 30d))
maps_to:   ATT&CK T1110 Brute Force · T1078 Valid Accounts

เงื่อนไข ① คือการนับความล้มเหลว เกณฑ์ “5 ครั้งใน 10 นาที” ตั้งไว้เพื่อไม่ให้คนพิมพ์ผิดครั้งสองครั้งตอนเช้าโดนแจ้งเตือน เงื่อนไข ② คือส่วนที่อันตรายจริง เพราะการเดาผิดเฉย ๆ ยังไม่เสียหายอะไร แต่การเดา ถูก แปลว่าประตูเปิดแล้ว เงื่อนไข ③ คือบริบทที่ช่วยตัดสัญญาณหลอก คนที่ลืมรหัสแล้วรีเซ็ตเองจากโต๊ะทำงานจะไม่ติดเงื่อนไขนี้

ทำไมนับ “ต่อบัญชี” ไม่ใช่ “ต่อ IP”

เพราะคนร้ายเปลี่ยน IP ได้ง่ายมาก ถ้าเรานับต่อ IP เขาแค่สลับเครื่องที่ใช้ยิงไปเรื่อย ๆ ตัวนับก็ไม่เคยถึงห้า แต่บัญชีเป้าหมายยังเป็นบัญชีเดิม การนับต่อบัญชีจึงจับได้แม้ IP จะเปลี่ยนทุกครั้ง ในทางกลับกัน ยังมีอีกเทคนิคที่เรียกว่า การพ่นรหัสผ่าน (password spraying) คือลองรหัสยอดนิยมรหัสเดียวกับบัญชีจำนวนมาก บัญชีละครั้งเดียว เพื่อไม่ให้บัญชีไหนถูกล็อก กฎข้างบนจับแบบนี้ไม่ได้ ต้องมีกฎคู่กันที่นับ “จำนวนบัญชีที่ล้มเหลวจากต้นทางเดียวกัน” แทน

บทเรียนข้อนี้สำคัญมาก: ไม่มีกฎข้อไหนจับได้ทุกอย่าง ทีมตรวจจับจึงคิดเป็นชุด แต่ละข้อปิดมุมที่ข้ออื่นมองไม่เห็น และผูกแต่ละข้อเข้ากับเทคนิคในกรอบ MITRE ATT&CK ที่เราเรียนใน CASE-013 เพื่อดูว่ายังมีเทคนิคไหนที่เราไม่มีกฎเฝ้าอยู่เลย

กฎที่ดีต้องถูกดูแลเหมือนโค้ด

ทีมที่ทำงานเป็นระบบจะเก็บกฎไว้ในระบบควบคุมเวอร์ชันแบบเดียวกับโปรแกรมเมอร์ เขียนทดสอบด้วยล็อกตัวอย่างทั้งแบบที่ต้องแจ้งและไม่ต้องแจ้ง และจดว่าใครแก้อะไรเมื่อไร แนวทางนี้เรียกว่า detection-as-code นอกจากนี้ยังมีรูปแบบกลางชื่อ Sigma ที่ให้เขียนกฎครั้งเดียว แล้วแปลงไปใช้กับ SIEM หลายยี่ห้อได้ ชุมชนนักป้องกันทั่วโลกแบ่งปันกฎกันผ่านรูปแบบนี้

เมื่อกฎดัง L1 ทำอะไร

1. เช็กบริบทก่อนตกใจ

   บัญชีนี้ลาพักร้อนหรือเดินทางไหม ใช้ VPN ของบริษัทอยู่หรือเปล่า IP นี้เป็นของผู้ให้บริการคลาวด์ที่คนร้ายชอบเช่าไหม

2. ดูว่าหลังล็อกอินทำอะไร

   เปิดอีเมลกี่ฉบับ ตั้งกฎส่งต่ออีเมลไหม ดาวน์โหลดไฟล์หรือเปลี่ยนเบอร์โทรสำหรับกู้บัญชีหรือเปล่า

3. ติดต่อเจ้าของบัญชีผ่านช่องทางที่รู้จัก

   โทรเบอร์ที่อยู่ในระบบพนักงาน ไม่ใช่ตอบกลับอีเมลจากบัญชีที่อาจถูกยึดไปแล้ว

4. ถ้ายังไม่ชัด ให้ตัดก่อน แล้วค่อยถาม

   สั่งออกจากระบบทุกเซสชัน บังคับเปลี่ยนรหัส และยกระดับให้ L2 การทำให้คุณนิดาเสียเวลาสิบนาทีตอนเช้า ถูกกว่าการปล่อยให้คนร้ายอ่านอีเมลไปจนถึงเช้ามาก

06แจ้งเตือนจริง แจ้งเตือนหลอก True & false positives

ทุกครั้งที่กฎทำงาน มีผลลัพธ์ได้แค่สี่แบบ ขึ้นอยู่กับว่า “ระบบแจ้งไหม” และ “มีการโจมตีจริงไหม” ตารางสี่ช่องนี้ดูง่าย แต่เป็นหัวใจของการออกแบบการตรวจจับทั้งหมด

คนไทยรู้จักวงจรนี้ดีจากนิทานอีสปเรื่องเด็กเลี้ยงแกะ เด็กตะโกนว่าหมาป่ามาจนชาวบ้านเลิกเชื่อ วันที่หมาป่ามาจริงจึงไม่มีใครวิ่งไปช่วย ในห้อง SOC อาการนี้มีชื่อเรียกว่า ความล้าจากแจ้งเตือน (alert fatigue) นักวิเคราะห์ที่ต้องปิดแจ้งเตือนหลอกวันละหลายร้อยเรื่อง สมองจะเริ่มทำงานแบบอัตโนมัติ กดปิด ๆ ๆ จนเผลอปิดเรื่องจริงไปด้วยโดยไม่รู้ตัว

ทำไมแจ้งเตือนหลอกถึงเยอะนัก? เพราะในระบบจริง เหตุการณ์ปกติมีมากกว่าการโจมตีหลายเท่าตัวนัก สมมุติกฎข้อหนึ่งแม่นมาก พลาดแค่หนึ่งครั้งในพันครั้ง แต่ถ้าวันหนึ่งมีการล็อกอินปกติหลายแสนครั้ง แค่ส่วนที่พลาดก็กลายเป็นแจ้งเตือนหลอกหลายร้อยเรื่องแล้ว ในขณะที่การโจมตีจริงอาจมีแค่เรื่องเดียว นักสถิติเรียกปรากฏการณ์นี้ว่าการมองข้ามอัตราพื้นฐาน (base rate) และมันคือเหตุผลที่กฎดี ๆ ต้องมีเงื่อนไขบริบทแบบข้อ ③ เสมอ

ลดเสียงรบกวนได้อย่างไร

• ปรับเกณฑ์และเพิ่มบริบท เช่น ยกเว้น IP ทางออกของ VPN บริษัท หรือดูประวัติของบัญชีนั้นประกอบ
• รวมแจ้งเตือนซ้ำเป็นเรื่องเดียว เหตุการณ์เดียวกันจากสิบเครื่อง ควรเป็นหนึ่งเคส ไม่ใช่สิบเคส
• ให้คะแนนความเสี่ยง เหตุการณ์เล็ก ๆ หลายอย่างบนบัญชีเดียวกันค่อย ๆ สะสมแต้ม จนเกินเส้นแล้วค่อยปลุกคน
• ให้เครื่องทำงานซ้ำ ๆ แทน การค้นข้อมูลประกอบแบบเดิมทุกครั้ง ให้ระบบอัตโนมัติทำก่อนคนเปิดดู
• วัดผลรายกฎ จดว่าแต่ละกฎแจ้งกี่ครั้ง เป็นของจริงกี่ครั้ง แล้วทบทวนเป็นรอบ ๆ

07EDR & XDR: ตาที่อยู่บนเครื่อง Endpoint detection & response

โปรแกรมแอนติไวรัสรุ่นเก่าทำงานเหมือนตำรวจที่ถือแฟ้มรูปผู้ต้องหา ใครหน้าตรงกับรูปในแฟ้มก็จับ ใครไม่ตรงก็ปล่อยผ่าน วิธีนี้เรียกว่าการจับด้วยลายเซ็น (signature) ใช้ได้ดีกับมัลแวร์ที่รู้จักแล้ว แต่แพ้ราบคาบกับของใหม่ หรือคนร้ายที่ไม่ใช้มัลแวร์เลย และใช้เครื่องมือที่มีอยู่แล้วในเครื่องแทน

EDR (Endpoint Detection and Response) คิดต่างออกไป แทนที่จะดูแค่หน้าตาไฟล์ มันบันทึก พฤติกรรม ทุกอย่างบนเครื่อง ใครเปิดโปรแกรมอะไร โปรแกรมนั้นเปิดโปรแกรมอะไรต่อ แก้ไฟล์ไหน ต่อเน็ตไปที่ใด แล้วส่งบันทึกเหล่านี้ขึ้นไปให้วิเคราะห์ ลองดูตัวอย่าง “ต้นไม้ของโปรแกรม” (process tree) ที่ EDR เห็น

explorer.exe
 └─ WINWORD.EXE  "ใบแจ้งหนี้_ตุลาคม.docm"
     └─ powershell.exe  -EncodedCommand (ข้อความเข้ารหัสยาวเหยียด)
         └─ เชื่อมต่อออก → 198.51.100.77:443   // IP ที่ไม่เคยเห็นมาก่อน

ทีละบรรทัดดูไม่ผิดอะไร Word เป็นโปรแกรมปกติ PowerShell เป็นเครื่องมือที่ผู้ดูแลระบบใช้ทุกวัน แต่ ความสัมพันธ์พ่อลูก ต่างหากที่ผิดสังเกต พนักงานบัญชีเปิดเอกสาร Word แล้วเอกสารนั้นสั่งเปิด PowerShell พร้อมคำสั่งที่ถูกซ่อนไว้ แล้วต่อออกไปหาเครื่องแปลกหน้าข้างนอก ห่วงโซ่แบบนี้แทบไม่มีเหตุผลปกติให้เกิด EDR จึงจับได้ แม้ไฟล์นั้นจะเป็นมัลแวร์ตัวใหม่ที่ไม่เคยมีใครเห็นมาก่อน

ตัว R ใน EDR คือ Response หมายถึงลงมือได้ด้วย ฟีเจอร์ที่ทีมรับมือเหตุรักที่สุดคือ การกักเครื่อง (host isolation) สั่งจากหน้าจอให้เครื่องที่ติดตัดขาดจากเครือข่ายทันที เหลือไว้แค่ช่องทางคุยกับ EDR เอง ทีมจึงยังสืบต่อได้ ขณะที่มัลแวร์ลามไปเครื่องอื่นไม่ได้แล้ว เหมือนกักตัวผู้ป่วยไว้ในห้องแยก แต่หมอยังเข้าไปตรวจได้

ส่วน XDR (Extended Detection and Response) คือการขยายแนวคิดเดียวกันออกไปนอกเครื่อง เอาข้อมูลจากเครื่องพนักงาน อีเมล ระบบยืนยันตัวตน คลาวด์ และเครือข่าย มาวิเคราะห์ด้วยกันในที่เดียว เพื่อเห็นการโจมตีที่กระโดดข้ามระบบ เช่น อีเมลหลอก → เครื่องติด → บัญชีถูกใช้บนคลาวด์ ได้เป็นเรื่องเดียว

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

08ข่าวกรองภัย ร่องรอย & การล่าภัย Threat intel, IOCs & hunting

SOC ที่ดีไม่ได้รอให้โดนก่อนแล้วค่อยเรียน แต่ฟังข่าวจากคนอื่นด้วย ข่าวกรองภัยคุกคาม (threat intelligence) คือความรู้ว่าใครกำลังโจมตีใคร ด้วยวิธีไหน และทิ้งร่องรอยอะไรไว้ แบ่งได้คร่าว ๆ เป็นสามระดับ ระดับกลยุทธ์สำหรับผู้บริหาร (กลุ่มไหนเล็งอุตสาหกรรมเรา) ระดับปฏิบัติการสำหรับทีมป้องกัน (เขาทำงานเป็นขั้นอย่างไร) และระดับเทคนิคที่ป้อนเข้าเครื่องมือได้ตรง ๆ

ข่าวกรองระดับเทคนิคมักมาในรูป ร่องรอยการบุกรุก (Indicator of Compromise: IOC) เช่น ค่าแฮชของไฟล์มัลแวร์ หมายเลข IP หรือชื่อโดเมนที่คนร้ายใช้ เอามาเทียบกับล็อกของเราได้ทันทีว่าเคยมีเครื่องไหนติดต่อกับสิ่งเหล่านี้ไหม หน่วยงานอย่าง ThaiCERT ก็เผยแพร่ข่าวเตือนภัยและร่องรอยแบบนี้ให้องค์กรไทยนำไปใช้ ส่วนระหว่างองค์กรด้วยกัน มีรูปแบบมาตรฐานสำหรับแลกเปลี่ยนชื่อ STIX และช่องทางส่งชื่อ TAXII

แต่ร่องรอยแต่ละแบบมีค่าไม่เท่ากัน นักวิจัยชื่อ David J. Bianco อธิบายเรื่องนี้ไว้ด้วยภาพที่คนในวงการใช้กันทั่วโลก เรียกว่า พีระมิดแห่งความเจ็บปวด (Pyramid of Pain)

ลองนึกถึงตำรวจที่ตามจับแก๊งลักรถ ถ้าจำแค่ทะเบียนรถที่แก๊งใช้ แก๊งก็แค่เปลี่ยนป้าย (นี่คือ IP และแฮช) แต่ถ้าตำรวจรู้ว่าแก๊งนี้ชอบลงมือตอนตีสี่ ในลานจอดห้าง โดยใช้วิธีเดิมทุกครั้ง (นี่คือ TTP: tactics, techniques and procedures) แก๊งต้องเปลี่ยนวิธีทำงานทั้งหมด ซึ่งยากและแพงกว่ามาก กฎแบบ “Word เปิด PowerShell แล้วต่อเน็ตออก” ในหัวข้อที่แล้ว คือการตรวจจับที่ระดับพฤติกรรม ส่วนการบล็อก IP หนึ่งตัวคือการตรวจจับที่ฐานพีระมิด ทั้งสองแบบมีประโยชน์ แต่ทีมที่เก่งจะพยายามไต่ขึ้นไปให้สูงที่สุดเสมอ

ศัพท์น่ารู้: IOC กับ TTP

IOC (Indicator of Compromise) คือ “หลักฐานว่าเคยมีคนบุกเข้ามา” เช่น แฮช IP โดเมน ใช้ค้นหาได้เร็วแต่หมดอายุไว ส่วน TTP (Tactics, Techniques and Procedures) คือ “วิธีทำงานของคนร้าย” เช่น ชอบใช้บัญชีที่ขโมยมาล็อกอินผ่าน VPN ตอนดึก จับยากกว่า แต่ใช้ได้นานกว่ามาก กรอบ MITRE ATT&CK ก็คือคลังของ TTP นั่นเอง

การล่าภัย: ไม่รอให้สัญญาณดัง

กฎตรวจจับทุกข้อมีข้อจำกัดเดียวกัน คือจับได้เฉพาะสิ่งที่เราคิดไว้ล่วงหน้า การล่าภัย (threat hunting) จึงเริ่มจากสมมติฐานกลับหัวว่า “สมมุติคนร้ายอยู่ในระบบเราแล้ว และหลบกฎทุกข้อได้ เขาจะทิ้งรอยอะไรไว้” แล้วออกค้นในข้อมูลที่เก็บไว้ ทั้งที่ยังไม่มีแจ้งเตือนสักอัน

1. ตั้งสมมติฐาน

   เช่น “ถ้ามีบัญชีถูกขโมย น่าจะมีบัญชีที่ล็อกอินจากสองประเทศห่างกันมากภายในหนึ่งชั่วโมง” มักได้แรงบันดาลใจจากข่าวกรองภัยหรือเทคนิคใน ATT&CK

2. ค้นข้อมูล

   เขียนคำค้นใน SIEM หรือ EDR ย้อนหลังหลายสัปดาห์ แล้วดูว่ามีอะไรตรงกับสมมติฐานบ้าง

3. แยกของปกติออก

   ส่วนใหญ่จะเจอเรื่องที่มีคำอธิบาย เช่น พนักงานใช้ VPN ส่วนตัว จดไว้ว่าอะไรคือสิ่งปกติของที่นี่ ความรู้นี้มีค่ามากในวันข้างหน้า

4. เปลี่ยนสิ่งที่ค้นได้ ให้เป็นกฎอัตโนมัติ

   ล่าเจอหรือไม่เจอก็ได้ประโยชน์ ถ้าคำค้นนั้นได้ผลดี ก็เอาไปเขียนเป็นกฎ ครั้งหน้าเครื่องจะจับให้เองโดยไม่ต้องรอคนออกล่า

09SOAR & ตัวชี้วัดของ SOC Automation & metrics

ทุกครั้งที่แจ้งเตือนแบบของฝนเด้งขึ้นมา นักวิเคราะห์ต้องทำสิ่งเดิมซ้ำ ๆ เปิดประวัติล็อกอิน เช็ก IP กับฐานข่าวกรอง ดูว่าบัญชีอยู่แผนกไหน เปิดตั๋วงาน งานแบบนี้กินเวลาเรื่องละหลายนาที และน่าเบื่อจนคนพลาดได้ง่าย SOAR (Security Orchestration, Automation and Response) คือเครื่องมือที่ให้เราเขียนขั้นตอนพวกนี้เป็นสูตร แล้วให้เครื่องทำแทน

on_alert: brute_force_then_success_new_country
steps:
  1. enrich   → ประเทศ / เจ้าของ IP / ประวัติ 30 วัน / แผนกของผู้ใช้
  2. check    → บัญชีนี้มีการตั้งกฎส่งต่ออีเมลใหม่ไหม
  3. notify   → ส่งข้อความหาเจ้าของบัญชีผ่านแอปของบริษัท: “นี่คุณใช่ไหม”
  4. wait     → รอคำตอบ 10 นาที
  5. if "ไม่ใช่" or ไม่ตอบ:
       require_approval(L1)       // คนกดยืนยันก่อนทำสิ่งที่กระทบงาน
       revoke_sessions(user) · force_password_reset(user)
  6. ticket   → เปิดเคส แนบผลทุกขั้นไว้ให้คนอ่านต่อ

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

วัดว่า SOC เก่งแค่ไหน

ตัวชี้วัดที่คนพูดถึงมากที่สุดมีสองตัว MTTD (Mean Time To Detect) คือเวลาเฉลี่ยตั้งแต่คนร้ายเริ่มลงมือ จนเราตรวจพบ และ MTTR (Mean Time To Respond) คือเวลาเฉลี่ยตั้งแต่ตรวจพบ จนหยุดความเสียหายได้ บางองค์กรใช้ตัว R ในความหมาย Recover คือนับไปจนกู้ระบบเสร็จ เวลาเทียบตัวเลขกับที่อื่นจึงต้องถามก่อนเสมอว่านับจากไหนถึงไหน ส่วนช่วงเวลาที่คนร้ายอยู่ในระบบโดยไม่มีใครรู้ เรียกว่า เวลาซุ่ม (dwell time)

ตัวชี้วัดมีประโยชน์ แต่ก็มีกับดัก ถ้าหัวหน้าวัดแค่ “ปิดเคสได้เร็วแค่ไหน” ทีมจะเรียนรู้ที่จะปิดเร็ว ไม่ใช่ปิดถูก ทีมที่ฉลาดจึงวัดหลายด้านคู่กัน เช่น สัดส่วนแจ้งเตือนที่เป็นของจริงของแต่ละกฎ จำนวนเทคนิคใน ATT&CK ที่มีกฎเฝ้าอยู่ และจำนวนกฎใหม่ที่เกิดจากการล่าภัยหรือจากบทเรียนของเหตุการณ์จริง

10ด้านที่เป็นมนุษย์ของ SOC The human side

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

นี่คือด้านที่ตำราเครื่องมือไม่ค่อยเล่า งาน SOC เป็นงานของมนุษย์อย่างมาก การทำงานเป็นกะทำให้นอนไม่เป็นเวลา งานที่ซ้ำกันทุกวันทำให้เหนื่อยล้า และแรงกดดันที่ “ห้ามพลาดแม้แต่เรื่องเดียว” ทำให้หลายคนหมดไฟ SOC ที่อยู่ได้นานจึงดูแลคนเท่ากับดูแลเครื่องมือ

• ส่งต่อกะอย่างเป็นระบบ จดว่ามีเคสไหนค้าง สงสัยอะไรอยู่ คนกะเช้าจะได้ไม่ต้องเริ่มจากศูนย์
• ยกระดับผิด ดีกว่าเงียบ ทีมต้องทำให้ทุกคนรู้สึกปลอดภัยที่จะยกเรื่องขึ้นไป แม้สุดท้ายจะไม่ใช่อะไร ถ้าคนกลัวโดนดุเพราะเตือนผิด เขาจะเลือกเงียบ และนั่นคือจุดที่ของจริงหลุดรอด
• ให้เครื่องรับงานซ้ำ ๆ เก็บพลังสมองของคนไว้กับงานที่ต้องคิดจริง
• หมุนงานและให้เวลาเรียนรู้ ให้คนจาก L1 ได้ลองล่าภัยหรือเขียนกฎบ้าง ช่วยทั้งเรื่องฝีมือและกำลังใจ

ถ้าอยากเดินสายนี้ เริ่มจากตรงไหน

พื้นฐานที่ช่วยมากที่สุดคือความเข้าใจเครือข่าย (บท CASE-007 และ CASE-011) และการใช้งาน Linux กับ Windows ในระดับที่อ่านล็อกของมันออก จากนั้นลองตั้งห้องแล็บเล็ก ๆ ในเครื่องตัวเอง ติดตั้ง SIEM โอเพนซอร์ส ส่งล็อกจากเครื่องเสมือนเข้าไป แล้วลองเขียนกฎข้อแรกด้วยตัวเอง โจทย์ฝึกแบบ CTF ฝั่งป้องกัน (blue team) ที่ให้สืบจากล็อกก็เป็นสนามซ้อมที่ดีมาก เส้นทางอาชีพมักเริ่มจาก L1 แล้วแตกแขนงไปเป็นนักรับมือเหตุ นักล่าภัย วิศวกรตรวจจับ หรือนักวิเคราะห์ข่าวกรอง

SOC ส่วนตัวในมือถือของเรา

ไม่ต้องทำงานในห้อง SOC ก็ใช้หลักคิดเดียวกันได้ บริการใหญ่อย่าง Google และ Facebook มีหน้ารวมอุปกรณ์ที่ล็อกอินบัญชีเราอยู่ และส่งแจ้งเตือนเมื่อมีการล็อกอินจากเครื่องใหม่ นั่นคือ “แจ้งเตือน” ส่วนตัวของเรา

1. อย่าปิดแจ้งเตือนความปลอดภัย

   อีเมลหรือข้อความว่า “มีการล็อกอินจากอุปกรณ์ใหม่” คือสัญญาณที่มีค่าที่สุด อ่านทุกครั้ง อย่าตั้งกรองทิ้ง

2. เปิดดูรายการอุปกรณ์เดือนละครั้ง

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

3. ถ้าเห็นสิ่งแปลก ให้ตัดก่อน

   ออกจากระบบทุกเครื่อง เปลี่ยนรหัสผ่าน และเปิดการยืนยันสองชั้น แบบเดียวกับที่ฝนทำกับบัญชีของคุณนิดา

11สรุปให้จำ Recap

ถ้าจำได้แค่หกข้อจากบทนี้ ให้จำหกข้อนี้

• SOC มองให้เห็น จับให้ได้ ส่งต่อให้เร็ว เครื่องจักรกรองก่อน คนตัดสินใจในจุดที่ต้องใช้วิจารณญาณ
• ล็อกที่ดีตอบได้ว่าใคร ทำอะไร ที่ไหน เมื่อไร อย่างไร ต้องซิงก์เวลา และส่งออกจากเครื่องไปเก็บที่ศูนย์กลางทันที
• SIEM เก็บ แปลง เติมบริบท และจับคู่ หลักฐานหลายชิ้นที่ชี้ไปทางเดียวกัน มีน้ำหนักกว่าชิ้นเดียวที่ดูน่ากลัว
• แจ้งเตือนหลอกที่มากเกินไปคือภัยจริง เพราะมันผลักของจริงให้หลุดรอด วัดและปรับกฎทุกข้อเป็นรอบ ๆ
• ไต่พีระมิดขึ้นไป จับที่พฤติกรรม (TTP) ทำให้คนร้ายเจ็บกว่าการบล็อก IP หรือแฮช และอย่ารอแจ้งเตือน ออกล่าภัยด้วย
• ยิ่งตรวจพบเร็ว ยิ่งเสียหายน้อย ลด MTTD ด้วยกฎที่ดีและระบบอัตโนมัติ แต่ให้คนยืนยันก่อนลงมือขั้นที่กระทบงาน

ลองทบทวนดู