איך כותבים Analytics Rule ב-Microsoft Sentinel

שלב 1: כתבו Detection specification לפני KQL

Use Case צריך לענות על שאלות ברורות: איזו התנהגות נזהה? למה היא מסוכנת? אילו Data sources דרושים? מה Expected benign activity? מי Owner? מה האנליסט יעשה כאשר החוק מופעל? לאיזה MITRE technique הוא קשור?

הגדירו גם גבולות. Rule אינה מוכיחה Account compromise. היא מזהה Pattern שדורש חקירה. אם קיימת הצלחה, היא יכולה להעלות Priority, אך עדיין צריך לוודא רצף והקשר.

שלב 2: ודאו Data readiness

פתחו את הטבלה ובדקו Sample events. האם ResultType הוא מספר או מחרוזת? האם IPAddress ריק בחלק מהאירועים? האם Service principals מופיעים לצד משתמשים? מהו Ingestion delay? האם קיימים Tenant או Application שדורשים החרגה?

Rule שמסתמכת על שדה לא יציב תישבר. תעדו Schema, Connector, Normalization ו-Data health query. אם המקור מפסיק לשלוח, Dashboard חייב להתריע; “אין Alerts” אינו בהכרח מצב בטוח.

שלב 3: כתבו Query שמחזירה Evidence שימושי

Query בסיסית ל-Password Spray במעבדה יכולה לקבץ כשלונות לפי IP וחלון זמן ולדרוש מספר משתמשים ייחודיים:

let Lookback = 15m;
let MinimumAttempts = 20;
let MinimumUsers = 5;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where tostring(ResultType) != "0"
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            UserList=make_set(UserPrincipalName, 20),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by IPAddress, bin(TimeGenerated, 5m)
| where Attempts >= MinimumAttempts and Users >= MinimumUsers
| project TimeGenerated, IPAddress, Attempts, Users, UserList, FirstSeen, LastSeen

התוצאה צריכה להכיל את השדות שהאנליסט צריך ואת השדות שימופו ל-Entities. במקרה זה IPAddress הוא Entity מרכזית, ו-UserList הוא Context. רשימה דינמית של משתמשים אינה בהכרח מתאימה למיפוי Account יחיד, ולכן אפשר ליצור Alert לפי IP ולהוסיף Custom details, או לשנות את מבנה התוצאה בהתאם ל-Workflow.

בדקו Query על כמה טווחים: שעה, יום ושבוע. תייגו ידנית True, False ו-Benign Positives. ראו האם היא מזהה פעילות של VPN או Health checks. אל תכוונו Threshold רק כדי להגיע לאפס Alerts.

שלב 4: Frequency ו-Lookback

Query frequency קובעת כמה פעמים החוק רץ. Query period או Lookback קובע כמה זמן אחורה הוא בודק. אם Rule רצה כל חמש דקות ובוחנת 15 דקות, אותו Pattern יכול להופיע בכמה הרצות. מנגנוני Event grouping, Alert grouping או Suppression יכולים לצמצם כפילויות, אך יש להבין את ההשפעה.

Lookback צריך להיות ארוך מספיק כדי לכסות Ingestion delay ולזהות את ההתנהגות, אך לא רחב מדי. Password Spray איטי עשוי לדרוש חלון גדול יותר או Baseline שונה. Rule מהירה מדי יכולה לייצר רעש; Rule איטית מדי מגדילה זמן זיהוי.

שלב 5: Severity, MITRE ופרטי Alert

Severity צריכה לשקף סיכון כאשר התנאי מתקיים, לא את התוצאה הסופית של החקירה. Password Spray ללא הצלחה עשוי להיות Medium, אך ניסיון נגד חשבונות Privileged או הצלחה לאחר הכשלונות עשויים להצדיק דירוג שונה. אפשר להשתמש ב-Alert details override כדי להציג IP, משתמש או Count בכותרת באופן דינמי, תוך שמירה על כותרת קריאה.

מיפוי MITRE ATT&CK עוזר להסביר את התנהגות היריב ולבנות Coverage map. בחרו Tactics ו-Techniques שמתאימים ללוגיקה בפועל. אל תמפו רשימה ארוכה רק כדי להיראות מקיפים.

Custom details צריכים להציג Context שמקצר Triage: Attempts, Users, FirstSeen, LastSeen, Application או Tenant. הימנעו מהעברת מידע רגיש שאינו דרוש.

שלב 6: Entity mapping

Entity mapping מאפשר ל-Sentinel לזהות IP, Account, Host, URL ועוד. Entity איכותית מאפשרת Investigation, Enrichment, UEBA וקישור ל-Incidents אחרים. ודאו שהשדה בפלט הוא Scalar ובפורמט המתאים.

בדוגמה ממפים IP.Address ל-IPAddress. אם החוק מחזיר UserPrincipalName יחיד לכל שורה, ניתן למפות Account.FullName או AadUserId בהתאם ל-Schema. כאשר Query מסכמת משתמשים רבים ברשימה, אל תכריחו Mapping שאינו מייצג Entity אחת.

שלב 7: Event grouping ו-Alert grouping

Event grouping קובע אם כל שורת Query תהפוך ל-Alert נפרד או שכל התוצאות יאוגדו. אם כל IP הוא Case נפרד, שורה לכל IP ו-Alert לכל Result עשויים להיות הגיוניים. אם מאגדים הכול ל-Alert אחד, אנליסט עלול לקבל Incident עצום עם IPs לא קשורים.

Alert grouping יכול לצרף Alerts ל-Incident לפי Entities או פרטים. הגדירו חלון וזיהוי קשר אמיתי. Grouping אגרסיבי מדי מסתיר התפתחות ומערבב Scopes; Grouping חלש מדי יוצר Incident לכל הרצה.

שלב 8: Automation ו-Tasks

בשלב ראשון, אוטומציה יכולה להקצות Owner, להוסיף Tags, ליצור Tasks, להעשיר IP או לשלוח Notification. פעולות Containment אוטומטיות דורשות Confidence גבוה, Exceptions, אישור ויכולת Rollback. Detection חדש צריך בדרך כלל תקופת Monitor לפני תגובה אוטומטית משמעותית.

צרפו Tasks שמכוונים את האנליסט: בדוק הצלחות מאותו IP, בדוק MFA, בדוק Reputation, חפש פעילות המשך ופנה לבעל החשבון. כך Rule מייצרת תהליך ולא רק Alert.

Testing ו-Tuning

1. הריצו Query ידנית על נתונים היסטוריים וסמנו תוצאות.
2. בדקו Unit test עם אירועים מדומים שמייצגים Positive ו-Negative cases.
3. הפעילו Rule במצב ניטור ללא Automation מסוכנת.
4. מדדו Volume, True/False/Benign Positive, זמן Triage ואיכות Context.
5. שנו Threshold, exclusions או grouping עם תיעוד סיבה.
6. בצעו Regression test לאחר שינוי Parser, Connector או Query.
7. קבעו Review date ו-Owner; Rule ללא תחזוקה הופכת לחוב זיהוי.

Checklist לפני הפעלה

• ✓Use Case והיפותזה מתועדים.
• ✓Data source, Schema ו-Delay נבדקו.
• ✓Query מחזירה יחידת חקירה ברורה.
• ✓Frequency ו-Lookback מכסים את ההתנהגות בלי כפילות חריגה.
• ✓Severity ו-MITRE תואמים ללוגיקה.
• ✓Entities ו-Custom details תקינים.
• ✓Grouping נבדק על כמה תוצאות.
• ✓קיימים Playbook, Owner ו-Review date.
• ✓נבדקו Privacy, עלות והרשאות.
• ✓קיים Rollback לשינויים ול-Automation.

טעויות נפוצות

• להתחיל מ-Query שמצאתם באינטרנט בלי Use Case מקומי.
• למפות Entity מרשימה או משדה שאינו יציב.
• להשתמש ב-Lookback חופף בלי להבין כפילויות.
• להגדיר High severity לכל Rule.
• להחריג IP או משתמש לצמיתות ללא Expiration.
• להוסיף Suppression שמסתיר הסלמה של פעילות.
• להפעיל חסימה אוטומטית לפני תקופת Tuning.
• לא לבדוק Data health ו-Schema changes.

סיכום ו-CTA

בחרו Use Case אחד במעבדה וכתבו Detection specification של עמוד אחד לפני KQL. לאחר מכן בנו Rule, הפעילו אותה על נתונים מדומים ותעדו שלוש תוצאות: True, False ו-Benign Positive. השיפור החשוב ביותר אינו עוד תנאי ב-Query, אלא Incident שהאנליסט הבא יכול לחקור במהירות ובעקביות.

שאלות ותשובות

מקורות

• Microsoft Learn — Scheduled analytics rules in Microsoft Sentinel
• Microsoft Learn — Create custom analytics rules
• Microsoft Learn — Create analytics rules for Sentinel solutions
• Microsoft Learn — Create scheduled rules from templates
• Microsoft Learn — Best practices for KQL