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

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

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

  • גישור על נתונים: משתמשים ב-placeholders, כמו $userid או $ip, כדי למצוא התאמות בין משתני אירועים שונים (לדוגמה, אפשר להשתמש ב-$userid כדי לקשר את מזהה המשתמש בין אירועי הכניסה והיציאה).
  • תוצאות קיבוץ: בקטע 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 חובה. כולל מטא-נתונים תיאוריים (כמו 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 מקצה אירוע לשם נפוץ שאפשר להתייחס אליו בהמשך השאילתה. פרטים נוספים זמינים במאמר בנושא שימוש במשתני placeholder. $userid = $e.principal.user.userid
קטע של match מגדירים את הקיבוצים ומציינים חלון זמן נתמך. בדוגמה המרת החיפוש לכלל YARA-L, הקיבוץ match: $userid over day מקבץ נכון את האירועים לפי מזהה המשתמש בכל תקופה של 24 שעות (1d).

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

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

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

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

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

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

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

  1. הגדרת משתני האירועים: בקטע events, מגדירים את $e1 כדי לתעד אירועים של "PROCESS_LAUNCH" ואת $e2 כדי לתעד גיבובים ספציפיים של קבצים זדוניים.
  2. התאמה באמצעות משתני placeholder: משתמשים במשתנה ה-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 (כלי Labs): אם אתם עוברים מפלטפורמות של מתחרים, אתם יכולים להשתמש בכלי הזה (שזמין בקטע Labs) כדי להמיר שאילתות SPL מדור קודם של Splunk ל-YARA-L. הכלי הזה יוצר נקודת התחלה מובנית, שמאיצה את ההעברה ומשפרת את לוגיקת הזיהוי. כדי להשתמש בכלי Labs, ב-Google SecOps, עוברים אל yourinstancename.chronicle.security/labs.

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

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