פישינג היא כבר מזמן אחת הדרכים הטובות ביותר להשיג גישה לארגון יעד. פעם זה לא היה ככה. בימים הראשונים של אבטחת המחשב, ניצול הקוד הרחוק (RCE) היה השיטה המועדפת להשגת גישה, מכיוון שהוא לא דרש אינטראקציה של משתמשים. למעשה, אם משהו דרש אינטראקציה עם המשתמש, זה לא נחשב לאיום רציני. שיטות אבטחה טובות יותר החלו לתפוס אחיזה, ושיטת הגישה של RCE הפכה להרבה יותר מאתגרת. והתברר, לגרום למשתמשים לקיים אינטראקציה היה קל יותר ממה שאי פעם דמיינו.
אותו מחזור התחיל לחזור על עצמו עם יעדים מקומיים. ארגונים החלו להתקדם באבטחת הרשתות הפנימיות שלהם מפני שימוש בזיהוי ותגובה של נקודות קצה (EDR), וטכנולוגיות אחרות מצוידות יותר לזיהוי תוכנות זדוניות ותנועה לרוחב. בעוד שהתקפות הופכות קשות יותר, זו עדיין לא אסטרטגיה לא יעילה עבור תוקף. פריסת תוכנות כופר וצורות אחרות של תוכנות זדוניות היא עדיין תוצאה נפוצה.
מדוע תשתית הענן שלך היא יעד מוביל להתקפות פישינג
הענן נתן לדיוג גבול חדש לגמרי לתקוף, ומתברר שהוא יכול להיות מסוכן מאוד. סביבות SaaS הן מטרות בשלות להתקפות דיוג ויכולות לתת לתוקף הרבה יותר מגישה לאימיילים מסוימים. כלי אבטחה עדיין מבשילים בסביבה זו, מה שמציע לתוקפים חלון הזדמנויות שבו שיטות כמו התקפות פישינג יכולות להיות מאוד יעילות.
התקפות דיוג מכוונות למפתחים ושרשרת אספקת התוכנה
כפי שראינו לאחרונה, ל-Dropbox היה תקרית עקב מתקפת פישינג נגד מפתחיה. רימו אותם נותן את אישורי Github שלהם לתוקף באמצעות אימייל דיוג ואתר מזויף, למרות זאת אימות רב-פקטורי (MFA). מה שעושה את זה מפחיד הוא שזה לא היה רק משתמש אקראי ממכירות או פונקציה עסקית אחרת, זה היה מפתחים עם גישה להרבה נתונים של Dropbox. למרבה המזל, נראה שהיקף התקרית לא משפיע על הנתונים הקריטיים ביותר של Dropbox.
GitHub, ופלטפורמות אחרות בתחום האינטגרציה הרציפה/פריסה רציפה (CI/CD), הן "תכשיטי הכתר" החדשים עבור חברות רבות. עם הגישה הנכונה, התוקפים יכולים לגנוב קניין רוחני, להדליף קוד מקור ונתונים אחרים, או התנהגות התקפות שרשרת האספקה. זה הולך אפילו רחוק יותר, מכיוון שלעתים קרובות GitHub משתלב עם פלטפורמות אחרות, שאותן התוקף עשוי להיות מסוגל לסובב. כל זה יכול לקרות מבלי לגעת אי פעם ברשת המקומית של הקורבן, או ברבים מכלי האבטחה האחרים שארגונים רכשו, מכיוון שהכל הוא תוכנה כשירות (SaaS) ל-SaaS.
אבטחה בתרחיש זה יכולה להיות אתגר. כל ספק SaaS עושה את זה אחרת. הנראות של לקוח לגבי מה שקורה בפלטפורמות הללו היא לרוב מוגבלת. GitHub, למשל, נותן גישה רק ל-Audit Log API שלו במסגרת התוכנית הארגונית שלו. קבלת נראות היא רק המכשול הראשון שצריך להתגבר עליו, הבא יהיה ליצור תוכן זיהוי שימושי סביבו. ספקי SaaS יכולים להיות שונים למדי במה שהם עושים ובנתונים שהם מספקים. תידרש הבנה קונטקסטואלית של אופן הפעולה שלהם כדי לבצע ולתחזק את האיתורים. ייתכן שלארגון שלך יש הרבה פלטפורמות SaaS כאלה בשימוש.
כיצד מפחיתים סיכונים הקשורים לדיוג בענן?
פלטפורמות זהות, כמו Okta, יכולות לעזור להפחית את הסיכון, אבל לא לגמרי. זיהוי כניסות לא מורשות היא ללא ספק אחת הדרכים הטובות ביותר לגלות התקפות דיוג ולהגיב אליהן. זה קל יותר לומר מאשר לעשות, שכן התוקפים תפסו את הדרכים הנפוצות לזיהוי נוכחותם. שרתי פרוקסי או VPN משמשים בקלות כדי לפחות שנראה שהם מגיעים מאותו אזור כללי כמו המשתמש כדי להביס זיהוי מדינות או נסיעות בלתי אפשריות. ניתן ליישם מודלים מתקדמים יותר של למידת מכונה, אך אלה עדיין לא אומצו באופן נרחב או הוכחו.
זיהוי האיומים המסורתי מתחיל להסתגל גם לעולם ה-SaaS. ל-Falco, כלי פופולרי לזיהוי איומים עבור מכולות וענן, יש מערכת פלאגין שיכולה לתמוך כמעט בכל פלטפורמה. צוות Falco כבר פרסם תוספים וחוקים עבור Okta ו-GitHub, בין היתר. לדוגמה, הפלאגין GitHub יש כלל שמפעיל אם מתחייבים כלשהם מראים סימנים של כורה קריפטו. מינוף הזיהויים המיועד לכך הוא דרך טובה להתחיל בהכנסת הפלטפורמות הללו לתוכנית זיהוי האיומים הכוללת שלך.
פישינג כאן כדי להישאר
פישינג, והנדסה חברתית בכלל, לעולם לא יישארו מאחור. זו הייתה שיטת תקיפה יעילה במשך שנים, והיא תהיה כל עוד אנשים יתקשרו. חשוב להבין שהתקפות אלו אינן מוגבלות לתשתית שבבעלותך או שאתה מנהל ישירות. SaaS נמצא בסיכון במיוחד בגלל חוסר הנראות של רוב הארגונים למה שקורה בפועל בפלטפורמות האלה. לא ניתן למחוק את האבטחה שלהם כבעיה של מישהו אחר, מכיוון שדוא"ל פשוט ואתר מזויף הוא כל מה שצריך כדי לקבל גישה למשאבים האלה.
