SIEM กับ SOAR คืออะไร อธิบายด้วยภาพห้องครัวสำหรับมือใหม่

SIEM กับ SOAR มีภาพลักษณ์ที่ไม่ค่อยดีนัก ราคาแพง ต้อง tuning หลายสัปดาห์กว่าจะใช้งานได้จริง และหลายทีมจบลงด้วย dashboard ที่เต็มไปด้วย alert ที่ไม่มีใครเชื่อถือครับ แนวทางของหน่วยงานรัฐก็พูดเรื่องเดียวกันแต่สุภาพกว่า คือทั้งสองแพลตฟอร์มไม่ใช่เครื่องมือแบบ "set and forget" และต้องมีคนที่มีทักษะคอยดูแลให้มันทำงานได้ (ASD/CISA executive guidance หัวข้อ 3)

บทความนี้จึงไม่เริ่มจากผลิตภัณฑ์ แต่เริ่มจากห้องครัว log คือ วัตถุดิบ SIEM คือ ห้องครัว ที่วัตถุดิบถูกล้าง หั่น และนำมารวมกันเป็นอาหาร ส่วน SOAR คือ การ์ดสูตรอาหาร ที่แปะไว้บนผนัง บอกผู้ช่วยว่าต้องทำอะไรเมื่อมีออร์เดอร์แบบหนึ่งเข้ามา ถ้าจำภาพนี้ไว้ ศัพท์เทคนิคส่วนใหญ่จะเข้าที่เองครับ

คำศัพท์พื้นฐาน: log, event และ alert

นิยามที่ตรงไปตรงมาที่สุดยังอยู่ใน SP 800-92, Guide to Computer Security Log Management ของ NIST ที่เผยแพร่เมื่อกันยายน พ.ศ. 2549 เอกสารนี้นิยาม log ว่าเป็นบันทึกของ event ที่เกิดขึ้นในระบบและเครือข่ายขององค์กร log ประกอบด้วย log entry และแต่ละ entry เก็บข้อมูลของ event หนึ่งรายการ (SP 800-92 บทสรุปผู้บริหาร) entry เหล่านี้มาจากซอฟต์แวร์ด้าน security เช่น firewall และ intrusion prevention system มาจากระบบปฏิบัติการ และมาจากแอปพลิเคชัน

alert เป็นคนละเรื่องกัน คือการที่ระบบบอกคนว่ามีบางอย่างต้องเข้าไปดู SP 800-92 ผูก alert ไว้กับ correlation เมื่อ correlate entry ที่เกี่ยวข้องกันแบบอัตโนมัติ ผลลัพธ์โดยทั่วไปคือ entry ใหม่ที่รวมชิ้นส่วนไว้ในที่เดียว และขึ้นอยู่กับข้อมูลที่พบ ระบบอาจส่ง alert เพิ่มด้วยเพื่อบอกว่า event นี้ต้องตรวจสอบเพิ่มเติม (SP 800-92 หัวข้อ 3.2)

ถ้าเทียบกับครัว log entry หนึ่งรายการคือหัวหอมหนึ่งหัว event คือ "หัวหอมมาถึงแล้ว" และ alert คือใบออร์เดอร์ที่เชฟวางไว้ที่ช่องส่งอาหารว่า "โต๊ะ 7 ต้องดูเดี๋ยวนี้" ครับ

SP 800-92 เก่าแต่ไม่ได้ถูกทิ้ง NIST เผยแพร่ร่างฉบับปรับปรุงชื่อ Cybersecurity Log Management Planning Guide (SP 800-92 Rev. 1) เมื่อตุลาคม พ.ศ. 2566 และ ณ ตอนที่เขียนบทความนี้ยังเป็น initial public draft อยู่ (NIST CSRC)

SIEM: collect, normalise, correlate, alert

practitioner guidance ปี พ.ศ. 2568 จาก ASD ของออสเตรเลีย CISA และพันธมิตร อธิบาย SIEM ว่าเป็นซอฟต์แวร์ที่ รวบรวม รวมศูนย์ และวิเคราะห์ log เพื่องานด้าน security SIEM ที่ตั้งค่าดีจะเทียบข้อมูลกับ baseline ของกิจกรรมปกติ ร่วมกับ rule และ filter เพื่อหากิจกรรมที่ผิดปกติ (ASD/CISA practitioner guidance หัวข้อ 1) งานหลักมีสี่อย่าง เริ่มจากภาพในครัวก่อน

1. Collect (รับของเข้าครัว) SP 800-92 อธิบายไว้สองทาง คือ agentless ที่เซิร์ฟเวอร์ดึง log หรือเครื่องต้นทางส่ง log มาเอง และ agent-based ที่มีโปรแกรมเล็ก ๆ บนแต่ละเครื่องคอย filter และ normalise log ก่อนส่ง (SP 800-92 หัวข้อ 3.4)
2. Normalise (ล้างและหั่นทุกอย่างให้ขนาดเดียวกัน) แปลงแต่ละ field ให้อยู่ในรูปแบบเดียวกัน ตัวอย่างของ NIST เองคือเวลา แหล่งหนึ่งเขียน 2:34:56 P.M. EDT อีกแหล่งเขียน 14:34 แล้วแยก time zone ไว้อีก field (SP 800-92 หัวข้อ 3.2) แนวทางปี พ.ศ. 2568 ให้ตัวอย่างที่ใหม่กว่า คือแหล่งหนึ่งใช้ src_ip อีกแหล่งใช้ sourceAddress และ SIEM ต้องรู้ว่าสองชื่อนี้หมายถึงสิ่งเดียวกัน (practitioner guidance หัวข้อ 3)
3. Correlate (นำวัตถุดิบมารวมเป็นจาน) NIST นิยาม event correlation ว่าเป็นการหาความสัมพันธ์ระหว่าง log entry สองรายการขึ้นไป แบบที่พบบ่อยที่สุดคือแบบ rule-based ที่จับคู่ entry ด้วย timestamp, IP address และประเภทของ event (SP 800-92 หัวข้อ 3.2) ขั้นตอนที่ใกล้เคียงกันคือ aggregation ตัวอย่างของ NIST คือการยุบ entry หนึ่งพันรายการจากการสแกนครั้งเดียว ให้เหลือ entry เดียวที่บอกว่าสแกนไปกี่เครื่อง
4. Alert (ใบออร์เดอร์ที่ช่องส่งอาหาร) อาหารถูกส่งไปให้คน

 SIEM: collect · normalise · correlate · alert                  
                        \                                       
┌──────────┐              \                                     
│ FIREWALL▪│─·─────────·    \                                   
└──────────┘                  \            ┌─ ALERT ───────────┐
                               \           │                   │
                             ∙   \         │                   │
┌──────────┐                       \────── │ watching.         │
│ ENDPOINT▪│──·──────·──                   │                   │
└──────────┘                       /────── │                   │
                             ∙   /         │                   │
                               /           │                   │
┌──────────┐                  /            └───────────────────┘
│ CLOUD   ▪│───·──────·─    /  correlate                        
└──────────┘              /                alerts: 0            
                        /                  many in, few out     
                      normalise                                 
 in: 43 events/s                                                

ภาพเคลื่อนไหวนี้แสดงหัวใจของกรวย คือ เข้ามาเยอะ ออกไปน้อย firewall deny ครั้งเดียวไม่น่าสนใจ process ใหม่หนึ่งตัวก็เช่นกัน แต่ถ้าทั้งสามอย่างเกิดกับเครื่องเดียวกันในเวลาใกล้กัน ก็คุ้มที่คนจะเข้าไปดูครับ

แนวคิดเดียวกันนี้เห็นได้ในเอกสารของผลิตภัณฑ์เชิงพาณิชย์ด้วย Microsoft อธิบาย Sentinel ว่าเป็น cloud-native SIEM ที่ normalise ข้อมูลจากหลายแหล่งทั้งตอน ingest และตอน query (โมเดล ASIM) และใช้ analytics จัดกลุ่ม alert เป็น incident เพื่อลด noise (Microsoft Learn)

SOAR: การ์ดสูตรอาหาร

แนวทางของ ASD/CISA อธิบาย SOAR ว่าเป็นแพลตฟอร์มที่ทำให้การตอบสนองต่อกิจกรรมผิดปกติเป็นอัตโนมัติ โดยใช้ playbook ที่กำหนดไว้ล่วงหน้า ซึ่งระบุ action บางอย่างที่ต้องทำเมื่อเกิด security event แบบหนึ่ง แนวทางเขียนไว้ชัดว่า action อัตโนมัติเหล่านี้ ไม่ได้มาแทนที่ incident responder ที่เป็นคน แต่รับบางขั้นตอนไปทำ เพื่อให้ทีมไปโฟกัสกับปัญหาที่ยากกว่า (practitioner guidance หัวข้อ 1 และ 2) SOAR บางตัวมี SIEM อยู่ในตัว อีกหลายตัวทำงานบน SIEM ที่แยกกัน

นี่คือการ์ดสูตรอาหาร เมื่อออร์เดอร์แบบ X เข้ามา ผู้ช่วยทำตามการ์ด ดูข้อมูลลูกค้า ถามเชฟ จัดจาน แล้วส่งออกไป ในภาษา security playbook หนึ่งอาจเติมข้อมูล user และ host ให้ alert (enrich) ให้ analyst ตัดสินใจ isolate เครื่อง แล้วเปิด ticket

 SOAR playbook: the recipe card       case notes                
                                     ┌─────────────────────────┐
    ┆   ┌────────────────────────┐   │                         │
 [!]┆   │ 1 ENRICH   auto        │   │                         │
    ┆   └────────────────────────┘   │                         │
    ┆                                │                         │
    ┆   ┌────────────────────────┐   │                         │
    ┆   │ 2 DECIDE   analyst     │   │                         │
    ┆   └────────────────────────┘   │                         │
    ┆                                │                         │
    ┆   ┌────────────────────────┐   │                         │
    ┆   │ 3 CONTAIN  auto        │   └─────────────────────────┘
    ┆   └────────────────────────┘                              
    ┆                                 steps run in order        
    ┆   ┌────────────────────────┐                              
    ┆   │ 4 TICKET   auto        │    repeatable steps: auto    
    ┆   └────────────────────────┘    judgement: a person       
                                                                

ตัวอย่างใน Microsoft Sentinel คือ playbook เป็น workflow ที่สร้างใน Azure Logic Apps รันได้ทั้งแบบสั่งเอง และแบบอัตโนมัติเมื่อ automation rule ทริกเกอร์จาก alert หรือ incident และมี connector สำหรับเปิด ticket ในระบบอย่าง ServiceNow หรือ Jira (Microsoft Learn)

แนวทางยังระบุความเสี่ยงไว้ด้วย SOAR ที่ตั้งค่าไม่ดีอาจเข้าใจพฤติกรรมปกติผิดว่าเป็น incident แล้ว isolate ระบบโดยอัตโนมัติ ทำให้ธุรกิจสะดุด ด้วยเหตุนี้แนวทางจึงบอกว่า SOAR มัก ไม่เหมาะกับสภาพแวดล้อมที่ยังไม่พร้อม (ยังไม่มี SIEM, SIEM เพิ่งตั้ง หรือไม่มีทีมที่มีประสบการณ์) ต้องทำ SIEM ให้ดีก่อน (practitioner guidance หัวข้อ 3) key action ข้อหนึ่งใน executive guidance สรุปไว้ในบรรทัดเดียวว่า ให้ทดสอบ SIEM ก่อน deploy SOAR (executive guidance)

นี่คือเหตุผลที่ playbook ในภาพเคลื่อนไหวมีขั้นตอนของคนอยู่ตรงกลาง การทำสูตรที่ไม่เคยลองทำด้วยมือให้เป็นอัตโนมัติ คือวิธีเผาครัวทั้งครัวครับ

ซื้อของจำเป็นก่อน: priority logs

เอกสารฉบับที่สามในชุดปี พ.ศ. 2568 คือ Priority logs for SIEM ingestion ซึ่งเปรียบได้กับรายการซื้อของ เอกสารเรียงแหล่ง log ตามลำดับความสำคัญแบบ หลวม ๆ ผู้เขียนบอกตรง ๆ ว่ารายการนี้ไม่ครบ ลำดับไม่ได้เหมาะกับทุกองค์กร และเป็นจุดเริ่มต้นสำหรับเครือข่ายองค์กรทั่วไป ลำดับมีดังนี้

คำแนะนำรอบ ๆ รายการสำคัญไม่แพ้ตัวรายการครับ

• ค่อย ๆ เพิ่ม เพิ่มแหล่งข้อมูลทีละน้อย ไม่ใช่เปิดทั้งหมดพร้อมกัน
• ไม่เก็บ log เพียงเพื่อให้ได้เก็บ แต่ละแหล่งต้องคิดถึงจุดประสงค์ ลำดับความสำคัญ ปริมาณที่สร้างขึ้น และคุณค่าต่อการวิเคราะห์ แนวทางชี้ว่า log ของ firewall หรือ DNS อาจมีปริมาณมากจนกลบข้อมูลที่มีประโยชน์ในตัวมันเอง
• SIEM ไม่ใช่ห้องเก็บของ หน่วยงานผู้เขียนไม่สนับสนุนอย่างยิ่งให้ใช้ SIEM เป็นที่เก็บ log ทั้งหมด แบบรวมศูนย์ log ที่เก็บเพื่อ compliance ไปอยู่ใน data lake หรือ storage ที่ถูกกว่าได้ และควรส่งเฉพาะ log ที่เกี่ยวกับ security เข้า SIEM

practitioner guidance อธิบายว่าเรื่องนี้กระทบงบประมาณอย่างไร คือ SIEM ส่วนใหญ่คิดราคาตามปริมาณ log ที่ ingest และค่า default บางอย่างก็ดันตัวเลขนี้ให้สูงขึ้น (practitioner guidance หลักข้อ 4) สำหรับองค์กรที่เพิ่งเริ่มทำ detection แนวทางยังเสนอจุดเริ่มต้นของ retention ไว้ คืออย่างน้อยหนึ่งปีสำหรับ log ด้าน administrative และ security และ 90 วันสำหรับ log เชิงข้อมูลทั่วไป (หลักข้อ 7)

สูตรที่พกไปใช้ครัวไหนก็ได้: Sigma

ถ้า SIEM ทุกตัวมี query language ของตัวเอง detection ทุกตัวที่เขียนก็จะติดอยู่กับผลิตภัณฑ์เดียว Sigma พยายามแก้ปัญหานี้ README ของโปรเจกต์เรียกมันว่า signature format แบบเปิดและเป็นกลางสำหรับอธิบาย log event และเปรียบว่า Sigma เป็นของ log file แบบที่ Snort เป็นของ network traffic และ YARA เป็นของไฟล์ repository หลักมี detection rule มากกว่า 3,000 rule เผยแพร่ภายใต้ Detection Rule License (DRL) 1.1

Sigma rule คือไฟล์ YAML ส่วนที่ต้องมีคือ title, logsource (category, product, service) และบล็อก detection ที่มี condition (Sigma docs) ด้านล่างเป็น rule เล็ก ๆ ที่ผมเขียนขึ้นเพื่อเป็นตัวอย่างในบทความนี้ มันเฝ้าดู event "audit log cleared" ของ Windows (1102) ซึ่งอยู่ในรายการ Windows endpoint ของ priority logs guidance

title: Windows security log cleared
status: experimental
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 1102
    condition: selection
falsepositives:
    - Planned log maintenance by administrators
level: high

ตัวแปลงอย่างเป็นทางการคือ sigma-cli ซึ่งแปลง rule เป็น query language ของ SIEM แต่ละตัวผ่าน backend plugin เช่น sigma plugin install splunk แล้วตามด้วย sigma convert -t splunk -p sysmon <rules>

ตรงนี้เองที่ detection-as-code เข้ามาเกี่ยว เมื่อ detection เป็นไฟล์ข้อความ เราเก็บไว้ใน Git รีวิวการเปลี่ยนแปลง และทดสอบใน CI ได้เหมือนโค้ดแอปพลิเคชันครับ เอกสารของ Sigma อธิบายเรื่องนี้ไว้ในหัวข้อการนำ CI/CD มาใช้กับ detection workflow รวมถึงการทำ version control ให้ detection (Sigma docs) แนวทางของ ASD/CISA ก็พูดในทำนองเดียวกันว่า การทำ log event ให้เป็นมาตรฐานเดียวกันช่วยให้ใช้ detection rule ส่วนกลางจาก community หรือ vendor ได้ และ deploy ได้เร็วขึ้น (practitioner guidance หัวข้อ 2)

ทำไมพ่อครัวสำคัญกว่าเตาอบ

ส่วนที่มีประโยชน์ที่สุดของแนวทางชุดนี้ในความเห็นผม คือมันพูดเรื่องคนและการ tuning มากกว่าเรื่องฟีเจอร์ครับ

• การวิเคราะห์ที่ดีคือ true positive และ true negative มี alert เมื่อมีเหตุการณ์จริง และเงียบเมื่อไม่มีอะไร ข้อมูลน้อยไปหรือ rule อ่อนไปจะได้ false negative ข้อมูลมากไปและ rule ที่ส่งเสียงดังจะได้ false positive และ alert fatigue แนวทางบอกว่าปัญหาแบบหลังพบบ่อยกว่า เพราะทีมมักชอบเก็บข้อมูลมากเกินไป (practitioner guidance หัวข้อ 3)
• baseline ใช้เวลาเป็นสัปดาห์ ต้องรู้ก่อนว่าปกติหน้าตาเป็นอย่างไรจึงจะเห็นสิ่งผิดปกติ และการสร้าง baseline ใช้เวลาอย่างน้อยหลายสัปดาห์ของการเก็บข้อมูล query สืบสวน และ tuning (หลักข้อ 6) ถ้าเครือข่ายถูกเจาะอยู่แล้ว ก็มีความเสี่ยงที่กิจกรรมอันตรายจะถูกนับเป็นเรื่องปกติ
• ความเงียบอาจเป็นความผิดพลาด query ที่ล้มเหลวมักไม่คืนผลอะไรเลย ซึ่งดูเหมือน "ไม่มีอะไรต้องรายงาน" ทีมต้องมีวิธีรู้ตัวเมื่อระบบหยุดส่ง log (หลักข้อ 6 และ 7)
• วางแผนเรื่องคน ถ้าดูแลแพลตฟอร์มเอง ให้คาดว่าต้องมีพนักงานหลายคนทำงานเต็มเวลา รวมถึงการฝึกอบรมต่อเนื่อง (หัวข้อ 3 และหลักข้อ 5)
• ทดสอบ ซ้อมเป็นประจำด้วยเทคนิคของผู้โจมตีที่รู้จักกันดี เพื่อให้มั่นใจว่า log มาถึง alert ทำงาน และ playbook ทำในสิ่งที่คาดไว้ (หลักข้อ 11)

การชิมแล้วปรับรสไม่มีวันจบ เมนูเปลี่ยน ซัพพลายเออร์เปลี่ยน และลูกค้าที่พยายามแอบเข้าครัวก็เปลี่ยนไปด้วยครับ

มุมมองเริ่มต้นสำหรับทีมเล็ก

ถ้าคุณเป็นทีมเล็กที่กำลังดูเรื่องทั้งหมดนี้ นี่คือวิธีที่ผมจะอ่านแนวทางชุดนี้ เป็นข้อเสนอของผมเอง ไม่ใช่ checklist ทางการครับ

1. เขียนให้ชัดว่าต้องการ detect อะไร ก่อนเลือกผลิตภัณฑ์ แนวทางแนะนำให้ทำ proof of concept ที่กำหนดขอบเขต และมี system owner ที่ระบุชื่อชัดเจน (หลักข้อ 1)
2. เริ่มจากต้นรายการ priority EDR และอุปกรณ์เครือข่ายก่อน ตามด้วย identity (domain controller และ AD) และตรวจว่าแต่ละแหล่งมีประโยชน์จริงก่อนเพิ่มแหล่งถัดไป
3. แยกห้องเก็บของออกจากห้องครัว เก็บ log เพื่อ compliance ไว้ใน storage ที่ถูกกว่า ส่ง log ด้าน security เข้า SIEM
4. เขียน detection เป็นไฟล์ (Sigma หรือ format ของ SIEM เอง) และเก็บไว้ใน version control
5. เก็บ SOAR ไว้ทีหลัง และเมื่อเริ่ม ให้ทำขั้นตอนที่น่าเบื่อและเสี่ยงต่ำเป็นอัตโนมัติก่อน (enrichment, ticket) ก่อนจะทำอะไรที่ isolate เครื่อง

ถ้างบประมาณคืออุปสรรค ก็มีทางเลือกแบบ open source อยู่ Logging Made Easy ของ CISA เป็นแพลตฟอร์ม open source ไม่มีค่าใช้จ่าย สำหรับองค์กรขนาดเล็กและกลาง สร้างบน Wazuh, Elastic และ ElastAlert แต่ต้องระวังหนึ่งเรื่อง CISA ยุติการสนับสนุนไปเมื่อ 22 พฤษภาคม พ.ศ. 2569 ยังใช้งานต่อได้ แต่ CISA ไม่ดูแลแล้ว จึงควรมองเป็นห้องแล็บสำหรับเรียนรู้หรือโปรเจกต์ของ community มากกว่าผลิตภัณฑ์ที่มีคนซัพพอร์ตครับ

ห้องครัวจะทำงานได้ก็ต่อเมื่อวัตถุดิบสด พ่อครัวรู้จักเมนู และการ์ดสูตรอาหารผ่านการลองทำด้วยมือมาก่อน ผลิตภัณฑ์ช่วยได้ แต่มันคือเตาอบ ไม่ใช่เชฟครับ

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

• NIST SP 800-92, Guide to Computer Security Log Management (หน้า CSRC)
• NIST SP 800-92 (PDF)
• NIST SP 800-92 Rev. 1 (initial public draft), Cybersecurity Log Management Planning Guide
• CISA: Guidance for SIEM and SOAR Implementation
• ASD/CISA: Implementing SIEM and SOAR platforms, Executive guidance
• ASD/CISA: Implementing SIEM and SOAR platforms, Practitioner guidance
• ASD/CISA: Priority logs for SIEM ingestion, Practitioner guidance
• Microsoft Learn: What is Microsoft Sentinel SIEM?
• SigmaHQ: Sigma rule repository
• Sigma docs: Rules
• Sigma docs: About Sigma
• SigmaHQ: sigma-cli
• CISA: Logging Made Easy (GitHub)