ในฐานะส่วนหนึ่งของกิจกรรมระดับมืออาชีพ นักพัฒนา ผู้ทดสอบ และผู้เชี่ยวชาญด้านความปลอดภัยต้องจัดการกับกระบวนการต่างๆ เช่น Vulnerability Management (VM), (Secure) SDLC
ข้างใต้วลีเหล่านี้มีชุดวิธีปฏิบัติและเครื่องมือต่างๆ ที่ใช้เชื่อมโยงกัน แม้ว่าผู้ใช้จะต่างกันก็ตาม
ความก้าวหน้าทางเทคนิคยังไม่ถึงจุดที่เครื่องมือหนึ่งสามารถแทนที่บุคคลเพื่อวิเคราะห์ความปลอดภัยของโครงสร้างพื้นฐานและซอฟต์แวร์ได้
เป็นเรื่องที่น่าสนใจที่จะเข้าใจว่าเหตุใดจึงเป็นเช่นนั้นและปัญหาใดที่เราเผชิญ
กระบวนการต่างๆ
กระบวนการจัดการช่องโหว่ได้รับการออกแบบมาเพื่อการตรวจสอบความปลอดภัยของโครงสร้างพื้นฐานและการจัดการแพตช์อย่างต่อเนื่อง
กระบวนการ SDLC ที่ปลอดภัย (“วงจรการพัฒนาที่ปลอดภัย”) ได้รับการออกแบบมาเพื่อรักษาความปลอดภัยของแอปพลิเคชันในระหว่างการพัฒนาและการดำเนินงาน
ส่วนที่คล้ายกันของกระบวนการเหล่านี้คือกระบวนการประเมินช่องโหว่ - การประเมินช่องโหว่ การสแกนช่องโหว่
ข้อแตกต่างที่สำคัญระหว่างการสแกน VM และ SDLC คือในกรณีแรกเป้าหมายคือการตรวจจับช่องโหว่ที่ทราบในซอฟต์แวร์หรือการกำหนดค่าของบุคคลที่สาม ตัวอย่างเช่น Windows เวอร์ชันเก่าหรือสตริงชุมชนเริ่มต้นสำหรับ SNMP
ในกรณีที่สอง เป้าหมายคือการตรวจจับช่องโหว่ไม่เพียงแต่ในส่วนประกอบของบุคคลที่สาม (การขึ้นต่อกัน) แต่ในโค้ดของผลิตภัณฑ์ใหม่เป็นหลัก
สิ่งนี้สร้างความแตกต่างในเครื่องมือและแนวทาง ในความคิดของฉัน งานในการค้นหาช่องโหว่ใหม่ในแอปพลิเคชันนั้นน่าสนใจกว่ามาก เนื่องจากไม่ได้ขึ้นอยู่กับการพิมพ์ลายนิ้วมือ การรวบรวมแบนเนอร์ รหัสผ่านที่บังคับเดรัจฉาน ฯลฯ
สำหรับการสแกนช่องโหว่ของแอปพลิเคชันโดยอัตโนมัติคุณภาพสูง จำเป็นต้องมีอัลกอริธึมที่คำนึงถึงความหมายของแอปพลิเคชัน วัตถุประสงค์ และภัยคุกคามเฉพาะ
เครื่องสแกนโครงสร้างพื้นฐานมักจะถูกแทนที่ด้วยตัวจับเวลาอย่างที่ฉันบอกไว้ . ประเด็นก็คือ ตามสถิติแล้ว คุณสามารถพิจารณาว่าโครงสร้างพื้นฐานของคุณมีช่องโหว่ หากคุณไม่ได้อัปเดตเป็นเวลาหนึ่งเดือน
เครื่องมือ
การสแกน เช่นเดียวกับการวิเคราะห์ความปลอดภัย สามารถทำได้โดยใช้กล่องดำหรือกล่องสีขาว
กล่องดำ
เมื่อสแกนแบล็คบ็อกซ์ เครื่องมือจะต้องสามารถทำงานกับบริการผ่านอินเทอร์เฟซเดียวกันกับที่ผู้ใช้ใช้งาน
เครื่องสแกนโครงสร้างพื้นฐาน (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose ฯลฯ) ค้นหาพอร์ตเครือข่ายแบบเปิด รวบรวม “แบนเนอร์” กำหนดเวอร์ชันของซอฟต์แวร์ที่ติดตั้ง และค้นหาฐานความรู้เพื่อหาข้อมูลเกี่ยวกับช่องโหว่ในเวอร์ชันเหล่านี้ พวกเขายังพยายามตรวจจับข้อผิดพลาดในการกำหนดค่า เช่น รหัสผ่านเริ่มต้นหรือการเข้าถึงข้อมูลแบบเปิด รหัส SSL ที่อ่อนแอ เป็นต้น
เครื่องสแกนแอปพลิเคชันเว็บ (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP ฯลฯ) ยังสามารถระบุส่วนประกอบที่รู้จักและเวอร์ชันของส่วนประกอบเหล่านั้นได้ (เช่น CMS, เฟรมเวิร์ก, ไลบรารี JS) ขั้นตอนหลักของเครื่องสแกนคือการรวบรวมข้อมูลและคลุมเครือ
ในระหว่างการรวบรวมข้อมูล เครื่องสแกนจะรวบรวมข้อมูลเกี่ยวกับอินเทอร์เฟซแอปพลิเคชันและพารามิเตอร์ HTTP ที่มีอยู่ ในระหว่างการคลุมเครือ ข้อมูลที่กลายพันธุ์หรือสร้างขึ้นจะถูกแทรกลงในพารามิเตอร์ที่ตรวจพบทั้งหมดเพื่อกระตุ้นให้เกิดข้อผิดพลาดและตรวจหาช่องโหว่
เครื่องสแกนแอปพลิเคชันดังกล่าวอยู่ในคลาส DAST และ IAST - การทดสอบความปลอดภัยของแอปพลิเคชันแบบไดนามิกและเชิงโต้ตอบตามลำดับ
กล่องสีขาว
การสแกนไวท์บ็อกซ์มีความแตกต่างมากกว่า
ในฐานะที่เป็นส่วนหนึ่งของกระบวนการ VM เครื่องสแกน (Vulners, Incsecurity Couch, Vuls, Tenable Nessus ฯลฯ) มักจะได้รับสิทธิ์ในการเข้าถึงระบบโดยทำการสแกนที่มีการรับรองความถูกต้อง ดังนั้น เครื่องสแกนสามารถดาวน์โหลดเวอร์ชันแพ็คเกจที่ติดตั้งและพารามิเตอร์การกำหนดค่าได้โดยตรงจากระบบ โดยไม่ต้องเดาจากแบนเนอร์บริการเครือข่าย
การสแกนมีความแม่นยำและสมบูรณ์ยิ่งขึ้น
หากเราพูดถึงการสแกนไวท์บ็อกซ์ (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs ฯลฯ ) ของแอปพลิเคชัน เราก็มักจะพูดถึงการวิเคราะห์โค้ดแบบคงที่และการใช้เครื่องมือที่เหมาะสมของคลาส SAST - การทดสอบความปลอดภัยของแอปพลิเคชันแบบคงที่
ปัญหา
การสแกนมีปัญหามากมาย! ฉันต้องจัดการกับพวกเขาส่วนใหญ่เป็นการส่วนตัวโดยเป็นส่วนหนึ่งของการให้บริการสแกนอาคารและกระบวนการพัฒนาที่ปลอดภัย รวมถึงเมื่อดำเนินการวิเคราะห์ความปลอดภัย
ผมจะเน้นกลุ่มปัญหาหลัก 3 กลุ่ม ซึ่งได้รับการยืนยันจากการสนทนากับวิศวกรและหัวหน้าฝ่ายบริการรักษาความปลอดภัยข้อมูลในบริษัทต่างๆ
ปัญหาการสแกนแอปพลิเคชันเว็บ
- ความยากในการดำเนินการ สแกนเนอร์จำเป็นต้องได้รับการปรับใช้ กำหนดค่า ปรับแต่งสำหรับแต่ละแอปพลิเคชัน จัดสรรสภาพแวดล้อมการทดสอบสำหรับการสแกน และนำไปใช้ในกระบวนการ CI/CD เพื่อให้สิ่งนี้มีประสิทธิภาพ มิฉะนั้นจะเป็นขั้นตอนที่เป็นทางการซึ่งไร้ประโยชน์ซึ่งมีแต่ผลบวกลวงเท่านั้น
- ระยะเวลาการสแกน แม้แต่ในปี 2019 เครื่องสแกนก็ทำงานได้ไม่ดีนักในการลดความซ้ำซ้อนของอินเทอร์เฟซ และสามารถใช้เวลาหลายวันในการสแกนหน้าเว็บนับพันหน้าโดยมีพารามิเตอร์ 10 ตัวในแต่ละหน้า โดยพิจารณาว่าต่างกัน แม้ว่าโค้ดเดียวกันจะต้องรับผิดชอบก็ตาม ขณะเดียวกัน การตัดสินใจปรับใช้สู่การผลิตภายในวงจรการพัฒนาจะต้องดำเนินการอย่างรวดเร็ว
- คำแนะนำที่ไม่ดี สแกนเนอร์ให้คำแนะนำที่ค่อนข้างทั่วไป และนักพัฒนาก็ไม่สามารถเข้าใจได้อย่างรวดเร็วเสมอไปว่าจะลดความเสี่ยงอย่างไร และที่สำคัญที่สุดคือ จำเป็นต้องดำเนินการทันทีหรือยังยังไม่น่ากลัว
- ผลกระทบเชิงทำลายต่อแอปพลิเคชัน เครื่องสแกนอาจทำการโจมตี DoS บนแอปพลิเคชันได้ดี และยังสามารถสร้างเอนทิตีจำนวนมากหรือเปลี่ยนแปลงเอนทิตีที่มีอยู่ได้ (เช่น สร้างความคิดเห็นนับหมื่นในบล็อก) ดังนั้นคุณจึงไม่ควรเริ่มการสแกนในการใช้งานจริงโดยไม่ได้ตั้งใจ
- การตรวจจับช่องโหว่คุณภาพต่ำ เครื่องสแกนมักจะใช้เพย์โหลดแบบคงที่และอาจพลาดช่องโหว่ที่ไม่เข้ากับสถานการณ์พฤติกรรมที่ทราบของแอปพลิเคชันได้อย่างง่ายดาย
- เครื่องสแกนไม่เข้าใจฟังก์ชันของแอปพลิเคชัน เครื่องสแกนเองไม่ทราบว่า "บริการธนาคารทางอินเทอร์เน็ต", "การชำระเงิน", "ความคิดเห็น" คืออะไร สำหรับพวกเขา มีเพียงลิงก์และพารามิเตอร์ ดังนั้นชั้นใหญ่ของช่องโหว่ตรรกะทางธุรกิจที่เป็นไปได้ยังคงถูกเปิดเผยโดยสมบูรณ์ พวกเขาจะไม่คิดที่จะตัดค่าใช้จ่ายซ้ำซ้อน การสอดแนมข้อมูลของผู้อื่นด้วย ID หรือเพิ่มความสมดุลผ่านการปัดเศษ
- เครื่องสแกนไม่เข้าใจความหมายของเพจ เครื่องสแกนไม่สามารถอ่านคำถามที่พบบ่อย จำ captcha ไม่ได้ และด้วยตนเอง พวกเขาจะไม่ทราบวิธีลงทะเบียนแล้วเข้าสู่ระบบใหม่ คุณไม่สามารถคลิก "ออกจากระบบ" และวิธีลงนามคำขอเมื่อเปลี่ยนพารามิเตอร์ ค่านิยม ส่งผลให้แอปพลิเคชันส่วนใหญ่ไม่สามารถสแกนได้เลย
ปัญหาในการสแกนซอร์สโค้ด
- ผลบวกลวง การวิเคราะห์แบบคงที่เป็นงานที่ซับซ้อนซึ่งต้องแลกมาด้วยข้อเสียหลายอย่าง ความแม่นยำมักต้องเสียสละ และแม้แต่เครื่องสแกนระดับองค์กรที่มีราคาแพงก็สร้างผลบวกลวงจำนวนมาก
- ความยากในการดำเนินการ เพื่อเพิ่มความแม่นยำและความสมบูรณ์ของการวิเคราะห์แบบคงที่ จำเป็นต้องปรับแต่งกฎการสแกน และการเขียนกฎเหล่านี้อาจใช้แรงงานมากเกินไป บางครั้งการค้นหาตำแหน่งทั้งหมดในโค้ดที่มีข้อบกพร่องบางอย่างและแก้ไขนั้นง่ายกว่าการเขียนกฎเพื่อตรวจจับกรณีดังกล่าว
- ขาดการสนับสนุนการพึ่งพา โปรเจ็กต์ขนาดใหญ่ขึ้นอยู่กับไลบรารีและเฟรมเวิร์กจำนวนมากที่ขยายขีดความสามารถของภาษาการเขียนโปรแกรม หากฐานความรู้ของเครื่องสแกนไม่มีข้อมูลเกี่ยวกับ "อ่างล้างจาน" ในเฟรมเวิร์กเหล่านี้ ก็จะกลายเป็นจุดบอด และเครื่องสแกนก็จะไม่เข้าใจโค้ดด้วยซ้ำ
- ระยะเวลาการสแกน การค้นหาช่องโหว่ในโค้ดถือเป็นงานที่ซับซ้อนในแง่ของอัลกอริธึม ดังนั้นกระบวนการนี้อาจใช้เวลานานและต้องใช้ทรัพยากรการคำนวณจำนวนมาก
- ความคุ้มครองต่ำ แม้จะมีการใช้ทรัพยากรและเวลาในการสแกน แต่นักพัฒนาเครื่องมือ SAST ยังคงต้องประนีประนอมและวิเคราะห์ไม่ใช่ทุกสถานะที่โปรแกรมอาจอยู่ใน
- การทำซ้ำของการค้นพบ การชี้ไปที่บรรทัดเฉพาะและ Call Stack ที่นำไปสู่ช่องโหว่นั้นเป็นเรื่องที่ดี แต่ในความเป็นจริงแล้ว เครื่องสแกนมักจะไม่ได้ให้ข้อมูลเพียงพอที่จะตรวจสอบการมีอยู่ของช่องโหว่จากภายนอก ท้ายที่สุดแล้ว ข้อบกพร่องอาจอยู่ในโค้ดที่ไม่ทำงาน ซึ่งผู้โจมตีไม่สามารถเข้าถึงได้
ปัญหาการสแกนโครงสร้างพื้นฐาน
- สินค้าคงคลังไม่เพียงพอ ในโครงสร้างพื้นฐานขนาดใหญ่ โดยเฉพาะอย่างยิ่งที่แยกออกจากกันทางภูมิศาสตร์ มักจะเป็นเรื่องยากที่สุดที่จะทราบว่าโฮสต์ใดที่จะสแกน กล่าวอีกนัยหนึ่ง งานสแกนมีความเกี่ยวข้องอย่างใกล้ชิดกับงานการจัดการสินทรัพย์
- การจัดลำดับความสำคัญไม่ดี เครื่องสแกนเครือข่ายมักจะให้ผลลัพธ์มากมายโดยมีข้อบกพร่องซึ่งไม่สามารถนำมาใช้ในทางปฏิบัติได้ แต่อย่างเป็นทางการแล้วระดับความเสี่ยงนั้นสูง ผู้บริโภคได้รับรายงานที่ตีความได้ยาก และไม่มีความชัดเจนว่าต้องแก้ไขอะไรก่อน
- คำแนะนำที่ไม่ดี ฐานความรู้ของเครื่องสแกนมักมีเพียงข้อมูลทั่วไปเกี่ยวกับช่องโหว่และวิธีแก้ไข ดังนั้นผู้ดูแลระบบจะต้องเตรียมรับมือกับ Google สถานการณ์จะดีขึ้นเล็กน้อยเมื่อใช้เครื่องสแกนไวท์บ็อกซ์ ซึ่งสามารถออกคำสั่งเฉพาะเพื่อแก้ไขได้
- ทำด้วยมือ โครงสร้างพื้นฐานอาจมีหลายโหนด ซึ่งหมายถึงอาจมีข้อบกพร่องมากมาย รายงานที่ต้องแยกวิเคราะห์และวิเคราะห์ด้วยตนเองในแต่ละรอบซ้ำ
- ความคุ้มครองไม่ดี คุณภาพของการสแกนโครงสร้างพื้นฐานโดยตรงขึ้นอยู่กับขนาดของฐานความรู้เกี่ยวกับช่องโหว่และเวอร์ชันของซอฟต์แวร์ โดยที่ แม้แต่ผู้นำตลาดก็ยังไม่มีฐานความรู้ที่ครอบคลุมและฐานข้อมูลโซลูชั่นฟรีก็มีข้อมูลมากมายที่ผู้นำไม่มี
- ปัญหาเกี่ยวกับการแพตช์ บ่อยครั้งที่การแก้ไขช่องโหว่ของโครงสร้างพื้นฐานเกี่ยวข้องกับการอัพเดตแพ็คเกจหรือการเปลี่ยนแปลงไฟล์การกำหนดค่า ปัญหาใหญ่ที่นี่คือระบบ โดยเฉพาะระบบเดิม สามารถทำงานได้อย่างคาดเดาไม่ได้อันเป็นผลมาจากการอัปเดต โดยพื้นฐานแล้ว คุณจะต้องดำเนินการทดสอบการบูรณาการกับโครงสร้างพื้นฐานที่ใช้งานจริงในการผลิต
แนวทาง
เป็นอย่างไร
ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับตัวอย่างและวิธีจัดการกับปัญหาต่างๆ ที่ระบุไว้ในส่วนต่อไปนี้ แต่สำหรับตอนนี้ ฉันจะระบุทิศทางหลักที่คุณสามารถทำงานได้:
- การรวมเครื่องมือสแกนต่างๆ ด้วยการใช้เครื่องสแกนหลายเครื่องอย่างถูกต้อง คุณจะสามารถเพิ่มฐานความรู้และคุณภาพของการตรวจจับได้เพิ่มขึ้นอย่างมาก คุณจะพบช่องโหว่มากกว่าสแกนเนอร์ทั้งหมดที่เปิดตัวแยกกันทั้งหมด ในขณะที่คุณสามารถประเมินระดับความเสี่ยงได้แม่นยำยิ่งขึ้นและให้คำแนะนำเพิ่มเติม
- การบูรณาการ SAST และ DAST มีความเป็นไปได้ที่จะเพิ่มความครอบคลุมของ DAST และความแม่นยำของ SAST ได้โดยการแลกเปลี่ยนข้อมูลระหว่างกัน จากแหล่งที่มา คุณสามารถรับข้อมูลเกี่ยวกับเส้นทางที่มีอยู่ และการใช้ DAST คุณสามารถตรวจสอบได้ว่าช่องโหว่นั้นมองเห็นได้จากภายนอกหรือไม่
- การเรียนรู้ของเครื่อง™ ในปี 2015 ฉัน (และ ) เกี่ยวกับการใช้สถิติเพื่อให้เครื่องสแกนมีสัญชาตญาณของแฮ็กเกอร์และเร่งความเร็ว นี่เป็นปัจจัยสำคัญสำหรับการพัฒนาการวิเคราะห์ความปลอดภัยแบบอัตโนมัติในอนาคตอย่างแน่นอน
- การรวม IAST เข้ากับการทดสอบอัตโนมัติและ OpenAPI ภายในไปป์ไลน์ CI/CD คุณสามารถสร้างกระบวนการสแกนโดยใช้เครื่องมือที่ทำงานเป็นพร็อกซี HTTP และการทดสอบการทำงานที่ทำงานบน HTTP ได้ การทดสอบและสัญญาของ OpenAPI/Swagger จะทำให้เครื่องสแกนมีข้อมูลที่ขาดหายไปเกี่ยวกับกระแสข้อมูล และทำให้สามารถสแกนแอปพลิเคชันในสถานะต่างๆ ได้
- การกำหนดค่าที่ถูกต้อง สำหรับแต่ละแอปพลิเคชันและโครงสร้างพื้นฐาน คุณต้องสร้างโปรไฟล์การสแกนที่เหมาะสม โดยคำนึงถึงจำนวนและลักษณะของอินเทอร์เฟซและเทคโนโลยีที่ใช้
- การปรับแต่งสแกนเนอร์ บ่อยครั้งที่ไม่สามารถสแกนแอปพลิเคชันได้โดยไม่ต้องดัดแปลงสแกนเนอร์ ตัวอย่างคือเกตเวย์การชำระเงินซึ่งแต่ละคำขอจะต้องลงนาม โดยไม่ต้องเขียนตัวเชื่อมต่อไปยังโปรโตคอลเกตเวย์ เครื่องสแกนจะโจมตีคำขอด้วยลายเซ็นที่ไม่ถูกต้องอย่างไร้เหตุผล นอกจากนี้ยังจำเป็นต้องเขียนเครื่องสแกนเฉพาะสำหรับข้อบกพร่องเฉพาะประเภท เช่น
- การจัดการความเสี่ยง การใช้เครื่องสแกนต่างๆ และการบูรณาการกับระบบภายนอก เช่น การจัดการสินทรัพย์ และการจัดการภัยคุกคาม จะทำให้สามารถใช้พารามิเตอร์ต่างๆ เพื่อประเมินระดับความเสี่ยง เพื่อให้ฝ่ายบริหารได้เห็นภาพสถานะความปลอดภัยปัจจุบันของการพัฒนาหรือโครงสร้างพื้นฐานที่เพียงพอ
คอยติดตามและมาขัดขวางการสแกนช่องโหว่!
ที่มา: will.com