Microsoft Sentinel: מדריך חקירת Incident לאנליסט מתחיל

לפני החקירה: הכנות בסיסיות

אנליסט צריך הרשאות מתאימות לצפייה, הקצאה ושינוי Incident. Microsoft מציינת את Sentinel Responder כאחד התפקידים הנדרשים לחקירה. הרשאות צריכות לפעול לפי Least privilege, ובארגון אמיתי חשוב להפריד בין צפייה בנתונים רגישים לבין פעולות תגובה כגון בידוד נכס או השבתת משתמש.

ודאו שה-Incident כולל Entities שימושיים. Entity mapping ב-Analytics rule מאפשר למערכת לזהות Account, Host, IP, URL, File או Process. ללא Mapping, החקירה הגרפית והקישורים להקשר יהיו מוגבלים. בנוסף, בדקו ש-Data connectors בריאים ושאין Ingestion delay משמעותי.

לפני פתיחת Incident, הגדירו SLA או Triage target, Owner וקריטריונים להסלמה. Incident ללא Owner עלול להמתין גם כאשר Severity גבוה.

שלב 1: קריאת Incident queue

בתור האירועים מתבצע התעדוף הראשוני. אל תסתפקו ב-Severity. בדקו Created time, Last activity, Product, Tactics, מספר Alerts, Entities, Owner ו-Status. חברו זאת לקריטיות הנכס ולזהות המשתמש. אירוע Medium בחשבון Privileged עשוי לקבל Priority גבוה יותר מאירוע High בנכס מבודד במעבדה.

שלב 2: פתיחת Incident והבנת הסיפור

קראו את Summary ואת רשימת ה-Alerts. כמה Alerts יכולים להיות תוצרים של אותו Rule או מוצרים שונים. בדקו אם Alert grouping איגד פעילות הגיונית או יצר Incident רחב מדי. שימו לב ל-Time range: Alert מאוחר יכול להרחיב את Incident ולהסתיר את תחילת הפעילות.

פתחו כל Alert מרכזי וקראו את Detection source, Description, Query או Evidence, Threshold ו-Entities. שאלו: מה התנאי שבאמת הופעל? האם הוא מבוסס Indicator, אנומליה, התנהגות או Correlation? מה רמת הוודאות? אילו נתונים לא נבדקו?

הימנעו מהטיית כותרת. Alert בשם “Compromised account” עדיין דורש אימות. שם דרמטי אינו Evidence.

שלב 3: Entities ויחסים

Entities הן עוגני החקירה. התחילו מהחשבון, Host או IP המרכזי ובדקו Insights: פעילות קודמת, Alerts נוספים, חברות בקבוצות, Sign-ins, Related hosts ו-Threat intelligence. אל תסתמכו על גרף בלבד; הוא מציג יחסים שהמערכת הצליחה למפות, לא את כל המציאות.

לכל Entity בנו כרטיס חקירה קצר: מזהה, סוג, Owner, קריטיות, Last known good, פעילות חריגה ומקורות נתונים. כאשר קיימים שמות דומים, ודאו שאתם עוקבים אחר Object ID או SID ולא רק Display name.

שאלות לחשבון משתמש

• האם החשבון Privileged או Service account?
• האם MFA הופעל ומה הייתה תוצאת האימות?
• האם ה-IP, המכשיר והמדינה מוכרים?
• האם קיימים כשלונות, Reset, Consent או שינויי הרשאה?
• האם המשתמש מאשר את הפעילות באמצעות ערוץ תקשורת אמין?

שאלות ל-Host

• האם התחנה מנוהלת ומעודכנת?
• מהו Process tree והאם Command line חריגה?
• האם קיימים Connections, Files או Persistence indicators?
• האם Alert נוסף מ-EDR או Network sensor תומך בסיפור?
• האם בידוד התחנה ישפיע על שירות קריטי?

שלב 4: Evidence ו-Timeline

Evidence מרכזת ממצאים שהמערכת קישרה ל-Incident. בדקו מקור, זמן וערך. הבחינו בין Raw event, Alert evidence ו-Enrichment. Indicator שמופיע ב-Threat Intelligence אינו מספיק אם לא נמצא קשר לפעילות של הנכס.

Timeline מסדרת Alerts, bookmarks ופעולות. השתמשו בה כדי לזהות התחלה, התרחבות ותגובה, אך בנו גם Timeline משלכם כאשר יש מקורות מחוץ ל-Sentinel. נרמלו UTC, תעדו Event time לעומת Ingestion time וסמנו פערים.

Tasks יכולים להבטיח שהאנליסט בודק שלבים נדרשים: אימות משתמש, חיפוש Sign-ins, בדיקת Host, פנייה ל-IT והוספת Classification. Task completed אינו אומר שהתוצאה תקינה; Ticket צריך לכלול מה נבדק ומה נמצא.

שלב 5: חיפוש משלים ב-Logs

ממשק Incident מספק הקשר, אך Query משלימה ב-Logs היא בדרך כלל לב החקירה. התחילו מ-Entity וחלון זמן, הרחיבו מעט לפני ואחרי הפעילות, וחפשו אירועים תומכים או סותרים.

let TargetUser = "student@contoso.example";
let StartTime = datetime(2026-08-01 08:30:00);
let EndTime = datetime(2026-08-01 10:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated asc

לאחר Authentication, בדקו Audit, Endpoint, DNS או Cloud activity לפי הסיפור. אל תרחיבו לכל הטבלאות בלי מטרה. כל Query צריכה לענות על שאלה: האם הייתה הצלחה? האם נוצר Session? האם בוצע שינוי הרשאה? האם התחנה יצרה Process או Connection חריג?

תרחיש: משתמש ו-IP חשודים

1. Incident כולל Alert על Sign-in ממדינה חדשה ו-Alert נוסף על Inbox rule שנוצרה.
2. Triage מזהה שהמשתמש עובד בכספים ושהפעילות החלה מחוץ לשעות הרגילות.
3. ב-Entities נבדקים IP, חשבון ואפליקציה. ה-IP אינו VPN מוכר, והחשבון אינו אמור לעבוד מהמדינה שזוהתה.
4. KQL מציגה כמה כשלונות, הצלחה עם MFA method חריג ושינוי Mailbox לאחר מכן.
5. האנליסט בודק Audit logs, Sessions, OAuth consents ופעילות משתמש נוספת. הוא פונה למשתמש דרך ערוץ מאומת.
6. לאחר אישור שהפעילות אינה שלו, האירוע מסווג True Positive ומוסלם ל-IR. פעולות Containment מבוצעות לפי Playbook והרשאה.
7. ה-Ticket מתעד Timeline, Queries, Evidence, פעולות, בעלים והמלצות לשיפור Detection.

סיווג, תגובה וסגירה

Classification צריך להבחין בין True Positive, False Positive ו-Benign Positive, בהתאם למודל הארגוני. הוסיפו Reason ו-Comment שמסבירים את הראיות. סגירה ללא נימוק פוגעת ב-Tuning ובמדדים.

אם נדרשת תגובה, בצעו אותה לפי Playbook: ביטול Sessions, Reset credentials, בידוד Endpoint, חסימת Indicator, שמירת ראיות או פנייה לצוותים. פעולות בלתי הפיכות או בעלות השפעה עסקית דורשות אישור מתאים.

לפני סגירה ודאו שה-Scope נבדק, שהפעילות אינה ממשיכה, שכל Tasks הושלמו, שהלקחים הועברו ל-Detection owner ושנפתחו Actions לתיקון Root cause.

Checklist חקירה

• ✓Owner ו-Priority הוגדרו.
• ✓נקראה לוגיקת כל Alert ולא רק הכותרת.
• ✓Accounts, Hosts ו-IPs אומתו באמצעות מזהים יציבים.
• ✓נבדקו Evidence ו-Timeline עם אזורי זמן נכונים.
• ✓בוצעו Queries משלימות מול המקורות הרלוונטיים.
• ✓הופרדו עובדות, הנחות ופרשנות.
• ✓Classification ו-Severity עודכנו עם נימוק.
• ✓פעולות תגובה תועדו עם זמן ומבצע.
• ✓נוצרו משימות המשך ל-Tuning או Hardening.

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

• להניח שכל Alerts ב-Incident שייכים לאותה תקיפה.
• להסתמך על Investigation graph בלי לבדוק Raw logs.
• להתעלם מ-Ingestion delay או מקור נתונים חסר.
• לסגור False Positive רק כי המשתמש מוכר.
• להריץ חיפושים רחבים ללא שאלת חקירה.
• לבצע Containment משמעותי בלי להבין השפעה עסקית.
• לסגור Incident בלי להעביר משוב ל-Rule owner.

סיכום ו-CTA

בנו במעבדה Incident מדומה עם Account, IP ושני Alerts. כתבו חמש שאלות חקירה, Query אחת לכל שאלה ו-Timeline קצר. המטרה אינה ללחוץ על כל האפשרויות בממשק, אלא להראות כיצד כל פעולה משנה החלטה. לאחר מכן עברו למאמר Analytics Rule כדי להבין כיצד Incident איכותי מתחיל ב-Detection שניתן לחקור.

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

מקורות

• Microsoft Learn — Investigate Microsoft Sentinel incidents in depth
• Microsoft Learn — Microsoft Sentinel incident investigation and case management
• Microsoft Learn — Microsoft Sentinel roles and permissions
• Microsoft Learn — Use tasks to manage incidents
• Microsoft Learn — Microsoft Sentinel overview and portal transition