לא מזמן קיבלנו מאחד הלקוחות שלנו מייל ישיר: "בדקתי את הציונים מהמבדק האחרון שמיקרוסופט השתתפה בו, והתוצאות לא טובות. 85% מהתקיפות הנפוצות לא נחסמו, ו-16% מההתראות פוספסו. איך מיקרוסופט תעזור לנו להגן על המכשירים, Windows, Linux ו-Ubuntu?"
לא הצלחנו להתאים את המספרים האלה בדיוק לתוצאות ש-MITRE פרסמה, אבל השאלה עצמה לגיטימית לגמרי, ואנחנו שומעים אותה הרבה. במאמר הזה נסביר מה המספרים האלה מייצגים, מה הם לא מייצגים, ולמה ההגנה האמיתית של Defender נמדדת ביכולות שמסביב ל-EDR: חוקי ASR, סיכון מכשיר ב-Intune, ניהול פגיעויות (TVM), ותמונת אירוע אחת שמחברת זהויות, מכשירים, דוא"ל, אפליקציות ענן ו-Active Directory. אלה בדיוק השכבות שאנחנו מגדירים בפרויקטי אבטחת מידע ב-Microsoft 365.
מה בודקים מבדקי MITRE ATT&CK Evaluations, ומה לא
MITRE ATT&CK Evaluations הוא מבדק שנתי שמדמה תקיפה של קבוצה אמיתית ובודק איך מוצרי EDR מגיבים לה. MITRE עצמה מדגישה שהמבדק לא מדרג ספקים ולא מכריז על "מנצח". המבדק מורכב משני חלקים שונים מאוד:
- מבדק זיהוי (Detection): יכולות החסימה מנוטרלות במכוון, כדי שהתקיפה תרוץ עד הסוף ויהיה אפשר לבדוק מה המוצר ראה בכל שלב. כאן אין משמעות ל"חסימה", רק לנראות.
- מבדק הגנה (Protection): החסימה פעילה, ובודקים באיזה שלב המוצר עוצר את התקיפה.
מה המבדק לא בודק: איך המוצר מוגדר אצלכם, כמה התראות שווא הוא מייצר ביום עבודה רגיל, איך ה-SOC מתעדף ומטפל באירוע, ומה קורה כשהמוצר עובד יחד עם הגנת זהויות, דוא"ל וענן. בנוסף, התרחישים משתנים מדי שנה, כך שאי אפשר להשוות ציון של שנה אחת לשנה אחרת.
למה חושבים ש-Defender לא מספיק טוב
התפיסה נשענת בעיקר על מבדק ההגנה של 2024, שבו התוצאות של Defender היו חלשות יותר. באותו מבדק עצמו, לפי מיקרוסופט, Defender XDR השיג כיסוי זיהוי מלא בכל שלבי התקיפה במבדק הזיהוי, אבל המספר שמסתובב ברשת הוא כמובן מספר החסימה.
ב-2025 השתנה המצב כולו: מיקרוסופט הודיעה ביוני שלא תשתתף במבדק, ובספטמבר הצטרפו אליה SentinelOne ו-Palo Alto Networks. כולן הסבירו שהן מעדיפות להפנות את המשאבים לפיתוח המוצר. לפי Infosecurity Magazine, אנליסטים בתעשייה העלו גם חשש שהמבדק הפך יותר לכלי שיווקי מאשר למדד אמיתי.
כלומר, הנתון שהלקוח ראה הוא נתון אמיתי, אבל הוא מגיע ממבדק אחד, בתרחיש אחד, וממוצר שבודקים אותו בבידוד.
מה האמת: איך לקרוא נכון את התוצאות
השאלה הנכונה היא לא "מי קיבל 100%", אלא "איך המוצר יתפקד אצלי, מוגדר נכון, עם שאר שכבות ההגנה". ארבע נקודות שכדאי לזכור:
- זיהוי מול חסימה. במבדק הזיהוי החסימה כבויה מראש, ולכן "לא נחסם" שם הוא לא כישלון. רק מבדק ההגנה מודד חסימה, ועליו כאמור יש מחלוקת מתודולוגית.
- כמות התראות היא לא איכות. מוצר שמקפיץ התראה על כל צעד קטן מקבל ניקוד גבוה, אבל ב-SOC אמיתי זה מתכון לעייפות התראות. Defender מאחד אירועים בודדים ל-Incident אחד עם סיפור מלא של התקיפה.
- ציון מושלם דורש זהירות. כשרוב הספקים הגדולים יצאו מהמבדק, חלק מהנשארים מפרסמים 100%. אנליסטית של Forrester הזהירה כבר אחרי מבדק 2024 שלא לקבל טענות כאלה כפשוטן. הגדרות שמותאמות במיוחד לתרחיש ידוע לא תמיד ישימות בארגון שעובד.
- EDR הוא רק שכבה אחת. במבדק בודקים את רכיב תחנת הקצה לבד. בסביבת ייצור, Defender מקבל סיגנלים גם מזהויות (Entra ID ו-Defender for Identity), מדוא"ל ומאפליקציות ענן, וזה מה שמאפשר לעצור תקיפה מוקדם, לפעמים עוד לפני שהיא מגיעה למחשב.
ולגבי השאלה המקורית של הלקוח: Defender for Endpoint תומך ב-Windows, ב-Linux (כולל Ubuntu) וב-macOS, עם ניהול מרכזי אחד לכולם. ב-Linux הוא נותן אנטי-וירוס, EDR וניהול פגיעויות. חלק מהשכבות שנדבר עליהן עכשיו הן של Windows בלבד, כמו חוקי ASR, וחסימת גישה לפי סיכון מכשיר עובדת ב-Windows, ב-iOS וב-Android. ההבדל בין הגנה חלשה לחזקה נקבע בעיקר ביכולות שמסביב ל-EDR, ובאופן שבו הן מוגדרות. עליהן נדבר עכשיו.
חוקי ASR: מה מאבדים כשמוצר אנטי-וירוס אחר הוא הראשי
חוקי ASR (Attack Surface Reduction) ב-Windows עובדים רק כש-Microsoft Defender Antivirus הוא האנטי-וירוס הראשי ופועל ב-Active mode. ברגע שמותקן מוצר אנטי-וירוס של יצרן אחר, Defender עובר ל-Passive mode (במכשיר שמחובר ל-Defender for Endpoint) או נכבה (במכשיר שלא מחובר), וחוקי ASR מפסיקים לאכוף, גם אם הוגדרו במדיניות.
זה פער שכיח מאוד בארגונים: Defender for Endpoint מותקן ומדווח, אבל ההגנה המונעת הכי אפקטיבית שלו כבויה בשקט. חוקי ASR חוסמים בדיוק את ההתנהגויות שתוקפים משתמשים בהן בתחילת התקיפה, למשל:
- קבצי Office שיוצרים תהליכי-בן או מריצים קוד
- גניבת סיסמאות מתהליך LSASS
- הרצת סקריפטים מוסתרים (Obfuscated) של PowerShell ו-JavaScript
- הרצת קבצים מצורפים מדוא"ל ומ-USB לא חתום
- שימוש בדרייברים פגיעים חתומים לעקיפת ההגנה
ההמלצה שלנו: להפעיל כל חוק קודם ב-Audit mode, לבדוק את ההשפעה על הסביבה, להגדיר החרגות ספציפיות לחוק, ורק אז לעבור ל-Block או Warn. את כל זה מנהלים ממקום אחד ב-Intune, והדיווחים מופיעים בפורטל Defender.
אם הארגון מחזיק היום מוצר EDR או AV של יצרן אחר לצד רישוי Microsoft 365 E5 (שכולל Defender for Endpoint) או Business Premium (שכולל Defender for Business), כדאי לשאול מה באמת מקבלים מהשילוב הזה, ומה משלמים פעמיים. איך עושים את המעבר בפועל, הסברנו במדריך המעבר מ-SentinelOne ל-Defender for Endpoint.
Intune ו-Device Risk: מכשיר נגוע לא נכנס למשאבי הארגון
החיבור בין Defender for Endpoint ל-Intune הופך כל זיהוי במחשב להחלטת גישה. Defender מחשב לכל מכשיר רמת סיכון (Machine Risk Score), Intune מסמן מכשיר שעבר את הסף כלא תואם (Non-compliant), ו-Conditional Access ב-Entra ID חוסם ממנו גישה לדוא"ל, ל-SharePoint, ל-Teams ולכל אפליקציה שמחוברת ל-Entra. בפועל זה נראה כך:
- תוקף מריץ כלי חשוד על מחשב של עובד.
- Defender מזהה ומעלה את רמת הסיכון של המכשיר ל-Medium או High.
- Intune מסמן את המכשיר כלא תואם, אוטומטית.
- Conditional Access חוסם גישה חדשה מהמכשיר הזה למשאבי הענן, גם אם לתוקף יש סיסמה תקפה.
- אחרי טיפול וניקוי, רמת הסיכון יורדת והגישה חוזרת אוטומטית.
זו בדיוק שכבה שמבדק EDR בבידוד לא יכול למדוד: גם אם התוקף הצליח להריץ משהו, הוא לא מצליח להשתמש במכשיר כדי להגיע לנתונים. אותו מנגנון עובד גם במובייל, עם Defender for Endpoint ל-iOS ול-Android.
היכולות הטובות של TVM: לסגור את הדלת לפני שמישהו נכנס
רוב התקיפות לא מתחילות בקוד מתוחכם אלא בפגיעות ישנה שלא טופלה. Microsoft Defender Vulnerability Management (לשעבר TVM) משתמש באותו סוכן של Defender for Endpoint, בלי סריקות רשת ובלי התקנה נוספת, ונותן תמונה רציפה של מצב המכשירים.
| יכולת | מה היא נותנת בפועל |
|---|---|
| מלאי תוכנות ופגיעויות | רשימה חיה של כל תוכנה, גרסה ו-CVE בכל מכשיר: Windows, Linux ו-macOS |
| תעדוף לפי סיכון אמיתי | דירוג לפי ניצול פעיל בשטח, חשיפה וחשיבות המכשיר, לא רק לפי ציון CVSS |
| Security Recommendations | רשימת פעולות מסודרת לפי ההשפעה על ציון החשיפה (Exposure Score) |
| בקשות תיקון ל-IT | פתיחת Remediation Request עם מועד יעד, וחיבור ל-Intune לטיפול |
| חסימת אפליקציות פגיעות | חסימת הרצה של גרסה פגיעה עד שהיא מעודכנת |
| הערכת Security Baselines | השוואה של הגדרות המכשירים מול CIS ו-STIG |
| מלאי תוספי דפדפן ותעודות | זיהוי תוספים מסוכנים ותעודות שפגות או חלשות |
ארבע מהיכולות, חסימת אפליקציות פגיעות, הערכת Security Baselines, תוספי דפדפן ומלאי תעודות, דורשות את תוסף Defender Vulnerability Management מעבר ל-Defender for Endpoint Plan 2. כדאי לבדוק מה כלול אצלכם.
ניהול אירוע במקום אחד: כל המקורות על אותו מסך
היתרון הגדול ביותר של Defender הוא לא ה-EDR עצמו, אלא שכל מקורות המידע של התקיפה נכנסים ל-Incident אחד בפורטל Microsoft Defender XDR:
| מקור | המוצר | מה הוא מוסיף לאירוע |
|---|---|---|
| מכשירים | Defender for Endpoint | תהליכים, קבצים, חיבורי רשת, בידוד מכשיר |
| זהויות בענן | Entra ID Protection | התחברויות חשודות, משתמש בסיכון, גניבת Token |
| Active Directory מקומי | Defender for Identity | Kerberoasting, Pass-the-Hash, תנועה רוחבית מול בקרי התחום |
| דוא"ל ו-Teams | Defender for Office 365 | הודעת הפישינג המקורית, מי עוד קיבל אותה, מי לחץ |
| אפליקציות ענן | Defender for Cloud Apps | פעילות חריגה ב-SaaS, הורדת נתונים, אפליקציות OAuth זדוניות |
במקום לקפוץ בין חמש קונסולות ולחבר ידנית את הנקודות, האנליסט רואה את כל הסיפור: מייל פישינג שנפתח, משתמש שהתחבר ממקום חריג, מחשב שהריץ PowerShell חשוד, וניסיון תנועה רוחבית מול ה-AD, באירוע אחד, עם ציר זמן אחד.
על הבסיס הזה פועל גם Automatic Attack Disruption: כשהמערכת מזהה תקיפה פעילה, כמו כופרה או השתלטות על חשבון, היא יכולה להכיל מכשירים ולהשבית את המשתמש שנפגע, גם ב-Active Directory המקומי (עם Defender for Identity), אוטומטית, בלי לחכות לאנליסט. את כל זה אפשר להרחיב עם Microsoft Sentinel, שמשולב באותו פורטל, למקורות נוספים כמו חומות אש ותשתיות ענן אחרות.
בשורה התחתונה
ציון במבדק MITRE הוא נקודת מידע אחת, לא החלטת רכש. ההגנה האמיתית של Microsoft Defender נבנית מהשילוב: EDR עם Defender Antivirus פעיל, חוקי ASR אוכפים, סיכון מכשיר שמזין את Intune ו-Conditional Access, ניהול פגיעויות רציף, ותמונת אירוע אחת שמחברת מכשירים, זהויות, דוא"ל, ענן ו-AD.
בפרויקטים שלנו אנחנו רואים שוב ושוב את אותו דבר: הרישוי קיים, אבל חצי מהיכולות כבויות או מוגדרות חלקית.
רוצים לדעת איפה אתם עומדים? קבעו שיחה עם הצוות של OnCloud ונבדוק יחד את מצב ההגדרות של Defender, Intune ו-Conditional Access בארגון שלכם.
קביעת שיחהמקורות
- Microsoft Security Blog: Defender XDR in the 2024 MITRE ATT&CK Evaluations
- Microsoft Tech Community: Microsoft’s participation in MITRE ATT&CK Evaluations Enterprise 2025
- Infosecurity Magazine: Major vendors pull out of the MITRE evaluations
- SecurityWeek: MITRE posts results of the 2025 ATT&CK Enterprise Evaluations
- Forrester: Don’t trust vendor claims about getting 100% on the MITRE ATT&CK Evaluations
- Microsoft: ASR rules requirements
- Microsoft: Defender Antivirus compatibility with other security products
- Microsoft: Configure Conditional Access with Defender for Endpoint
- Microsoft: Compare Defender Vulnerability Management plans