ביטויים, אופרטורים ומבנים אחרים

נתמך ב:

במסמך הזה תמצאו מידע שיעזור לכם ליצור כללים ושאילתות ב-YARA-L באמצעות ביטויים.

ביטויים בוליאניים

ביטויים בוליאניים הם ביטויים עם סוג בוליאני, שכולל ביטויי השוואה, ביטויי פונקציות וביטויים של רשימת הפניות או של טבלת נתונים. אפשר להשתמש בביטויים בוליאניים בקטע events ובקטע outcome בכלל או בשאילתה של YARA-L.

ביטויי השוואה

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

דוגמה: ביטויי השוואה

$e.source.hostname = "host1234"
$e.source.port < 1024
1024 < $e.source.port
$e1.source.hostname != $e2.target.hostname
$e1.metadata.collected_timestamp.seconds > $e2.metadata.collected_timestamp.seconds
$port >= 25
$host = $e2.target.hostname
"google-test" = strings.concat($e.principal.hostname, "-test")
"email@google.org" = re.replace($e.network.email.from, "com", "org")

ביטויי פונקציות

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

re.regex()

net.ip_in_range_cidr()

דוגמה: ביטויי פונקציה

re.regex($e.principal.hostname, `.*\.google\.com`)
net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/24")

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

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

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

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

// STRING reference list
$e.principal.hostname in %string_reference_list

// Regular expression reference list
$e.principal.hostname in regex %regex_reference_list

// CIDR reference list
$e.principal.ip in cidr %cidr_reference_list

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

// STRING data table
$e.target.hostname in %data_table_name.column_name

// Regular expression data table
$e.target.hostname in regex %regex_table_name.column_name

// CIDR data table
$e.principal.ip in cidr %cidr_table_name.column_name

דוגמה: שימוש ב-not וב-nocase בתחביר של רשימות הפניות

// Exclude events whose hostnames match substrings in my_regex_list.
not $e.principal.hostname in regex %my_regex_list

// Event hostnames must match at least 1 string in my_string_list (case insensitive).
$e.principal.hostname in %my_string_list nocase

האופרטור nocase תואם לרשימות STRING ולרשימות REGEX.

מסיבות שקשורות לביצועים, יש מגבלות על השימוש ברשימת ההפניות ובטבלת הנתונים:

  • מספר ההצהרות המקסימלי של in בשאילתה, עם או בלי אופרטורים מיוחדים: 10
  • מספר מקסימלי של הצהרות in עם האופרטור regex: 5
  • מספר מקסימלי של הצהרות in עם האופרטור cidr: 5

ביטויים לוגיים

אפשר להשתמש באופרטורים הלוגיים and ו-or בקטע events.

דוגמה: ביטויים לוגיים

$e.metadata.event_type = "NETWORK_DNS" or $e.metadata.event_type = "NETWORK_DHCP"
($e.metadata.event_type = "NETWORK_DNS" and $e.principal.ip = "192.0.2.12") or ($e.metadata.event_type = "NETWORK_DHCP" and $e.principal.mac = "AB:CD:01:10:EF:22")
not $e.metadata.event_type = "NETWORK_DNS"

סדר העדיפות שמוגדר כברירת מחדל, מהגבוה לנמוך, הוא not, and, or. לדוגמה, הביטוי a or b and c מוערך כ-a or (b and c) כשמגדירים את האופרטורים or ו-and באופן מפורש בביטוי.

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

$e1.field = "bat"
or $e1.field = "baz"
$e2.field = "bar"

הפירוש הוא כזה:

($e1.field = "bat" or $e1.field = "baz")
and ($e2.field = "bar")

מכיוון שהתנאי or מוגדר באופן מפורש, הפרדיקטים שמסביב מקובצים ונבדקים קודם. הנשוא האחרון, $e2.field = "bar". המשתמש מצטרף באופן מרומז באמצעות and. התוצאה היא שסדר ההערכה משתנה.

חיפושים בטבלת נתונים בביטויים לוגיים

כשמשתמשים בחיפושים בטבלת נתונים (התחביר in %list) בקטע events, חלים אילוצי התחביר הבאים:

  • בלעדיות של סוגים: אי אפשר לשלב השוואות של שדות רגילים (לדוגמה, $field = "value") עם חיפושים בטבלאות נתונים באותו בלוק לוגי.

  • הגבלת אופרטורים: אפשר לשלב בין חיפושים בטבלאות נתונים רק באמצעות האופרטור OR. האופרטור AND לא נתמך בביטויים האלה.

  • בלעדיות של משתני אירוע עם OR: כשמשתמשים באופרטור OR כדי לשלב חיפושים בטבלת נתונים, כל החיפושים בביטוי OR צריכים להתייחס לשדות מאותו משתנה אירוע. לדוגמה, הערך ($e.user in %table1 OR $e.group in %table2) תקין. עם זאת, לא ניתן להשתמש בביטויים כמו ($e.user in %table OR $g.user in %table). הסיבה לכך היא שלחיפושים בין משתני אירועים שונים (לדוגמה, $e ו-$g) בתנאי OR אין נקודת שוויון משותפת, ולכן הקומפיילר נכשל בזמן הריצה עם RULE ERROR: error processing rule.

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

// Invalid: Mixing a field comparison with a data table lookup
($field = "value" OR $field in %list)

// Invalid: Using AND with data table lookups
($field_A in %list_A AND $field_B in %list_B)

דוגמה: דוגמה תקינה

// Valid: Multiple data table lookups joined by OR
($field in %list_A OR $field in %list_B)

דוגמה: שימוש לא תקין באופרטור OR בין משתנים

// Invalid: OR condition across different event variables
($e.user in %table OR $g.user in %table)

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

סוגים מנויים

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

בדוגמה הבאה, הערכים USER_UNCATEGORIZED ו-USER_RESOURCE_DELETION תואמים ל-15000 ול-15014, ולכן הכלל יחפש את כל האירועים שמופיעים ברשימה:

$e.metadata.event_type >= "USER_CATEGORIZED" and $e.metadata.event_type <= "USER_RESOURCE_DELETION"

Nocase Modifier

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

דוגמה: nocase modifier

$e.principal.hostname != "http-server" nocase
$e1.principal.hostname = $e2.target.hostname nocase
$e.principal.hostname = /dns-server-[0-9]+/ nocase
re.regex($e.target.hostname, `client-[0-9]+`) nocase

אי אפשר להשתמש במגדיר nocase אם סוג השדה הוא ערך ממוספר. הדוגמאות הבאות לא תקינות ויגרמו לשגיאות קומפילציה:

$e.metadata.event_type = "NETWORK_DNS" nocase
$e.network.ip_protocol = "TCP" nocase

תגובות

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

  • כדי להוסיף הערה בשורה אחת, משתמשים בשני תווים של קו נטוי (// comment).
  • כדי להוסיף הערה בכמה שורות, משתמשים בתו לוכסן אחד ובתו כוכבית (/* comment */).

Literals

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

ייצוגים מילוליים של מחרוזות

מחרוזות ליטרליות הן רצפים של תווים שמוקפים במירכאות כפולות (") או במירכאות הפוכות (`). המחרוזת מתפרשת בצורה שונה, בהתאם לסוג המירכאות שבו משתמשים:

  • מירכאות כפולות ("hello\tworld"): לשימוש במחרוזות רגילות. צריך לכלול תווי Escape, כאשר ‎\t מתפרש כ-Tab.
  • גרשיים הפוכים (`hello\tworld`): משתמשים בהם כשרוצים שכל התווים יפורשו באופן מילולי, כך שהתו ‎\t לא יפורש כ-Tab.

ביטויים רגולריים מילוליים

לגבי מחרוזות ליטרליות של ביטויים רגילים, יש שתי אפשרויות:

  • אם רוצים להשתמש ישירות בביטויים רגולריים בלי הפונקציה re.regex(), צריך להשתמש ב-/regex/ בשביל ליטרלים של ביטויים רגולריים.

  • אם רוצים להשתמש במחרוזות מילוליות כביטויים רגולריים מילוליים, צריך להשתמש בפונקציה re.regex(). שימו לב: במחרוזות מילוליות עם מירכאות כפולות, צריך לסמן בתו בריחה (escape) את התווים של הקו הנטוי ההפוך באמצעות תווים של קו נטוי הפוך, וזה יכול להיראות מוזר.

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

re.regex($e.network.email.from, `.*altostrat\.com`)

re.regex($e.network.email.from, ".*altostrat\\.com")

$e.network.email.from = /.*altostrat\.com/

‫Google ממליצה להשתמש בתווי גרש הפוכים למחרוזות בביטויים רגולריים כדי לשפר את הקריאות.

אופרטורים

אופרטור תיאור
= שווה/הצהרה
‎!= לא שווה
> קטן מ-
=> קטן מ- או שווה ל-
> גדול מ:
=< גדול או שווה ל-

הסבר על השימוש במשתנים ב-YARA-L

ב-YARA-L, כל המשתנים משתמשים בתחביר $<variable name>. בקטע הזה מתוארים סוגי המשתנים שבהם אפשר להשתמש ב-YARA-L.

משתני אירוע

משתני אירוע מייצגים קבוצות של אירועים או אירועים של ישויות. מציינים תנאים למשתני אירוע בקטע events באמצעות שם, מקור אירוע ושדות אירוע.

  • מקורות האירועים הם udm (לאירועים שעברו נורמליזציה) ו-graph (לאירועים של ישויות). אם לא מציינים מקור, udm מוגדר כמקור ברירת המחדל.

  • שדות של אירועים מיוצגים כשרשרת של .<שם השדה> (לדוגמה, $e.field1.field2), והשרשרות של השדות תמיד מתחילות מהמקור ברמה העליונה (UDM או Entity).

התאמת משתנים

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

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

בקטע events מציינים מה כל משתנה התאמה מייצג.

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

משתמשים במשתני placeholder כדי לתעד ולאחסן ערכים ספציפיים משדות של אירועים ב-UDM, כדי להפנות אליהם ולהשתמש בהם לאורך שאילתה. אתם יכולים להשתמש בהם כדי לקשר בין אירועים מפוזרים, במיוחד בשאילתות עם כמה אירועים. אם מקצים ערך משותף (לדוגמה, userid או hostname) למחזיק מקום, אפשר להשתמש במחזיק המקום הזה בקטע match כדי לקבץ אירועים שמשתפים את הערך הזה בחלון זמן מוגדר.

מגדירים משתנים של מצייני מיקום בקטע events על ידי הקצאת הערך של שדה UDM לשם משתנה עם הקידומת $ (לדוגמה, $targetUser = $e.target.user.userid).

אפשר גם להגדיר משתני placeholder בקטעים הבאים:

  • בקטע condition מציינים את התנאים של match.
  • outcome כדי לבצע חישובים, להגדיר מדדים או לחלץ נקודות נתונים ספציפיות מהאירועים התואמים.
  • הקטע match כדי לקבץ אירועים לפי ערכים משותפים.

הקצאת פונקציה לערך פלייסהולדר

ב-YARA-L, הקצאת פונקציה למחזיק מיקום היא תהליך של שינוי נתוני אירועים ב-UDM ואחסון התוצאה לשימוש בכלל הכלל. הפעולה הזו מאפשרת לכם לבצע חישובים או שינויים בנתונים בקטע events ולהפנות לתוצאות האלה בקטעים match, condition ו-outcome.

הרכיבים העיקריים הם:

  • פונקציות: פעולות מובנות שמבצעות חישובים או טרנספורמציות של נתונים (כמו מניפולציה של מחרוזות או מתמטיקה) בשדות אירועים ספציפיים.
  • משתני placeholder: משתנים שמוגדרים על ידי המשתמש, עם הקידומת $ (לדוגמה, $user, ‏ $ip), שמשמשים כמאגרי נתונים. הם מאחסנים ערכים שחולצו ישירות מאירועים או שנוצרו על ידי פלט של פונקציות.
  • הקצאה: הלוגיקה שמקשרת את הפלט של פונקציה למשתנה placeholder, וכך הופכת את הנתונים שעברו טרנספורמציה לנגישים לשאר הלוגיקה של הזיהוי.

מגבלות

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

  1. צריך להקצות לכל placeholder ביטוי שמכיל שדה אירוע.

    דוגמאות תקינות

    $ph1 = $e.principal.hostname
    $ph2 = $e.src.hostname
    
    // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
    $ph1 = strings.concat($ph2, ".com")
    
    $ph1 = $e.network.email.from
    $ph2 = strings.concat($e.principal.hostname, "@gmail.com")
    
    // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
    $ph1 = strings.to_lower($ph2)
    

    דוגמה לא תקינה

    $ph1 = strings.concat($e.principal.hostname, "foo")
    $ph2 = strings.concat($ph1, "bar") // $ph2 has NOT been assigned to an expression containing an event field.
    
  2. הקריאה לפונקציה צריכה להיות תלויה באירוע אחד בלבד. עם זאת, אפשר להשתמש ביותר מארגומנט אחד של קריאה לפונקציה מאותו אירוע.

    דוגמה תקינה

    $ph = strings.concat($event.principal.hostname, "string2")

    $ph = strings.concat($event.principal.hostname, $event.src.hostname)

    דוגמה לא תקינה

    $ph = strings.concat("string1", "string2")

    $ph = strings.concat($event.principal.hostname, $anotherEvent.src.hostname)

שימוש במילות מפתח להגדרת שאילתות

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

מילות המפתח לא תלויות באותיות רישיות (לדוגמה, and או AND הן מילות מפתח שוות).

קטגוריות עיקריות של מילות מפתח ב-YARA-L 2.0

הרשימה הזו לא מלאה, אבל היא כוללת את מילות המפתח העיקריות שמשמשות ב-YARA-L 2.0 ליצירת שאילתות איתור חזקות.

  • הגדרת השאילתה:
    • rule: מתחיל את ההגדרה של שאילתת YARA-L חדשה.
    • private: מציין ששאילתה היא פרטית, ומונע את החשיפה הישירה שלה או את ההפעלה שלה מבחוץ.
    • global: מציין שהשאילתה היא גלובלית, כלומר שהיא צריכה לחול על כלל הנתונים.
  • קטעי שאילתות:
    • meta: מציג את קטע המטא-נתונים עם מידע תיאורי על השאילתה.
    • strings: מציין את הקטע שבו מוגדרים דפוסי המחרוזות.
    • condition: מציין את הקטע שמכיל את הלוגיקה הבוליאנית להפעלת השאילתה.
    • events: מגדיר את הקטע שבו מציינים את משתני האירועים והתנאים שלהם.
    • match: פותח את הקטע של צבירת ערכים בחלון זמן.
    • outcome: מגדיר את הקטע להוספת הקשר וניקוד לשאילתות שהופעלו.
  • אמצעי שינוי של מחרוזות:
    • ascii: מציין שמחרוזת צריכה להיות תואמת לטקסט ASCII.
    • wide: מציין שיש להתאים מחרוזת כתווים רחבים (UTF-16).
    • nocase: מבצעת התאמה של מחרוזת ללא הבחנה בין אותיות רישיות לאותיות קטנות.
    • fullword: המחרוזת צריכה להיות זהה למילה שלמה.
    • xor: מחיל טרנספורמציית XOR על המחרוזת לפני ההתאמה.
    • base64, base64wide: קידוד Base64 מוחל לפני ההתאמה.
  • אופרטורים לוגיים:
    • and, ‏ or, ‏ not: אופרטורים לוגיים בוליאניים סטנדרטיים לצירוף תנאים.
    • all of, ‏ any of: משמש להערכה של כמה ביטויים במסגרת תנאי.
  • אופרטורים להשוואה ואופרטורים יחסיים:
    • at: מציין היסט מדויק להתאמת מחרוזות.
    • contains: בודקת אם מחרוזת מכילה מחרוזת משנה.
    • startswith, ‏endswith: בדיקה אם מחרוזת מתחילה או מסתיימת עם מחרוזת משנה.
    • icontains, istartswith, iendswith, iequals: גרסאות לא תלויות רישיות.
    • matches: משמש להתאמה של ביטויים רגולריים.
  • סוגי נתונים ומגדירי גודל:
    • int8, ‏ uint8, ‏ int16, ‏ uint16, ‏ int32, ‏ uint32: סוגי מספרים שלמים עם גדלים שצוינו.
    • int8be, uint8be, int16be, uint16be, int32be, uint32be: גרסאות big-endian של סוגי מספרים שלמים.
    • filesize: מייצג את גודל הקובץ שמנותח.
    • entrypoint: מתייחס לנקודת הכניסה של קובץ הפעלה.

תמיכה במיפוי YARA-L

‫YARA-L תומך במפות עבור סוגי הנתונים Struct ו-Label, שמשמשים בחלק מהשדות של UDM.

כדי לחפש צמד מסוים של מפתח-ערך בשני סוגי הנתונים Struct ו-Label, משתמשים בתחביר הרגיל של המפה:

  • תחביר של שדה במבנה: $e.udm.additional.fields["pod_name"] = "kube-scheduler"
  • תחביר של שדה התווית: $e.metadata.ingestion_labels["MetadataKeyDeletion"] = "startup-script"

דוגמה: שימוש תקין ולא תקין במפות

בדוגמאות הבאות מוצג שימוש תקין ולא תקין במפות.

שימוש תקין במפות

שימוש בשדה Struct בקטע events:

events:
  $e.udm.additional.fields["pod_name"] = "kube-scheduler"
  

שימוש בשדה Label (תווית) בקטע outcome (תוצאה):

outcome:
  $value = array_distinct($e.metadata.ingestion_labels["MetadataKeyDeletion"])
 

הקצאת ערך של מפה למשתנה placeholder:

$placeholder = $u1.metadata.ingestion_labels["MetadataKeyDeletion"]

שימוש בשדה מפה בתנאי של צירוף:

// using a Struct field in a join condition between two udm events $u1 and $u2
$u1.metadata.event_type = $u2.udm.additional.fields["pod_name"]

שימוש במפות שלא נתמך

שילוב מילות מפתח any או all עם מפה

all $e.udm.additional.fields["pod_name"] = "kube-scheduler"

סוגים אחרים של ערכים

תחביר המיפוי יכול להחזיר רק ערך מחרוזת. במקרה של סוגי נתונים [Struct](https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#struct), תחביר המפה יכול לגשת רק למפתחות שהערכים שלהם הם מחרוזות. אי אפשר לגשת למפתחות שהערכים שלהם הם סוגים פרימיטיביים אחרים, כמו מספרים שלמים.

טיפול בערכים כפולים במיפויים

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

לתווית יש מפתח כפול

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

דוגמה: תווית עם מפתח כפול

השאילתה $e.metadata.ingestion_labels["dupe-key"] תחזיר את הערך האפשרי הראשון, val1, אם היא תופעל על נתוני הדוגמה הבאים:

    // Disrecommended usage of label with a duplicate key:
    event {
      metadata{
        ingestion_labels{
          key: "dupe-key"
          value: "val1" // This is the first possible value for "dupe-key"
        }
        ingestion_labels{
          key: "dupe-key"
          value: "val2"
        }
      }
    }
  

לתווית יש שדה חוזר ברמת האב

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

דוגמה: תווית עם שדה חוזר של ישות אם

שאילתת הטקסט $e.security_result.rule_labels["key"] תחזיר את הערך האפשרי הראשון, val3, אם היא תופעל על דוגמת הנתונים הבאה:

    event {
      // security_result is a repeated field.
      security_result {
        threat_name: "threat1"
        rule_labels {
          key: "key"
          value: "val3" // This is the first possible value for "key"
        }
      }
      security_result {
        threat_name: "threat2"
        rule_labels {
          key: "key"
          value: "val4"
        }
      }
    }
  

גישה למשתני התוצאה במפות

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

נתוני התוצאות זמינים בשדות הבאים:

  • הערכים של התוצאות שומרים על הסוגים המקוריים שלהם בשדה variables.
  • בשדה outcomes מאוחסנות גרסאות string לצורך תאימות לאחור.

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

תחביר:

$d.detection.detection.variables[OUTCOME_NAME].TYPE_SUFFIX

תחביר לרצפים:

$d.detection.detection.variables[OUTCOME_NAME].SEQUENCE_TYPE_SUFFIX.TYPE_VALS_SUFFIX

דוגמאות: גישה למשתני תוצאה במפות

גישה לתוצאה של מחרוזת:

    $my_string_outcome = $d.detection.detection.variables["outcome_ip"].string_val
   

בדוגמה הזו מאחזרים את ערך המחרוזת ישירות (לדוגמה, "1.1.1.1" אם outcome_ip הייתה מחרוזת יחידה).

גישה לתוצאה של מספר שלם

    $my_int_outcome = $d.detection.detection.variables["outcome_port"].int64_value
    

בדוגמה הזו מאחזרים את הערך של המספר השלם (לדוגמה, 30).

גישה לרשימה של מספרים שלמים באמצעות Int64Sequence

   $my_int_list = $d.detection.detection.variables["outcome_ports"].int64_seq.int64_vals
   

בדוגמה הזו מאחזרים את הרשימה המלאה של המספרים השלמים ומבטלים את הקינון שלהם כמו בשדות חוזרים (לדוגמה, [2, 3, 4]).

גישה לרכיב ספציפי מרשימה של מספרים שלמים

    $first_int = $d.detection.detection.variables["outcome_ports"].int64_seq.int64_vals[0]
    

בדוגמה הזו, הפונקציה מחזירה את המספר השלם הראשון מהרשימה (לדוגמה, 2).

גישה לרשימת מחרוזות (StringSequence)

    $my_string_list = $d.detection.detection.variables["outcome_ips"].string_seq.string_vals
    

בדוגמה הזו מאחזרים את הרשימה המלאה של המחרוזות ומבטלים את הקינון שלהן כמו שדות חוזרים (לדוגמה, ["1.1.1.1", "2.2.2.2"]).

גישה לרכיב ספציפי מרשימה של מחרוזות

    $first_ip = $d.detection.detection.variables["outcome_ips"].string_seq.string_vals[0]
    

בדוגמה הזו מאחזרים את כתובת ה-IP הראשונה מהרשימה (לדוגמה, "1.1.1.1").

סיומות הסוג הזמינות של variables

רשימה מלאה של הסיומות הנתמכות זמינה במאמר FindingVariable.

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