החלת הצטרפות בחיפוש ובמרכזי בקרה

נתמך ב:

הצטרפות עוזרת לקשר בין נתונים מכמה מקורות כדי לספק יותר הקשר לחקירה. קישור של אירועים קשורים, ישויות ונתונים אחרים מאפשר לחקור תרחישי תקיפה מורכבים ולהציג מגמות באופן חזותי.

במאמר הזה מוסבר איך להשתמש בפעולת הצירוף בשדה חיפוש ובחלוניות של לוח הבקרה ב-Google SecOps. הוא כולל את סוגי ההצטרפות הנתמכים, תרחישים לדוגמה ושיטות מומלצות.

מושגים מרכזיים בנושא צירופים

אפשר ליצור צירוף על ידי קישור מקורות נתונים באמצעות משתני placeholder משותפים או הצהרות שוויון מפורשות (לדוגמה, $e1.hostname = $e2.hostname). כשמגדירים צירוף בקטע match של שאילתה מבוססת-סטטיסטיקה, צריך להשתמש במשתני placeholder.

בדוגמאות הבאות מוצגות דרכים לקשר מקורות נתונים באמצעות שני שדות עם סימן שוויון (=) ומשתנה placeholder משותף.

  • דוגמה 1: צירוף מרומז באמצעות משתני placeholder

    events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

  • דוגמה 2: צירוף מפורש באמצעות שוויון ומשתני מיקום

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

בדוגמאות שבקטע הזה מוצג תחביר שמשמש בחיפוש.

כברירת מחדל, השאילתות בחיפוש הן לא תלויות באותיות רישיות.

צירוף של אירוע לאירוע

  • שילוב בין אירועים מקשר בין שני אירועים שונים של מודל נתונים אוניברסלי (UDM). שאילתת הדוגמה הבאה מקשרת אירוע USER_LOGIN לאירוע אחר כדי למצוא את שם המארח (altostrat) שהמשתמש יצר איתו אינטראקציה, על סמך כתובת IP משותפת:

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m

הצטרפות לאירוע ב-ECG

  • הצטרפות של אירוע ל-ECG מקשרת אירוע UDM לישות מתוך גרף הקשר של הישות (ECG). שאילתת הדוגמה הבאה מוצאת אירוע NETWORK_CONNECTION ואירוע ASSET מגרף הישויות שחולקים את אותו שם מארח בחלון של שעה אחת:

    events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1

Datatable-event join

  • איחוד של אירועים עם טבלת נתונים מקשר בין אירועים ב-UDM לבין רשומות בטבלת נתונים מותאמת אישית. האפשרות הזו שימושית לבדיקת נתונים של אירועים בזמן אמת מול רשימה שהוגדרה על ידי המשתמש, כמו כתובות IP זדוניות ידועות או גורמים זדוניים. בשאילתה לדוגמה הבאה, מתבצע צירוף של אירועי NETWORK_CONNECTION לטבלת נתונים כדי למצוא קשרים שכוללים כתובות IP ספציפיות מהרשימה:

    $ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h

שימוש בפסוקית IN עם טבלאות נתונים

אפשר גם להשתמש בפסוקית in כדי לבדוק אם ערך של שדה קיים בעמודה של טבלת נתונים. התחביר הזה נתמך בכל מקורות הנתונים (לדוגמה, ioc.type in %abc.type) ומספק דרך נוחה לסנן אירועים על סמך רשימות הפניה בלי להגדיר משתני placeholder מפורשים לצירוף.

תרחישים נפוצים לדוגמה

בקטע הזה מפורטות כמה דרכים נפוצות לשימוש בצירופים.

זיהוי גניבה ושימוש בפרטי כניסה

יעד: למצוא מקרים שבהם משתמש מחובר בהצלחה, ואז מוחק במהירות קובץ מערכת קריטי. יכול להיות שמדובר בהשתלטות על חשבון או בפעילות זדונית של משתמשים עם גישה פנימית.

סוג הצירוף: צירוף של אירוע לאירוע

תיאור: השאילתה הזו מחברת בין שני אירועים נפרדים שלא מעוררים חשד כשלעצמם, אבל מעוררים חשד רב כשהם מתרחשים יחד. המערכת מחפשת קודם אירוע USER_LOGIN ואז אירוע FILE_DELETION. אליהם מצטרף user.userid נפוץ עם חלון זמן קצר.

  • שאילתה לזיהוי גניבת פרטי כניסה

    // Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

זיהוי חיבורים מסוכנים מנכסים קריטיים

המטרה: להעשיר נתונים חיים של רשת במידע על נכסים כדי למצוא חיבורים יוצאים משרתים שלא אמורים לתקשר עם דומיינים חיצוניים עם שכיחות נמוכה (לדוגמה, שרת של מסד נתונים בייצור).

סוג ההצטרפות: הצטרפות לאירוע אק"ג

תיאור: יכול להיות שחיבור יחיד לרשת לדומיין נדיר לא יקבל עדיפות גבוהה. עם זאת, השאילתה הזו מגדילה את החשיבות של האירוע הזה על ידי צירוף שלו לגרף הקשר של הישות (ECG). הוא מחפש באופן ספציפי אירועים NETWORK_CONNECTION שמגיעים מנכסים שמסומנים כ-Critical Database Server (שרת מסד נתונים קריטי) בתרשים הישויות.

  • שאילתה לגבי חיבורים מסוכנים

    events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

חיפוש של אינדיקטורים של פריצה (IOC) של גורמים זדוניים

יעד: חיפוש פעיל של אינדיקטורים לפריצה (IoC) על ידי בדיקה של כל שאילתות ה-DNS הפעילות מול רשימה של דומיינים שידוע שהם בשימוש של גורם איום ספציפי.

סוג הצירוף: צירוף של טבלת נתונים ואירוע

תיאור: צוות מודיעין איומי הסייבר שלכם מתחזק טבלת נתונים בשם ThreatActor_Domains שבה מפורטים דומיינים זדוניים. השאילתה הזו מאחדת את כל האירועים NETWORK_DNS_QUERY בזמן אמת עם טבלת הנתונים הזו. הוא מציג באופן מיידי כל מקרה שבו מארח ברשת מנסה לפתור דומיין מרשימת המודיעין בנושא איומים.

  • שאילתת חיפוש של IOC שקשור לגורם זדוני

    // Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

הצטרפות למרכזי בקרה

לוחות הבקרה תומכים במגוון רחב יותר של מקורות נתונים ובחלונות זמן ארוכים יותר של קורלציה בהשוואה לחיפוש. בניגוד לשאילתות SQL רגילות, ב-YARA-L 2.0 לא נעשה שימוש בהצהרות JOIN מפורשות. במקום זאת, מקורות הנתונים מקושרים באמצעות מתאם של משתני placeholder משותפים או באמצעות שאילתות רב-שלביות.

תלות באותיות רישיות

שאילתות בלוח הבקרה הן תלויות אותיות רישיות. כדי לבצע חיבור או חיפוש לא תלויי-אותיות במרכז בקרה, משתמשים במקש הצירוף nocase.

מקורות נתונים נתמכים

במרכזי בקרה, אפשר לצרף נתונים משילובים נתמכים של מקורות נתונים. (לא ניתן לשלב את כל השילובים של מקורות נתונים בשאילתה אחת).

כל הפניה לנתונים בשאילתה של לוח בקרה עם כמה מקורות חייבת לכלול את התחילית של מסווג YARA-L (לדוגמה, $u1), ולא רק את השדות המאוחדים. כך המערכת יכולה לזהות בצורה נכונה את הבעלות על השדות במקורות נתונים חופפים.

שילובי הצטרפות נתמכים

שאילתות איחוד (join) מאפשרות לכם ליצור קורלציה בין אירועי UDM, הקשר של ישויות וטבלאות נתונים בלוחות בקרה מובנים. כדי לשמור על ביצועי המערכת, חשוב לעיין בשילובים הנתמכים ובמגבלות הטכניות שמופיעים בקטע הזה לפני שיוצרים את השאילתות.

  • אירוע UDM לאירוע UDM (אירוע מרובה)
  • UDM event to entity context
  • אירוע UDM לטבלת נתונים

  • פנייה להיסטוריית פניות: השילוב הזה מוגבל למקור אחד בדיוק של case ולמקור אחד בדיוק של case_history. אי אפשר לכלול בצירוף הזה מקורות נתונים אחרים.

מידע על מגבלות ואמצעי הגנה מופיע במאמר מגבלות ואילוצים טכניים.

דוגמה: Join case and case_history

אפשר לקשר בין המטא-נתונים של הכרטיס לבין היסטוריית הפעילות שלו באמצעות הצטרפות למזהה הכרטיס הייחודי.

  • בדוגמה הבאה מתבצע איחוד של מקורות הנתונים case ו-case_history כדי לספור את המספר הכולל של פעולות היסטוריות לכל מקרה בעדיפות גבוהה.

      // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

תרחיש שימוש מתקדם: חישוב MTTR

למדדים מורכבים יותר כמו זמן ממוצע לפתרון (MTTR) או זמן ממוצע לסגירת כרטיס (MTTC), אפשר להשתמש בשאילתה רב-שלבית. כך אפשר לחשב את משך הזמן של כל מקרה בנפרד בשלב הראשון, ואז לחשב את הממוצע של משכי הזמן האלה באופן גלובלי בבלוק התוצאה הסופית.

  • השאילתה הבאה מחשבת את הזמן הממוצע לסגירת בקשות תמיכה (בדקות) בכל הבקשות ב-Default Environment.

    stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

שיטות מומלצות

כדי לשפר את הביצועים של שאילתות הצירוף ולוודא שהן מעובדות ביעילות, מומלץ לפעול לפי השיטות המומלצות האלה לסינון אירועים ולניהול היקף החיפוש.

שימוש במסננים ספציפיים כדי לצמצם את מספר האירועים

שאילתות עם הצטרפות יכולות להיות עתירות משאבים כי הן משלבות הרבה תוצאות.

  • מסננים רחבים וכלליים עלולים לגרום לשגיאות בשאילתות, לפעמים אחרי עיכוב ארוך. לדוגמה:

    • target.ip != ""

    • ‫metadata.event_type = "NETWORK_CONNECTION" (אם סוג האירוע הזה נפוץ מאוד בסביבה שלכם)

  • מומלץ לשלב בין מסננים כלליים למסננים ספציפיים יותר כדי לצמצם את המספר הכולל של האירועים שהשאילתה צריכה לעבד. מסנן רחב כמו target.ip != "" צריך להיות משולב עם מסננים ספציפיים יותר כדי לשפר את הביצועים של השאילתה. לדוגמה:

    $e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m

אם השאילתה עדיין פועלת לאט, אפשר גם לצמצם את טווח הזמן הכולל של השאילתה (לדוגמה, מ-30 יום לשבוע אחד).

מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש ב-YARA-L.

מגבלות טכניות

כשמשתמשים בצירופים בחיפוש ובמרכזי בקרה, חלות המגבלות הבאות:

מגבלות על חלון ההתאמה ועל השאילתות

חלון ההתאמה מגדיר את מסגרת הזמן הספציפית שבה האירועים יכולים להיות קשורים זה לזה. זה שונה מטווח הזמן של החיפוש שבוחרים בממשק המשתמש.

החיפוש עבר אופטימיזציה לחקירות מהירות או בזמן אמת, בפרקי זמן קצרים יותר.

מגבלת השאילתות Usage
עד 48 שעות (יכול להיות ששאילתות מסוימות יתמכו בחלונות זמן ארוכים יותר). הצלבת אירועים בחקירות מהירות.

מגבלות במרכזי בקרה

לוחות הבקרה תומכים בניתוח היסטורי לטווח ארוך.

סוג ההצטרפות מגבלת השאילתות Usage
‫UDM-to-UDM ו-UDM-to-Entity 31 ימים שאילתות טלמטריה בנפח גבוה.
Case-to-CaseHistory 90 ימים שאילתות למעקב אחרי מחזור החיים.
תצורות נתמכות אחרות עד 365 ימים חזרה למקורות שאינם מבוססים על UDM או על מדדים (לדוגמה, מדדי הטמעה).

מגבלות על מקורות נתונים וטבלאות

המספר המקסימלי של מקורות נתונים וטבלאות שאפשר לצרף בשאילתה אחת תלוי אם אתם משתמשים בחיפוש או במרכזי בקרה.

מגבלות החיפוש

  • אפשר להשתמש בעד שני אירועים של UDM בכל שאילתה.
  • אפשר להשתמש באירוע אחד של אק"ג לכל שאילתה.
  • אפשר להשתמש בעד שני Datatables לכל שאילתה.
  • אי אפשר להצטרף לטבלת נתונים ישירות לטבלת הקשר של ישות. צריך להשתמש באירוע UDM כגשר ביניים (לדוגמה, מתאמים בין $event.target.hostname לבין $datatable.hostname וגם $asset.graph.entity.asset.hostname).

הגבלות על מרכז הבקרה

סוג ההצטרפות מספר טבלאות האירועים המקסימלי (UDM או טבלת נתונים) מספר מקסימלי של טבלאות ישויות
ריבוי אירועים (UDM ל-UDM) 2 לא רלוונטי
UDM to entity 2 1
UDM to datatable 2 לא רלוונטי
שאילתות מרובות שלבים 2 1

ביצועים ושכבות הגנה

המערכת עוקבת אחרי שאילתות מורכבות של צירוף כדי לזהות צריכת משאבים מוגזמת. כדי להגן על הביצועים הכוללים של הסביבה, המערכת עשויה להשהות או להכניס להסגר באופן אוטומטי שאילתות שחורגות מספיות הבטיחות של המשאבים.

אם שאילתה נכשלת או מחזירה שגיאות שמציינות שהיא חרגה ממגבלות המשאבים, כדאי לנסות את האופטימיזציות הבאות:

  • מצמצמים את חלון הזמן של השאילתה.
  • כדי להקטין את גודל מערך הנתונים לפני ההצטרפות, מוסיפים מסננים ספציפיים יותר.
  • פשטו את הצבירות.

הגבלות על ממשקי API ועל סוגי שאילתות

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.