Deterministic Detection Rules ใน OT ทำงานยังไง — จาก Allow List ถึง Incident
กลไก deterministic detection ใน OT: Allow List, Device Mapping, rule type และการ triage incident ใน zcrOT อธิบายผ่านตัวอย่างสถานการณ์สมมติ ปรึกษาทีมเราได้ฟรี
Deterministic Detection Rules ใน OT ทำงานยังไง — จาก Allow List ถึง Incident
ทีม OT ส่วนใหญ่ไม่ได้ขาด log — ขาดเวลา คนที่ต้องคอยไล่ดูทราฟฟิกเครือข่ายโรงงานหรือระบบ SCADA ทุกวันมักเจอปัญหาเดียวกัน คือเครื่องมือ monitor แจ้งเตือนอะไรก็ไม่รู้ตลอดเวลา จนสุดท้ายทีมเลือกที่จะปิดการแจ้งเตือนบางอย่างทิ้งไปเพราะไม่มีเวลาไล่ดูทัน ซึ่งอันตรายกว่าไม่มีระบบแจ้งเตือนเลยด้วยซ้ำ
คำตอบที่หลายเจ้าใช้คือ machine learning แบบ anomaly detection — ให้โมเดลเรียนรู้ "พฤติกรรมปกติ" แล้วแจ้งเตือนเมื่อเจออะไรที่ผิดไปจากนั้น ฟังดูฉลาด แต่ปัญหาคือเวลาแจ้งเตือนขึ้นมา ทีมมักตอบไม่ได้ว่า "ทำไมถึงเตือน" เพราะโมเดลไม่ได้อธิบายเหตุผลตรงๆ ให้ — ได้แต่บอกว่า "ผิดปกติ" เฉยๆ
นี่คือเหตุผลที่ระบบแบบ deterministic ยังมีที่ยืนอยู่ในงาน OT กฎแบบนี้ไม่ได้ฉลาดเท่าโมเดล machine learning แต่ทุกกฎเขียนเงื่อนไขไว้ชัดว่า ถ้า A และ B เกิดขึ้นพร้อมกัน ให้แจ้งเตือน — อธิบายได้เสมอว่าทำไมถึงเตือน ซึ่งในงานที่การตัดสินใจผิดอาจทำให้ต้องหยุดไลน์ผลิต ความสามารถในการอธิบายมีค่ามากกว่าที่คิด
บทความนี้เจาะเข้าไปดู Detection Engine ของ zcrOT ตรงๆ จาก demo สาธารณะที่เปิดให้ทุกคนเข้าไปคลิกดูเองได้ (https://demo.ot.zcr.ai/dashboard/detection-engine) ข้อมูลใน demo เป็นข้อมูลตัวอย่าง เราจึงไม่เอาตัวเลขบนหน้าจอมาเล่า แต่จะอธิบายว่าแต่ละแท็บมีไว้ทำอะไรและควรอ่านยังไง แล้วไล่ตามสถานการณ์สมมติเรื่องหนึ่ง ตั้งแต่รายการใน Allow List จนกลายเป็น incident ระหว่างอ่านเปิด demo ตามไปดูด้วยก็ได้
กลไก 3 ชั้นก่อนจะกลายเป็น Incident
Detection Engine ของ zcrOT แบ่งงานออกเป็นหลายแท็บ ที่เกี่ยวกับกลไกตรวจจับโดยตรงมี 4 แท็บ คือ Allow Lists, Device Mappings, Detection Rules และ Incidents (แท็บสุดท้ายใช้สำหรับการตอบสนองและ triage) แต่ละแท็บทำหน้าที่ต่างกันชัดเจน และเรียงกันเป็นชั้นกรองก่อนทราฟฟิกจะกลายเป็นสิ่งที่ทีมต้องมานั่งดู
ชั้นที่ 1 — Allow List: บอกระบบว่าอะไร "ปกติอยู่แล้ว"
รายการใน Allow List คือบันทึกว่าทราฟฟิกแบบนี้ทีมเคยตรวจดูแล้วและตัดสินว่าเป็นเรื่องปกติ แต่ละรายการมีชื่อ, คำอธิบาย, scope (ต้นทาง ปลายทาง และช่วงพอร์ต) และประเภท (คุยกันภายในเครือข่ายหรือออกไปข้างนอก และใช้โปรโตคอลอะไร เช่น Modbus หรือ TLS) พูดง่ายๆ คือการเขียนลงไปตรงๆ ว่าเครือข่ายนี้ "ปกติ" หน้าตาเป็นยังไง ทีมจะได้ไม่ต้องกลับมาไล่ตรวจเรื่องเดิมซ้ำ
นิสัยที่ควรฝึกคือเขียนแต่ละรายการให้แคบไว้ ลองนึกถึงรายการหนึ่งที่ระบุว่า monitoring server เครื่องเดียว poll gateway ตัวเดียวผ่าน Modbus ตามรอบเวลา รายการแบบนี้ระบุไว้เฉพาะเจาะจงมาก คือต้นทางนี้ ปลายทางนี้ พอร์ตนี้ โปรโตคอลนี้ ถ้ามีเครื่องอื่นเริ่มคุยกับ gateway ตัวนั้น หรือ monitoring server ไปคุยกับปลายทางอื่น ในรายการก็ไม่มีตรงไหนบอกว่าทราฟฟิกนั้นปกติ รายการยิ่งกว้างก็ยิ่งนับทราฟฟิกว่าปกติไปมาก รายการที่คลุมไปครึ่งเครือข่ายช่วยประหยัดแรงพิมพ์ แต่ก็เหมาว่าปกติกับทราฟฟิกจำนวนมากที่ยังไม่มีใครเคยดูจริงๆ
ชั้นที่ 2 — Device Mapping: แปล IP ให้เป็นชื่อที่คนอ่านแล้วเข้าใจทันที
Device Mappings คือแท็บที่จับคู่ IP address หรือ Modbus unit ID เข้ากับชื่อที่คนอ่านเข้าใจ ฟังดูเป็นงานจุกจิก แต่เป็นสิ่งที่ช่วยให้คนอ่านชั้นอื่นๆ ออก เพราะรายการใน Allow List เขียนเป็น address และทราฟฟิกดิบส่วนใหญ่ก็เป็น address เหมือนกัน ไล่เทียบรายการกับ mapping แล้วจะรู้ทันทีว่าหมายถึงอุปกรณ์ตัวไหนในเครือข่าย (สองแท็บนี้ไม่ได้ผูก reference กันโดยตรง จึงควรทำการเทียบแบบนี้ให้เป็นนิสัย) เรื่องนี้สำคัญที่สุดตอนกลางดึกที่ alert เข้ามาจริง เพราะไม่มีใครอยากมานั่งไล่ว่า address นี้คือเครื่องไหน นอกจากนี้ การ map ยังเป็นเรื่องของวินัยในการตั้งชื่อด้วย คือตั้งชื่ออุปกรณ์แต่ละตัวให้ชื่อเดียวแล้วใช้เหมือนกันทุกที่ เพราะชื่อที่ผิดไปแม้ตัวอักษรเดียวอาจทำให้เข้าใจว่ามีอุปกรณ์ตัวที่สองทั้งที่จริงมีตัวเดียว
อีกกรณีที่ควรทำความเข้าใจคือ Modbus unit ID อุปกรณ์หลายตัวที่อยู่หลัง gateway (เช่น flow meter, drive controller และเซนเซอร์อุณหภูมิ) ไม่ได้มี IP ของตัวเองเสมอไป แต่อาจตอบด้วย unit ID คนละเลขภายใต้ address ของ gateway ตัวเดียวกัน ซึ่งเป็นรูปแบบทั่วไปในงาน OT จริง ถ้า map ทั้ง unit ID และ IP ทีมที่อ่าน log จะรู้ทันทีว่า unit ID ที่เห็นในทราฟฟิกหมายถึงอุปกรณ์ตัวไหน โดยไม่ต้องเปิด network diagram มาเทียบเอง
ชั้นที่ 3 — Detection Rule: เงื่อนไขที่บอกว่าเมื่อไหร่ถึงจะเตือนจริง
นี่คือชั้นที่ตัดสินว่าอะไรควรกลายเป็น incident กฎแต่ละข้อมีชื่อ, priority, type และ severity โดย rule type มีให้เลือก 4 แบบ คือ Single Event (เจอครั้งเดียวก็เตือนได้ทันที เช่น client ที่ไม่รู้จักพยายามต่อเข้า gateway), Threshold (ต้องเกินจำนวนที่กำหนดถึงจะเตือน เช่น การเข้าซ่อมบำรุงระยะไกลนอกเวลาทำการ), Aggregation (รวมเหตุการณ์ย่อยหลายอันเข้าด้วยกันก่อนตัดสิน เช่น Modbus error ที่เกิดถี่ผิดปกติ) และ Correlation (เทียบพฤติกรรมกับ baseline ที่เคยเห็น เช่น ทราฟฟิกออกไป cloud ที่ผิดไปจากรูปแบบเดิม) การมี rule type ให้เลือกหลายแบบแบบนี้สำคัญ เพราะเหตุการณ์ผิดปกติในโรงงานไม่ได้มีรูปแบบเดียว บางอย่างต้องจับได้ทันทีที่เห็นครั้งแรก บางอย่างต้องรอดูแนวโน้มก่อนถึงจะฟันธงได้
อยากลองตั้งกฎแบบนี้ในเครือข่าย OT ของตัวเองไหม ดูแพ็กเกจทั้งหมดได้ที่ แพ็กเกจ zcrOT →
ตัวอย่างสมมติ — จากกฎ สู่ Incident
ทฤษฎีอย่างเดียวยังไม่พอ จึงขอไล่สถานการณ์หนึ่งให้ดูตั้งแต่ต้นจนจบ สถานการณ์นี้แต่งขึ้นเอง ไม่มีอุปกรณ์จริง IP จริง หรือชื่อจริงอยู่ในนั้นเลย ถ้าจะร่างสถานการณ์แบบนี้ไว้ใน runbook ของทีมเอง ให้ใช้ address จากช่วงที่ RFC 5737 กันไว้สำหรับเอกสาร ตัวอย่างจะได้ไม่ถูกเข้าใจผิดว่าเป็นระบบที่ใช้งานอยู่จริง
สมมติโรงงานเล็กๆ แห่งหนึ่งมี data gateway ที่รวบรวมค่าจากอุปกรณ์หน้างานไม่กี่ตัวผ่าน Modbus ทีมมีรายการใน Allow List สำหรับ monitoring server ที่ poll gateway ตัวนี้ และทั้งสองเครื่องมีชื่อกำกับอยู่ใน Device Mappings แล้ว กฎที่เปิดไว้มีสองข้อ คือกฎ Single Event สำหรับ client ที่ไม่รู้จักเข้ามาที่ gateway และกฎ Threshold สำหรับกิจกรรม remote maintenance นอกช่วงเวลาที่ตกลงกันไว้
คืนหนึ่งที่เงียบๆ มีเครื่องที่ยังไม่มีใคร map ไว้เริ่มส่ง Modbus request เข้ามาที่ gateway ลองไล่เทียบกับบันทึกของทีมดู
- ไม่มีรายการใน Allow List ที่ครอบคลุมทราฟฟิกระหว่างเครื่องนี้กับ gateway จึงไม่มีอะไรบอกว่าทราฟฟิกนี้ปกติ
- Device Mappings ก็ไม่มีชื่อของเครื่องนี้ ในทราฟฟิกดิบจึงเป็นแค่ address เปล่าๆ ซึ่งก็เป็นเบาะแสอย่างหนึ่งแล้ว
- กฎ Single Event เขียนไว้สำหรับ client แบบนี้พอดี จึงเตือนตั้งแต่ครั้งแรกที่เจอ และเพราะเงื่อนไขของกฎเขียนไว้ชัด ทุกคนบอกได้ทีหลังว่าทำไมถึงเตือน คือมี client ที่ไม่รู้จักเข้ามาที่ gateway
- การ match นั้นกลายเป็น incident ตอนนี้จึงมีเรื่องให้คนไปนั่งดูแล้ว
ส่วนที่มีประโยชน์จริงคือสิ่งที่อ่านต่อได้จาก incident นั้น เริ่มจากเงื่อนไขที่ทำให้เตือน ซึ่งดูได้จากกฎที่เขียนไว้สำหรับกรณีนี้ ถ้าเอา address ในทราฟฟิกเบื้องหลังไปเทียบกับ Device Mappings ก็รู้ว่าส่วนไหนของโรงงานเกี่ยวข้อง สถานะบอกว่ามีคนรับเรื่องไปหรือยัง (เช่น open, acknowledged หรือ closed) จำนวนครั้งที่ match บอกว่ากฎนี้ match บ่อยแค่ไหน ส่วน risk score มีไว้ช่วยตัดสินว่าควรดูอะไรก่อน
สองข้อสุดท้ายนี้ต้องระวังหน่อย เพราะ incident สองรายการอาจ match จำนวนครั้งเท่ากันแต่ควรได้รับความสนใจไม่เท่ากันเลย client ที่ไม่รู้จักเข้ามาที่ gateway ซ้ำแล้วซ้ำอีก เป็นคนละเรื่องกับกฎ severity ต่ำที่ match ซ้ำๆ บนอุปกรณ์ที่รู้กันอยู่แล้วว่า alert ถี่เป็นปกติ นี่คือเหตุผลที่ทีม triage ไม่ควรตัดสินว่าจะรีบดูอันไหนก่อนจาก "จำนวนครั้งที่ match" อย่างเดียว และอย่าเพิ่งคิดว่า risk score คือ severity ของกฎในอีกรูปหนึ่ง ให้มองเป็นข้อมูลชิ้นหนึ่งสำหรับ triage ไม่ใช่คำตัดสิน
กรณีที่เงียบก็สอนอะไรได้เหมือนกัน กฎ Threshold ในสถานการณ์นี้เงียบตลอดทั้งคืน ซึ่งไม่จำเป็นต้องแปลว่าระบบเสีย กฎที่เปิดอยู่แต่ไม่เคยสร้าง incident อาจแค่รอเงื่อนไขที่ยังไม่เกิดก็ได้ เพียงแต่ต้องแน่ใจก่อนว่าเป็นเพราะเหตุนี้จริง ก่อนจะวางใจพึ่งกฎข้อนั้น
ถ้าอยากรู้ต่อว่าเหตุการณ์ OT หน้าตาเป็นยังไงและควรชั่งน้ำหนักยังไง มีบทความแยกไว้ที่ 4 ประเภทเหตุการณ์ OT
ไม่ใช่แค่ Modbus อ่าน-เขียน — Classification ละเอียดกว่าที่คิด
เวลาสร้าง Allow List ใหม่ ระบบให้เลือก Classification จาก dropdown ที่ครอบคลุมมากกว่าหมวด Modbus อ่าน-เขียนที่คนมักคาดไว้ตอนแรก นอกจากทราฟฟิก Modbus แล้ว ยังมีกลุ่มสำหรับทราฟฟิกแบบอื่น เช่น HTTPS session และ ICMP probe รวมถึงกลุ่ม inbound port access — สะท้อนว่าระบบจำแนกทราฟฟิกละเอียดกว่าที่ชื่อโปรโตคอลเปล่าๆ ชื่อเดียวจะสื่อได้
แต่ก็ต้องพูดตรงๆ ว่าความละเอียดของ Classification พวกนี้ยังอยู่ในกรอบของ Modbus และทราฟฟิกระดับเครือข่าย (network flow) เป็นหลัก ถ้าหน้างานมี EV charger จุดนี้สำคัญ — zcrOT ไม่มี signature เฉพาะสำหรับ OCPP (Open Charge Point Protocol) ซึ่งเป็นโปรโตคอลที่ EV charger คุยกับ backend โดยตรง หมายความว่าการตรวจจับที่เกี่ยวกับ EV charger ทำงานจากทราฟฟิกเครือข่ายที่วิ่งเข้าออก IP ของ charger เป็นหลัก ไม่ใช่การแกะข้อความ OCPP ระดับ protocol — ถ้าองค์กรต้องการมองลึกถึงระดับข้อความ OCPP ต้องมองหาเครื่องมือเฉพาะทางเพิ่มเติม อันนี้เป็นข้อจำกัดจริงที่ควรรู้ก่อนตัดสินใจ ไม่ใช่เรื่องที่ควรปิดบัง
เรื่องขอบเขต protocol แบบนี้ก็เป็นจุดที่ zcrOT ยังตามหลังผู้เล่นระดับโลกอยู่จริง ถ้าใครกำลังเทียบ zcrOT กับ Claroty, Nozomi Networks หรือ Dragos อยู่ มีบทความเปรียบเทียบตรงๆ ไม่มีเอนเข้าข้างตัวเองเขียนไว้แล้วที่ zcrOT เทียบกับ Claroty, Nozomi Networks และ Dragos
สรุป
กลไกทั้งหมดที่เล่ามา — Allow List บอกว่าอะไรปกติ, Device Mapping แปล IP ให้เป็นชื่อที่อ่านรู้เรื่อง, Detection Rule กำหนดเงื่อนไขที่ต้องเตือน, แล้วค่อยจบที่ Incident ที่มี risk score ให้จัดลำดับ — คือสิ่งที่ทำให้ทีม OT ไม่ต้องมานั่งไล่ทราฟฟิกดิบทีละบรรทัดเอง แต่ก็ไม่ต้องเชื่อ black box แบบไม่มีเหตุผลรองรับเช่นกัน ทุกการแจ้งเตือนมาจากกฎที่เขียนเงื่อนไขไว้ชัด จึงมีคำตอบเสมอว่าทำไมถึงเตือน
ถ้าอยากรู้ภาพใหญ่กว่านี้ว่าทำไมงาน OT ถึงคิดต่างจาก IT ตั้งแต่ต้น อ่านต่อได้ที่ OT Security สำหรับโรงงานอุตสาหกรรม ส่วนใครอยากลองเข้าไปคลิกดูของจริงด้วยตัวเอง ไม่ต้องสมัครสมาชิก เข้าได้ที่ zcrOT demo หรือดูรายละเอียดแพ็กเกจทั้งหมดที่ หน้าราคา
ติดต่อทีมงาน
อยากรู้ว่ากฎแบบไหนเหมาะกับเครือข่าย OT ของคุณ ปรึกษาทีมเราได้ฟรี ไม่มีค่าใช้จ่าย
แหล่งข้อมูลอ้างอิง
- RFC 5737 — IPv4 Address Blocks Reserved for Documentation — ยืนยันว่ามี IPv4 สามช่วง (ช่วง TEST-NET) ที่สงวนไว้สำหรับเอกสารและตัวอย่างโดยเฉพาะ address ที่หยิบจากช่วงเหล่านี้จึงไม่ชี้ไปที่ระบบจริงของใคร
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security — ยืนยันว่าระบบ ICS/OT ต้องการความพร้อมใช้งานสูง การทำงานแบบ real-time และพฤติกรรมที่คาดเดาได้ (deterministic) ซึ่งทำให้ความต้องการด้านความปลอดภัยต่างจาก IT ทั่วไปอย่างมีนัยสำคัญ — สนับสนุนเหตุผลที่บทความใช้อธิบายว่าทำไม deterministic detection ยังมีที่ยืน แม้ NIST จะไม่ได้พูดถึงประเด็น explainability ของ ML โดยตรง