EQL מול ES|QL: מתי משתמשים בכל שפה בחקירות אבטחה

מה EQL פותרת

EQL מתאימה במיוחד לרצפים מסודרים בזמן. Rule יכולה לחפש Process start ולאחריו Network event מאותו process.entity_id. אפשר לקשר Events לפי שדה משותף באמצעות by, להגדיר Timestamp, Event category ו-Tiebreaker, ואף לחפש Missing events בתרחישים מסוימים.

היתרון הוא שהלוגיקה משקפת סיפור: שלב א התרחש לפני שלב ב. במקום לסכם שני סוגי Events באותו חלון ולהניח שהם קשורים, EQL בודקת את הסדר ואת Key הקישור. לכן היא שימושית ל-Process chains, Authentication sequences, File ואז Process, או Event שמצופה להגיע ואינו מגיע.

sequence by process.entity_id
  [process where event.type == "start" and process.name == "lab-tool.exe"]
  [network where event.type == "connection" and network.direction == "egress"]

הדוגמה משתמשת בשם דמיוני ובנתוני מעבדה. היא מחפשת Process ולאחריו Network connection מאותה ישות Process. היא אינה מוכיחה זדוניות; יש לבדוק Destination, Signer, Parent, User ו-Host context.

מה ES|QL פותרת

ES|QL פועלת על טבלאות ותומכת בעיבוד Pipeline. מתחילים ב-FROM, מסננים ב-WHERE, יוצרים שדות ב-EVAL, מסכמים באמצעות STATS ... BY, ממיינים ומציגים Columns. Detection מסוג ES|QL הופכת כל שורת Result ל-Alert.

היא מתאימה כאשר השאלה היא כמותית או דורשת Transformation: כמה Hosts הפעילו כלי מסוים, אילו Users יצרו נפח חריג, מהו היחס בין Success ל-Failure, או איזה שדה מחושב עובר Threshold. היא אינה הבחירה הטבעית כאשר סדר Event א ואז ב הוא העיקר; Elastic ממליצה להשתמש ב-EQL לרצפים מסודרים.

FROM logs-endpoint.events.*
| WHERE event.category == "process" AND event.type == "start"
| WHERE process.name == "lab-tool.exe"
| STATS executions = COUNT(*), hosts = COUNT_DISTINCT(host.id) BY user.name
| WHERE executions >= 5

Query זו מסכמת הפעלות לפי משתמש ומסננת Users עם חמש הפעלות ומעלה. היא עונה על שאלה שונה מה-EQL: “מי הפעיל את הכלי כמה פעמים ובכמה Hosts?”, לא “האם Process מסוים יצר Connection אחריו”.

Sequence מול Pipeline

אותו תרחיש בשתי גישות

נניח שהתרחיש הכללי הוא כלי מעבדה בשם lab-tool.exe שעשוי לפעול בהקשר חריג. קודם מגדירים את השאלה המדויקת:

• שאלה EQL: האם Instance מסוים של הכלי התחיל ואז יצר Network connection?
• שאלה ES|QL: אילו משתמשים או Hosts הפעילו את הכלי בתדירות חריגה?
• שאלה Custom query: האם הכלי הופעל בכלל עם Parent לא צפוי?

שלוש השאלות יכולות לתמוך באותו Use Case, אך אינן שקולות. EQL מספקת קשר כרונולוגי. ES|QL מספקת Baseline או Aggregation. Custom query מספקת התאמה ישירה. Detection architecture טובה עשויה להשתמש בכמה Rules, אבל יש להימנע מכפילויות ולהגדיר מה כל Rule מוסיפה.

דרישות נתונים

EQL דורשת Timestamp אמין ו-Event category. רצפים נהנים מ-Tiebreaker כאשר Events חולקים אותו זמן. שדה הקישור צריך להיות יציב: process.entity_id עדיף בדרך כלל על process.name, משום שכמה Processes יכולים לשתף שם. אם entity_id חסר או משתנה בין Sources, Sequence לא תעבוד כמצופה.

ES|QL דורשת שה-Indices יהיו נגישים ושדות יתאימו לפקודות. Aggregation על Field מסוג text במקום keyword, ערכי Null או Schema לא עקבי עלולים לשנות Results. ב-Detection Rule יש להביא בחשבון Deduplication של Alerts, Schedule ו-Lookback. יכולות ודרישות Metadata מסוימות משתנות בין גרסאות Elastic, ולכן יש לבדוק את תיעוד הגרסה.

יתרונות ומגבלות

יתרונות EQL

• מבטאת סדר Event באופן קריא.
• מקשרת שלבים לפי Entity משותפת.
• מתאימה ל-Process lineage ולרצפים התנהגותיים.
• יכולה לבטא היעדר Event צפוי בתרחישים נתמכים.

מגבלות EQL

• אינה הכלי הטבעי ל-Aggregation מורכבת ול-Statistics.
• תלויה מאוד ב-Timestamp, event.category ו-Key יציב.
• Sequence רחבה מדי עלולה להיות יקרה או רועשת.

יתרונות ES|QL

• Pipeline ברור לסינון, חישוב ו-Aggregation.
• יצירת שדות נגזרים באמצעות EVAL.
• STATS ... BY מאפשרת Detection על ערכים מסוכמים.
• מתאימה ל-Hunting ודוחות טבלאיים.

מגבלות ES|QL

• אינה מחליפה EQL כאשר סדר Events הוא הדרישה המרכזית.
• כל Row הופכת ל-Alert, ולכן Grain של התוצאה חייב להיות מתוכנן.
• Aggregation יכולה לאבד Raw event context אם Investigation Guide אינה מספקת Drill-down.

מטריצת בחירה

תרגיל מעבדה

1. צרו חמישה Process events דמיוניים ושני Network events עם process.entity_id.
2. כתבו EQL שמחזירה Sequence רק כאשר Network מגיע אחרי Process על אותה ישות.
3. כתבו ES|QL שמסכמת מספר הפעלות לפי user.name ו-host.id.
4. שנו Timestamp של Event אחד ובדקו מה קורה לרצף.
5. הסירו process.entity_id מאירוע ובדקו כיצד איכות הנתונים משפיעה.
6. כתבו לכל Query משפט: מה היא מוכיחה, מה אינה מוכיחה ומהו Drill-down נדרש.

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

• להשתמש ב-ES|QL כדי לחקות Sequence מורכבת כאשר EQL מתאימה.
• להשתמש ב-EQL לשאלה שהיא Count פשוט.
• לקשר לפי process.name במקום Entity יציבה.
• להתעלם מ-Time zone, Ingestion delay ו-Tiebreaker.
• להפוך Aggregation לשורת Alert בלי שדות שמאפשרים חקירה.
• להעתיק Query מגרסה אחרת בלי לבדוק Syntax ודרישות Metadata.

סיכום ו-CTA

לפני כתיבת Query, כתבו את השאלה על דף: האם אני מחפש Event, Sequence, Count, Transformation, IOC או Anomaly? הבחירה בשפה כמעט נובעת מהתשובה. בתרגול HPI מומלץ לשמור את אותה Telemetry ולהריץ עליה EQL ו-ES|QL, כדי לראות כיצד מודל השאלה משנה את תוצאת החקירה.

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

מקורות

• Elastic Docs — Event correlation (EQL) rules
• Elastic Docs — ES|QL rules
• Elastic Docs — Rule type guides
• Elastic Docs — Choose the right rule type
• Elastic Docs — ES|QL for security use cases