สิ่งที่ RASP ควรได้รับ

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

ในทางตรงกันข้าม เทคโนโลยี RASP ของแท้ทำงานที่ชั้นแอปพลิเคชัน ซึ่งมีบริบททั้งหมดของผู้ใช้ ตรรกะแอปพลิเคชัน และข้อมูลโดเมน บริบทนี้ช่วยให้ RASP สามารถตัดสินใจอย่างรอบรู้เกี่ยวกับความปลอดภัยของแอปพลิเคชัน และป้องกันการเจาะระบบก่อนที่จะก่อให้เกิดอันตราย ผลที่ตามมาคือ RASP ที่แท้จริงควรมีค่า False Positive เป็นศูนย์และเวลาแฝงที่ลดลง ซึ่งจะช่วยเพิ่มประสิทธิภาพในทันที True RASP ต้องการรายการกฎที่ไม่เปลี่ยนรูปซึ่งใช้บริบทเพื่อทำความเข้าใจเมื่อมีการแนะนำช่องโหว่ใหม่และดำเนินการตามนั้น การเปลี่ยนแปลงไม่ได้นี้เป็นไปได้เมื่อกฎถูกรวมเข้ากับโค้ดฐานที่ชั้นแอปพลิเคชัน และไม่ต้องการการเปลี่ยนแปลงใดๆ เมื่อปรับใช้

สามจุดที่ RASP ผิดพลาด

1. ปัญหาสุนัขเห่า: การแจ้งเตือนส่วนใหญ่เป็นผลบวกที่ผิดพลาด

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

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

2. ปัญหาคนเลว 999 คน: สามารถทดสอบตัวอย่างได้เท่านั้น

เชื่อหรือไม่ว่า ผู้ขายบางรายบอกให้คุณเรียกใช้โซลูชันการรักษาความปลอดภัยในสภาพแวดล้อมการผลิตเท่านั้น หากคุณป้องกันเฉพาะขนาดตัวอย่างเท่านั้น ซึ่งหมายความว่าจะดึงตัวอย่าง — อาจเป็นหนึ่งในทุก ๆ 1,000 คำขอ — และทดสอบตัวอย่างนั้นพร้อมกับจับสิ่งที่เกิดขึ้นในปี 999 ถัดไป หมายความว่าหากคุณเป็นนักแสดงที่ดี ลายเซ็นของคุณจะตรวจสอบได้ แต่ไม่ว่านักแสดง 999 คนต่อไปนี้จะมีเจตนาร้ายหรือไม่ก็ตาม พวกเขาก็จะผ่านพ้นไปได้ การขาดความสม่ำเสมอนี้เป็นเพราะ RASP ที่ใช้ WAF ไม่สามารถจัดการกับข้อกำหนดด้านประสิทธิภาพที่ต้องทดสอบทุกคำขอ

3. ปัญหา “ใช้เวลานานเกินไป”: เวลาแฝงส่งผลต่อประสิทธิภาพ

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

การปรับปรุงกระบวนการนี้คล้ายกับการปรับโค้ดให้เหมาะสม เมื่อสร้างรายการ นักพัฒนาตั้งค่าให้เพิ่มรายการใหม่ที่จุดเริ่มต้นของรายการแทนที่จะเป็นตอนท้าย การเพิ่มประสิทธิภาพนี้ป้องกัน VM จากการสร้างรายการทั้งหมดใหม่ทุกครั้งที่มีการเพิ่มรายการใหม่ ป้องกันไม่ให้เวลาแฝงเพิ่มขึ้นเมื่อรายการเพิ่มขึ้น วิศวกรคอมไพลเลอร์แก้ไขปัญหาเหล่านี้โดยการนำการคอมไพล์แบบทันเวลาพอดี (JIT) มาใช้ในช่วงต้นปี 2000 ซึ่งปรับโค้ดให้เหมาะสมโดยอัตโนมัติตามความแตกต่างของภาษาที่กำหนด

ทำไมคำจำกัดความของ RASP จึงถูกรดน้ำ?

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

True RASP ปรับโค้ดให้เหมาะสมเพื่อประสิทธิภาพและความปลอดภัย

เนื่องจากแพลตฟอร์ม RASP ส่วนใหญ่ทำงานเหมือน WAF จึงมีค่าใช้จ่ายจำนวนมากที่เกี่ยวข้อง ซึ่งจำเป็นต้องเรียกใช้ในโหมดตัวอย่าง ในทางตรงกันข้าม RASP ของแท้จะทำการป้องกันจริงในรันไทม์

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

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

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

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

วิธีการนี้ช่วยให้การรักษาความปลอดภัยสามารถปรับใช้ได้แบบไม่เชื่อเรื่องพระเจ้า และไม่ต้องมีการเปลี่ยนแปลงรหัสในรหัสแอปพลิเคชัน ปรับแต่ง หรือรอหน้าต่างการปรับใช้

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

RASP สามารถและควรได้รับมาตรฐานที่สูงขึ้น

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been