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

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

המאמר מתמקד במשטחי תקיפה, הצורך בניהול, מבט תוקף על משטחי תקיפה ועל הכלי החדש בשכונה Microsoft Defender External Attack Surface Management.

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

מציאות בשטח

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

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

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

בתור אחד שמתמקד בתחום של DFIR גם בתגובה ותחקור אני תמיד שם את עצמי בנעלי התוקף ותמיד מגלה שהתוקפים מחפשים ומוצאים נקודות חלשות – ולעיתים מדובר על נקודות שאינן מוכרות ויתרה מכך גם לא הדרך הכי מתוחכמת לבצע חדירה.

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

משטח תקיפה

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

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

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

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

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

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

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

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

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

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

רגע לפני שנדבר על כלי EASM ובפרט על Defender EASM צריך להבין את התמונה של ASM קודם לכן.

על ASM וכאלה

רגע לפני שנתחיל לדבר על Microsoft Defender EASM צריך לקבל את התמונה הכללית על Attack Surface Management על מנת שנוכל להבין את הנקודות החשובות ביומיום של ניהול משטחי תקיפה.

תכונות של כלי ASM

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

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

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

פונקציות הליבה של ASM

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

תהליכי וצורת עבודה יכולים להשתנות בין תהליכים וכלים שונים אך תמיד חייבים להתבסס על העקרונות הבאים:

גילוי נכסים – לא ניתן לנהל נכס אם אינוי ידוע שהוא קיים כלל. לרוב הארגונים יש מגוון הפתעות כשאר מדובר על נכסים כמו זה של "אלמונים לא מוכרים", כגון נכסים השוכנים באתרי שותפים או של צד שלישי, וורקלואדים בסביבות ענן (zombie app/api), התקני IoT, כתובות IP, מכונות ברשתות שונות, קרדס מאוחסנים בצד שלישי והרשימה ארוכה. כידוע, כלים ותהליכים שאינם שייכים לדור החדש יכולים לפספס בקלות רבה את הנכסים במשטחי התקיפה האלה, אך ניתן למצוא אותם בצורה טובה יותר על ידי תוכנית ופתרונות מתקדמים לניהול משטחי תקיפה המשתמשים בטכניקות של גילוי. 

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

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

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

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

כלי ASM והתאמה לכלי אבטחה 

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

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

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

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

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

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

נקודות תקיפה אל מול ASM

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

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

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

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

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

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

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

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

נקודת מבט של תוקף

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

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

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

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

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

רכיבי SaaS – ארגונים ממשיכים להוסיף יישומי SaaS נוספים. ארגונים עם 500-2,000 עובדים בממוצע עם 650 יישומים שונים (רק הגדרה דיפולטית של Office 365 מכילה 200 יישומים). לכן, גם אם רק מחצית מהיישומים הללו משתייכים לקטגוריות של "סיכון גבוה", זה עדיין אומר שצוותי הגנה צריכים להגן על אינפסור נכסים, בעיות ופערי אבטחה. תוקפים מודעים למצב הזה הרבה יותר משאר צוותי אבטחה ולכן מנצלים אפליקציות בעלי סיכון גבוה (ועם הרשאות גבוהות) בכדי לחדור לענן.

נקודות כשל – יתר על כן, כל קשר מוביל לנקודת כשל פוטנציאלית כמו ווקטורי התקיפה הפוטנציאליים הבאים:

– גישת משתמש מכל מקום אל הענן
– ממשקי API פתוחים (מי אמר Zombie API?)
– וורקלואדים חשופים בענן
– פונקציות שמוגדרות מפתחות ואלה חשופות לרשת החיצונית
– משאבים שהוגדרו באופן שגוי כמו מיסקונפיגורציה של מכונות, או Storage ענני וכו

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

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

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

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

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

מציאות אל מול כלי ASM

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

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

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

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

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

– סיסמאות חלשות
– מערכות מיושנות 
– הגדרות שגויות

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

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

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

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

מהו Defender EASM

הכלי Microsoft Defender External Attack Surface Management או בקצרה Defender EASM הוא הילד החדש במשפחת הדפדנדרים וכמו האחרים הוא משלים חלק מהותי בפאזל של Kill-Chain תוך שמירה על המאפיינים המוכרים של המשפחה עם אינטגרציה לכלים אחרים, התממשקות אל Security Graph, העברת נתונים בין כלים אחרים ועוד.

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

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

גילוי ואינבנטורי

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

Defender EASM כולל את הגילוי של סוגי הנכסים הבאים:

• תחומים
• שמות מארחים
• דפי אינטרנט
• בלוקי IP
• כתובות IP
• ASNs
• תעודות SSL
• אנשי קשר של WHOIS

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

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

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