รู้ได้ยังไงว่า Detection ครอบคลุม Ransomware พอหรือยัง
coverage 100% ไม่ได้แปลว่าจับ ransomware ได้จริง วิธีวัด detection coverage ด้วย MITRE ATT&CK แยกกฎที่ทำงานจริงจากกฎที่รออยู่ และหา blind spot ให้เจอก่อน
รู้ได้ยังไงว่า Detection ครอบคลุม Ransomware พอหรือยัง
เวลาผู้บริหารถามว่า "ถ้ามี ransomware เข้ามาวันนี้ เราจับได้ไหม" คำตอบที่ได้ยินบ่อยที่สุดคือ "จับได้ครับ เรามี EDR มี SIEM มี firewall ครบ"
นั่นไม่ใช่คำตอบ นั่นคือรายการของที่ซื้อมา
คำถามที่ตอบยากกว่ามากคือ ครอบคลุมแค่ไหน แล้ววัดจากอะไร เพราะ "ครบ" ในความหมายของคนจัดซื้อ กับ "ครบ" ในความหมายของคนที่ต้องนั่งดูหน้าจอตอนตีสาม เป็นคนละเรื่องกัน
ทำไมเปอร์เซ็นต์ coverage ถึงหลอกตา
MITRE ATT&CK เป็นวิธีที่ตรงไปตรงมาที่สุดในการตอบคำถามนี้ เพราะมันแปลง "เราป้องกันดีไหม" ให้กลายเป็นตารางที่กาถูกกาผิดได้ (ถ้ายังไม่คุ้นกับ ATT&CK ว่าคืออะไร อ่าน MITRE ATT&CK คืออะไร ก่อนได้)
แต่พอเอาไปทำเป็นตัวเลขเปอร์เซ็นต์เมื่อไหร่ ตัวเลขนั้นก็หลอกได้ทันที และหลอกได้อย่างน้อยสามแบบ
กับดักที่ 1 — มีกฎ ไม่เท่ากับกฎกำลังทำงาน
นี่คือกับดักที่เจอบ่อยที่สุด SIEM ส่วนใหญ่มี rule catalog ติดมาให้จำนวนมากตั้งแต่วันแรก และหน้ารายงานก็นับกฎเหล่านั้นทั้งหมดว่าเป็น "coverage"
ปัญหาคือกฎจะยิงได้ก็ต่อเมื่อมี log ป้อนเข้ามา กฎที่ต้องใช้ log จาก endpoint แต่ EDR ยังไม่ได้ต่อเข้า SIEM ก็คือกฎที่เขียนไว้สวยๆ แล้วนอนอยู่เฉยๆ มันนับเป็น coverage บนกระดาษได้ แต่ไม่ได้ปกป้องอะไรเลย
กับดักที่ 2 — นับที่ระดับ technique ทำให้ดูดีเกินจริง
ATT&CK นับเป็น technique แต่ในโลกจริงแต่ละ technique มีวิธีทำได้หลายแบบ
ยกตัวอย่างการปิดระบบป้องกันก่อนเข้ารหัสไฟล์ — จะ stop service ก็ได้ จะแก้ registry ก็ได้ จะใช้ไดรเวอร์ที่มีลายเซ็นถูกต้องแต่มีช่องโหว่มาปิด EDR ก็ได้ ถ้ากฎของคุณจับได้แค่วิธีแรก ตารางก็ยังขึ้นว่า technique นี้ "covered" อยู่ดี
เปอร์เซ็นต์ไม่ได้โกหก แต่มันหยาบกว่าที่คนอ่านรายงานเข้าใจ
กับดักที่ 3 — ครอบคลุมทั้ง matrix ไม่เท่ากับครอบคลุม ransomware
ATT&CK มี technique เยอะมาก และ ransomware ก็ไม่ได้ใช้ทั้งหมด การไล่กาให้เขียวทั้งตารางจึงเป็นการกระจายแรงแบบไม่มีน้ำหนัก
สิ่งที่ควรทำแทนคือเลือกเส้นทางที่ ransomware เดินจริง แล้ววัดเฉพาะเส้นนั้นให้ลึก — เข้ามาได้ยังไง ยกระดับสิทธิ์ยังไง เดินไปเครื่องอื่นยังไง ปิดระบบป้องกันยังไง แล้วค่อยเข้ารหัส ถ้าเส้นนี้มีรูตรงกลางแม้แค่จุดเดียว ตัวเลขรวมทั้ง matrix ก็ช่วยอะไรไม่ได้
แล้วหน้าจอที่ใช้วัด มันบอกอะไรได้บ้าง
หน้า Detection Coverage ใน zcrSIEM ไม่ได้ตอบว่า "ปลอดภัยกี่เปอร์เซ็นต์" แต่บังคับให้กฎทุกข้อต้องอยู่ในสถานะใดสถานะหนึ่งจากสามแบบนี้
| สถานะกฎ | หมายความว่า |
|---|
| Live | มี log source ป้อนข้อมูลเข้ามาแล้ว กฎข้อนี้ยิงอยู่จริงวันนี้ |
| Ready | เขียนไว้แล้ว แต่ยังรอ source ที่วางแผนจะต่อเข้ามา จึงยังไม่ยิง |
| Uncovered | ไม่มี source ตัวไหนที่วางแผนไว้ ป้อนข้อมูลให้กฎข้อนี้ได้เลย |
แค่แยกสามช่องนี้ก็ปิดกับดักที่ 1 ได้แล้ว เพราะมันแยก "มีกฎ" ออกเป็น "ยิงอยู่" กับ "ยังไม่ยิง" ตั้งแต่บรรทัดแรก
การ์ด ATT&CK ข้างกันใช้ตรรกะเดียวกัน มันบอกทั้งจำนวน technique ที่มีกฎรองรับ และจำนวนที่กฎยิงอยู่จริงบน log ที่ ingest เข้ามาวันนี้ สองเลขนี้ไม่เท่ากันเมื่อไหร่ ส่วนต่างก็คือ technique ที่ เขียวบนกระดาษ แต่มืดของจริง และถ้ารายงานผู้บริหารด้วยเปอร์เซ็นต์ตัวเดียว คุณก็กลบส่วนต่างนั้นไปด้วยมือตัวเอง
อีกอย่างที่ต้องดูให้ขาดคือฐานของเปอร์เซ็นต์ มันคิดจาก base technique ที่หน้านี้นับอยู่ ไม่ใช่ทุก technique ใน ATT&CK ดังนั้นต่อให้ขึ้น 100% ก็ไม่ได้แปลว่าครอบคลุมทั้ง matrix
กราฟ MITRE ATT&CK coverage by tactic ทางขวาแยกสองเรื่องนี้ออกจากกันด้วยสี แถบเข้มคือส่วนที่ยิงอยู่จริงบน log ปัจจุบัน แถบอ่อนคือส่วนที่เหลือ พอมองเป็นแถบเรียงตามแท็กติกแล้วเห็นชัดกว่าตัวเลขเยอะ
ลองอ่านแถบพวกนี้เป็นประโยคดู: ถ้าแถบ Lateral Movement อ่อนกว่าแถบ Initial Access แปลว่าเรามีโอกาสเห็นตอนคนร้ายเดินไปเครื่องอื่นน้อยกว่าตอนเขาเข้ามาครั้งแรก — ซึ่งสำหรับ ransomware คือช่วงที่แพงที่สุดที่จะพลาด
แล้วฝั่ง log source ล่ะ
พาเนล Coverage by log source ตอบอีกครึ่งหนึ่งของคำถาม มันไล่ทีละ source ว่าถ้าตัวนี้ป้อน log เข้ามา จะปลุกกฎข้อไหนให้ทำงานบ้าง แล้วติดป้าย Ingested ให้ตัวที่ส่ง log เข้ามาจริงแล้ว แยกออกจากตัวที่ยังเป็นแค่แผน
ส่วนชื่อที่อยู่ใน catalog ของ zcrSIEM ก็คุ้นกันดี ทั้ง FortiGate, Palo Alto, Cisco ASA, Windows Active Directory, CrowdStrike Falcon, SentinelOne Singularity, Sangfor NGAF, Sangfor IAG ไปจนถึง Mail Security Gateway
ข้อดีอยู่ตรงที่มันเป็นรายบรรทัด ไม่ใช่ยอดรวม สมมติวันนี้ CrowdStrike Falcon หยุดส่ง log — agent พัง คนแก้ policy ผิด ใบอนุญาตหมดอายุ — กฎทุกข้อที่ผูกไว้กับมันจะเงียบลงพร้อมกัน และต่างจาก alert ที่ส่งเสียงดัง ความเงียบไม่เคยประกาศตัวเอง การเฝ้าดูว่า "log หายไปหรือเปล่า" เป็นการตั้งค่าอีกชุดหนึ่งต่างหาก อย่าเหมาว่ามันเปิดอยู่แล้ว
การเห็นว่า source แต่ละตัวแบกกฎไว้กี่ข้อจึงสำคัญกว่าที่คิด มันเปลี่ยน "log source ล่ม" จากปัญหา IT ธรรมดา ให้กลายเป็นตัวเลขความเสี่ยงที่อธิบายให้คนไม่ใช่สายเทคนิคฟังได้ทันที — และนี่คือเหตุผลว่าทำไม การต่อ log จาก EDR เข้า SIEM ให้ถูกวิธี ถึงเป็นงานที่คุ้มค่าที่จะทำให้เสร็จก่อนไปซื้อกฎเพิ่ม
วัดจริงยังไง — เริ่มจากสี่คำถาม
ไม่ต้องทำโปรเจกต์ใหญ่ ลองตอบสี่ข้อนี้ให้ได้ก่อน
1. ตอนนี้มีกฎกี่ข้อที่ทำงานอยู่จริง ไม่ใช่กี่ข้อที่มีอยู่ในระบบ ถ้าตัวเลขสองตัวนี้ห่างกันมาก ส่วนต่างคือหนี้ที่ยังไม่ได้จ่าย
2. ถ้าตัด ransomware เป็นขั้นๆ แต่ละขั้นมี feed อะไรรองรับอยู่ ทำเป็นใบเช็กสต็อกง่ายๆ แบบนี้
| ขั้นของ ransomware | feed ที่ต้องมี ถึงจะมีโอกาสเห็นขั้นนี้ | ตอนนี้ ingest อยู่จริงไหม |
|---|
| เข้ามาครั้งแรก | mail gateway, firewall/VPN ขอบเครือข่าย, proxy | ☐ |
| ขโมยและยกระดับสิทธิ์ | authentication log จาก AD | ☐ |
| สำรวจและเดินไปเครื่องอื่น | endpoint (EDR) + authentication | ☐ |
| ปิดระบบป้องกันและลบ backup | endpoint (EDR) | ☐ |
| เข้ารหัสไฟล์ | endpoint (EDR) | ☐ |
ขั้นไหนที่ตอบไม่ได้ว่า feed ตัวไหนจะทำให้เห็น หรือรู้ทั้งรู้ว่า feed นั้นยังไม่ได้ต่อเข้ามา — ขั้นนั้นคือ blind spot ตัวจริง ไม่ใช่ช่องว่างในตาราง ATT&CK
ส่วนคำถามว่ากฎแต่ละข้อควรมองหาอะไรในแต่ละขั้น มีเขียนไว้แล้วใน ตรวจจับ ransomware ด้วย SIEM และถ้าอยากเห็นภาพว่าเหตุการณ์ที่กระจัดกระจายมันต่อกันเป็นเส้นเดียวได้ยังไง ดูที่ อ่าน attack flow ด้วย MITRE ATT&CK
3. ถ้า log source ที่สำคัญที่สุดหายไปหนึ่งตัว จะเสียกฎกี่ข้อ ถ้าตอบไม่ได้ในสามสิบวินาที แปลว่ายังไม่มีใครวัดเรื่องนี้อยู่
4. เคยยิงทดสอบจริงครั้งสุดท้ายเมื่อไหร่ ข้อนี้สำคัญที่สุด และเป็นข้อที่หน้า dashboard ไหนก็ตอบแทนไม่ได้
สิ่งที่หน้า coverage บอกไม่ได้ (และไม่ควรแกล้งว่าบอกได้)
หน้าจอแบบนี้ตอบคำถามว่า "มีกฎไหม และกฎกำลังทำงานอยู่ไหม" ได้ดี แต่มีอีกอย่างน้อยสี่เรื่องที่มันตอบไม่ได้
มันไม่ได้บอกว่ากฎ tune ดีหรือเปล่า กฎที่ยิงวันละสองร้อยครั้งจนทีมปิดการแจ้งเตือนทิ้ง มีค่าเท่ากับไม่มีกฎ แต่บนหน้า coverage มันก็ยังนับเป็น live เหมือนกฎที่ดีที่สุด
มันไม่ได้บอกว่า log ที่เข้ามานั้น "ครบ" ไหม ป้าย Ingested บอกแค่ว่ามี log จาก source นั้นเข้ามา ไม่ได้รับประกันว่าเปิดครบทุกประเภท ไฟร์วอลล์ที่ส่งแค่ traffic log แต่ไม่ได้ส่ง IPS log ก็ยังขึ้นว่า Ingested เหมือนกัน — เรื่องนี้ต้องไปไล่ที่ config ของอุปกรณ์เอง ไม่มีทางลัด
มันไม่ได้พิสูจน์ว่าจับได้จริง ระหว่าง "มีกฎที่ควรจะจับได้" กับ "ยิงทดสอบแล้วจับได้จริง" มีระยะห่างที่ต้องเดินด้วยการทดสอบเท่านั้น ไม่ใช่ด้วยการอ่าน dashboard
มันไม่ได้บอกว่าจับได้ทันไหม coverage เป็นเรื่องของการ "เห็น" ส่วนการหยุดทันเป็นคนละปัญหา ซึ่งเป็นงานของฝั่ง automation และการซ้อมมือคนมากกว่างานของกฎ
พูดตรงๆ คือหน้า Detection Coverage ทำให้คุณเถียงกันด้วยข้อมูลได้ แทนที่จะเถียงกันด้วยความรู้สึก — แค่นั้นก็คุ้มแล้ว แต่มันไม่ใช่ใบรับรองว่าปลอดภัย และไม่มีเครื่องมือไหนออกใบรับรองนั้นให้ได้
สัญญาณว่าเรื่องนี้ใช่คุณ
- ตอบไม่ได้ทันทีว่าตอนนี้มีกฎกี่ข้อที่ทำงานอยู่จริง
- เพิ่งต่อ log source ใหม่เข้ามา แต่ไม่รู้ว่ามันเปิดกฎอะไรเพิ่มให้บ้าง
- เคยมี log source หยุดส่งข้อมูลหลายวันกว่าจะมีคนสังเกตเห็น
- รายงานผู้บริหารมีเปอร์เซ็นต์ coverage แต่ไม่มีใครอธิบายได้ว่านับจากฐานอะไร
- ไม่เคยยิงทดสอบว่ากฎฝั่ง ransomware ยิงจริงหรือเปล่า
เข้าข่ายสองข้อขึ้นไป งานที่คุ้มที่สุดคือการวัดของที่มีอยู่ให้ชัดก่อน ไม่ใช่การซื้อกฎหรือเครื่องมือเพิ่ม เพราะยังไม่รู้เลยว่าที่มีอยู่ทำงานอยู่กี่ข้อ
zcrSIEM ทำเรื่องนี้ยังไง
zcrSIEM แยก "กฎที่มี" ออกจาก "กฎที่ทำงานอยู่จริง" ให้เห็นในหน้าเดียว — Live / Ready / Uncovered บอกสถานะกฎ, coverage by log source บอกว่าถ้าเสีย source ไหนจะเสียกฎกี่ข้อ, กราฟ ATT&CK by tactic บอกว่ารูอยู่ตรงแท็กติกไหน และมีปุ่ม Create custom rule สำหรับเคสที่กฎสำเร็จรูปไม่ครอบคลุม
สิ่งที่มันไม่ได้ทำแทนคุณคือการตัดสินใจว่ารูไหนสำคัญพอที่จะแก้ก่อน — อันนั้นยังต้องใช้คนที่รู้จักธุรกิจตัวเอง
อยากรู้ว่าของที่มีอยู่ตอนนี้ครอบคลุมได้จริงแค่ไหน ดู แพ็กเกจและราคา และถ้าสนใจว่าจะไล่ล่าสิ่งที่กฎยังจับไม่ได้ยังไง อ่านต่อที่ AI threat hunting
ติดต่อทีมงาน
อยากรู้ว่า detection ที่ใช้อยู่ตอนนี้มีรูตรงไหนบ้าง คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย
แหล่งอ้างอิง
- MITRE ATT&CK, “Data Encrypted for Impact (T1486)” — นิยามเทคนิคและบริบทของ ransomware: https://attack.mitre.org/techniques/T1486/ (เข้าถึง 14 กันยายน 2026)
- หมายเหตุข้อมูล: ตัวอย่าง coverage และตัวเลขในบทความเป็น illustrative analysis ไม่ใช่ telemetry หรือผลทดสอบของลูกค้า