สอน Local LLM ให้ “อ่าน” โรงงานของคุณ: อธิบายภัยไซเบอร์และบันทึกเครื่องจักรด้วย simpliSOC

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

นักวิเคราะห์ SOC (ถ้าโรงงานมี) เห็นการแจ้งเตือนจาก Wazuh ว่า FC 15 write multiple coils, srcip 10.0.4.71, dst PLC-04, 02:14 น. นี่คือสัญญาณด้านความปลอดภัย ซึ่งอ่านออกได้ถ้าคุณรู้จัก Modbus function code อยู่แล้ว

หัวหน้ากะไม่เห็นอะไรเลย หรือเห็นแค่สัญญาณเตือนบน HMI ที่ขึ้นว่า FAULT 0x22 พร้อมไฟแดง นี่คือสัญญาณด้านปฏิบัติการ ซึ่งอ่านออกได้ถ้าคุณรู้อยู่แล้วว่าโค้ดข้อผิดพลาด 0x22 บนไลน์นั้นหมายถึงอะไร

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

1. ทบทวน: การมองเห็นชั้น OT ให้ได้ก่อน

ก่อนที่โมเดลจะอธิบายอะไรได้ ต้องมีคนคอย "ฟัง" อยู่ก่อน เราพูดถึงเรื่องการมองเห็น (visibility) ไว้อย่างละเอียดแล้วในบทความ Why Your Factory Floor Is the Softest Target in Your Network: การแทป (TAP) เครือข่ายแบบ passive หรือใช้ SPAN port บนสวิตช์ฝั่ง OT, เซนเซอร์ Zeek ที่ถอดรหัส Modbus TCP และ EtherNet/IP ให้กลายเป็นบันทึกแบบมีโครงสร้าง และ Wazuh agent ที่ส่งบันทึกเหล่านั้นไปยัง SOC backend — ทั้งหมดนี้โดยไม่มีการส่ง probe packet แบบ active เข้าไปหา PLC ที่อาจรับมือกับมันไม่ไหว

สถาปัตยกรรมนั้นให้คุณได้ข้อมูลดิบ: ใครคุยกับ PLC ตัวไหน ด้วย protocol อะไร function code แบบไหน เวลาใด คำถามที่บทความนี้จะพูดถึงคือเกิดอะไรขึ้นกับข้อมูลนั้น หลังจาก Wazuh ตีธงแล้ว — และแนวคิดเดียวกันนี้สามารถขยายไปสู่บันทึกสุขภาพเครื่องจักรที่อยู่ข้างๆ กันได้หรือไม่

flowchart TD
    PLC1["PLC Modbus TCP"]
    PLC2["PLC EtherNet IP"]
    HMI["HMI Workstation"]
    SW["OT Switch SPAN Port"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor"]
    WZ["Wazuh Manager OT Rules"]

    PLC1 --> SW
    PLC2 --> SW
    HMI --> SW
    SW --> TAP
    TAP --> ZEEK
    ZEEK --> WZ

2. ครึ่งแรก: อธิบายการแจ้งเตือนด้านความปลอดภัย ใช้งานได้จริงวันนี้

ส่วนนี้ไม่ใช่การคาดเดา ระบบ AI-assisted triage ของ simpliSOC ตามที่ระบุไว้ในหน้าผลิตภัณฑ์ simpliSOC รัน local LLM กับการแจ้งเตือนของ Wazuh ที่เข้าเกณฑ์อยู่แล้ว ผ่าน endpoint แบบ OpenAI-compatible (Ollama, llama.cpp, vLLM, LocalAI) ที่ทำงานอยู่ในเครือข่ายของลูกค้าเอง โดยอ่านการแจ้งเตือนพร้อมกิจกรรมโดยรอบ แล้วเขียนคำอธิบายเป็นภาษาที่คนอ่านเข้าใจได้ พร้อมฟันธงว่าเป็น true หรือ false positive ทั้งแบบอัตโนมัติหรือกดขอเองก็ได้

การนำกลไกเดียวกันนี้มาชี้ไปยัง OT rules — จากสถาปัตยกรรม passive tap ด้านบน — จะให้ผลตอบแทนที่มากกว่าฝั่ง IT เพราะกลุ่มผู้ใช้ต่างกัน นักวิเคราะห์ SOC พูดภาษา Wazuh อยู่แล้ว แต่วิศวกรโรงงานหรือหัวหน้ากะโดยทั่วไปไม่พูด และพวกเขามักเป็นคนแรกที่อยู่ใกล้เครื่องจักรจริงเมื่อมีอะไรเกิดขึ้น

เทียบการแจ้งเตือนดิบกับสิ่งที่โมเดลส่งกลับมาให้:

การแจ้งเตือนดิบจาก Wazuh:

rule.id: 100045
rule.level: 12
agent: zeek-ot-sensor-01
modbus.func_code: 15
modbus.dst_ip: 10.0.2.14 (PLC-04)
modbus.src_ip: 10.0.4.71
timestamp: 2026-09-02T02:14:03+07:00

ผลลัพธ์แบบมีโครงสร้างจากโมเดล:

{
  "severity": "high",
  "asset": "PLC-04 (extruder line 2)",
  "summary": "มีโฮสต์ที่ไม่เคยเขียนข้อมูลเข้า PLC ตัวนี้มาก่อน ส่งคำสั่ง write-multiple-coils เวลา 02:14 น. นอกช่วงหน้าต่างซ่อมบำรุงที่กำหนดไว้ 22:00-23:00 น.",
  "context_check": "ไม่มีใบสั่งงานซ่อมบำรุงเปิดอยู่สำหรับไลน์ 2 คืนนี้ และ IP ต้นทางไม่ตรงกับช่วง VPN ของผู้ขาย",
  "recommended_action": "escalate_and_verify_physically",
  "confidence": 0.78
}

บล็อกที่สองคือสิ่งที่หัวหน้ากะสามารถลงมือทำได้ทันทีโดยไม่ต้องรู้ว่า coil คืออะไร โมเดลไม่ได้แต่งเรื่องเปรียบเทียบกับหน้าต่างซ่อมบำรุงขึ้นมาเอง — SOC Integrator ดึงบริบทนั้น (ใบสั่งงานที่เปิดอยู่ ช่วง IP ของผู้ขายที่รู้จัก) มาใช้เหมือนที่ทำกับการแจ้งเตือนฝั่ง IT อยู่แล้ว ตามแนวทางที่อธิบายไว้ใน Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslog สิ่งที่เปลี่ยนจริงๆ สำหรับ OT คือคำศัพท์ใน prompt และฟิลด์ที่ SOC Integrator เอามาเสริม — ชื่ออุปกรณ์แทนชื่อผู้ใช้ หน้าต่างซ่อมบำรุงแทนเวลาทำการปกติ ช่วง VPN ของผู้ขายแทนช่วง IP ของพนักงาน

3. ครึ่งหลัง: แนวคิดเดียวกัน ชี้ไปที่บันทึกสุขภาพเครื่องจักร — เป็นแนวคิด roadmap ไม่ใช่ฟีเจอร์ที่ส่งมอบแล้ว

ตรงนี้สำคัญที่ต้องพูดให้ชัดเจนว่าอะไรมีอยู่จริง กับอะไรที่เราคิดว่าควรมี simpliSOC คือ stack ด้านความปลอดภัย มันยังไม่อ่านโค้ดข้อผิดพลาดของ PLC ค่าที่เบี่ยงเบนของ historian tag หรือบันทึกการเตือนของ HMI ในวันนี้ และไม่มีส่วนใดในหัวข้อนี้ที่บรรยายความสามารถปัจจุบันของ simpliSOC

สิ่งที่เราคิดว่าคุ้มค่าที่จะสร้าง: โมเดล local ตัวเดียวกัน รันจาก endpoint on-premise ตัวเดียวกัน แต่ได้รับหน้าที่ที่สอง แทนที่จะอ่านการแจ้งเตือน OT ของ Wazuh มันอ่านสายข้อมูลปฏิบัติการที่ระบบอย่าง simpliFactory เก็บอยู่แล้วในระดับชั้นโรงงาน — โค้ดข้อผิดพลาด ค่า tag ที่เบี่ยงเบนออกจากสเปก การเตือนถี่ๆ บน HMI — แล้วผลิตคำอธิบายแบบภาษาที่คนอ่านเข้าใจและมีโครงสร้างแบบเดียวกัน แต่เล็งไปที่ช่างซ่อมบำรุงแทนนักวิเคราะห์ความปลอดภัย

เหตุผลด้านต้นทุนคือสิ่งที่ทำให้แนวคิดนี้มีค่ามากกว่าแค่ไดอะแกรม โมเดลขนาด 7B–14B ที่รันแบบ local ตามแนวทางใน Choosing Hardware for Local LLMs in 2026: A Practical Sizing Guide มีต้นทุนต่อการเรียกใช้ที่ถูกพอจนไม่จำเป็นต้องพิสูจน์ตัวเองด้วยงานเดียว เมื่อโรงงานมี endpoint local ที่ทำ triage ด้านความปลอดภัยอยู่แล้ว การเพิ่มผู้ใช้งานที่สองด้วย prompt และ output schema ที่ต่างออกไป ใกล้เคียงกับการเปลี่ยน config มากกว่าการเริ่มโปรเจกต์ใหม่ — นี่คือเหตุผลทั้งหมดของแนวทาง on-premise ตั้งแต่แรก ตามที่กล่าวไว้ใน Why Enterprises in Southeast Asia and Japan Are Moving LLMs Inside the Firewall ซึ่งครอบคลุมข้อกำหนดของ PDPA ไว้โดยตรง และยังสอดคล้องกับมาตรา 59 ของพระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ที่กำหนดให้โครงสร้างพื้นฐานสำคัญบางประเภทต้องดูแลข้อมูลปฏิบัติการอย่างรัดกุม รวมถึงเข้ากับแนวทางส่งเสริมการลงทุนด้าน smart manufacturing ของ EEC/BOI ที่มักกำหนดให้ระบบสำคัญต้องอยู่ในประเทศ

flowchart TD
    OTLOG["OT Security Log Stream Wazuh"]
    MESLOG["Machine Health Log Stream MES Historian"]
    LLM["Local LLM Endpoint Ollama or vLLM"]
    SOCOUT["Plain Language Security Explanation"]
    MESOUT["Plain Language Fault Explanation Roadmap"]

    OTLOG --> LLM
    MESLOG --> LLM
    LLM --> SOCOUT
    LLM --> MESOUT

ตัวอย่างผลลัพธ์แบบมีโครงสร้างที่อาจเป็นไปได้ฝั่งสุขภาพเครื่องจักร — เป็นตัวอย่างแนวคิด ไม่ใช่ schema ที่ใช้งานจริง:

{
  "asset": "Extruder Line 2 - Zone 3 Heater",
  "fault_code": "0x22",
  "summary": "อุณหภูมิ Zone 3 เบี่ยงเบนต่ำกว่าค่าที่ตั้งไว้ 8 เปอร์เซ็นต์ในช่วง 40 นาทีที่ผ่านมา สอดคล้องกับลักษณะของ heating element ที่เสียบางส่วนมากกว่าเซนเซอร์ผิดพลาด",
  "similar_history": "รูปแบบการเบี่ยงเบนแบบเดียวกันนี้เคยเกิดขึ้นก่อนการเปลี่ยน heater ของ Zone 3 เมื่อวันที่ 2026-03-14",
  "recommended_action": "schedule_inspection_before_next_shift",
  "confidence": 0.65
}

สิ่งที่แยกแนวคิดนี้ออกจากซอฟต์แวร์ predictive maintenance สำเร็จรูปมีสองอย่าง: มันรันบนโมเดล on-premise ตัวเดียวกันที่ถูกพิสูจน์คุณค่าไปแล้วด้วยเคสด้านความปลอดภัย และมันอธิบายข้อผิดพลาดด้วยภาษาของทีมซ่อมบำรุงแทนที่จะให้พวกเขาไปอ่านกราฟแนวโน้มเอง

4. Guardrail ใช้กับทั้งสองครึ่ง และ OT ยกระดับความเสี่ยงขึ้นไปอีก

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

เรื่องนี้สำคัญกว่าในฝั่ง OT มากกว่า IT เพราะรูปแบบความล้มเหลวเป็นเรื่องทางกายภาพ การตัดสิน false positive ผิดพลาดในการแจ้งเตือนฝั่ง IT เสียแค่เวลาของนักวิเคราะห์ แต่การตัดสิน false negative ผิดพลาดใน "ไม่ต้องสนใจ นี่แค่ heater เบี่ยงเบน" ทั้งที่จริงๆ เป็นการเปลี่ยน setpoint โดยไม่ได้รับอนุญาต คือผลลัพธ์คนละระดับ — และในทางกลับกัน การปฏิบัติต่อข้อผิดพลาดเชิงกลไกจริงเหมือนเป็นเหตุการณ์ด้านความปลอดภัย หมายถึงโรงงานต้องหยุดไลน์ผลิตด้วยเหตุผลที่ผิด ทั้งครึ่งความปลอดภัยและครึ่งสุขภาพเครื่องจักรของแนวคิดนี้ไม่ควรถูกไว้วางใจให้ตัดสินใจ แต่ควรถูกไว้วางใจให้อธิบายอย่างรวดเร็วแก่คนที่ตัดสินใจจริง

Guardrail อีกข้อส่งต่อมาจากงานด้าน OT visibility โดยตรง: ไม่มีส่วนใดในนี้เขียนข้อมูลเข้า PLC ปรับ setpoint หรือดำเนินการเชิงรุกบนเครือข่าย OT โมเดลอ่านบันทึกที่มีอยู่แล้วและผลิตข้อความ เป็นท่าทีแบบ passive เดียวกับที่ Zeek sensor ใช้ เพียงแต่ขยายเข้าไปในชั้นการให้เหตุผล ไม่ใช่หยุดแค่ชั้นการเก็บข้อมูล

5. สิ่งนี้หมายความว่าอย่างไรสำหรับการคุยเรื่องความปลอดภัยโรงงานหรือ MES

หากคุณรัน Wazuh พร้อม OT rules อยู่แล้ว การขยายชั้นอธิบายด้วย local-LLM ไปยังการแจ้งเตือนเหล่านั้นเป็นการคุยเรื่อง scope ไม่ใช่สถาปัตยกรรมใหม่ — มันใช้ endpoint เดิม รูปแบบการเสริมข้อมูลของ SOC Integrator เดิม และการออกแบบ guardrail เดิมที่ใช้งานจริงกับการแจ้งเตือนฝั่ง IT อยู่แล้ว

หากคุณยังอยู่ในขั้นตอนก่อนหน้านั้น — มี MES ที่เก็บข้อมูลชั้นโรงงานแต่ยังไม่มีการมองเห็นด้านความปลอดภัย OT หรือกลับกัน — คำถามเรื่องลำดับคือควรติดตั้งเครื่องมือวัดสายข้อมูลไหนก่อน คำแนะนำเริ่มต้นของเราคือ passive OT tap และ Wazuh rules ตามที่อธิบายไว้ในบทความเดือนมิถุนายน เพราะนั่นคือช่องว่างที่มีความเสี่ยงด้านลบสูงสุด (เครือข่าย OT ที่ไม่ถูกเฝ้าระวังคือความเสี่ยงที่มีอยู่จริงวันนี้) ตามด้วยชั้นอธิบายด้วย local-LLM และการขยายไปสู่สุขภาพเครื่องจักรเมื่อมีสายข้อมูลที่คุ้มค่าจะอธิบายแล้ว

คำถามที่พบบ่อย

ตอนนี้ simpliSOC วินิจฉัยข้อผิดพลาดของเครื่องจักรได้แล้วหรือยัง ไม่ใช่แค่เหตุการณ์ด้านความปลอดภัย?
ยังไม่ได้ ระบบ triage แบบ local-LLM ของ simpliSOC เป็นฟีเจอร์ที่ใช้งานจริงสำหรับการแจ้งเตือนด้านความปลอดภัยเท่านั้น การประยุกต์ใช้ด้านสุขภาพเครื่องจักรที่อธิบายในบทความนี้เป็นแนวคิดต่อยอดของสถาปัตยกรรมเดียวกัน ไม่ใช่ความสามารถปัจจุบัน

มีข้อมูลโรงงานถูกส่งออกนอกเครือข่ายโรงงานหรือไม่?
ไม่มี Local LLM รันบนฮาร์ดแวร์ที่อยู่ในเครือข่ายของลูกค้าเอง ผ่าน endpoint แบบ OpenAI-compatible (Ollama, llama.cpp, vLLM หรือ LocalAI) ไม่มีข้อมูล — ทั้งบันทึกด้านความปลอดภัยหรือบันทึกเครื่องจักร — ออกจากเครือข่ายเพื่อให้สิ่งนี้ทำงาน

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

ถ้าเรายังไม่มีการมองเห็นเครือข่าย OT ล่ะ?
เริ่มจากตรงนั้นก่อน ชั้นอธิบายด้วย local-LLM ต้องการสายข้อมูลบันทึกให้อ่าน และ passive Zeek/Wazuh tap ตามที่อธิบายไว้ในบทความด้าน OT visibility ของเราคือวิธีที่มีความเสี่ยงต่ำที่สุดในการได้มาซึ่งสิ่งนั้น โดยไม่แตะต้อง PLC ที่กำลังทำงานอยู่

แหล่งที่มา:

• simpliSOC — Open-Source Security Operations Platform
• Why Your Factory Floor Is the Softest Target in Your Network
• Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslog
• Choosing Hardware for Local LLMs in 2026: A Practical Sizing Guide
• Why Enterprises in Southeast Asia and Japan Are Moving LLMs Inside the Firewall
• simpliFactory