חשיפה מלאה של Microsoft 365: למה מחברי SIEM ברירת המחדל משאירים אתכם עיוורים

By Mirko Peters · 2026-08-11

ברוכים השבים לבלוג! אם אתם מנהלים את תפעול האבטחה של ארגון המשתמש ב-Microsoft 365, סביר להניח שאתם חשים תחושת ביטחון מדומה. לחצתם על "en…

Automatically translated with AI from the original post. Read the English original

ברוכים השבים לבלוג! אם אתם מנהלים את פעילות האבטחה בארגון שעושה שימוש ב-Microsoft 365, סביר שאתם חשים בביטחון מדומה. הפעלתם את מחבר ה-M365 ברירת המחדל של ה-SIEM, וידאתם שהלוגים זורמים, וסימנתם את תיבת הציות. אבל האם אתם באמת מוגנים? האמת הלא נוחה היא שמחברי SIEM מובנים משאירים לעיתים קרובות פערים עצומים, ומפספסים לגמרי עומסי עבודה מתקדמים בענן, שבהם תוקפים מודרניים אוהבים לפעול. כדי להבין לעומק את הנושא החשוב הזה, כדאי להאזין לפרק הפודקאסט הנלווה שלנו, Send Critical Microsoft 365 Logs to Your SIEM, שבו אנחנו מפרקים את הפערים האלה בפירוט.

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

פערי הנראות של Microsoft 365 ב-SIEMs פופולריים

בין שאתם משתמשים ב-Microsoft Sentinel, ב-Splunk או ב-QRadar, תבניות הקליטה ברירת המחדל בדרך כלל מתמקדות בכניסות בסיסיות ל-Azure Active Directory ובלוגי פעילות בסיסיים של Office 365. למרות שזה מכסה את היסודות, הן משאירות עומסי עבודה קריטיים חשופים לחלוטין. בפלטפורמות SIEM פופולריות מופיעים באופן עקבי כמה פערים עיקריים:

• Exchange: מחברי ברירת מחדל מפספסים לעיתים קרובות גישה לתיבת דואר שאינה של הבעלים, יצירה חשודה של כללים והעברות, פעולות SendAs או SendOnBehalf, ושינויים פתאומיים בהרשאות לתיבת הדואר.
• SharePoint ו-OneDrive: אולי אתם רואים הורדות קבצים, אבל האם אתם רואים יצירה ושימוש בקישורים חיצוניים ואנונימיים, שיתוף מחדש של קבצים, או שינויי הרשאות מיוחדות באתרים?
• Teams: תוקפים אוהבים לשתף פעולה בפומבי. מדיניות ברירת מחדל כמעט אף פעם לא לוכדת שיתוף חיצוני באמצעות ערוצים שמגובים ב-SharePoint, מחיקות ועריכות של הודעות, שינויים במדיניות פגישה, או העלאה לא מורשית של אפליקציות בצד.
• Power Platform: עלייתן של סביבות קוד נמוך וללא קוד מביאה עמה סיכונים נסתרים. קפיצות ביצירת Flows ואפליקציות, שימוש מסוכן במחברים (כמו Outlook, Teams או מחברי HTTP כלליים), ועקיפות של מדיניות מניעת אובדן נתונים (DLP) מושמטות לעיתים קרובות.
• רגישות ו-DLP: אירועים של החלת תוויות, הסרתן, פגיעות במדיניות וביטולים ידניים חסרים לעיתים קרובות לגמרי, אלא אם מכוונים אליהם במפורש.
• הקשר של Azure AD: הקשר חיוני לגבי כניסות מסוכנות, תוצאות של גישה מותנית וחריגות במכשירים או במיקום גיאוגרפי נשמטים לעיתים קרובות משאילתות סטנדרטיות.

שורשי הבעיה: למה חסרים לכם אירועים קריטיים

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

ראשית, מגבלות רישוי משחקות תפקיד משמעותי. ביקורת מתקדמת, טלמטריית Exchange מפורטת ותיעוד אירועים עשיר של SharePoint נעולים לעיתים קרובות מאחורי רישיונות ברמה גבוהה יותר כמו Microsoft 365 E5 או תוספות Advanced Audit. אם הדייר שלכם נמצא ברמת E3, האירועים האלה פשוט לא נוצרים או נשמרים מלכתחילה.

שנית, היקף המחברים מגביל את איסוף הנתונים. מחברים סטנדרטיים בדרך כלל שולפים את זרמי "OfficeActivity" הבסיסיים, ומתעלמים מעומסי עבודה מתקדמים. שלישית, הגבלות תפוקת API ועיכובים באצווה עלולים להעמיס על אוספים מקוריים בשעות השיא, וכך לגרום לאובדן לוגים. רביעית, פערים במנתחי הנתונים (parsers) פירושם שגם אם בלובי ה-JSON הגולמיים מגיעים ל-SIEM, שדות שלא מופו ושינויי סכמה שקטים הופכים אותם לחסרי משמעות. לבסוף, בקרות עלות שמיישמים צוותים הנשענים על תקציב מצמצמים בשקט קטגוריות רועשות, מבלי להבין את ההשלכות על האבטחה.

איזון בין בקרת עלויות לבין שמירה על נראות

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

התחילו בסינון במקור. הגדירו את מנגנוני הקליטה שלכם כך שייכללו רק פעולות בעלות אות גבוה, כמו New-InboxRule, Add-MailboxPermission, או אירועים של יצירה ושימוש בקישורי שיתוף אנונימיים. לפני שהאירועים מגיעים ל-SIEM שלכם, בצעו דה-דופליקציה ואיחוד של אירועים רועשים וחסרי ערך, כמו שמירות גרסה רקעיות ב-SharePoint.

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

תכנון צינור קליטה עמיד

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

• מקור: משכו נתונים מיומן הביקורת המאוחד של M365, מ-Advanced Audit, מכניסות ומיומני סיכון של Azure AD, מ-Microsoft Information Protection (MIP), מהתראות DLP ומהתראות האבטחה של Microsoft Defender.
• הובלה: הזרימו נתונים מ-Graph או מ-Management API אל Azure Event Hub, שפועל כמאגר ביניים ומנגנון הפעלה חוזרת, ורק לאחר מכן העבירו אותם ל-SIEM שלכם.
• עיבוד: נרמלו והעשירו את הנתונים כבר באזור הנחיתה, והוסיפו הקשר משתמש, סימוני מחלקה, סימוני VIP, מצב מכשיר ונתונים גיאוגרפיים.
• ממשל: יישמו בדיקות שלמות יומיות, מנגנוני המתנה חוזרת (backoff) לשגיאות 429 של הגבלת קצב, מעקב אחר שינויים בסכמה והתראות על תורי הודעות שלא נמסרו (dead-letter queue).

נרמול והעשרה לנתונים מוכנים לאנליסטים

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

שטחו שדות מרכזיים בזמן הקליטה: Actor, Target, Action, ResourcePath, LinkType (אנונימי, ארגוני, או אנשים ספציפיים), ExternalRecipient ו-LabelName. מפו שדות אלה לסכמה אחידה, כמו Azure Monitor Common Security Incident Model (ASIM) או Elastic Common Schema (ECS), כדי שהנדסת הזיהוי שלכם תשתרע על פני השירותים בצורה חלקה. לבסוף, העשירו את האירועים בנתוני HR (תפקיד, סוג העסקה, מחלקה), ברשימות VIP, ברשימות היתר של שותפים, במצב ציות של מכשירים ובסיווגי רגישות.

זיהויים בעלי אות גבוה לפריסה מיידית

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

• דליפה דרך תיבת הדואר: זהו כלל חדש בתיבת הדואר שמעביר הודעות החוצה או מעביר הודעות אל RSS/Junk, ומתרחש בתוך שעה מכניסה ממיקום גיאוגרפי חדש או ממכשיר לא מזוהה.
• גישה נסתרת: סמנו גישה של מי שאינו הבעלים לתיבת הדואר של חשבון VIP, כאשר קדם לה אירוע Add-MailboxPermission ב-24 השעות האחרונות.
• דליפה מ-SharePoint: התריעו על קישורי שיתוף אנונימיים או של "אנשים ספציפיים" שנוצרו לקבצים שמסווגים כ-Confidential או כ-Restricted.
• שימוש לרעה בקישורים: זהו נפח גבוה של הורדות חיצוניות בחלון של 15 דקות, שמקורן בקישור שיתוף שנוצר לאחרונה מכתובת IP או ASN חדשים.
• ציר מעבר דרך Teams: אתרו תרחישים שבהם קובץ משותף החוצה, ובאותו משתמש מוסיף אורח חיצוני לצוות תוך שעתיים.
• שימוש לרעה ב-Power Automate: סמנו זינוק פתאומי של שלושה זרימות חדשות או יותר ביום, שנוצרו על ידי חשבון שאינו מפתח, ובמיוחד באמצעות מחברי HTTP או Outlook.
• הצטברות הרשאות: עקבו אחר הוספות והסרות חוזרות של תפקידי חבר או מנהל באותו אתר או סביבת עבודה רגישים, בחלון של 24 שעות.
• נתונים מיושנים: זהו מצבים שבהם מערכי הנתונים של תוכן ההנהלה או הכספים נכשלים ברענון במשך שני מחזורים או יותר, כדי למנוע מההנהלה לקבל החלטות על בסיס נתונים לא עדכניים.

תוכנית יישום של 30 יום לסגירת הפערים

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

• שבוע 1: הפעילו Advanced Audit במקומות שבהם הדבר נדרש, בצעו מלאי של מחברי ה-SIEM הנוכחיים שלכם, ומפו את קטגוריות האירועים החסרות.
• שבוע 2: הקימו את צינור Event Hub שלכם. נתבו אליו את טלמטריית Unified Audit Logs, Advanced Audit, Azure AD ו-Defender, והטמיעו את הסינוני המקדים שלכם.
• שבוע 3: נרמלו והעשירו את זרמי הנתונים שלכם, מלאו לאחור את יומני הקריטיים מ-30 הימים האחרונים, ופרסו את שבעת הזיהויים בעלי האות הגבוה שהוזכרו לעיל, עם חלונות השתקה מתאימים.
• שבוע 4: התאימו את העלויות שלכם על ידי הסרת הרעש שנותר והתאמת שכבות השמירה. הוסיפו מוניטורים לשלמות הנתונים והריצו תרגיל שולחני של צוות purple team שבודק כללי תיבות דואר, שיתוף חיצוני וזינוקים בזרימות.

מדדי KPI ניהוליים להוכחת ההצלחה

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

• כיסוי: אחוז משפחות אירועי M365 הממוקדות שנקלטו ונותחו בהצלחה (יעד של 95% ומעלה).
• מהירות: זמן ממוצע לאישור (MTTA) וזמן ממוצע לפתרון (MTTR) של אירועי אבטחה הקשורים ל-M365 (מגמה יורדת).
• רעש: יחס בין התראות לאירועים חיוביים אמיתיים (מגמה עולה באיכות האות).
• עלות: עלות לגיגה-בייט שנקלט (מגמה יורדת של כ-40% בזכות הסינון המקדים).
• אמינות: מספר הימים עם פערים בקליטת נתונים (היעד: אפס) ו-SLA לשינויי סכמה (עדכוני מנתחים תוך שבעה ימים משינוי סכמה של Microsoft).

מכשולים נפוצים ודרכי הפתרון

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

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

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

סיכום: הפסיקו להסתמך על הציות לצורך הגנה

העיקר פשוט: מחברי SIEM ברירת מחדל שומרים עליכם מצויתים לדרישות, אך לא מגינים עליכם. על ידי משיכת יומני Microsoft 365 הנכונים, נרמול שלהם לסכמה אחידה, העשרתם בהקשר עסקי קריטי וחיפוש איומים באמצעות זיהויים המותאמים להתנהגות תוקפים אמיתית, תוכלו לסגור לחלוטין את נקודות העיוורון שלכם. כך ה-SIEM שלכם מפסיק לפספס את הסיפור ומתחיל לכתוב אותו. כדי להעמיק עוד יותר באסטרטגיה זו, האזינו לפרק המלא בנושא Send Critical Microsoft 365 Logs to Your SIEM והתחילו לצמצם את פערי הנראות שלכם עוד היום!