אבטחת אפליקציות – חמישה טרנדים ל-2019

שיתוף ב facebook
שיתוף ב twitter
שיתוף ב linkedin

אבטחת אפליקציות

אבטחת אפליקציות – חמישה טרנדים ל-2019

הקדמה,

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

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

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

0: בדיקות אבטחת אפליקציות מסורתיות

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

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

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

כמו שאמרתי, זה לא הולך לשום מקום אבל ייתכן שיתחיל לצוץ באופן אחר כפי שנראה בהמשך המאמר.

1: "דחיפה לשמאל" ו"הבניית אבטחה"

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

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

באופן דומה, המפתחים של סורקי חולשות מתמקדים בכבדות על לאפשר לארגונים לשלב את הכלים שלהם אל תוך הבילד האוטומטי שלהם ולתהליכי ההשקה. ראו, לדוגמה, את השחרור של [Burp Suite Enterprise] לפני כמה חודשים כחלק משחרור גרסה 2.0 שלהם.

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

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

2: ניטור, התראה ותגובה באפליקציות

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

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

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

3: עליית "ללא שרת" (Serverless)

הקונספט של ללא-שרת, על פיו האפליקציה קיימת רק כקוד תכנות בסביבת ענן, או שירותי backend מסופקים במלואם על ידי צד שלישי, מתגבר בשנים האחרונות. אנו רואים אותו מיושם באפליקציות חדשות המשתמשות ב"backend as a service" כגון גוגל פיירבייס או "פונקציות כשירות" כגון AWS למבדה.

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

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

4: פלטפורמות באג-באונטי מתקדמות ומציעות בדיקות חדירה

פלטפורמות הבאג-באונטי הגדולות השקיעו זמן ומאמץ משמעותיים על מנת לבנות מאגר של בודקי אבטחה ידניים מוכשרים ברמה גבוהה. מאגר זה מגיע עם דירוג, דוגמאות של ממצאים, פרסומים וכו', ומשמש כדרך להבליט כמה מבודקי האבטחה המתוחכמים ביותר בעולם. כעת נראה שהם ממנפים את המאגר הזה כדי להכנס לשוק הצפוף של "תשלום עבור מאמץ" בבדיקות חדירה במקום פשוט להציע "תשלום עבור תוצאות" כפי שהציעו בעבר. הראיונות שנתנו באגקראוד (Bugcrowd) ב[פודקאסט של Risky Business] בפרקים [524] ו-[531] הם בגדר "חובה לשמוע" לכל ספק בדיקות אבטחת אפליקציות.

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

ליועצים שאין להם הזמן או הנטייה לבנות את הסטטוס הזה בזמנם החופשי, עכשיו נראה כמו זמן טוב להתחיל לבנות כישורים בתחומי ה-"push left" או "ניטור אפליקציות" (application monitoring) שהודגשו לעיל. נראה שגישת באג-באונטי זו, של "תשלום עבור מאמץ" עלולה להיות העתיד של בדיקות אבטחה אפליקטיביות מסורתיות.

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

5: הצורך במומחי אבטחת מוצר

העלייה של ללא-שרת ו"קלאוד-נייטיב" (cloud native) מובילה לכך שאפילקציות כבר אינן תואמות לארכיטקטורת "שרת ווב", "שרת אפליקציה" ו"שרת דטבייס" הישנה. במקום זאת, אפליקציות נבנות ממספר שירותים שונים, חלקם ינוהלו ויתארחו באופן מלא על ידי צד שלישי.

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

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

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

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

לסיכום

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

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

ג'וש גרוסמן

יועץ אבטחת מידע בכיר וראש צוות

@JoshCGrossman

joshg@comsecglobal.com

תודה למיכאל לוי על ההגהה והפידבק על פוסט זה

Sign up for our Newsletter

סגירת תפריט