ניטור זהויות: מה שטוב ל-LAN לא עובד בענן

בשנים האחרונות חלה עלייה משמעותית במתקפות בסביבות ענן, על זה ודאי שמעתם. אבל האם ידעתם שביותר מ-75% מאירועי הפריצה התוקפים השתמשו בחשבונות תקפים (Valid Account) שנגנבו? כדי להתמודד ארגונים צריכים לשנות גישה, לפחות באופן זמני

כתב אורח
29.9.24

מקור: dreamstime

מאת משה פורמן, מנהל מחלקת המחקר של חברת CyTwist

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

אך למרות הקדמה והידע הרב, בחדשות עדיין מרבים לדווח על קבוצות תקיפה מתוחכמות (APT) שמצליחות לגרום נזקים חמורים. בשנה וחצי האחרונות נרשם גידול של כ-100% במתקפות מבוססות זהות בסביבות ענן; השימוש בזהויות באירועי אבטחת ענן נמצא בגידול מתמיד, עם יותר מ-75% מאירועי הפריצה לסביבות ענן שנגרמו כתוצאה משימוש בזהויות תקפות שנגנבו (Valid Accounts). איך זה קרה? פושעי סייבר הסתמכו במידה רבה על חשבונות תקפים גנובים כדי להשיג גישה ראשונית, והשיגו אותם בדרכים שונות כגון דליפות מידע, גניבת מידע, תקיפות הנדסה חברתית, גניבת סיסמאות, שירותי איפוס סיסמאות לא בטוחים ועוד, מה שהביא לגידול אקספוננציאלי בהתקפות אלה.

מנגנוני AI עדיין לא הוכחו כיעילים

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

במעבר לסביבות ה-Cloud, עולם הסייבר שכפל חלק מהשיטות המוכרות מסביבות ה-LAN, מתוך מחשבה שאם יש משהו שעובד בסביבת On-Prem, הוא אמור להיות יעיל גם בסביבת הענן. אולם, המציאות שונה, ובשנים האחרונות אנו עדים לכך שרוב תקיפות ה-Data Breach מתבצעות בסביבות הענן. השיטה המסורתית של חסימת גניבת מידע דרך ניטור לוגים ובקרת גישה באמצעות ה-FW אינה אפקטיבית בסביבת הענן, שבה כל הגישה מתבצעת דרך הרשת, מה שמאפשר לפעולות התוקף להראות לגיטימיות ואין שום פעילות מחשידה בפעולותיו של התוקף.

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

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

מקור: dreamstime

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

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

האלמנט הזדוני

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

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

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

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

No comments found.

מישרות פתוחות

אולי פיספסת

Geektime INSIDER

זה המקום להכיר את החברות, המשרדים וכל מי שעושה את ההייטק בישראל (ויש גם מלא משרות פתוחות!) #תוכן מקודם