เจฟฟ์ วิลเลียมส์ ผู้ก่อตั้ง OWASP และผู้ก่อตั้ง & CTO ของ Contrast Security – สัมภาษณ์รายการ

เจฟฟ์ วิลเลียมส์ ผู้ก่อตั้ง OWASP และผู้ก่อตั้ง & CTO ของ Contrast Security ถือเป็นหนึ่งในบุคคลที่มีอิทธิพลที่สุดในด้านความปลอดภัยของแอปพลิเคชันสมัยใหม่ ในช่วงหลายทศวรรษที่ผ่านมา เขาได้ช่วยกำหนดวิธีการที่องค์กรต่างๆ เข้าใกล้ในการพัฒนาซอฟต์แวร์ที่มีความปลอดภัย การจัดการความเสี่ยง และการป้องกันแอปพลิเคชันในขณะทำงาน วิลเลียมส์เล่นบทบาทสำคัญในการสร้าง OWASP จากการเริ่มต้นเป็นโครงการอาสาสมัครขนาดเล็กให้กลายเป็นองค์กรพัฒนาไม่แสวงหาผลกำไรที่ได้รับการยอมรับในระดับโลก โดยมีส่วนร่วมในโครงการสำคัญๆ เช่น OWASP Top Ten, WebGoat, ESAPI, ASVS และ XSS Prevention Cheat Sheet ก่อนที่จะก่อตั้ง Contrast Security ในปี 2014 เขายังเป็นผู้ก่อตั้ง Aspect Security ซึ่งเป็นหนึ่งในบริษัทแรกๆ ที่อุทิศตนให้กับการให้คำปรึกษาด้านความปลอดภัยของแอปพลิเคชัน การฝึกอบรม การทดสอบการเจาะระบบ และการฝึกอบรมการพัฒนาที่ปลอดภัยสำหรับองค์กรขนาดใหญ่

OWASP เป็นองค์กรพัฒนาไม่แสวงหาผลกำไรที่มุ่งเน้นในการปรับปรุงความปลอดภัยของซอฟต์แวร์ผ่านโครงการโอเพ่นซอร์ส การทำงานร่วมกันของชุมชนระดับโลก การศึกษา และมาตรฐานอุตสาหกรรม องค์กรนี้ก่อตั้งขึ้นในปี 2001 และได้กลายเป็นหนึ่งในองค์กรที่มีอิทธิพลที่สุดในด้านความปลอดภัยของแอปพลิเคชัน โดยมีห้องประชุมท้องถิ่นหลายร้อยแห่ง ผู้ร่วมให้ข้อมูลหลายพันคน และทรัพยากรที่ได้รับการยอมรับอย่างกว้างขวางซึ่งใช้โดยนักพัฒนา ผู้เชี่ยวชาญด้านความปลอดภัย องค์กร และรัฐบาลทั่วโลก OWASP เป็นที่รู้จักจากโครงการต่างๆ เช่น OWASP Top Ten ซึ่งระบุความเสี่ยงด้านความปลอดภัยของแอปพลิเคชันเว็บที่สำคัญที่สุด พร้อมด้วยเฟรมเวิร์กด้านความปลอดภัยหลายโครงการ เครื่องมือทดสอบ ตัวบ่งชี้โครงการ และโครงการฝึกอบรม องค์กรนี้ดำเนินงานตามหลักการเป็นกลางต่อผู้ขาย ทำให้ทรัพยากรทางการศึกษาและคำแนะนำด้านความปลอดภัยสามารถเข้าถึงได้ฟรีสำหรับชุมชนเทคโนโลยีระดับโลก

Contrast Security เป็นบริษัทด้านความปลอดภัยของแอปพลิเคชันที่มุ่งเน้นในการปกป้องซอฟต์แวร์จากภายในแอปพลิเคชันที่ทำงานจริง แทนที่จะพึ่งพาเครื่องมือสแกนภายนอกเพียงอย่างเดียว แพลตฟอร์มของบริษัทใช้เทคโนโลยีการติดเครื่องมือในขณะทำงานเพื่อให้สามารถมองเห็นความเสี่ยง ความเสียหาย API ส่วนประกอบของโอเพ่นซอร์ส และพฤติกรรมของแอปพลิเคชันในเวลาเดียวกัน โดยครอบคลุมพื้นที่ต่างๆ เช่น การทดสอบความปลอดภัยของแอปพลิเคชันแบบโต้ตอบ (IAST) การตรวจจับและตอบสนองต่อแอปพลิเคชัน (ADR) การป้องกันแอปพลิเคชันแบบเรียลไทม์ (RASP) และการวิเคราะห์องค์ประกอบซอฟต์แวร์ Contrast Security ได้กำหนดตำแหน่งของตนเองโดยการรวมความปลอดภัยเข้ากับกระบวนการ DevSecOps ในรูปแบบที่ทันสมัย ทำให้นักพัฒนา ทีม AppSec และทีมปฏิบัติการด้านความปลอดภัยสามารถระบุและแก้ไขความเสี่ยงได้เร็วขึ้นในขณะเดียวกันก็รักษาความเร็วในการส่งมอบซอฟต์แวร์

หลังจากช่วยกำหนดรูปแบบความปลอดภัยของแอปพลิเคชันสมัยใหม่ผ่านการทำงานกับ OWASP คุณพบช่องว่างในอุตสาหกรรมอะไรที่ทำให้คุณตัดสินใจก่อตั้ง Contrast Security และวิธีการที่ทฤษฎีฐานของบริษัทคงไว้ได้เมื่อความท้าทายด้านความปลอดภัยมีการเปลี่ยนแปลง?

อุตสาหกรรมกำลังจมอยู่ในผลการวิเคราะห์เชิงทฤษฎีที่ไม่มีที่สิ้นสุด และไม่สามารถมุ่งเน้นไปที่ปัญหาที่แท้จริง Security ทีมมีเครื่องสแกนเนอร์ที่สร้างคิวยาวโดยไม่ทราบว่าช่องโหว่ใดที่สามารถเข้าถึงได้ ใช้ได้ หรือถูกโจมตีในขณะผลิต เราก่อตั้ง Contrast ด้วยความคิดง่ายๆ ว่าการตัดสินใจด้านความปลอดภัยควรมาจากการสังเกตการณ์โดยตรงของแอปพลิเคชันที่ทำงานจริง ไม่ใช่การเดาจากภายนอก

สุดท้าย ฉันหวังว่าอุตสาหกรรมจะก้าวหน้าจนถึงจุดที่เราสามารถเลิกการวนซ้ำการค้นหาปัญหา การแก้ไข และการค้นหาปัญหาใหม่ๆ ได้ ฉันหวังว่าเราจะเริ่มสร้างซอฟต์แวร์ที่มีการออกแบบด้านความปลอดภัยที่แข็งแกร่งและมีเหตุผลที่จะเชื่อว่ามีการป้องกันที่เหมาะสมสำหรับภัยคุกคามที่คาดหวัง การผสมผสานระหว่างความปลอดภัยในขณะทำงานและ AI มีศักยภาพ แต่เรายังอยู่ห่างออกไปหลายปี

คุณได้กล่าวถึงการเกิดขึ้นของ “ช่องโหว่ระดับตำนาน” (Mythos-level vulnerabilities) อะไรคือคำจำกัดความของช่องโหว่ประเภทใหม่นี้ และทำไมพวกมันจึงยากสำหรับเครื่องมือความปลอดภัยแบบเดิมๆ ที่จะตรวจจับ?

ช่องโหว่ระดับตำนานคือช่องโหว่ที่เกิดขึ้นจากความซับซ้อนของสแต็กซอฟต์แวร์สมัยใหม่ การโต้ตอบระหว่างพฤติกรรมของเฟรมเวิร์ก ส่วนประกอบ และรูปแบบการออกแบบทำให้นักพัฒนาบางครั้งไม่เข้าใจอย่างเต็มที่ เครื่องมือแบบเดิมยังคงได้รับการปรับให้เหมาะสมสำหรับรูปแบบที่เรียบง่ายและเหตุการณ์ที่สามารถสังเกตได้ ช่องโหว่ระดับตำนานมักต้องการความเข้าใจเกี่ยวกับพฤติกรรมของแอปพลิเคชัน การไหลของการดำเนินงาน และบริบทในขณะทำงานในระดับที่ลึกกว่า

ทำไมช่องโหว่หลายประเภทจึงไม่สามารถสร้างการแจ้งเตือนใน môi trường Security Operations Center (SOC) สมัยใหม่ และสิ่งนี้เปิดเผยอะไรเกี่ยวกับวิธีการที่ทีมความปลอดภัยวัดความเสี่ยงในปัจจุบัน?

โดยทั่วไป SOC ถูกสร้างขึ้นรอบๆ เหตุการณ์ที่สามารถสังเกตได้: ล็อก, สัญญาณ, การรับส่งข้อมูลเครือข่าย, กิจกรรมจุดสิ้นสุด แต่การโจมตีหลายประเภทในระดับแอปพลิเคชันไม่เคยสร้างสัญญาณที่มีความหมายในระบบเหล่านั้น นักพัฒนาบางครั้งไม่ทราบถึงช่องโหว่และไม่ได้เพิ่มการบันทึกที่จะแสดงให้เห็นถึงการโจมตี ดังนั้นการโจมตีหลายครั้งจึงมองไม่เห็นในล็อก SOC ทีมสามารถตอบสนองได้เพียงสิ่งที่พวกเขาเห็นเท่านั้น ดังนั้นเมื่อระดับแอปพลิเคชันและ API มีความสำคัญมากขึ้น จึงจำเป็นต้องมีการติดตั้งเซ็นเซอร์ด้านความปลอดภัยที่สามารถตรวจจับและรายงานพฤติกรรมที่ผิดปกติ

สถาปัตยกรรมแอปพลิเคชันสมัยใหม่ เช่น ไมโครเซอร์วิส API และระบบเซิร์ฟเลส ได้พัฒนาไปอย่างรวดเร็ว ตรงจุดที่สถาปัตยกรรมเหล่านี้กำลังแซงหน้าแนวทางด้านการตรวจจับความปลอดภัยแบบเดิมๆ?

สถาปัตยกรรมเหล่านี้ทำลายแบบจำลองริมขอบเก่า การร้องขอเดินทางผ่านบริการหลายสิบรายการ ฟังก์ชันชั่วคราว API คิว และส่วนประกอบของบุคคลที่สามก่อนที่จะเสร็จสิ้นการทำธุรกรรม เครื่องมือตรวจจับหลายตัวยังคงมองเห็นเพียงชิ้นส่วนแทนที่จะเป็นเส้นทางการดำเนินการที่สมบูรณ์ พวกมันสามารถตรวจสอบแพ็คเก็ตหรือล็อก แต่ไม่สามารถเข้าใจเจตนา การไหลของข้อมูล หรือว่าโค้ดอันตรายได้ถูกดำเนินการจริงหรือไม่ ความปลอดภัยเกี่ยวกับบริบท ดังนั้นเราจึงต้องสร้างแบบจำลองหรือตัวแทนเสมือนของโครงสร้างพื้นฐานแอปพลิเคชันของเราเพื่อให้เราสามารถให้เหตุผลเกี่ยวกับสิ่งที่เรากำลังเห็นได้

OWASP Top Ten ยังคงเน้นย้ำถึงประเด็นด้านความปลอดภัย เช่น การออกแบบที่ไม่ปลอดภัยและส่วนประกอบที่มีช่องโหว่ ทำไมความเสี่ยงเหล่านี้จึงยังคงอยู่ต่อไป尽管มีการรับรู้และเครื่องมืออย่างกว้างขวาง?

การรับรู้ไม่แก้ไขปัญหาเรื่องแรงจูงใจหรือความซับซ้อน ส่วนใหญ่องค์กรยังคงวัดความสำเร็จโดยปริมาณการสแกน การปิดตั๋ว หรือการตรวจสอบการปฏิบัติตามข้อกำหนดมากกว่าการลดความเสี่ยงจริง

ในขณะเดียวกัน ซัพพลายเชนซอฟต์แวร์ระเบิดออกไปในขนาด นักพัฒนารวมแอปพลิเคชันจากส่วนประกอบหลายพันชิ้นที่พวกเขาไม่ได้เขียนและแน่นอนว่าไม่ได้ประเมินความปลอดภัย ทีมความปลอดภัยถูกท่วมท้นในการไตร่ตรองความเสี่ยงเชิงทฤษฎีและไม่สามารถมุ่งเน้นไปที่ 1-2% ที่แท้จริงที่สำคัญ โดยไม่มีหลักฐานในขณะทำงาน การจัดลำดับความสำคัญจะล้มเหลว และด้วยการเกิดขึ้นของโมเดล AI ที่ทรงพลังและตัวยึด มีปริมาณที่เพิ่มขึ้นอย่างมาก

องค์กรควรพิจารณาการพึ่งพาบันทึกและแจ้งเตือนใหม่เมื่อช่องโหว่บางอย่างที่สำคัญที่สุดไม่ปล่อยสัญญาณที่สามารถสังเกตได้?

บันทึกคือหลักฐานของสิ่งที่แอปพลิเคชันเลือกที่จะรายงาน ไม่ใช่หลักฐานของสิ่งที่เกิดขึ้นจริง นั่นคือความแตกต่างที่อันตราย องค์กรต้องเปลี่ยนจากการสังเกตการณ์ทางอ้อมไปสู่การสังเกตการณ์โดยตรง แทนที่จะหวังว่าการโจมตีจะสร้างอาร์ติแฟคท์ที่สามารถตรวจจับได้ ระบบความปลอดภัยควรระบุพฤติกรรมที่มีช่องโหว่และพฤติกรรมการโจมตีในขณะทำงาน หากโค้ดอันตรายถูกดำเนินการ ระบบควรทราบทันที – ไม่ว่าจะมีการเขียนล็อกหรือไม่

คุณได้สนับสนุนการมองเห็นในขณะทำงานเป็นวิธีแก้ปัญหา อะไรคือการมองเห็นในขณะทำงานที่แท้จริงในทางปฏิบัติ และมันเปลี่ยนแปลงวิธีการทำงานของทีมความปลอดภัยในแต่ละวันอย่างไร?

การมองเห็นในขณะทำงานที่แท้จริงหมายถึงการเข้าใจว่าแอปพลิเคชันกำลังทำอะไรในขณะผลิตจริง: เส้นทางใดที่เปิดเผย ไลบรารีใดที่ใช้งานอยู่ ที่ใดที่ข้อมูลที่ละเอียดอ่อนไหลไป โค้ดใดที่ถูกดำเนินการ และการโจมตีได้เข้าถึงฟังก์ชันช่องโหว่หรือไม่ ในทางปฏิบัติ มันเปลี่ยนความปลอดภัยจากการล่าแบบตอบสนองเป็นวินัยที่แม่นยำ ทีมหยุดการล่าช่องโหว่จำนวนมากและเริ่มมุ่งเน้นไปที่เปอร์เซ็นต์ที่เล็กน้อยของการเปิดเผยที่สามารถเข้าถึงได้ มีความสำคัญ และถูกโจมตีอย่างแข็งขัน ซึ่งปรับปรุงอัตราส่วนสัญญาณต่อเสียงรบกวนและความเร็วในการตอบสนองอย่างมาก ในเฉลี่ยเพียง 38% ของไลบรารีโอเพ่นซอร์สที่ถูกจัดแพ็คในแอปพลิเคชันถูกโหลดเข้าไปในหน่วยความจำและถูกดำเนินการ และไม่ใช่ทุกโค้ดในเซตย่อยนี้ที่ถูกใช้ ดังนั้นสิ่งหนึ่งที่ความปลอดภัยในขณะทำงานทำให้เป็นไปได้คือการมุ่งเน้นไปที่โค้ดที่แท้จริงที่ทำงาน และไม่ใช่ไลบรารี่และฟังก์ชันที่ไม่ได้ใช้ที่มาพร้อมกับแอปพลิเคชัน

การรักษาความปลอดภัยโดยใช้เครื่องมือติดเครื่องมือเปรียบเทียบกับแนวทางแบบเดิมๆ เช่น SAST, DAST หรือการตรวจสอบริมขอบในแง่ของประสิทธิผลและความสามารถในการปรับขนาด?

เครื่องมือแบบเดิมๆ อ้างอิงความเสี่ยงจากภายนอก การติดเครื่องมือสังเกตความเป็นจริงโดยการสังเกตโค้ดที่ทำงานจริง การติดเครื่องมือสามารถเห็นเส้นทางการดำเนินการที่แท้จริง พฤติกรรมเฟรมเวิร์ก บริบทการรับรองความถูกต้อง การไหลของข้อมูล และความสำเร็จของการโจมตีในเวลาจริง มันกำจัดหมวดหมู่ขนาดใหญ่ของผลบวกลวงและเปิดเผยช่องโหว่ที่เครื่องมือริมขอบไม่พบเลย ที่ขนาดใหญ่ ความแม่นยำนี้กลายเป็นเรื่องสำคัญ องค์กรไม่สามารถไตร่ตรองผลการค้นหาทางทฤษฎีหลายล้านรายการได้อีกต่อไป หลักฐานในขณะทำงานกำลังจะกลายเป็นตัวกรองที่ยั่งยืนเพียงตัวเดียว การทำงานในขณะทำงานเป็นแบบเรียลไทม์ ดังนั้นมันจึงเป็นคู่ที่ดีกว่าสำหรับพายพันและท่อขนส่ง CI/CD มากกว่าการสแกนและการไตร่ตรอง และการทำงานในขณะทำงานเป็นแบบต่อเนื่อง ดังนั้นคุณจึงไม่จำกัดอยู่ที่มุมมองแบบจุดเดียวในเวลาของความปลอดภัย

เมื่อระบบ AI และแอปพลิเคชันแบบอัตโนมัติกลายเป็นที่นิยมมากขึ้น ช่องโหว่ที่มองไม่เห็นจะกลายเป็นอันตรายมากขึ้น และทีมควรเตรียมตัวอย่างไร?

AI ทำให้ช่องโหว่ที่มองไม่เห็นกลายเป็นอันตรายมากขึ้นเพราะมันเร่งทั้งสองด้านของปัญหา นักพัฒนากำลังสร้างซอฟต์แวร์เร็วขึ้น และผู้โจมตีกำลังหาช่องโหว่และใช้ประโยชน์จากช่องโหว่เหล่านั้นเร็วขึ้น แต่โปรแกรมความปลอดภัยส่วนใหญ่ยังคงพึ่งพาการประมวลผลของมนุษย์ ซึ่งไม่สามารถทำงานได้ที่ความเร็วของ AI ทีมควรเตรียมตัวในสองวิธี ประการแรก สร้างการป้องกันในขณะทำงานที่แข็งแกร่งกว่าซึ่งสามารถตรวจจับ ปิดกั้น และจำกัดการโจมตีในขณะผลิตในขณะที่ช่องโหว่กำลังถูกแก้ไข ซึ่งให้การป้องกันการบินให้กับองค์กร ประการที่สอง ใช้ AI และการทำให้กระบวนการทำงานอัตโนมัติเพื่อเขียนโค้ดที่ปลอดภัยยิ่งขึ้นตั้งแต่แรก โดยมีการออกแบบที่ดีกว่า การทดสอบ การทบทวน และการตรวจสอบอย่างเข้มงวด ไม่เช่นนั้นเราก็แค่สร้างความเสี่ยงเร็วกว่าที่เราจะจัดการได้

หากคุณกำลังให้คำแนะนำแก่ผู้นำ Security Operations Center (SOC) ในปัจจุบัน ก้าวแรกที่เป็นรูปธรรมที่พวกเขาควรทำเพื่อปิดช่องว่างการมองเห็นก่อนที่จะนำไปสู่การละเมิดที่สำคัญคืออะไร?

ประการแรก ยอมรับว่าการวัดผลริมขอบเพียงอย่างเดียวไม่เพียงพอสำหรับความปลอดภัยของแอปพลิเคชันสมัยใหม่ ในความเป็นจริง มันไม่สามารถมองเห็นหรือหยุดการโจมตีแอปพลิเคชันและ API ได้หลายครั้ง ที่ริมขอบ SOC ต้องการการมองเห็นภายในแอปพลิเคชันที่ทำงาน ไม่ใช่เพียงโครงสร้างพื้นฐานที่โฮสต์พวกมันเท่านั้น ประการที่สอง จัดลำดับความสำคัญของหลักฐานในขณะทำงานมากกว่าผลการค้นหาทางทฤษฎี มุ่งเน้นไปที่ช่องโหว่ที่อยู่ในโค้ดที่ใช้งานอยู่ ระบุเส้นทางการโจมตีที่ใช้งานอยู่ และบริการที่เปิดเผยและทำงานอยู่ในขณะผลิต สุดท้าย รวมความปลอดภัยของแอปพลิเคชันเข้ากับการออกแบบการตรวจจับและป้องกันความปลอดภัย อนาคตของ SOC ไม่สามารถปฏิบัติต่อแอปพลิเคชันเหมือนกล่องดำที่ไม่โปร่งใสได้อีกต่อไป แอปพลิเคชันคือพื้นผิวการโจมตีหลักๆ และต้องการการมองเห็นที่ดีเยี่ยมในขณะทำงาน

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ OWASP หรือ Contrast Security.