แบบจำลองภัยคุกคามที่มีประโยชน์อธิบายว่าคุณปกป้องอะไร ใครหรืออะไรสามารถส่งผลกระทบได้ ความเชื่อถือเปลี่ยนแปลงที่ใด และคุณจะลดและทดสอบความเสี่ยงที่สำคัญที่สุดอย่างไร เริ่มจากโครงการจริงแทนที่จะเป็นรายการเครื่องมือทั่วไป
กำหนดขอบเขตให้เล็กพอที่จะให้เหตุผลได้
เริ่มจากบริการที่ใช้งานได้หนึ่งอย่าง: พอร์ทัลลูกค้า เว็บไซต์เผยแพร่ หรือแอปพลิเคชันภายใน เขียนองค์ประกอบที่คุณดำเนินการและระบบภายนอกที่คุณพึ่งพา แบบจำลองภัยคุกคามควรทำให้สมมติฐานมองเห็นได้ ไม่ใช่บอกว่าการโจมตีที่เป็นไปได้ทั้งหมดได้รับการแก้ไขแล้ว เก็บเวอร์ชันแรกให้เล็กพอที่ผู้ติดตั้งใช้งานแอปพลิเคชันจะอธิบายได้โดยไม่ต้องมีที่ปรึกษาแยกมาตีความแผนภาพ
ระบุผลลัพธ์และสินทรัพย์ที่มีค่า ซึ่งอาจรวมถึงข้อมูลลูกค้า การเข้าถึงของผู้ดูแล สถานะการชำระเงิน เนื้อหาที่เผยแพร่ และความสามารถในการกู้คืนบริการ ความพร้อมใช้งานอาจเป็นสินทรัพย์ได้แม้ข้อมูลจะเป็นสาธารณะ ตัดสินใจว่าความล้มเหลวใดจะสร้างความไม่สะดวกและความล้มเหลวใดจะสร้างความเสียหายต่อผู้คนหรือองค์กร ความแตกต่างนั้นช่วยให้คุณจัดลำดับความสำคัญของการควบคุมแทนที่จะปฏิบัติต่อคำเตือนทุกอย่างเท่าเทียมกัน
วาดจุดที่ความเชื่อถือเปลี่ยนแปลง
คำแนะนำแบบจำลองภัยคุกคามของ OWASP ใช้การไหลของข้อมูลและขอบเขตความเชื่อถือเพื่อทำให้การออกแบบเข้าใจได้ สำหรับแอปพลิเคชันโฮสต์ขนาดเล็ก ให้วาดเบราว์เซอร์ กระบวนการเว็บ ฐานข้อมูล ผู้ดูแล ปลายทางสำรองข้อมูล และการผสานรวมภายนอก ทำเครื่องหมายข้อมูลที่เคลื่อนที่ระหว่างกัน คำขอที่ข้ามจากไคลเอนต์ที่ไม่น่าเชื่อถือเข้าสู่การดำเนินการของเซิร์ฟเวอร์ที่มีสิทธิ์พิเศษสมควรได้รับการตรวจสอบและอนุญาตอย่างชัดเจน
อย่าสมมติว่าการอยู่ในเครื่องเดียวกันทำให้ทุกองค์ประกอบได้รับความเชื่อถือเท่ากัน กระบวนการอัปโหลดสาธารณะไม่ควรมีสิทธิ์เดียวกันกับการดูแลฐานข้อมูล งานสำรองข้อมูลอาจต้องมีการเข้าถึงแบบอ่านโดยไม่สามารถแก้ไขบันทึกของแอปพลิเคชันที่ใช้งานอยู่ การแยกบทบาทเหล่านั้นทำให้ผลกระทบขององค์ประกอบที่ถูกบุกรุกควบคุมได้ง่ายขึ้น และสิทธิ์ที่จำเป็นตรวจสอบได้ง่ายขึ้น
เลือกสถานการณ์ความล้มเหลวที่ konkret
ใช้เหตุการณ์ที่เป็นไปได้เพียงไม่กี่เหตุการณ์เพื่อท้าทายการออกแบบ ผู้โจมตีขโมยรหัสผ่านผู้ดูแล ผู้ใช้ขอข้อมูลของผู้อื่น การอัปโหลดทำให้ดิสก์เต็ม การติดตั้งใช้งานเปิดเผยไฟล์คอนฟิกูเรชัน สำเนากู้คืนไม่สามารถกู้คืนได้ อธิบายสภาพเริ่มต้น องค์ประกอบที่ได้รับผลกระทบ และผลที่ตามมา สถานการณ์เฉพาะเจาะจงทดสอบได้ง่ายกว่าคำแนะนำกว้าง ๆ ให้ปรับปรุงความปลอดภัย
รวมความผิดพลาดและการใช้เวิร์กโฟลว์ที่ชอบด้วยกฎหมายในทางที่ผิด ตลอดจนการบุกรุกจากภายนอก การลองใหม่หนึ่งครั้งอาจสร้างการดำเนินการที่มีค่าได้สองรายการ หรือคำขอสองรายการอาจแข่งขันกันเพื่อเปลี่ยนวัตถุเดียวกัน คำแนะนำด้านตรรกะทางธุรกิจของ OWASP เน้นสมมติฐานของกระบวนการเหล่านี้ ตรวจสอบว่าใครได้รับอนุญาตให้เลื่อนเวิร์กโฟลว์ไปยังสถานะถัดไป และการทำซ้ำหรือจัดลำดับคำขอใหม่เปลี่ยนแปลงผลลัพธ์โดยไม่คาดคิดหรือไม่
| สถานการณ์ | การควบคุมที่ต้องตรวจสอบ | หลักฐานที่ต้องเก็บรวบรวม |
|---|---|---|
| ข้อมูลรับรองผู้ดูแลถูกขโมย | การเข้าถึงแบบจำกัดและปัจจัยที่สองเมื่อได้รับการสนับสนุน | การเข้าสู่ระบบที่ไม่ได้รับอนุญาตไม่สามารถสำเร็จได้ |
| มีการขอวัตถุของผู้อื่น | การอนุญาตวัตถุฝั่งเซิร์ฟเวอร์ | การทดสอบที่แยกออกมาส่งคืนผลลัพธ์แบบปฏิเสธ |
| ดิสก์เต็มจากการอัปโหลด | การควบคุมขนาด โควตา และการเก็บรักษา | มีการบังคับใช้ขีดจำกัดก่อนที่บริการจะล้มเหลว |
| คำขอเวิร์กโฟลว์ซ้ำ | ความเป็น idempotent และขอบเขตธุรกรรม | คำขอที่ทำซ้ำสร้างผลลัพธ์เดียว |
จัดลำดับความสำคัญตามผลกระทบและเส้นทางที่เป็นไปได้จริง
สำหรับแต่ละสถานการณ์ ให้บันทึกผลกระทบที่อาจเกิดขึ้นและเงื่อนไขที่จำเป็นสำหรับการเกิดขึ้น หลีกเลี่ยงการแสร้งว่าคะแนนตัวเลขที่คาดเดาเป็นความน่าจะเป็นที่แม่นยำ คุณยังสามารถแยกแยะรหัสผ่านที่อ่อนแอซึ่งเปิดสู่อินเทอร์เน็ตออกจากเหตุการณ์ภายในที่มีเงื่อนไขสูงได้ มอบหมายเจ้าของและขั้นตอนถัดไปที่ปฏิบัติได้จริงให้กับความเสี่ยงที่สำคัญ เพื่อให้แบบจำลองสร้างงานที่ใครบางคนสามารถทำสำเร็จได้จริง
พิจารณาวงจรชีวิตของข้อมูลตลอดจนการบุกรุกของแอปพลิเคชัน การส่งออกข้อมูลวินิจฉัยอาจเปิดเผยข้อมูลที่ไม่จำเป็นในระหว่างการทำงานปกติ ฟิลด์บัญชีที่เก็บไว้อาจสร้างความเสี่ยงได้นานหลังจากวัตถุประสงค์สิ้นสุดลง การทบทวนความเป็นส่วนตัวจึงสามารถลบข้อมูลหรือลดระยะเวลาการเก็บรักษา ในขณะที่การทบทวนความปลอดภัยจำกัดการเข้าถึงสิ่งที่เหลืออยู่ การเปลี่ยนแปลงทั้งสองอย่างควรอยู่ในแบบจำลองเมื่อสิ่งเหล่านั้นปกป้องโครงการ
ทดสอบการควบคุมในสภาพแวดล้อมที่ได้รับอนุญาต
สร้างสภาพแวดล้อม staging ที่มีสิทธิ์ตัวแทนและบันทึกที่สร้างขึ้น ทดสอบการเข้าถึงที่ถูกปฏิเสธ ขีดจำกัดคำขอ การลองเวิร์กโฟลว์ใหม่ และการกู้คืน อย่าใช้ข้อมูลลูกค้าจริงเมื่อข้อมูลสังเคราะห์สามารถแสดงพฤติกรรมได้ วัตถุประสงค์คือการตรวจสอบการควบคุม ไม่ใช่สร้างทราฟฟิกการโจมตีที่น่าประทับใจ อยู่ในระบบที่คุณเป็นเจ้าของหรือได้รับอนุญาตอย่างชัดเจนให้ประเมิน
บันทึกสิ่งที่ผ่าน สิ่งที่ล้มเหลว และสิ่งที่ยังไม่ทราบ ผลลัพธ์ของสแกนเนอร์สามารถเป็นหลักฐานได้ แต่ไม่แทนที่การทดสอบกฎทางธุรกิจของแอปพลิเคชัน ในทำนองเดียวกัน ตัวเลือกการป้องกันเครือข่ายไม่ได้ตรวจสอบการอนุญาตวัตถุหรือการจัดการไฟล์ลับ แนบผลลัพธ์ที่มีประโยชน์เข้ากับสถานการณ์เพื่อให้ผู้ดูแลในอนาคตเข้าใจว่าทำไมการควบคุมนั้นจึงมีอยู่
ทำให้แบบจำลองเชื่อมโยงกับการเปลี่ยนแปลง
ทบทวนส่วนที่เกี่ยวข้องเมื่อคุณเพิ่มการผสานรวม เปิดเผยปลายทางใหม่ เปลี่ยนสิทธิ์ หรือย้ายข้อมูลไปยังปลายทางอื่น คุณไม่จำเป็นต้องวาดสถาปัตยกรรมทั้งหมดใหม่สำหรับการแก้ไขข้อความเล็กน้อย ตัวกระตุ้นคือการเปลี่ยนแปลงสมมติฐานเกี่ยวกับการเข้าถึง ข้อมูล หรือพฤติกรรมของระบบ เก็บแบบจำลองไว้ข้างเอกสารการติดตั้งใช้งานและการกู้คืน แทนที่จะปล่อยให้เป็นผลลัพธ์ของการประชุมเชิงปฏิบัติการครั้งเดียว
SwissOctet จัดหาแค็ตตาล็อกตัวเลือกโครงสร้างพื้นฐาน ไม่ใช่แบบจำลองภัยคุกคามของแอปพลิเคชันที่เสร็จสมบูรณ์ เลือกคอนฟิกูเรชันและตัวเลือกที่รองรับการควบคุมของคุณ จากนั้นตรวจสอบการติดตั้งใช้งานที่คุณสร้าง แบบจำลองขนาดเล็กที่ได้รับการดูแลพร้อมการดำเนินการที่ทดสอบแล้วมีประโยชน์มากกว่าคอลเลกชันผลิตภัณฑ์ความปลอดภัยขนาดใหญ่ที่ไม่มีคำอธิบายชัดเจนเกี่ยวกับความเสี่ยงที่จัดการ
รายการตรวจสอบปฏิบัติของคุณ
- ระบุสินทรัพย์และผลที่ตามมาของความล้มเหลว
- วาดการไหลของข้อมูลและขอบเขตความเชื่อถือ
- เลือกสถานการณ์การบุกรุก ความผิดพลาด และเวิร์กโฟลว์ที่เฉพาะเจาะจง
- มอบหมายการควบคุมและเจ้าของให้กับความเสี่ยงที่สำคัญ
- ทดสอบด้วยข้อมูลสังเคราะห์ในสภาพแวดล้อมที่ได้รับอนุญาต
- ทบทวนแบบจำลองเมื่อสมมติฐานที่เกี่ยวข้องเปลี่ยนแปลง
รายละเอียดที่สำคัญ
ฉันต้องมีกรอบงานอย่างเป็นทางการเพื่อเริ่มต้นหรือไม่+
ไม่จำเป็น แผนภาพเล็ก ๆ และชุดสถานการณ์ที่จัดทำเอกสารไว้สามารถมีประโยชน์ได้ กรอบงานช่วยให้คุณทบทวนความเสี่ยงอย่างสม่ำเสมอ
สแกนเนอร์ช่องโหว่แทนที่แบบจำลองภัยคุกคามหรือไม่+
ไม่ใช่ สแกนเนอร์อาจพบจุดอ่อนทางเทคนิค ในขณะที่แบบจำลองภัยคุกคามยังตรวจสอบสมมติฐานการออกแบบ สิทธิ์ และเวิร์กโฟลว์ทางธุรกิจด้วย
ฉันควรอัปเดตแบบจำลองบ่อยเพียงใด+
อัปเดตส่วนที่ได้รับผลกระทบเมื่อการไหลของข้อมูล การผสานรวม สิทธิ์ หรือฟังก์ชันที่เปิดเผยเปลี่ยนแปลง และทบทวนความเสี่ยงที่ยังไม่ได้รับการแก้ไขอย่างสม่ำเสมอ
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- OWASP: Cheat Sheet สำหรับการสร้างแบบจำลองภัยคุกคาม cheatsheetseries.owasp.org
- OWASP: การสร้างแบบจำลองภัยคุกคามในทางปฏิบัติ devguide.owasp.org
- OWASP: ความปลอดภัยของตรรกะทางธุรกิจ cheatsheetseries.owasp.org
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก