ניתוח סיכונים ל-UEBA

נתמך ב:

במסמך הזה מוסבר על קבוצות הכללים בקטגוריה Risk Analytics for UEBA, על הנתונים הנדרשים ועל ההגדרות שבהן אפשר להשתמש כדי לכוונן את ההתראות שנוצרות על ידי כל קבוצת כללים. קבוצות הכללים האלה עוזרות לזהות איומים על ידי הערכה של מקורות היומן הנתמכים.

תיאורים של קבוצות כללים

קבוצות הכללים הבאות זמינות בקטגוריה Risk Analytics for UEBA, והן מקובצות לפי סוג הדפוסים שזוהו:

אימות

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

ניתוח תנועה ברשת

  • חריגה בבייטים נכנסים לפי מכשיר: כמות משמעותית של נתונים שהועלו לאחרונה לישות של מכשיר יחיד, בהשוואה לשימוש היסטורי.
  • חריגה בבייטים יוצאים לפי מכשיר: כמות משמעותית של נתונים שהורדו לאחרונה מישות של מכשיר יחיד, בהשוואה לשימוש היסטורי.
  • Anomalous Total Bytes by Device: ישות של מכשיר העלתה והורידה לאחרונה כמות משמעותית של נתונים, בהשוואה לשימוש היסטורי.
  • Anomalous Inbound Bytes by User: ישות של משתמש יחיד הורידה לאחרונה כמות משמעותית של נתונים, בהשוואה לשימוש היסטורי.
  • חריגה בסך הבייטים לפי משתמש: ישות משתמש העלתה והורידה לאחרונה כמות משמעותית של נתונים, בהשוואה לשימוש היסטורי.
  • התקפת כוח ברוטלית ואז התחברות מוצלחת של משתמש: יישות של משתמש יחיד מכתובת IP אחת ביצעה כמה ניסיונות אימות שנכשלו לאפליקציה מסוימת לפני שהצליחה להתחבר.

זיהויים שמבוססים על קבוצות של חברות להשוואה

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

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

פעולות חשודות

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

זיהויים שמבוססים על מניעת אובדן נתונים

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

הנתונים הנדרשים לניתוח סיכונים לקטגוריית UEBA

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

אימות

כדי להשתמש באחד מסדרות הכללים האלה, צריך לאסוף נתוני יומן מ-Azure AD Directory Audit ‏ (AZURE_AD_AUDIT) או מ-Windows Event ‏ (WINEVTLOG).

ב-WINEVTLOG, צריך להגדיר את הגדרות איסוף הנתונים כך שיכללו את Event IDs Windows הבאים ביומן האירועים Security Channel. האירועים האלה ממופים ישירות ל-Event types (לדוגמה, USER_LOGIN או PROCESS_LAUNCH) שמשמשים את מנוע הזיהוי.

דרישות לגבי מזהה אירוע ב-Windows

סוג אירוע מזהה אירוע ב-Windows
USER_LOGIN 529, 4624, 4625, 4626, 4648, 4672, 4768, 4769, 4770, 4771, 4777, 4820, 4821, 4964
USER_CREATION 4720
NETWORK_CONNECTION 4096, 4097, 4321, 5156, 5632, 5633, 5157
GROUP_MODIFICATION 4728, 4729, 4732, 4733, 4735, 4737, 4745, 4746, 4747, 4750, 4751, 4752, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4784, 4785, 4786, 4787, 4788, 4791
PROCESS_LAUNCH 4688
PROCESS_OPEN 4663, 4670, 4691, 8002

ניתוח תנועה ברשת

כדי להשתמש באחד מהכללים האלה, צריך לאסוף נתוני יומן שמתעדים את פעילות הרשת. לדוגמה, ממכשירים כמו FortiGate ‏ (FORTINET_FIREWALL), Check Point ‏ (CHECKPOINT_FIREWALL), Zscaler ‏ (ZSCALER_WEBPROXY), CrowdStrike Falcon ‏ (CS_EDR) או Carbon Black ‏ (CB_EDR).

זיהויים שמבוססים על קבוצות של חברות להשוואה

כדי להשתמש באחד מסדרות הכללים האלה, צריך לאסוף נתוני יומן מ-Azure AD Directory Audit ‏ (AZURE_AD_AUDIT) או מ-Windows Event ‏ (WINEVTLOG).

פעולות חשודות

כללים בקבוצה הזו משתמשים בסוג נתונים שונה.

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

כדי להשתמש בקבוצת הכללים הזו, צריך לאסוף נתוני יומנים מ-Azure AD Directory Audit ‏ (AZURE_AD_AUDIT) או מ-Windows Event ‏ (WINEVTLOG).

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

כדי להשתמש בקבוצת הכללים הזו, צריך לאסוף נתוני יומן שמתעדים פעילויות בנקודות קצה או נתוני ביקורת, כמו אלה שתועדו על ידי CrowdStrike Falcon‏ (CS_EDR), Carbon Black‏ (CB_EDR) או Azure AD Directory Audit‏ (AZURE_AD_AUDIT).

זיהויים שמבוססים על מניעת אובדן נתונים

כדי להשתמש באחד מסדרות הכללים האלה, צריך לאסוף נתוני יומן שמתעדים פעילויות של תהליכים וקבצים, כמו אלה שתועדו על ידי CrowdStrike Falcon‏ (CS_EDR), Carbon Black‏ (CB_EDR) או SentinelOne EDR‏ (SENTINEL_EDR).

קבוצות הכללים בקטגוריה הזו תלויות באירועים עם הערכים הבאים של metadata.event_type: PROCESS_LAUNCH, ‏ PROCESS_OPEN, ‏ PROCESS_MODULE_LOAD.

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

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

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

דוגמה לכלל של ניתוח סיכונים לקטגוריית UEBA

בדוגמה הבאה מוצג אופן היצירה של כלל ליצירת זיהויים בכל שם מארח של ישות שציון הסיכון שלה גבוה מ-100:

rule EntityRiskScore {
  meta:
  events:
    $e1.principal.hostname != ""
    $e1.principal.hostname = $hostname

    $e2.graph.entity.hostname = $hostname
    $e2.graph.risk_score.risk_window_size.seconds = 86400 // 24 hours
    $e2.graph.risk_score.risk_score >= 100

    // Run deduplication across the risk score.
    $rscore = $e2.graph.risk_score.risk_score

  match:
    // Dedup on hostname and risk score across a 4 hour window.
    $hostname, $rscore over 4h

  outcome:
    // Force these risk score based rules to have a risk score of zero to
    // prevent self feedback loops.
    $risk_score = 0

  condition:
    $e1 and $e2
}

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

חלונות הזמן האפשריים היחידים לכללים של ניקוד סיכון של ישות הם 24 שעות או 7 ימים (86,400 או 604,800 שניות בהתאמה). אם לא כוללים את גודל חלון הסיכון בכלל, הכלל מחזיר תוצאות לא מדויקות.

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

rule EntityContextAndRiskScore {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.hostname = $host

    $context.graph.entity.hostname = $host
    $context.graph.metadata.entity_type = "ASSET"

    $risk_score.graph.entity.hostname = $host
    $risk_score.graph.risk_score.risk_window_size.seconds = 604800

  match:
    $host over 2m

  outcome:
    $entity_risk_score = max($risk_score.graph.risk_score.normalized_risk_score)

  condition:
    $log_in and $context and $risk_score and $entity_risk_score > 100
}

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

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