Binance Hack: ผลกระทบประเมิน 6.3

ตามรายงานล่าสุด Binance เปิดเผยผลกระทบรวมประมาณ 6.3 พันล้านดอลลาร์จากการถูกแฮ็ก พร้อมระบุว่าสินทรัพย์มูลค่า 3 พันล้านดอลลาร์ได้รับการยืนยันว่าอยู่ในสถานะถูกแช่แข็ง รายละเอียดยังอยู่ระหว่างการสอบสวน ดังนั้นเส้นทางทางเทคนิคของเหตุการณ์และการระบุความเกี่ยวข้องที่กว้างขึ้นควรถูกพิจารณาเป็นข้อสันนิษฐานเบื้องต้น ไม่ใช่ข้อเท็จจริงที่ตัดสินแล้ว

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

รายงานปัจจุบันเกี่ยวกับเหตุการณ์ Binance มีอะไรบ้าง?

รายงานล่าสุดระบุเหตุการณ์ที่ Binance โดยมีผลกระทบโดยประมาณรวม 6.3 พันล้านดอลลาร์ สินทรัพย์ที่ถูกยืนยันว่าแช่แข็งมูลค่า 3 พันล้านดอลลาร์ และเส้นทางที่คาดว่าเกี่ยวข้องกับการแฮ็กแล็ปท็อปของวิศวกร DevOps การเข้าถึงคอนเทนเนอร์บริการ และการส่งรายการถอนเงินที่ไม่ได้รับอนุญาต Binance รายงานว่าไม่พบหลักฐานรั่วไหลของกุญแจส่วนตัวในกระเป๋าเงิน หยุดการถอนเงินระหว่างการปรับปรุงระบบความปลอดภัย และยังคงให้บริการฝากเงินเป็นปกติ

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

รายงาน	รายละเอียดที่ชัดเจน	การตีความด้านความปลอดภัย
ผลกระทบโดยประมาณ	Binance ระบุว่าประเมินผลกระทบรวม 6.3 พันล้านดอลลาร์	ตัวเลขที่รายงานสะท้อนภาพรวมการประเมินเหตุการณ์ ไม่ใช่ยอดการสูญเสียสุดท้าย
สินทรัพย์ที่แช่แข็ง	Binance ระบุว่ายืนยันได้ว่ามีสินทรัพย์แช่แข็ง 3 พันล้านดอลลาร์	การแช่แข็งเป็นผลลัพธ์ของการควบคุมและต้องการการตรวจสอบสินทรัพย์ระดับเจาะจง
การเข้าถึงเบื้องต้นที่สงสัย	แล็ปท็อปของวิศวกร DevOps ถูกแฮ็ก อาจเปิดทางเข้าสู่คอนเทนเนอร์บริการ	การถูกละเมิดที่จุดปลายทางสามารถลุกลามเป็นการละเมิดในระบบปฏิบัติการเมื่อขอบเขตการปฏิบัติการอ่อนแอ
เส้นทางรายการธุรกรรมที่สงสัย	ผู้โจมตีอาจส่งรายการถอนเงินที่ไม่ได้รับอนุญาต	เวิร์กโฟลว์การถอนเงินต้องมีการควบคุมมากกว่าการเก็บกุญแจในกระเป๋าเงิน
กุญแจในกระเป๋าเงิน	Binance กล่าวว่าพบไม่มีหลักฐานรั่วไหลของกุญแจส่วนตัว	เหตุการณ์ถอนเงินผิดกฎหมายสามารถเกิดขึ้นโดยไม่ต้องมีการขโมยกุญแจลงนามระยะยาวโดยตรง
ความต่อเนื่องของบริการ	หยุดถอนเงิน ช่วยให้ฝากเงินยังดำเนินการได้ และคาดว่าจะเริ่มบริการถอนใหม่ภายใน 48 ชั่วโมง	การแยกการทำงานเข้ากับออกช่วยรักษาบริการบางส่วนในระหว่างการควบคุม
การดำเนินการของ Arbitrum	Arbitrum Security Council รายงานการแช่แข็ง 30.5 ล้านดอลลาร์ที่เกี่ยวข้องกับ 74.6 ล้าน ARB และ 8,425 ETH	การประสานงานข้ามระบบสามารถจำกัดการเคลื่อนย้ายสินทรัพย์ที่ได้รับผลกระทบได้
การดำเนินการของ Aave	Aave แช่แข็งตลาดใน V3 และ V4 เพื่อป้องกันโดยไม่เกิดเหตุ	โปรโตคอลที่พึ่งพาอาจต้องลดความเสี่ยงก่อนที่สาเหตุทางเทคนิคเต็มจะได้รับการทราบ

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

นี่คือเหตุผลที่รายงานเหตุการณ์ควรแยกข้อเท็จจริงที่ยืนยันแล้วออกจากสมมุติฐานการสอบสวน การแฮ็กแล็ปท็อป DevOps ที่สงสัยเป็นเส้นทางที่รายงานและอยู่ระหว่างการตรวจสอบ การขาดหลักฐานการรั่วไหลของกุญแจส่วนตัวเป็นข้อแถลงเชิงปฏิบัติการที่มีความหมาย แต่ไม่สามารถระบุการควบคุมทั้งหมดที่อาจล้มเหลวได้ด้วยตัวมันเอง

แล็ปท็อปที่ถูกแฮ็กสามารถนำไปสู่การถอนเงินที่ไม่ได้รับอนุญาตได้อย่างไร?

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

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

1. ชั้นจุดปลายทางมนุษย์: แล็ปท็อปผู้ดูแลระบบ, ฮาร์ดแวร์โทเค็น, ตัวจัดการรหัสผ่าน, เว็บเบราว์เซอร์ที่ปลอดภัย, เครื่องมือพัฒนา, และไคลเอนต์เข้าถึงระยะไกล
2. ชั้นตัวตน: เซอร์วิสเข้าสู่ระบบครั้งเดียว, การจัดการการเข้าถึงพิเศษ, การมอบหมายบทบาท, ควบคุมเซสชัน และการเข้าถึงฉุกเฉิน
3. ชั้นเวิร์กโหลด: คอนเทนเนอร์บริการ, ระบบจัดการออเคสเตรชัน, การฉีดความลับ, API, และคิวข้อความภายใน
4. ชั้นธุรกรรม: กฎการถอน, รายการอนุญาต, ข้อจำกัดความเร็ว, เครื่องมือประเมินความเสี่ยง, การอนุมัติแบบหลายฝ่าย, คำขอลงนาม และการตรวจสอบการตั้งบัญชี
5. ชั้นกักเก็บ: ชิ้นส่วนกุญแจ, อุปกรณ์ลงนาม, เงินสำรองออฟไลน์, โมดูลความปลอดภัยฮาร์ดแวร์, และกระบวนการกู้คืน

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

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

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

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

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

ทำไมการไม่มีรายงานการรั่วไหลของกุญแจส่วนตัวจึงไม่ยุติการสอบสวน?

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

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

ความแตกต่างนี้สร้างคำถามทางความปลอดภัยสองชุดแยกกัน:

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

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

การสอบสวนที่น่าเชื่อถือควรรักษาพยานหลักฐานจากเทเลเมทรีของจุดปลายทาง บันทึกตัวตน กิจกรรมคอนเทนเนอร์ การตั้งค่าโครงสร้างพื้นฐาน คิวธุรกรรม บันทึกการอนุมัติ และร่องรอยบนเชน นอกจากนี้ควรกำหนดช่วงเวลาที่ชัดเจน: การเข้าถึงที่น่าสงสัยครั้งแรก การยกระดับสิทธิ์ การโต้ตอบกับบริการ การส่งคำขอถอนเงิน คำขอลงนาม การกระจายข่าวสาร การควบคุม และการแช่แข็งสินทรัพย์

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

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

การตอบสนองของ Arbitrum และ Aave แสดงอะไรบ้าง?

การดำเนินการที่รายงานโดย Arbitrum Security Council และ Aave แสดงให้เห็นว่าการควบคุมความเสียหายสามารถขยายไปเกินกว่าแลกเปลี่ยนที่ได้รับผลกระทบโดยตรง เมื่อสินทรัพย์และสภาพคล่องมีการปฏิสัมพันธ์กับระบบ onchain ที่กว้างขึ้น Arbitrum Security Council รายงานการแช่แข็ง 30.5 ล้านดอลลาร์ ซึ่งประกอบด้วย 74.6 ล้าน ARB และ 8,425 ETH ขณะที่ Aave รายงานแช่แข็งตลาดใน V3 และ V4 เพื่อป้องกันก่อน

การดำเนินการเหล่านี้สะท้อนโมเดลตอบสนองสองแบบที่แตกต่างแต่เสริมกัน

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

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

เปรียบเทียบนี้มีประโยชน์กับทุกทีมโปรโตคอลที่ออกแบบแผนตอบสนองฉุกเฉิน:

วิธีการตอบสนอง	ผู้ดำเนินการที่รายงาน	การดำเนินการเฉพาะที่รายงาน	วัตถุประสงค์หลักเพื่อป้องกัน
การจำกัดสินทรัพย์เฉพาะ	Arbitrum Security Council	แช่แข็ง 30.5 ล้านดอลลาร์ ที่ประกอบด้วย 74.6 ล้าน ARB และ 8,425 ETH	ป้องกันการเคลื่อนย้ายสินทรัพย์ที่ถูกระบุเพิ่มเติม
มาตรการป้องกันตลาดกว้าง	Aave	แช่แข็งตลาดใน V3 และ V4	ลดการแพร่กระจายผ่านตลาดสินเชื่อ
การหยุดบริการศูนย์กลาง	Binance	หยุดถอนเงินระหว่างปรับปรุงระบบความปลอดภัย	หยุดการโอนออกเพิ่มเติม ขณะยังคงบริการรับฝากเงิน

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

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

สำหรับการวิเคราะห์เพิ่มเติมเกี่ยวกับสถาปัตยกรรมความปลอดภัย การควบคุมธรรมภิบาล และความเสี่ยงของโปรโตคอลจากเหตุการณ์ ผู้อ่านสามารถสำรวจ ศูนย์วิจัย Soken

ทีมงานควรเปลี่ยนแปลงอะไรหลังจากรูปแบบการโจมตีที่รายงานนี้?

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

การทบทวนเชิงปฏิบัติควรเริ่มต้นจากเส้นทางธุรกรรมที่มีมูลค่าสูงสุด ไม่ใช่รายการตรวจสอบโครงสร้างพื้นฐานทั่วไป

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

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

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

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

5. กำหนดโดเมนอนุมัติแยกอิสระ การตัดสินใจถอนที่สำคัญไม่ควรพึ่งพาการอนุมัติที่ควบคุมโดยสภาพแวดล้อมจุดปลายทางเดียวกัน ผู้ให้บริการตัวตน หรือบทบาทผู้ดูแลเดียวกัน

6. ซ้อมระบบแยกตัวโดยไม่ปิดทั้งหมด Binance รายงานว่าระบบฝากเงินยังดำเนินการอยู่ในขณะที่หยุดถอน ทีมงานควรวางแผนล่วงหน้าว่าบริการใดจะยังคงใช้งานได้ บริการใดจะต้องหยุด และการควบคุมใดกำหนดการเริ่มทำงานใหม่อย่างปลอดภัย

7. กำหนดการประสานงานภายนอกล่วงหน้า การดำเนินการของ Arbitrum Security Council และการแช่แข็งตลาดของ Aave แสดงให้เห็นว่าการติดต่อกับแลกเปลี่ยน เครือข่าย สะพาน และโปรโตคอลควรจัดตั้งก่อนเกิดเหตุฉุกเฉิน ในเหตุการณ์จริง คุณภาพของการประสานงานมักกำหนดได้ว่าการควบคุมเป็นไปอย่างรวดเร็วหรือแยกส่วน

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

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

การระบุที่รายงานว่าเป็น TraderTraitor ซึ่ง TRM Labs ให้ความมั่นใจสูงควรได้รับการจัดการอย่างมีวินัยในขณะที่รายละเอียดยังอยู่ระหว่างการตรวจสอบ การระบุความเกี่ยวข้องสามารถนำทางการเฝ้าระวังและการประสานงานป้องกัน แต่ไม่ควรแทนที่การแก้ไขปัญหาที่ใช้หลักฐาน ความล้มเหลวของการควบคุมแบบเดียวกันอันตรายไม่ว่าจะผู้โจมตีเป็นใคร

สร้างแบบฝึกหัดตอบสนองการถอนครั้งต่อไปโดยอิงจากลำดับเหตุการณ์ของ Binance ที่รายงาน: สมมติว่าแล็ปท็อป DevOps ถูกคอมโปรไมส์ ติดตามสิทธิ์การเข้าใช้คอนเทนเนอร์บริการที่เข้าถึงได้ และยืนยันว่าไม่มีคำขอใดที่เกิดขึ้นสามารถหลบเลี่ยงนโยบายการถอนอิสระและการตรวจสอบการลงนามได้ แบบฝึกหัดนี้จะเปลี่ยนผลกระทบที่รายงาน 6.3 พันล้านดอลลาร์เป็นการทดสอบออกแบบที่เป็นรูปธรรม ขณะเดียวกันก็ยึดการตอบสนองเหตุการณ์ไว้กับหลักฐาน ขอบเขตการเข้าถึง และการควบคุมปฏิบัติการที่กู้คืนได้