Splunk Enterprise Security: מתהליך Detection ועד Investigation

מ-Detection ל-Finding או Notable

Detection ב-Splunk ES מבוססת בדרך כלל על Correlation Search או על מנגנון Detection חדש יותר בהתאם לגרסה. החיפוש בוחן נתונים, מחזיר Results ומפעיל Response. בתרחיש מסורתי ה-Response יוצר Notable או Finding. בתרחיש RBA, Detection יכולה לכתוב Risk event לאינדקס הסיכון במקום לפתוח Case מיידי.

הבחירה הזו משנה את יחידת העבודה. התראה מסורתית אומרת: “התרחש Pattern מסוים עכשיו”. RBA אומרת: “לישות מסוימת נוספו כמה אינדיקציות לאורך זמן, והצטברותן עברה תנאי שמצדיק חקירה”. כך ניתן לחבר אותות חלשים — למשל Login חריג, הרצת כלי ניהול ותקשורת ליעד חדש — למקרה אחד בעל הקשר עשיר יותר.

Risk objects ו-Risk score

Risk object הוא ישות שאפשר לצבור עליה סיכון: משתמש, מערכת, מכשיר או סוג מותאם. שני שדות יסוד הם risk_object והסוג שלו. אם אותו משתמש מופיע פעם כ-tair, פעם כ-tair@company.example ופעם בכתיב אחר, נרמול לא עקבי עלול לפצל את הסיפור לשלוש ישויות או לאחד ישויות שאינן זהות. לכן איכות Asset and Identity data היא חלק מה-Detection, לא נושא אדמיניסטרטיבי צדדי.

Risk score הוא אמצעי תעדוף. הוא אינו הסתברות מתמטית לפריצה ואינו תחליף לראיות. יש לבדוק מי נתן את הציון, מה היו Risk modifiers, האם האירוע צפוי בסביבה, מה קריטיות הנכס ומהו חלון הזמן. Rule שמוסיף 80 נקודות לכל פעולה נפוצה ייצור “אינפלציית סיכון” ויפגע באמון האנליסטים.

Risk incident rule או Finding-based detection יכולה לאגד Risk events לפי ישות, Threat object או תנאי מצטבר. האנליסט צריך לפתוח את האירועים התורמים ולא להסתפק בסכום. שני Scores זהים יכולים לייצג סיפורים שונים לחלוטין: חמישה אותות בינוניים ממקורות בלתי תלויים, או עשרים חזרות של אותו אירוע רועש.

בדיקת Assets ו-Identities

Splunk ES יכולה להעשיר Findings באמצעות רשימות Asset ו-Identity. העשרה טובה מוסיפה קריטיות, בעלים, מחלקה, קטגוריית מערכת, ציפיות תפעוליות ונתונים נוספים. לפני חקירה עמוקה בדקו האם הישות מזוהה נכון: האם ה-IP שייך ל-VPN, האם Host הוא שרת Production, האם המשתמש הוא Service account, והאם קיימת תווית Privileged.

יש להבחין בין עובדה להעשרה. src=203.0.113.10 הוא ערך מהאירוע. “VPN Gateway” הוא Context שמגיע מ-Lookup. אם ה-Lookup ישן, גם ההחלטה תהיה שגויה. תעדו את מקור ההעשרה ואת מועד העדכון כאשר הוא משפיע על סגירה או הסלמה.

Workflow חקירה מעשי

1. קראו את שם ה-Detection, התיאור, ה-Owner, ה-MITRE mapping וה-Drill-down. נסחו במשפט אחד מה החוק טוען.
2. זהו את ה-Entity המרכזית ואת טווח הזמן. בדקו אם היא User, System או ישות מותאמת, והאם קיימת קריטיות עסקית.
3. פתחו את האירועים התורמים. ודאו שהם קיימים, שהשדות נכונים ושאין כפילות בגלל Lookback או Ingestion delay.
4. בנו Timeline כרונולוגי. הוסיפו Authentication, Endpoint, Network, DNS, Cloud ו-Email לפי התרחיש.
5. חפשו Related findings על אותה ישות, אותו IP, Hash, Process או Threat object. אל תגבילו את החיפוש רק לכותרת המקורית.
6. בדקו הסברים לגיטימיים: פעילות IT מאושרת, Scanner, Automation, שינוי מערכת, VPN או כלי ניהול מוכר.
7. סווגו את הממצא לפי הראיות: True Positive, Benign Positive, False Positive, Duplicate או מצב ביניים המצריך הסלמה.
8. עדכנו Owner, Status, Urgency/Disposition ו-Notes. אם נפתחה Investigation, צרפו Artifacts, משימות ופעולות תגובה.

תרחיש מעבדה: סיכון מצטבר למשתמש

נניח שבמשך 40 דקות מתקבלים ארבעה Risk events על המשתמש lab.user. הציונים להלן הם דוגמה בלבד. המטרה אינה לסכום מספרים בעיניים, אלא להבין האם האירועים קשורים לאותה פעילות.

החקירה מתחילה ב-Drill-down לכל אות. אם ה-Login הגיע מ-VPN ארגוני והמכשיר מנוהל, אין לסגור מיד: עדיין צריך לבדוק את PowerShell וה-DNS. אם ה-PowerShell הופעל על ידי מערכת ניהול מוכרת, ה-Share תואם לתפקיד והדומיין שייך לעדכון תוכנה, ייתכן Benign Positive. אם כמה אותות מתחברים לאותו Host ולתהליך לא מוכר, יש להסלים ולשקול Containment לפי Playbook מאושר.

סגירה ומשוב לזיהוי

סגירה טובה כוללת מה נבדק, אילו Events תמכו בהחלטה, אילו מקורות לא היו זמינים ומהו ההסבר. ב-RBA חשוב לציין אילו Risk events היו שימושיים ואילו יצרו רעש. כך Detection engineer יכול לשנות Risk modifiers, להוסיף Entity zones, לשפר Normalization או לעדכן תנאי Aggregation.

אל תבצעו Exclusion רחב על משתמש, Host או IP רק כדי להקטין Volume. העדיפו Exception מצומצמת בזמן ובתנאים, עם Owner ותאריך תפוגה. לאחר שינוי הריצו Regression test על True Positives היסטוריים ועל תרחישי מעבדה.

Checklist לאנליסט

• ✓הבנתי מה ה-Detection טוענת ומה היא אינה מוכיחה.
• ✓בדקתי את כל האירועים התורמים ולא רק את Score הסופי.
• ✓אימתתי Risk object, סוג ישות ונרמול שם.
• ✓בדקתי Asset/Identity enrichment ומקורו.
• ✓בניתי Timeline וחיפשתי Findings קשורים.
• ✓הפרדתי עובדות, הנחות והסבר לגיטימי.
• ✓תיעדתי Disposition וראיות בצורה שאנליסט אחר יכול להמשיך ממנה.
• ✓העברתי משוב ממוקד ל-Detection ולא יצרתי Exclusion גורף.

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

• להתייחס ל-Risk score כהוכחה לפגיעה.
• לחקור רק את האירוע בעל הציון הגבוה ביותר.
• לאחד זהויות שונות או לפצל אותה זהות בגלל Normalization לקוי.
• להניח שהעשרת Asset נכונה בלי לבדוק עדכניות.
• לסגור Finding בלי Drill-down לאירועים הגולמיים.
• לכתוב Notes כלליים כמו “נבדק ותקין” ללא ראיות.
• לבצע Tuning שמעלים את הסימפטום אך לא מטפל בשורש הרעש.

סיכום ו-CTA

קחו Detection אחד במעבדת Splunk ES ובנו עבורו דף חקירה: היפותזה, Risk object, אירועים תורמים, Drill-down, מקורות העשרה, תנאי סגירה ומשוב ל-Tuning. התרגיל מחבר SPL לדרך העבודה של אנליסט. במסלול Cybersecurity & AI של HPI ניתן לתרגל את אותו מעבר מלוג גולמי לחקירה מתועדת, תוך שימוש בסביבות מורשות ובנתונים מדומים בלבד.

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

מקורות

• Splunk Documentation — How risk-based alerting works in Splunk Enterprise Security
• Splunk Documentation — Triage findings and finding groups in Splunk Enterprise Security
• Splunk Documentation — Review investigation details in Splunk Enterprise Security
• Splunk Documentation — Manage assets and identities to enrich findings
• Splunk Documentation — Risk notables in Splunk Enterprise Security