תחילת העבודה עם YARA-L 2.0 ב-SecOps

נתמך ב:

‫YARA-L 2.0 היא שפת שאילתות ייחודית ומובנית מאוד שמפעילה את Google Security Operations לכל החיפושים, לוחות הבקרה וזיהוי האיומים שמבוסס על כללים. במסמך הזה מוסבר על המבנה הבסיסי של YARA-L, ומוצגים שלבים מעשיים לשימוש בו. המדריך הזה מיועד לכל מי שרוצה להשתמש ב-YARA-L, בין אם מדובר באנליסט אבטחה שמחפש איומים או בمهندس זיהוי שבונה לוגיקה חדשה וחזקה.

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

לפני שמתחילים

הסבר על המבנה של YARA-L

כל שאילתת YARA-L מחולקת לקטעים נפרדים עם שמות, שקובעים את ההתנהגות של השאילתה.

המבנה הזה מאפשר ניתוח רב-שלבי ומתאם.

הזמנה קטע כללים חיפוש/מרכזי בקרה תיאור
1 meta חובה אופציונלי מגדיר מטא-נתונים תיאוריים לכלל, כמו מחבר, תיאור וחומרה. לדוגמה, מחבר (security team), תיאור (Detects multiple failed user logins within 10-minute windows) וחומרה (High).ראו תחביר של קטע meta.
2 events חובה חובה מגדיר ומסנן את האירועים שצריך לעקוב אחריהם: התחברויות של משתמשים, התחברויות של משתמשים שנכשלו (משתני אירועים) וקישורים למשתנה של התאמת משתמשים (משתני פלייסהולדר). מצהיר על כל מקורות הנתונים (בעיקר אירועים) שצריך להביא בחשבון ומסנן אותם באמצעות שדות UDM. תחביר של קטע events
3 match חובה אופציונלי מקבץ לפי אירועים ומאפשר לציין את חלון הזמן הנתמך (לדוגמה, by 5m). נדרש במקרים מסוימים של חיפושים סטטיסטיים שבהם מתבצע צבירה. נדרש לשאילתות של קורלציה בין כמה אירועים. ב-match, חובה לציין את השעה בכללים, אבל לא חובה לציין אותה בחיפוש ובלוחות הבקרה.

הערה: אם מחריגים קטע match, הכלל יכול להתאים לאירוע יחיד.match
4 outcome אופציונלי אופציונלי חישוב מדדים חיוניים וקבלת תובנות (לדוגמה, count(), avg()). ראו תחביר של קטע outcome.
5 condition חובה אופציונלי ההגדרה הזו קובעת את הלוגיקה שצריכה להתקיים כדי להחזיר תוצאות (בחיפוש) או להפעיל התראה (בכלל). הפונקציה מעריכה את הקריטריונים של משתנה השאילתה כדי לקבוע אם התוצאה רלוונטית (לדוגמה, $event >5). ראו תחביר של קטע condition.
6 options אופציונלי אופציונלי מאפשר להפעיל או להשבית התנהגות ספציפית של כלל. תחביר של קטע options
7 dedup לא רלוונטי אופציונלי הפונקציה מסירה אירועים כפולים על ידי קיבוץ שלהם על סמך משתנים מרכזיים או נתיבי אירועים (לדוגמה, target.user.userid,‏ target.ip,‏ principal.hostname או משתנים כמו $host,‏ $user). מידע נוסף על משתני אירועים ועל שימוש בביטול כפילויות בחיפוש ובמרכזי בקרה
8 order לא רלוונטי אופציונלי מיון התוצאות לפי שדות ספציפיים (לדוגמה, asc). מידע נוסף על משתני אירועים אופציונלי (רלוונטי רק כשמשתמשים ב-match).
9 limit לא רלוונטי אופציונלי מגבילה את מספר האירועים המקסימלי שמוחזרים מהשאילתה.
10 select לא רלוונטי אופציונלי מציין את רשימת השדות של UDM שייכללו בתוצאות השאילתה.
11 unselect לא רלוונטי אופציונלי מציינת את רשימת השדות של UDM שצריך להחריג מתוצאות השאילתה.

זמינות של מקורות נתונים ב-YARA-L

ל-YARA-L יש גישה למקורות נתונים שונים, בהתאם למיקום שלכם בפלטפורמה. אירועים, ישויות (ECG) וטבלאות נתונים זמינים באופן מלא בחיפוש, במרכזי בקרה ובכללים. פרטים על שאילתות לדוגמה זמינים במאמר בנושא מקורות נתונים נתמכים.

בטבלה הבאה מפורטות התכונות שזמינות ב-YARA-L:

תכונה זמין ב
פניות והיסטוריית פניות מרכזי שליטה
טבלאות נתונים חיפוש, לוחות בקרה, כללים
ישויות (ECG) חיפוש, מרכזי בקרה, כללים
מדדי הטמעה מרכזי שליטה
התאמות של IoC מרכזי שליטה
זיהויים של כללים מרכזי בקרה, כללים
קבוצות כללים מרכזי שליטה
אירועים חיפוש, מרכזי בקרה, כללים
מדדי UEBA חיפוש, מרכזי בקרה

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

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

כדי ליצור את החיפוש הראשון שלכם באמצעות מסנן YARA-L, פועלים לפי השלבים הבאים כדי לחפש משתמשים שהכניסה שלהם נכשלה:

  1. ב-Google SecOps, עוברים לדף search.
  2. מסננים לפי אירועי התחברות:
    metadata.event_type = "USER_LOGIN"

    טיפ: אפשר להשמיט את כותרת הקטע events: בחיפושים. כברירת מחדל, תחביר החיפוש מרמז על החלק הזה.

  3. הוספת פעולות event להתחברויות שנכשלו של משתמשים שלא מופיע אצלם userid ריק. 
    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""
  4. כדי לראות את התוצאות, צריך להריץ את החיפוש הזה.

שימוש במשתני פלייסהולדר

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

אפשר להשתמש במשתני פלייסהולדר כדי:

  • נתוני גישור: משתמשים בפלייסהולדרים, כמו $userid או $ip, כדי למצוא התאמות בין משתני אירועים שונים (לדוגמה, אפשר להשתמש ב-$userid כדי לקשר את מזהה המשתמש בין אירועי ההתחברות וההתנתקות).
  • Group results: בקטע match, משתמשים במשתני placeholder כדי להגדיר את חלון הפלט של השאילתה, כמו match: $userid over 1h.
  • יצירת תוצאות: אפשר להשתמש בפלייסהולדרים כדי לתעד ולהציג נקודות ספציפיות על הגרף בפלט של השאילתה.

לדוגמה, אם מקצים את הערך $user = principal.user.userid, המשתנה $user יכיל עכשיו את הערך הספציפי שחולץ מהאירוע. אחר כך משתמשים באפשרות $user בקטע match כדי לקבץ את כל הפעילות שקשורה למשתמש הספציפי הזה.

שיטת החיפוש הסטטיסטי עוזרת לכם לקבל תובנות, מגמות או חריגות על ידי ביצוע חישובים בקבוצות של אירועים. במקום להחזיר רשימה של יומנים נפרדים, הוא מספק סיכומים מצטברים של הנתונים. הלוגיקה משתמשת בקטע match (לקיבוץ) ובקטע outcome (לחישובים). הקטע outcome תומך בפונקציות צבירה, כמו count(),‏ sum(),‏ avg(),‏ max(),‏ min() ו-stddev().

בדוגמה הבאה נעשה שימוש בלוגיקה הבאה של השאילתה:

  • ‫events: מסנן את הנתונים הגולמיים של ניסיונות כניסה שנכשלו.
  • ‫match: מגדיר את קיבוץ האירועים (לפי userid).
  • ‫outcome: מבצע את הצבירה הסטטיסטית (מספר אירועים לכל משתמש).

דוגמה: צבירה של פעילות התחברות שנכשלה באמצעות פונקציות outcome

בדוגמה הבאה נעשה שימוש בפונקציות הצבירה של הקטע outcome (כמו count() או sum()) כדי לסכם את פעילות הכניסה שנכשלה.

  1. משתמשים בקטע match כדי לקבץ את אירועי ההתחברות שנכשלו לפי userid:

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""

match:
  principal.user.userid

  2. משתמשים בcount של ניסיונות כניסה שנכשלו לכל משתמש ($failed_login_count), שמוגדר על ידי המשתנה outcome:

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""

match:
  principal.user.userid

outcome:
  $failed_login_count = count(metadata.id)

  3. מריצים את החיפוש כדי לראות את התוצאות.

  4. אופציונלי: מוסיפים רכיב של זמן לקטע match (במקרה הזה, day). לאחר מכן, מעדכנים את המשתנה outcome כך שיהיה מפורש יותר ($daily_failed_login_count):

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""
$user = principal.user.userid

match:
  $user by day

outcome:
  $daily_failed_login_count = count(metadata.id)

יצירת ווידג'ט ללוח הבקרה מתוך החיפוש

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

אחרי שהחיפוש מאומת, אפשר לשמור אותו כווידג'ט ולהוסיף אותו למרכז הבקרה, באופן הבא:

  1. כשהתוצאות מוצגות, לוחצים על הכרטיסייה Visualize‏ >‏ Add to Dashboard.
  2. מגדירים את הווידג'ט:
    1. נותנים לווידג'ט שם (לדוגמה, "Daily Failed Login").
    2. בוחרים טווח תאריכים.
    3. בוחרים אם להוסיף אותו ללוח בקרה קיים או ללוח בקרה חדש.
    4. לוחצים על הוספה.
  3. אופציונלי: אפשר ליצור שאילתות ישירות בלוחות הבקרה. אפשר גם להעתיק לוחות בקרה שנערכו ולשנות את העריכות של השאילתות בתוכם כנקודת התחלה.
  4. אופציונלי: אתם יכולים ליצור לוח בקרה בהתאמה אישית ולהוסיף לו ווידג'טים באמצעות YARA-L. פרטים נוספים מופיעים במאמר יצירת לוח בקרה בהתאמה אישית.

הגדרת לוח בקרה

כשיוצרים מרכז בקרה חדש, הקטע events הוא נקודת התחלה חובה. משם אפשר להשתמש ב-match (לקיבוץ תוצאות) או ב-outcome (לחישוב פלטים וצבירות).

לדוגמה, אתם יכולים ליצור לוח בקרה עם קטעים של events ושל match, שבו מוצגת החומרה ($severity) של זיהויים שמקובצים by hour.

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

  • אתם יכולים ליצור מרכז בקרה באמצעות הקטעים events ו-match כדי להציג את חומרת ($severity) הזיהויים, שמקובצים ל-hour קטגוריות:

    detection.detection.severity != "UNKNOWN_SEVERITY"
$severity = detection.detection.severity

match:
  $severity by hour

דוגמה: צבירה של סה"כ ההשפעה הקריטית

  • באופן דומה, אתם יכולים ליצור לוח בקרה באמצעות הקטעים events ו-outcome כדי לעקוב אחרי זיהויים ברמת חומרה גבוהה:

    detection.detection.severity = "CRITICAL"
$severity = detection.detection.severity

outcome:
  $detection_count = count_distinct($severity)

דוגמה: הצגת נפח הזיהוי לפי חומרה לאורך זמן

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

    detection.detection.severity != "UNKNOWN_SEVERITY"
$severity = detection.detection.severity

match:
  $severity by hour

outcome:
  $detection_count = count_distinct(detection.id)

דוגמה: חישוב תדירות ההתחברות של משתמשים

  • בדוגמה הבאה מתמקדים בחישוב login_count למשתמשים ספציפיים באמצעות הקטעים match ו-outcome:

    events:
  metadata.event_type = "USER_LOGIN"

match:
  target.user.userid

outcome:
  $login_count = count(metadata.id)

יצירת כלל

כל כלל צריך לכלול את הקטעים הבאים:

  • ‫meta: מכיל את שם הכלל ופרטים תיאוריים.
  • ‫events: הגדרה של מקורות הנתונים והמסננים באמצעות משתני אירועים.
  • condition: מציין אילו משתני אירועים צריכים להתקיים כדי שהכלל יופעל.

הגדרה ושימוש במשתני אירוע

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

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

דוגמה: הגדרה וסינון של משתני אירועים

  • כדי להגדיר משתנה של אירוע (לדוגמה, $e), משתמשים בקידומת בקטע events של השאילתה. כך אתם מצהירים שהאירועים האלה מיוצגים על ידי המשתנה. לדוגמה, הביטוי $e.principal.hostname = "dev" מעריך כל אירוע כדי לקבוע אם שם המארח הוא התאמה מדויקת.

    $e.principal.hostname = "dev"
$e.metadata.event_type = "USER_LOGIN"

אחר כך אפשר להשתמש במשתנה הזה בקטעים אחרים של השאילתה כדי להפנות לקבוצה הספציפית הזו של אירועים (בקטעים match, outcome, condition) ולשדות הנתונים שלהם.

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

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

רכיב תיאור דוגמה
מבנה הכלל השאילתה נעטפת בבלוק rule ומוקצה לה שם ייחודי לזיהוי הגילוי. rule DailyFailedLoginAttempts { }
meta section חובה. כולל מטא-נתונים תיאוריים (כמו author, ‏ description, ‏ severity) כדי לשפר את ניהול הכללים ולספק הקשר לצוות. מומלץ כשיטה מומלצת לניהול כללים. author = "Alex"
severity = "Medium"
משתנה של אירוע בשאילתת כללים, לכל שדה בקטע events יש קידומת של משתנה אירוע (כמו $e) שמייצג אירוע ספציפי (או קבוצת אירועים) שתואם לקריטריונים שלכם. הן פועלות כקיבוץ לוגי של מסננים.

בדוגמה Convert your search to a YARA-L rule, ‏ $e מייצג את כל ניסיונות הכניסה שנכשלו של המשתמש.		 $e.metadata.event_type = "USER_LOGIN"
משתנה פלייסהולדר מקצה לאירוע שם נפוץ שאפשר להפנות אליו בהמשך השאילתה. פרטים נוספים זמינים במאמר שימוש במשתני פלייסהולדר. $userid = $e.principal.user.userid
match section הגדרת הקיבוצים וציון חלון זמן נתמך. בדוגמה המרת החיפוש לכלל YARA-L, הקיבוץ match: $userid over day מקבץ נכון את האירועים לפי מזהה המשתמש בכל תקופה של 24 שעות (1d).

כשכותבים כלל, צריך לציין חלון זמן נתמך כדי להגדיר את תקופת המבט לאחור. אפשר להטמיע חלון קופץ, נפתח או מתרחב בהתאם לדרישות הלוגיות. השימוש באופרטור over יוצר במפורש חלון קצוב (hopping window). 		$userid over 1d
outcome section מבצע צבירות סטטיסטיות או מתעד משתנים ספציפיים כדי שההתראות שיתקבלו יהיו אינפורמטיביות יותר.

משתמשים בפונקציה count() ב-$e.metadata.id כדי לצבור אירועים בכל קבוצה match. אפשר גם להקצות משתנים, כמו $userid, כדי לתעד שדות ספציפיים של UDM ולספק הקשר נוסף בפלט הזיהוי שמתקבל.		 $failed_count = count($e.metadata.id)
הקטע condition נדרש כדי שכלל ייצור זיהוי.

הגדרת הסף לזיהוי בקטע condition. לדוגמה, אם משתמשים ב-#e > 5, מספר האירועים צריך להיות גדול מחמש (5) כדי להפעיל התראה. אם לא מבצעים חישובים, עדיין צריך להוסיף קטע condition ולציין את קיומו של משתנה האירוע (לדוגמה, #e).

כדאי לנתח את נתוני הבסיס של הסביבה כדי להגדיר ספים שיזהו פעילות חשודה תוך מזעור התוצאות החיוביות הכוזבות. גם אם אתם לא מבצעים חישובים, עדיין צריך קטע condition ולציין את קיומו של משתנה האירוע, למשל #e.		 #e > 5 או $e

כדי להבין איך המבנה הזה פועל, אפשר לעיין בדוגמה הבאה.

דוגמה: זיהוי של ניסיון לפריצה (כמה ניסיונות התחברות שנכשלו)

  • בדוגמה הבאה מזוהים כמה ניסיונות כניסה שנכשלו של משתמש יחיד בחלון של 24 שעות:

    rule DailyFailedLoginAttempts {
  meta:
    author = "Alex"
    description = "Detects multiple failed login attempts for a single user within a day."
    severity = "Medium"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "FAIL"
    $e.principal.user.userid != ""
    $userid = $e.principal.user.userid

  match:
    $userid over 1d

  outcome:
    $daily_failed_login_count = count($e.metadata.id)

  condition:
    $daily_failed_login_count > 5
}

כדי להמיר שאילתת חיפוש סופית לכלל מהימן ליצירת זיהויים, בדרך כלל מבצעים את השלבים הבאים:

  1. ב-Google SecOps, עוברים אל Rules Editor (עורך הכללים).
  2. מתחילים כלל חדש.
  3. מדביקים את שאילתת החיפוש ומשנים אותה כך שתתאים למבנה הכלל, כולל:
    • הקטע meta: מגדיר את כלל המטא-נתונים, כולל שם הכלל, המחבר ורמת החומרה
    • ‫event section: חובה. בניגוד לחיפוש, צריך לתת שם לכותרת של הקטע event`.
    • משתני אירוע: משתנים שמצהירים על אירועים ספציפיים (או קבוצות של אירועים) בתוך הלוגיקה שלכם ומתייחסים אליהם.
    • הקטע match עם חלונות זמן נתמכים: מציין את מפתחות הקיבוץ ומגדיר את הפרמטרים של הזמן (לדוגמה, 5m או 1d). הערה: אם משתמשים בקטע match בכללים, צריך להוסיף חלון זמן.
    • הקטע condition: מגדיר את הלוגיקה הסופית או את ערך הסף שצריך להתקיים כדי להפעיל כלל.

מתקדם: יצירת כלל עם כמה אירועים

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

כלל שכולל כמה אירועים צריך לכלול את הקטעים הבאים:

  • ‫meta: מכיל את שם הכלל ופרטים תיאוריים.
  • ‫events: מגדיר את מקורות הנתונים והמסננים באמצעות משתני אירועים.
  • ‫match: הגדרת מסגרת הזמן ומשתנה placeholder שמשמש לקישור בין האירועים.
  • outcomeכולל הקשר נוסף לגבי ההתראה. כללים שמתייחסים לכמה אירועים דורשים פונקציית צבירה.
  • condition: מציין אילו משתני אירועים צריכים להתקיים כדי שהכלל יופעל.

כדי ליצור כלל עם כמה אירועים:

  1. הגדרת משתני האירועים: בקטע events, מגדירים את $e1 כדי לתעד אירועי "PROCESS_LAUNCH" ואת $e2 כדי לתעד גיבובים ספציפיים של קבצים זדוניים.
  2. התאמה באמצעות פלייסהולדרים: משתמשים במשתנה הפלייסהולדר $user כדי לקשר בין שני זרמי האירועים הנפרדים האלה באמצעות מזהה משתמש ראשי משותף (לדוגמה, $user = $e1.principal.user.userid and $user = $e2.principal.user.userid).
  3. קיבוץ ההתאמה: בקטע match, מציינים שהאירועים האלה חייבים להתרחש באותו $user בתוך חלון זמן מוגדר, למשל 5 דקות (5m).

דוגמה: יצירת כלל עם כמה אירועים

  • בדוגמה הבאה, $e1 מייצג אירוע PROCESS_LAUNCH ו-$e2 מייצג אירוע עם גיבוב זדוני ספציפי. משתנה ה-placeholder‏ $user מבצע קורלציה בין האירועים האלה לפי אותו מזהה משתמש ראשי.

    rule MultiEventExample {
  meta:
    author = "Alex"
    description = "Detects a bad hash execution or a process launch from a specific IP for the same user."

  events:
    $e1.principal.ip = "1.1.1.1"
    $e1.metadata.event_type = "PROCESS_LAUNCH"
    $e2.target.file.sha256 = "badhash..."
    $user = $e1.principal.user.userid
    $user = $e2.principal.user.userid

  match:
    $user over 5m

  condition:
    $e1 or $e2
}

רכיבי הכלל הבאים מתארים את הלוגיקה שבה נעשה שימוש בדוגמה:

  • משתני אירועים: הגדרתם שני משתני אירועים, $e1 ו-$e2. השתמשתם במשתנה placeholder‏ $user כדי לצרף את האירועים האלה לשדה המשותף userid.
  • הקטע match: נוסף קטע match לכלל הזה של כמה אירועים כדי לקבץ לפי משתמש ולציין חלון זמן של קפיצה של חמש דקות (5m) לצורך קורלציה בין האירועים.
  • בקטע condition: הגדרת הלוגיקה להפעלת ההתראה. בדוגמה הזו, התראה תופעל אם האירוע הראשון או האירוע השני קיימים.

שימוש בכלים אחרים כדי ליצור את השאילתה

הכלים האלה חיוניים לכתיבה, לאימות ולהטמעה מהירה של YARA-L:

  • כלי החיפוש של UDM: חיפוש מהיר של שמות, הגדרות וסוגי נתונים של שדות UDM ישירות בממשק המשתמש. אם מזהה השדה לא ידוע, כדאי קודם לבדוק את ההפניה הזו.
  • שפה טבעית לחיפוש ב-YARA-L: בשורת החיפוש, מזינים תיאורים כדי לנסח את השאילתה הראשונית או לקבל או לתרגם הצעות תואמות ב-YARA-L.
  • כלי SPL → YARA-L Translator (כלי Labs): אם אתם עוברים מפלטפורמות של מתחרים, אתם יכולים להשתמש בכלי הזה (שזמין בקטע Labs) כדי להמיר שאילתות Splunk SPL מדור קודם ל-YARA-L. כך נוצרת נקודת התחלה מובנית, שמאיצה את ההעברה ומשפרת את לוגיקת הזיהוי. כדי להשתמש בכלי Labs, ב-Google SecOps, עוברים אל yourinstancename.chronicle.security/labs.

המאמרים הבאים

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