במאמר הקודם הסברנו למה ציון במבדק MITRE לא מספר את כל הסיפור על Defender. הפעם נראה איך זה נראה בשטח: לקוח תעשייתי שלנו מריץ פיילוט Zero Trust, ובמסגרתו מסיר את SentinelOne מהמחשבים ומעביר אותם ל-Defender, ל-Intune ולסט מלא של מדיניות הקשחה, כחלק מפרויקט אבטחת Microsoft 365 רחב יותר.
נעבור על הסיבות למעבר, על התהליך צעד אחרי צעד, ועל מה שחשוב לבדוק כדי שהפער בהגנה יהיה קצר ומכוסה.
למה ארגונים עוברים
הסיבה הראשונה היא כמעט תמיד כסף: ארגונים עם Microsoft 365 E5 (שכולל Defender for Endpoint) או Business Premium (שכולל Defender for Business) כבר משלמים על EDR של מיקרוסופט, ובמקביל משלמים על EDR נוסף. אבל הכסף הוא רק חלק מהסיפור.
- חוקי ASR לא עובדים לצד מוצר אחר. כשמותקן אנטי-וירוס של יצרן אחר, Defender Antivirus עובר ל-Passive mode, ובמצב הזה חוקי ASR לא נאכפים בכלל. הארגון מאבד את שכבת המניעה החזקה ביותר של Windows.
- אין חיבור לגישה. רמת הסיכון ש-Defender מחשב לכל מחשב יכולה לחסום גישה דרך Intune ו-Conditional Access. Defender מזין את רמת הסיכון של המחשב ל-Compliance של Intune באופן מובנה, בלי מחבר או מוצר נוסף.
- שתי קונסולות, שני סיפורים. ה-SOC רואה את התחנה במוצר אחד, ואת הזהויות, הדוא"ל והענן בפורטל של מיקרוסופט. אחרי המעבר ל-Defender הכל נכנס לאותו Incident.
- ניהול פגיעויות בסיסי כלול. מלאי התוכנות, הפגיעויות וההמלצות מגיעים מאותו סוכן, בלי כלי נוסף. יכולות מתקדמות דורשות תוסף.
איך נראה המעבר בפועל
העיקרון המרכזי: לא מחליפים את כל הארגון ביום אחד. בונים קבוצת פיילוט ב-Entra ID, מקשרים אליה את כל המדיניות החדשה, ומעבירים מחשבים בהדרגה. כך זה נראה אצל הלקוח:
- הכנה מראש. כל המדיניות של הפיילוט נבנית ב-Intune ומשויכת לקבוצת מכשירים ייעודית. מחשבי הייצור ממשיכים לקבל את המדיניות הקיימת עד שהם עוברים.
- הסרת SentinelOne. מסירים את הסוכן עם ה-Passphrase מקונסולת SentinelOne, ומאתחלים את המחשב. ב-Windows 10 ו-11, ברגע שהמוצר האחר יורד, Defender Antivirus חוזר אוטומטית ל-Active mode.
- הוספה לקבוצת הפיילוט. המחשב נכנס לקבוצה, וכל המדיניות מגיעה אליו אוטומטית: חיבור ל-Defender for Endpoint, הגדרות אנטי-וירוס, חוקי ASR, BitLocker, חומת אש ו-Security Baselines. עד ש-Intune מחיל את המדיניות, Defender Antivirus כבר פעיל עם הגדרות ברירת מחדל.
- חריגים מוגדרים כקבוצה. מחשב שצריך לקבל RDP או Ping נכנסים מתווסף לקבוצה נפרדת עם חוק חומת אש מתאים, במקום לפתוח את זה לכולם.
- בדיקה אחרי 2–4 שעות. ב-Intune המחשב צריך להיות Compliant וההגדרות במצב Succeeded. בפורטל Defender האנטי-וירוס צריך להיות פעיל, ורמת הסיכון Low או Medium לכל היותר.
- הסלמה אחרי 8 שעות. אם משהו עדיין לא תקין, צוות הפרויקט בודק את המחשב לפי שמו.
המסלול שמיקרוסופט ממליצה עליו הוא חפיפה: לחבר את המחשבים ל-Defender for Endpoint כש-Defender Antivirus ב-Passive mode לצד המוצר הקיים, להגדיר הכל, ורק אחר כך להסיר את המוצר הישן. בפיילוט הזה בחרנו במסלול הישיר, עם קבוצה קטנה ובדיקה אחרי כל מחשב. חפיפה מתאימה לארגונים שמעדיפים ששני המוצרים ירוצו יחד, במחיר של שלב ביניים ארוך יותר.
מה חשוב לבדוק לפני ואחרי ההסרה
רוב התקלות במעבר לא נובעות מ-Defender עצמו, אלא מדברים שנשכחו בדרך. אלה הנקודות שאנחנו בודקים בכל פרויקט:
| נקודה | למה זה חשוב |
|---|---|
| Passphrase להסרה | בלי ה-Passphrase מהקונסולה, SentinelOne לא יוסר מהמחשב, והתהליך נתקע |
| Defender ב-Active mode | אחרי האתחול לוודא שהאנטי-וירוס פעיל ולא נשאר ב-Passive, אחרת ASR לא יעבוד. אם הוא נתקע, מגדירים ForceDefenderPassiveMode=0 ומאתחלים |
| Tamper Protection | מונע ממשתמש או מתוקף לכבות את Defender או לשנות את הגדרותיו |
| החרגות (Exclusions) | להעביר רק החרגות שבאמת נדרשות לאפליקציות עסקיות, ולא להעתיק בעיוורון את הרשימה מהמוצר הקודם |
| חוקי ASR במצב Audit | להתחיל ב-Audit, לבדוק השפעה על אפליקציות, ורק אחר כך לעבור ל-Block |
| מדיניות Compliance | לכלול בה גם את רמת הסיכון של Defender, כדי שמחשב נגוע ייחסם אוטומטית ב-Conditional Access |
| Windows Server | בשרתים Defender לא עובר ל-Passive אוטומטית כשיש מוצר אחר. בזמן החפיפה מגדירים ForceDefenderPassiveMode=1 לפני החיבור ל-Defender for Endpoint |
מה מקבלים אחרי המעבר
בפיילוט הזה, החלפת ה-EDR היא בעצם הפתח להקשחה מלאה של התחנה. כל מחשב שעובר מקבל את השכבות הבאות, כולן ממקום ניהול אחד ב-Intune:
- הקשחת מערכת ההפעלה והאפליקציות: Security Baselines של מיקרוסופט ל-Windows, ל-Defender for Endpoint, ל-Microsoft 365 Apps ולדפדפן Edge.
- אנטי-וירוס ו-EDR פעילים: Defender Antivirus ב-Active mode, Tamper Protection והמלצות התצורה של Defender.
- חוקי ASR: כרגע ב-Audit, בדרך ל-Block אחרי בדיקת ההשפעה.
- הצפנה וחומת אש: BitLocker וחוקי Firewall מנוהלים, עם חריגים לפי קבוצות.
- סיסמאות מקומיות: נעילת חשבון מקומי אחרי 10 ניסיונות כושלים.
- הגבלות על סוכני AI מקומיים: Baseline ייעודי (בתצוגה מקדימה) שמגביל כלי AI שרצים על התחנה, נושא שהולך ונעשה חשוב.
- Compliance שמבוסס על סיכון: מחשב נחשב תקין רק אם יש לו סיסמה, Secure Boot, TPM ואנטי-וירוס פעיל, ורמת הסיכון שלו ב-Defender היא Medium לכל היותר. מחשב שחורג נחסם מגישה למשאבי הארגון.
השורה האחרונה היא לב העניין: אחרי המעבר, מה ש-Defender רואה על המחשב משפיע ישירות על מה שהמשתמש יכול לגשת אליו. זה ה-Zero Trust בפועל.
בשורה התחתונה
מעבר מ-SentinelOne ל-Defender for Endpoint חוסך רישוי כפול, אבל הערך האמיתי שלו הוא מה שנפתח אחריו: חוקי ASR שעובדים, הקשחה אחידה מ-Intune, וגישה שתלויה במצב האמיתי של המחשב. המפתח הוא תהליך מדורג: קבוצת פיילוט, בדיקות ברורות אחרי כל מחשב, ומעבר לייצור רק אחרי שהכל יציב.
שוקלים מעבר ל-Defender? קבעו שיחה עם הצוות של OnCloud, ונבנה יחד תוכנית מעבר ופיילוט שמתאימה לסביבה שלכם.
קביעת שיחהמקורות
- Microsoft: Migrate to Defender for Endpoint from non-Microsoft endpoint protection
- Microsoft: Migrate to Defender for Endpoint, phase 3: onboard
- Microsoft: Defender Antivirus compatibility with other security products (active and passive mode)
- Microsoft: ASR rules requirements
- Microsoft: Mobile Threat Defense integration with Intune