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

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

כידוע, שכבת הדואר צריכה לקבל את תשומת הלב הראויה, ולהיות חלק מפעולות פרואקטיביות של היומיום בהגנת הסייבר, כן של היומיום, ולא השבועי! בסביבות שאני דוגם, מקשיח ועוקף כחלק מפעילויות שגרתיות, ישנם כל כך הרבה מקרים של מיסקונפיגורציה, מיסאינפורמציה וחוסר תשומת לב לאפשרויות שניתן לאכוף עם הכלים של Exchange Online Protection יחד עם Defender for Office ואף לשלב עם הממשקי XDR ואקוסיסטם רחב יותר, למשל, Ironscales.

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

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

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

הקשחת Exchange Online Protection

תחילה, נבצע הגדרות ברכיב המובנה של Exchange Online הלא הוא Exchange Online Protection שאינו מגיע מוקשח אפילו לא ברמה הבסיסית, ולכן נתחיל מאותן פעולות רגילות ונבצע הגדרה של הרשומות המוכרות ולאחר מכן נתאים אותן אל כל אותן הגדרות של Microsoft 365.

אומנם המנגנון של SPF, או DKIM וכן DMARC מאוד ישנות אבל במידה ומגדירים אותן ברמת רשומות DNS ולאחר מכן מבצעים התאמה אל מול הגדרות של Exchange Online Protection וכן Defender for Office אנו מקבלים חסימה גבוהה ומיידית של ספאם ופישינג.

SPF – מנגנון לזיהוי תעבורת דואר ממקור לא אמין, מטרתו העיקרית של מנגנון SPF הוא לוודא את זהות השולח ע”י מאפיינים שונים בין היתר:

• כתובת מול רשומת SPF (מבוסס TXT)
• דומיין אשר שולח את הדואר
• פרטי נמען עם ערכים, כגון: Mail From

בשירותי הדואר השונים ניתן להגדיר רשומת TXT לטובת SPF וצריך לשים לב לתרחישים בהם ישנם מצב היברידי או גורם חיצוני שמבצע סינון למיילים (third party emsil ecurity).
כמו שירותי ענן אחרים כך גם בשירות Exchange Online ישנם מספר תקנים כגון HIPPA שמחייב הגדרת SPF מול הדומיין, בכל המקרים האלה ישנה אינפורמציה רבה לגבי הגדרת SPF מול הארגון.

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

מטרתו העיקרית של DKIM הוא לזהות מהיכן הגיעה תעבורת הדואר ע”י מספר פרמטרים:

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

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

DMARC – בשמו המלא נקרא Domain-based Message Authentication, Reporting and Conformance והוא מנגנון נוסף לזיהוי תעבורת דואר עם התמקדות בפישינג. DMARC בודק הודעה שעברה בהצלחה מול SPF או DKIM ןלאחר מכן מבצע בדיקה מול שדות: Mail from וכן From,  במידה וישנו במייל בעיה שאינו תואם להגדרות DMARC המייל יוגדר כדואר זבל או פישינג ואינו יעבור אל שרתי הדואר, במידה והמייל יהיה תקין בהתאם להגדרות DMARC המייל ימשיך הלאה לשירות הדואר.

מעבר לבדיקה שמנגנון DMARC מבצע בשירות הדואר, מתבצעת בנוסף לכך דיווח לגבי מיילים ותעבורת דואר לא תקינה ובכדי לעבוד עם DMARC צריך להוסיף רשומת TXT בלבד ללא צורך בהגדרות נוספות ברמת שירות Office 365. בהגדרת SPF וכן DKIM אנו צריכים קודם כל להגדיר DNS מול הספק ולאחר מכן נוכל לבצע הגדרה ברמת רכיבי הדואר (EOP/MDO).

הגדרת SPF במצב -all משמעותה Hard Fail והיא תדחה תעבורת דואר ומצבים כאשר SPF אינו מאומת במלואו. למשל, תעביר פריטי דואר לתיקיית Junk או תשים אותם בהסגר.

איך בודקים האם הגדרת DMARC בוצעה בצורה הנכונה? התרשים הבא מסייע הבנה של הרשומות שאנו צריכים להגדרת DMARC כולל הגדרות סף 👇

הגדרת DKIM

בתשתית Microsoft 365 ובפרט בתשתית Exchange Online הגדרת DKIM היא פשוטה בגלל שרוב הדרישות כבר מוגדרת ברמת Microsoft 365 ואנו צריכים להגדיר רשומות DNS, להפעיל את האפשרות ולוודא שהמפתחות הוגדרו בהצלחה. לאחר מכן, אנו בדוקים האם DKIM נכנס לפעולה ברמת בדיקת Header של תעבורת הדואר.

הגדרת Anti-Spam

לצד זה נאנבל את האפשרות של SPF record: hard fail במצב On. במצב כזה, תעבורת דואר שתגיע מתוך דומיינים שאינם מוגדרים עם SPF ואינם מאומתים תקבל תיוג ספאם עם SCL גבוה. כאשר ישנו SCL גבוה לרוב התעבורה עוברת אל תיקיות Junk או Quarantine.

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

הגדרות שמומלץ לבצע ברמת Anti-spam ולשים אותם במצב מופעל (On) ללא יוצא מן הכלל. הגדרות אנטי-ספאם:

• Empty messages – פריטי דואר ריקים שלא מגיעים עם תוכן מקבלים SCL גבוה. לרוב נמצא בשימוש של פעולות Discovery מול תיבות הדואר.
• Embedded tags in HTML – דואר שמגיע עם תיוג embed בתוך HTML מקבל SCL גבוה. דואר מתויג HTML מאפשר להזריק למסמך סאונד, תמונות וכו.
• JavaScript or VBScript in HTML – דואר שמגיע עם JavaScript בתוך HTML עלול להפעיל פעולות מסוימות כולל פעולות מול הזכרון ולא מהדיסק.
• Form tags in HTML – דואר שמגיע עם form משמש ליצירת טופסי אתר, פרסומות דוא"ל ולעיתים דורשות מידע מהנמען.
• Frame or iframe tags in HTML – דואר שמגיע עם תיוג frame או iframe מאפשר הצגת טקסט או גרפיקה.
• Web bugs in HTML – דואר שמגיע עם תיוג object מאפשר לפלאגינים או יישומים לפעול בתוך HTML
• Sender ID filtering hard fail – מאפשר בדיקת SPF עם בדיקת מזהה שולח בכדי לסייע בהגנה מפני כותרות דואר המכיל שולחים מזויפים.

בכל ההגדרות הנ"ל יש לוודא האם תעבורת הדואר תופנה לתיקיית Junk, או לתיקיית Quarantine, או לתיקיית SecOps. הפניות נעשות על סמך דירוג SCL ופוליסי קיים או כזה שהוגדר מראש.

טיפ: מומלץ לשים את כל ההגנות של אנטי-ספאם במצב מופעל (ON) ללא יוצא מן הכלל בכדי לאפשר אכיפה של תיוגים, הקשחת SPF ויתר ההגדרות

הגדרת Anti-malware

בהגדרת Anti-malware נפעיל את האפשרויות הבודדות הבאות:

האפשרות של common attachments filter לפי רשימה מקוסטמת של קבצים שאין צורך בהעברתם אל תיבת הדואר של המשתמשים. רשימת סיומות נוספות:

Python files (“.py”, “.pyc”, “.pyo”, “.pyw”, “.pyz”, “.pyzw”)
Java files (“.jar”, “.jnlp”)
PowerShell files (“.ps1”, “.ps1xml”, “.ps2”, “.ps2xml”, “.psc1”, “.psc2”, “.psd1”, “.psdm1”, “.cdxml”, “.pssc”)
Digital certificates (“.cer”, “.crt”, “.der”)
Third-party apps (“.appcontent-ms”, “.settingcontent-ms”, “.cnt”, “.hpj”, “.website”, “.webpnp”, “.mcf”, “.printerexport”, “.pl”, “.theme”, “.vbp”, “.xbap”, “.xll”, “.xnk”, “.msu”, “.diagcab”, “.grp”)
Microsoft components (“.appref-ms”, “.udl”, “.wsb”).

טיפ: מומלץ להוסיף סיומות קבצים ככל האפשר ולא להסמתך על הדיפולט. 

טיפ: מומלץ לנהל הקשחות ואכיפת פוליסי מתוך ממשק XDR, בקישור https://security.microsoft.com

הקשחות Defender

הקשחת Defender for Office נחלקות למספר חלקים של אנטי פישינג, סנדבוקיסנג וסט הגדרות לפי השלבים המתוארים.

הגדרת AntiPhish

Phishing threshold – מבצע בכל רגי נתון בדיקות על תעבורת דואר שמטרתה לבצע פישינג ומחולקת למספר קטגוריות של Low, Meduim, High. במצב כזה המנגנון האוטומטי של Defender for Office מבצע חישובים שונים (דירוג הדואר, דירוג השולח, האם נצפה ברשת ואחרים) על מנת לתת אינדיקציה לכל תעבורת דואר שהיא, ולכן האפשרויות של Phishing threshold מדורגות לפי מספר רמות כאשר הרביעית שבהן היא האגרסיבית.

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

הגדרות נוספות שהן חלק מתוך Phishing threshold & protection וכאלה שמומלץ להגדיר ולהפעיל אותן הן ההגדרות הבאות:

• Impersonated user protection – מניעת התחזות ברמת משתמש
• Impersonated domain protection – מניעת התחזות ברמת דומיין
• Trusted impersonated senders and domains – החרגת דומיינים ונמענים מסוימים איננה באה בחשבון ולכן מומלץ להשאיר ללא החרגה
• Mailbox intelligence – מבצע למידה של תיבות הדואר והתנהגות משתמש כולל דפוסי דוא"ל עם אנשי הקשר והפרדה בין שולח לגטיטמי לשולח שאינו מוכר
• Mailbox intelligence for impersonations – מבצע למידה של תיבות הדואר והתנהגות משתמש כולל דפוסי דוא"ל מול שולחים שאינם מוכרים מול הנמען ומול הדומיין
• Spoof intelligence – בשונה מהתחזות מוכרת, הספופינג עובד על גבי תאימות מול From אל מול Email Source, וגם כאן נעשות בדיקות מול של שולחים, דומיינים והתאמה בינהם.

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

• First contact safety tip
• User impersonation safety tip
• Domain impersonation safety tip
• Unusual characters safety tip
• Unauthenticated senders symbol (?) for spoof
• Show "via" tag

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

הגדרת Safe Attachment

לאחר שרכיב Exchange Online Protection מבצע את כל אותן פעולות ספציפיות של Anti-Malware נכנס לפעולה הרכיב של Safe Attachment כחלק מתוך Defender for Office. מטרת Safe Attachment היא לבצע סנדבוסקינג על כל קובץ שמגיע ורגע לפני שהוא נוחת בתחנה. כאשר מתבצעת סריקה של Safe Attachment מתבצעים מאחורי הקלעים בדיקות על גבי רכיב ייעודי לכל סריקה, וכל קובץ שנסרק ממשיך בדרכו בהתאם פוליסי שהוגדר, במידה וישנם קבצים המכילים תוכן חשוד הסריקה עלולה לקחת עד 20 דקות, ואם ישנה בעיה בקובץ הוא ייחסם.

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

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

Safe Documents for Office clients – מאפשר סריקה של קובצי אופיס עם המנגנון של Defender for Endpoint במצב של Protected View או במצב שישנו Application Guard for Office. יוזרים אינם צריכים בתחנות קצה את הסנסור של Defender for Endpoint.

לאחר מכן נגדיר פוליסי של Safe attachments שחוסם מראש כל תעבורת דואר שיש בה קובץ עם חשד מסוים. המלצות:

Block – Block current and future messages and attachments with detected malware – מניעת מסירה של הודעות עם קבצים מצורפים שזוהו כחשודות. האפקט גורם לכך שתעבורת דואר תעבור ישירות להסגר. ברירת מחדל היא שרק מורשים יכולים לסקור, לשחרר או למחוק את כל אותן פריטי דואר. בנוסף לכך ייחסמו אוטומטית מופעים עתידיים של ההודעות והקבצים המצורפים.

Safe Attachments unknown malware response – במידה והסריקה עבור קבצים מצורפים נתקלת בבעיה כלשהיא או אינה יכולה להשלים את הפעולה תתבצע חסימה בכל מקרה ולכן כדאי להחיל ניתוב לזיהוי קבצים חשודים לנמען ספציפי (SecOps Mailbox) אחרת, ייתכן שהודעות לא יועברו לנמען.

הגדרת Safe Link

Safe Links מספק סריקה וכתיבה (rewrite) מחדש של הודעות דואר נכנסות ואימות מבוסס time-of-click של כתובות URL וקישורים בהודעות דואר ובמיקומים אחרים. סריקת קישורים מתרחשת בנוסף להגנה הרגילה ברכיב Exchange Online Protection.

נכון לימים אלה Safe Links אינו מגיע עם פוליסי מובנה ולכן יש ליצור אחד כזה בהתאם להמלצות הבאות:

Action on unknown or potentially malicious URLs in messages – מבצע פעולות על קישורים שאינם מוכרים או אינם ידועים וכן על קישורים מוכרים במטרה לזהות קישורים זדונים, כמו כאלה שהוחלפו, קישורים שמתבססים על קמפיינים, קישורים עם תוכן זדוני שרוכבים על גבי Cloud Storage, קישורים שמבצעים ניתובים מחדש וכן הלאה.

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

Apply real-time URL scanning for suspicious links and links that point to files – מאפשר סריקה בזמן אמת של קישורים, כולל קישורים המצביעים על תוכן שניתן להוריד. הערך המומלץ מופעל. הודעות המכילות כתובות URL נבדקות עד לסיום הסריקה והודעות נוחתות תיבת הדואר רק לאחר אימות הקישורים.

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

תיבת SecOps

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

הגדרת Quarantine policy

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

ניתן להגדיר מספר פוליסים שונים לאוכלוסיות שונות, ובהתאם לכל מדיניות שהוגדר ברמת רכיבי הגנה (אותם רכיבים שהוזכרו מוקדם יותר במאמר).

פרואקטיביות

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

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

מה אפשרות לעשות בפעילות פרואקטיבית בשכבת הדואר?

לוודא שאנו מכירים את כל הנכסים בשכבת הדואר

לעיתים קרובות ישנם תיבות מערכת כמו Shared Mailbox או תיבות Services ללא סיסמאות, או סיסמאות חלשות ולכן אנו חייבים לוודא שכל תיבת דואר שייכת למשתמש אקטיבי. תיבות מערכת שיכולות לקבל סיסמה חייבות להיות עם סיסמה מורכבת בת 20 תווים לפחות.

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

לבצע בדיקות אבטחה מול תשתית הדואר

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

חריגות ואנומליות בתעבורת הדואר

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

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

מעקב אחר קמפיינים

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

סימולציות

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

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

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

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

בדוח Threat Protection Status נקבל תובנות לגבי איומים קיימים ברמת File Reputation, או Spoof או Fingerprint Matching ונוספים. כמו בכל דוח נוכל לבצע סינון ולקבל אינדיקציה על כל אובייקט ומשם להמשיך בניתוח התעבורה וכן בפעולות מנע שהוזכרו קודם לכן.

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

בדוגמה שלפנינו ניתן לראות את הפעולות שניתן לבצע מתוך ממש Explorer על אובייקט אחד או יותר.

פעולות Submission מסייעות לנו בסימון דואר וחסימה שלו ברמת תיבת דואר, דומיין וכן הלאה.

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

תהליך IR ותחקור

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

זיהוי ותחקור – שלב הזיהוי אשר נעשה לאחר זיהוי פעולה התקפית (קמפיין פישינג, קובץ עם תוכן נגוע וכו) נותן לנו את ההתראה הראשונית שיכולה להיות התראה למייל, התראה אל SIEM או כל מנגנון אחר, תובנה באמצעות דוח או פעולה פרואקטיבית. כאשר מקבלים התראה אנו צריכים להבין האם מדובר על התראה רגילה, או התראה מסוג Incident. כאשר מדובר על התראה רגילה, לרוב זה יכול להיות false positive אבל כאשר ישנו סט התראות אנו צריכים לוודא שלא מדובר באירוע אמיתי. במידה ומדובר על התראה מסוג incident אנו צריכים לקחת להגיב בצורה מהירה ולהבין האם אנו ממשיכים לניתוח או שמסווגים את ההתראה לפי benign false positive.

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

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

כאשר לוקחים את האפשרויות תחקור של Automated investigation and response או בשמו הקצר AIR אנו יכולים לבצע פעולות תחקור מתקדמות, ומכיוון שהכלי מנגיש לנו באופן אוטומטי את אינדיקציות לתחקור אנו מקבצים את זמני התדובה, זמני התחקור וביצוע פעולות מנע. התגובה היא בדגש על המאפיינים של Time to Closure וכן Time to Triage.

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

זיהוי לפי התראה, תובנה או פעולה פרואקטיבית בממשקי AIR, ממשק Explorer, ואף Advanced Hunting או Microsoft Sentinel.

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

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

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

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

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

שילוב מול Sentinel

ניתן לשלב את תשתית הדואר ובפרט את Defender for Office אל מול Microsoft XDR וכן אל Microsoft Sentienl. בשני המקרים אנו יכולים לקבל התראה, לבצע פעולות מנע אטומטיות (וגם ידני), לבצע תחקור מתקדם יותר מאשר הממשקים הקודמים, לאסוף מידע נוסף, לבצע קורלציה מול תשתיות ורכיבים אחרים ועוד שלל פעולות.

בממשק XDR בתחקור של Advanced Hunting אפשר להריץ שאילתות לזיהוי בעיות שונות, כמו בדוגמה המצורפת של זיהוי אובייקטים בתיבות הדואר שלא הצליחו להימחק ע"י האפשרות של ZAP.

כאשר עובדים עם Microsoft Sentinel אנו צריכים תחילה להזרים מידע מתוך Exchange Online וכן Defender for Office, ולכן נבצע חיבור שהוא מאוד פשוט. שני הקונקטורים הנ"ל מאפשרים לאסוף, מידע, לתחקר ולהגיב לבעיות דואר שונות. בניית התוכן נעשית על KQL לטובת יצירת Analytics Rule, או Hunting ואף וורבוקים שונים.

חיבור הקונקטורים נעשה בצורה הפשוטה מתוך ממשק Data Connector.

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

הערה: שאילתות בתשתית הדואר קיימות בקישור המצורף אצלי בגיטהאב

לסיכום

האפשרויותתעבורת הדואר היא אחת השכבות הבעייתיות, ולראייה הדוחות (רבעון 4 לשנת 2021) האחרונים שיצאו שמראים שישנה עלייה מתמדת בתקיפות בתשתית הדואר. כידוע, התוקף נמצא צעד אחד לפנינו ולכן אנו צריכים להיות פרואקטיביים, שזה אומר, להכין את כלי ההגנה בהתאם, לבצע את כלל ההגדות כמו אלה של Exchange Online Protection וכן Defender for Office במצב המחמיר ביותר בכדי למנוע הסתננות של תעבורת חשודה.

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

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

קישורים נוספים

Configure anti-phishing policies in Microsoft Defender for Office 365 – Office 365 | Microsoft Docs

Azure-Sentinel-4-SecOps/IRP/Phishing at master · eshlomo1/Azure-Sentinel-4-SecOps (github.com)

מאמרים נוספים של הגנה על תשתית הדואר

Hunting Mail Forwarding With Azure Sentinel (eshlomo.us)