การใช้ Small Language Model (SLM) ตรวจจับการโจมตีทางไซเบอร์จาก Wazuh Log และ Firewall Syslog

ศูนย์ปฏิบัติการความปลอดภัย (SOC) ต้องเผชิญกับปริมาณ alert มหาศาลทุกวัน องค์กรขนาดกลางที่รัน Wazuh บน endpoint หลายร้อยเครื่อง บวกกับ firewall อย่าง FortiGate ที่ส่ง syslog เข้ามา สามารถสร้าง event ได้หลักหมื่นรายการต่อวันโดยง่าย การทำ correlation ด้วย rule แบบดั้งเดิมจับรูปแบบที่รู้จักได้ดี แต่มักพลาด "หางยาว" ของภัยคุกคาม เช่น alert หลายรายการที่แยกกันดูไม่เกี่ยวข้องแต่จริง ๆ เชื่อมโยงกัน การลาดตระเวนแบบช้า ๆ (low-and-slow reconnaissance) หรือบริบทที่นักวิเคราะห์มนุษย์เท่านั้นจะมองออกว่าน่าสงสัย

จุดนี้เองที่ small language model (SLM) — ไม่ใช่โมเดลขนาดใหญ่ระดับ frontier แต่เป็นโมเดลขนาดกะทัดรัด 7B–14B พารามิเตอร์ที่รันภายในองค์กร — เข้ามามีบทบาทในระบบ โดยไม่ได้แทนที่ engine ตรวจจับของ Wazuh หรือ correlation rule ของ SIEM แต่ทำงานต่อจากขั้นตอนเหล่านั้น เปลี่ยน alert ที่เป็น noise ให้กลายเป็นการวิเคราะห์ที่พร้อมให้นักวิเคราะห์อ่านต่อได้ทันที

ทำไมต้อง SLM ไม่ใช่ LLM

สำหรับงาน SOC มีข้อจำกัดสามข้อที่มักตัด hosted model ขนาดใหญ่ออกไป:

• ข้อมูลต้องอยู่ภายในประเทศ/องค์กร (Data residency) — ลูกค้าองค์กรในอุตสาหกรรมที่มีการกำกับดูแลเข้มงวดมักไม่อนุญาตให้ log ความปลอดภัยดิบออกนอกเครือข่าย ทำให้โมเดลแบบ API ของผู้ให้บริการ frontier ส่วนใหญ่ใช้ไม่ได้
• Latency และต้นทุนเมื่อใช้งานปริมาณมาก — การให้คะแนน alert cluster หลายพันรายการต่อวันต้องการโมเดลที่เร็วและถูกต่อการเรียกใช้ ไม่ใช่โมเดลที่คิดราคาต่อ token ในอัตรา frontier
• งานไม่ต้องการการให้เหตุผลระดับ frontier — การจัดหมวดหมู่ alert burst ตาม MITRE ATT&CK หรือเขียนสรุปเหตุการณ์สองประโยค อยู่ในความสามารถของโมเดล 7B–14B ที่ prompt ดีอยู่แล้ว

โมเดลอย่าง Llama 3.1 8B, Qwen2.5 14B หรือ Phi-4 ที่รันในองค์กรผ่าน vLLM หรือ Ollama ให้จุดสมดุลที่เหมาะสม: ทำตามคำสั่งได้ดีพอสำหรับ output แบบ JSON ที่มีโครงสร้าง และเล็กพอที่จะรันบน GPU เครื่องเดียวภายในเครือข่ายของลูกค้าเอง

SLM อยู่ตรงไหนใน pipeline

ข้อผิดพลาดที่ควรเลี่ยงคือการป้อน log ดิบเข้าโมเดลโดยตรง เพราะ Wazuh และ firewall ทำ normalization ให้อยู่แล้ว งานของ SLM ควรเริ่มหลังขั้นตอน aggregation ไม่ใช่ก่อนหน้านั้น

flowchart TD
    A["Wazuh agent + FortiGate syslog"] --> B["Wazuh manager: จับคู่ rule และ normalize"]
    B --> C["OpenSearch: รวม alert ตาม source IP / ช่วงเวลา"]
    C --> D["SLM scoring service: จัดหมวดหมู่, สรุป, จับคู่กับ MITRE ATT&CK"]
    D --> E["DFIR-IRIS: สร้าง case พร้อมข้อมูลเสริม"]
    E --> F["Shuffle SOAR: แยกเส้นทางตามผลของ SLM"]
    F --> G["PagerDuty: ส่งต่อให้นักวิเคราะห์"]

Alert ของ Wazuh เป็น JSON ที่มีโครงสร้างอยู่แล้ว — rule ID, ระดับความรุนแรง, agent, source/destination IP และ raw log ให้รวม alert ที่เกี่ยวข้องกันเป็นช่วงเวลาสั้น ๆ (เช่น ห้านาที จัดกลุ่มตาม source IP หรือ user) ก่อนส่งเข้าโมเดล วิธีนี้ทำให้ SLM ให้เหตุผลกับลำดับเหตุการณ์ที่กระชับ แทนที่จะแกะข้อความจำนวนมาก ซึ่งช่วยทั้งลดต้นทุนและเพิ่มความแม่นยำ

SLM เก่งเรื่องอะไรจริง ๆ

Rule engine แม่นยำแต่ตายตัว มันเก่งเรื่อง "log pattern นี้เกิดขึ้นแล้ว" แต่อ่อนเรื่อง "ลำดับเหตุการณ์ที่ดูธรรมดาเหล่านี้รวมกันแล้วเหมือนการโจมตีที่กำลังดำเนินอยู่" ช่องว่างนี้แหละที่ SLM เข้ามาเพิ่มมูลค่าได้:

• สรุปเหตุการณ์ — เปลี่ยน alert ที่เกี่ยวข้องกันสิบสองรายการให้เป็นสรุปภาษาที่เข้าใจง่ายสองประโยค ให้นักวิเคราะห์เวร on-call อ่านได้ในห้าวินาที แทนที่จะไล่ดู raw log
• การให้เหตุผลข้าม log แหล่งต่าง ๆ — เชื่อมโยงการปฏิเสธการเชื่อมต่อจาก FortiGate ที่เกิดถี่ ๆ กับการ login ล้มเหลวใน Wazuh จาก source IP เดียวกันในเวลาต่อมา และอธิบายว่าทำไมรูปแบบนี้คล้าย password spraying หรือ credential stuffing — การให้เหตุผลแบบนี้ correlation rule แบบตายตัวมักพลาด เว้นแต่จะมีคนเขียน rule เฉพาะสำหรับ combination นั้นไว้ล่วงหน้า
• ลด false positive — ให้คะแนน alert โดยอิงบริบทสั้น ๆ ที่ฝังไว้ (ความสำคัญของ asset, ช่วงเวลาบำรุงรักษาที่ทราบล่วงหน้า, พฤติกรรมของแอดมินที่คาดไว้) เพื่อลด noise ก่อนที่จะเปิด case ใน DFIR-IRIS

Output ต้องมีโครงสร้าง ไม่ใช่ข้อความอิสระ

โมเดลไม่ควรตอบกลับเป็นย่อหน้าให้ SOAR ต้องมาแกะด้วย regex ให้ prompt ให้ส่งกลับเป็น JSON ที่เข้มงวด:

{
  "severity": "high",
  "mitre_technique": "T1110.003 - Password Spraying",
  "summary": "17 failed logins across 4 accounts from a single external IP within 6 minutes, followed by one successful login.",
  "recommended_action": "disable_account_and_escalate",
  "confidence": 0.82
}

จากนั้น Shuffle สามารถแยกเส้นทางตามฟิลด์ severity และ recommended_action ได้โดยตรง ส่ง case ที่ความรุนแรงสูงและความมั่นใจสูงไปที่ PagerDuty ทันที ส่วน case ที่ความมั่นใจต่ำกว่าจะเข้าคิวให้นักวิเคราะห์ตรวจสอบ

Guardrail สำคัญกว่าความแม่นยำ

การตัดสินใจออกแบบที่สำคัญที่สุดคือ กำหนดว่าโมเดล ห้าม ทำอะไร SLM ใน pipeline ของ SOC ควรทำหน้าที่ให้คำแนะนำเท่านั้น — สรุป จัดหมวดหมู่ และเสนอแนะ แต่ไม่ปิด case หรือแก้ไขระบบเองโดยอัตโนมัติ ต้องมีนักวิเคราะห์มนุษย์ตรวจสอบทุกกรณีที่เกินระดับความรุนแรงที่กำหนดไว้ นี่ไม่ใช่แค่ความระมัดระวังเฉย ๆ แต่เป็นตัวกำหนดว่ากระบวนการ SOC จะอธิบายได้หรือไม่หาก false negative เกิดขึ้นระหว่างการตรวจสอบของลูกค้า

เริ่มต้นได้แม้ไม่มีข้อมูลติดป้าย (labeled data)

องค์กรส่วนใหญ่ไม่มีชุดข้อมูล "alert cluster → ผลลัพธ์ที่ถูกต้อง" ที่พร้อมสำหรับ fine-tune ไม่เป็นไร เริ่มต้นด้วย few-shot prompting ที่ดี — ตัวอย่าง alert cluster ไม่กี่ชุดพร้อมการจับคู่ MITRE และระดับความรุนแรงที่ถูกต้อง ฝังไว้ใน system prompt ร่วมกับคำอธิบาย rule เฉพาะขององค์กร — ก็ทำให้โมเดล 7B–14B ได้ความแม่นยำที่ใช้งานได้ทันที ส่วนการ fine-tune จะคุ้มค่าเมื่อสะสมเคสจริงที่นักวิเคราะห์ยืนยันแล้วได้สักสองสามร้อยเคส

ผลลัพธ์คือ pipeline ของ SOC ที่ Wazuh และ firewall ยังคงทำหน้าที่ที่ถนัดที่สุด — การตรวจจับที่รวดเร็วและแน่นอน — ในขณะที่ SLM รับผิดชอบชั้นการให้เหตุผลที่ซับซ้อนและอิงบริบทมากขึ้น ซึ่งแต่เดิมต้องพึ่งนักวิเคราะห์ที่เหนื่อยล้ามองจอตอนตีสอง