זיהוי ותגובה לאיומי זהות (ITDR)
מרחב הזהויות היו ונשארו שטח תקיפה פורה, והמעבר לענן הרחיב את שטח התקיפה למימדים לא ידועים, וכעת מרחב הזהויות הוא אחד הווקטורים המתורגטים והמוצלחים במרחב הסייבר. תקריות שמקורן בגניבת זהויות, או מחטף של טוקנים ועוגיות, וכן מניפולציות מגוונות נמצאות במרחב וניתנים לניצול ע״י שחקנים ותוקפים רבים.
המעבר לענן והאימוץ של אפליקציות ענניות לקח את מרחב הזהויות למקומות אחרים שלא היו ידועים (ובחלקם עדיין אינם), והאינטגרציה בין סביבות שונות (אפליקציות, ספקי ענן, וורקלואדים ועוד) קיימת אפילו במצבים בהם אין כלים ובקרות שיודעות לזהות את המקומות החשוכים.
ריבוי עננים ואינטגרציה עם אפליקציות ענניות גרמו למצב של דירקטורי מרובים שאין להם בהכרח חיבור לגורם אחד (IDP) שמנהל את כלל הזהויות והגישה. בסביבות רבות ישנו מצב שבו ישנו דירקטורי אחד או יותר שעובד באופן עצמאי ושאינו מחובר לספק ניהול גישה וזהויות.
מכאן זה לוקח אותנו למקום שבו אנו צריכים להגן על מצבים של זהויות מולטי ענניות והיברידיות, כאשר הזהות היא ניידת ויכולה לנוע בין איזורי זמן שונים, סביבות שאינן ארגוניות, מצבים שמתחברים מכל פינה ושאר מצבים. מכאן מוצרים תריסירי פערים בזהויות ומענה אבטחה מינימלי.
ספק ניהול זהויות וגישה אינו פתרון אבטחה, ולכן חשוב לדעת כי למרות שאנו שואפים לחבר את כלל הזהויות לספק ניהול זהויות וגישה אחד, ולעבוד עם גורם אחד שמנהל את כלל הזהויות, עדיין צריך לסגור פערי אבטחה. פתרון הוליסטי שנוגע לרוחב ולעומק בכלל הזויות ורכיבי המשנה ועונה למצבים רבים, הוא פתרון ITDR.
בחינה מחדש של IAM
האם IAM הוא מענה אבטחה? כאמור, לגמרי לא. מה שכן חדש הוא ההכרה בכך שכלי IAM אלה הם תשתית זהות וגישה בלבד, ולא אבטחה!!! יתר על כן, אפשר לראות בדוחות מחקר רבים שתוקפים מתוחכמים מתמקדים באופן פעיל בתשתית ניהול זהויות וגישה (IAM), ולכן צריך לאמץ ולפתח דרכים להגן גם על תשתית זו.
בשנים האחרונות ארגונים השקיעו מאמצים ניכרים בשיפור יכולות IAM, אך חלק גדול ממנו התמקד בטכנולוגיה לשיפור אימות ודלגציה של משתמשים, מה שלמעשה מגדיל את שטח התקיפה. בעוד שנעשתה עבודה מאומצת בהצבת כלים שמטרתם לפעול בצורה מאובטחת יותר עם הזהויות והגישה שלנו, עם כלים כמו אימות, התוקפים מוצאים דרכים לערער את המערכות האלה ולהשתמש בהן כדרך שלהם להגיע עמוק לתוך המטרות שלהם.
מקרים מוכרים מהשנים האחרונות הם מקרים בפרופיל זהויות גבוה. הראשון במקרה הוא SolarWinds שבו תוקפים ניצלו מצב מסוים בכדי לחטוף Active Directory מקומי ולנצל סביבות היברידיות. מקרה נוסף הוא, המקרה של Okta שבה קבוצת Lapsus פגעה בספק צד שלישי והשתמשה בגישה זו כדי לחדור לסביבת לקוחות של Okta, וזכתה לכמויות פסיכיות של גישה.
כלי IAM יכולים להיות חזקים ושימושיים להפליא, אבל הם יכולים גם להיות נקודת כשל אחת ענקית במידה והם נפגעים. עקרון בסיסי של אבטחה אומר לנו שאנחנו לא צריכים את אותה מערכת שמנהלת את תשתית הזהויות להיות גם זאת שמנטרת ומאבטחת את הזהויות.
למי שעובד עם ספקי זהויות יודע שישנו פגם מרכזי בכלי IAM והוא שיש להם נראות מוגבלת וחלקית. למשל, ספק זהויות (IDP) כמו Okta יראה רק את הזהויות שנמצאות בדירקטורי שלו ואם עוקבים רק אחר זהויות מהצד של IDP, ניתן לראות רק מחצית מהתמונה של הרשאת גישה.
מה לגבי מבט על הנכסים בכדי לראות למי יש הרשאות גישה אליהם? ייתכן שיש מצבים של משתמשי IAM מקומיים בענן של AWS? או במקרה של אפליקציות/מערכות שמאמצות את המודל של ״הבא זהות משלך״. במצב כזה, משתמשים פנימיים או חיצוניים קיימים עם גישה, ולעיתים קרובות אין לנו מושג שהם שם ומה פעולותיהם.
הרשאות גישה יכולות להיות התשובה לשאלה מה יכולה זהות, אדם או מכונה, לעשות לאחר אימות? לאילו נכסים הם יכולים לגשת? איזו רמת גישה (קריאה, כתיבה, ניהול וכו’) תהיה להם?. הרשאות גישה אלה הן הקשר בין הזהות לבין האפליקציות והרכיבים שבהם הזהות מקיימת אינטראקציה עם הנכסים שלהם. ההבנה למי יש גישה למה וכיצד הוא משתמש בהרשאות אלה היא קריטית לפעולה מאובטחת.
זהות במרחב הישן-חדש
למעלה משני עשורים של טכנולוגיות, מכונות, התקנים ניידים, מחשוב ענן, ניידות ומשתמשים שעובדים בצורה מרוחקת, שהואצו עוד יותר על ידי מגיפת COVID-19 – כל אלה שחקו את היקף אבטחת הרשת המוכרת. עובדה מוכרת היא של יוזרים אשר ניגשים לשירותי צד שלישי מתוך מכשירים אישיים ומרשתות פרטיות וכאן ארגונים צריכים לדמיין מחדש כיצד לאבטח את הגישה.
זהות מתוארת כהיקף בעל סיכון גבוה מכיוון שגם אם אפליקציות, תקשורות ורשת, נקודות קצה וכל המכשירים האחרים מאובטחים ומכוסים ברמה מקסימלית, תוקף זקוק לגישה רק לחשבון מורשה אחד כדי להיות מסוגל לסכן את כלל המשאבים בארגון.
מצד אחד זהות היא סיכון ישן ומוכר בין עשורים, אך הענן נתן לסיכון הזה של זהות בוסט מחודש כי המתיחה של זהויות למספר סביבות ענניות, והשילוב של אפליקציות ענניות גרם למשתמש לאמץ מספר זהויות שונות בכל מערכת. מנהלי אבטחת מידע מתקשים בתשובה למענה של שאלות כמו, כמה זהויות יש למשתמש ממוצע? האם כלל זהויות נמצאות במקום אחד? כמה דירטקורי מחוברים לספק זהות בארגון? מהי רמת הנראות של זהויות? תמיד יש פערים.
הנקודות המוזכרות מעלה יכולות להיות מוכרות אבל חשוב להבין כי הענן גרם לנקודת מפנה מהותית בהגנה על זהויות, וכיום הבנה על זהויות מתייחסת לאובייקים בעלי דופק ואובייקטים דוממים וכל אובייקט שיכול להשפיע על מערך הגנת זהויות.
מבט כללי מאוד על אובייקטים מסויימים שנמצאים בעננים של Azure ושל AWS. מודל הרשאות ופוליסי שונה בין סוגי אובייקטים ומודל הזדהות ואימות.
התרשים מתוך מתוך האתר של ermetic
זהות היתה ונשארה נקודת התורפה
על פי NIST, פגיעות היא “חולשה במערכת מידע או ביישום שעלולים להיות מנוצלים או מופעלים ע״י גורם מסוכן”, ואשר חל על האופן שבו תוקפים מנצלים בדרך כלל זהויות שאינן מנוהלות, אינן מוגדרות וחשופות. כאמור, זהויות הפכו לסיכון הארגוני הגדול ביותר.
מערכת לניהול זהויות וגישה (IAM) תוכננו לאכוף את עקרון הפריבילגיה הפחותה, אך גם מבקשות למזער את החיכוך לאחר אימות המשתמש. מטרות שונות מאוד אלה הפכו את זה הרבה יותר קשה לזהות כאשר תוקף מסכן ומשתמש בפרטים (קרדס/אישורים) של משתמש לגטימי. כתוצאה מכך, תקיפות שמקורן בהשתלטות על חשבונות (ATO) הפכו לווקטור תקיפה חזק ומוביל, וזאת, למרות הפריסה של ניהול חשבונות מורשים (PAM), אימות רב-גורמי (MFA) ופתרונות אחרים לניהול זהויות וגישה (IAM) שנועדו להגן על זהויות מפני ניצול של שחקנים ותוקפים.
ישנן טכניקות רבות שבהם תוקפים משתמשים כדי לקבל גישה לחשבון, ולעיתים קרובות ממנפים כלי תקיפה בקוד פתוח. ע״י פגיעה בזהויות בדרך זו, הם מסוגלים בקלות רבה יותר להסתיר את פעילותם ״שלכאורה לגטימיות״ ולעבור מהר יותר את שלבי ההתקפה לפני שהם משלימים את הפעולה הסופית.
בנוסף לכך, מתקפות כופר ממנפות לעתים קרובות קרדס שנגנבו במתקפת פישינג או שנרכשו ברשת האפלה כדי לבסס גישה ראשונית. לאחר, מכאן, התוקפים משתמשים במגוון כלים, כגון Mimikatz ושאר כלים מובנים, כדי להסלים הרשאות, ומשם לאסוף/לנצל אובייקטים נוספים ומורשים.
סוגים של סיכוני זהות
סיכוני זהות הניתנים לניצול קיימים בכל ארגון ובקצב של אחד מכל חמש יוזרים. הגורמים להיותן של זהויות פגיעות נחלקים לשלוש קטגוריות: זהויות לא מנוהלות, מוגדרות באופן שגוי וכאלה שהן חשופות.
זהויות לא מנוהלות
- אובייקטי Services – זהויות שאינן מנוהלות ע״י PAM ומשום שהן לא התגלו במהלך היישום ומשום שלא כל היישומים תואמים ל PAM, כגון, יישומים מדור קודם שעלות המודרניזציה עבורם כרוכה בעלויות.
- אובייקטי מערכת מקומיים – הרשאות ניהול מקומיות מאפשרות מגוון בקשות IT, אך לעתים קרובות אינן מתגלות או נשכחות לאחר יצירתן, ומותירות אותן ללא ניהול.
- חשבונות מורשים רבים אחרים אינם מנוהלים ע״י פתרונות PAM או MFA מכיוון שהם נותרו ללא גילוי במהלך הפריסה. מקרה זה נפוץ מאוד בענן.
זהויות מוגדרות באופן שגוי
- אובייקטי צללים – המורכבות של קבוצות זהויות מקשות מאוד לראות את הזכויות והזכאויות המלאות של כלל הזהויות, מה שגורם לחשבונות לקבל הרשאות מוגזמות שלרוב אינן נדרשות.
- הצפנה חלשה וסיסמאות – זהויות שהוגדרו למנף הצפנה חלשה או חסרה או שאינן אוכפות מדיניות סיסמאות חזקה.
- חשבונות Services – זהויות עם זכויות גישה מורשות עשויות להיות מוגדרות באופן שגוי כדי לאפשר באופן שגוי כניסה אינטראקטיבית על גורם אנושי.
זהויות חשופות
- אישורים מסוג Cached credentials – פרטי חשבון ואישורים המאוחסנים בדרך כלל בזיכרון של נקודות קצה, ברישום ובדיסק, שם הם מנוצלים בקלות ע״י כלי תקיפה נפוצים.
- Cloud Access Tokens – טוקן גישה בענן המאוחסנים בנקודות קצה הם אמצעי נפוץ עבור תוקפים כדי לקבל גישה לנכסי ענן.
- ניצול סשנים – הפעלות יישומים מרוחקים עשויות להיות סגורות בצורה לא נכונה, מה שמאפשר לתוקפים למנף סשן פתוח ואת ההרשאות, במידה רבה ללא הסיכון של זיהוי.
חשוב לציין שכל זהות נתונה יכולה להיות פגיעה בדרכים רבות, ופרט בשלושת הקטגוריות הפגיעות שהוזכרו. זהויות אלה חושפות לעתים קרובות ארגונים לרמה הגבוהה ביותר של סיכון.
לדוגמה, זהות יחידה יכולה להיות מוגדרת באופן שגוי כך שתחזיק בזכויות Shadow Admin, מה שמטבעו גורם לזהות זו להיות לא מנוהלת בשל היעדר מודעות IT שבדרך כלל יפעיל את הרמה הנוספת של הגנת ניהול גישה המיועדת לחשבונות עם הזכויות שהיא מחזיקה (PAM, MFA וכו’), וניתן להשתמש באותה זהות בדרכים שגורמות לאישור שלה להיחשף.
שטח התקיפה עובר לסביבת הענן?
סביבות מקומיות של Active Directory מחוברות אל סביבת Azure AD או שווה ערך בספק זהות אחר, וככל שיותר ארגונים מאמצים סביבות ענן היברידיות ניתן לראות שכובד המשקל עדיין נמצא עדיין בסביבת Active Directory. לראייה, מתקפת SolarWinds התגלתה כדאגה עליונה עבור ארגונים רבים. כדי לחזק את העובדה הזאת מהשטח ישנה הלימה של Gartner והיא, שרק 3% מהארגונים יעברו לחלוטין בסביבת Active Directory אל סביבת Azure AD עד שנת 2025.
אבל ההגנה על מערכות Active Directory היברידיות אלה נמצאת בראש סדר העדיפויות: היכולת החשובה ביותר למניעת התקפות בארגונים היא ניטור רציף של פגיעויות Active Directory וכן Azure AD, והתצורות בעלות הסיכון שהן חושפות. הדוח מציין כי רק אחוז קטן ממנהלי אבטחת המידע ציינו שהם “בטוחים מאוד” שהם יכולים למנוע או להגיב במהירות לתקפיות Active Directory.
מהו ITDR
אם כך מה אנו יכולים לעשות בפערים האלה שנוצרו בשנים האחרונות? האם יש מקום לעוד כלי, פרייוורק ושאר מתודולוגיות? שזה מגיע לזהויות, כן! כמו שאמרתי לפני שנים: ברגע שיש חיבור לענן ומתקיימת ניידות של יוזרים, סביבת הפרימטר היא היוזר והזהות שלו. מכאן זה לוקח אותנו לאמץ מודל / פתרון / מתולוגיה של ITDR.
האנלוגיה הקרובה ביותר ל ITDR היא זיהוי איומים ותגובה של AD TDR שתומכים בדרך כלל בשילוב כלשהו של המאפיינים הבאים:
- ניתוח נתוני תצורה, מדיניות וזהות להערכת מצב האבטחה של זהויות
- ניהול נתיבי תקיפה וניתוח השפעה לאורך מסלול התקיפה
- ניקוד סיכונים ותעדוף
- ניטור בזמן אמת של התנהגויות זמן ריצה עבור אינדיקטורים נפוצים
- למידת מכונה וניתוח לזיהוי התנהגויות ואירועים חריגים
- מענה ותיקון אוטומטי ותגובה לתקריות ואירועים
- ממשקים לניתוח תקריות ואירועים
- אינטגרציה עם כלי אוטומציה ותגובה (SOAR)
- שילוב עם פתרונות MFA כדי לספק אימות מתקדם בתגובה לאירועי סיכון
נוכחותם של AD TDR וכן ITDR מצביעה על כך שזהויות ראויות לאותה רמת ניהול ובקרה שארגונים החילו על מרחבים ושטחים אחרים – אם לא יותר. זה חשוב עכשיו יותר מתמיד מאז שזהויות הפכו לווקטור התקיפה השולט במתקפות סייבר. כפי שקרה בכל ההיבטים האחרים של סיכוני סייבר, יש לנהל את סיכון הזהות באמצעות בקרות מניעה ותחקור כאחד.
חשוב להדגיש כי ITDR מלא צריך לכלול יכולות מניעה המגלות ומתקנות פערים במצב הזהות של הארגון כדי למנוע ניצול זהות, כמו גם יכולות תחקור המתריעות במדויק על אינדיקטורים של פגיעה בזמן שהם מתרחשים.
בקרות מונעות של ITDR
ITDR צריך לשלוט במניעה של גילוי ותיקון סיכונים, איומים ופגיעויות של זהויות לפני שגורם צד שלישי ינסה לנצל אותן.
בדומה לגישות מסורתיות לניהול פגיעויות וסיכונים, יכולות הגילוי של ITDR מאפשרות לארגונים למלא את הסיכונים של נכסי הזהויות שלהם, ולכן, ITDR צריך לספק גילוי זהויות אוטומטי, רציף ומקיף הכולל נראות לחשבונות מורשים לא מנוהלים, לא מוגדרים וחשופים.
נראות זו מאפשרת קבלת החלטות יעילה של צוותי סיסטם, צוותי אבטחה וכן צוותי תגובה ומחקר כדי לצמצם סיכונים אלה בפריסות הגדולות והרב-שלביות של מערכות ניהול זהויות שונות, כגון IGA, PAM, MFA, SSO ואחרות. למעשה, סריקה רציפה זו לאיתור בעיות נדרשת לניהול יעיל של כל מערכת מורכבת, וניהול זהויות אינו יוצא דופן.
בקרות ITDR
כאמור, מטרת ITDR היא לשלוט במרחב הזהויות וברגע שיש אינדיקציה לתוקף או שחקן פנים ארגוני המנסה לסכן או למנף זהות באופן שיוצר סיכון לארגון. יש צורך בבקרות כדי להפחית סיכונים שלא ניתן למנוע, כך שהצוותים יוכלו לקבל התראה ולהגיב במהירות במידת הצורך במקרה של התקפה.
זיהוי מדויק של סיכוני ואיומי זהות לפני השלמת תקיפה הוכח כקשה להשגה מכמה סיבות:
משך זמן לזיהוי מתקפות – זמני השהייה של התוקפים בסוגי תקיפות רבים, משתנים בין סביבות שונות ובפרט בענן. ע״י העברת המיקוד לפשרה של זהויות לביצוע חדירות למערכת, התוקפים מצליחים לנוע הרבה יותר מהר דרך שלבי ההתקפה שלהם כדי לבצע גילוי, לנוע לרוחב, לאסוף נתונים ולהשלים את מסלול התקיפה.
יעילות מופחתת של בקרות אבטחה קיימות – ככל שהמיקוד של התוקפים עבר לניצול זהויות כמטרה העיקרית שלהם, התוקפים זונחים לעיתים טכניקות קודמות רבות, מה שהופך את כלי האבטחה לטכניקות אלה ללא רלוונטיים. התוקפים גם הוכיחו באופן קבוע שברגע שהם מסלימים את ההרשאות שלהם, הם מסוגלים להשבית בקרות אבטחה, לעוור פתרונות אבטחה שלמים כולל סוכני נקודות קצה.
חוסר יכולת לזהות במדויק פגיעות – חתימות וניתוחים מבוססי התנהגות (לבד) של חשבונות מורשים מוכיחים שמדובר בפתרון שאינו יעיל במקרים רבים ומתקשים בזיהוי מדויק של הסלמה בפריבילגיות זדוניות ותנועה לרוחב, כפי שמעידה העלייה המתמשכת בהתקפות מוצלחות. היעדר עקביות מספקת בהתנהגויות המקובלות של חשבונות מנהלים מורשים (אנטרופיית נתונים) הוביל לקשיים בבניית קווי בסיס יעילים הנדרשים כדי למזער התראות חיוביות כוזבות ושליליות כוזבות.
לפיכך, יש צורך בזיהוי מדויק יותר של חשבונות מורשים שנפרצו. למשל, הגישה הדטרמיניסטית של הזרקת תוכן מטעה כדי לפתות תוקפים, מציעה אלטרנטיבה לניתוח התנהגותי לזיהוי של הסלמת הרשאות ותנועה לרוחב. כאשר היא מיושמת היטב (אינו מימוש פשוט ליישום), גישה זו מאמצת גישה ישנה של מלכודות שרק תוקף יתקשר איתם, בהתבסס על הבנת הטכניקות והכלים של התוקף, ואינה משאירה שום רמזים לתוקף להאמין שהם לכודים.
הגישה הנוספת של הורדת הרשאות לאובייקטים שאינם נדרשים לכך תופסת תאוצה אך עדיין אינה מיושמת במצבים רבים בגלל חוסר המודעות והנראות באובייקטים רבים, לרוב אובייקטים דוממים בעלי הרשאות גבוהות שאינם נדרשים לכך.
מה מייחד את ITDR?
שאלה נפוצה סביב ITDR היא במה הוא שונה ממערכות אחרות לזיהוי איומים או לאבטחת זהויות שארגונים כבר משתמשים בהן כיום? האם זה עוד מאותו דבר? התשובה הפשוטה היא לא, אבל בואו נציין עוד מספר נקודות.
כלים קיימים להגנה על זהויות, כגון IAM, IGA ו- PAM, מתמקדים בעיקר בהרשאות ובאימות, ומבטיחים שלאנשים הנכונים תהיה גישה לקבצים ולאפליקציות הדרושים להם. בשנים האחרונות, ארגונים השקיעו מאמצים רבים בשיפור יכולות אלה, תוך אימוץ אפליקציות ומערכות מתוחכמות יותר ויותר לניהול זהויות וגישה באמצעות אימות.
במקרים מסוימים, IAM עלול להוות סיכון אבטחה משמעותי כאשר משתמשים בו בבידוד – הוא עלול להפוך לנקודת כשל יחידה אם הוא נחשף לסכנה. כאן ITDR נכנס לתמונה. ITDR עוסקת למעשה בהפרדת חובות אלה כדי שנוכל לאבטח את תשתית ה- IAM שלנו ולהבטיח שהיא פועלת כמתוכנן.
כיצד ITDR מתמודד עם (EDR) זיהוי ותגובה של נקודות קצה? כלי EDR פועלים באופן דומה ל ITDR אך בסופו של דבר מתמקדים בדברים שונים. כלומר, EDR מחפש תקיפות על נקודות קצה, בעוד ITDR מחפש תקיפות על זהויות.
לדוגמה, כאשר EDR מזהה התקפה, הוא יכול לבודד את המערכת כדי להגביל פעולות ותנועות בכדי לעצור את מסלול התקיפה. לעומת זאת, מערכות ITDR מוסיפות לעתים קרובות שכבה נוספת של אבטחה ע״י הוספת אפשרויות תגובה לבידוד משתמש או גישה. פתרונות אלה יכולים גם להגביל את התנועה לרוחב דרך הרשת.
עם זאת, נכון גם שפתרונות ITDR עשויים להשתנות בהתאם לדרישה וצורך. בהתחשב בכך, התכונות שצריכות להיות כדי להיחשב כ ITDR:
- לנטר ולזהות פעילות זדונית של זהויות והרשאות.
- לזהות תצורות שגויות הקשורות לזהות.
- לחקור איומי זהות באמצעות פרטי משתמש הקשריים.
- לזהות חריגת משתמש מהפעילות האופיינית שלו.
- בעקבות הזיהוי תגיע התגובה.
ITDR – לפני, במהלך ואחרי התקפה
טיפול בהגנה על מערכות זהויות היא עדות לעלייתו של Active Directory לצד Azure AD (גם היברידי) כמטרה עיקרית עבור תוקפים – המנוצלים ב 9 מתוך 10 מתקפות סייבר. ארגונים מודאגים מהאתגרים של הגנה על סביבות זהות היברידיות לאורך כל מחזור החיים של ההתקפה. בעת הערכת פתרונות ITDR, צריך לתת עדיפות למניעה, זיהוי, תיקון אוטומטי והתאוששות ממתקפות.
שלבים באימוץ ITDR
לפני שמחפשים כלים להגנה על תשתית הזהויות, מומלץ לזהות את הפערים בסביבה ע״י ביצוע שלושת השלבים הבאים:
- הערכת מצב האבטחה של ״זהות תחילה״.
- הערכת סיכוני ואיומי זהות.
- יצירה, שיפור והתאמת מקרה ותגובה.
זהות תחילה
בשלב ראשון צריך לבדוק את רמת הסיכון של זהויות בסביבה היברידית ע״י סקירת הרשאות גישה בפועל וזיהוי חשבונות מסוג Stale, הרשאות יתר ונתיבי הסלמה של הרשאות. ריבוי הזהויות והנכסים יחד עם האופי הדינמי של סביבה היברידית עם הענן מובילים לעיתים קרובות לגישה נסתרת, לא מנוצלת ומוגזמת.
לדוגמה, למעלה מ 95% מהחשבונות בענן זכאים לפחות מ 3% הרשאות שהם מקבלים, מה שמגדיל מאוד את שטח התקיפה עבור פריצות לחשבונות.
סקירת כל שירותי הענן והיישומים לגישה לא חוקית יכולה לגזול זמן רב ולהיות מועדת לשגיאות. פתרונות CIEM (ניהול זכאות לתשתית ענן) יכולים לסייע בזיהוי הרשאות יתר. בנוסף, כדאי גם לסקור יישומי ענן וכלי IAM כדי לזהות גישות שונות מיציאה חלקית, כמו גם הסלמות הרשאות בין מערכות.
הערכת איומי זהות
בנוסף, צריך לסקור את התצורות והפריסות של כלי IAM /IDP/SSO/IGA / PAM כדי לזהות סיכונים ואיומים כגון סיסמאות חשופות, התחזות למשתמשים ושינויים לא מורשים. אפילו פריסות בשלות של פתרונות IAM עשויות להיות חשופות לאיומי זהויות עקב תצורות שגויות או אפילו לפי תכנון.
הערכה תספק רמת חשיפה ותציין את התעדוף וההיקף של אימוץ ITDR להגנה מתמשכת. זיהוי המקום שבו נחשפים תסייע גם לקבוע מי צריך להיות הבעלים של ITDR בארגון.
מקרה ותגובה
כלי SIEM, SOAR ו XDR מטפלים בתגובה לתקריות עבור תשתית האבטחה. רוב הסיכויים שחלק מהנהלים הקיימים יכולים לשמש גם לסיכוני זהות ואיומים. לכן, כדאי לסקור את הפלייבוקים הקיימים כדי לזהות מה יתאים עבור אירועי זהות וגישה ומה דורש התאמות, או ליצור פלייבוקים חדשים. פתרונות ITDR מסוימים יספקו גם יכולות תיקון אוטומטיות, כגון השבתת גישה והמלצות לפתרון, כגון מעבר בין פרוטוקולים. החומרה וההשפעה הפוטנציאלית של תקריות יקבעו את הדחיפות והאוטומציה של הפלייבוק.
לסיכום, אבטחת זהויות צריכה להיות בראש סדר העדיפויות בנוף איומי הסייבר של היום. איתור יעיל של איומים מבוססי זהות ותגובה בעולם שבו תוקפים עוקפים ללא הרף כלי אימות והרשאה. ITDR בצורה הנכונה יכול למלא תפקיד מכריע בהגנה על מערכות הזהות.
