Elastic Security: יצירת Detection Rule ו-Investigation Guide

שלב 1: הגדירו Use Case ובחרו Rule type

התחילו ממשפט התנהגותי: “לזהות Process מסוג מסוים שמופעל בהקשר שאינו צפוי על תחנות משתמש”. לאחר מכן הגדירו מה נחשב התאמה, איזה Context נדרש ומהו הסבר לגיטימי. רק אז בחרו Rule type.

בחירה לא נכונה יוצרת Query מסובכת או התראות לא יציבות. אם סדר האירועים הוא מהותי, EQL טבעית יותר מ-ES|QL. אם נדרש Aggregation, ES|QL או Threshold מתאימות יותר. Custom query טובה להתאמה ישירה לשדות.

שלב 2: ודאו ECS ו-Data readiness

Elastic Common Schema — ECS — מגדירה שמות ומבנים משותפים, כגון event.category, event.type, host.name, user.name, process.name, process.command_line ו-process.parent.name. Rule שתלויה בשדות שאינם ממופים באופן עקבי תעבוד על Integration אחד ותיכשל על אחר.

פתחו Sample events ובדקו: האם event.category הוא process? האם event.type כולל start? האם process.command_line נאסף או מוסתר? האם process.entity_id קיים? האם @timestamp הוא זמן האירוע או זמן הקליטה? תעדו Index patterns, Integrations, Version ו-Required fields. הרשימה של Required fields בממשק היא מידע למשתמש ואינה מתקנת מיפוי בפועל.

שלב 3: כתבו Query ממוקדת

בדוגמת מעבדה נרצה לזהות יצירת Process בשם lab-admin-tool.exe כאשר ה-Parent אינו תוכנת הניהול הצפויה. השם הוא דמיוני. ב-Custom query אפשר לכתוב KQL פשוט:

event.category:process and event.type:start and process.name:"lab-admin-tool.exe" and not process.parent.name:"approved-manager.exe"

ה-Query מצביעה על חריגה, אך אינה מוכיחה זדוניות. יש לבדוק Signer, Hash, Path, User, Host, Parent command line ושכיחות. לפני יצירת Rule הריצו אותה ב-Discover או Timeline על טווחים שונים. בדקו אם קיימים שדות Null, Variants בשם או Sources שאינם אמינים.

אם ההתנהגות דורשת רצף — לדוגמה Process ולאחריו Network connection מאותו process.entity_id — עברו ל-EQL. אם רוצים לסכם כמה Hosts הפעילו את הכלי או לחשב Count לפי Parent, ES|QL יכולה להיות מתאימה.

שלב 4: Schedule ו-Lookback

Rule כוללת Query, Schedule ו-Actions. Interval קובע כמה פעמים היא רצה. Lookback מרחיב את חלון החיפוש כדי לכסות Events שמגיעים באיחור. חלונות חופפים עלולים ליצור Alerts כפולים אם אין Deduplication או Suppression מתאימה. חלון קצר מדי מפספס נתונים מאוחרים.

בדקו Ingestion delay לפי מקור. Endpoint events עשויים להגיע כמעט בזמן אמת, בעוד מקור Cloud או Batch עשוי להתעכב. הגדירו Run every ו-Additional look-back מתוך מדידה. לאחר שינוי Pipeline או Integration מדדו מחדש.

שלב 5: Severity, Risk ו-MITRE

Severity מתארת את חומרת ההתאמה לפי ה-Use Case; Risk score מאפשר דירוג מספרי. אל תשתמשו ב-High לכל Rule. Process חריג על Lab host שונה מאותו Process על Domain Controller. אפשר להשתמש ב-Risk score override כאשר שדה אמין מספק Context, אך יש לבדוק Missing values ו-Range.

מיפוי MITRE ATT&CK צריך להתאים להתנהגות שה-Rule מזהה, לא לתרחיש התקיפה המלא שאתם מדמיינים. Rule שמזהה Process execution לא בהכרח מוכיחה Persistence או Exfiltration.

שלב 6: Suppression ו-Exceptions

Alert suppression מקבצת התאמות חוזרות לפי שדות כדי לצמצם נפח. היא אינה תחליף ל-Query נכונה. Suppression לפי host.name יכולה להסתיר התפתחות אם אותו Host מייצר כמה Behaviors שונים. בחרו שדות שמייצגים את יחידת החקירה, למשל host.id ו-process.hash, והגדירו Window מתוך Baseline.

Exceptions מוציאות התאמות ידועות. צרו Exception מצומצמת: Hash חתום, Path, Parent מסוים ו-Host group מוגדר, במקום החרגת process.name בכל הארגון. הוסיפו Comment, Owner ותאריך Review. כאשר ניתן, העדיפו Exception list מנוהלת על פני Query עם עשרות NOT clauses.

שלב 7: כתבו Investigation Guide

Investigation Guide היא מסמך Markdown שמצורף ל-Rule ומופיע לצד Alert. לפי Elastic, מדריך טוב בנוי סביב Triage, Analysis ו-Response, מתחיל בהקשר ולא ברשימת Commands, ומפנה לשדות Alert, Timeline queries ו-Osquery כאשר הדבר מתאים.

אפשר להפנות לשדות דינמיים כגון host.name או user.name ולהוסיף כפתורי Timeline כאשר הגרסה והרישוי תומכים. שמרו את המדריך קצר וסריק. האנליסט עובד תחת לחץ; פסקאות ארוכות ללא סדר יישארו לא נקראות.

שלב 8: Validation ו-Tuning

1. הריצו Preview או Query היסטורית וסמנו דוגמאות True, False ו-Benign Positive.
2. בדקו Rule על Positive sample מדומה ועל Negative sample. ודאו שהיא נכשלת כאשר שדה חסר ולא יוצרת התאמה שגויה.
3. הפעילו תחילה בלי Response מסוכנת. מדדו Alert volume, זמני חקירה ואיכות Context.
4. בדקו Rule execution status, gaps, permissions ו-API key. Rules רצות בהרשאות המשתמש האחרון שערך אותן.
5. כוונו Query, Schedule, Suppression ו-Exceptions בנפרד כדי לדעת מה פתר את הבעיה.
6. בצעו Regression test לאחר עדכון Integration, ECS mapping או Elastic version.

Checklist

• ✓Rule type מתאים לשאלה.
• ✓Indices, Data view, ECS ו-Required fields נבדקו.
• ✓Query מחזירה יחידת חקירה ברורה.
• ✓Schedule ו-Lookback מכסים Delay בלי כפילות חריגה.
• ✓Severity, Risk ו-MITRE תואמים להתנהגות.
• ✓Suppression ו-Exceptions מצומצמות ומתועדות.
• ✓Investigation Guide כולל Triage, Analysis ו-Response.
• ✓קיימים Owner, Review date, Metrics ו-Regression test.

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

• לבחור EQL, KQL או ES|QL לפי העדפה ולא לפי השאלה.
• להעתיק Prebuilt Rule בלי לבדוק Data requirements.
• להניח ש-ECS ממופה בגלל שהשדה מופיע בחלק מהאירועים.
• להגדיל Lookback בלי להבין כפילויות.
• ליצור Exception רחבה על Process name.
• להפעיל Response אוטומטית לפני Validation.
• לכתוב Investigation Guide שמכיל רק “בדוק אם זדוני”.

סיכום ו-CTA

בחרו Process דמיוני במעבדה ובנו Rule מלאה: Data contract, Query, Schedule, Risk, Exception אחת, Investigation Guide ו-Test cases. לאחר מכן תנו לאנליסט אחר לחקור Alert בלי הסבר בעל פה. אם המדריך והשדות אינם מספיקים, שפרו את ה-Rule לפני שמוסיפים עוד לוגיקה.

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

מקורות

• Elastic Docs — Create a detection rule
• Elastic Docs — Detection rule concepts
• Elastic Docs — Rule type guides
• Elastic Docs — Write investigation guides
• Elastic Docs — Prebuilt rule components