ขั้นตอนการกู้คืนที่ไม่มีใครใส่ไว้ใน runbook

แผนการกู้คืนทุกฉบับที่เราอ่านถูกวัดจากความเร็วที่ข้อมูลกลับมา Recovery time objective, recovery point objective, ชั่วโมงของ downtime, รายได้ ที่สูญเสียต่อชั่วโมง ตัวเลขเหล่านี้คือสิ่งที่อยู่บนสไลด์สำหรับผู้บริหาร และเป็น ตัวเลขที่ถูกต้องสำหรับสิ่งส่วนใหญ่ที่การกู้คืนต้องทำ

และนั่นก็เป็นเหตุผลว่าทำไมหนึ่งขั้นตอนจึงหายไปจาก runbook เกือบทุกฉบับใน ภูมิภาคนี้

วันที่ทั้งสอง

เริ่มจากไทม์ไลน์ เพราะไทม์ไลน์คือกลไกทั้งหมด

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

ตอนนี้ให้ถามว่า ทีมกู้คืนจะหยิบแบ็กอัปไหน พวกเขาจะหยิบ restore point ล่าสุดที่เชื่อว่าสะอาด ในทางปฏิบัติ นั่นหมายถึง restore point ล่าสุดที่สร้างก่อนที่เหตุการณ์จะถูก ตรวจพบ เพราะ การตรวจพบคือเหตุการณ์เดียวที่มี timestamp ซึ่งทุกคนเห็นพ้องต้องกัน

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

ตัวชี้วัดที่ลบขั้นตอนนั้นออก

นี่คือส่วนที่ได้รับความสนใจน้อยกว่า และมันไม่ใช่ปัญหาด้านเทคโนโลยีเลย

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

ไม่มีใครเขียนว่า "we skipped file hygiene" ลงใน runbook นั่นไม่ใช่วิธีที่ มันเกิดขึ้น ขั้นตอนนั้นไม่เคยอยู่ใน runbook มาก่อน ไม่มีตัวชี้วัดใดเคยเรียกร้องมัน และการ กู้คืนก็เสร็จตามกำหนด แรงจูงใจทำงานอย่างเงียบ ๆ

ดังนั้นรูปแบบจึงเกิดซ้ำ: เซิร์ฟเวอร์ถูกสร้างใหม่จากอิมเมจที่สะอาด, credentials ถูกหมุนใหม่, endpoint ถูก reimage, เครือข่ายถูกแบ่งส่วนอย่างเหมาะสมในครั้งนี้ จากนั้น fileshares, mailboxes และ document repositories ก็กลับมาเหมือนเดิมทุกประการ ไม่ถูกแตะต้อง ชั้นเดียวที่ไม่มีใครสร้างขึ้นมาใหม่คือชั้นที่พาสิ่งนั้นเข้ามา

เหตุใดการสแกนซ้ำจึงเป็นเครื่องมือที่ไม่เหมาะ

คำตอบที่ชัดเจนคือการสแกนแบ็กอัปก่อนกู้คืน และควรอธิบายให้ชัดเจนว่าทำไมวิธีนั้นจึงอ่อนกว่าที่ฟังดู

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

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

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

ขั้นตอน restore-hygiene มีลักษณะอย่างไร

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

โดยสรุป คือมีหนึ่งขั้นตอนที่แทรกระหว่างการ restore และการกลับเข้าสู่บริการ:

1. สร้างใหม่แทนที่จะตรวจสอบ. แยกเอกสารแต่ละฉบับออกเป็นส่วนประกอบ ตรวจสอบทุกส่วนเทียบกับข้อกำหนดที่เผยแพร่สำหรับรูปแบบนั้น แล้วสร้างไฟล์ใหม่เอี่ยมจากการแทนค่านั้น: ใช้สูตร ไม่ใช่ไบต์ต้นฉบับ ความแตกต่างนี้สำคัญกว่าที่ฟังดู การคัดลอกเฉพาะส่วนที่เอ็นจินตัดสินว่าดี ก็ยังเป็นการตัดสินว่าอะไรดูปลอดภัย ซึ่งก็คือการตรวจจับที่สวมเสื้อผ้าคนละแบบ และไฟล์ต้นฉบับก็ยังเป็นไฟล์ที่เข้ามาอยู่ดี การสร้างใหม่จะไม่ส่งผ่านต้นฉบับเลย ดังนั้นจึงไม่มีอะไรรอดมาได้เพราะไม่ถูกจดจำ นี่คือสิ่งที่ Content Disarm and Reconstruction แบบกำหนดแน่นอนทำ; Glasswall รายงานว่าไฟล์อันตราย 100% ถูกทำให้เป็นกลางจากการทดสอบ 8.27 ล้านไฟล์ และกรณีศึกษาศูนย์วิจัยภาครัฐของบริษัทอธิบายการกู้คืนที่จัดลำดับแบบนี้
2. เก็บบันทึกแยกตามไฟล์. สำหรับเอกสารแต่ละฉบับ เอาอะไรออกไป ภายใต้นโยบายใด เวลาใด นี่คือหลักฐานที่รายงานเหตุการณ์ของคุณต้องใช้ และเป็นหลักฐานที่ผู้ประเมินจะขอ และไม่สามารถสร้างย้อนหลังได้
3. จัดลำดับตาม blast radius ไม่ใช่ตามตัวอักษร. ไดรฟ์ที่ใช้ร่วมกัน กล่องจดหมาย และทุกอย่างที่ไปอยู่ในไปป์ไลน์อัตโนมัติควรมาก่อน แชร์ของฝ่ายการเงินที่ป้อนกระบวนการรายเดือนที่ขับเคลื่อนด้วยมาโคร เป็นปัญหาระดับสูงกว่าคลังเก็บที่ไม่มีใครเปิด
4. สมมติว่า estate ยังถูกแยกเป็นเกาะ. ระหว่างการกู้คืน มักไม่มีเครือข่ายให้ส่งไฟล์ข้ามไป ซึ่งเป็นเหตุผลว่าทำไมการประมวลผลที่อยู่บนเดสก์ท็อปจึงสำคัญในบริบทนี้ ในแบบที่ไม่สำคัญในสภาวะปกติ Glasswall Meteor รันเอ็นจินในเครื่อง ทั้งแบบออนไลน์ ออฟไลน์ หรือ air-gapped

ไม่มีอะไรในนี้ที่หรูหรา และไม่มีอะไรในนี้เป็นวิศวกรรมใหม่ มันคือหนึ่งขั้นตอนและการตัดสินใจที่จะใช้เวลา

ครึ่งหนึ่งของหลักฐาน

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

Cybersecurity Code of Practice for Critical Information Infrastructure ของสิงคโปร์ระบุไว้ชัดเจนในข้อ 6.1.4: ต้องเก็บ logs ไว้อย่างน้อยสิบสองเดือนหลังเหตุการณ์ที่บันทึกไว้ ป้องกันการแก้ไขและการลบโดยไม่ได้รับอนุญาต และ "อยู่ภายใต้ log retention policy เพื่ออำนวยความสะดวกในการสืบสวนเหตุการณ์ด้าน cybersecurity" การเก็บรักษาที่มีวัตถุประสงค์ตามที่ระบุไว้คือการสืบสวน ไม่ใช่คลังเก็บ

MAS Technology Risk Management Guidelines กำหนดความคาดหวังที่สอดคล้องกันสำหรับสถาบันการเงิน: ไฟล์ที่ไม่น่าเชื่อถือซึ่งมาถึงทางเมล พอร์ทัลอัปโหลด หรือการแลกเปลี่ยนกับบุคคลที่สาม จะถูกจัดการที่ขอบเขตระบบ แทนที่จะยอมรับเข้ามาเพียงเพราะผลการตรวจจับบอกว่าใช้ได้

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

คำถามที่ควรถาม

แผนการกู้คืนถูกซักซ้อม ขั้นตอน restore-hygiene ถูกเพิ่มหลังเหตุการณ์ครั้งที่สอง ซึ่งเป็นจุดที่มีต้นทุนสูงในการเรียนรู้เรื่องนี้

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

สำหรับภาพรวมภาระหน้าที่ทั้งหมดในสิงคโปร์ รวมถึง Cybersecurity (Amendment) Act 2024 และการอัปเดต CCoP ที่ประกาศในเดือนกรกฎาคม 2026 ดูหน้า compliance ของสิงคโปร์