ใช้ LLM ในงาน Security Operations ได้จริงแค่ไหน และจุดไหนยังไม่ควรฝากความหวัง

ช่วงหลังผมเห็นหลายทีมเริ่มถามคำถามคล้ายกันว่า "เอา LLM มาใช้ในงาน Security Operations ได้จริงแค่ไหน" บางคนคาดหวังว่า AI จะช่วยลด alert fatigue ได้ทันที บางคนกลัวว่าถ้าเอา AI มาแตะ log หรือ incident ticket จะกลายเป็นความเสี่ยงใหม่มากกว่าประโยชน์

ผมคิดว่าคำตอบที่ตรงที่สุดคือ ใช้ได้จริง แต่ต้องวางบทบาทให้ถูก LLM เหมาะกับงานที่ต้องอ่านเยอะ สรุปเยอะ แปลงภาษาเยอะ และช่วยเตรียมข้อมูลให้ analyst ตัดสินใจต่อ แต่ยังไม่ควรฝากความหวังกับงานที่ต้องใช้ judgement สูง เช่น ปิด incident, ลดระดับ severity, isolate เครื่อง production, แจ้งลูกค้า, หรือสั่ง remediation ที่กระทบระบบจริง

สาระตั้งต้นจากแหล่งข้อมูล

ก่อนเขียนให้เป็นบทความ ผมแยกแก่นของเรื่องนี้ออกมาก่อน:

1. LLM มีประโยชน์กับงาน security ที่มีข้อมูลกระจัดกระจายและต้องแปลงให้อ่านง่าย เช่น alert, log, ticket, timeline และ report
2. งานที่ LLM ช่วยได้ดีมักเป็น "เตรียมข้อมูล" ไม่ใช่ "ตัดสินแทน"
3. Microsoft รายงานผลการใช้งาน Security Copilot หลายชุดว่า generative AI ช่วยให้ analyst ทำงานบางประเภทเร็วขึ้น เช่น response time ดีขึ้นใน randomized controlled trial ปี 2023 และ product page ล่าสุดยังพูดถึง phishing triage agent ที่ช่วยหา malicious emails ได้เร็วขึ้นในบริบทการทดสอบภายใน
4. แต่แหล่งอย่าง NCSC, OWASP, NIST และ CISA ย้ำเหมือนกันว่า generative AI มีความเสี่ยงเฉพาะ เช่น prompt injection, sensitive information disclosure, data poisoning, excessive agency, misinformation และ governance ที่ต้องออกแบบตั้งแต่ต้น
5. ดังนั้นโจทย์ไม่ใช่ "ควรใช้ AI หรือไม่" แต่คือ "จะใช้กับงานไหน ภายใต้ขอบเขตข้อมูล สิทธิ์ และการตรวจทานแบบใด"

ถ้าเขียนให้ง่ายขึ้นสำหรับคนทำงานจริง ประโยคหลักคือ LLM เป็นผู้ช่วยที่ดีสำหรับการจัดโต๊ะทำงานของ analyst แต่ยังไม่ควรเป็นคนกดปุ่มสุดท้ายแทน analyst

จุดที่ LLM ช่วย SOC ได้จริง

งาน Security Operations มีปัญหาเดิมอยู่หลายอย่าง: alert เยอะเกิน, ข้อมูลอยู่หลายระบบ, log อ่านยาก, ticket เขียนไม่สม่ำเสมอ, knowledge base หาไม่เจอ และ analyst ต้องเสียเวลารวมข้อมูลก่อนเริ่มวิเคราะห์จริง

ตรงนี้ LLM ช่วยได้ค่อนข้างชัด เพราะมันถนัดการอ่านข้อมูลจำนวนมากแล้วสรุปเป็นรูปแบบที่คนเข้าใจง่าย ตัวอย่างที่ practical มีหลายแบบ

1. สรุป alert หลายรายการให้เป็นภาพเดียวว่าเกิดอะไรขึ้น ใครเกี่ยวข้อง ระบบไหนได้รับผลกระทบ และ timeline เบื้องต้นเป็นอย่างไร
2. ช่วยจัดกลุ่ม alert ที่คล้ายกัน เพื่อลด noise ก่อนส่งต่อให้ analyst ตรวจ
3. แปลง query จากภาษาคนเป็น KQL, SPL, SQL หรือ query ของเครื่องมือที่ทีมใช้อยู่ โดยให้คนตรวจ syntax และ logic อีกครั้ง
4. ช่วยร่าง incident report ฉบับแรกจาก ticket note, log snippet, finding และ action ที่ทำไปแล้ว
5. ช่วยแปลภาษาทางเทคนิคให้ทีมอื่นเข้าใจ เช่น อธิบาย impact ให้ผู้บริหารหรือ owner ของระบบอ่านรู้เรื่อง
6. ช่วยดึง runbook หรือ policy ที่เกี่ยวข้องมาเป็น checklist ให้ analyst ไม่ลืมขั้นตอนสำคัญ

ประโยชน์ของ LLM ในงานเหล่านี้ไม่ใช่การทำให้ analyst ไม่ต้องคิด แต่คือทำให้ analyst ใช้เวลาคิดกับเรื่องที่ควรคิดมากขึ้น แทนที่จะเสียเวลา copy log, รวม timeline, หรือเขียน summary ซ้ำ ๆ

จุดที่ยังต้องมีคนคุม

ปัญหาของ LLM คือมันตอบได้เร็วและดูมั่นใจ แม้บางครั้งจะตีความผิด สรุปตกหล่น หรือเติมรายละเอียดที่ไม่มีในหลักฐานจริง ในงานทั่วไปอาจแค่เสียเวลา แต่ใน Security Operations ผลเสียอาจหนักกว่า เช่น ปิด incident เร็วเกินไป, มองข้าม lateral movement, สรุป root cause ผิด, หรือส่งข้อมูลอ่อนไหวให้ผิดกลุ่ม

ผมจึงมองว่าอย่างน้อย 5 เรื่องนี้ยังต้องมีคนรับผิดชอบชัดเจน

1. Severity และ business impact

AI อาจช่วยสรุปว่า alert เกี่ยวกับระบบใดและมี indicator อะไรบ้าง แต่การตัดสินว่า incident นี้ critical หรือ high ต้องดูบริบทองค์กร เช่น ระบบนั้นเป็น production หรือไม่ มีข้อมูลลูกค้าหรือไม่ อยู่ในช่วง change window หรือไม่ และมีข้อผูกพันด้านกฎหมายหรือสัญญาหรือเปล่า

2. Containment และ remediation

การ isolate endpoint, disable account, block domain, rotate key หรือปิด service เป็น action ที่กระทบงานจริง LLM อาจเสนอทางเลือกได้ แต่ไม่ควรมีสิทธิ์ทำ action เหล่านี้เองโดยไม่มี approval gate โดยเฉพาะในระบบที่ย้อนกลับยาก

3. ข้อมูลอ่อนไหว

CISA และพันธมิตรออกแนวทาง AI Data Security ในปี 2025 โดยเน้นว่าข้อมูลที่ใช้ train, test และ operate ระบบ AI ต้องถูกป้องกันอย่างจริงจัง เพราะข้อมูลไม่ดีหรือรั่วไหลจะกระทบทั้งความถูกต้องและความน่าเชื่อถือของผลลัพธ์ ในบริบท SOC ข้อมูลที่ต้องระวังมีทั้ง log ภายใน, incident ticket, customer data, vulnerability detail, credential, token, source code และข้อมูลส่วนบุคคล

4. Prompt injection และข้อมูลภายนอก

NCSC อธิบายไว้ชัดว่า prompt injection ไม่เหมือน SQL injection เพราะปัญหาพื้นฐานคือ LLM ไม่ได้มี security boundary ที่แข็งแรงระหว่างคำสั่งกับข้อมูลที่ไม่น่าเชื่อถือใน prompt เดียวกัน ถ้า AI อ่าน email, web page, PDF, ticket หรือ attachment จากภายนอก คำสั่งแฝงอาจถูกซ่อนอยู่ในข้อมูลเหล่านั้นได้

5. การสื่อสารนอกทีม

LLM ช่วยร่างข้อความแจ้งผู้บริหาร ลูกค้า หรือทีม operation ได้ แต่ข้อความสุดท้ายต้องผ่านคนที่เข้าใจ impact จริง เพราะภาษา incident communication ต้องแม่นทั้งข้อเท็จจริง ความเสี่ยง สิ่งที่ยังไม่รู้ และสิ่งที่กำลังทำ

ใช้ LLM ใน SOC แบบไม่เสี่ยงเกินจำเป็น

วิธีเริ่มที่ผมคิดว่าเหมาะคือเริ่มจาก use case ที่ "อ่านได้ แต่ยังไม่เขียนกลับ" ก่อน เช่น summarisation, enrichment, report draft, query suggestion และ runbook lookup อย่าเพิ่งเริ่มจาก automation ที่สั่ง block, delete, isolate หรือ notify ลูกค้าทันที

แนวทางที่ควรมีตั้งแต่แรก:

1. กำหนด use case ชัดว่า AI ทำอะไรได้และทำอะไรไม่ได้
2. แยกข้อมูลตามระดับความอ่อนไหว และ redact ก่อนส่งเข้าเครื่องมือภายนอก
3. ให้ AI แสดง source หรือหลักฐานที่ใช้สรุป ไม่ใช่ให้ตอบลอย ๆ
4. บังคับ human approval สำหรับ action ที่กระทบระบบ ลูกค้า เงิน ข้อมูลส่วนบุคคล หรือ compliance
5. จำกัดสิทธิ์ tool และ connector ด้วยหลัก least privilege
6. เก็บ log ของ prompt, output, tool call และ approval decision เท่าที่เหมาะกับ policy
7. ทดสอบ failure mode เช่น prompt injection, hallucination, missing context และข้อมูลเก่าหรือผิดใน knowledge base
8. วัดผลด้วย metric ที่ practical เช่น time to triage, report quality, analyst satisfaction, false positive handling และจำนวน incident ที่ต้องแก้งานซ้ำ

NIST AI RMF และ Generative AI Profile ช่วยเป็นกรอบคิดที่ดี เพราะไม่ได้บอกแค่ว่า AI ดีหรือไม่ดี แต่ชวนให้ govern, map, measure และ manage ความเสี่ยงตามบริบทการใช้งานจริง

ใช้กับงานไหนก่อนดี

ถ้าเป็นทีมเล็ก ผมจะเริ่มจาก 3 งานนี้ก่อน

งานแรกคือ incident summarisation ให้ AI สรุป ticket note และ log ที่ analyst เลือกมาแล้ว จากนั้นให้ analyst ตรวจว่า timeline, affected asset, observed indicator และ next action ถูกต้องหรือไม่ งานนี้ลดเวลาการเขียนเอกสารได้ แต่ยังคุม source ได้ดี

งานที่สองคือ query assistance ให้ AI ช่วยร่าง query จากคำถาม เช่น "หา failed login จาก account นี้ใน 24 ชั่วโมงล่าสุด" แล้วให้ analyst ตรวจ query ก่อน run วิธีนี้ช่วย junior analyst เรียนรู้เครื่องมือได้เร็วขึ้น แต่ไม่ควรปล่อยให้ AI run query ที่ดึงข้อมูลกว้างเกินจำเป็นโดยไม่มีขอบเขต

งานที่สามคือ runbook checklist ให้ AI ดึงขั้นตอนที่เกี่ยวข้องจากเอกสารภายใน เช่น phishing triage, malware alert, suspicious login หรือ data leakage แล้วแสดงเป็น checklist พร้อม link กลับไปยัง source วิธีนี้ช่วยลดการลืมขั้นตอน แต่ต้องมั่นใจว่า knowledge base มี owner และอัปเดตจริง

สิ่งที่ไม่ควรรีบทำ

ผมจะระวังเป็นพิเศษกับการให้ LLM ทำสิ่งเหล่านี้โดยอัตโนมัติ:

1. ปิด incident หรือ downgrade severity เอง
2. ส่ง email แจ้งลูกค้าหรือผู้บริหารเอง
3. isolate เครื่อง production โดยไม่มีคนอนุมัติ
4. สร้าง firewall rule หรือ block rule จากข้อมูลที่ยังไม่ตรวจ
5. ดึงข้อมูล log ขนาดใหญ่ที่มีข้อมูลส่วนบุคคลเข้า external AI โดยไม่มี data policy
6. ใช้ knowledge base ที่ใครก็แก้ได้เป็น source สำคัญโดยไม่มี review

เหตุผลไม่ใช่เพราะ LLM ใช้ไม่ได้ แต่เพราะผลเสียของการทำผิดสูงกว่าประโยชน์ของการประหยัดเวลาไม่กี่นาที

สรุป

LLM ใน Security Operations ไม่ใช่เวทมนตร์ที่แก้ปัญหา SOC ได้ทั้งหมด แต่ก็ไม่ใช่ของเล่นที่ควรมองข้าม ประโยชน์จริงอยู่ที่การลดงานอ่านซ้ำ สรุปข้อมูล ร่างเอกสาร ช่วย query และทำให้ analyst เห็นบริบทเร็วขึ้น

จุดสำคัญคืออย่าออกแบบจากความสามารถของ model อย่างเดียว ให้เริ่มจาก workflow จริง: งานไหนซ้ำ งานไหนตรวจง่าย งานไหนย้อนกลับได้ งานไหนเสี่ยงถ้าผิด และใครเป็นคนรับผิดชอบ decision สุดท้าย

ถ้าทีมเริ่มจาก use case เล็ก มี data boundary ชัด มี source ให้ตรวจ มี approval gate และมี log ย้อนกลับได้ LLM จะเป็นเครื่องมือที่ช่วย SOC ได้จริง แต่ถ้าเริ่มจากการให้ AI แตะข้อมูลทุกอย่างและทำ action ได้กว้างโดยไม่มี governance ปัญหาจะไม่ใช่ว่า AI ฉลาดพอหรือไม่ แต่คือไม่มีใครรู้ว่ามันเห็นอะไร เชื่ออะไร และทำอะไรแทนเราไปแล้วบ้าง

อ่านต่อที่เกี่ยวข้อง

• ถ้าอยากมองภาพรวมความเสี่ยง AI ในองค์กร อ่าน ความเสี่ยงจากการใช้ AI: ตั้งแต่ Deepfake, Prompt Injection ไปจนถึง Agent ที่มีสิทธิ์เกินจำเป็น
• ถ้าอยากต่อยอดเรื่อง AI agent ในงาน security อ่าน AI Agent กับ Cybersecurity: ผู้ช่วยที่ดี หรือ Attack Surface แบบใหม่
• ถ้าอยากปูพื้นเรื่องการลด implicit trust อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง

แหล่งอ้างอิง

• Microsoft Security Blog: Security Copilot improves speed and efficiency for security and IT teams
• Microsoft Security Copilot product page
• NCSC: Prompt injection is not SQL injection
• OWASP: Top 10 for Large Language Model Applications
• CISA: AI Data Security - Best Practices for Securing Data Used to Train & Operate AI Systems
• NIST: AI Risk Management Framework
• NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile