How-to: สร้าง OT Detection Lab ด้วย MITRE ATT&CK for ICS v20 — จาก Log ดิบสู่ Use Case แรกใน 5 ขั้นตอน

สัปดาห์ก่อนเราคุยกับวิศวกรของโรงงานประกอบชิ้นส่วนแห่งหนึ่งเรื่องระบบตรวจจับการโจมตี เขาพูดประโยคที่เราเจอบ่อยมาก: “เรามี SIEM แล้ว แต่ไม่รู้ว่าจะเขียน rule อะไรลงไป” นี่คือช่องว่างที่แท้จริงของ OT Security ในประเทศไทย — ไม่ใช่การขาดเครื่องมือ แต่คือการขาด “คำถามที่ถูกต้อง” ที่จะถามกับ log ที่มีอยู่

ข่าวดีคือเมื่อวันที่ 13 ตุลาคม 2026 MITRE ปล่อย ATT&CK v20 ซึ่งโดเมน ICS (Industrial Control Systems) ได้ข้อมูลใหม่ที่เป็นประโยชน์กับโรงงานไทยอย่างมาก: ตอนนี้มีถึง 106 Detection Strategies และ 302 Analytics พร้อมบริบทแพลตฟอร์มและ Asset ชัดเจน — แปลว่านี่คือจุดเริ่มต้นที่ดีที่สุดที่เคยมีมาสำหรับการสร้าง Use Case ตรวจจับการโจมตีที่เจาะจงกับระบบควบคุมของเราเอง

ขั้นที่ 1: เลือกเทคนิคที่ “เป็นไปได้จริง” กับโรงงานคุณ

ความผิดพลาดที่พบบ่อยที่สุดของทีมที่เพิ่งเริ่ม คือพยายามเขียน rule ครบทุก technique ในเมทริกซ์ 78 ข้อ — แล้วเลิกกลางทาง ให้เริ่มจาก 3-5 เทคนิคที่ตรงกับช่องทางที่โรงงานคุณมีจริง:

• ถ้ามีช่องทาง remote สำหรับผู้รับเหมา: T0886 Remote Services — ตรวจจับการเชื่อมต่อจาก IP ที่ไม่ใช่ของทีมภายใน
• ถ้า HMI เป็น Windows: T0853 Scripting — ตรวจ process ที่ไม่ควรมีบนเครื่อง Engineering
• ถ้าใช้ Modbus TCP: T0855 Unauthorized Command Message — ตรวจ Master ID ที่ไม่อยู่ใน whitelist
• ถ้ามี Setpoint สำคัญต่อคุณภาพผลิตภัณฑ์: T0831 Manipulation of Control — ตรวจการเปลี่ยนแปลงค่าที่ผิดจังหวะ

ขั้นที่ 2: ถามคำถามเดียวที่สำคัญ — “อะไรบอกเราว่ามันเกิดขึ้น?”

Detection Engineering ไม่ใช่ศาสตร์ของการเขียน rule แต่คือการแปลงพฤติกรรมที่เรากลัวให้เป็นสัญญาณที่ระบบมองเห็นได้ ตัวอย่างการแปลง:

ขั้นที่ 3: จัดหา Data Source ที่ถูกต้อง

โรงงานส่วนใหญ่มีข้อมูลมากกว่าที่คิด แต่กระจายอยู่ในที่ที่ไม่มีใครเก็บรวม: SPAN port ที่ต่อค้างไว้ตั้งแต่โครงการเก่า Syslog ที่ PLC ส่งมาแต่ไม่มีใครอ่าน และ log ของไฟร์วอลล์ที่หมุนทิ้งทุก 7 วัน การรวบรวมพวกนี้เข้าที่เดียว (แม้เป็นไฟล์รวมง่ายๆ) คือก้าวแรกที่คุ้มค่าที่สุด

ขั้นที่ 4: เขียน Rule และทดสอบด้วยตัวเอง

ก่อนเสียบ rule ลงระบบจริง ให้ทดสอบด้วย “การโจมตีตัวเอง” แบบควบคุมได้ — จากเครื่องทดสอบบนเครือข่ายเดียวกัน ลองส่ง Modbus write จาก IP ที่ไม่อยู่ใน whitelist ถ้า rule ดี มันต้องเตือนภายในไม่กี่วินาที ถ้าไม่เตือน แปลว่าต้องไล่ดูว่าสัญญาณหายไปตรงไหนของสายส่งข้อมูล

ขั้นที่ 5: ปรับ Threshold ให้เข้ากับจังหวะโรงงาน

rule ที่เตือนทุก 5 นาทีจะถูกปิดภายในสัปดาห์ ก่อนเปิดใช้งานจริง ให้เก็บข้อมูล 2-4 สัปดาห์เพื่อดู baseline ของโรงงาน: ช่วงเปลี่ยนกะมีการ login กี่ครั้ง ช่วงเปลี่ยน production run มีการเขียน Setpoint กี่ครั้ง ตัวเลขเหล่านี้คือเส้นแบ่งระหว่าง rule ที่คนเชื่อกับ rule ที่คนปิด

Honey Connection: ห้องแล็บจำลองของเราเอง

ก่อนส่งมอบระบบ monitoring ให้ลูกค้า Honey Corporation ทดสอบ Use Case ทุกข้อในห้องแล็บที่มี PLC จริง และเครือข่ายจำลองโรงงาน — เพราะเราเชื่อว่า rule ที่ไม่เคยถูกทดสอบกับการโจมตีจำลอง ไม่ควรถูกเสียบเข้ากับโรงงานจริง ประสบการณ์จากงานติดตั้งระบบ IoT ในภาคอาหารและห้องเย็นของเราสอนว่า สภาพแวดล้อมจริงมักแปลกกว่าที่เอกสารเขียนไว้เสมอ

Key Takeaways

• ATT&CK v20 (13 ต.ค. 2026) คือของใหม่ที่ใช้ได้เลย: โดเมน ICS มี 106 Detection Strategies และ 302 Analytics พร้อมบริบท Asset — เป็นจุดเริ่มต้นที่ดีที่สุดเท่าที่เคยมีมา
• เริ่มจาก 3-5 Use Case ไม่ใช่ 78: เลือกเทคนิคที่ตรงกับช่องทางจริงของโรงงาน (remote access, HMI, Modbus, Setpoint) แล้วขยายทีหลัง
• คำถามเดียวที่ต้องตอบได้: “อะไรบอกเราว่าพฤติกรรมนี้กำลังเกิดขึ้น?” — ตอบไม่ได้เท่ากับยังไม่มี detection
• ข้อมูลมีอยู่แล้วในโรงงานส่วนใหญ่: SPAN port, Syslog, และ firewall log ที่ไม่มีใครรวบรวม — การเก็บมาไว้ที่เดียวคือก้าวแรกที่คุ้มค่าที่สุด
• ทดสอบด้วยการโจมตีตัวเอง: rule ที่ไม่เคยจุดสัญญาณเตือนจริง คือ rule ที่ยังไม่พร้อมใช้งาน