คำแนะนำสำหรับการทดสอบความปลอดภัย
ใช้กับคำแนะนำรายการตรวจสอบความปลอดภัยที่ได้รับการออกแบบอย่างดีนี้: Power Platform
| SE:09 | จัดทำระบบการทดสอบที่ครอบคลุมซึ่งรวมเอาแนวทางต่างๆ เพื่อป้องกันปัญหาความปลอดภัย ตรวจสอบการดำเนินการป้องกันภัยคุกคาม และทดสอบกลไกการตรวจจับภัยคุกคาม |
|---|
การทดสอบที่เข้มงวดเป็นรากฐานของการออกแบบความปลอดภัยที่ดี การทดสอบเป็นรูปแบบหนึ่งของการตรวจสอบเชิงกลยุทธ์เพื่อให้แน่ใจว่ามาตรการควบคุมทำงานตามที่ตั้งใจไว้ การทดสอบยังเป็นวิธีการเชิงรุกในการตรวจจับช่องโหว่ในระบบอีกด้วย
สร้างความแม่นยำในการทดสอบผ่านลำดับและการตรวจสอบจากหลายมุมมอง คุณควรรวมมุมมองจากภายในสู่ภายนอกที่ทดสอบแพลตฟอร์มและโครงสร้างพื้นฐาน และการประเมินจากภายนอกที่ทดสอบระบบเหมือนกับผู้โจมตีภายนอก
คู่มือนี้มีคำแนะนำสำหรับการทดสอบมาตรการรักษาความปลอดภัยของเวิร์กโหลดของคุณ ใช้วิธีการทดสอบเหล่านี้เพื่อปรับปรุงการต่อต้านการโจมตีเวิร์กโหลดของคุณ และรักษาความลับ ความถูกต้อง และความพร้อมใช้งานของทรัพยากร
คำจำกัดความ
| เงื่อนไข | ข้อกำหนด |
|---|---|
| การทดสอบความปลอดภัยของแอปพลิเคชัน (AST) | เทคนิควงจรชีวิตการพัฒนาความปลอดภัย (SDL) ของ Microsoft ที่ใช้วิธีการทดสอบแบบกล่องขาวและกล่องดำเพื่อตรวจสอบช่องโหว่ด้านความปลอดภัยในโค้ด |
| การทดสอบแบบกล่องดำ | วิธีการทดสอบที่ตรวจสอบพฤติกรรมของแอปพลิเคชันที่มองเห็นได้จากภายนอกโดยไม่ต้องมีความรู้เกี่ยวกับระบบภายใน |
| ทีมสีฟ้า | ทีมที่ป้องกันการโจมตีของทีมสีแดงในการฝึกซ้อมเกมสงคราม |
| การทดสอบการเจาะระบบ | วิธีการทดสอบที่ใช้เทคนิคการเจาะระบบอย่างมีจริยธรรมเพื่อตรวจสอบการป้องกันความปลอดภัยของระบบ |
| ทีมสีแดง | ทีมที่สวมบทบาทเป็นศัตรูและพยายามเจาะระบบในเกมสงคราม |
| วงจรชีวิตการพัฒนาความปลอดภัย (SDL) | ชุดของแนวทางปฏิบัติของ Microsoft ซึ่งสนับสนุนข้อกำหนดด้านการประกันความปลอดภัยและการปฏิบัติตามข้อกำหนด |
| วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) | กระบวนการหลายขั้นตอนที่เป็นระบบสำหรับการพัฒนาระบบซอฟต์แวร์ |
| การทดสอบแบบกล่องขาว | วิธีการทดสอบที่ผู้ประกอบวิชาชีพทราบโครงสร้างของโค้ด |
กลยุทธ์การออกแบบที่สำคัญ
การทดสอบเป็นกลยุทธ์ที่ไม่สามารถต่อรองได้ โดยเฉพาะด้านความปลอดภัย ช่วยให้คุณสามารถค้นพบและแก้ไขปัญหาด้านความปลอดภัยในเชิงรุกก่อนที่จะถูกนำไปใช้ประโยชน์ และเพื่อตรวจสอบว่ามาตรการควบคุมความปลอดภัยที่คุณนำไปใช้นั้นทำงานตามที่ออกแบบไว้หรือไม่
ขอบเขตของการทดสอบต้องรวมถึงแอปพลิเคชัน โครงสร้างพื้นฐาน และกระบวนการอัตโนมัติและมนุษย์
หมายเหตุ
คำแนะนำนี้สร้างความแตกต่างระหว่างการทดสอบและการรับมือภัยคุกคามทางไซเบอร์ แม้ว่าการทดสอบเป็นกลไกการตรวจจับที่แก้ไขปัญหาได้อย่างเหมาะสมก่อนการใช้งานจริง แต่ก็ไม่ควรสับสนกับการแก้ไขหรือการสอบสวนที่ดำเนินการโดยเป็นส่วนหนึ่งของการรับมือภัยคุกคามทางไซเบอร์ ลักษณะของการกู้คืนจากเหตุการณ์ด้านความปลอดภัยมีอธิบายไว้ใน คำแนะนำสำหรับการรับมือภัยคุกคามทางไซเบอร์ด้านความปลอดภัย
มีส่วนร่วมในการวางแผนการทดสอบ ทีมจัดการเวิร์กโหลดอาจไม่ได้ออกแบบกรณีทดสอบ งานนั้นมักจะรวมศูนย์ไว้ในองค์กรหรือดำเนินการโดยผู้เชี่ยวชาญด้านความปลอดภัยภายนอก ทีมจัดการเวิร์กโหลดควรมีส่วนร่วมในกระบวนการออกแบบนั้น เพื่อให้แน่ใจว่าการประกันความปลอดภัยจะรวมเข้ากับฟังก์ชันการทำงานของแอปพลิเคชัน
ขอให้คิดเหมือนผู้โจมตี ออกแบบกรณีทดสอบของคุณโดยสมมติว่าระบบถูกโจมตี ด้วยวิธีนี้ คุณสามารถเปิดเผยช่องโหว่ที่อาจเกิดขึ้นและจัดลำดับความสำคัญของการทดสอบตามนั้น
ดำเนินการทดสอบในลักษณะที่มีโครงสร้างและด้วยกระบวนการที่ทำซ้ำได้ สร้างความแม่นยำในการทดสอบของคุณเกี่ยวกับลำดับ ประเภทของการทดสอบ ปัจจัยขับเคลื่อน และผลลัพธ์ที่ตั้งใจไว้
ใช้เครื่องมือที่เหมาะสมสำหรับงาน ใช้เครื่องมือที่ได้รับการกำหนดค่าให้ทำงานกับเวิร์กโหลด หากคุณไม่มีเครื่องมือ ให้ซื้อเครื่องมือ อย่าสร้างเอง เครื่องมือรักษาความปลอดภัยต้องการความเชี่ยวชาญสูง และการสร้างเครื่องมือของคุณเองอาจทำให้เกิดความเสี่ยงได้ ใช้ประโยชน์จากความเชี่ยวชาญและเครื่องมือที่นำเสนอโดยทีม SecOps ส่วนกลางหรือโดยวิธีการภายนอก หากทีมจัดการเวิร์กโหลดไม่มีความเชี่ยวชาญนั้น
สร้างสภาพแวดล้อมที่แยกต่างหาก การทดสอบสามารถจำแนกเป็นแบบทำลายล้างหรือไม่ทำลายล้าง การทดสอบแบบไม่ทำลายล้างจะไม่รุกราน พวกเขาระบุว่ามีปัญหา แต่ไม่เปลี่ยนแปลงฟังก์ชันการทำงานเพื่อแก้ไขปัญหา การทดสอบแบบทำลายล้างเป็นการรุกรานและอาจสร้างความเสียหายให้กับฟังก์ชันการทำงานโดยการลบข้อมูลออกจากฐานข้อมูล
การทดสอบในสภาพแวดล้อมการทำงานจริงจะให้ข้อมูลที่ดีที่สุดแก่คุณแต่ทำให้เกิดการหยุดชะงักมากที่สุด คุณมักจะทำการทดสอบแบบไม่ทำลายล้างในสภาพแวดล้อมการทำงานจริงเท่านั้น โดยทั่วไป การทดสอบในสภาพแวดล้อมที่ไม่ใช่สภาพแวดล้อมการทำงานจริงจะรบกวนน้อยกว่า แต่อาจไม่ได้แสดงถึงการกำหนดค่าของสภาพแวดล้อมการทำงานจริงอย่างถูกต้องในลักษณะที่มีความสำคัญต่อความปลอดภัย
คุณสามารถสร้างโคลนแบบแยกของสภาพแวดล้อมการทำงานจริงของคุณได้โดยใช้ คุณลักษณะการคัดลอกสภาพแวดล้อม หากคุณตั้งค่าไปป์ไลน์การปรับใช้งานแล้ว คุณสามารถปรับใช้โซลูชันของคุณกับสภาพแวดล้อมการทดสอบเฉพาะได้
ประเมินผลการทดสอบเสมอ การทดสอบถือเป็นความพยายามที่สูญเปล่าหากไม่ได้ใช้ผลลัพธ์เพื่อจัดลำดับความสำคัญของการดำเนินการและปรับปรุงตั้งแต่ต้นทาง จัดทำเอกสารหลักเกณฑ์ด้านความปลอดภัย รวมถึงแนวทางปฏิบัติที่ดีที่สุดที่คุณพบ เอกสารที่รวบรวมผลลัพธ์และแผนการแก้ไขจะให้ความรู้แก่ทีมเกี่ยวกับวิธีต่างๆ ที่ผู้โจมตีอาจพยายามละเมิดความปลอดภัย จัดการฝึกอบรมด้านความปลอดภัยเป็นประจำสำหรับนักพัฒนา ผู้ดูแลระบบ และผู้ทดสอบ
เมื่อคุณออกแบบแผนการทดสอบ ให้คิดถึงคำถามต่อไปนี้:
- คุณคาดหวังว่าการทดสอบจะทำงานบ่อยแค่ไหน และจะส่งผลต่อสภาพแวดล้อมของคุณอย่างไร
- การทดสอบประเภทต่างๆ ที่คุณควรทำมีอะไรบ้าง
คุณคาดหวังว่าการทดสอบจะดำเนินการบ่อยแค่ไหน
ทดสอบเวิร์กโหลดเป็นประจำเพื่อให้แน่ใจว่าการเปลี่ยนแปลงไม่ก่อให้เกิดความเสี่ยงด้านความปลอดภัยและไม่มีการถดถอยใดๆ ทีมต้องพร้อมที่จะตอบสนองต่อการตรวจสอบความปลอดภัยขององค์กรที่อาจดำเนินการได้ตลอดเวลา นอกจากนี้ยังมีการทดสอบที่คุณสามารถดำเนินการเพื่อตอบสนองต่อเหตุการณ์ด้านความปลอดภัยได้ด้วย ส่วนต่อไปนี้ให้คำแนะนำเกี่ยวกับความถี่ของการทดสอบ
การทดสอบตามปกติ
การทดสอบตามปกติจะดำเนินการตามลำดับปกติ โดยเป็นส่วนหนึ่งของขั้นตอนการทำงานมาตรฐานของคุณและเพื่อให้เป็นไปตามข้อกำหนด การทดสอบต่างๆ อาจดำเนินการในลำดับที่แตกต่างกัน แต่สิ่งสำคัญคือการทดสอบเป็นระยะและตามกำหนดเวลา
คุณควรรวมการทดสอบเหล่านี้เข้ากับ SDLC ของคุณ เนื่องจากการทดสอบเหล่านี้ให้การป้องกันเชิงลึกในแต่ละขั้นตอน กระจายชุดการทดสอบเพื่อตรวจสอบการประกันข้อมูลประจำตัว การจัดเก็บและการส่งข้อมูล และช่องทางการสื่อสาร ทำการทดสอบเดียวกันที่จุดต่างๆ ในวงจรเพื่อให้แน่ใจว่าไม่มีการถดถอยใดๆ การทดสอบตามปกติจะช่วยสร้างเกณฑ์มาตรฐานเบื้องต้น อย่างไรก็ตาม นั่นเป็นเพียงจุดเริ่มต้น เมื่อคุณค้นพบปัญหาใหม่ที่จุดเดียวกันของวงจร คุณจะเพิ่มกรณีการทดสอบใหม่ การทดสอบยังปรับปรุงได้ด้วยการทำซ้ำ
ในแต่ละขั้นตอน การทดสอบเหล่านี้ควรตรวจสอบโค้ดที่เพิ่มหรือลบออก หรือการตั้งค่าการกำหนดค่าที่เปลี่ยนแปลง เพื่อตรวจหาผลกระทบด้านความปลอดภัยของการเปลี่ยนแปลงเหล่านั้น คุณควรปรับปรุงประสิทธิภาพของการทดสอบด้วยระบบอัตโนมัติ ซึ่งมีความสมดุลกับการทบทวนจากผู้ทรงคุณวุฒิ
พิจารณาดำเนินการทดสอบความปลอดภัยโดยเป็นส่วนหนึ่งของไปป์ไลน์อัตโนมัติหรือการดำเนินการทดสอบตามกำหนดเวลา ยิ่งคุณค้นพบปัญหาด้านความปลอดภัยได้เร็วเท่าใด ก็จะยิ่งค้นหาโค้ดหรือการเปลี่ยนแปลงการกำหนดค่าที่เป็นสาเหตุของปัญหาได้ง่ายขึ้นเท่านั้น
อย่าพึ่งพาเฉพาะการทดสอบอัตโนมัติเพียงอย่างเดียว ใช้การทดสอบด้วยตนเองเพื่อตรวจจับช่องโหว่ที่มีเพียงผู้เชี่ยวชาญที่เป็นมนุษย์เท่านั้นที่สามารถตรวจจับได้ การทดสอบด้วยตนเองเหมาะสำหรับกรณีการใช้งานเชิงสำรวจและการค้นหาความเสี่ยงที่ไม่ทราบ
การทดสอบแบบกะทันหัน
การทดสอบแบบกะทันหันให้การตรวจสอบการป้องกันความปลอดภัยในเวลานั้น การแจ้งเตือนความปลอดภัยที่อาจส่งผลต่อเวิร์กโหลดในขณะนั้นจะทำให้เกิดการทดสอบเหล่านี้ คำสั่งขององค์กรอาจต้องมีกรอบความคิดแบบหยุดชั่วคราวและทดสอบเพื่อตรวจสอบประสิทธิภาพของกลยุทธ์การป้องกัน หากการแจ้งเตือนยกระดับไปสู่ภาวะฉุกเฉิน
ประโยชน์ของการทดสอบแบบกะทันหันคือการเตรียมพร้อมสำหรับเหตุการณ์จริง การทดสอบเหล่านี้อาจเป็นฟังก์ชันบังคับให้ทำการทดสอบการยอมรับของผู้ใช้ (UAT)
ทีมความปลอดภัยอาจตรวจสอบเวิร์กโหลดทั้งหมดและดำเนินการทดสอบเหล่านี้ตามความจำเป็น ในฐานะเจ้าของเวิร์กโหลด คุณต้องอำนวยความสะดวกและทำงานร่วมกับทีมความปลอดภัย เจรจาต่อรองระยะเวลารอคอยกับทีมความปลอดภัยให้เพียงพอที่ให้คุณสามารถเตรียมตัวได้ รับทราบและสื่อสารกับทีมของคุณและผู้เกี่ยวข้องว่าการหยุดชะงักเหล่านี้มีความจำเป็น
ในกรณีอื่นๆ คุณอาจจำเป็นต้องทำการทดสอบและรายงานสถานะความปลอดภัยของระบบต่อภัยคุกคามที่อาจเกิดขึ้น
การแลกเปลี่ยน: เนื่องจากการทดสอบแบบด้นสดเป็นเหตุการณ์ที่ก่อให้เกิดความวุ่นวาย คุณจึงควรเตรียมกำหนดลำดับความสำคัญของงานใหม่ ซึ่งอาจทำให้การทำงานที่วางแผนไว้อื่นๆ ล่าช้า
ความเสี่ยง: มีความเสี่ยงที่ไม่รู้ การทดสอบแบบกะทันหันอาจเป็นความพยายามเพียงครั้งเดียวโดยไม่มีกระบวนการหรือเครื่องมือที่กำหนดไว้ แต่ความเสี่ยงหลักคือ การหยุดชะงักของจังหวะการดำเนินธุรกิจ คุณต้องประเมินความเสี่ยงเหล่านั้นโดยสัมพันธ์กับประโยชน์ต่างๆ
การทดสอบเหตุการณ์ด้านความปลอดภัย
มีการทดสอบที่ตรวจหาสาเหตุของเหตุการณ์ด้านความปลอดภัยที่แหล่งที่มา ช่องว่างด้านความปลอดภัยเหล่านี้ต้องได้รับการแก้ไขเพื่อให้แน่ใจว่าจะไม่เกิดเหตุการณ์ซ้ำอีก
เหตุการณ์ต่างๆ ยังปรับปรุงกรณีทดสอบเมื่อเวลาผ่านไปด้วยการเปิดเผยช่องว่างที่มีอยู่ ทีมควรใช้บทเรียนที่ได้รับจากเหตุการณ์และนำการปรับปรุงมาใช้เป็นประจำ
การทดสอบประเภทต่างๆ มีอะไรบ้าง
การทดสอบสามารถจัดประเภทตาม เทคโนโลยี และตาม วิธีการทดสอบ รวมประเภทเหล่านั้นและแนวทางต่างๆ ไว้ในประเภทเหล่านั้นเพื่อให้ได้รับความครอบคลุมอย่างสมบูรณ์
ด้วยการเพิ่มการทดสอบที่หลากหลายและการทดสอบประเภทต่างๆ คุณสามารถค้นพบ:
- ช่องว่างในมาตรการควบคุมความปลอดภัยหรือมาตรการควบคุมทดแทน
- การกำหนดค่าที่ผิดพลาด
- ช่องว่างในความสามารถในการสังเกตและวิธีการตรวจจับ
แบบฝึกหัดการสร้างแบบจำลองภัยคุกคามที่ดีสามารถชี้ไปยังประเด็นสำคัญ เพื่อให้แน่ใจถึงความครอบคลุมและความถี่ของการทดสอบ หากต้องการคำแนะนำเกี่ยวกับการสร้างแบบจำลองภัยคุกคาม โปรดดู คำแนะนำสำหรับการรักษาความปลอดภัยวงจรชีวิตการพัฒนา
การทดสอบส่วนใหญ่ที่อธิบายไว้ในส่วนเหล่านี้สามารถใช้เป็นการทดสอบตามปกติได้ อย่างไรก็ตาม ความสามารถในการทำซ้ำอาจทำให้เกิดค่าใช้จ่ายในบางกรณีและทำให้เกิดการหยุดชะงัก พิจารณาข้อดีข้อเสียเหล่านี้อย่างรอบคอบ
การทดสอบที่ตรวจสอบความถูกต้องของกลุ่มเทคโนโลยี
ต่อไปนี้เป็นตัวอย่างประเภทของการทดสอบและจุดที่ต้องให้ความสำคัญ รายการนี้ไม่ได้ครบถ้วนสมบูรณ์ ทดสอบสแตกทั้งหมด รวมถึงสแตกแอปพลิเคชัน ส่วนหน้า แบ็คเอนด์ API ฐานข้อมูล และการผสานรวมภายนอกใดๆ
- ความปลอดภัยของข้อมูล: ทดสอบประสิทธิผลของการเข้ารหัสข้อมูลและการควบคุมการเข้าถึงเพื่อให้แน่ใจว่าข้อมูลได้รับการปกป้องอย่างเหมาะสมจากการเข้าถึงและการดัดแปลงที่ไม่ได้รับอนุญาต
- เครือข่ายและการเชื่อมต่อ: ทดสอบไฟร์วอลล์ของคุณเพื่อให้แน่ใจว่าอนุญาตเฉพาะปริมาณการใช้งานที่คาดหวัง ได้รับอนุญาต และปลอดภัยต่อเวิร์กโหลดเท่านั้น
- แอปพลิเคชัน: ทดสอบโค้ดต้นฉบับด้วยเทคนิคการทดสอบความปลอดภัยของแอปพลิเคชัน (AST) เพื่อให้แน่ใจว่าคุณปฏิบัติตามแนวทางการเขียนโค้ดที่ปลอดภัย และเพื่อตรวจจับข้อผิดพลาดขณะรันไทม์ เช่น หน่วยความจำเสียหาย และปัญหาสิทธิ์พิเศษ
- การระบุตัวตน: ประเมินว่าการมอบหมายบทบาทและการตรวจสอบเงื่อนไขทำงานตามที่ตั้งใจไว้หรือไม่
วิธีการทดสอบ
มีมุมมองมากมายเกี่ยวกับวิธีการทดสอบ เราขอแนะนำการทดสอบที่ช่วยให้สามารถตามล่าภัยคุกคามโดยการจำลองการโจมตีในโลกจริง พวกเขาสามารถระบุผู้ก่อภัยคุกคามที่อาจเกิดขึ้น เทคนิคของพวกเขา และการหาประโยชน์ที่ก่อให้เกิดภัยคุกคามต่อเวิร์กโหลด ทำให้การโจมตีสมจริงที่สุด ใช้แนวทางภัยคุกคามที่เป็นไปได้ทั้งหมดที่คุณระบุระหว่างการสร้างแบบจำลองภัยคุกคาม
นี่คือข้อดีบางประการของการทดสอบผ่านการโจมตีในโลกจริง:
- เมื่อคุณทำให้การโจมตีเหล่านี้เป็นส่วนหนึ่งของการทดสอบตามปกติ คุณจะใช้มุมมองจากภายนอกเพื่อตรวจสอบเวิร์กโหลด และตรวจสอบให้แน่ใจว่าฝ่ายป้องกันสามารถทนต่อการโจมตีได้
- จากบทเรียนที่พวกเขาได้เรียนรู้ ทีมจะยกระดับความรู้และทักษะของพวกเขา ทีมงานปรับปรุงการรับรู้สถานการณ์และสามารถประเมินความพร้อมของตนเองในการตอบสนองต่อเหตุการณ์ต่างๆ
ตัวอย่างของการทดสอบที่จำลอง ได้แก่ การทดสอบแบบกล่องดำและกล่องขาว การทดสอบการเจาะระบบ และแบบฝึกหัดเกมสงคราม
การทดสอบแบบกล่องดำและกล่องขาว
ประเภทการทดสอบเหล่านี้มีมุมมองที่แตกต่างกันสองแบบ ในการทดสอบแบบกล่องดำ ระบบภายในจะไม่สามารถมองเห็นได้ ในการทดสอบแบบกล่องขาว ผู้ทดสอบมีความเข้าใจแอปพลิเคชันเป็นอย่างดี และยังสามารถเข้าถึงโค้ด ไฟล์บันทึก โทโพโลยีทรัพยากร และการกำหนดค่าสำหรับการดำเนินการทดสอบอีกด้วย
การทดสอบที่จำลองการโจมตีผ่านการทดสอบการเจาะระบบ
ผู้เชี่ยวชาญด้านความปลอดภัยที่ไม่ได้เป็นส่วนหนึ่งของทีมไอทีหรือแอปพลิเคชันขององค์กรจะทำการทดสอบการเจาะระบบ หรือ การเจาะระบบทดสอบ พวกเขาพิจารณาระบบในลักษณะที่ผู้ประสงค์ร้ายกำหนดขอบเขตการโจมตี เป้าหมายของพวกเขาคือ การค้นหาช่องว่างด้านความปลอดภัยโดยการรวบรวมข้อมูล วิเคราะห์จุดอ่อน และรายงานผลลัพธ์
ผู้ปฏิบัติงานอาจต้องการเข้าถึงข้อมูลที่ละเอียดอ่อนทั่วทั้งองค์กร ปฏิบัติตามกฎการมีส่วนร่วมเพื่อให้แน่ใจว่าไม่มีการใช้การเข้าถึงในทางที่ผิด ดูทรัพยากรที่ระบุไว้ใน ข้อมูลที่เกี่ยวข้อง
การทดสอบที่จำลองการโจมตีผ่านแบบฝึกหัดเกมสงคราม
ในวิธีการโจมตีที่เป็นแบบจำลองนี้ มีสองทีม:
- ทีม สีแดง เป็นฝ่ายตรงข้ามที่พยายามจำลองการโจมตีในโลกจริง หากพวกเขาทำสำเร็จ คุณจะพบช่องว่างในการออกแบบความปลอดภัยของคุณและประเมินขอบเขตรัศมีการกระจายของการละเมิดความปลอดภัย
- ทีม สีน้ำเงิน คือทีมจัดการเวิร์กโหลดที่ทำหน้าที่ป้องกันการโจมตี พวกเขาทดสอบความสามารถในการตรวจจับ ตอบสนอง และแก้ไขการโจมตี พวกเขาตรวจสอบการป้องกันที่นำไปใช้เพื่อปกป้องทรัพยากรเวิร์กโหลด
หากดำเนินการเป็นการทดสอบตามปกติ แบบฝึกหัดเกมสงครามสามารถให้การมองเห็นอย่างต่อเนื่องและรับประกันว่าการป้องกันของคุณทำงานตามที่ออกแบบไว้ แบบฝึกหัดเกมสงครามสามารถทดสอบข้ามระดับภายในเวิร์กโหลดของคุณได้
ตัวเลือกยอดนิยมในการจำลองสถานการณ์การโจมตีที่สมจริงคือ การฝึกอบรมการจำลองการโจมตี ของ Microsoft Defender สำหรับ Office 365
สำหรับข้อมูลเพิ่มเติม โปรดดู ข้อมูลเชิงลึกและรายงานสำหรับการฝึกอบรมการจำลองการโจมตี
สำหรับข้อมูลเกี่ยวกับการสร้างทีมสีแดงและทีมสีน้ำเงิน โปรดดู Microsoft Cloud Red Teaming
การอำนวยความสะดวกของ Power Platform
โซลูชัน Microsoft Sentinel สำหรับ Microsoft Power Platform ช่วยให้ลูกค้าตรวจพบกิจกรรมที่น่าสงสัยต่างๆ เช่น:
- การดำเนินการ Power Apps จากพื้นที่ที่ไม่ได้รับอนุญาต
- การทำลายข้อมูลที่น่าสงสัยโดย Power Apps
- การลบจำนวนมากของ Power Apps
- การโจมตีแบบฟิชชิ่งเกิดขึ้นผ่าน Power Apps
- กิจกรรมโฟลว์ Power Automate โดยพนักงานที่ลาออก
- Microsoft Power Platform ตัวเชื่อมต่อที่เพิ่มในสภาพแวดล้อม
- อัปเดตหรือลบนโยบายการป้องกันข้อมูลสูญหาย Microsoft Power Platform
สำหรับข้อมูลเพิ่มเติม ดู ภาพรวมโซลูชัน Microsoft Sentinel สำหรับ Microsoft Power Platform
สำหรับคู่มือผลิตภัณฑ์ โปรดดู ความสามารถในการล่าใน Microsoft Sentinel
Microsoft Defender for Cloud มีการสแกนช่องโหว่สำหรับเทคโนโลยีต่างๆ สำหรับข้อมูลเพิ่มเติม โปรดดู เปิดใช้งานการสแกนช่องโหว่ด้วย Microsoft Defender Vulnerability Management
แนวทางปฏิบัติของ DevSecOps ผสมผสานการทดสอบความปลอดภัยเข้าเป็นส่วนหนึ่งของกรอบความคิดในการปรับปรุงอย่างต่อเนื่องและตลอดเวลา แบบฝึกหัดเกมสงครามเป็นแนวทางปฏิบัติทั่วไปที่ผสานเข้ากับจังหวะการดำเนินธุรกิจของ Microsoft สำหรับข้อมูลเพิ่มเติม โปรดดู ความปลอดภัยใน DevOps (DevSecOps)
Azure DevOps รองรับเครื่องมือของบริษัทอื่นที่สามารถทำให้เป็นอัตโนมัติโดยเป็นส่วนหนึ่งของไปป์ไลน์การรวม/การปรับใช้งานต่อเนื่อง (CI/CD) สำหรับข้อมูลเพิ่มเติม โปรดดู เปิดใช้งาน DevSecOps ด้วย Azure และ GitHub
ข้อมูลที่เกี่ยวข้อง
การทดสอบการเจาะระบบล่าสุดและการประเมินความปลอดภัยสามารถดูได้ที่ Microsoft Service Trust Portal
Microsoft ดำเนินการทดสอบบริการต่างๆ ของ Microsoft Cloud อย่างกว้างขวาง การทดสอบนี้รวมถึงการทดสอบการเจาะระบบโดยมีการเผยแพร่ผลลัพธ์บนพอร์ทัลความเชื่อถือการบริการสำหรับองค์กรของคุณ องค์กรของคุณอาจทำการทดสอบการเจาะระบบของคุณเองในบริการต่างๆ ของ Microsoft Power Platform และ Microsoft Dynamics 365 การทดสอบการเจาะระบบทั้งหมดต้องเป็นไปตาม กฎการมีส่วนร่วมในการทดสอบการเจาะระบบของ Microsoft Cloud สิ่งสำคัญคือต้องจำไว้ว่าในหลายกรณี Microsoft Cloud ใช้โครงสร้างพื้นฐานที่ใช้ร่วมกันเพื่อโฮสต์แอสเซทของคุณและแอสเซทที่เป็นของลูกค้ารายอื่น คุณต้องจำกัดการทดสอบการเจาะระบบทั้งหมดให้กับแอสเซทของคุณ และหลีกเลี่ยงผลที่ตามมาโดยไม่ตั้งใจต่อลูกค้ารายอื่นรอบตัวคุณ
ปฏิบัติตามกฎการมีส่วนร่วมเพื่อให้แน่ใจว่าไม่มีการใช้การเข้าถึงในทางที่ผิด สำหรับคำแนะนำในการวางแผนและดำเนินการโจมตีจำลอง โปรดดู:
คุณสามารถจำลองการโจมตีแบบปฏิเสธการบริการ (DoS) ใน Azure อย่าลืมปฏิบัติตามนโยบายที่กำหนดไว้ใน การทดสอบการจำลองของ Azure DDoS Protection
รายการตรวจสอบความปลอดภัย
โปรดดูชุดคำแนะนำทั้งหมด