SOAR บน Athena XDR: Playbook สำเร็จรูป, Node, การรันอัตโนมัติ และการแก้ Playbook ที่รันไม่สำเร็จ

SOAR (Security Orchestration, Automation and Response) บน Sangfor Athena XDR นำขั้นตอนตอบสนองที่ทีม SOC ทำซ้ำทุกวัน เช่น ตรวจว่า IP อยู่ใน Whitelist หรือไม่ → บล็อกที่ไฟร์วอลล์ → เปลี่ยนสถานะ Alert → แจ้งทีม มาเรียงเป็น Playbook แล้วให้ระบบทำแทน จะให้รันเองทั้งหมดหรือหยุดรอคนอนุมัติบางขั้นก็ได้ บทความนี้สำหรับผู้ดูแลระบบและทีม SOC ที่ต้องการเริ่มจาก Playbook สำเร็จรูป ปรับให้ตรงกับ Alert ขององค์กร สร้าง Playbook ที่รันอัตโนมัติ และแก้ปัญหาเมื่อ Playbook รันไม่สำเร็จ

SOAR ทำงานอย่างไร

1. เมื่อเกิด Security Alert หรือ Security Incident ใหม่ XDR ส่งข้อมูลให้ SOAR

2. SOAR หา Playbook ที่ Conditions for Execution ตรงกับเรื่องนั้น เช่น ประเภทภัย แหล่งข้อมูล สถานะ และผลวิเคราะห์ของ Security GPT

3. Playbook ทำงานทีละ Node บนแผนผัง Node ที่คัดกรอง ตัดสินใจ หรือรอคนอนุมัติทำงานภายใน XDR ส่วน Action Node ออกไปสั่งอุปกรณ์ผ่านแอปที่เชื่อมไว้ เช่น ไฟร์วอลล์ EPP หรือระบบอีเมล

4. ผลของทุก Node ถูกเก็บไว้ใน Execution History ย้อนดูได้ภายหลัง

SOAR เป็นระบบกึ่งอัตโนมัติที่ทำให้กระบวนการเดิมของทีมเป็นดิจิทัลและเป็นมาตรฐาน งานที่เหมาะคืองานที่เกิดซ้ำบ่อยและมีขั้นตอนแน่นอน หากต้องการตัวช่วยบล็อกผู้โจมตีที่ชัดเจนโดยแทบไม่ต้องตั้งค่า ให้ดู Auto Containment ซึ่งมีตารางเปรียบเทียบกับ SOAR

เตรียมความพร้อม

• License – ที่ Configuration › Basic Configuration › Licensing การ์ด SOAR อยู่ในกลุ่ม App Center หากจะสั่งอุปกรณ์ของผู้ผลิตอื่น ใช้ License SOAR รุ่นที่รองรับอุปกรณ์ Third-Party และหากจะใช้ Adaptive Unblocking ต้องมี Security Operation GPT ด้วย
• อุปกรณ์ – ที่ Configuration › Connection › Device Connection อุปกรณ์ที่จะรับคำสั่งต้อง Online และป้าย Coordinated Response เป็นสีเขียว ทั้ง Native Devices (Athena NGFW, Athena EPP) และ Third-Party Devices ที่เชื่อมผ่าน XDR Broker (ดู FortiGate Coordinated Response)
• กระบวนการ – คุยกับเจ้าของระบบก่อนว่าเรื่องใดเกิดซ้ำบ่อยและปกติจัดการอย่างไร เพราะการบล็อกผิดเพียงครั้งเดียวอาจกระทบงานของแผนกอื่น ตกลงขั้นตอนให้ตรงกัน แล้วตรวจว่ามีข้อมูลและ Action ให้ใช้ครบทุกขั้นก่อนตั้งค่าและทดสอบ

เมนู SOAR, Apps และ Predefined Playbooks

เข้าได้จาก Responses › SOAR เมนูด้านซ้ายจะเปลี่ยนเป็นของ SOAR (ปุ่ม Back กลับเมนูหลัก)

เมนู	ใช้ทำอะไร
Playbooks › My Playbooks	Playbook ที่ Clone มาหรือสร้างเอง แบ่งตาม Playbook Groups เปิด/ปิดแต่ละตัวที่คอลัมน์ Status
Playbooks › Predefined Playbooks	Playbook สำเร็จรูปของ Sangfor
Playbooks › Tasks	งานที่รอคนอนุมัติหรือกรอกข้อมูล (จาก Review / Record Node)
Playbooks › Execution History	ผลการรันทุกครั้ง แยกแท็บ Playbooks และ Actions
Configuration › Notifications / Tags / Constants	Template แจ้งเตือน, ป้ายสำหรับแอปและอุปกรณ์, ค่าคงที่ที่หลาย Playbook ใช้ร่วมกัน (เช่น Whitelist)
Apps	แอปที่ SOAR สั่งงานได้ แต่ละแอปผูกกับอุปกรณ์ที่เรียกว่า Resource

การ์ดแต่ละใบในหน้า Apps บอกชื่อแอป ผู้ผลิต และจำนวน Resource คลิกการ์ดเพื่อดู App Details: Resources (อุปกรณ์ที่ผูกไว้) และ Actions ที่ Playbook เรียกใช้ได้ Resource ของแอปผู้ผลิตอื่นเพิ่มที่ Device Connection แท็บ Third-Party Devices โดยเปิด Coordinated Response

หน้า Predefined Playbooks แบ่งเป็นแท็บ Alert Playbooks (ทำงานกับ Alert ทีละรายการ เช่น Auto Blocking Internet IP from Which Inbound Attacks Failed), Incident Playbooks (ทำงานกับทั้ง Incident เช่น Inbound Attack Response และ Response to External IP or Domain Name Infected with Common Virus) และ Basic Playbooks ซึ่งเป็นชิ้นส่วนพื้นฐาน (บางครั้งเรียกว่า Super Action) ให้ Playbook อื่นเรียกใช้

คลิกการ์ดเพื่อเปิดรายละเอียด: แท็บ Introduction มี Execution Condition, แท็บ Content เป็นแผนผังขั้นตอน และแท็บ Associated Apps บอกแอปที่ต้องใช้ เช่น กลุ่ม Firewall App

Clone Playbook สำเร็จรูป

Playbook สำเร็จรูปใช้งานโดยการ Clone ให้เลือก Clone จากแท็บ Alert หรือ Incident (Basic Playbook ออกแบบมาให้ถูกเรียกจาก Playbook อื่น) ตัวอย่างนี้ใช้ Auto Blocking Internet IP from Which Inbound Attacks Failed ซึ่งบล็อก IP จากอินเทอร์เน็ตที่โจมตีเข้ามาแล้วไม่สำเร็จ

1. คลิกการ์ด แล้วกด Clone ที่มุมขวาบน หน้าตั้งค่าจะเปิดในแท็บใหม่ของเบราว์เซอร์ (แท็บ Introduction แสดง Execution Condition ตามภาพในหัวข้อก่อนหน้า)

2. ขั้น Basics: กรอก Playbook Name ที่ไม่ซ้ำ, Playbook Description, เลือก Playbook Group (กด Add สร้างกลุ่มใหม่ได้) และคง Threat Type ตามต้นฉบับ แล้วกด Next

   

3. ขั้น Modify Settings: ตั้ง Execution Method เป็น Execute Manually ก่อนเพื่อทดสอบทีละรอบ, Assets = All, เปิดรายการ Firewall application แล้วติ๊กไฟร์วอลล์ที่จะให้บล็อก และเลือก Block Duration เช่น Temporary block (default 10 minutes) ลิงก์ Configure Whitelist to Reduce False Positive Blocks และ Device Connection พาไปตั้งค่าที่เกี่ยวข้อง

   

4. กด Save ขั้น Completed แสดง Operation successful เปิดสวิตช์ Playbook Status แล้วยืนยัน OK จากนั้นกด View Playbook List

   

ใน My Playbooks จะเห็นสำเนาของเรา พร้อม Basic Playbook ที่สำเนาเรียกใช้ (ในตัวอย่างนี้คือ Blocking และ Unblocking Alert IP - General Playbook) ซึ่งระบบเพิ่มให้ตอน Clone หากจะแก้ ให้แก้ที่สำเนาใน My Playbooks

ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร

ปรับเงื่อนไข, Node และ Constants

คลิกชื่อ Playbook เพื่อเปิดแผนผัง (โหมดดูอย่างเดียว) กด Edit Playbook เพื่อแก้ไข แถบด้านบนในโหมดแก้ไขมี Playbook Settings, Advanced, Save and Update, Save as Draft และ Cancel ทุกครั้งที่กด Save and Update ระบบให้กรอก Update Purpose บอกเหตุผลของการแก้ไข แล้วกด OK ระบบแจ้ง Saved successfully

Conditions for Execution

เปิด Playbook Settings เพื่อดูเงื่อนไข หลายเงื่อนไขต้องตรงทุกข้อ ส่วนหลายค่าในข้อเดียวตรงค่าเดียวก็พอ Playbook ที่ไม่มีเงื่อนไขจะไม่รันอัตโนมัติ เพื่อป้องกันการรันตาม Alert ทุกตัว

ให้เทียบเงื่อนไขกับ Alert จริงขององค์กรที่แท็บ Alert Fields ของ Alert เช่น เงื่อนไข Direction == External➝Internal ของต้นฉบับอาจไม่ตรงกับ Alert ที่ระบุทิศทางเป็น Inbound ในกรณีนี้ให้ลบข้อ Direction (กดกากบาทท้ายข้อ) แล้วคัดด้วย Attack Result (Attempted / Failed) และ Security GPT Analysis Conclusion (not in False Positive, Business False Positive) แทน

Node ที่ดึง IP ภายนอก

ดับเบิลคลิก Node Obtain Alert External IP Information (หรือ Obtain External IP Information / Obtain Domain Information ใน Incident Playbook) ช่อง Query by Threat Intelligence ตั้งไว้เป็น Malicious - Black ทำให้ส่งต่อเฉพาะ IP ที่ Threat Intelligence ระบุว่าอยู่ในบัญชีดำ หากต้องการให้ IP ภายนอกทุกตัวไปผ่าน Filter Node ถัดไป (เช่น IP ใหม่ที่ไม่เคยมีประวัติใน Threat Intelligence) ให้ลบค่านี้ออก กด OK แล้ว Save and Update

Constants (Whitelist ที่ใช้ร่วมกัน)

Filter Node ของ Playbook บล็อกสำเร็จรูปตัด IP ใน Predefined-IP Whitelist และ IP สาธารณะของอุปกรณ์องค์กร (Predefined-Public device network tags) ออก ก่อนใช้งานจริงให้แก้ค่า Whitelist ให้ตรงกับองค์กร

1. ไปที่ SOAR › Configuration › Constants แล้วค้นด้วยคำว่า IP Whitelist

   

2. กด Edit ที่แถว Predefined-IP Whitelist กรอกวง IP ภายในและ IP ขาออกอินเทอร์เน็ตขององค์กร บรรทัดละหนึ่งค่า แล้วกด OK Playbook ทุกตัวที่อ้างถึง Constant นี้จะได้ค่าใหม่โดยไม่ต้องแก้ตัว Playbook

   

การสร้าง Constant ใหม่ กด Add กรอก Name เลือก Constant Type (IP, Port, Time, Character String, Integer) แล้วกรอกค่าทีละบรรทัด

ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร

รัน Playbook ด้วยมือและตรวจผล

1. เปิด Alert หรือ Incident ที่ตรงเงื่อนไข (เช่น ที่ Detections › Security Alerts แท็บ All Alerts) กดเมนู Fix › Execute SOAR Playbook

   

2. หน้าต่าง Execute Playbook ติ๊ก Display matched playbooks only ไว้ จึงแสดงเฉพาะ Playbook ที่เงื่อนไขตรงกับเรื่องนั้น หาก Playbook ที่ต้องการไม่ขึ้น (เช่น Incident ไม่อยู่ในสถานะ Pending แล้ว) ให้เอาติ๊กออกเพื่อแสดงทั้งหมด

   

3. เลือก Playbook แล้วกด Next ระบบถามค่าที่ Playbook ต้องใช้ เช่น Firewall application และ Block Duration กด Use Default Value เพื่อใช้ค่าที่ตั้งไว้ตอน Clone แล้วกด Execute

   

4. เปิดแท็บ SOAR Execution History ของ Alert/Incident รอบล่าสุดอยู่บนสุด ด้านขวา (Execution Details) แสดงผลทีละ Node เช่น Filter Node ให้ผล Exist malicious IP addresses แล้ว Sub-playbook เริ่มสั่งบล็อก

   

5. ยืนยันที่อุปกรณ์และที่ Responses › Responses แท็บ Address Blocking เมื่อครบเวลาบล็อกชั่วคราว สถานะเปลี่ยนเป็น Unblocked และ Rule Name บอก Action ที่ใช้ปลด (ไฟร์วอลล์ผู้ผลิตอื่นตรวจได้ที่ Console ของอุปกรณ์ ดู FortiGate Coordinated Response)

   

Node และตัวแปรใน Playbook

แถบ Nodes ด้านซ้ายของแผนผังแบ่งเป็นกลุ่ม

กลุ่ม	Node	หน้าที่
Actions	Action	เรียก Action ของแอปที่เชื่อมไว้ เช่น บล็อก IP, สแกนไวรัส, เปลี่ยนสถานะ Alert, ส่งอีเมล
Actions	Playbook	เรียก Playbook ที่มีอยู่ (Sub-playbook) เพื่อประกอบงานที่ซับซ้อนขึ้น
Process Filters	Node for AI Block Analysis During Auto Containment	คัด Entity ที่ควรบล็อกด้วย AI ก่อนสั่งบล็อก
Process Filters	Filter	คัดเฉพาะข้อมูลที่ตรงกติกาแล้วส่งต่อ ต่อกติกาด้วย AND / OR / NOT และแยกได้หลายทาง (Loop)
Process Filters	Decision	เลือกเส้นทางถัดไปด้วย If / Else if / Else
Manual Operations	Review	หยุดรอผู้อนุมัติ (Approver, Response Time โดย 0 = รอไม่จำกัด, Approval Content, Attachment, Reply Requirement แบบ Yes/No, Text หรือ Custom Options)
Manual Operations	Record	ให้ผู้ใช้กรอกข้อมูลระหว่างทาง เช่น เจ้าของเครื่อง (Recorded By, Notification Text, Recorded Item แบบ Text, Option หรือ Dynamic Parameter List)
End	End	จุดจบของ Playbook ทุกเส้นทางต้องต่อถึง End

การให้คนอนุมัติหรือกรอกข้อมูลระหว่างทาง:

1. ในโหมดแก้ไข ลาก Review จากกลุ่ม Manual Operations มาวางบนแผนผัง แล้วดับเบิลคลิกเพื่อเปิด Parameter Settings

2. เลือก Approver จากผู้ใช้ในระบบ ตั้ง Response Time (0 = รอไม่จำกัด) กรอก Approval Content ซึ่งใส่ตัวแปรของ Alert ได้ แนบไฟล์ได้ที่ Attachment และเลือก Reply Requirement เป็น Yes/No, Text หรือ Custom Options ส่วน Notifications ใช้ตั้งช่องทางแจ้งผู้อนุมัติ

   

3. หากต้องการให้คนกรอกข้อมูล เช่น เจ้าของเครื่อง ใช้ Record Node: เลือก Recorded By, กรอก Notification Text, ตั้งชื่อ Recorded Item แล้วเลือกชนิดคำตอบ (Text, Option หรือ Dynamic Parameter List)

   

4. งานจาก Review และ Record Node จะไปรอที่ SOAR › Playbooks › Tasks เมื่อผู้ที่ได้รับมอบหมายตอบแล้ว Playbook จะทำต่อที่ Node ถัดไป

ส่งค่าระหว่าง Node และตัวแปร

Node ที่ต่อเส้นถึงกันหยิบผลของ Node ก่อนหน้าได้ เช่น ช่อง Block IP ของ Node บล็อกอ้างถึง ${filter.40.case1…} ซึ่งหมายถึงผลของ Filter Node หมายเลข 40 ใช้หมายเลข Node แยกที่มาของค่าเมื่อมี Node ชื่อคล้ายกัน หาก Node ไม่ได้ต่อเส้นถึงกัน จะมองไม่เห็นค่าของ Node นั้น

เมื่อคลิกช่องตัวแปร รายการจะแบ่งเป็นกลุ่ม: ตัวแปรของ Alert (ขึ้นต้นด้วย alarm เช่น ${alarm.srcIp}, ${alarm.dstIp}, ${alarm.riskTag}), Constant, ผลของ Node ก่อนหน้า และ Playbook Input ส่วน Playbook ชนิด Security Incident ใช้ตัวแปรที่ขึ้นต้นด้วย event เช่น ${event.name}, ${event.hostIp}, ${event.gptResult} ค่าบางตัวเก็บเป็นตัวเลข เช่น ${event.severity} (-1 informational, 1 low, 2 medium, 3 high, 4 critical) และ ${event.dealStatus} (1 Pending, 2 In Progress, 3 Completed, 4 Suspended, 5 Dismissed, 6 Contained) ตัวแปรใช้ได้ทั้งในกติกาและในช่องข้อความ เช่น Approval Content

ส่วน Advanced ของ Action Node มี Delayed Execution (หน่วงเวลาก่อนทำงาน), Execute after Approval และ Terminate upon Error

ภายใน Basic Playbook สำหรับบล็อก IP

Blocking Alert IP - General Playbook ถามสถานะของ Entity ก่อนว่า IP ใดบล็อกไปแล้ว จากนั้น Decision แยกทาง: ถ้ายังมี IP ที่ยังไม่บล็อกจึงไปทางบล็อก ไฟร์วอลล์จึงได้รับคำสั่งเฉพาะ IP ใหม่ ทางบล็อกแยกเป็น Node ของไฟร์วอลล์แต่ละยี่ห้อ เช่น FortiGate ใช้ Action Block Infected Endpoint IP Address ส่วนระยะเวลาบล็อกชั่วคราวกำหนดที่ Node ปลดบล็อก (UnBlocking Alert IP) ด้วย Delayed Execution

หากการโจมตีเดิมยังเข้ามาเรื่อย ๆ XDR จะอัปเดต Alert เดิมแทนการสร้าง Alert ใหม่ และ Playbook ที่รันอัตโนมัติจะรับเฉพาะ Alert ที่ยังเป็น Pending Alert ที่จัดการแล้วจึงไม่เข้ารอบซ้ำ จนกว่าจะถูกตรวจพบซ้ำและกลับเป็น Pending

สร้าง Playbook ที่รันอัตโนมัติ

ตัวอย่างนี้สร้าง Playbook จากแผนผังว่าง ให้บล็อก IP ต้นทางของการโจมตีที่ไม่สำเร็จบนไฟร์วอลล์ แล้วปลดบล็อกเองเมื่อครบ 10 นาที

1. ที่ My Playbooks กด Add แผง Playbook Settings เปิดขึ้นมา กรอกชื่อและคำอธิบาย เลือกกลุ่ม และ Threat Type = Security Alert ตั้ง Execution Method เป็น Execute Manually ไว้ก่อน

2. เพิ่ม Conditions for Execution ด้วย Add Condition: Attack Result in Attempted, Failed, Status in Pending และ Security GPT Analysis Conclusion not in Business False Positive, False Positive แล้วกด OK (ระบบบันทึก Playbook ทันทีและพาไปที่แผนผัง)

   

3. ลากเส้นออกจาก Start แล้วเลือก Filter ตั้งชื่อ Node และชื่อทาง กติกา: Src IP (จากกลุ่ม Security Alert) not in Predefined-IP Whitelist ช่อง Error Processing เลือกให้หยุด Playbook เมื่อไม่มีข้อมูลเหลือ แล้วกด OK

   

4. ต่อ Action Node ใช้ Action ของไฟร์วอลล์ เช่น FortiGate Block Infected Endpoint IP Address ช่อง IP เลือก Src IP จากผลของ Filter (IP จึงผ่านการคัดแล้ว) ช่อง Block Duration ปล่อยว่าง (ค่า 0 = Permanent Block เป็นค่าเริ่มต้น) แล้วเลือกอุปกรณ์ในช่อง Device

   

5. ต่อ Action Node ปลดบล็อก (เช่น Unblock Infected Endpoint IP Address) ใช้ IP ชุดเดียวกัน เปิด Advanced › Delayed Execution แล้วตั้ง 10 minutes ระยะเวลานี้คือเวลาที่ IP ถูกบล็อก

6. ลากเส้นจาก Node สุดท้ายไปที่ End ทุกเส้นทางต้องต่อถึง End ก่อนเปิดใช้ Playbook หากยังต่อไม่ครบ ระบบจะแจ้ง Node not connected

   

7. เปิด Playbook Settings อีกครั้ง เปลี่ยน Execution Method เป็น Execute Automatically ระบบเพิ่มเงื่อนไข Whitelisted Status in Not Whitelisted และติ๊ก Adaptive Unblocking ให้ เลือกข้อมูลของ Alert ที่จะเฝ้าดูอย่างน้อยหนึ่งอย่าง เช่น Security GPT Analysis Conclusion หากภายหลัง GPT เปลี่ยนผลจน Alert ไม่ตรงเงื่อนไขแล้ว ระบบจะปลดบล็อก Entity ที่ Playbook นี้บล็อกไว้ให้เอง

   

8. กด OK แล้วกด Save and Enable กรอก Update Purpose (หน้าต่างเดียวกับตอน Save and Update) แล้วกด OK Playbook จะรอทำงานเองเมื่อมี Alert ตรงเงื่อนไข

การแจ้งทีมทางอีเมลทุกครั้งที่ Playbook ทำงาน ตั้งได้ที่ส่วน Notifications ของ Playbook Settings ดูรายละเอียดใน การตั้งค่าอีเมลแจ้งเตือนของ SOAR

ตัวอย่าง: Incident Playbook บล็อก IP/โดเมนและสแกนไวรัส

เมื่อเครื่องภายในติดไวรัสและติดต่อ IP หรือโดเมนภายนอก (เช่น พฤติกรรม C&C) ใช้ Playbook สำเร็จรูป Response to External IP or Domain Name Infected with Common Virus ซึ่งดึง IP และโดเมนภายนอกของ Incident คัดด้วย Whitelist สั่งไฟร์วอลล์บล็อก แล้วสั่ง Athena EPP สแกนไวรัสที่เครื่องในรอบเดียว

1. ที่ SOAR › Playbooks › Predefined Playbooks แท็บ Incident Playbooks คลิกการ์ด Response to External IP or Domain Name Infected with Common Virus แท็บ Introduction แสดง Execution Condition และแท็บ Content แสดงแผนผัง

   

2. เปิดแท็บ Associated Apps Playbook นี้ใช้ Firewall App และ Endpoint Security App (Endpoint Secure) หากองค์กรไม่ได้เชื่อม Athena EPP ให้ลบ Node สแกนไวรัสออกจากสำเนาภายหลัง

   

3. กด Clone ขั้น Basics กรอก Playbook Name เลือก Playbook Groups แล้วกด Next (เหมือนหัวข้อ Clone)

4. ขั้น Modify Settings ตั้ง Execute Manually, Assets = All เลือกไฟร์วอลล์ในช่อง Firewall application และเลือก Athena EPP ในช่อง Endpoint security application ช่อง Whether to send notification เลือก No notification หากยังไม่ได้เชื่อม Message App แล้วกด Save

   

5. ขั้น Completed เปิดสวิตช์ Playbook Status ยืนยัน OK แล้วกด View Playbook List

6. เปิด Incident ที่ต้องการ กด Fix › Execute SOAR Playbook หาก Playbook ไม่ขึ้นในรายการ ให้เอาติ๊ก Display matched playbooks only ออก เลือก Playbook แล้วกด Next กด Use Default Value แล้วกด Execute

   

7. หากรอบแรกขึ้น Execution Failed พร้อมข้อความ The parameter (Block IP) is required but is empty ที่ Sub-playbook Blocking IP in Incident แปลว่า Node ที่ดึง IP และโดเมนภายนอกตั้ง Query by Threat Intelligence เป็น Malicious - Black ไว้ ทำให้ไม่มี IP ส่งต่อ

   

8. ที่ My Playbooks เปิดสำเนา กด Edit Playbook ดับเบิลคลิก Node Obtain External IP Information ลบค่าในช่อง Query by Threat Intelligence ให้ว่าง กด OK ทำแบบเดียวกันที่ Node Obtain Domain Information จากนั้นกด Save and Update กรอก Update Purpose แล้วกด OK (ภาพ Node นี้ดูได้ในหัวข้อปรับเงื่อนไข, Node และ Constants)

9. กลับไปที่ Incident กด Re-execute แล้วกด OK เพื่อยืนยัน

   

10. ดูผลที่แท็บ SOAR Execution History ของ Incident รอบใหม่อยู่บนสุด ด้านขวาแสดงผลทีละ Node เช่น Filter Node ของ IP ให้ผล The filter result is empty เมื่อ IP อยู่ใน Whitelist และ Filter Node ของโดเมนให้ผล Malicious domain name exists จากนั้น Playbook สั่งบล็อกโดเมนและสั่ง Endpoint Secure สแกนไวรัสที่เครื่อง ตรวจคำสั่งบล็อกได้ที่ Responses › Responses และงานสแกนที่แท็บ Virus Scan

    

Incident Playbook สำเร็จรูป Inbound Attack Response ใช้ขั้นตอนเดียวกัน สำหรับ IP สาธารณะที่โจมตีหรือสแกนเครือข่ายภายใน: Playbook ดึง IP ภายนอก ตรวจกับ Whitelist แล้วสั่งไฟร์วอลล์บล็อก และปรับสถานะ Incident ให้ ตอน Clone เลือกเฉพาะ Firewall application และก่อนใช้งานให้ลบค่า Malicious - Black ที่ Node Obtain External IP Information และแก้ Predefined-IP Whitelist แบบเดียวกัน

ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร

Execution History และการแก้ Playbook ที่รันไม่สำเร็จ

Responses › SOAR › Playbooks › Execution History มี 2 แท็บ

• Playbooks – ทุกรอบที่ Playbook ทำงาน กรองช่วงเวลาด้วย Execution Time คอลัมน์ Executed By เป็น Auto Playbook Execution เมื่อรันเอง หรือชื่อบัญชีเมื่อมีคนสั่ง, Execution Status, Details (ลิงก์ Action และ Notifications) และปุ่ม Re-execute ชี้ไอคอน i ข้างสถานะเพื่อดูสาเหตุที่ไม่สำเร็จ
• Actions – ทีละคำสั่ง พร้อม Action Parameter และอุปกรณ์ที่รับคำสั่ง (Resource) แถวคำสั่งบล็อกมีปุ่ม Undo ไว้ย้อนคำสั่งด้วยมือ

เมื่อ Playbook ที่สั่งจาก Incident รันไม่สำเร็จ หน้า Incident จะแสดงแผงแจ้ง Failed to execute the playbook พร้อมปุ่ม View Execution Records, Re-execute, Execute Other Playbooks และ Fix Threat Entity

ขั้นตอนแก้ Playbook ที่รันไม่สำเร็จแบบครบทุกขั้นดูได้ในตัวอย่าง Incident Playbook

หาก Filter Node ให้ผล The filter result is empty แปลว่า IP ทุกตัวถูกคัดออกเพราะอยู่ใน Whitelist หรือเป็น IP ของอุปกรณ์องค์กร ให้ตรวจ Constants ที่เกี่ยวข้อง หรือสั่งบล็อก IP นั้นโดยตรงด้วย Execute SOAR Action

ตรวจทุกสัปดาห์ – เปิดดูรอบที่ไม่สำเร็จ แล้วไล่ 3 จุด: แอปยังเชื่อมต่อได้ (Test Connectivity), เงื่อนไขยังตรงกับ Alert จริง และ Node ต่อถึง End ครบทุกทาง

Execute SOAR Action: สั่งงานเดียว

ใช้เมื่อต้องการสั่งงานเดียวของแอปตัวเดียว เช่น ทดสอบการเชื่อมต่อ หรือบล็อก IP ที่ไฟร์วอลล์ผู้ผลิตอื่นทันที

1. ที่ Alert หรือ Incident กด Fix › Execute SOAR Action

2. ช่อง Action เปิดกลุ่มแอป (เช่น Network Security App › FortiGate) แล้วเลือก Action เช่น Add Blocked IP หรือ Undo IP Address Blocking กด OK

   

3. กรอกพารามิเตอร์ เช่น Block IP Address เลือกอุปกรณ์ในช่อง Device แล้วกด Execute ระบบแจ้ง Executed successfully

   

4. ตรวจผลที่ Responses › SOAR › Playbooks › Execution History แท็บ Actions คำสั่งล่าสุดอยู่แถวแรก พร้อม Resource และลิงก์ Undo ไว้ถอนคำสั่ง (ภาพแท็บ Actions อยู่ในหัวข้อ Execution History)

สรุปการเลือกใช้จากเมนู Fix: หยุดทันทีด้วยมือใช้ Block Address, สั่งงานเดียวของแอปเดียวใช้ Execute SOAR Action, งานหลายขั้นที่มีอนุมัติหรือแจ้งเตือนใช้ Execute SOAR Playbook

ตัวอย่าง: จัดการ Alert เมื่อพบครบ 3 ครั้ง

บางองค์กรต้องการให้ระบบลงมือเฉพาะเมื่อพบ Alert เดิมครบ 3 ครั้ง เพื่อลดผลกระทบจากการเตือนผิด งานนี้สร้างเป็น Custom Playbook โดยใช้ Custom Tag เป็นตัวนับ เมื่อ Alert ที่ถูกเปลี่ยนสถานะแล้วถูกตรวจพบซ้ำ XDR จะเปลี่ยนสถานะกลับเป็น Pending ทำให้ Playbook ทำงานอีกรอบ

ครั้งที่พบ	Tag ที่มีอยู่	ทางใน Decision	สิ่งที่ทำ
1	ไม่มี	Else (tag-0)	เพิ่ม Tag 1 เปลี่ยนสถานะเป็น Fixing หรือ Ignored คอมเมนต์ "detected once"
2	1	If (tag-1)	ลบ Tag 1 เพิ่ม Tag 2 เปลี่ยนสถานะ คอมเมนต์ "detected twice"
3	2	Else if (tag-2)	ลบ Tag 2 เพิ่ม Tag 3 บล็อก IP เปลี่ยนสถานะเป็น Fixed คอมเมนต์ "detected thrice"

1. ที่ SOAR › Configuration › Constants กด Add สร้าง Constant ชนิด Character String 2 รายการ เช่น tag-1 ค่า 1 และ tag-2 ค่า 2

   

2. ที่ My Playbooks กด Add ตั้ง Threat Type = Security Alert และเงื่อนไขอย่างน้อย Status == Pending (เพิ่มเงื่อนไขอื่นได้ตามต้องการ) แล้วกด OK

   

3. ต่อจาก Start ด้วย Action Node Query security alert analysis tag เพื่ออ่าน Tag ปัจจุบันของ Alert

4. ต่อ Decision Node (เช่น ตั้งชื่อ Tag) ช่องตัวแปรเลือกพารามิเตอร์ Security Alert Tag Name จากผลของ Node ก่อนหน้า

   

5. ตั้ง 3 ทาง: If ชื่อ tag-1 กติกา Tag Name ∩ Constant tag-1, Else if ชื่อ tag-2 กติกา Tag Name ∩ Constant tag-2 และ Else ชื่อ tag-0 สำหรับ Alert ที่ยังไม่ถูกติด Tag แล้วกด OK

   

6. ทาง tag-0 (พบครั้งแรก): เพิ่ม Action Node Add security alert analysis tag ค่า 1 แล้วต่อ Action Node Adjust Security Alert Fixing Status เปลี่ยนเป็น Fixing หรือ Ignored พร้อมคอมเมนต์ "detected once"

   

7. ทาง tag-1 (พบครั้งที่สอง): Remove security alert analysis tag ค่า 1 → Add security alert analysis tag ค่า 2 → เปลี่ยนสถานะพร้อมคอมเมนต์ "detected twice"

8. ทาง tag-2 (พบครั้งที่สาม): ลบ Tag 2 แล้วเพิ่ม Tag 3

   

9. ต่อด้วย Node ดึง External IP ของ Alert (Obtain Alert External IP Information) แล้ว Action Node บล็อก เช่น Add IP to Blacklist ของไฟร์วอลล์ ช่อง IP Address อ้างถึงผลของ Node ดึง IP (จะเรียก Sub-playbook บล็อกแทนก็ได้) จากนั้นเปลี่ยนสถานะ Alert เป็น Fixed พร้อมคอมเมนต์ "detected thrice"

   

10. ต่อทุกทางไปที่ End แล้วกด Save and Enable แผนผังที่เสร็จแล้วเป็นดังภาพ

    

11. ทดสอบ: เมื่อ Alert ถูกพบครั้งแรก แท็บ SOAR Execution History ของ Alert แสดงผลของ Decision Node เป็น tag-0 และ Alert ถูกติด Tag 1

    

12. เมื่อพบครั้งที่สาม ผลของ Decision Node เป็น tag-2 Playbook สั่งบล็อก IP และ Alert เปลี่ยนเป็น Fixed ตรวจคอมเมนต์ทั้ง 3 ครั้งในบันทึกของ Alert และตรวจการบล็อกที่ Responses › Responses แท็บ Address Blocking

    

ข้อแนะนำในการออกแบบ Playbook

• เริ่มจาก Predefined Playbook แล้ว Clone มาปรับ ตรวจแท็บ Associated Apps ว่าตรงกับอุปกรณ์ขององค์กร
• ทดสอบด้วย Execute Manually ก่อนเสมอ เมื่อผลถูกต้องจึงเปลี่ยนเป็น Execute Automatically และเปิด Adaptive Unblocking
• ตั้งเงื่อนไขให้ตรงกับ Alert จริง มิฉะนั้น Playbook จะไม่ขึ้นในขั้น Matching
• Node ต้องต่อเส้นถึงกันจึงอ้างพารามิเตอร์ได้ และทุกเส้นทางต้องจบที่ End
• ป้องกันการบล็อกซ้ำด้วยการถามสถานะ Entity ก่อนบล็อก (Basic Playbook สำหรับบล็อก IP ทำให้แล้ว)
• ต้องการเลือกทุก Alert ยกเว้นบางกลุ่ม ใช้ Decision แบบกลับด้าน: ตั้งทาง If ให้จับ Tag ที่ไม่ต้องการด้วย AND แล้วให้ทาง Else รับ Alert ที่เหลือไปทำต่อ
• ใน Filter Node ใช้ตัวดำเนินการ ∩ และ not ∩ เพื่อแยก IP ที่อยู่ / ไม่อยู่ใน Whitelist จากช่องที่มีหลาย IP
• Playbook สำเร็จรูปบางตัวมีขั้นส่ง Instant Message ผ่าน Message App หากยังไม่ได้เชื่อม Message App ให้เลือก No notification และใช้ Template อีเมลของ SOAR แทน
• เก็บการสั่งเองไว้เป็นทางสำรองเสมอ และเริ่มจาก Auto Containment ก่อนเพิ่ม Playbook ทีละเรื่องตามงานที่ทีมทำซ้ำบ่อย