คุณสร้างแผนการตอบสนองต่อเหตุการณ์ที่ใช้ได้จริงได้อย่างไร

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

เริ่มต้นด้วยเฟส ไม่ใช่ playbook

NIST SP 800-61 ได้กำหนดสี่เฟส: การเตรียมการ การตรวจหาและวิเคราะห์ การกักเก็บ/การขจัด/การกู้คืน และกิจกรรมหลังเหตุการณ์ ลำดับนี้สำคัญ ทีมมักชอบที่จะข้ามไปที่การกักเก็บเพราะดูเหมือนว่ามีประสิทธิผล แต่ถ้าคุณยังไม่ได้ทำงานเตรียมการ คุณไม่รู้เครือข่ายของคุณเองเพียงพอที่จะกักเก็บสิ่งใดๆ ได้อย่างสะอาด

การเตรียมการหมายถึงสินทรัพย์ที่ปัจจุบันอยู่จริง ไม่ใช่สเปรดชีตจากปี 2022 มันหมายถึงการรู้ช่วงเวลาการเก็บบันทึกของคุณ (ถ้าเป็น 7 วันและผู้โจมตีใช้เวลา 30 วัน คุณได้สูญเสียไทม์ไลน์ไปแล้ว) มันหมายถึงเครื่องมือการสืบสวนที่ stage ไว้ล่วงหน้า — Velociraptor, KAPE หรือแม้แต่ขั้นตอน tar/dd ที่มีเอกสารสำหรับอิมเมจดิสก์ — เพื่อไม่ให้ใครดาวน์โหลดเครื่องมือลงในโฮสต์ที่ถูกโจมตีระหว่างเหตุการณ์ที่ใช้งานอยู่

กำหนดระดับความรุนแรงก่อนที่คุณจะต้องการมัน

SEV1 (การสอบถามข้อมูลที่ใช้งานอยู่ การดำเนินการ ransomware การพิจารณาผู้ดูแลโดเมน) ต้องการการตอบสนองแตกต่างจากการตอบสนอง SEV3 (มัลแวร์ที่โดดเดี่ยวในเวิร์กสเตชันที่ไม่มีสิทธิ์หนึ่งเครื่อง) เขียนลงมาเป็นเมทริกซ์: ผลกระทบ vs ขอบเขต vs ความมั่นใจ กำหนดเวลาการตอบสนองที่จำเป็นและเส้นทางการขยาย (escalation path) สำหรับความรุนแรงแต่ละระดับ ถ้าผู้บัญชาการเหตุการณ์ของคุณสำหรับ SEV1 คือบุคคลเดียวกับที่ต้องอนุมัติการซื้ออื่น ๆ ทุก $500 คุณได้สร้างคอขวดไว้ในกระบวนการฉุกเฉินของคุณเอง

บทบาท incident commander ไม่ใช่ทางเลือก

คนหนึ่งรัน incident นี้ ไม่จำเป็นต้องเป็นวิศวกรอาวุโสที่สุดตามค่าเริ่มต้น — บุคคลที่เหมาะสมที่สุดในการประสานงาน มอบหมายงาน และตัดสินใจการกักเก็บภายใต้ความกดดัน บุคคลนี้ไม่จำเป็นต้องสัมผัสแป้นพิมพ์ในระหว่างการตอบสนอง พวกเขาติดตามไทม์ไลน์ จัดการการสื่อสารกับอนุมติและผู้นำ และตัดสินใจเมื่อใดที่จะดึงก้าน isolating segment หรือ ปิดระบบออนไลน์

ถ้าไม่มีบทบาทนี้ คุณจะได้เห็นบุคคลห้าคน SSH ไปที่กล่องเดียวกัน ไม่มีใครพูดคุยกับอีกฝ่ายหนึ่ง และไม่มีใครจับภาพหน่วยความจำ volatile ก่อนที่ใครบางคนจะรีบูตเครื่องเพื่อ "ดูว่าจะแก้ไขได้หรือไม่"

การตัดสินใจการกักเก็บที่สำคัญจริง ๆ

การตัดสินใจที่ยากที่สุดในเหตุการณ์ส่วนใหญ่คือ: isolate ตอนนี้หรือสังเกตการณ์อีกเล็กน้อยเพื่อทำความเข้าใจขอบเขต? การดึง network access เร็วเกินไปจะทำให้ผู้โจมตีที่ยังคงเคลื่อนไหวได้ทั่วไป และทำลายโอกาสของคุณที่จะเห็นการเคลื่อนไหวครั้งต่อไปของพวกเขา การรอนานเกินไปจะปล่อยให้ ransomware จบการเข้ารหัส shares

จุดกึ่งกลางที่สมเหตุสมผล: ใช้ network segmentation และ EDR isolation (CrowdStrike, Defender for Endpoint, SentinelOne ทั้งหมดรองรับสิ่งนี้) เพื่อตัดโฮสต์ออกจากการเคลื่อนไหวข้างเคียง ในขณะที่ให้ฟังก์ชันนำไปยังการจับหน่วยความจำ การปิดเต็มที่ควรจะเป็นวิธีสุดท้าย — มันฆ่า volatile evidence และ สำหรับกรณี ransomware สามารถทริกเกอร์พฤติกรรมต้านการสืบสวนที่ฝังในบางเพย์โหลด

ช่องว่างการบันทึกที่คุณจะเสียใจในระหว่าง ไม่ใช่ก่อนหน้า

ค่าเริ่มต้นของ Windows Event Log ไม่เพียงพอ ถ้าคุณไม่ได้ deploy Sysmon ด้วยการกำหนดค่าที่สมควร (SwiftOnSecurity หรือ baseline configs ของ Olaf Hartong เป็นจุดเริ่มต้นที่ดี) คุณจะสร้างต้นไม้กระบวนการใหม่จากชิ้นส่วน ด้านเครือข่าย NetFlow หรือ Zeek logs มีความสำคัญมากกว่าที่องค์กรส่วนใหญ่รู้จักจนกว่าพวกเขาจะต้องตอบ