סקירה כללית על ניתוח נתונים מבוסס הקשר

נתמך ב:

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

דוגמאות:

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

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

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

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

  • הקשר רלוונטי זמין לחישוב של ציון סיכונים הקשרי מבוסס-היוריסטיקה של זיהויים בזמן הביצוע של הזיהוי ולא בשלב המיון על ידי אדם
  • קיצור הזמן שמוקדש למיון ולחיבור ידני של מידע ממערכות שונות לאבטחת IT (מסופי EDR, יומני חומת אש או שרת proxy, הקשר CMDB ו-IAM, תוצאות סריקת פגיעויות)
  • התכונה מאפשרת לאנליסטים ולמהנדסי זיהוי לסנן אשכולות שלמים של איומים שצפויים או שלא מייצגים סכנה לארגון (בדיקות של תוכנות זדוניות בסביבת ארגז חול, נקודות חולשה ופעילות חריגה ברשת פיתוח ללא מידע אישי רגיש או גישה, ועוד).

כתיבת כללים לניתוח מבוסס-הקשר

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

כדי לחפש נתוני הקשר של ישות:

  1. מציינים מקור באמצעות udm או entity.

    $eventname.[<source>].field1.field2 בהקשר של ישות, הערך של <source> הוא graph. באירוע UDM, הערך של <source> הוא udm. אם לא מציינים את הפרמטר הזה, ברירת המחדל של <source> היא udm.

  2. מציינים את נתוני הישות:

    $e1.graph.entity.hostname = "my-hostname"

    $e1.graph.entity.relations.relationship = "OWNS"

  3. מציינים את נתוני האירוע של UDM. שתי ההצהרות הבאות שקולות.

    $e1.udm.principal.asset_id = "my_asset_id"

    $e1.principal.asset_id = "my_asset_id"

אתם יכולים ליצור הרבה כללים מאותו סוג עבור הקשרים של ישויות כמו עבור אירועי UDM, כולל הכללים הבאים:

  • כמה כללים של אירועים

  • השוואה בין הקשרים של ישויות שונות

  • השוואה בין הקשרים של ישויות לבין אירועים ב-UDM

  • שדות חוזרים בהקשרים של ישויות

  • חלונות הזזה

  • חישוב ציון הסיכון של זיהויים

בניגוד לאירוע UDM, להקשר של ישות אין חותמת זמן ספציפית. לכל רשומה של הקשר ישות יש מרווח זמן, entity.metadata.interval, שבו הקשר הישות תקף. המרווח הזה לא חייב להיות יום שלם, והוא יכול להיות בכל משך זמן.

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

  • כשמשווים אירועי UDM להקשר של ישות עם חלונות, ההקשר של הישות מייצג ערך קבוע בחלון שצוין.
  • אם יש משבצות זמן סמוכות שבהן הערך של הקשר של הישות משתנה, מערכת Google SecOps מנסה למצוא התאמה לכל הערכים של הקשר של הישות, ומחזירה את כל ההתאמות שנמצאו.

דוגמאות לכללים

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

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

rule LoginLogout {
  meta:
  events:
    ($log_inout.metadata.event_type = "USER_LOGIN" or  $log_inout.metadata.event_type = "USER_LOGOUT")
    $log_inout.principal.user.user_display_name = $user

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_inout and $context
}

דוגמה לחלון נע

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

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

דוגמה לחלון הזזה לא תקין

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

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

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

בדוגמה הבאה השתמשנו בקטע outcome כדי לחשב את ציון הסיכון של הזיהוי.

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

דוגמה להפעלה חשודה של תהליך

בדוגמה הבאה מתבצעת הערכה של נתוני תהליך אירועים ב-UDM בהשוואה לנתוני הקשר של IOC שמאוחסנים כהקשר של ישות.

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

תנאים נוספים להקשר של ישות

כדי ליצור משתנה אירוע שמשתמש בהקשר של ישות, צריך לספק <source> אחרי שם האירוע. הערך של <source> חייב להיות graph.

התבנית הבאה מתייחסת להקשר של ישות:

  • $e.graph.entity.hostname

שימו לב שיש שתי שיטות שוות ערך להתייחסות לאירוע UDM:

  • $u.udm.principal.asset_id
  • $u.principal.asset_id

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

קטע התוצאה

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

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

מידע מפורט על השימוש והתחביר של קטע outcome מופיע בקטע על התוצאה.

הקטע 'תוצאה' וביטול כפילויות בזיהוי או קיבוץ של זיהויים

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

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

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

הכלל הזה יתאים לתוצאות הבאות:

זיהוי 1: שם מארח: test-hostname חלון זמן: [t1, t2] ציון סיכון: 10

זיהוי 2: שם המארח: test-hostname חלון הזמן: [t1, t2] ציון הסיכון: 73

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

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

מידע על האופן שבו Google SecOps קולטת נתונים הקשריים ומעשירה ישויות זמין במאמר איך Google SecOps מעשירה נתונים של אירועים וישויות

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