תחביר של קטע התוצאה

נתמך ב:

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

הגדרת קטע התוצאה

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

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

הכלל הזה מחפש ניסיונות התחברות שנכשלו ממיקום חדש:

rule failed_logins
{
  meta:
   author = "Security Team"
   description = "Detects multiple failed user logins within 10-minute windows."
   severity = "HIGH"

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

  match:
   $user over 10m

  outcome:
   $failed_login_count = count($e.metadata.id)
   $first_fail_time = min($e.metadata.event_timestamp.seconds)

  condition:
   #e >= 5
}

הקטע outcome מבצע צבירות של משתני האירוע והפלייסהולדר: ספירת ההתחברויות שנכשלו, ספירת כתובות ה-IP הנפרדות וקבלת השעה שבה אירע הכשל.

outcome:
   $failed_login_count = count($e.metadata.id)
   $first_fail_time = min($e.metadata.event_timestamp.seconds)

אם כוללים ומאכלסים את משתנה התוצאה המיוחד $risk_score, הערך שלו (מספר שלם או מספר ממשי) מוצג בדף התראות ו-IoC עבור התראות שנוצרו על ידי השאילתה.

אם לא כוללים משתנה $risk_score בקטע outcome של שאילתה, מוגדר אחד מערכי ברירת המחדל הבאים:

  • אם השאילתה מוגדרת ליצירת התראה, הערך של $risk_score מוגדר ל-40.

  • אם השאילתה לא מוגדרת ליצירת התראה, הערך של $risk_score מוגדר ל-15.

הערך של $risk_score מאוחסן בשדה security_result.risk_score ב-UDM.

משתנה התוצאה risk_score

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

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

חוּמרה טווח הניקוד תיאור דוגמה
התראה – קריטית 90 - 100 פרצה פעילה שעלולה להשפיע על יותר מחשבון משתמש אחד או נקודת קצה אחת. נדרשת בדיקה מיידית. ‫Mimikatz הופעל בבקר הדומיין.
התראה – גבוהה 80 - 89 פגיעה פעילה בנקודת קצה (endpoint) אחת או בישות אחת. צריך לבדוק אותם באופן מיידי. שרת ייצור שולח קריאה ל-C2 מוכר ועדכני.
התראות – בינוני 50 - 79 בעיית אבטחה אפשרית שצריך לבדוק. אין פגיעה מאושרת, אבל אפשר להעביר את הבעיה לטיפול ברמה גבוהה יותר. פרטי כניסה שנחשפו, אין סימנים לשימוש לרעה.
ללא התראה – נמוכה 20 - 49 אירוע אבטחה עם השפעה נמוכה, שבשילוב עם אינדיקטורים או תצפיות אחרים, עלול להוביל לאירוע משמעותי יותר. בדרך כלל לא נדרשת בדיקה, ואפשר לשלב את האירוע עם זיהויים אחרים באמצעות כללים מורכבים כדי ליצור התראה. סריקת יציאות פנימיות.
תצפיות שלא מפעילות התראות 1 - 19 באופן כללי, זיהויים שמבוססים על מידע ונועדו ליצור מוּדעוּת מצבית לאיום. בדרך כלל לא נדרשת בדיקה. אפשר לשלב עם זיהויים אחרים באמצעות כללים מורכבים כדי ליצור התראות. אירוע התחברות, אין סימנים לשימוש לרעה.

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

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

משתנה תוצאה risk_entity_to_score

כברירת מחדל, מערכת Google SecOps מקצה את ציון הסיכון של הזיהוי לכל הישויות באירועים שנדגמו. הוא גם מקצה את הניקוד לכל הישויות שמופיעות בקטעים match ו-outcome של הכלל. כדי להקצות את ציון הסיכון לישויות ספציפיות, צריך לציין את משתנה התוצאה risk_entity_to_score בנוסף ל-risk_score. חישוב של ציון סיכונים תומך בישויות user ו-asset. אי אפשר להשתמש בשיטה הזו עם ישויות מסוג RESOURCE או GROUP.

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

$risk_entity_to_score_source_asset = $e.principal.asset.hostname
$risk_entity_to_score_targeted_user = $e.target.user.userid

משתני התוצאה האלה מקצים את הערך של risk_score שצוין בקטע outcome של הכלל לישויות $e.principal.asset.hostname ו-$e.target.user.userid.

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

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

במאמר כלל של כמה אירועים מוסבר איך כותבים כלל של כמה אירועים.

rule suspicious_admin_privilege_escalation {
 // This rule matches single events. Rules can also match multiple events within
 // the same time window.

 meta:
   // Allows for storage of arbitrary key-value pairs of rule details, such as 
   // who wrote it, what it detects on, and version control.
   // The "author" and "severity" fields are special, since they are used as
   // columns on the rules dashboard. To sort based on these fields on the 
   // dashboard, add them here.
   // Severity value should be "Low", "Medium", or "High"
   author = "analyst123"
   description = "Detects suspicious login to critical admin accounts."
   severity = "HIGH"

 events:
   $e.metadata.event_type = "USER_LOGIN"
   $e.target.user.attribute.roles.name = "ADMIN"
   $e.security_result.summary = "Successful login with high-privilege access"

 outcome:
   // Multi-event rules require an aggregation function
   // For example, risk_score = max(0)
   // See https://docs.cloud.google.com/chronicle/docs/yara-l/yara-l-2-0-examples#outcome_conditionals_example_rule
   $risk_score = 80
   $risk_entity_to_score = $e.target.user.userid
   $source_ip = array_distinct($e.principal.ip)

 condition:
   $e
}

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

הכלל הזה בודק אם יש תנועה רוחבית על ידי זיהוי חיבורי רשת בין מקטעים ברשת הפנימית. הוא משתמש ב-$risk_entity_to_score prefix כדי להקצות סיכון לכמה ישויות בזיהוי אחד. ציוני הסיכון של המארח שיזם את הפעולה ($risk_entity_to_score_source_asset) ושל המשתמש שהיה היעד ($risk_entity_to_score_targeted_user) מתעדכנים. מנוע הסיכונים מתעד משתני תוצאה אחרים שלא משתמשים בקידומת הספציפית הזו להקשר, אבל מתעלם מהם (ציוני הסיכון שלהם נשארים ללא שינוי).

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

rule lateral_movement_network_connection {
 // This rule matches single events. You can also match multiple events within
 // the same time window.

 meta:
   // Allows for storage of arbitrary key-value pairs of rule details (for 
   // example, who wrote it, what it detects on, and version control).
   // The "author" and "severity" fields are special, since they are used as
   // columns on the rules dashboard. To sort based on these fields on the 
   // dashboard, add them here. Severity value should be "Low", "Medium" or "High"
   author = "analyst123"
   description = "Detects lateral movement attempts between internal segments."
   severity = "MEDIUM"

 events:
   $e.metadata.event_type = "NETWORK_CONNECTION"
   $e.principal.asset.hostname != ""
   $e.target.user.userid != ""
   // Can also use: $e.target.ip = /10\..*/
   net.ip_in_range_cidr($e.target.ip, "10.0.0.0/8")

 outcome:
   // Multi-event rules require an aggregation function
   // for example, risk_score = max(0)
   // See https://docs.cloud.google.com/chronicle/docs/yara-l/yara-l-2-0-examples#outcome-conditionals-example-rule
   $risk_score = 50
   $risk_entity_to_score_source_asset = $e.principal.asset.hostname
   $risk_entity_to_score_targeted_user = $e.target.user.userid
   $target_ip_info = array_distinct($e.target.ip)

 condition:
   $e
}

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

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

  • מספר שלם
  • מספרים ממשיים (float)
  • מחרוזת
  • רשימות של מספרים שלמים
  • רשימות של נקודות צפות
  • רשימות של מחרוזות

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

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

if(BOOL_CLAUSE, THEN_CLAUSE)
if(BOOL_CLAUSE, THEN_CLAUSE, ELSE_CLAUSE)

אפשר לקרוא ביטוי מותנה כך: "אם BOOL_CLAUSE נכון, אז מחזירים את THEN_CLAUSE, אחרת מחזירים את ELSE_CLAUSE".

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

  • שמות שדות UDM עם אופרטור השוואה:

    if($context.graph.entity.user.title = "Vendor", 100, 0)

  • משתנה פלייסהולדר שהוגדר בקטע events:

    if($severity = "HIGH", 100, 0)

  • משתנה תוצאה אחר שמוגדר בקטע outcome:

    if($risk_score > 20, "HIGH", "LOW")

  • פונקציות שמחזירות ערך בוליאני:

    if(re.regex($e.network.email.from, `.*altostrat.com`), 100, 0)

  • חיפוש ברשימת עזר:

    if($u.principal.hostname in %my_reference_list_name, 100, 0)

  • השוואה בין צבירות נתונים:

    if(count($login.metadata.event_timestamp.seconds) > 5, 100, 0)

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

אפשר להשמיט את ELSE_CLAUSE אם סוג הנתונים הוא מספר שלם או מספר ממשי. אם משמיטים את ELSE_CLAUSE, הערך שלו יהיה 0. לדוגמה:

`if($e.field = "a", 5)` is equivalent to `if($e.field = "a", 5, 0)`

חובה לספק את ELSE_CLAUSE אם סוג הנתונים הוא מחרוזת או אם THEN_CLAUSE הוא משתנה פלייסהולדר או משתנה תוצאה.

פעולות מתמטיות

אפשר להשתמש בפעולות מתמטיות כדי לחשב סוגי נתונים של מספרים שלמים או מספרים עם נקודה צפה (float) בקטעים outcome ו-events של שאילתה. מערכת Google Security Operations תומכת בחיבור, חיסור, כפל, חילוק ושארית כאופרטורים ברמה העליונה בחישוב.

קטע הקוד הבא הוא דוגמה לחישוב בקטע outcome:

outcome:
  $risk_score = max(100 + if($severity = "HIGH", 10, 5) - if($severity = "LOW", 20, 0))

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

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

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

ערכים מילוליים של מספרים שלמים רגילים מוגדרים כברירת מחדל כמספרים שלמים של 64 ביט עם סימן (INT64), שלא תואמים לשדות UDM של מספרים שלמים של 64 ביט ללא סימן (UINT64), כמו network.received_bytes,‏ network.sent_bytes ו-principal.file.size. שילוב של הסוגים האלה בפעולות אריתמטיות (+, -, *) או בפעולות מודולו (%) עלול לגרום לשגיאת זמן ריצה בקטע outcome. כדי לפתור את הבעיה, צריך להשתמש ב-cast.as_int() או ב-cast.as_uint() כדי להתאים לסוגי מספרים שלמים. צריך להגדיר המרה מפורשת לאופרטור %. בפעולות אריתמטיות, אפשר גם לאלץ קבועים של מספרים שלמים להתנהג כמו מספרים בנקודה צפה (float) באמצעות ליטרלים של נקודה צפה, כמו 2.0 או 100.0, או אילוץ חלוקה, כמו (2/1), בביטויים ללא אופרטורים אחרים של / באותה שורה. מידע נוסף זמין במאמר פעולות אריתמטיות עם שדות אירועים לא חתומים.

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

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

דוגמה: אירוע יחיד בלי קטע התאמה

// No match section, so this is a single-event query.

outcome:
  // Use placeholder directly as an outcome value.
  $my_outcome = $email_sent_bytes

  // Use placeholder in a conditional.
  $other_outcome = if($file_size > 1024, "SEVERE", "MODERATE")

condition:
  $e

דוגמה: אירוע מרובה עם קטע התאמה

match:
  // This is a multi event query with a match section.
  $hostname over 5m

outcome:
  // Use placeholder directly in an aggregation function.
  $max_email_size = max($email_sent_bytes)

  // Use placeholder in a mathematical computation.
  $total_bytes_exfiltrated = sum(
    1024.0
    + $email_sent_bytes
    + $file_event.principal.file.size
  )

condition:
  $email_event and $file_event

משתני תוצאה בביטויים של הקצאת תוצאות

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

בדוגמה הבאה, הערך של משתנה התוצאה $risk_score נגזר ממשתנה התוצאה $event_count:

דוגמה: משתנה תוצאה שנגזר ממשתנה תוצאה אחר

match:
  // This is a multi event query with a match section.
  $hostname over 5m

outcome:
  // Aggregates all timestamp on login events in the 5 minute match window.
  $event_count = count($login.metadata.event_timestamp.seconds)

  // $event_count cannot be aggregated again.
  $risk_score = if($event_count > 5, "SEVERE", "MODERATE")

  // This is the equivalent of the 2 outcomes combined.
  $risk_score2 = if(count($login.metadata.event_timestamp.seconds) > 5, "SEVERE", "MODERATE")

condition:
  $e

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

  • צבירת נתונים
  • ‫Arrays.length() קריאות להפעלת פונקציות
  • עם מקשי הצירוף any או all

צבירת נתונים

שדות של אירועים חוזרים הם ערכים לא סקלריים. כלומר, משתנה אחד מצביע על כמה ערכים. לדוגמה, משתנה שדה האירוע $e.target.ip הוא שדה חוזר, ויכולים להיות לו אפס, אחד או הרבה ערכי IP. זה ערך לא סקלרי. לעומת זאת, המשתנה של שדה האירוע $e.principal.hostname הוא לא שדה חוזר ויש לו רק ערך אחד (כלומר ערך סקלרי).

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

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

השאילתה הבאה מקבצת אירועים באמצעות קטע `match` ומפנה לשדה אירוע שאינו חוזר בקטע `outcome`:

rule OutcomeAndMatchWindow{
  ...
  match:
    $userid over 5m
  outcome:
    $hostnames = array($e.principal.hostname)
  ...
}

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

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

  • שדות של אירועים (חוזרים או לא חוזרים) כשהשאילתה משתמשת בקטע match
  • פלייסהולדרים של אירועים (חוזרים או לא חוזרים) כשהשאילתה משתמשת בקטע match
  • שדות של אירועים חוזרים כשהשאילתה לא משתמשת בקטע match
  • פלייסהולדרים של אירועים חוזרים כשהשאילתה לא משתמשת בקטע match

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

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

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

פונקציית צבירה תיאור
max() פלט של הערך המקסימלי מבין כל הערכים האפשריים. פועל רק עם מספרים שלמים ומספרים עם נקודה צפה.
min() הפלט הוא הערך המינימלי מבין כל הערכים האפשריים. פועל רק עם מספרים שלמים ומספרים עם נקודה צפה.
sum() הפלט הוא הסכום של כל הערכים האפשריים. פועל רק עם מספרים שלמים ומספרים עם נקודה צפה.
count_distinct() אוספת את כל הערכים האפשריים, ואז מוציאה את מספר הערכים האפשריים הייחודיים.
count() הפונקציה פועלת כמו `count_distinct()‎`, אבל מחזירה ספירה לא ייחודית של ערכים אפשריים.
array_distinct() אוספת את כל הערכים הייחודיים האפשריים, ואז מפיקה רשימה של הערכים האלה. קודם מתבצעת הסרת כפילויות כדי ליצור רשימה ייחודית, ואז מתבצע חיתוך. בחיפוש, הרשימה נחתכת למקסימום של 1,000 רכיבים אקראיים. במרכזי הבקרה ובכללים, הרשימה נחתכת ל-25 רכיבים אקראיים לכל היותר.
array() הפונקציה פועלת כמו array_distinct(), אבל מחזירה רשימה של ערכים לא ייחודיים. בחיפוש Google, הרשימה נחתכת למקסימום של 1,000 רכיבים אקראיים. במרכזי הבקרה ובכללים, הרשימה נחתכת ל-25 רכיבים אקראיים לכל היותר.

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

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

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

outcome:
  $asset_id_count = count($event.principal.asset_id)
  $asset_id_distinct_count = count_distinct($event.principal.asset_id)

  $asset_id_list = array($event.principal.asset_id)
  $asset_id_distinct_list = array_distinct($event.principal.asset_id)

condition:
  #event > 1

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

event:
  // UDM event 1
  asset_id="asset-a"

event:
  // UDM event 2
  asset_id="asset-b"

event:
  // UDM event 3
  asset_id="asset-b"

אז הערכים של התוצאות יהיו:

    ‎$asset_id_count = 3
    ‎$asset_id_distinct_count = 2
    ‎$asset_id_list = `["asset-a", "asset-b", "asset-b"]
    ‎$asset_id_distinct_list = `["asset-a", "asset-b"]

מגבלות

  • בקטע outcome אי אפשר להפנות למשתנה פלייסהולדר חדש שלא הוגדר כבר בקטע events או בקטע outcome.

  • בקטע outcome אי אפשר להשתמש במשתני אירועים שלא הוגדרו בקטע events.

  • בקטע outcome אפשר להשתמש בשדה אירוע שלא נעשה בו שימוש בקטע events, בתנאי שמשתנה האירוע שאליו שייך שדה האירוע כבר הוגדר בקטע events.

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

בסקירה הכללית של YARA-L 2.0 מופיעות דוגמאות לקטע outcome.

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

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

מידע נוסף

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