מה RASP היה צריך להיות

בשנים האחרונות, אבטחת יישומים העולם ראה את עלייתו של הגנה עצמית של יישום בזמן ריצה (RASP) טֶכנוֹלוֹגִיָה. כפי שתואר על ידי Gartner, RASP היא טכנולוגיית אבטחה המשולבת באפליקציה או בסביבת זמן הריצה שלו, המסוגלת לשלוט ולמנוע התקפות בזמן אמת. למרבה הצער, רבים חומת אש של יישומי אינטרנט (WAF) חברות ראו הזדמנות למנף את המונח. הם הציגו סוכנים "דמויי RASP" בשכבת הרשת, שאינה מאמצת לחלוטין את ההגדרה של טכנולוגיית RASP.

לעומת זאת, טכנולוגיית RASP מקורית פועלת בשכבת האפליקציה, שם יש לה הקשר מלא של המשתמש, הלוגיקה של האפליקציה ומידע התחום. הקשר זה מאפשר ל-RASP לקבל החלטות מושכלות לגבי אבטחת האפליקציה ולמנוע ניצול לפני שהם יכולים לגרום נזק. כתוצאה מכך, ל-RASP אמיתי צריך להיות אפס תוצאות חיוביות שגויות והשהייה מופחתת, מה שמספק דחיפה מיידית לביצועים. RASP אמיתי דורש רשימה של כללים בלתי ניתנים לשינוי המשתמשים בהקשר כדי להבין מתי מוצגת פגיעות חדשה ולפעול בהתאם. חוסר שינוי זה אפשרי כאשר כללים נאפים בבסיס הקוד בשכבת היישום ואינו דורש שינויים לאחר פריסה.

שלושה אזורים שבהם RASP השתבש

1. בעיית הכלב הנובח: רוב ההתראות הן חיוביות כוזבות

הבעיה עם WAFs היא שהם עובדים בשכבת הרשת, אינדיקטור בפיגור של ביצוע יישומים. חוסר ההקשר הנובע מכך מוביל לשיעורים חיוביים כוזבים גבוהים, זמני המתנה ארוכים וביצועים גרועים, מכיוון ש-WAFs יכולים רק לנחש לגבי אופי הפגיעות על סמך מה שהם נחשפו אליו בעבר.

דמיינו לעצמכם כלב שמירה בחצר נובח בכל פעם שהוא שומע רעש מעבר לגדר. רעשים אלה עשויים להיות גישה של פולש, אבל הם יכולים להיות גם מכוניות שעוברות במקום. כלב השמירה אינו יכול לאמוד במדויק את ההבדל, כך שהחומרה של כל רעש נתון אובדת, מה שהופך את האנשים בתוך הבית לבלתי אפשריים לדעת אילו התראות הן אמיתיות ואילו תוצאות חיוביות כוזבות. תרחיש זה הוא בעצם היכולת של היצע ה-RASP הסטנדרטי.

2. בעיית 999 הרעים: מסוגל לבדוק רק מדגם

תאמין או לא, ספקים מסוימים אומרים לך להפעיל את פתרון האבטחה שלהם רק בסביבות ייצור אם אתה מגן רק על גודל מדגם. זה אומר שהוא מושך דגימה - אולי אחת מכל 1,000 בקשות - ובודק את הדגימה הזו תוך שהוא קולט מה יקרה ל-999 הבאות. כלומר, אם אתה שחקן טוב, החתימה שלך תיגמר. אבל בלי קשר לשאלה אם ל-999 השחקנים הבאים יש כוונות רעות או לא, הם יצליחו. חוסר העקביות הזה נובע רק מכך ש-RASPs מבוססי WAF לא יכולים להתמודד עם דרישות הביצועים של הצורך לבדוק כל בקשה.

3. בעיית "זה לוקח יותר מדי זמן": חביון משפיע על הביצועים

בכל פעם שיש לך RASP מבוסס WAF, אתה חווה חביון מוגבר, מכיוון שהוא לא יכול להשפיע על בסיס הקוד של היישום בשום אופן. בינתיים, RASPs זמינים באופן נרחב צריכים לשלוח מטענים שלמים של טקסט אל מנתח האינטרנט שלהם ואז להמתין לשליחתו בחזרה, מה שעלול להימשך זמן רב. ואם הלקוחות שלך ממתינים לתשלומים שיעברו, הם עלולים לוותר ולחפש את המתחרים שלך במקום זאת.

שיפור תהליך זה דומה לאופטימיזציה של קוד. בעת יצירת רשימה, מפתחים מגדירים אותה להוסיף פריטים חדשים לתחילת רשימה במקום לסוף. אופטימיזציה זו מונעת מה-VM לבנות מחדש את הרשימה כולה בכל פעם שמתווסף פריט חדש, ומונעת את השהייה הגוברת ככל שהרשימה גדלה. מהנדסי מהדרים התייחסו לבעיות אלו על ידי הטמעת קומפילציה בדיוק בזמן (JIT) בתחילת שנות ה-2000, אשר מבצעת אופטימיזציה אוטומטית של קוד על סמך הניואנסים של השפה הנתונה.

מדוע ההגדרה של RASP התמהמה כל כך?

פיתוח טכנולוגיית RASP דורש שילוב של הנדסת אבטחה וכישורי הנדסת תוכנה. כדי להיות יעיל, מפתח ה-RASP חייב להבין לעומק את ארכיטקטורת האפליקציה ואת הניואנסים של שפת התכנות שבה נעשה שימוש. זה דורש מומחיות בתחום הנדיר בקרב אנשי אבטחה.

RASP אמיתי מייעל קוד לביצועים וגם לאבטחה

מכיוון שרוב פלטפורמות ה-RASP מתנהגות כמו WAFs, ישנה תקורה מסיבית המחייבת להפעיל אותן במצב מדגם. לעומת זאת, RASP מקורי מבצע את ההגנה בפועל בזמן הריצה.

הפעולות האלה קיימות בזיכרון, וזה מאוד יעיל, ומכיוון שזה קיים באותו מקום כמו האפליקציות שלך, הן מאוד ביצועיות. על ידי ביצוע ההגנה בזמן הריצה, אין צורך להגביל לדרג או לבצע הגנה בגדלים של דגימה מכיוון שהפעולה בפועל נמשכת מספר אלפיות שנייה.

ללא קשר לשינויים שנעשו באפליקציה, אבטחה בעלת ביצועים גבוהים נשארת קבועה. הפילוסופיה הזו מתיישרת עם הפילוסופיה של תשתית-כקוד, שבה אתה מגדיר את המצב הרצוי של התשתית שלך, ולא משנה מה קורה בסביבה, מצב התשתית נשאר זהה.

RASP, בהגדרה, מקביל לעקרונות רבים של תשתית-כקוד. הקבלה זו אפשרית בשל המודעות ההקשרית העמוקה לאפליקציה ולשפה בה היא בנויה. כמו תשתית כקוד, גישה אמיתית ל-RASP יכולה וצריכה לעשות שימוש בחוסר שינוי כדי להבטיח שהכללים מיושמים ללא קשר לשינויים בבסיס הקוד.

אי-שינוי אפשרי על ידי ביצוע בדיקה של הפלט של פונקציה בפעם הראשונה שהיא נקראת והחלפת כל פונקציונליות לא בריאה עם פונקציונליות מוגנת, מה שמבטיח שהיישום תמיד בריא בזמן שהוא פועל.

גישה זו מאפשרת לאבטחה להיות אגנוסטית לפריסה ואינה דורשת שינויי קוד בקוד היישום, כוונון או המתנה לחלונות פריסה.

על ידי ביצוע הגנה בזמן הריצה, תיקון תוצאות עם הגנה מיידית על כל מופעי הריצה של האפליקציה, מבטל את הצורך בתוצאות שגויות קבועות ומסיר את הסיכון לניצול עתידי.

ניתן וצריך להחזיק RASP ברמה גבוהה יותר

בקיצור, RASP צריך להיות ברמה גבוהה יותר. כאשר נעשה זאת, ניתן לאבטח אלפי יישומים, להוזיל את עלות הבעלות הכוללת של ה-WAF שלך ולסייע במניעת שחיקה בצוותי האבטחה שלך.

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been