ในส่วนนี้ เราจะพูดถึงรายละเอียดถึงวิธีการเตรียมองค์กรให้พร้อมเปิดตัวและดำเนินโปรแกรมการเปิดเผยช่องโหว่ให้ประสบความสำเร็จ รวมถึงคำแนะนำเชิงปฏิบัติการเกี่ยวกับวิธีอุดช่องโหว่ที่คุณพบ
การค้นหาข้อบกพร่อง
การเพิ่มโปรแกรมความปลอดภัยที่มีอยู่กับนักวิจัยด้านความปลอดภัยจากภายนอกเป็นวิธีที่ดีในการค้นหาปัญหาที่ซับซ้อนและปิดบังช่องโหว่ แต่การใช้ VDP ในการค้นหาปัญหาด้านความปลอดภัยขั้นพื้นฐานที่สามารถค้นพบได้ภายใน เป็นการสิ้นเปลืองทรัพยากร
การจัดการชิ้นงาน
ในเรื่องการค้นหาข้อบกพร่อง วิธีเดียวที่จะรู้ว่าต้องเริ่มต้นตรงไหนคือเมื่อคุณมีสิ่งที่อยู่ในนั้น คุณสามารถซื้อเครื่องมือรักษาความปลอดภัยเป็นร้อยๆ ได้ แต่คงไม่เกิดผลอะไรใดๆ หากทีมต่างๆ ยืนหยัดแอปพลิเคชัน ระบบ และบริการเฉพาะกิจโดยที่คุณไม่ทราบ โดยเฉพาะอย่างยิ่งเมื่อคุณไม่มีวิธีที่จะค้นพบและดำเนินการประเมินความปลอดภัยของเนื้อหาเหล่านี้ ตรวจสอบกับบุคลากรและทีมงานที่รับผิดชอบในการช่วยสนับสนุนแอปพลิเคชัน ระบบ และบริการใหม่ๆ เพื่อดูว่ามีกระบวนการในการสร้างและดูแลรักษาพื้นที่โฆษณาของสิ่งที่กำลังเกิดขึ้นและใครเป็นเจ้าของบ้าง หากยังไม่มีกระบวนการที่เป็นปัจจุบัน ก็เป็นโอกาสอันดีในการทำงานร่วมกัน กับทีมเหล่านี้เพื่อสร้างกระบวนการ การทำความเข้าใจเนื้อหาขององค์กรคือจุดเริ่มต้นที่ดีที่สุดเมื่อระบุพื้นที่ในการโจมตีของคุณ ในกระบวนการนี้ ทีมความปลอดภัยควรมีส่วนร่วมในการพัฒนาการใช้งานโครงสร้างพื้นฐานใหม่เพื่อให้การตรวจสอบความปลอดภัยได้ แนวทางปฏิบัติที่ดีคือมีคลังเนื้อหาและเจ้าของจำนวนมาก พื้นที่โฆษณาประเภทนี้มีประโยชน์เมื่อใช้แพตช์ใหม่ซึ่งกำหนดให้ระบบบางอย่างหยุดทำงานชั่วคราว โดยจะแสดงแผนงานของบุคคลหรือทีมที่ต้องได้รับทราบข้อมูลและระบบที่ได้รับผลกระทบ การมีกระบวนการจัดการเนื้อหาที่มีประสิทธิภาพจะช่วยให้มั่นใจได้ว่าระบบจะระบุเจ้าของได้ตั้งแต่ช่วงต้นของกระบวนการ มีการอัปเดตอย่างสม่ำเสมอ และระบบทั้งหมดในองค์กรทำงานได้ตามที่ต้องการ
นอกเหนือจากการจัดการชิ้นงานเชิงรุกแล้ว ลองพิจารณามาตรการเชิงรับที่คุณสามารถนำไปใช้และระบุชิ้นงานที่เป็นขององค์กร แต่หลุดรอดพ้นจากช่องโหว่ของกระบวนการจัดการชิ้นงานที่ได้มาตรฐาน ซึ่งอาจรวมถึงการใช้กระบวนการ "สอดแนม" เดียวกันกับที่นักวิจัยด้านความปลอดภัยใช้ ซึ่งจะเข้าร่วม VDP และโปรแกรมเงินรางวัลของข้อบกพร่อง ตัวอย่างเช่น คุณสามารถใช้ประโยชน์จากเครื่องมือโอเพนซอร์สฟรีที่สแกนและแจกแจงช่วง IP หรือโดเมนที่อาจเป็นขององค์กรคุณผ่านอินเทอร์เน็ต การค้นหาข้อบกพร่อง ใน Google Search จะแสดงกลเม็ดเคล็ดลับต่างๆ เพื่อช่วยคุณระบุเนื้อหาจากองค์กรที่คุณไม่เคยรู้มาก่อน
การสแกนช่องโหว่พื้นฐาน
ตอนนี้คุณมีรากฐานที่มั่นคงสำหรับตำแหน่งที่ต้องการพบปัญหาด้านความปลอดภัยแล้ว ต่อไปมาดูวิธีดังกล่าวกัน มีหลายระดับความลึกที่คุณเจาะลึกได้โดยขึ้นอยู่กับทรัพยากรขององค์กร แต่จะต้องหาจุดสมดุลระหว่างความพยายามรักษาความปลอดภัยภายในของคุณกับชุมชนการแฮ็กภายนอกผ่านโปรแกรมการเปิดเผยช่องโหว่ ยอดคงเหลือนี้จะแตกต่างกันไปในแต่ละองค์กร โดยขึ้นอยู่กับทรัพยากรที่มี
เลือกเครื่องมือ
มีเครื่องมือต่างๆ มากมายเพื่อช่วยระบุช่องโหว่ เครื่องมือสแกนช่องโหว่บางอย่างมีให้บริการฟรี แต่บางรายการก็มีค่าใช้จ่าย การพิจารณาว่าควรเลือกเครื่องมือใดนั้นขึ้นอยู่กับความต้องการของแต่ละบุคคล
- ข้อกำหนดขององค์กร
- เครื่องมือแต่ละรายการเป็นไปตามข้อกำหนดเหล่านี้มากน้อยเพียงใด
- เครื่องมือนี้มีน้ำหนักมากกว่าต้นทุน (การเงินและการติดตั้งใช้งาน)
คุณใช้เทมเพลตข้อกำหนดนี้ (OpenDocument .ods, Microsoft Excel .xlsx) เพื่อประเมินเครื่องมือต่างๆ ตามข้อกำหนด ตัวอย่างข้อกำหนดบางส่วนจะรวมอยู่ในเทมเพลต แต่คุณควรปรึกษากับทีมรักษาความปลอดภัย ไอที และทีมวิศวกรรมเพื่อให้สอดคล้องกับความสามารถที่จำเป็น ก่อนเปิดตัวโปรแกรมการเปิดเผยช่องโหว่ อย่างน้อยคุณต้องสามารถทำการสแกนช่องโหว่กับสินทรัพย์ภายนอก (เช่น เว็บไซต์, API, แอปบนอุปกรณ์เคลื่อนที่) ซึ่งจะช่วยให้คุณค้นหาและแก้ไขช่องโหว่ที่ค้นพบได้ง่ายก่อนที่คุณจะเชิญนักวิจัยด้านความปลอดภัยภายนอกให้มาทำการทดสอบกับเนื้อหาและบริการเหล่านี้
การตั้งค่าการสแกน
การสแกนช่องโหว่โดยอัตโนมัติอาจพบปัญหามากมาย แต่ก็อาจทำให้เกิดผลบวกลวงได้ คุณจึงจำเป็นต้องมีทรัพยากรเพื่อตรวจสอบ ผลลัพธ์ก่อนที่จะแชร์กับทีมที่ได้รับผลกระทบ คุณจะต้องใช้ขั้นตอนเพื่อให้แน่ใจว่าการสแกนทำเป็นประจำและผลของการสแกนเหล่านี้ได้รับการแก้ไขแล้วจริงๆ ลักษณะนี้จะต่างกันไปในแต่ละองค์กร แต่อย่างน้อยคุณจะต้องพิจารณาดังนี้
- ความถี่ในการสแกน
- ต่อเนื่อง
- รายสัปดาห์
- รายเดือน
- เนื้อหาที่กำลังสแกน
- ข้อมูลเข้าสู่ระบบ
- การสแกนที่ตรวจสอบสิทธิ์แล้วและไม่ผ่านการตรวจสอบสิทธิ์
- (คำแนะนำ: หากคุณไม่สแกนด้วยข้อมูลเข้าสู่ระบบ นักวิจัยด้านความปลอดภัยก็จะทดสอบด้วยข้อมูลเข้าสู่ระบบเมื่อคุณเริ่ม VDP คุณอาจพบช่องโหว่จำนวนมากที่พบได้)
- บทบาทและความรับผิดชอบ
- ระบุสมาชิกในทีมที่รับผิดชอบการดำเนินการสแกน
- ตั้งค่าการหมุนเวียนหากจำเป็น
- ผลการสแกน
- กำลังตรวจสอบผลการสแกน
- การรายงานข้อบกพร่องสำหรับช่องโหว่ที่ยืนยันแล้ว
- ระบุเจ้าของเพื่อแก้ไขข้อบกพร่อง
- ติดตามผลกับเจ้าของเกี่ยวกับการแก้ไข
เราจะลงลึกถึงรายละเอียดเพิ่มเติมเกี่ยวกับวิธีตรวจสอบว่าปัญหาด้านความปลอดภัยที่ระบุได้รับการแก้ไขแล้วในส่วนการแก้ไขข้อบกพร่องในภายหลังของคู่มือนี้
ขั้นตอนการตรวจสอบความปลอดภัย
แม้ว่าการสแกนช่องโหว่จะเป็นวิธีที่ยอดเยี่ยมในการระบุปัญหาด้านความปลอดภัยในองค์กรในเชิงรับ แต่การใช้กระบวนการตรวจสอบความปลอดภัยจะช่วยป้องกันช่องโหว่ที่อาจเกิดขึ้นตั้งแต่แรกได้ สำหรับจุดประสงค์ของคู่มือนี้ คำว่าการตรวจสอบความปลอดภัยหมายถึงสถานการณ์ที่ทำให้สมาชิกในทีมความปลอดภัยต้องได้รับการตรวจสอบโดยเจ้าหน้าที่ โดยทั่วไปแล้วจะรวมถึงการมีอำนาจในการบล็อกการเปลี่ยนแปลงหากเห็นว่ามีความเสี่ยงเกินไป หากทีมความปลอดภัยของคุณไม่สามารถบล็อกการเปลี่ยนแปลงที่มีความเสี่ยงได้ คุณยังคงต้องมีกระบวนการดำเนินงานเพื่อบันทึกความเสี่ยง วิธีนี้ช่วยให้มั่นใจได้ว่าใครก็ตามที่พุชการเปลี่ยนแปลงจะรู้ถึงความเสี่ยงที่เกี่ยวข้องและยอมรับความเสี่ยงนั้นในเชิงรุก
เกณฑ์การตรวจสอบความปลอดภัย
การตรวจสอบความปลอดภัยควรเกิดขึ้นเมื่อใด การสร้างชุดเกณฑ์ที่จะทริกเกอร์การตรวจสอบความปลอดภัยช่วยให้มั่นใจได้ว่าทุกคนเข้าใจตรงกัน ด้านล่างคือตัวอย่างบางส่วนของสถานการณ์ที่อาจทำให้มีการตรวจสอบความปลอดภัย
- มีการเสนอฟังก์ชันการทำงานใหม่ที่เกี่ยวข้องกับข้อมูลที่ละเอียดอ่อนของผู้ใช้
- ฟีเจอร์ใหม่ที่ให้ผู้ใช้แชร์ตำแหน่งของตนในแผนที่ได้
- การขอข้อมูลที่อาจมีความละเอียดอ่อนจากผู้ใช้ เช่น ที่อยู่บ้าน วันเกิด หรือหมายเลขโทรศัพท์
- มีการอัปเดตสำคัญเกี่ยวกับฟังก์ชันที่มีอยู่
- นำข้อมูลผู้ใช้ที่มีอยู่ไปใช้ในรูปแบบใหม่ที่ผู้ใช้ไม่คาดคิด โดยไม่เปิดโอกาสให้ผู้ใช้ได้เลือกไม่ใช้
- การเปลี่ยนแปลงฟีเจอร์ที่เกี่ยวข้องกับการตรวจสอบสิทธิ์ การให้สิทธิ์ และการจัดการเซสชัน
- การเปลี่ยนแปลงสภาพแวดล้อมการใช้งานของบริษัท
- การเปลี่ยนแปลงการกำหนดค่าเครือข่าย โดยเฉพาะการเปลี่ยนแปลงที่อาจส่งผลให้มีการเปิดเผยบริการภายนอก
- การติดตั้งซอฟต์แวร์ใหม่ที่จัดการข้อมูลที่ละเอียดอ่อนของผู้ใช้ ซึ่งหากถูกบุกรุกอาจนำไปใช้เข้าถึงข้อมูลที่ละเอียดอ่อนของผู้ใช้ในทางอ้อม
- การสร้างระบบหรือบริการใหม่
- การติดต่อกับผู้ให้บริการรายใหม่หรือการเปลี่ยนวิธีที่คุณทำงานร่วมกับผู้ให้บริการที่มีอยู่
- การเริ่มต้นใช้งานผู้ให้บริการรายใหม่ที่จะจัดการข้อมูลที่ละเอียดอ่อนของผู้ใช้
- การเปลี่ยนแปลงวิธีทำงานร่วมกับผู้ให้บริการที่มีอยู่ซึ่งส่งผลให้ผู้ให้บริการจัดการข้อมูลผู้ใช้ที่ละเอียดอ่อน
รายการนี้ไม่ใช่รายการที่ครบถ้วนสมบูรณ์ แต่จะช่วยให้คุณได้ทราบว่าควรมีการเปลี่ยนแปลงประเภทใดที่ต้องผ่านการตรวจสอบความปลอดภัยบ้าง เมื่อคุณกำหนดเกณฑ์ว่าสิ่งใดที่ต้องมีและไม่จำเป็นต้องมีการตรวจสอบความปลอดภัย คุณควรพูดคุยเรื่องนี้กับผู้มีส่วนเกี่ยวข้องหลักทั่วทั้งองค์กรเพื่อให้แน่ใจว่า
- ผู้มีส่วนเกี่ยวข้องมีโอกาสตรวจสอบและให้ ความคิดเห็นเกี่ยวกับเกณฑ์ดังกล่าว
- ผู้มีส่วนเกี่ยวข้องยอมรับเกณฑ์
- ผู้มีส่วนเกี่ยวข้องตกลงที่จะขอรับการตรวจสอบความปลอดภัยในเชิงรุก
จัดทำเกณฑ์นี้ ตลอดจนวิธีขอรับการตรวจสอบความปลอดภัย (เช่น การส่งข้อบกพร่องไปยังคิวให้ทีมความปลอดภัยตรวจสอบ) เพื่อให้องค์กรดำเนินการตามกระบวนการนี้ได้ง่ายขึ้น
การจัดทรัพยากรการตรวจสอบความปลอดภัย
การตรวจสอบความปลอดภัยต่างจากการสแกนอัตโนมัติตรงที่อาจใช้ทรัพยากรมากกว่า ทีมรักษาความปลอดภัยแต่ละทีมมีเวลาเหลือเฟือในแต่ละวันเพียงมากเพื่อทำงานหลายๆ อย่างให้สำเร็จ คุณจึงต้องประเมินจำนวนการตรวจสอบความปลอดภัยที่อาจสร้างขึ้นโดยอิงตามเกณฑ์ของคุณ ถ้าพบว่าทีมของคุณมีความต้องการล้นมือและล้าหลัง ผู้ที่รอการเปิดตัวฟีเจอร์ของตนจะไม่พอใจกับทีมรักษาความปลอดภัย ซึ่งอาจทำให้เกิดการเปลี่ยนแปลงทางวัฒนธรรมในองค์กร ทำให้ทีมรักษาความปลอดภัยถูกมองว่าเป็นตัวบล็อกแทนที่จะเป็นพาร์ทเนอร์ หากกระบวนการตรวจสอบความปลอดภัยไม่มีประสิทธิภาพ บุคลากรและทีมจำนวนมากจะพยายามข้ามขั้นตอนดังกล่าวโดยสิ้นเชิง หากมีทรัพยากรไม่เพียงพอ ให้พิจารณาคลายเกณฑ์ที่จะต้องมีการตรวจสอบความปลอดภัย และยินดียอมรับความเสี่ยงที่เหลือเพิ่มเติม หากเกิดเหตุการณ์ต่างๆ ขึ้นอันเป็นผลจากการไม่มีทรัพยากรสำหรับดำเนินการตรวจสอบความปลอดภัย ก็จะช่วยให้มีความจำเป็นต้องใช้ทรัพยากรด้านความปลอดภัยเพิ่มมากขึ้น
การดำเนินการตรวจสอบการรักษาความปลอดภัย
เมื่อต้องตัดสินใจว่าจะตรวจสอบความปลอดภัยใดและวิธีตรวจสอบ คุณจะต้องมีคิวตามลำดับความสำคัญในการนำข้อมูลมาดำเนินการ สร้างวิธีที่เป็นมาตรฐานสำหรับคนอื่นๆ ในองค์กรในการส่งคำขอรับการตรวจสอบความปลอดภัยด้วยข้อมูลใดก็ตามที่คุณต้องการเพื่อจัดลำดับความสำคัญอย่างเหมาะสม เช่น ลองดูแบบสอบถามที่มีหัวข้อต่างๆ เช่น ลักษณะของการเปลี่ยนแปลง รวมถึงสรุปสั้นๆ เกี่ยวกับการเปลี่ยนแปลงและประเภทของข้อมูลผู้ใช้ที่ได้รับผลกระทบ คุณสามารถจัดหมวดหมู่การตรวจสอบความปลอดภัยที่เป็นไปได้ให้เป็นการเปลี่ยนแปลงที่มีความเสี่ยงสูง ปานกลาง หรือต่ำ โดยอัตโนมัติตามคำตอบของคำถามเหล่านี้ หากการเปลี่ยนแปลงมีความเสี่ยงสูง คุณอาจต้องมีกระบวนการตรวจสอบความปลอดภัยที่ละเอียดยิ่งขึ้น หากการเปลี่ยนแปลงมีความเสี่ยงต่ำ คุณอาจใช้กระบวนการตรวจสอบความปลอดภัยที่ใช้เวลาน้อยลงเพื่อช่วยลดทรัพยากรที่ต้องใช้และเร่งการดำเนินการให้เร็วขึ้น ซึ่งจะช่วยพัฒนาธุรกิจให้ดียิ่งขึ้นได้ พิจารณาตั้งค่าการหมุนเวียนภายในทีมให้รับผิดชอบการจัดการคิวการตรวจสอบความปลอดภัย ตรวจสอบความปลอดภัยใหม่ๆ ให้สมาชิกในทีมเลือก และติดตามความคืบหน้าของการตรวจสอบความปลอดภัยที่มีอยู่ ขั้นตอนจริงของการตรวจสอบความปลอดภัย จะแตกต่างกันขึ้นอยู่กับสิ่งที่ได้รับการตรวจสอบ ตัวอย่างเช่น ฟีเจอร์ใหม่ในแอปบนอุปกรณ์เคลื่อนที่อาจต้องให้วิศวกรความปลอดภัยตรวจสอบโค้ดและมองหาช่องโหว่ที่อาจเกิดขึ้น คุณอาจต้องตรวจสอบซอฟต์แวร์ใหม่ที่จะติดตั้งเพื่อให้แน่ใจว่าได้ตั้งค่าการควบคุมการเข้าถึงไว้อย่างเหมาะสม การทำงานร่วมกับผู้ให้บริการภายนอกอาจนำเสนอกระบวนการที่แตกต่างกันโดยสิ้นเชิง โปรดอ่านในแบบสอบถามการประเมินด้านความปลอดภัยสำหรับผู้ให้บริการของ Google เพื่อเป็นข้อมูลอ้างอิง
การแก้ไขข้อบกพร่อง
การค้นหาข้อบกพร่องนั้นเป็นเรื่องสำคัญ แต่การรักษาความปลอดภัยจะปรับปรุงก็ต่อเมื่อมีการแก้ไขข้อบกพร่องแล้วเท่านั้น การทราบว่าองค์กรของคุณมีความเสี่ยงอะไรบ้างแต่การจัดการกับความเสี่ยงนั้นอย่างมีประสิทธิภาพย่อมดีกว่า
การจัดการช่องโหว่
ช่องโหว่มาจากแหล่งข้อมูลที่หลากหลาย รวมถึงความพยายามภายใน (เช่น การสแกนช่องโหว่และการตรวจสอบความปลอดภัย) การทดสอบและการตรวจสอบการเจาะระบบของบุคคลที่สาม หรือแม้แต่นักวิจัยด้านความปลอดภัยภายนอกที่แจ้งให้คุณทราบผ่านช่องทางการสนับสนุนก่อนเปิดตัว VDP อย่างเป็นทางการ องค์กรของคุณต้องมีวิธีจัดหมวดหมู่ช่องโหว่ใหม่และที่มีอยู่ เพื่อให้แน่ใจว่ามีการสื่อสารไปยังผู้มีส่วนเกี่ยวข้องที่เหมาะสม จัดลำดับความสำคัญอย่างถูกต้อง และแก้ไขอย่างทันท่วงที เมื่อคุณเปิดตัว VDP คุณจะมีช่องโหว่ใหม่ๆ เข้าสู่กระบวนการจัดการช่องโหว่ของคุณ การมีกระบวนการที่มั่นคงในการจัดการกับช่องโหว่เหล่านี้จะช่วยให้คุณติดตามความคืบหน้าในการแก้ไขและตอบสนองต่อคำขอการอัปเดตจากนักวิจัยด้านความปลอดภัยภายนอกได้ การที่สามารถจัดลำดับความสำคัญของช่องโหว่และสื่อสารกับผู้เข้าร่วม VDP เกี่ยวกับลำดับเวลาการแก้ไขจะช่วยเพิ่มการมีส่วนร่วมกับชุมชนนักวิจัยด้านความปลอดภัย รวมถึงช่วยเพิ่มชื่อเสียงด้านความปลอดภัยขององค์กรด้วย ส่วนต่อไปนี้จะอธิบายถึงแง่มุมต่างๆ ของโปรแกรมการจัดการช่องโหว่ที่คุณต้องมีก่อนการเปิดตัว VDP
สร้างมาตรฐานความรุนแรงและลำดับเวลาการแก้ไข
การสร้างภาษาที่ใช้เฉพาะในชุมชนเกี่ยวกับความรุนแรงของช่องโหว่และลำดับเวลาการแก้ไขที่เหมาะสมที่เกี่ยวข้องกับความรุนแรงแต่ละรายการจะช่วยให้คุณกำหนดความคาดหวังมาตรฐานกับองค์กรได้ง่ายขึ้น หากเราปฏิบัติต่อช่องโหว่ต่างๆ เหมือนเป็นเหตุฉุกเฉิน องค์กรของคุณจะใช้ทรัพยากรที่มีอยู่จนหมดและรู้สึกไม่พอใจต่อทีมความปลอดภัย หากทุกช่องโหว่ถือว่ามีลำดับความสำคัญต่ำ จะไม่มีช่องโหว่ได้รับการแก้ไขและความเสี่ยงในการละเมิดจะเพิ่มขึ้น ทุกองค์กรมีทรัพยากรจำกัด คุณจึงต้องกำหนด การจัดอันดับระดับความรุนแรง การจัดอันดับนี้ระบุเกณฑ์ที่ช่วยให้องค์กรเข้าใจความรุนแรงของช่องโหว่และกำหนดเวลาการแก้ไขที่คาดไว้ซึ่งเชื่อมโยงกับความรุนแรงแต่ละอย่าง ร่างชุดหลักเกณฑ์ความรุนแรง และแชร์กับผู้มีส่วนเกี่ยวข้องที่สำคัญในองค์กรเพื่อขอความคิดเห็น ตัวอย่างเช่น หากฝ่ายวิศวกรรมเกี่ยวข้องกับการกำหนดมาตรฐานความรุนแรงของคุณ พวกเขาก็มีแนวโน้มที่จะยอมรับมาตรฐานเหล่านี้มากขึ้นและปฏิบัติตามมาตรฐานดังกล่าวเมื่อถึงเวลาแก้ไขช่องโหว่ภายในกรอบเวลาที่กำหนด หลักเกณฑ์ความรุนแรงอาจแตกต่างกันไปตามความเสี่ยงที่เฉพาะเจาะจงกับธุรกิจของคุณ คุณอาจลองใช้แบบฝึกหัดสร้างแบบจำลองภัยคุกคาม เพื่อให้ทราบว่าภัยคุกคามใดมีแนวโน้มมากที่สุดและจะส่งผลกระทบต่อองค์กรมากที่สุด และใส่ตัวอย่างปัญหาที่จัดอยู่ในความรุนแรงแต่ละหมวดหมู่ ด้านล่างนี้เป็นตัวอย่างมาตรฐานความรุนแรงและลำดับเวลาการแก้ไขสำหรับองค์กรทางการเงิน
| ความรุนแรง | คำอธิบาย | ลำดับเวลาการแก้ไข | ตัวอย่าง |
|---|---|---|---|
| วิกฤต | ปัญหาที่ก่อให้เกิดภัยคุกคามที่จวนจะต่อผู้ใช้หรือธุรกิจของเรา | เจ้าของ: คุณควรระบุเจ้าของหลักที่ตรวจสอบว่าช่องโหว่ได้รับการแก้ไขภายใน 8 ชั่วโมง ทรัพยากรของการโทรและหน้าเว็บตามที่จำเป็น
แม้อยู่นอกเวลาทำการปกติ แก้ไข: ปัญหานี้ควรได้รับการแก้ไขหรืออย่างน้อยควรลดความเสี่ยงอย่างเร็วที่สุด หรือไม่เกิน 3 วันทำการ |
ฐานข้อมูลเวอร์ชันที่ใช้งานจริง รวมถึงบันทึกทางการเงินของผู้ใช้ทั้งหมด ผู้โจมตีที่เข้าถึงความลับทางการค้า เช่น อัลกอริทึมการลงทุนที่เป็นกรรมสิทธิ์ของเรา เหตุการณ์ที่ดำเนินอยู่รวมถึงผู้โจมตีที่เข้าถึงเครือข่ายภายในหรือระบบที่ใช้งานจริงซึ่งมีความละเอียดอ่อน |
| สูง | ปัญหาที่อาจก่อให้เกิดความเสียหายอย่างมาก หากมีการแสวงหาประโยชน์ | เจ้าของ: คุณควรระบุเจ้าของหลักภายใน 1 วันทำการ แก้ไข: ภายใน 10 วันทำการ (ประมาณ 2 สัปดาห์) |
ช่องโหว่ที่อาจทำให้เกิดการเข้าถึงข้อมูลที่ละเอียดอ่อนหรือฟังก์ชันการทำงานของผู้ใช้ (เช่น ความสามารถของผู้ใช้ในการขโมยเงินจากผู้ใช้รายอื่น) |
| สื่อ | ประเด็นที่แสวงหาประโยชน์ได้ยากกว่าหรือไม่ส่งผลให้เกิดความเสียหายโดยตรง | เจ้าของ: คุณควรระบุเจ้าของหลักภายใน 5 วันทำการ แก้ไข: ภายใน 20-40 วันทำการ (ประมาณ 1-2 เดือน) |
ปัญหาที่ได้รับการยืนยันซึ่งตรวจพบโดยโปรแกรมสแกนอัตโนมัติ เช่น แพตช์สำหรับการอัปเดตความปลอดภัยโดยไม่มีการแสวงหาประโยชน์ที่ไม่รู้จัก ปัญหาเกี่ยวกับการเปิดเผยข้อมูลที่อาจช่วยแก้ปัญหาการโจมตีเพิ่มเติมได้ ปัญหาการจำกัดอัตราที่อาจมีการแสวงหาประโยชน์ (เช่น การเดารหัสผ่านของผู้ใช้ได้อย่างต่อเนื่อง) |
| ต่ำ | ปัญหาที่มีผลกระทบน้อยที่สุด ใช้สําหรับการบันทึกปัญหาที่ทราบเป็นหลัก | ไม่มีข้อกำหนดในการค้นหาเจ้าของหรือแก้ไขภายในไทม์ไลน์ที่ระบุ | การเปิดเผยข้อมูลที่ไม่ก่อให้เกิดความเสี่ยง แต่ไม่จำเป็นต้องเข้าถึงข้อมูลนี้จากภายนอก |
การล่อลวงแมลง
ทั้งนี้เราจะไม่กล่าวถึงการตัดผม แต่กำลังพูดถึงการตรวจสอบว่าข้อบกพร่องมีการจัดรูปแบบอย่างถูกต้องเพื่อให้แก้ไขข้อบกพร่องได้โดยง่าย ใช้ตารางก่อนหน้านี้เป็นแนวทางในการตั้งคำจำกัดความระดับความรุนแรงของคุณเอง คำจำกัดความเหล่านี้ใช้เพื่อจำแนกข้อบกพร่องออกเป็นความรุนแรงระดับต่างๆ และสื่อสารกับเจ้าของ
นอกเหนือจากการกำหนดความรุนแรงของช่องโหว่แต่ละรายการแล้ว คุณต้องตรวจสอบว่าข้อบกพร่องอยู่ในรูปแบบมาตรฐานที่ทำให้ทีมต่างๆ ดำเนินการได้ง่ายขึ้น ช่องโหว่จะเข้าสู่กระบวนการจัดการช่องโหว่ในรูปแบบต่างๆ (เช่น ผลลัพธ์ของเครื่องสแกนอัตโนมัติหรือการเขียนข้อมูลด้วยตนเองจากการตรวจสอบความปลอดภัย) การสละเวลามาแปลงช่องโหว่แต่ละรายการให้อยู่ในรูปแบบมาตรฐานจะช่วยเพิ่มโอกาสที่ทีมฝั่งที่รับโอนจะเข้าใจและแก้ไขปัญหาได้อย่างรวดเร็ว
รูปแบบหรือเทมเพลตนี้อาจแตกต่างกันไปตามองค์กรของคุณและข้อมูลที่เกี่ยวข้องที่สุดในการช่วยเจ้าของแก้ไขข้อบกพร่องที่ได้กำหนดไว้ อย่างไรก็ตาม ต่อไปนี้เป็นเทมเพลตตัวอย่างที่คุณสามารถใช้ได้ คุณจะใช้เทมเพลตนี้ซ้ำได้ในภายหลังเมื่อสร้างแบบฟอร์มการส่งข้อมูลของโปรแกรมการเปิดเผยช่องโหว่สำหรับนักวิจัย
ชื่อเรื่อง: <คำอธิบายปัญหา 1 บรรทัด โดยปกติจะเป็นประเภทช่องโหว่ และเนื้อหา/บริการ/อื่นๆ ที่ได้รับผลกระทบ ตัวเลือกระบุความรุนแรง หรือเชื่อมโยงความรุนแรงกับฟิลด์ในเครื่องมือติดตามปัญหาของคุณ สรุป: <คำอธิบายคร่าวๆ ของช่องโหว่ และความสำคัญของปัญหา> ขั้นตอนการทำซ้ำ: <คำแนะนำอย่างเป็นขั้นตอนจะส่งผลกระทบอย่างไร เกี่ยวกับวิธีการแสดงถึงการมีอยู่ของช่องโหว่>ตัวอย่างช่องโหว่ที่มีความรุนแรงสูงที่เป็นไปได้มีดังนี้
Title: [สูง] การอ้างอิงออบเจ็กต์โดยตรงที่ไม่ปลอดภัย (IDOR) ในหน้าโปรไฟล์ สรุป: พบ IDOR ในฟังก์ชันการทำงานของ หน้าโปรไฟล์ของแอปที่ทำให้ผู้ใช้มีสิทธิ์เข้าถึง เพื่อดูและแก้ไขโปรไฟล์ของผู้ใช้รายอื่นโดยไม่ได้รับอนุญาต ซึ่งรวมถึงชื่อและนามสกุล ที่อยู่บ้าน หมายเลขโทรศัพท์ และวันเกิดของผู้ใช้รายอื่น เราได้ตรวจสอบบันทึกและพบว่า ยังไม่มีการแสวงหาประโยชน์จากปัญหานี้ เราตรวจพบปัญหานี้ จากภายใน ขั้นตอนการสร้างข้อผิดพลาดซ้ำ
- ตั้งค่าพร็อกซี เช่น Burp Suite) เพื่อสกัดกั้นการเข้าชมในอุปกรณ์เคลื่อนที่ที่ติดตั้งแอปไว้
- ไปที่หน้าโปรไฟล์ของคุณ และดักจับคำขอ HTTP ที่เชื่อมโยง
- แก้ไข profileID=###### เป็น profileID=000000 (นี่คือผู้ใช้ทดสอบ) แล้วส่งคำขอ HTTP
- แอปจะแสดงโปรไฟล์ของผู้ใช้ 000000 และคุณจะดูและแก้ไขข้อมูลได้
สถานการณ์การโจมตี / ผลกระทบ: ผู้ใช้ทุกคนสามารถใช้ช่องโหว่นี้เพื่อดูและแก้ไขโปรไฟล์ของผู้ใช้รายอื่น ในสถานการณ์ที่เลวร้ายที่สุด ผู้โจมตีอาจทำให้กระบวนการดึงข้อมูลโปรไฟล์ของผู้ใช้ทุกๆ คนอยู่ในระบบของเราเป็นไปโดยอัตโนมัติ แม้ว่าเราจะไม่เชื่อว่ามีการใช้ประโยชน์จากช่องโหว่นี้ แต่สิ่งสำคัญคือเราต้องปฏิบัติกับปัญหานี้เป็นปัญหาระดับความรุนแรงสูงมาตรฐาน หากเราพบหลักฐานการแสวงหาประโยชน์ สิ่งนี้อาจเพิ่มพูนเป็นความรุนแรงร้ายแรง ขั้นตอนการแก้ไข: ใช้การตรวจสอบฝั่งเซิร์ฟเวอร์เพื่อให้แน่ใจว่าผู้ใช้ที่ส่งคำขอควรมีสิทธิ์เข้าถึงเพื่อดู/แก้ไขโปรไฟล์ที่ขอผ่านค่าของ profileID ตัวอย่างเช่น ถ้าอลิซลงชื่อเข้าสู่ระบบและมี profileID 123456 แต่พบว่าอลิซได้ส่งคำขอ profileID 333444 ผู้ใช้ควรจะเห็นข้อผิดพลาดและควรบันทึกการพยายามเข้าถึงโปรไฟล์ของผู้ใช้อีกรายหนึ่งครั้งนี้ ดูข้อมูลเพิ่มเติมเกี่ยวกับ IDOR และวิธีแก้ไขได้ที่เนื้อหาของ OWASP เกี่ยวกับข้อบกพร่องนี้
คุณสามารถประหยัดเวลาและแรงงานได้โดยการหาวิธีที่จะทำให้ช่องโหว่ในการแปลงช่องโหว่จากแหล่งที่มาต่างๆ เป็นรูปแบบมาตรฐานโดยอัตโนมัติ เมื่อสร้างช่องโหว่มากขึ้น คุณอาจพบประเด็นที่พบบ่อยในขั้นตอนการแก้ไข นอกเหนือจากเทมเพลตรูปแบบข้อบกพร่องทั่วไปแล้ว คุณอาจต้องการสร้างเทมเพลตเพิ่มเติมสำหรับประเภทช่องโหว่ทั่วไปด้วย
กำลังค้นหาเจ้าของ
บางทีสิ่งที่ยากที่สุดอย่างหนึ่งในการจัดการช่องโหว่คือการระบุเจ้าของให้ช่วยแก้ไขข้อบกพร่อง รวมถึงเปิดโอกาสให้ผู้ซื้อยอมรับเพื่อทุ่มเททรัพยากรให้กับการแก้ไขข้อบกพร่องได้จริงตามกำหนดเวลา หากคุณตั้งค่าขั้นตอนการจัดการสินทรัพย์ไว้ การดำเนินการดังกล่าวจะง่ายขึ้นเล็กน้อย หากไม่ สิ่งนี้อาจเป็นแรงจูงใจในการทำเช่นนั้น ทั้งนี้ขึ้นอยู่กับขนาดขององค์กร การค้นหาเจ้าของอาจเป็นเรื่องที่ค่อนข้างง่ายหรือ มีความซับซ้อนมาก เมื่อองค์กรเติบโตขึ้น ความพยายามในการระบุว่าใครเป็นผู้รับผิดชอบในการแก้ไขปัญหาด้านความปลอดภัยที่เพิ่งตรวจพบก็เพิ่มมากขึ้นด้วย ลองนำการหมุนในหน้าที่ดำเนินงานไปใช้ ผู้ที่มีหน้าที่รับผิดชอบในการตรวจสอบช่องโหว่ที่ยังไม่มีการมอบหมาย ติดตามเจ้าของ และจัดลำดับความสำคัญตามความรุนแรง แม้ว่าคุณจะสามารถระบุว่าใครเป็นผู้รับผิดชอบในการแก้ไขช่องโหว่และระบุพวกเขาให้กับข้อบกพร่องได้ คุณก็ต้องชักชวนให้พวกเขาใช้เวลาในการแก้ไขจริงๆ ด้วย แนวทางนี้อาจแตกต่างกันไปตามทีมหรือบุคคล ตลอดจนหัวข้ออื่นๆ ที่ทีมกำลังทำอยู่ หากได้รับความเห็นชอบจากองค์กรเกี่ยวกับมาตรฐานความรุนแรงและลำดับเวลาการแก้ไขแล้ว คุณจะอ้างอิงข้อมูลดังกล่าวได้ แต่ในบางครั้งก็อาศัยการโน้มน้าวใจเพิ่มเติมให้ผู้ใช้แก้ไขข้อบกพร่อง เคล็ดลับทั่วไปในการกระตุ้นการแก้ไขช่องโหว่มีดังนี้
- อธิบายสาเหตุ: เมื่อมีการกำหนดช่องโหว่ให้แก้ไข การดำเนินการดังกล่าวมักเป็นการทำงานที่ไม่คาดคิด อธิบายว่าเหตุใดปัญหานี้จึงสำคัญ ที่ต้องแก้ไขอย่างทันท่วงที (เช่น ผลกระทบ / สถานการณ์การโจมตี) และตรวจสอบว่าเจ้าของเข้าใจ
- รวบรวมบริบท: ในบางกรณี อาจมีเพียงบุคคลเดียวที่มีความรู้ที่จำเป็นต่อการแก้ไขข้อบกพร่อง และอาจมีงานอื่นๆ ที่กำลังทำอยู่ ใช้เวลาค้นหาว่างานเหล่านี้คืออะไร เป็นไปได้ว่างานอื่นๆ อาจมีความสำคัญมากกว่าการแก้ไขช่องโหว่นี้ในระยะสั้น การแสดงความเห็นอกเห็นใจและความยืดหยุ่นในกรอบเวลาของการแก้ไขจะช่วยส่งเสริมภาพลักษณ์ที่ดีและสร้างความสัมพันธ์ที่แน่นแฟ้นกับผู้ที่ต้องการแก้ไขช่องโหว่ โปรดระวังอย่าให้ระยะเวลาคล่องตัวมากเกินไป มิฉะนั้นองค์กรของคุณจะไม่คำนึงถึงลำดับเวลาการแก้ไขของคุณอย่างจริงจัง
- อธิบายวิธี: แม้ว่าคุณจะใส่คำแนะนำด้านการแก้ไขไว้ในข้อบกพร่องก็ตาม เจ้าของการแก้ไขปัญหาอาจสับสนหรือต้องการความช่วยเหลือในการเรียนรู้วิธีแก้ไขข้อบกพร่อง หากบุตรหลานต้องการความช่วยเหลือในการหาวิธีแก้ไข ก็ช่วยสอนพวกเขา เพียงโยนข้อบกพร่องไปที่เจ้าของโดยไม่ให้ความช่วยเหลือก็จะส่งผลเสียต่อความสัมพันธ์ขององค์กรกับทีมรักษาความปลอดภัย การช่วยเหลือผู้อื่นมากที่สุดเท่าที่จะเป็นไปได้ จะเป็นพลังให้พวกเขาแก้ไขช่องโหว่ทั้งในปัจจุบันและอนาคต รวมถึงช่วยสอนคนอื่นๆ ด้วย
- ปรับเปลี่ยนคำขอ: ทีมและบุคคลจำนวนมากอาจมีกระบวนการในการยอมรับและจัดลำดับความสำคัญของคำของานที่เข้ามาใหม่อยู่แล้ว บางทีมอาจต้องการให้ คำขอที่เข้ามาทั้งหมดส่งมาถึงผู้จัดการของตน ส่วนผู้ใช้คนอื่นๆ จะต้องการส่งคำขอรับความช่วยเหลือในรูปแบบมาตรฐาน บางรูปแบบจะทำงานเฉพาะกับสิ่งที่กำหนดไว้ล่วงหน้าใน Sprint ไม่ว่าในกรณีใดก็ตาม การสละเวลาเล็กน้อยเพื่อปรับคำขอให้เหมาะกับรูปแบบที่ทีมหรือแต่ละคนมักใช้เพื่อขอรับความช่วยเหลือจะช่วยเพิ่มโอกาสที่คำขอของคุณจะได้รับการดำเนินการและที่สำคัญ
- ส่งต่อเป็นทางเลือกสุดท้าย: หากได้ลองดำเนินการตามทุกวิธีข้างต้นแล้ว และบุคคลหรือทีมที่รับผิดชอบการแก้ไขช่องโหว่จะไม่เสียเวลาแก้ปัญหาด้านความปลอดภัยที่ร้ายแรง โปรดพิจารณาส่งต่อให้กับผู้นำ หากจําเป็น วิธีการนี้ควรเป็นทางเลือกสุดท้ายเสมอ เนื่องจากอาจสร้างความเสียหายต่อความสัมพันธ์กับบุคคลหรือทีมที่เป็นปัญหา
การวิเคราะห์สาเหตุของปัญหา
นอกเหนือจากการค้นหาและแก้ไขช่องโหว่แต่ละอย่างแล้ว การวิเคราะห์สาเหตุที่แท้จริง (RCA) ยังช่วยให้คุณระบุและแก้ไขปัญหาด้านความปลอดภัยที่เป็นระบบได้ด้วย ทุกคนมีทรัพยากรจำกัด จึงขอแนะนำให้ข้ามขั้นตอนนี้ อย่างไรก็ตาม การใช้เวลาเพื่อวิเคราะห์แนวโน้มในข้อมูลช่องโหว่ของคุณ รวมถึงตรวจสอบข้อบกพร่องที่มีความร้ายแรงและร้ายแรงยิ่งขึ้น จะช่วยประหยัดเวลาและลดความเสี่ยงได้ในระยะยาว ตัวอย่างเช่น สมมติว่าคุณสังเกตเห็นช่องโหว่ประเภทเดียวกัน (เช่น การเปลี่ยนเส้นทาง Intent) ปรากฏซ้ำแล้วซ้ำอีกตลอดทั้งแอป คุณจึงตัดสินใจพูดคุยกับทีมที่นำช่องโหว่นี้เข้ามาในแอปและรู้ตัวว่าทีมส่วนใหญ่ยังไม่เข้าใจว่าการเปลี่ยนเส้นทางโดยเจตนาคืออะไร เหตุใดจึงสำคัญ หรือวิธีป้องกัน คุณรวบรวมการพูดคุยและคู่มือที่จะช่วยให้ ความรู้แก่นักพัฒนาซอฟต์แวร์ในองค์กรเกี่ยวกับช่องโหว่นี้ ช่องโหว่นี้อาจยังไม่หายไปโดยสิ้นเชิง แต่อัตราการแสดงก็น่าจะลดลงด้วย เมื่อคุณเริ่มใช้ VDP ทุกๆ ช่องโหว่ที่บุคคลที่สามรายงานให้คุณทราบคือสิ่งที่เล็ดลอดผ่านกระบวนการรักษาความปลอดภัยภายในที่คุณมีอยู่ การดำเนินการ RCA กับข้อบกพร่องจาก VDP จะให้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับวิธีปรับปรุงโปรแกรมความปลอดภัยอย่างเป็นระบบ
การตรวจจับและการตอบสนอง
การตรวจจับและการตอบสนองหมายถึงเครื่องมือและกระบวนการใดๆ ที่คุณมีอยู่เพื่อตรวจหาและตอบสนองต่อการโจมตีที่อาจเกิดขึ้นต่อองค์กร ซึ่งอาจอยู่ในรูปของโซลูชันที่ซื้อมาหรือพัฒนาเอง ซึ่งจะวิเคราะห์ข้อมูลเพื่อระบุพฤติกรรมที่น่าสงสัย ตัวอย่างเช่น ในส่วนข้อบกพร่องสำหรับการล่อลวง เราพูดถึงการบันทึกทุกครั้งที่ผู้ใช้พยายามเข้าถึงโปรไฟล์ของผู้ใช้คนอื่นโดยไม่ได้รับอนุญาต คุณอาจมีสัญญาณหรือการแจ้งเตือนที่สร้างขึ้นหากสังเกตเห็นว่าผู้ใช้พยายามเข้าถึงโปรไฟล์ของผู้ใช้รายอื่นหลายครั้งในระยะเวลาสั้นๆ หรือจะดำเนินการโดยอัตโนมัติเพื่อบล็อกผู้ใช้ดังกล่าวไม่ให้เข้าถึงบริการของคุณในช่วงเวลาหนึ่ง หรือไม่มีกำหนดจนกว่าสถานการณ์จะได้รับการตรวจสอบและคืนการเข้าถึงด้วยตนเอง หากยังไม่มีกลไกในการตรวจจับและการตอบสนอง ให้ลองทำงานร่วมกับที่ปรึกษาผู้เชี่ยวชาญเพื่อช่วยแนะนำวิธีสร้างโปรแกรมนิติเวชและตอบสนองต่อเหตุการณ์ (DFIR) ทางดิจิทัลสำหรับองค์กร หากคุณมีกลไกการตรวจจับและการตอบสนองอยู่แล้ว ก็จะต้องพิจารณาถึงผลของการมีนักวิจัยด้านความปลอดภัย 5, 10 หรือ 100 ที่ทำการทดสอบกับแพลตฟอร์มการโจมตีที่ใช้อินเทอร์เน็ตของคุณ ซึ่งอาจส่งผลกระทบอย่างมากต่อ IDS/IPS (ระบบตรวจจับและป้องกันการบุกรุก) ที่คุณใช้อยู่
ความเสี่ยงที่อาจเกิดขึ้น ได้แก่
- การแจ้งเตือนมากเกินไป: การแจ้งเตือนจำนวนมากหรือสัญญาณที่ดูเหมือนการโจมตีที่เป็นอันตราย แต่อันที่จริงเป็นการทดสอบที่ได้รับอนุมัติจากนักวิจัยด้านความปลอดภัยที่เข้าร่วม VDP ของคุณ มีการสร้างเสียงรบกวนมากมายจนทำให้แยกแยะการโจมตีจริงกับการทดสอบความปลอดภัยที่ถูกต้องตามกฎหมายได้ยาก
- การแจ้งเตือนที่ผิดพลาดของการตอบสนองเมื่อเกิดเหตุการณ์: หากคุณมีกระบวนการต่างๆ ที่กำหนดให้บุคคลของหน้าเว็บในเวลาตีสองครึ่งวันเสาร์ พวกเขาจะไม่ยินดีกับการตื่นขึ้นมาตรวจสอบการละเมิดที่อาจเกิดขึ้นซึ่งจริงๆ แล้วเป็นเพียงแค่นักวิจัยด้านความปลอดภัยที่ทำการทดสอบอย่างถูกต้องตามกฎหมายเท่านั้น
- การบล็อกนักวิจัยด้านความปลอดภัย: หากคุณมี IPS (ระบบป้องกันการบุกรุก) ในเชิงรุก คุณอาจบล็อกที่อยู่ IP ของนักวิจัยด้านความปลอดภัยที่พยายามสแกน ทดสอบด้วยตนเอง ฯลฯ เพื่อระบุช่องโหว่และรายงานให้คุณทราบ โดยเฉพาะอย่างยิ่ง ในกรณีของ VDP หากนักวิจัยด้านความปลอดภัยถูกบล็อกหลังจากการทดสอบ 5 นาที พวกเขาอาจหมดความสนใจและหันไปสนใจโปรแกรมขององค์กรอื่นแทน ซึ่งอาจส่งผลให้นักวิจัยด้านความปลอดภัยโปรแกรมของคุณขาดการมีส่วนร่วมโดยรวม และเพิ่มโอกาสในการเกิดช่องโหว่ที่ยังไม่ถูกค้นพบ (ทำให้องค์กรของคุณไม่ทราบข้อมูล) แม้ว่าคุณอาจไม่อยากลด IPS ของตัวเอง แต่ก็มีมาตรการอื่นๆ ที่ทำได้เพื่อลดความเสี่ยงที่ทำให้นักวิจัยไม่มีส่วนร่วม
วิธีการจัดการกับความเสี่ยงเหล่านี้ส่วนใหญ่จะขึ้นอยู่กับว่าคุณต้องการใช้แนวทางใดในการทำงานร่วมกับนักวิจัยด้านความปลอดภัยภายนอก หากคุณต้องการการทดสอบรูปแบบกล่องดำที่จำลองการโจมตีจริง คุณก็ไม่ต้องทำอะไรเลย ในกรณีนี้ การเข้าชมของนักวิจัยจะสร้างการแจ้งเตือนและทีมของคุณอาจดำเนินการตรวจสอบและตอบสนองตามความเหมาะสม วิธีนี้จะช่วยให้ทีมของคุณสามารถฝึกฝนการตอบสนองต่อสิ่งที่ดูเหมือนเป็นการโจมตีจริง แต่อาจทำให้การมีส่วนร่วมกับนักวิจัยความปลอดภัยลดลง โดยเฉพาะอย่างยิ่งหากทีมถูกบล็อกไม่ให้ทำการทดสอบ นอกจากนี้ ยังอาจทำให้ไม่มีการโจมตีจริงในขณะที่ตรวจสอบการทดสอบที่ถูกต้อง หากต้องการใช้แนวทางแบบกล่องสีเทามากกว่านี้ คุณอาจพิจารณาทำงานร่วมกับนักวิจัยด้านความปลอดภัยเพื่อระบุการเข้าชมทดสอบด้วยตนเองในทางใดทางหนึ่ง ซึ่งจะทำให้คุณเพิ่ม รายการที่อนุญาตพิเศษหรือกรองการรับส่งข้อมูลออกจากการทดสอบและการแจ้งเตือนที่ได้ ทีมของคุณจะแยกแยะระหว่างการโจมตีจริงกับการทดสอบที่ได้รับการรับรองได้ดียิ่งขึ้น และนักวิจัยจะมีความสามารถในการค้นหาและรายงานช่องโหว่ให้คุณทราบโดยไม่ขัดขวางระบบป้องกันการบุกรุกของคุณ บางองค์กรขอให้นักวิจัยด้านความปลอดภัยส่งแบบฟอร์มเพื่อสมัครรับตัวระบุที่ไม่ซ้ำกันซึ่งสามารถแนบไปกับส่วนหัวในคำขอที่นักวิจัยสร้างขึ้นได้ วิธีนี้จะช่วยให้องค์กรกำหนดการเข้าชมที่อนุญาตพิเศษสำหรับผู้วิจัยได้ รวมถึงยังสามารถระบุได้ว่าผู้วิจัยเริ่มทำเกินขอบเขตการทดสอบที่ตกลงกันไว้หรือไม่ หากเกิดกรณีเช่นนี้ คุณสามารถติดต่อผู้วิจัยและขอให้นักวิจัยระงับไว้จนกว่าจะได้วางแผนการทดสอบร่วมกัน