ฉันจะเขียน Risk Finding ที่ธุรกิจจะดำเนินการได้อย่างไร
คู่มือปฏิบัติการสำหรับการแปลงช่องโหว่หรือการค้นหาจากการตรวจสอบให้เป็นข้อความความเสี่ยงที่ผู้บริหารจะให้เงินทุนและแก้ไขจริงๆ
การค้นหาด้านความปลอดภัยส่วนใหญ่ตายไปในสเปรดชีตเพราะเขียนสำหรับผู้คนด้านความปลอดภัยคนอื่นๆ ไม่ใช่สำหรับคนที่อนุมัติงบประมาณ ถ้ารายงานของคุณกล่าวว่า "CVE-2023-XXXX, CVSS 9.8, patch ทันที" คุณได้อธิบายช่องโหว่ ไม่ใช่ความเสี่ยง ธุรกิจไม่ได้ดำเนินการกับช่องโหว่ มันดำเนินการกับผลที่ตามมาที่มันสามารถจินตนาการได้
เหตุใดคะแนนความรุนแรงเพียงอย่างเดียวจึงไม่ขยับใครก็ตาม
CVSS บอกคุณว่าข้อบกพร่องนั้นแย่แค่ไหนแบบแยกตัวตั้ง มันไม่ได้บอกอะไรเลยว่าข้อบกพร่องนั้นสามารถเข้าถึงได้หรือไม่ ว่าทรัพย์สินที่อยู่เบื้องหลังมีความสำคัญต่อรายได้หรือไม่ หรือว่าการควบคุมชดเชยมีอยู่แล้วหรือไม่ 9.8 บนกล่อง dev ภายในที่ไม่มีเส้นทางอินเทอร์เน็ตและไม่มีข้อมูลที่ละเอียดอ่อน ไม่เหมือนกับ 7.5 บนเกตเวย์การชำระเงิน ถ้าคุณจัดอันดับการค้นหาด้วย CVSS เพียงอย่างเดียว คุณจะใช้เชื่อมั่นของคุณไปแก้ไขสิ่งที่ไม่มีใครจะเคยนำมาใช้ประโยชน์ และการค้นหาที่สำคัญจริงๆ หายไปในเสียงรบกวน
ความเสี่ยงที่ได้รับการดำเนินการมีสามส่วนประกอบ เส้นทางที่เป็นไปได้ต่อผลกระทบ ต้นทุนที่เป็นเงินหรือการดำเนินงานที่แนบมากับผลกระทบนั้น และเจ้าของที่สามารถแก้ไขได้จริงๆ หากคุณขาดตัวใดตัวหนึ่ง การค้นหาจะนั่งในระดับคิว
สร้างการค้นหารอบสถานการณ์ ไม่ใช่ผลลัพธ์จากสแกนเนอร์
แทนที่จะเขียน "พบ SQL injection บน /login endpoint" ให้เขียนสถานการณ์ "ผู้โจมตีที่ไม่ได้รับการพิสูจน์สิทธิ์สามารถดึงตารางลูกค้าทั้งหมด รวมถึงรหัสผ่านที่แฮช และที่อยู่การเรียกเก็บเงิน ผ่านแบบฟอร์มการเข้าสู่ระบบ ตารางนี้สนับสนุนบัญชีที่ใช้งานอยู่ 40,000 บัญชี และฐานข้อมูลเดียวกันเก็บประวัติการสั่งซื้อที่เชื่อมโยงกับ PCI scope" ตอนนี้ผู้อ่านไม่ได้แยกวิเคราะห์คลาสช่องโหว่ พวกเขากำลังจินตนาการถึงจดหมายแจ้งเหตุการณ์รั่วไหลและการโทรเรื่องการยืนยันตัวตน
โครงสร้างที่มีประโยชน์สำหรับแต่ละการค้นหา
- สิ่งที่สามารถเกิดขึ้นได้ — เส้นทางการโจมตีในภาษาธรรมชาติ หนึ่งหรือสองประโยค
- สิ่งที่มันสัมผัส — ระบบเฉพาะ ข้อมูลเฉพาะ กระบวนการทางธุรกิจเฉพาะ
- สิ่งที่มันค่อย — ชั่วโมงหยุดทำงาน ความเสี่ยงจากการควบคุม ความเชื่อใจของลูกค้า ค่าปรับตามสัญญา ใช้ตัวเลขจริงเมื่อคุณมี (ค่าปรับ SLA ต้นทุนเหตุการณ์ในอดีต หักประกันภัยไซเบอร์)
- สิ่งที่ต้องใช้ในการแก้ไข — ความพยายาม ไม่ใช่แค่ "patch มัน" บางครั้งการแก้ไขคือกฎ WAF วันนี้และการเปลี่ยนแปลงโค้ดในสปรินต์ถัดไป
- ใครเป็นเจ้าของการแก้ไข — ชื่อหรือทีม ไม่ใช่ "IT"
เชื่อมการค้นหากับบางสิ่งที่ธุรกิจติดตามอยู่แล้ว
บริษัททุกแห่งมีเมตริกที่ผู้นำติดตามแล้ว ความพร้อมใช้งาน SLA อัตราการเลิกใช้ การค้นหาจากการตรวจสอบ SOC 2 ล่าสุด ค่าเบี้ยประกันภัยไซเบอร์ สัญญาลูกค้าเฉพาะที่มีข้อกำหนดความปลอดภัย ถ้าคุณสามารถเชื่อมการค้นหากับสิ่งที่มีอยู่แล้ว — "นี่คือคลาสปัญหาเดียวกันที่บริษัทประกันของเราสังเกตเห็นในการต่ออายุครั้งล่าสุด" หรือ "กระแสข้อมูลนี้อยู่ในขอบเขตสำหรับการตรวจสอบ SOC 2 ในไตรมาสที่ 3" — คุณไม่ได้ขอให้พวกเขาสนใจบางสิ่งใหม่ คุณกำลังแสดงให้พวกเขาเห็นภัยคุกคามต่อบางสิ่งที่พวกเขารับผิดชอบอยู่แล้ว
นี่คือที่ที่การพูดคุยกับด้านธุรกิจจ่ายก่อนที่คุณจะยืนยันรายงาน การสนทนาสิบนาทีกับการเงินหรือการดำเนินงานเกี่ยวกับสิ่งที่หยุดทำงาน 4 ชั่วโมงในระบบเฉพาะค่อยจะเป็นจริงนั้นดีกว่าบรรทัด "ความเสียหายต่อชื่อเสียง" ทั่วไปใดๆ ได้รับตัวเลข อ้างอิงมัน ไปต่อ
จัดอันดับตามความสามารถในการใช้ประโยชน์และรัศมีการระเบิด ไม่ใช่ CVSS เพียงอย่างเดียว
วิธีการสร้างลำดับความสำคัญที่ใช้ได้
- มันสามารถเข้าถึงผ่านอินเทอร์เน็ตหรือจำเป็นต้องเข้าถึงภายในก่อนหรือไม่
- มี exploit สาธารณะหรือเป็นเพียงทางทฤษฎีเท่านั้น
- มันสัมผัสข้อมูลที่ได้รับการควบคุม (PCI PHI PII) หรือระบบสมบัติของกระบวนการหรือไม่
- เวลาและต้นทุนในการแก้ไขที่แท้จริงเทียบกับต้นทุนของการปล่อยไว้เป็นเท่าไหร่
การค้นหาที่ได้คะแนนสูงสำหรับการเข้าถึงได้และรัศมีการระเบิด แต่มีคะแนนปานกลางเพียงอย่างเดียวบน CVSS มักจะสมควรที่จะข้ามคิวแทนบั๊กที่ได้คะแนนวิกฤตที่ฝังไว้สามเส้นทางเครือข่ายลึกเบื้องหลังกล่อง jump พร้อม MFA
เขียนการขอ ไม่ใช่แค่ปัญหา
สิ้นสุดการค้นหาทั้งหมดด้วยคำขอเฉพาะ บรรทัดงบประมาณ หน้าต่างการเปลี่ยนแปลง ข้อยกเว้นนโยบายที่จะปิด หรือการตัดสินใจที่ระบุชื่อที่จำเป็นในวันที่กำหนด "เราแนะนำการแก้ไข" จะถูกละเว้น "เราต้องใช้หน้าต่างบำรุงรักษา 4 ชั่วโมงก่อนวันที่ 15 เพื่อแก้ไขเกตเวย์การชำระเงิน หรือเรายอมรับความเสี่ยงที่เหลือเป็นลายลักษณ์อักษร" บังคับให้มีการตัดสินใจแบบใดแบบหนึ่ง การให้ตัวเลือกการยอมรับความเสี่ยงที่ชัดเจนแก่ผู้บริหาร เป็นลายลักษณ์อักษร พร้อมชื่อของพวกเขา มักเป็นสิ่งที่ทำให้การแก้ไขได้รับการอนุมัติในที่สุดแทนที่จะเป็นอย่างอื่น
ถ้าคุณต้องการเรียนรู้การเปลี่ยนผลลัพธ์การสแกนดิบเป็นการค้นหาแบบนี้ ให้ดำเนินการส่วน Blue Team และ Offensive ของ Korra Studio ร่วมกัน — การจับคู่บริบทการใช้ประโยชน์กับแบบฝึกหัดการรายงานคือที่ที่ทักษะนี้ทำให้คมชัดจริงๆ
เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio
นี่คือบันทึกหนึ่งจากฐานความรู้ของ Korra Studio — แพลตฟอร์มจับคู่หัวข้อแต่ละหัวข้อกับการฝึกสอนแบบ 1-to-1
เริ่มใช้งานฟรีarrow_forward