לפני פרויקט בניית חוקה בחברת ביטוח, מנהל הפרויקטים של אבטחת המידע שלח לנו רשימת שאלות מסודרת. אפשר לבנות את החוקה ב-Defender XDR, ב-Sentinel או בשילוב, אז איפה בונים מה? איך מונעים חוקים כפולים? אילו הרשאות מינימליות נדרשות, ואפשר לעבוד עם PIM? ואיך נראה התוצר הסופי?
אלה בדיוק השאלות שכל ארגון עם Microsoft Defender ו-Sentinel צריך לשאול לפני שהוא כותב את החוק הראשון, והן חוזרות כמעט בכל פרויקט אבטחת מידע ב-Microsoft 365 שאנחנו מובילים. במאמר הזה ריכזנו את התשובות.
Defender XDR או Sentinel: איפה בונים כל חוק
השאלה "Defender או Sentinel" הולכת ומאבדת מהמשמעות שלה. מיקרוסופט מעבירה את Sentinel לתוך פורטל Defender (אחרי 31 במרץ 2027 הוא יהיה זמין רק שם), והתקריות משתי המערכות כבר מתאחדות לאותו Incident. מאוקטובר 2025 מיקרוסופט ממליצה לבנות חוקים חדשים כ-Custom Detections, מנוע אחד שעובד גם על נתוני Defender XDR וגם על נתוני Sentinel. לכן השאלה האמיתית היא איפה נמצאים הנתונים שהחוק צריך:
| סוג החוק | איפה לממש | למה |
|---|---|---|
| התנהגות חשודה בתחנות ושרתים | Custom Detection על נתוני Defender XDR | הנתונים כבר קיימים ב-Advanced Hunting בלי עלות קליטה, ואפשר לצרף פעולת תגובה אוטומטית כמו בידוד מכשיר |
| פעילות חריגה בזהויות, בדוא"ל ובאפליקציות ענן | Custom Detection על נתוני Defender XDR | מתחבר ישירות לאותו Incident עם מיפוי ישויות אוטומטי |
| זיהוי מהיר על טבלה אחת | Custom Detection בתדירות Near Real-Time (NRT) | רץ על הנתונים בזמן שהם נכנסים, בלי מגבלה על מספר החוקים. מוגבל לטבלה אחת ולטבלאות הנתמכות, בלי joins |
| חומות אש, VPN, שרתי Linux, מערכות OT ומקורות צד שלישי | Sentinel (Custom Detection או Analytics Rule על נתוני Sentinel) | הנתונים האלה נכנסים רק ל-Sentinel |
| קורלציה בין Defender למקורות חיצוניים | Sentinel | צריך את שני מקורות הנתונים באותה שאילתה |
| לוגיקה שצריכה היסטוריה של חודשים | Sentinel, עם Summary Rules או Watchlists | חוק Custom Detection מסתכל עד 30 יום אחורה ו-Analytics Rule עד 14 יום. היסטוריה ארוכה בונים מסיכומים ורשימות ב-Sentinel |
כלל אצבע: אם הנתונים כבר קיימים ב-Defender XDR, לא קולטים אותם ל-Sentinel רק כדי לכתוב עליהם חוק. זה חוסך עלויות קליטה, ומונע את המצב הנפוץ שבו אותו אירוע מייצר שתי התראות משתי המערכות.
יש עדיין מקרים שבהם Analytics Rule עדיף: אוטומציה שמופעלת על יצירת Incident, תבניות מ-Content Hub, פריסה ב-Bicep וחוקים על כמה Workspaces. אלה עוד לא נתמכים ב-Custom Detections.
מתחילים מהמובנה, לא מדף ריק
הטעות הנפוצה ביותר בפרויקט חוקה היא לכתוב מאות חוקים מותאמים לפני שבודקים מה המוצר כבר מזהה בעצמו. Defender XDR מגיע עם מגוון גדול של זיהויים מובנים, ו-Sentinel עם תבניות חוקים מוכנות. סדר העבודה שאנחנו ממליצים עליו:
- מיפוי מקורות. אילו מערכות ושירותים רוצים לנטר, ואילו מוצרי Defender פעילים בפועל: Endpoint, Identity, Office 365, Cloud Apps.
- בדיקת הכיסוי המובנה. מה המוצרים מזהים כבר היום, ומה מופיע בתבניות של Sentinel ובפתרונות מ-Content Hub.
- מיפוי ל-MITRE ATT&CK. ממפים את הזיהויים הקיימים לטכניקות, ומסמנים את הטכניקות הרלוונטיות לסביבה שלכם. לא כל טכניקה רלוונטית לכל ארגון.
- Gap Analysis. הפער בין הטכניקות הרלוונטיות לזיהויים הקיימים הוא רשימת העבודה. כל פער הופך ל-Use Case.
- תעדוף. מתחילים מ-Use Cases שמכסים סיכון גבוה עם נתונים שכבר קיימים, למשל השתלטות על חשבון, הסלמת הרשאות ותנועה רוחבית.
- כתיבה, בדיקה ו-Tuning. רק עכשיו כותבים את החוקים המותאמים, ובודקים כל אחד לפני הפעלה.
כך מתקבלת חוקה שמשלימה את המוצר, במקום לשכפל אותו.
הרשאות: מינימום הכרחי, ורק לזמן העבודה
אצל הלקוח, איש האבטחה שאמור לבנות את החוקים קיבל בתחילת הפרויקט Global Reader בלבד. זו נקודת התחלה טובה: הרשאת קריאה בלבד, שמאפשרת לראות הכל ולא לשנות כלום. לנתוני Sentinel צריך גם Microsoft Sentinel Reader, כי הגישה אליהם נשלטת ב-Azure RBAC. מה שצריך להוסיף לה תלוי במקום שבו החוקים נבנים:
| מה עושים | הרשאה מינימלית | איפה מגדירים |
|---|---|---|
| יצירה וניהול של Custom Detections, Alert Tuning ו-IOCs | Detection tuning (manage) בתפקיד מותאם | Unified RBAC בפורטל Defender |
| הרצת שאילתות ב-Advanced Hunting | Security data basics (read) | Unified RBAC בפורטל Defender |
| יצירת Analytics Rules על נתוני Sentinel | Microsoft Sentinel Contributor על ה-Resource Group של ה-Workspace בלבד | Azure RBAC |
| הגדרת אוטומציה (Playbooks) | Logic App Contributor ליצירת Playbooks, Microsoft Sentinel Contributor לחיבור שלהם לחוקים, ו-Microsoft Sentinel Playbook Operator להרצה ידנית | Azure RBAC |
היתרון של Detection tuning (manage) הוא שהוא מאפשר לנהל חוקים בלי לתת את ההרשאה הרחבה של Core security settings (manage), ובוודאי בלי Security Administrator. ייתכן שיידרשו הרשאות נוספות לנתונים של מוצר ספציפי, למשל כשמוגדרות קבוצות מכשירים ב-Defender for Endpoint.
לגבי ספק חיצוני שעובד בסביבה, ההמלצה שלנו ברורה: תפקיד מותאם עם הרשאות מינימליות, והפעלה דרך PIM לזמן העבודה בלבד, לא הרשאה קבועה. את תפקידי Unified RBAC אפשר לשייך לקבוצת Entra, ואת הקבוצה להפעיל דרך PIM for Groups (דורש Entra ID P2). כל הפעלה נרשמת ביומן, ובסוף הפרויקט לא נשארות הרשאות פתוחות.
Tuning: פחות רעש, יותר התראות שאפשר לפעול עליהן
כל חוק שמייצר התראות שאף אחד לא מטפל בהן מזיק יותר משהוא עוזר: הוא מרגיל את ה-SOC להתעלם. כמה כללים שעובדים:
- הרצה בשקט לפני הפעלה: מריצים את השאילתה על 30 הימים האחרונים ב-Advanced Hunting, ורואים כמה תוצאות היא הייתה מייצרת. חוק שהיה מתריע מאות פעמים בחודש עוד לא מוכן. שימו לב: חוק Custom Detection חדש רץ מיד אחרי השמירה על 30 הימים האחרונים, ויכול לייצר עד 150 התראות בכל הרצה.
- חומרה לפי פעולה: High רק למה שדורש תגובה מיידית. כל השאר Medium או Low, או רק תיעוד לצורך Hunting.
- החרגות ממוקדות: מחריגים חשבון שירות, שרת או תהליך ספציפי, לא תיקייה שלמה או משתמש עם הרשאות רחבות. וכל החרגה מתועדת עם סיבה ובעלים.
- מיפוי ישויות: מגדירים בכל חוק את המשתמש, המכשיר וה-IP. כך המערכת מאחדת התראות לאותו Incident, במקום עשר התראות נפרדות.
- בלי כפילויות: לפני כתיבת חוק בודקים אם זיהוי מובנה כבר מכסה אותו. אם כן, משפרים את הזיהוי הקיים עם Alert Tuning במקום לכתוב חוק חדש.
- סקירה תקופתית: פעם ברבעון עוברים על החוקים לפי כמות ההתראות ושיעור ה-False Positives, ומעדכנים או מכבים.
התוצר הסופי: קטלוג חוקים
התוצר של פרויקט חוקה הוא לא רק החוקים שרצים במערכת, אלא קטלוג שמאפשר לצוות לתחזק אותם אחרי שהפרויקט נגמר. לכל חוק בקטלוג נרשמים השדות הבאים:
| שדה | מה נרשם |
|---|---|
| Use Case | מה החוק מזהה, במשפט אחד |
| פלטפורמה | Custom Detection או Analytics Rule, ועל אילו נתונים |
| שאילתת KQL | הקוד המלא, בניהול גרסאות |
| מיפוי MITRE | הטקטיקה והטכניקה שהחוק מכסה |
| מקורות נתונים | הטבלאות והמחברים שהחוק תלוי בהם |
| חומרה | ועל מה היא מבוססת |
| תדירות | NRT, כל שעה, פעם ביום |
| החרגות | מה מוחרג ולמה |
| בעלים | מי אחראי על החוק ועל הטיפול בהתראות שלו |
| היסטוריית Tuning | מה שונה, מתי ולמה |
| תגובה | פעולה אוטומטית או נוהל טיפול ידני |
קטלוג כזה עונה גם על השאלה ששואלים מבקרים ורגולטורים: מה בדיוק אתם מנטרים, ואיך אתם יודעים שזה עובד.
בשורה התחתונה
חוקה טובה מתחילה במה שהמוצר כבר מזהה, ממשיכה ב-Gap Analysis מול MITRE, ובונה חוקים רק על הפערים. מה שרץ על נתוני Defender XDR נבנה כ-Custom Detection, ו-Sentinel נשאר למקורות חיצוניים, לקורלציה ולטווחי זמן ארוכים. ההרשאות מינימליות ודרך PIM, וכל חוק מתועד בקטלוג.
מתכננים פרויקט חוקה? קבעו שיחה עם הצוות של OnCloud, ונבנה יחד את המתודולוגיה, ההרשאות והתעדוף שמתאימים לסביבה שלכם.
קביעת שיחהמקורות
- Microsoft Tech Community: Custom detections are now the unified experience for creating detections
- Microsoft Tech Community: Custom detection rules get a boost (unlimited NRT)
- Microsoft: Compare analytics rules and custom detections
- Microsoft: Create custom detection rules
- Microsoft: Permissions in Microsoft Defender Unified RBAC
- Microsoft: Roles and permissions in Microsoft Sentinel
- Microsoft: Microsoft Sentinel in the Defender portal