รูปแบบการดูแลระบบ Athena XDR และการทำงานร่วมกับ Sangfor MDR (Self-run, Hybrid, Fully Managed)

Athena XDR ช่วยคัดกรองและสรุปเรื่องให้ทีม แต่การเฝ้าระวังตลอด 24 ชั่วโมงยังต้องใช้คน บทความนี้อธิบายรูปแบบการดูแลระบบสามแบบ การแบ่งหน้าที่เมื่อทำงานร่วมกับทีม Sangfor MDR สิ่งที่ต้องเตรียมก่อนเริ่มบริการ การติดตามงานของทีม MDR บน Console และการวัดผล เหมาะสำหรับผู้บริหารด้าน IT หัวหน้าทีม Security และทีม SOC ที่กำลังเลือกรูปแบบหรือเริ่มใช้บริการ

รูปแบบการดูแลระบบสามแบบ

Asset สำคัญคือเครื่องที่ถ้าหยุดหรือถูกเจาะ งานของธุรกิจจะหยุดตาม เช่น Server ที่ให้บริการและ Database ทุกแบบใช้ Athena XDR และ Security GPT ชุดเดียวกัน องค์กรเริ่มจากดูแลเองแล้วเพิ่มบริการ MDR ภายหลังได้ ทีมที่มีคนอยู่บ้างอาจเริ่มทำร่วมกันจาก Asset สำคัญไม่กี่เครื่อง เมื่อสองทีมทำงานเข้ากันแล้วจึงขยายขอบเขต

Athena MDR เป็นบริการจากผู้เชี่ยวชาญของทีม Sangfor MDR ที่ได้รับการรับรองกว่า 450 คน ดูแลตลอด 24 ชั่วโมง และ SOC ของบริการได้รับการรับรอง ISO 27001:2022 ทีม MDR ทำงานบน XDR ตัวเดียวกับองค์กร ทีมขององค์กรจึงเปิด Console เดียวกันได้ตลอด

การแบ่งหน้าที่ในแบบ Hybrid

ทั้งสองทีมเห็นผลวิเคราะห์ชุดเดียวกันในคอลัมน์ Security GPT Analysis Result งานซ้ำ ๆ อย่างประเมิน Alert สรุป Incident และแปลง Log ให้ AI ทำก่อน แล้วคนตรวจซ้ำ หากต้องการให้ Security GPT สรุปพฤติกรรมเฉพาะขององค์กรต่างไป ใช้กฎ GPT Tuning (Whitelists)

ตกลงการแจ้งเตือนและการตัดสินใจให้ชัดก่อนเริ่มบริการ

• รายชื่อผู้ติดต่ออย่างน้อยสองคนต่อเรื่อง เพื่อให้รับแทนกันได้ และแยกบทบาทผู้รับแจ้ง ผู้อนุมัติ และผู้ลงมือแก้ในระบบ
• ช่องทางรับการแจ้งเตือนจากทีม MDR ซึ่งส่งเป็นการ์ดภาษาไทยที่มีระดับความรุนแรง เครื่องที่เกี่ยวข้อง และคำแนะนำ เรื่องระดับวิกฤติจะระบุชื่อผู้ติดต่อหลักไว้ด้วย เรื่องที่ไม่วิกฤติกดรับทราบ และงานที่ต้องแก้ในทีมขององค์กรเปิดเป็น Ticket ใน Ticketing System
• การกระทำที่อนุญาตไว้ล่วงหน้า เช่น บล็อก IP ภายนอกที่ชัดเจนว่าเป็นอันตราย และการกระทำที่ต้องถามก่อน เช่น แยก Server ที่ให้บริการธุรกิจ เพราะงานที่พึ่งระบบนั้นจะหยุดทันที
• เขียนข้อตกลงทั้งหมดไว้ในเอกสารหน้าเดียว ส่งฉบับเดียวกันให้ทีม MDR และแก้ทุกครั้งที่คนหรือระบบเปลี่ยน

การเริ่มใช้บริการ MDR

ก่อนทีม MDR จะเริ่มเฝ้าได้ ต้องเห็นข้อมูลชุดเดียวกับองค์กร

1. ใช้ Platform-X ID เดียวกัน XDR และบริการ MDR ต้องใช้ Platform-X ID เดียวกัน เมื่อใช้รหัสเดียวกัน XDR, บริการ MDR และ EPP จะใช้ข้อมูลร่วมกันเองและทีม MDR เห็น Incident ตั้งแต่วันแรก หากองค์กรใช้บริการ MDR อยู่ก่อนแล้ว ให้ใช้ Platform-X ID ของบริการนั้นเปิดใช้ XDR หากไม่แน่ใจว่าใช้ ID ใด สอบถามทีม Sangfor MDR

2. ย้ายแหล่งข้อมูลมาที่ XDR อุปกรณ์ที่เคยส่งข้อมูลตรงไปที่บริการ MDR ให้ย้ายมาส่งที่ XDR แทน EPP ที่เคยเชื่อมกับบริการ MDR ให้ตัดการเชื่อมต่อแล้วเชื่อมเข้า XDR (การเชื่อมต่อ Athena EPP) จากนั้นให้ผู้ดูแลด้าน Security ตรวจว่าเห็นข้อมูลของเครื่องครบ ส่วน Athena NDR ให้ย้ายมาเชื่อมที่ XDR และใช้ Auth Info ชุดใหม่ที่ XDR สร้างให้

3. ตรวจการเก็บข้อมูลของ EPP หาก EPP เชื่อมทั้ง XDR และ NDR ให้เปิดเก็บข้อมูลพฤติกรรมและ Log ของเครื่องให้ครบทุกกลุ่ม ทั้ง Windows และ Linux และตรวจ Edition ของ EPP บนเครื่องในขอบเขตกับทีม MDR ก่อนเริ่มโครงการ

4. XDR แบบ On-premises เชื่อมกับบริการ MDR ผ่าน Cloud Connection

ลำดับงานโดยทั่วไปตั้งแต่ตกลงใช้บริการจนทีม MDR เริ่มเฝ้าจริง: เปิดโครงการ ตั้งทีม ตกลงขอบเขตบริการและช่องทางสื่อสาร › เลือก Asset ที่ให้ทีม MDR ดูแล เจ้าของ และผู้ติดต่อ › เตรียมระบบ ต่ออุปกรณ์ให้ครบ ตรวจ Policy และตั้ง Mirror Traffic (ทีม MDR ช่วยดูว่าอุปกรณ์ในขอบเขตส่งข้อมูลครบ) › ผู้เชี่ยวชาญวิเคราะห์ภัยและจุดเสี่ยงที่ค้างอยู่ แล้วส่งรายงานฉบับแรกพร้อมลำดับการแก้ › แก้ตามรายงาน แล้วทีม MDR เริ่มเฝ้าเต็มรูปแบบและส่งรายงานตามรอบ องค์กรที่ใช้ Athena XDR แบบ SaaS มี Customer Success Manager ของ Sangfor ช่วยประสานงานช่วงเริ่มต้นให้ทั้งสองฝ่าย

กำหนด Asset สำคัญและเตรียมข้อมูล

รายการ Asset ที่ตกลงให้ทีม MDR ดูแลควรตรงกับ Asset ที่ Mark เป็น Critical ใน XDR เพื่อให้ทั้งสองทีมดูรายการเดียวกัน

1. ไปที่ Asset Center › Assets › Active Assets คลิกช่องตัวกรอง เลือก Asset Criticality แล้วตั้งค่าเป็น Critical Asset รายการจะเหลือเฉพาะ Asset สำคัญ

   

2. หากต้องการเพิ่มหรือนำเครื่องออก ติ๊กแถวของเครื่องแล้วเปิดเมนู Mark Asset เลือก As Critical หรือ As Noncritical

   

3. ตรวจจำนวนได้อีกทางที่การ์ด Asset Protection ใน Monitor Overview โดยกดสลับจาก All เป็น Critical

   

เมื่อมีระบบใหม่หรือเลิกใช้ระบบใด แจ้งทีม MDR ให้ปรับรายการให้ตรงกันทุกครั้ง และตรวจรายการอุปกรณ์ของบริการกับทีม Sangfor MDR ไปพร้อมกัน

ทีม MDR วิเคราะห์จากข้อมูลที่เข้ามาใน XDR ก่อนเริ่มบริการจึงต้องให้ Asset สำคัญส่งข้อมูลครบ

• ติดตั้ง EPP ให้ครบทุก Server ในขอบเขต
• STA รับ Traffic ของโซน Server ครบทั้งสองทิศทาง เพราะต้องเห็นทั้งคำขอและคำตอบ (จุดวาง STA)
• อุปกรณ์ทุกตัวในขอบเขตผ่าน 4 จุดในหน้า Native Devices คือ Online, Log Reporting และ Coordinated Response เป็นสีเขียว และมี Log ของวันนี้ใน Log Details (การตรวจสุขภาพการเชื่อมต่ออุปกรณ์)
• อุปกรณ์ของผู้ผลิตอื่นในขอบเขตควรถึง Level 2 หรือ Level 3 ในแท็บ Data Quality Analysis (Data Quality Analysis) และอุปกรณ์ Sangfor ใช้เวอร์ชันตามตารางที่แนะนำ

วงจรการทำงานของบริการ MDR

1. ข้อมูลจาก Endpoint และเครือข่ายไหลเข้า XDR AI คัดสัญญาณสำคัญ เชื่อมโยงข้อมูล และลดเรื่องที่เตือนผิด แล้วส่งเรื่องที่ต้องใช้คนให้ผู้เชี่ยวชาญ

2. ผู้เชี่ยวชาญตรวจว่าเป็นภัยจริงหรือไม่และกระทบอะไร เมื่อยืนยันแล้วจะแจ้งองค์กรพร้อมคำแนะนำ ทีมขององค์กรกดรับทราบ ขอความช่วยเหลือ หรือสอบถามกลับได้

3. หากต้องแก้ไข ทีม MDR แนะนำวิธีแก้และการตั้งค่าอุปกรณ์ บางเรื่องช่วยลงมือจากระยะไกล งานที่กระทบระบบจะถามองค์กรก่อนและแจ้งผลเมื่อเสร็จ การบล็อกที่ทำผ่าน XDR จะแสดงในหน้า Responses ให้ตรวจย้อนได้

4. เรื่องที่ปิดแล้วนำไปปรับกฎการตรวจจับ ครั้งต่อไปสัญญาณแบบเดียวกันจึงถูกจับได้เร็วขึ้น

นอกจากเฝ้า Alert ทีม MDR ยังล่าภัยเชิงลึกด้วย Logic ตรวจจับที่ตั้งเฉพาะระบบงานหรือช่องโหว่ขององค์กร เพื่อหาเครื่องที่ถูกยึด ผู้ใช้ที่ถูกหลอก และบัญชีที่รั่วตั้งแต่เนิ่น ๆ สืบสวน Incident ประเมินผลกระทบ ย้อนหาสาเหตุ และจัดทำรายงาน ช่วยจัดการเหตุทั่วไปอย่างโทรจันหรือ Cryptomining จากระยะไกล และสำหรับเหตุใหญ่ช่วยควบคุมความเสี่ยงและเสนอวิธีเสริมความปลอดภัย รายงานสรุปสถานะความปลอดภัยส่งตามรอบที่ตกลง เช่น รายสัปดาห์หรือรายเดือน ใช้นำเสนอผู้บริหารหรือประกอบการตรวจสอบภายในได้

ติดตามงานของทีม MDR บน Console

งานที่ทีม MDR ทำดูได้ที่หน้า Detections › Security Incidents หน้าเดียวกับที่ทีมขององค์กรใช้

• คลิกช่องตัวกรอง ในรายการฟิลด์มี MDRIncidentID ฟิลด์นี้เป็นคอลัมน์ MDR Incident ID ในตารางด้วย (อยู่ใกล้ Latency และ Closed By) แสดงความคืบหน้าของงาน MDR สี่ขั้น ตั้งแต่พบความเสี่ยง ผู้เชี่ยวชาญตรวจสอบ ติดตามผล จนปิด Incident สำหรับ XDR แบบ On-premises ฟิลด์เดียวกันนี้ชื่อ Mss Incident Service Status

• ชี้ที่ไอคอนข้างค่าในคอลัมน์ Latency จะเห็นเวลาของแต่ละขั้น ตั้งแต่การวิเคราะห์ความเชื่อมโยงจนถึงการรับทราบ Incident ทำให้รู้ว่าเวลาหมดไปกับขั้นใด

• เพิ่มคอลัมน์ Fixing Duration ได้จากปุ่มสามจุดท้ายหัวตาราง พิมพ์ Fixing แล้วติ๊ก Fixing Duration เอาตัวกรองสถานะออกเพื่อให้เห็นเรื่องที่ปิดแล้ว คอลัมน์ Closed By บอกว่าใครปิดเรื่อง ส่วน Fixing Duration บอกเวลาที่ใช้จัดการ

ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร ชื่อ Owner ของกลุ่ม Asset ที่แสดงในช่อง Affected Asset ของแต่ละ Incident ช่วยให้รู้ทันทีว่าต้องส่งต่อเรื่องให้ใคร

การวัดผลและงานประจำ

คำตอบที่ดีที่สุดว่าทำร่วมกับทีม MDR แล้วดีขึ้นแค่ไหน คือตัวเลขบน Console เทียบกับก่อนเริ่มบริการ จึงต้องจดตัวเลขตั้งต้นไว้ เช่น เวลาที่ทีมใช้ตรวจ Alert และจำนวนเรื่องที่ค้าง แล้วเทียบทุกเดือน

• เวลา Latency คือเวลาตั้งแต่ตรวจพบจนเรื่องขึ้นใน Console ส่วน Fixing Duration คือเวลาจัดการจนเสร็จ หลายองค์กรใช้เป็นตัวชี้วัด MTTD และ MTTR ใช้ไอคอนดาวน์โหลดที่มุมขวาของรายการ Incident เก็บรายการทุกสิ้นเดือน ในไฟล์มีคอลัมน์ Fixing Duration เป็นวินาทีสำหรับหาค่าเฉลี่ย
• ปริมาณงาน การ์ด Progress บน Monitor Overview แสดง Handled Incidents และ Incident Fixing Rate กดไอคอนเฟืองเพื่อเพิ่มช่อง Saved Time ส่วนการ์ด Auto Containment แสดง Average Block Time

  

• งานของ Security GPT หน้า Guarding Overview แสดง Alert Analysis Coverage และ Time Saved (Monitor Overview และ Guarding Overview)

นำตัวเลขเหล่านี้ไปทบทวนกับทีม MDR ทุกเดือน เพื่อตกลงว่าจะปรับขอบเขตหรือกฎใดต่อ องค์กรที่มี SOC หรือระบบ Ticket ของตัวเองดึง Incident, Alert, Asset และช่องโหว่จาก XDR ผ่าน API Key แยกตามระบบได้ (API Keys)

งานประจำของทีมขององค์กรเมื่อใช้แบบ Hybrid

• ทุกวัน ตอบการแจ้งเตือนจากทีม MDR ตามที่ตกลง ตัดสินใจคำขออนุมัติให้ชัด และแจ้งทีม MDR ล่วงหน้าก่อนสแกนช่องโหว่หรือทดสอบระบบตามแผน พร้อมเวลาและเครื่องต้นทาง บน Console เริ่มที่การ์ด Pending Issues และวงกลม Security Incidents ตามเดิม (งานประจำวันของทีม SOC)
• ทุกสัปดาห์ ทำ System Check และดูสถานะอุปกรณ์ของผู้ผลิตอื่นที่ Device Connection หากอุปกรณ์หรือ Agent ใดหยุดส่งข้อมูล ทีม MDR จะแจ้งให้ช่วยตรวจด้วย
• ทุกเดือน อ่านรายงานบริการ ทบทวน Whitelist และปรับรายการ Asset สำคัญให้ทันระบบใหม่

ข้อมูลของ Tenant อยู่ใน Data Center ตามภูมิภาคที่เลือกตอนเปิด Tenant ข้อตกลงด้านข้อมูลเปิดดูได้ที่ Configuration › Basic Configuration › Data Privacy แท็บ Privacy Policy ซึ่งมีลิงก์ End User License Agreement และ Data Processing Agreement ส่วนการเข้าถึงข้อมูลของทีม MDR ดูรายละเอียดในข้อตกลงบริการ และทบทวนร่วมกับทีม Sangfor ก่อนเริ่มใช้บริการ