הדבר היחיד שנוי במחלוקת יותר מאשר המשמעות של Application Security Posture Management (ASPM) האם ההשקעה ב ASPM כלי שווה את זה. מאז חשיפת הקטגוריה, ספקים מכל הסוגים מיהרו לטעון שהם עושים זאת, אך לא הוקדש הרבה דיו לשאלה האם זה העתיד. בסופו של דבר, עתיד אבטחת היישומים מטופל בצורה הטובה ביותר על ידי הבנת מהן הבעיות הגדולות ביותר שלה. במאמר זה, נדבר על אילו בעיות יצרו את הקטגוריה של ASPM ולהעריך אם הוא מציע את הפתרונות שהשוק מחפש.
בעיות באבטחת יישומים
יותר מדי סורקים
מאחר שטענתי במקור בעד ASPM לְרַבּוֹת 8 סוגים של סורקיםלפחות עוד שניים צצו. צוותי אבטחה יכולים לספוג סורקים, אבל רק אם יש משמעות שונה ביניהם. סריקת שרתים בזמן ריצה לא בהכרח צורך להיות באותו מקום שבו סורק מאגרים. הבעיה היא שמאגרים הפכו למקור אמין יותר של אמת לגבי היכן למצוא ולתקן פגיעויות.
למרות היותו במקום אחד, מאגר יכול להכיל עשרות קבצים שונים המבצעים פעולות רבות ושונות. באופן מסורתי, צוותי אבטחה היו צריכים להגדיר מספר תמונות Docker או קבצים בינאריים שונים כדי לסרוק את הקבצים הללו תוך כדי שינוי ונפרסות. תחזוקת סורקים יכולה בקלות להיות מספר עבודות במשרה מלאה, מכיוון שכולם גם נזקקו לתצורות מיוחדות כדי לעבוד על קטעי קוד שונים.
צוותי אבטחה צריך את הנראות מכל הסורקים השונים הללו, אך נהנים מאוד מהפשטות של "ללא סוכן" pipeline אינטרנטhooks שסורקים ללא תצורה, או לפחות אומרים לכלי יחיד לסרוק. ASPM כלים עושים עבודה נהדרת במתן נראות פשוטה.
יותר מדי תוצאות חיוביות שגויות
הטענה נגדית לאגירת כל סורק במקום אחד היא שאנשים טוענים שתהיה ירידה באיכות הסריקה. אני רגיש לדאגה הזו, אבל יש לי שתי נקודות נגד. ראשית, כלים רבים פשוט עוטפים את אותם חומרים בקוד פתוח בכל מקרה, הסורקים הכל-באחד פשוט יותר כנים לגבי זה. שנית, הטיעונים האלה תמיד מסתמכים על הרעיון שזה פשוט בלתי אפשרי שהסורק של מישהו יהיה טוב כמו שלו.
בסופו של דבר, הבעיה היא רק לפתור את בעיית ריבוי התוצאות החיוביות השגויות. נגישות היא הרעיון של גילוי האם ניתן באמת לנצל פגיעות או לא. ASPM לכלים יש גרסאות "מספיק טובות" של נגישות, כך שקשה יותר ויותר מיום לטעון שזה לא אפשרי.
הגרוע מכל, סריקה אחר קורות חיים לבד יכול להשאיר נקודות עיוורות קריטיות, ולכן אני מעריך ספקים כמו Xygeni משתי סיבות: ראשית, הסריקה שלהם במעלה הזרם אחר תוכנות זדוניות במקום רק פגיעויות. שנית, שלהם commitלחפש תצורות אחרות הניתנות לניצול כמו pipeline תצורות שגויות, וכן לזהות אם התקפות אלה אכן התרחשו.
לתקן דברים זה באמת קשה
צוותי אבטחה רואים מעט מאוד מהירות בתיקון הפגיעויות שלהם. שמעתי סיפורי אימה רבים על אפילו הפגיעויות הבוערות ביותר של אפס ימים שלקח חודשים לתקן בכל רחבי המערכת. enterprise מערכות אקולוגיות. בעוד שכלים רבים אמרו שהבעיה היא "תעדוף", אפשר לתעדף כל היום, אבל אם מהנדסים לא יכולים לתקן משהו בקלות, זה הכל לשווא.
זוהי מגמה יותר בצד של "ניהול פגיעויות" ASPM, אבל לעזור למפתחים לתקן פגיעויות צריכה להיות המטרה האמיתית של ASPM.
יותר מדי קוד, מהיר מדי
אם נחשוב שהענן האיץ את פריסות הקוד, בינה מלאכותית גנרטיבית רק הגבירה את מהירות הקוד. נקודה נוספת שלא נדונה מספיק היא כיצד בינה מלאכותית גנרטיבית ממשיכה לפתוח קהלים חדשים לקוד - ומאפשרת לכולם, החל מצוותי מכירות ועד חשבונאות, ליצור סקריפטים של פייתון שעושים דברים פשוטים.
התפתחויות אלו הפכו את הסריקה בתדירות גבוהה, לעתים קרובות ובסביבות מגוונות לחשובה מתמיד. אם נדרש תהליך אישור ארוך כדי להגדיר יישומים חדשים עם סריקה, אתם פשוט תהיו מוכנים להתעוור.
סביבות מגוונות מדי
בעוד שמספר הסורקים יכול להיות מכריע, כאשר מוסיפים את סגנון ה-Javascript, גרסת השפה או כל מסגרות אחרות לפי טעם החודש, מציאת "פתרונות נקודתיים הטובים מסוגם" פשוט אינה אפשרית יותר. אני לא רואה צוותי אבטחה המחפשים פתרון סריקה הטוב מסוגו לכל סגנון של Javascript. ASPM כלי יכול להפוך את כיסוי הסריקה לזמין הרבה יותר מאשר ניסיון לעבור על בסיס שפה אחר שפה.
ASPM פתרון כלי?
בעיות אלו הן הסיבה שהגדרתי ASPM כמו:
Application Security Posture Management מספק את כל מה שצריך כדי לסרוק ולתקן את האפליקציה שלך לאיתור פגיעויות. הוא מספק סריקת אבטחה בכל רחבי SDLC pipeline, קולט תוצאות ובונה זרימות עבודה לתיקון.
בפועל, זה מתממש כשילוב קוד מקור מקיף שסורק בצורה חלקה את הקוד שלך לאיתור פגיעויות, מתעדף אותן ועוזר להקצות אותן לאנשים הנכונים. בואו נבחן כיצד זה פותר את כל... הבעיות העיקריות ב-AppSec:
יותר מדי סורקים
- זה מובן מאליו - פשוט אין עוד סיבה שיהיו 8 פתרונות נקודתיים שונים כשאחד יכול להספיק כדי לכסות את רוב הערימה שלך.
יותר מדי תוצאות חיוביות שגויות
- בעוד שהרעיון של "פתרונות נקודתיים טובים יותר" נמשך, ASPMבדרך כלל יש ל- ים נראות הוליסטית הרבה יותר לגבי אופן פעולתה של אפליקציה. בין אם מדובר במיפוי תלויות בנייה, או בתמונה של "קוד לענן" - כלים אלה בדרך כלל עושים עבודה טובה יותר בסילוק תוצאות חיוביות שגויות.
לתקן דברים זה באמת קשה
- למען ההגינות, זה המקום שבו (באופן כללי) ספקים רבים שנמנעו מסריקה בנו מנועי תיקון טובים יותר. כך או כך, זה המקום שבו ASPM מצטיין מעל CSPM – יש לה למעשה שיטה להעביר ממצאים לאנשים שיכולים לתקן אותם.
יותר מדי קוד, מהיר מדי
- העובדה שפריסת סורקים אוטומטית במאגרים חדשים היא תכונה כה נדירה מראה לכם כיצד רק פעולות מבוססות-webhook ASPM מאפשר לאבטחה להתרחב במהירות הנדרשת לכמות הקוד בסביבה
סביבות מגוונות מדי
- אמנם תמיד עשויים להיות מקרי קצה, אך "הטובים ביותר מסוגם" נהיים קשים יותר ויותר להערכה - האם צוות אבטחה אמור לבדוק 8 סורקים מול 5 שפות עם 10 הוכחות היתכנות?
אני עומד בצד ASPM (ו ASPM כלים) בהיותם עתיד אבטחת היישומים, הם פותרים את רוב הבעיות העומדות בפני אנשי מקצוע בתחום אבטחת היישומים. ברגע שהחוזים הקיימים יסתיימו, או אפילו לפני כן, אנשי המקצוע יפנו לפתרונות החדשים הללו. הדבר היחיד שעוצר אותם הוא המודעות שיש דרך טובה יותר.
