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

נתמך ב:

‫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 נסרקים באמצעות שתי שיטות עיקריות על סמך המטרות שלכם: סינון החיפוש וחיפוש סטטיסטי (צבירות).

השיטה חיפוש באמצעות סינון מאפשרת לבודד אירועים ספציפיים מתוך הזרם הרחב יותר של נתוני הטלמטריה, בלי העומס של צבירת נתונים סטטיסטיים. בשיטה הזו נעשה שימוש בקריטריונים כדי לצמצם כמויות עצומות של נתוני אבטחה – כמו יומנים או תעבורת רשת – לקבוצת תוצאות ממוקדת. הלוגיקה דורשת רק לציין אירועים בקטע 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. המשתנים האלה משמשים כנקודות עוגן זמניות שמאפשרות להשוות נתונים בין אירועים שונים או להציג את הערכים האלה בפלט הסופי.

משתמשים במשתני placeholder כדי:

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

לדוגמה, אם מקצים את $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"
משתנה פלייסהולדר הפונקציה מקצה אירוע לשם נפוץ שאפשר להתייחס אליו בהמשך השאילתה. לפרטים נוספים, אפשר לעיין במאמר בנושא שימוש במשתני placeholder. $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 section נדרש כדי שכלל ייצור זיהוי.

הגדרת הסף לזיהוי בקטע 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, עוברים אל עורך הכללים.
  2. מתחילים כלל חדש.
  3. מדביקים את שאילתת החיפוש ומשנים אותה כך שתתאים למבנה הכלל, כולל:
    • הקטע meta: מגדיר את כלל המטא-נתונים, כולל שם הכלל, המחבר ורמת החומרה
    • ‫event section: חובה. בניגוד לחיפוש, צריך להגדיר כותרת ל-event.
    • משתני אירוע: משתנים שמצהירים על אירועים ספציפיים (או קבוצות של אירועים) בתוך הלוגיקה שלכם ומתייחסים אליהם.
    • הקטע match עם חלונות הזמן הנתמכים: מציין את מפתחות הקיבוץ ומגדיר את פרמטרי הזמן (לדוגמה, 5m או 1d). הערה: אם משתמשים בקטע match בכללים, צריך להוסיף חלון זמן.
    • הקטע condition: מגדיר את הלוגיקה הסופית או את הסף שצריך לעמוד בו כדי להפעיל כלל.

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

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

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

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

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

  1. הגדרת משתני האירועים: בקטע events, מגדירים את $e1 כדי לתעד אירועי "PROCESS_LAUNCH" ואת $e2 כדי לתעד גיבובים ספציפיים של קבצים זדוניים.
  2. התאמה באמצעות פלייסהולדרים: משתמשים במשתנה ה-placeholder‏ $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.