การเลือกใช้เทคโนโลยีการทดสอบความปลอดภัยของแอปพลิเคชันไม่ใช่เรื่องง่าย โดยสัญชาตญาณคุณจะถามตัวเองว่า“ เทคโนโลยีที่ดีที่สุดคืออะไร” เมื่อคุณพบคำตอบแล้วการเลือกผลิตภัณฑ์ที่คุณชอบที่สุดก็เป็นเรื่องง่าย
ฉันเป็นแฟนตัวยงของสัญชาตญาณ แต่ในกรณีนี้สัญชาตญาณจะทำให้เราเข้าใจผิดหากเราไม่เข้าใจขอบเขตทั้งหมดของการพิจารณาของเรา โดยพื้นฐานแล้วคำถามข้างต้นทำให้เรามีกรอบความคิด“ DAST vs. SAST vs. IAST” ว่าเมื่อใดควรเป็น“ DAST & SAST & IAST” ในโลกของ AppScan เราได้ข้อสรุปเมื่อกว่าทศวรรษที่แล้วในขณะที่เราขยายจาก DAST เป็น SAST และจากนั้นไปสู่ IAST การขยายตัวนี้เกิดจากการตระหนักว่าไม่ใช่แค่การเสนอทางเลือกให้กับลูกค้าของเรามากขึ้นเท่านั้น เป็นเรื่องของการปรับปรุงความครอบคลุมของการสแกนและลดความเสี่ยงใช้การทดสอบความปลอดภัยในหลาย ๆ ที่ในวงจรการใช้งาน DevOps โดยใช้เทคโนโลยีที่เหมาะสมสำหรับงานที่เหมาะสมและนำเสนอเครื่องมือที่เหมาะสมให้กับบุคคลที่เหมาะสม เทคโนโลยีไม่ได้แทนที่ซึ่งกันและกัน แต่เสริมซึ่งกันและกันและอยู่เคียงข้างกัน
ทำไมคุณถึงมองหาเทคโนโลยีเดียว?
เทคโนโลยีมีจุดแข็งและข้อ จำกัด พวกเขามีเป้าหมายให้กับผู้ชมพวกเขาให้ผลลัพธ์ที่แตกต่างกันและเติบโตภายใต้เงื่อนไขที่แตกต่างกัน วงจรชีวิตการพัฒนาและการเผยแพร่มีหลายขั้นตอนและมีผู้เข้าร่วมหลายคนที่มีทักษะและจุดสนใจที่แตกต่างกัน คุณสามารถและควรแนะนำเทคโนโลยีในจุดต่างๆของวงจรชีวิตเพื่อให้ได้การทดสอบความปลอดภัยที่มีประสิทธิภาพสูงสุด
การค้นหาเทคโนโลยีเดียวมักเกิดจากเหตุผลสามประการ:
- ข้อ จำกัด ด้านงบประมาณ: รายจ่ายเป็นปัญหาขององค์กรอยู่เสมอและอาจมีข้อ จำกัด
- โปรไฟล์และการเมือง: ประเภทของคนที่ทำงานในองค์กรที่พวกเขาฟังบล็อกที่พวกเขาอ่านและอื่น ๆ ความเต็มใจของส่วนต่างๆขององค์กรที่จะเข้าร่วมในโครงการรักษาความปลอดภัยและทำให้เกิดการบิดแขน (หรือที่เรียกว่าการเมือง) ล้วนส่งผลต่อการเลือกใช้เทคโนโลยี
- ข้อมูลที่ไม่ถูกต้อง: หรือข้อมูลที่มากเกินไป การรู้มากเกินไปหรือไม่เพียงพออาจทำให้เกิดความสับสนได้
ให้เราถามตัวเองเพิ่มเติมเพื่อพยายามกำหนดกรอบบริบทการใช้งานของแต่ละเทคโนโลยี พวกเขาจะช่วยออกแบบโปรแกรมของคุณ แต่หากการเลือกเทคโนโลยีเดียวยังคงเป็นเป้าหมายของคุณพวกเขาควรช่วยคุณตัดสินใจ
ใครกำลังทำการสแกน?
คำถามนี้ไม่เกี่ยวกับผู้ที่จะกำหนดค่าหรือตั้งค่าการสแกน คำถามยังเกี่ยวกับผู้ที่จะดำเนินการ ไม่ใช่ว่ามีข้อ จำกัด พิเศษ แต่เทคโนโลยีมักมีผู้ใช้บางประเภทอยู่ในใจซึ่งเหมาะกับพวกเขาดีกว่าเทคโนโลยีอื่น ๆ
นักพัฒนา: นักพัฒนาจะได้รับประโยชน์สูงสุดจากการเรียกใช้การสแกน SAST แต่พวกเขาสามารถใช้ประโยชน์จาก IAST ได้เช่นกันโดย DAST อาจจะไม่ค่อยเหมาะ
วิศวกร QA: วิศวกร QA มักจะเป็นผู้ดำเนินการสแกน IAST ที่ดีที่สุดเนื่องจากไม่มีการโต้ตอบพิเศษ การสแกนเกิดขึ้นเมื่อพวกเขากำลังดำเนินการ QA ตามปกติ (การทดสอบด้วยตนเองหรืออัตโนมัติ) พวกเขาไม่น่าจะเรียกใช้การสแกน DAST และโดยปกติจะไม่มีสิทธิ์เข้าถึงสภาพแวดล้อมการพัฒนาสำหรับ SAST
ผู้เชี่ยวชาญด้านความปลอดภัยและผู้ทดสอบ: ผู้เชี่ยวชาญด้านความปลอดภัยและผู้ทดสอบปากกาพบว่า SAST และ DAST เหมาะสม แต่ส่วนใหญ่จะไม่ใช้ IAST
ใครจะเป็นผู้จับผลลัพธ์?
นี่เป็นสิ่งสำคัญเนื่องจากเราต้องการให้ผลลัพธ์ดำเนินการได้มากที่สุด ท้ายที่สุดแล้วการพัฒนาจะได้รับผลการสแกนทั้งหมดและจำเป็นต้องดำเนินการตามนั้น (เช่นแก้ไข) อย่างไรก็ตามอาจมีตัวจับเพิ่มเติม (เช่น Ops หรือ IT) และโปรเซสเซอร์ระดับกลาง ผลลัพธ์ของ SAST และ IAST นั้นนักพัฒนาสามารถใช้งานได้โดยตรงมากที่สุด พวกเขามีข้อมูลที่ตรงที่สุดสำหรับพวกเขา (เช่นตำแหน่งรหัสเฉพาะ) อย่างไรก็ตามนักพัฒนาที่ชอบสถานการณ์การพักผ่อนหย่อนใจมากกว่าตำแหน่งโค้ดอาจได้รับประโยชน์มากขึ้นจาก DAST (เป็นเรื่องของสิ่งที่ผู้ใช้คุ้นเคย) ผลลัพธ์ของ DAST มีความหมายมากกว่าสำหรับผู้เชี่ยวชาญนักทดสอบปากกาหรือ Ops / IT (สำหรับการแก้ไขปัญหาโครงสร้างพื้นฐาน) ในกรณีส่วนใหญ่รหัสจะไม่สามารถเข้าถึงได้หรือไม่เกี่ยวข้องกับรหัสเหล่านี้
คุณวางแผนที่จะทำการสแกนเมื่อใด?
การสแกนอาจใช้เวลานาน การแนะนำงานอื่นในวงจรการพัฒนาของคุณไม่ว่าจะเป็นการตรวจสอบโค้ดการทดสอบหน่วยการทดสอบการทำงานอัตโนมัติหรือสิ่งอื่นใดต้องทำด้วยความระมัดระวัง การทดสอบความปลอดภัยเป็นเพียงหนึ่งในงานเหล่านั้น แต่โดยปกติแล้วจะถูกเพิกเฉย คุณต้องพิจารณาว่าอะไรสำคัญที่สุดสำหรับคุณ
หากการค้นหาปัญหาโดยเร็วที่สุดเป็นสิ่งสำคัญยิ่งการแนะนำการทดสอบความปลอดภัยให้กับนักพัฒนาโดยใช้ SAST เป็นทางเลือกที่ดี นักพัฒนายังพบว่าวิธีการทดสอบ DAST บางวิธีมีประโยชน์มาก
หากวัตถุประสงค์หลักของคุณรบกวนขั้นตอนการทำงานที่มีอยู่เพียงเล็กน้อยและคุณต้องการผลกระทบที่ไม่สามารถสังเกตเห็นได้ IAST อาจเป็นเทคโนโลยีที่คุณเลือกได้ การตั้งค่า IAST เพื่อปรับใช้กับแอปพลิเคชันเป็นการดำเนินการเพียงครั้งเดียวและเมื่อเสร็จแล้วแอปพลิเคชันจะถูกตรวจสอบอยู่เสมอ ทุกครั้งที่มีการโต้ตอบกับแอปพลิเคชัน (การทดสอบการทำงานอัตโนมัติการทดสอบด้วยตนเองหรือการทดสอบการรวมระบบ) แอปพลิเคชันจะได้รับการตรวจสอบปัญหาด้านความปลอดภัย
คุณอาจต้องการสร้างทีมใหม่สำหรับการทดสอบโดยเฉพาะภายนอกทีมที่มีอยู่ของคุณ ในกรณีนี้เทคโนโลยี DAST จะเป็นเครื่องมือที่พวกเขาเลือก DAST ช่วยให้ผู้ทดสอบสามารถแยกรหัสพื้นฐานและการเรียกใช้แอปพลิเคชันได้มากที่สุด
ผลที่คาดว่าจะได้รับจากการสแกนคืออะไร? คุณพยายามทำอะไรให้สำเร็จ?
ฟังดูเหมือนคำถามโง่ ๆ คำตอบของทั้งคู่คือ“ ฉันต้องการให้แอปพลิเคชันของฉันปลอดภัยมากขึ้น!” อย่างไรก็ตามการมองหาการ จำกัด ประเภทของเทคโนโลยีที่คุณใช้นั้นมีจุดมุ่งหมายเพื่อการประหยัดบางประเภท คุณกำลังพยายามประหยัดต้นทุนในแง่การเงินเงื่อนไขเวลาหรือเงื่อนไขอื่น ๆ คุณต้องตอบคำถามเหล่านี้อย่างตรงไปตรงมา
ตัวอย่างเช่นคุณอาจสนใจหรือให้ความสำคัญสูงกว่าในการรักษาความปลอดภัยโค้ดฝั่งเซิร์ฟเวอร์ของคุณและหากคุณต้องการให้นักพัฒนาจัดการปัญหาโดยเร็วที่สุดในวงจรการพัฒนา SAST อาจเป็นการตัดสินใจที่ถูกต้อง
อีกตัวอย่างหนึ่งคือการให้ความสำคัญกับการหลีกเลี่ยงความว้าวุ่นใจของนักพัฒนาซอฟต์แวร์และส่งเสริมให้ประหยัดเวลา IAST เหมาะสมที่จะตอบสนองความสำคัญเหล่านั้น เทคโนโลยีนี้ระบุข้อบกพร่องในขณะที่คุณกำลังทำอย่างอื่น ต้องใช้ความพยายามเพียงเล็กน้อยในการระบุปัญหา แม้ว่าจะ จำกัด เฉพาะโค้ดที่กำลังดำเนินการในระหว่างกิจกรรม “อย่างอื่น” แต่ก็มีราคาถูกมากในเกณฑ์ที่กำหนด
ซ้อนทับและคาดคะเน?
เมื่อคุณอ่านสิ่งนี้คุณอาจเชื่อว่ามีเส้นแบ่งที่ชัดเจนว่าใครควรใช้อะไรและเมื่อใด แน่นอนว่าความจริงนั้นซับซ้อนกว่ามากและสิ่งสำคัญคือการระบุข้อดีและความเหมาะสมของแต่ละเทคโนโลยีและปรับให้เหมาะสมตามแนวเหล่านั้น
มีพารามิเตอร์สี่ตัวที่แสดงถึงบรรทัด ได้แก่ ความแรงในการสแกนข้อ จำกัด ความเสี่ยงและผู้ใช้เป้าหมายที่สันนิษฐาน (สันนิษฐานโดยผู้ขาย)
SAST: SAST ทำงานได้ดีในการระบุช่องโหว่ทางฝั่งเซิร์ฟเวอร์ (ในเว็บแอปพลิเคชันครอบคลุมทุกแง่มุมของแอปพลิเคชันมือถือและเดสก์ท็อป) นอกจากนี้ยังสามารถตรวจพบช่องโหว่ฝั่งไคลเอ็นต์ได้ในบางสถานการณ์ แต่ไม่ถือว่าเหมาะสม ผลลัพธ์ของ SAST อาจต้องใช้การทดลองและล้างข้อมูลจำนวนมาก กระบวนการนี้อาจไม่สำคัญและอาจต้องใช้หลายรอบ แต่ผลลัพธ์ที่เน้นรหัสทำให้เหมาะสำหรับนักพัฒนาและมีประสิทธิภาพมากในการแก้ไขปัญหาอย่างรวดเร็ว
DAST: DAST ทำงานได้ดีมากกับช่องโหว่ฝั่งเซิร์ฟเวอร์เช่นกัน แต่ในสามเทคโนโลยีนี้ทำงานได้ดีที่สุดกับช่องโหว่ฝั่งไคลเอ็นต์ ลักษณะการทำงานของมันยังช่วยให้สามารถตรวจสอบความถูกต้องและลดรายงานเท็จได้มากขึ้น ในขณะที่ตำแหน่งรหัสหายไปส่วนข้อมูลการทดสอบสามารถช่วยในการดีบักซึ่งอาจเป็นทางเลือกที่ใช้งานได้ DAST มีจุดบอดบางประการ: ไม่สามารถระบุปัญหาที่ไม่ก่อให้เกิดผลข้างเคียงที่มองเห็นได้จากภายนอกซึ่ง DAST ต้องอาศัย ความครอบคลุมอาจเป็นปัญหาได้เช่นกันเนื่องจาก DAST อาจพลาดบางส่วนของแอปพลิเคชันที่เข้าถึงได้ยาก ไม่ต้องการให้ผู้ใช้โต้ตอบกับโค้ดหรือแอปพลิเคชันที่ทำงานอยู่ DAST เป็นเครื่องมือที่เหมาะกับผู้ทดสอบปากกาหรือรอบการทดสอบนอกวงมากที่สุด
IAST: จุดแข็งของ IAST ยังอยู่ที่การตรวจจับช่องโหว่ฝั่งเซิร์ฟเวอร์ ในหลาย ๆ รูปแบบจะมีลักษณะร่วมกันกับ SAST โดยมีข้อ จำกัด ที่สำคัญคือคุณภาพของผลลัพธ์ขึ้นอยู่กับคุณภาพของการครอบคลุมฟังก์ชันการทำงานของแอปพลิเคชันโดยตรง ข้อดีอย่างหนึ่งของ SAST คือการนำเสนอข้อมูลคำขอพร้อมกับการแสดงรหัสภายใน สิ่งนี้เปิดใช้ความสามารถในการสร้างซ้ำและการดีบักที่ไม่มี SAST ข้อดีประการที่สองคือการตรวจสอบรันไทม์ของรหัสสุขาภิบาลที่เสนอและรหัสตรวจสอบความถูกต้อง ความน่าเชื่อถือของรหัสสุขาภิบาลและการตรวจสอบความถูกต้องจะดำเนินการตามหลักเหตุผล (เว้นแต่จะใช้ฟังก์ชันไลบรารีที่รู้จักกันดี) หรือโดยการกำหนดค่า ไม่จำเป็นต้องใช้ใน IAST ผู้ใช้ที่ต้องการคือทุกคนที่มีส่วนร่วมในการทดสอบการทำงานในองค์กร สิ่งนี้ช่วยเพิ่มการลงทุนในการทดสอบได้อย่างมากทำให้สามารถทำการทดสอบได้ในระหว่างขั้นตอนการพัฒนาซึ่งก่อนหน้านี้เป็นไปไม่ได้หรือไม่สมเหตุสมผลทางธุรกิจ
แล้วคุณคิดอย่างไรเกี่ยวกับช่องว่างนี้? พวกเขาเป็นสิ่งที่คุณสามารถอยู่ได้หรือไม่?
ที่ HCL AppScan ข้อสรุปก่อนหน้านี้ของเราคือคุณไม่ควรยอมแพ้กับเทคโนโลยีใด ๆ คุณไม่สามารถจ่ายได้
เพื่อเรียนรู้เพิ่มเติม
หากต้องการทดลองใช้เทคโนโลยีการทดสอบความปลอดภัยของแอปพลิเคชันด้วยตัวคุณเองขอทดลองใช้ AppScan ฟรี 30 วันตอนนี้ หรือติดต่อมาทาง KTNBS เพื่อให้เราดูแลคุณเป็นที่ปรึกษาในเรื่องที่คุณสงสัย
ที่มา : https://blog.hcltechsw.com/appscan/ast-the-who-what-why-and-where-of-application-security-testing/
