SOAR บน Athena XDR — คู่มือใช้งานฉบับสมบูรณ์ (Playbooks, Nodes & ตัวอย่างจริง 4 แบบ)

SOAR (Security Orchestration, Automation and Response) คือโมดูลบน Sangfor Athena XDR ที่ช่วยให้ทีม Security สร้าง Workflow กึ่งอัตโนมัติเพื่อตอบสนองต่อ Security Incident และ Alert ได้อย่างเป็นระบบ ลดงานที่ต้องทำด้วยมือ (manual) และทำให้การจัดการภัยคุกคามเป็นแบบ Closed-Loop โดยทำงานร่วมกับอุปกรณ์/แอปที่เชื่อมต่อไว้ เช่น Firewall (Network Secure), Endpoint Secure และอุปกรณ์ของผู้ผลิตรายอื่น

บทความนี้เป็นคู่มือฉบับสมบูรณ์ อธิบายตั้งแต่แนวคิดพื้นฐาน องค์ประกอบ ข้อจำกัด เทคนิคการตั้งค่า ไปจนถึงตัวอย่างการสร้าง Playbook จริง 4 แบบแบบเป็นขั้นตอน เนื่องจาก SOAR เป็นหัวข้อที่ค่อนข้างซับซ้อน แนะนำให้อ่านส่วนแนวคิด (ข้อ 1–4) ก่อน แล้วจึงลงมือทำตามตัวอย่าง

1. SOAR คืออะไร และทำไมต้องใช้

SOAR ย่อมาจาก Security Orchestration, Automation and Response สิ่งสำคัญที่ต้องเข้าใจก่อนคือ:

โดยทั่วไปองค์กรมีกระบวนการจัดการเหตุการณ์ความปลอดภัยอยู่แล้ว แต่มักอยู่ในรูปเอกสาร/กระดาษ (paper-based) และทำด้วยมือ SOAR นำกระบวนการเหล่านั้นมา “เรียบเรียง (orchestrate)” ให้เป็น Workflow ดิจิทัล ดังตารางเทียบต่อไปนี้:

กระบวนการเดิม (ทำด้วยมือ / เอกสาร)	แปลงเป็นดิจิทัลด้วย SOAR (Orchestration)
ออกแบบขั้นตอนรับมือ (Design), ตั้งค่า (Configuration), ตรวจทาน (Review), บันทึก (Record)	โหนด Design / Configuration / Review / Record ใน Playbook
จับคู่เหตุการณ์ (Matching), คัดกรอง (Filtering), ตัดสินใจ (Decision), ตอบสนอง (Response)	โหนด Filter / Decision / Action และการทำงานอัตโนมัติของ Playbook
ผลลัพธ์อยู่ในรูปรายงาน/บันทึกด้วยมือ	บันทึกอัตโนมัติใน Execution History / Records

ข้อดีของ Athena XDR คือมี Predefined Playbook (Playbook สำเร็จรูป) สำหรับสถานการณ์ที่พบบ่อย ทำให้เริ่มใช้งานได้เร็วเพียงปรับพารามิเตอร์ไม่กี่จุด

2. SOAR ทำงานอย่างไร (SOAR Process)

เมื่อ Athena XDR ตรวจพบภัยคุกคาม ระบบจะไล่ทำงานตามลำดับ 7 ขั้นตอน ดังนี้:

1. Athena XDR ตรวจพบเหตุการณ์ (incident) ที่ถูกระบุว่าเป็นภัยคุกคาม
2. Athena XDR ค้นหา Playbook ที่ใช้ได้กับเหตุการณ์นั้น (query the applicable playbook)
3. ตรวจสอบว่าเหตุการณ์ตรงกับเงื่อนไข (conditions) ของ Playbook หรือไม่
4. ดำเนินมาตรการตอบสนองตาม Playbook ผ่านโหนดต่าง ๆ เช่น Action, Decision
5. จัดการ Application ที่เกี่ยวข้องเพื่อให้การทำงานสำเร็จ
6. เชื่อมต่อไปยัง Application ปลายทางผ่าน API, SSH หรือวิธีอื่น
7. ลงมือกระทำ (apply actions) กับอุปกรณ์/instance เป้าหมาย เช่น สั่ง Firewall บล็อก IP

กล่าวโดยสรุปคือ ภัยคุกคาม (Threat) → จับคู่ Playbook (Matching) → ทำงานเป็น Task (Action / Decision / Filter) → สั่งการผ่าน App (Firewall / EDR / Email ผ่าน API หรือ SSH) การจัดเรียงโหนดเหล่านี้ทำได้ในหน้า Playbook Editor:

3. องค์ประกอบและโหนด (Node) ต่าง ๆ ของ SOAR

3.1 Predefined Playbook (Playbook สำเร็จรูป)

Athena XDR มี Playbook สำเร็จรูปให้พร้อมใช้ เข้าถึงได้ที่ SOAR > Playbooks > Predefined Playbooks บนหน้านี้จะเห็น Playbook ทั้งหมด 32 ชุด แบ่งเป็น:

• Alert Playbooks (8 ชุด) — ถูกกระตุ้นด้วย Security Alert
• Incident Playbooks (10 ชุด) — ถูกกระตุ้นด้วย Security Incident
• Basic Playbooks (14 ชุด) — Playbook พื้นฐานที่เป็น “บล็อกตัวต่อ” ใช้เรียกจาก Playbook อื่นเท่านั้น

3.2 ประเภทของโหนด (Node Types)

ภายใน Playbook Editor มีโหนดให้ใช้ 7 ประเภท (แถบ Nodes ด้านซ้าย) แต่ละโหนดมีหน้าที่ต่างกัน:

โหนด (Node)	หน้าที่
Action	เรียกใช้ resource ของ Application เพื่อ query ข้อมูลหรือจัดการ incident/alert — ทำให้ไม่ต้องเรียกใช้ทรัพยากรทีละตัวด้วยมือ และตอบสนองแบบอัตโนมัติ
Playbook	นำ Playbook ที่มีอยู่มาใช้ซ้ำ — สร้าง Playbook ที่ซับซ้อนขึ้นได้อย่างรวดเร็วโดยประกอบจาก basic action
Filter	กรอง incident หรือ output ของขั้นก่อนหน้า เพื่อดึงเฉพาะข้อมูลที่ใช้ได้ไปใช้ต่อ — ตั้ง loop หลายเงื่อนไขแบบขนานได้
Decision	ประเมินผลลัพธ์เพื่อกำหนดขั้นตอนถัดไป (IF / loop) ทำให้เกิดการตัดสินใจอัตโนมัติ — ทำงานทางเดียว (one-way)
Review	ส่งเหตุการณ์ให้เจ้าหน้าที่ผู้มีสิทธิ์ตรวจทาน/อนุมัติด้วยตนเอง เหมาะกับ incident สำคัญหรือกรณีพิเศษ
Record	บันทึกข้อมูลด้วยมือบนโหนด เพื่อเก็บไว้อ้างอิงภายหลังหรือเป็นบทสรุป
End	จบการทำงานของ Playbook — แต่ละ Playbook มีได้เพียง 1 โหนด End

3.3 องค์ประกอบสนับสนุนอื่น ๆ

องค์ประกอบ	คำอธิบาย
Constants	ค่าคงที่ที่กำหนดไว้เพื่อนำไปอ้างอิงซ้ำใน Playbook เช่น กลุ่ม IP (IP group) หรือรายการ IP whitelist (เช่น constant ชื่อ Predefined-IP Whitelist ที่ใช้ในตัวอย่างท้ายบทความ)
Execution History	บันทึกการทำงานของแต่ละ Playbook และ Action ทำให้ปรับจูนและทบทวน Playbook ได้ง่าย
Execution Records	เรียงลำดับบันทึกการทำงานตามเวลา เพื่อการ optimize และ troubleshoot
Apps	มองทุกทรัพยากรที่ใช้ได้เป็น “Application” แยกตัว เพื่อบริหารจัดการรวมศูนย์ (ระบบผสาน security device/tool ไว้หลายชนิด)
Resources	แมป Resource เข้ากับ Application (แบบหนึ่งต่อหลาย) เพื่อจัดการรวมศูนย์และตอบสนองหลายอุปกรณ์ตามประเภทของเหตุการณ์

4. ขั้นตอนการวางระบบ SOAR (Delivery Procedure)

ก่อนลงมือตั้งค่า Playbook ควรทำความเข้าใจความต้องการให้ชัดเจนก่อน เอกสารแนะนำลำดับการวางระบบไว้ 4 ขั้น:

ขั้น	สิ่งที่ต้องทำ	รายละเอียด/สิ่งที่ต้องมี
1	เข้าใจว่าทำไมลูกค้าต้องการ SOAR และมี incident ใดเกิดขึ้นบ้าง	เข้าใจความต้องการ, ประเมินผลกระทบของ incident/alert แต่ละแบบ, และเข้าใจโครงสร้างองค์กร + กระบวนการจัดการเหตุการณ์ของลูกค้า
2	คุยกับลูกค้าและจัดลำดับกระบวนการจัดการ incident สำคัญก่อน	ต้องมีทักษะการสื่อสาร (บางครั้งลูกค้าเองก็ยังไม่แน่ใจกระบวนการที่เหมาะสม) และเพราะการตอบสนองอาจกระทบธุรกิจ จึงต้องยืนยันกระบวนการกับลูกค้าซ้ำ ๆ
3	วิเคราะห์พารามิเตอร์ (วิเคราะห์ขอบเขตความสามารถของผลิตภัณฑ์)	ต้องคุ้นเคยกับพารามิเตอร์ของ SOAR และขีดจำกัดของผลิตภัณฑ์ เพราะบางความต้องการอาจทำไม่ได้ด้วยข้อจำกัดของฟังก์ชัน
4	ตั้งค่า SOAR policy และ verify	เมื่อได้ข้อมูลข้างต้นครบ จึงเริ่มตั้งค่า Playbook ตามความต้องการ แล้วทดสอบ (verify) ประสิทธิภาพของ Playbook ที่ตั้งค่าไว้

5. ข้อจำกัดด้านประสิทธิภาพ (Performance Metrics)

ควรออกแบบ Playbook ให้อยู่ในขอบเขตต่อไปนี้ เพื่อประสิทธิภาพที่ดี:

รายการ	ค่าจำกัด	หมายเหตุ
จำนวน Playbook ที่ execute อัตโนมัติสูงสุด	XDR v2.0.12: 30 ต่อนาที XDR v2.0.17: 100 ต่อนาที	ใช้กับ Playbook ที่มีไม่เกิน 10 โหนด — ถ้าเกิน 10 โหนด จำนวนที่ทำงานพร้อมกันจะลดลง
จำนวน Playbook ที่กำลังทำงาน (in-progress) สูงสุด	ไม่จำกัด	SOAR จะตรวจหาโหนดที่ค้างไม่ทำงานเกิน 14 ชั่วโมง ซึ่งกินทรัพยากร ในกรณีปกติจึงไม่ควรเกิน 100,000 ต่อนาที
จำนวนโหนดสูงสุดใน 1 Playbook	300	—
จำนวน branch สูงสุดของ Decision หรือ Filter node	10	—
จำนวน sub-playbook ที่ซ้อนกันได้สูงสุด	5	—
จำนวน Playbook สูงสุด	ไม่จำกัด	แต่ Playbook ที่ execute อัตโนมัติได้พร้อมกันสูงสุด 100
เวลาหน่วง (delay) การ execute โหนดสูงสุด	7 วัน	—

6. การเตรียมความพร้อมก่อนใช้งาน

เงื่อนไขก่อนเริ่ม: ต้องมีอุปกรณ์ sensor และ application สำหรับตอบสนองพร้อมแล้ว ในตัวอย่างของคู่มือนี้ผสานเฉพาะ Endpoint Secure และ Network Secure แต่แนวคิดเดียวกันใช้กับ sensor อื่น ๆ รวมถึงอุปกรณ์ของผู้ผลิตรายอื่นได้ (รายละเอียดการผสานอุปกรณ์ ดูจากเอกสาร Athena XDR Quick Start and Optimization)

ก่อนเริ่ม แนะนำให้ตรวจสอบสิ่งต่อไปนี้:

• อุปกรณ์ Network Secure และ Endpoint Secure ที่ผสานไว้ online อยู่หรือไม่
• License ของ SOAR เปิดใช้งานและยังไม่หมดอายุ หรือไม่
• อุปกรณ์ของผู้ผลิตรายอื่น (third-party) อยู่ในสถานะ Connected หรือไม่

7. 15 เทคนิคและข้อควรระวังในการตั้งค่า Playbook

ส่วนนี้รวบรวมข้อควรระวังที่พบบ่อย ช่วยให้ตั้งค่า Playbook ได้ถูกต้องและหลีกเลี่ยงข้อผิดพลาด:

1. อย่าเปิด Notifications ใน Predefined Playbook — เพราะ Predefined Playbook รองรับการแจ้งเตือนเฉพาะ Lark และ DingTalk เท่านั้น (ถ้าต้องการอีเมล ให้เพิ่ม Email Action Node แทน — ดูข้อ 7)
2. ตรวจสอบให้เงื่อนไข (Conditions) ของ Playbook ถูกต้อง — ถ้า incident ไม่ตรงเงื่อนไขที่ตั้งไว้ Playbook นั้นจะไม่ปรากฏในขั้นตอนจับคู่ (matching) ของ incident เลย เพราะระบบตรวจเงื่อนไขก่อน execute เสมอ
3. โหนดต้องเชื่อมต่อกันจึงจะอ้างอิงพารามิเตอร์ได้ — หากต้องการอ้างอิงพารามิเตอร์ของโหนดต้นทาง โหนดปัจจุบันต้องถูกเชื่อมต่อกับโหนดต้นทางนั้น มิฉะนั้นพารามิเตอร์จะมองไม่เห็น

   

   

4. อย่า Clone Basic Playbook มาใช้ตรง ๆ — Basic Playbook ออกแบบมาให้ถูก “เรียก” โดย Playbook อื่นเท่านั้น ถ้า Clone มาใช้ตรง ๆ อาจเกิดข้อผิดพลาดตอนส่งผ่านพารามิเตอร์
5. แยกแยะโหนดที่คล้ายกันด้วยหมายเลขลำดับ (sequence number) — ใช้หมายเลขโหนด (เช่น #42) ระบุที่มาของพารามิเตอร์ได้ว่ามาจากโหนดใด
6. ตรวจสอบ Associated Applications ของ Predefined Playbook ว่าตรงกับความต้องการหรือไม่
7. เพิ่ม Email Action Node เมื่อต้องการส่งอีเมล — หากต้องการให้ Playbook ส่งอีเมล ให้เพิ่ม Email Action Node เข้าไปใน Playbook
8. เปิด Adaptive Unblocking สำหรับ Playbook ที่ Execute Automatically — ถ้าเลือกวิธี execute แบบอัตโนมัติ แนะนำให้เปิด Adaptive Unblocking
9. ตรวจว่าการบล็อกล้มเหลวเพราะ IP/Domain ถูกบล็อกไปก่อนแล้วหรือไม่ — เพิ่ม Action Node เพื่อ query สถานะของ threat entity ว่าเคยถูกบล็อกไปแล้วหรือไม่ (query attacker IP → query สถานะการจัดการ → บล็อกเฉพาะ IP ที่ยังไม่ถูกจัดการ)

   

10. เอา pop-up ตอน execute cloned playbook ออก — หากไม่ต้องการให้มีหน้าต่างเด้ง ต้องลบ playbook nodes และ playbook inputs (เช่น Firewall application, Block Duration) ในแท็บ Playbook Input ล่วงหน้า
11. “Super Action” หมายถึง Basic Playbook — เมื่อเห็นคำว่า Super Action ให้เข้าใจว่าหมายถึง Basic Playbook
12. ใช้ Reverse Filter เมื่อมีหลายค่าถูกส่งกลับ — เช่น ต้องการกรอง alert ที่สงสัยว่าเป็น false positive แต่ไม่มี tag ตรง ๆ ให้เพิ่ม Decision Node ตั้ง IF (จับ tag ด้วย AND) แล้วเพิ่ม ELSE เพื่อทำ reverse filter

    

13. ดึงทั้ง IP ที่อยู่/ไม่อยู่ใน whitelist จาก field ที่มีหลาย IP — ใช้ตัวดำเนินการ “not ∩” และ “∩” ในการจับคู่ IP บน Filter Node
14. วิธีหา Location ของ External IP — เพิ่ม Action Node (เช่นตั้งชื่อ Obtain External IP Information) เพื่อดึงข้อมูลตำแหน่ง แล้วนำไปใช้ต่อได้
15. วิธีเลี่ยง Playbook ถูก trigger ซ้ำ — Playbook จะถูก trigger ทุก ๆ alert ถ้า IP เดียวสร้าง 10 alert ก็จะ trigger 10 ครั้ง แก้โดยเพิ่ม Action Node query สถานะ threat entity เพื่อให้ข้ามการบล็อกถ้า IP นั้นถูกบล็อกไปแล้ว

8. ตัวอย่างที่ 1: Inbound Attack Response (Security Incident)

App ที่ต้องใช้: Firewall App — รองรับ Sangfor Network Secure (v8.0.82 ขึ้นไป), Hillstone, Palo Alto, Huawei, Huawei USG12000 Series (Notification App เสริม: Lark, DingTalk)

Step 1: Clone Playbook

ไปที่ SOAR > Playbooks > Predefined Playbooks คลิก Playbook ชื่อ Inbound Attack Response แล้วกด Clone ที่มุมขวาบนของแผงรายละเอียด (แท็บ Associated Apps จะบอกว่าต้องใช้ App ใดบ้าง)

Step 2: ตั้งค่าพื้นฐาน (Basic Configurations)

• Playbook Name: ตั้งชื่อที่ไม่ซ้ำกับ Playbook อื่น (ตัวอย่าง: “Inbound Attack Response-test”)
• Playbook Groups: เลือกกลุ่มของ Playbook → กด Next
• Execution Method: เลือก Execute Manually ก่อน เพื่อให้ทดสอบง่าย
• Assets: เลือก All หรือ Specified (แนะนำ All ก่อน)
• Firewall application: ตัวอย่างเลือก NGFW_lab
• Whether to send notification: เลือก No notification (Athena XDR รองรับเฉพาะ DingTalk และ Lark) → กด Save

Step 3: เปิดใช้งาน Playbook (Enable)

ในขั้น Completed ให้ เปิด (enable) Playbook แล้วคลิก View Playbook List เพื่อไปยังหน้า My Playbooks

Step 4: ปรับพารามิเตอร์บางส่วน

คลิกเข้า Playbook “Inbound Attack Response-test” แล้วปรับดังนี้:

4.1 ตรวจสอบเงื่อนไข (Execution Conditions) — Playbook จะทำงานก็ต่อเมื่อครบทุกเงื่อนไข ตัวอย่างนี้ใช้ค่าเริ่มต้น:

• เงื่อนไข 1: สถานะ incident เป็น Pending
• เงื่อนไข 2: incident ระดับความรุนแรง level-2 ที่เป็นการโจมตีจากภายนอกสู่ภายใน
• เงื่อนไข 3: ผลวิเคราะห์ของ Security GPT ระบุว่าไม่ใช่ false positive

4.2 Obtain External IP Information — ที่ Action Node ชื่อ Obtain External IP Information ให้เปิด Parameter Settings แล้วลบเงื่อนไข Query by Threat Intelligence: Malicious-Black ออก จากนั้นกด OK และบันทึก

4.3 เพิ่ม IP ใน Whitelist — ไปที่ Extensions > SOAR > Configuration > Constants แล้วแก้ไข constant ชื่อ Predefined-IP Whitelist

4.4 เพิ่ม Email Notification Action Node (ตามต้องการ) — เพิ่ม Action Node สำหรับส่งอีเมล และปรับ/ลบพารามิเตอร์ได้ตามต้องการ

Step 5: Execute Playbook

เมื่อแก้ไขครบ กด Save and Update แล้วกด OK จากนั้นทดสอบ: เปิดหน้า incident ที่มี External attack IP (ตัวอย่างคือ 119.23.107.2) คลิก Fix → เลือก Execute SOAR Playbook → เลือก firewall application, เลือก No notification แล้วกด Execute

Step 6: ตรวจสอบผล (Verify)

ที่หน้า Security Incident Details ของ incident นั้น คลิกแท็บ SOAR Records เพื่อดูรายละเอียดการทำงาน

สามารถตรวจสอบผลเพิ่มเติมได้ที่:

• Detection & Response > Responses > Address Blocking ในคอนโซล Athena XDR — ดูบันทึกการบล็อก
• คอนโซล Network Secure — จะเห็น IP ถูกบล็อกใน Global Blacklist
• หน้า Security Incidents — สถานะ incident เปลี่ยนจาก Fixing เป็น Fixed
• กล่องอีเมลผู้รับ — ได้รับอีเมลแจ้งเตือน

9. ตัวอย่างที่ 2: External IP/Domain ที่ติดไวรัส (Security Incident)

App ที่ต้องใช้: Firewall App (Network Secure/Hillstone/Palo Alto/Huawei/USG12000) และ Endpoint Security App (Sangfor Endpoint Secure)

Step 1–3: Clone, ตั้งค่าพื้นฐาน และ Enable

ไปที่ Predefined Playbooks คลิก Response to External IP or Domain Name Infected with Common Virus แล้วกด Clone จากนั้นตั้งค่าพื้นฐานเหมือนตัวอย่างที่ 1 (Execute Manually, Assets = All) แต่ต้องเลือกทั้ง Firewall application (ตัวอย่าง NGFW_lab) และ Endpoint security application (ตัวอย่าง EP_Lab) แล้วเลือก No notification → Save → Enable

Step 4: ปรับพารามิเตอร์

เงื่อนไขเริ่มต้นของ Playbook นี้: (1) Security GPT ระบุว่าไม่ใช่ false positive, (2) สถานะ incident = Pending, (3) incident ระดับ level-2 ที่เกี่ยวกับกิจกรรม C2 และไวรัส จากนั้นปรับ:

• Obtain External IP Information และ Obtain Domain Information — ลบเงื่อนไข Query by Threat Intelligence: Malicious-Black ในทั้งสองโหนด แล้ว OK + บันทึก
• เพิ่ม Whitelist — ที่ Extensions > SOAR > Configuration > Constants แก้ไข Predefined-IP Whitelist และ Predefined-Domain Name Whitelist
• Block IP in Incident - General Playbook — เลือก firewall device (ตัวอย่าง NGFW_lab) แล้ว OK
• Endpoint Secure Virus Scan - General Playbook — เลือก endpoint device (ตัวอย่าง EP_Lab) แล้ว OK

Step 5: Execute Playbook

กด Save and Update → OK จากนั้นเปิดหน้า incident ที่มี domain/ไฟล์/process ที่เป็นอันตราย คลิก Fix → Execute SOAR Playbook → เลือก firewall + endpoint application → No notification → Execute

Step 6: ตรวจสอบผล (Verify)

6.1 ตรวจการบล็อก Domain — ที่หน้า incident คลิกแท็บ SOAR Records จะเห็นว่า domain อันตรายถูกบล็อกสำเร็จ และตรวจยืนยันได้ที่คอนโซล Network Secure

6.2 การสแกนไวรัสบนเครื่อง endpoint — ระบบจะเริ่ม full scan บนเครื่อง (ใช้เวลาสักครู่)

10. ตัวอย่างที่ 3: Auto Blocking Internet IP (Security Alert)

App ที่ต้องใช้: Firewall App (Network Secure/Hillstone/Palo Alto/Huawei/USG12000/FortiGate)

Step 1–3: Clone, ตั้งค่าพื้นฐาน และ Enable

ที่ Predefined Playbooks คลิก Auto Blocking Internet IP from Which Inbound Attacks Failed → Clone จากนั้นตั้งชื่อ, เลือก Group → Next → Execute Manually, Assets = All, Firewall application = NGFW_lab, Block Duration = Temporary block (ค่าเริ่มต้น 10 นาที) → Save → Enable

Step 4: ปรับพารามิเตอร์

4.1 เงื่อนไข (6 ข้อ): (1) whitelist status = Not Whitelisted, (2) alert status = Pending, (3) ทิศทางการโจมตี external→internal, (4) alert ระดับ level-3 ทุกประเภท, (5) ผลการโจมตี = Attempted หรือ Failed, (6) Security GPT ระบุว่าไม่ใช่ false positive

4.3 Obtain Alert External IP Information — ลบเงื่อนไข Query by Threat Intelligence: Malicious-Black

4.4 Query สถานะของ Threat Entity — เพราะ Athena XDR รวม alert ทำให้ attack IP เป็น array บาง IP อาจถูกจัดการไปแล้ว จึงต้องกรอง IP ที่จัดการแล้วออก (ถ้าส่ง IP ซ้ำไป Firewall จะเกิด error) ให้เพิ่ม Action Node query สถานะ (ตัวอย่างชื่อ Example Query the entity process status) โดยตั้ง entity type = Address(IP URL Network-Side domain name) และ list of entities = External IP

4.5 เพิ่ม Decision Node — ตรวจว่ามี IP ที่ยังไม่ถูกจัดการอยู่จริงหรือไม่: ถ้ามี (not empty) ให้บล็อก, ถ้าไม่มี (empty) เปลี่ยนสถานะ alert เป็น Fixed โดยตรง จากนั้นตรวจ whitelist ของ IP เหล่านั้น

4.6 Block Alert IP - General Playbook — ค่าเริ่มต้นของ Block IP คือรายการ IP ที่ยังไม่ถูกจัดการ, เลือก firewall (NGFW_lab) แล้ว OK (ถ้าโหนดนี้ไม่ตรงความต้องการ เปลี่ยนเป็น Action Node บล็อก IP อื่นได้)

4.7 UnBlocking Alert IP - General Playbook — ตั้ง Block IP ให้เหมือนโหนด Block, เลือก firewall เดียวกัน และตั้ง Delayed Execution เพื่อควบคุมระยะเวลาบล็อก (ปรับได้)

Step 5: Execute Playbook

กด Save and Update → OK จากนั้นกรอง alert ที่ตรงเงื่อนไข เปิดหน้า alert details คลิก Fix → Execute SOAR Playbook → เลือก firewall → No notification → Execute

Step 6: ตรวจสอบผล (Verify)

ที่หน้า Alert Details คลิกแท็บ SOAR Execution History จะเห็นว่า attack IP ถูกบล็อกสำเร็จ และตรวจยืนยันที่คอนโซล Network Secure ได้ — หลังครบ 10 นาที IP จะถูกปลดบล็อกอัตโนมัติ

11. ตัวอย่างที่ 4: จัดการ Alert เมื่อตรวจพบครบ 3 ครั้ง (Custom Playbook)

หลักการนับด้วย tag: ทุกครั้งที่ alert ถูกจัดการแล้วเปลี่ยนสถานะเป็น ignore/fixing แต่พอ Athena XDR ตรวจพบ alert เดิมซ้ำ มันจะเปลี่ยนสถานะกลับเป็น Pending อัตโนมัติ ทำให้ Playbook ถูก trigger อีกครั้ง เราจึงใช้ tag บอกว่า “นี่คือการพบครั้งที่เท่าไร” ดังตาราง:

ครั้งที่ตรวจพบ	tag ที่มีอยู่ก่อน	สาขา (branch) ใน Decision	การกระทำ	สถานะ + คอมเมนต์
1	ไม่มี	Else (tag-0)	เพิ่ม tag ‘1’	fixing/ignored — “detected once”
2	tag ‘1’	If (tag-1)	ลบ ‘1’, เพิ่ม ‘2’	fixing/ignored — “detected twice”
3	tag ‘2’	Else if (tag-2)	ลบ ‘2’, เพิ่ม ‘3’, บล็อก IP	Fixed — “detected thrice”

Step 1: เพิ่ม custom tag ที่หน้า Constants

เปิดโมดูล SOAR ไปที่ Configuration > Constants กด Add สร้าง tag 2 รายการ (ตัวอย่าง: tag-1 ค่า ‘1’ และ tag-2 ค่า ‘2’ ชนิด Character String)

Step 2: สร้าง Custom Playbook

ไปที่ Playbook > My Playbook กด Add ตั้งค่า Threat Type = Security Alert และกำหนดเงื่อนไข (ออกแบบเองได้ แต่อย่างน้อยต้องมี status == pending) แล้วกด OK

Step 3: Query security alert analysis tag

เพิ่มโหนด query tag ของ alert เพื่อนำค่าไปใช้ในขั้นถัดไป

Step 4: ใช้ Decision Node นับจำนวนครั้ง

เพิ่ม Decision Node (ตัวอย่างชื่อ Tag) แยกเป็น 3 สาขา โดยอ้างอิงพารามิเตอร์ “Security Alert Tag Name”:

• Branch tag-1 — เข้าเมื่อ alert ถูกพบมาแล้ว 1 ครั้ง (มี tag-1 อยู่)
• Branch tag-2 — เข้าเมื่อ alert ถูกพบมาแล้ว 2 ครั้ง (มี tag-2 อยู่)
• Branch tag-0 (Else) — เข้าเมื่อยังไม่เคยพบ (ยังไม่มี tag)

Step 5: สาขา “พบครั้งแรก” (tag-0)

2 การกระทำ: (1) เพิ่ม custom tag ‘1’ (2) เปลี่ยนสถานะ alert เป็น fixing/ignored พร้อมคอมเมนต์ “detected once”

Step 6: สาขา “พบครั้งที่สอง” (tag-1)

3 การกระทำ: (1) ลบ tag ‘1’ (2) เพิ่ม tag ‘2’ (3) เปลี่ยนสถานะเป็น fixing/ignored พร้อมคอมเมนต์ “detected twice”

Step 7: สาขา “พบครั้งที่สาม” (tag-2)

5 การกระทำ: (1) ลบ tag ‘2’ (2) เพิ่ม tag ‘3’ (3) query threat entity ที่ต้องจัดการ (เช่น External IP ใน alert) (4) Handle Action เช่น เพิ่ม source IP ของ alert เข้า blacklist ของ Athena AF (ออกแบบ action ที่ซับซ้อนกว่านี้หรือเรียก sub-playbook ก็ได้) (5) เปลี่ยนสถานะเป็น Fixed พร้อมคอมเมนต์ “detected thrice”

Step 8: ตรวจสอบผล (Verify)

ภาพรวมของ Playbook ที่สร้างเสร็จ:

ทดสอบตามลำดับการตรวจพบ:

• ครั้งที่ 1: เข้าสาขา tag-0 → ติด tag ‘1’ → สถานะเป็น fixing (เมื่อพบครั้งที่ 2 XDR จะเปลี่ยนสถานะกลับเป็น pending อัตโนมัติ)
• ครั้งที่ 2: เข้าสาขา tag-1 → ติด tag ‘2’ → สถานะเป็น fixing
• ครั้งที่ 3: เข้าสาขา tag-2 → IP ถูกบล็อก → สถานะเป็น Fixed

ตรวจสอบคอมเมนต์ทั้ง 3 ครั้ง (detected once/twice/thrice) ได้ใน record ของ alert — เท่านี้ก็ได้ Playbook ที่จะลงมือจัดการก็ต่อเมื่อตรวจพบครบ 3 ครั้งแล้ว

12. สรุปและ Best Practices

• SOAR เป็นระบบกึ่งอัตโนมัติ ใช้เสริมกระบวนการของทีม ไม่ได้แทนที่คนทั้งหมด
• เริ่มจาก Predefined Playbook แล้ว Clone มาปรับ — อย่า Clone Basic Playbook มาใช้ตรง ๆ
• ทดสอบด้วย Execute Manually ก่อนเสมอ เมื่อมั่นใจแล้วจึงเปลี่ยนเป็น Execute Automatically (และเปิด Adaptive Unblocking)
• ตั้งเงื่อนไข (Conditions) ให้ถูกต้อง มิฉะนั้น Playbook จะไม่ปรากฏตอน matching
• ป้องกันการ trigger/บล็อกซ้ำด้วยการ query สถานะ threat entity และ/หรือเปลี่ยนสถานะเป็น Fixing
• Predefined Playbook แจ้งเตือนได้เฉพาะ Lark/DingTalk — ถ้าต้องการอีเมล ให้เพิ่ม Email Action Node
• ตรวจผลได้ที่แท็บ SOAR Records (incident) / SOAR Execution History (alert) และยืนยันที่คอนโซลของอุปกรณ์ปลายทาง (เช่น Firewall/NGFW หรือ Endpoint Secure)