סקירה כללית על UDM

נתמך ב:

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

UDM הוא מבנה נתונים סטנדרטי של Google Security Operations שמאחסן מידע על נתונים שהתקבלו ממקורות. הוא נקרא גם סכימה. ‫Google SecOps מאחסן את הנתונים המקוריים שהוא מקבל בשני פורמטים: כיומן גולמי מקורי וכרשומה מובנית של UDM. רשומת UDM היא ייצוג מובנה של היומן המקורי.

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

אלה כמה מהיתרונות של UDM:

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

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

מבנה UDM

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

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

  • ‫principal: הישות שממנה מגיעה הפעילות באירוע. כלולים גם קטעים שמפנים למקור (src) וליעד (target).
  • ‫intermediary: מערכות שאירועים עוברים דרכן, כמו שרת proxy או ממסר SMTP.
  • ‫observer: מערכות כמו כלי לניטור חבילות נתונים, שמנטרות את התנועה באופן פסיבי.

עיצוב אירוע UDM

כדי לפרמט אירוע UDM כדי להכין אותו לשליחה אל Google, צריך לבצע את השלבים הבאים:

  1. מציינים את סוג האירוע – סוג האירוע שבחרתם קובע אילו שדות נוספים אתם צריכים לכלול באירוע.
  2. מציינים את חותמת הזמן של האירוע.
  3. מציינים שמות עצם (ישויות) – כל אירוע חייב לכלול לפחות שם עצם אחד שמתאר מכשיר של משתתף או משתמש שמעורב באירוע.
  4. אופציונלי: ציון תוצאת האבטחה – אפשר לציין תוצאות אבטחה על ידי הוספת פרטים על הסיכונים והאיומים שמערכת האבטחה מוצאת. צריך לכלול את הפעולות הספציפיות שבוצעו כדי לצמצם את הסיכונים והאיומים האלה.
  5. ממלאים את שאר הפרטים הנדרשים והאופציונליים של האירוע באמצעות שדות האירוע של UDM.

מציינים את סוג האירוע

הערך הכי חשוב שמוגדר לכל אירוע שנשלח בפורמט UDM הוא סוג האירוע, שמצוין באמצעות אחד מהערכים האפשריים שזמינים ל-Metadata.event_type. הערכים האלה כוללים PROCESS_OPEN,‏ FILE_CREATION,‏ USER_CREATION,‏ NETWORK_DNS וכו' (לרשימה המלאה, ראו Metadata.event_type). בכל סוג אירוע צריך גם לאכלס קבוצה של שדות וערכים אחרים במידע שקשור לאירוע המקורי. במאמר שדות חובה ושדות אופציונליים לכל סוג אירוע ב-UDM מפורט אילו שדות צריך לכלול בכל סוג אירוע. בדוגמה הבאה אפשר לראות איך מציינים את PROCESS_OPEN כסוג האירוע באמצעות סימון טקסט של Proto3:

metadata {
    event_type: PROCESS_OPEN
}

ציון חותמת הזמן של האירוע

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

  • בפורמט JSON, משתמשים ב-RFC 3339
  • חותמת זמן של Proto3

בדוגמה הבאה אפשר לראות איך מציינים את חותמת הזמן באמצעות פורמט RFC 3339. בדוגמה הזו, yyyy-mm-ddThh:mm:ss+hh:mm – שנה, חודש, יום, שעה, דקה, שנייה וההפרש משעון UTC. ההפרש מ-UTC הוא מינוס 8 שעות, כלומר שעון החוף המערבי (PST).

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

ציון שמות עצם (ישויות)

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

אירוע UDM חייב לכלול לפחות אחד מהשמות העצם הבאים:

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

אם כל הפעילות מתרחשת במכונה אחת, צריך לתאר רק את המכונה הזו בבלוק principal. אל תשכפלו את פרטי המכונה ב-target או ב-src.

בדוגמה הבאה אפשר לראות איך אפשר למלא את השדות של principal:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

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

‫target: מייצג את המכשיר או האובייקט שהאירוע מתייחס אליהם. בחיבור חומת אש ממכשיר א' למכשיר ב', א' הוא הגורם המרכזי וב' הוא היעד. במקרה של הזרקת תהליך שבו תהליך C מוזרק לתהליך D, ‏ C הוא העיקרי ו-D הוא היעד.

המשתמש הראשי לעומת היעד ב-UDM

חשבון ראשי לעומת יעד ב-UDM

בדוגמה הבאה אפשר לראות איך השדות של יעד מאוכלסים:

target {
   ip: "198.51.100.31"
   port: 80
}

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

גם הגורם הראשי וגם היעד (ושמות עצם אחרים) יכולים להתייחס לשחקנים באותו מחשב. לדוגמה, אם תהליך A (principal) שפועל במכונה X מבצע פעולה בתהליך B (target) שגם הוא במכונה X, צריך לתאר את שניהם בבלוקים המתאימים.

  • ‫src: מייצג את אובייקט המקור שעליו מתבצעת הפעולה ואת ההקשר שלו, כמו המכונה שבה הוא נמצא. לדוגמה, אם משתמש U מעתיק את קובץ A במכונה X לקובץ B במכונה Y, צריך לציין את קובץ A ואת מכונה X בבלוק src.

  • intermediary: מכיל פרטים של מכשיר אחד או יותר שעיבדו את הפעילות שמתוארת באירוע. המידע הזה כולל פרטים על מכשירים כמו שרתי proxy וממסרי SMTP.

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

  • ‫about: מאחסן פרטים של אובייקטים שהאירוע מתייחס אליהם ושלא מתאימים ל-participant, ל-src, ל-target, ל-intermediary או ל-observer. אפשר להשתמש בו כדי לעקוב אחרי דברים כמו:

    • קבצים מצורפים לאימייל
    • דומיינים, כתובות URL או כתובות IP שמוטמעים בתוכן האימייל
    • קובצי DLL שנטענים במהלך אירוע PROCESS_LAUNCH

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

ציון תוצאת האבטחה

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

  • חומת אש של שרת proxy לאבטחת אימייל זיהתה שני קבצים מצורפים נגועים (SOFTWARE_MALICIOUS). הוא העביר אותם להסגר וחיטא אותם (QUARANTINE, ALLOW_WITH_MODIFICATION), ואז העביר את האימייל המחוטא.

  • מערכת SSO סייעה בניסיון כניסה שהוביל לAUTH_VIOLATION ונחסם (BLOCK).

  • ארגז חול לזיהוי תוכנות זדוניות זיהה תוכנת ריגול (SOFTWARE_MALICIOUS) בקובץ מצורף חמש דקות אחרי שהמערכת העבירה (ALLOW) את האימייל לתיבת הדואר הנכנס של המשתמש.

דוגמאות לחיפושים ב-UDM

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

דוגמה: חיפוש של התחברויות מוצלחות ל-Microsoft Windows 4624

החיפוש הבא מציג את אירועי הכניסה המוצלחת של Microsoft Windows 4624, יחד עם התאריך והשעה שבהם האירועים נוצרו, על סמך שני שדות UDM בלבד:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

דוגמה: חיפוש של כל הכניסות המוצלחות

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

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

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

בדוגמה הבאה אפשר לראות איך לחפש את userid "fkolzig" ולקבוע מתי המשתמש עם מזהה המשתמש הזה התחבר בהצלחה. אפשר להשלים את החיפוש הזה באמצעות קטע היעד. הקטע 'יעד' כולל קטעי משנה ושדות שמתארים את היעד. לדוגמה, היעד במקרה הזה הוא משתמש ויש לו מספר מאפיינים משויכים, אבל היעד יכול להיות גם קובץ, הגדרת רישום או נכס. בדוגמה הזו מחפשים את "fkolzig" באמצעות השדה target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

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

בדוגמה הבאה מתבצע חיפוש בנתוני הרשת של אירועי RDP עם target.port של 3389 ועם principal.ip של 35.235.240.5. הוא כולל גם שדה UDM מהקטע network, את כיוון הנתונים (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

דוגמה: חיפוש של תהליך ספציפי

כדי לבדוק את התהליכים שנוצרו בשרתים, מחפשים מופעים של הפקודה net.exe ומחפשים את הקובץ הספציפי הזה בנתיב הצפוי שלו. השדה שחיפשת הוא target.process.file.full_path. בחיפוש הזה, כוללים את הפקודה הספציפית שהונפקה בשדה target.process.command_line. אפשר גם להוסיף שדה בקטע 'מידע' שהוא התיאור של קוד האירוע 1 (ProcessCreate) של Microsoft Sysmon.

זוהי חיפוש UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

אפשר גם להוסיף את שדות החיפוש הבאים של UDM:

  • ‫principal.user.userid: זיהוי המשתמש שנותן את הפקודה.
  • ‫principal.process.file.md5: זיהוי גיבוב MD5.
  • ‫principal.process.command_line: שורת פקודה.

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

בדוגמה הבאה מוצג חיפוש של התחברויות של משתמשים (metadata.event_type is USER_LOGIN) שמשויכים למחלקת השיווק (target.user.department is marketing) בארגון שלכם. למרות ש-target.user.department לא מקושר ישירות לאירועי התחברות של משתמשים, הוא עדיין מופיע בנתוני ה-LDAP שמיובאים לגבי המשתמשים שלכם.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

אובייקטים לוגיים: אירוע וישות

סכימת ה-UDM מתארת את כל המאפיינים הזמינים שמאחסנים נתונים. כל רשומה ב-UDM מציינת אם היא מתארת אירוע או ישות. הנתונים מאוחסנים בשדות שונים בהתאם לסוג הרשומה (אירוע או ישות) וגם בהתאם לערך שמוגדר בשדה metadata.event_type או metadata.entity_type.

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

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

מודל של נתוני אירועים

איור: מודל של נתוני אירועים

מודל נתונים של ישות

איור: מודל נתונים של ישויות

המבנה של אירוע UDM

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

  • מטא-נתונים
  • משתמש (principal)
  • יעד
  • src
  • משקיף
  • מתווך
  • מידע כללי
  • network
  • security_result

  • תוספים

    מודל של נתוני אירועים

    איור: מודל של נתוני אירועים

בקטע metadata מאוחסנת חותמת הזמן, מוגדר event_type ומתואר המכשיר.

בקטעים principal, target, src, observer ו-intermediary מאוחסן מידע על האובייקטים שקשורים לאירוע. אובייקט יכול להיות מכשיר, משתמש או תהליך. ברוב המקרים, רק חלק מהקטעים האלה נמצאים בשימוש. השדות שבהם מאוחסנים הנתונים נקבעים לפי סוג האירוע והתפקיד של כל אובייקט באירוע.

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

  • נתוני אימייל: מידע בשדות to, from, cc, bcc ושדות אחרים באימייל.
  • נתוני HTTP: כמו method, referral_url ו-useragent.

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

בקטעים about ו-extensions מאוחסן מידע נוסף על אירועים ספציפיים לספק, שלא נכלל בקטעים האחרים. הקטע extensions הוא קבוצה חופשית של צמדי מפתח/ערך.

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

אם לא מאוחסנים נתונים בקטע של רשומת UDM, למשל בקטע extensions, הקטע הזה לא יופיע ברשומת UDM.

שדות המטא-נתונים

בקטע הזה מתוארים השדות שנדרשים באירוע UDM.

השדה event_timestamp

אירועים ב-UDM חייבים לכלול נתונים של metadata.event_timestamp, שהיא חותמת הזמן לפי שעון גריניץ' שבה האירוע התרחש. הערך חייב להיות מקודד באמצעות אחד מהתקנים הבאים: RFC 3339 או חותמת זמן של Proto3.

בדוגמאות הבאות מוסבר איך לציין את חותמת הזמן באמצעות פורמט RFC 3339,‏ yyyy-mm-ddThh:mm:ss+hh:mm (שנה, חודש, יום, שעה, דקה, שנייה וההפרש משעון UTC). הקיזוז מ-UTC הוא מינוס 8 שעות, מה שמציין PST.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

אפשר גם לציין את הערך באמצעות פורמט epoch.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

השדה event_type

השדה הכי חשוב באירוע UDM הוא metadata.event_type. הערך הזה מזהה את סוג הפעולה שבוצעה והוא לא תלוי בספק, במוצר או בפלטפורמה. דוגמאות לערכים: PROCESS_OPEN,‏ FILE_CREATION,‏ USER_CREATION ו-NETWORK_DNS. הרשימה המלאה מופיעה במסמך רשימת השדות של UDM.

הערך של metadata.event_type קובע אילו שדות נוספים נדרשים ואופציונליים צריך לכלול ברשומת UDM. מידע על השדות שצריך לכלול בכל סוג אירוע זמין במדריך לשימוש ב-UDM.

המאפיינים principal,‏ target,‏ src,‏ intermediary,‏ observer ו-about

המאפיינים principal, target, src, intermediary ו-observer מתארים נכסים שקשורים לאירוע. כל רשומה מכילה מידע על האובייקטים שקשורים לפעילות, כפי שתועד ביומן הגולמי המקורי. יכול להיות שזה המכשיר או המשתמש שביצעו את הפעילות, או המכשיר או המשתמש שהם היעד של הפעילות. יכול להיות שיופיע גם תיאור של מכשיר אבטחה שזיהה את הפעילות, כמו שרת proxy של אימייל או נתב רשת.

המאפיינים הנפוצים ביותר הם:

  • ‫principal: האובייקט שביצע את הפעילות.
  • ‫src: האובייקט שיזם את הפעילות, אם הוא שונה מהחשבון הראשי.
  • ‫target: האובייקט שעליו מתבצעת הפעולה.

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

השדות הנוספים הם:

  • ‫intermediary: כל אובייקט ששימש כמתווך באירוע. האובייקטים האלה יכולים לכלול שרתי proxy ושרתי אימייל.
  • ‫observer: כל אובייקט שלא מתקשר ישירות עם התנועה הרלוונטית. יכול להיות שמדובר בסורק פגיעויות או במכשיר לניטור חבילות.
  • ‫about: אובייקטים אחרים שהיו להם תפקיד באירוע (אופציונלי).

המאפיינים העיקריים

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

אם האירוע מתרחש במכונה אחת, המכונה הזו מתוארת רק במאפיין principal. אין צורך לתאר את המכונה במאפיינים target או src.

בקטע ה-JSON הבא אפשר לראות איך יכול להיות שמאכלסים את מאפיין principal.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

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

מאפייני היעד

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

במקרה של הזרקת תהליך על ידי תהליך C לתהליך היעד D, תהליך C הוא העיקרי ותהליך D הוא היעד.

הישות המורשית לעומת היעד

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

בדוגמה הבאה אפשר לראות איך אפשר לאכלס את שדה היעד.

target {
   ip: "192.0.2.31"
   port: 80
}

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

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

המאפיין src

מייצג אובייקט מקור שהמשתתף מבצע בו פעולה, יחד עם ההקשר של המכשיר או התהליך של אובייקט המקור (המכונה שבה נמצא אובייקט המקור). לדוגמה, אם משתמש U מעתיק את קובץ A במכונה X לקובץ B במכונה Y, גם קובץ A וגם מכונה X יצוינו בחלק src של אירוע UDM.

מאפיין הביניים

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

מאפיין הצופה

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

מאפיין המידע

השדה הזה מכיל פרטים על אובייקט שהאירוע מפנה אליו, שלא מתואר בשדות principal,‏ src,‏ target,‏ intermediary או observer. לדוגמה, יכול להיות שהיא תתעד את הפעולות הבאות:

  • קבצים מצורפים לאימייל.
  • דומיינים, כתובות URL או כתובות IP שמוטמעים בתוכן האימייל.
  • קובצי DLL שנטענים במהלך אירוע PROCESS_LAUNCH.

המאפיין security_result

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

אלה סוגי המידע שייאוחסנו במאפיין security_result:

  • פרוקסי לאבטחת אימייל זיהה ניסיון פישינג (security_result.category = MAIL_PHISHING) וחסימה (security_result.action = BLOCK) של האימייל.
  • חומת אש של שרת proxy לאבטחת אימייל זיהתה שני קבצים מצורפים נגועים (security_result.category = SOFTWARE_MALICIOUS), הכניסה אותם להסגר (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION) וניקתה אותם (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION), ואז העבירה את האימייל הנקי.
  • מערכת SSO מאפשרת התחברות (security_result.category = AUTH_VIOLATION) שנחסמה (security_result.action = BLOCK).
  • ארגז חול לזיהוי תוכנות זדוניות זיהה תוכנת ריגול (security_result.category = SOFTWARE_MALICIOUS) בקובץ מצורף חמש דקות אחרי שהקובץ נמסר (security_result.action = ALLOW) למשתמש בתיבת הדואר הנכנס שלו.

מאפיין הרשת

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

מאפיין התוספים

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

המבנה של ישות UDM

רשומה של ישות ב-UDM מאחסנת מידע על כל ישות בארגון. אם הערך של metadata.entity_type הוא USER, הרשומה שומרת מידע על המשתמש במאפיין entity.user. אם הערך של metadata.entity_type הוא ASSET, הרשומה מכילה מידע על נכס, כמו תחנת עבודה, מחשב נייד, טלפון ומכונה וירטואלית.

מודל נתונים של ישות

איור: מודל של נתוני אירועים

שדות המטא-נתונים

הקטע הזה מכיל שדות שנדרשים בישות UDM, כמו:

  • ‫collection_timestamp: התאריך והשעה שבהם נאסף הרשומה.
  • ‫entity_type: סוג הישות, כמו נכס, משתמש ומשאב.

מאפיין הישות

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

  • אם הערך של metadata.entity_type הוא USER, הנתונים נשמרים במאפיין entity.user.
  • אם הערך של metadata.entity_type הוא ASSET, הנתונים מאוחסנים במאפיין entity.asset.

מאפיין הקשר

בשדות שמתחת למאפיין relation מאוחסן מידע על ישויות אחרות שהישויות העיקריות קשורות אליהן. לדוגמה, אם הישות הראשית היא User (משתמש) והמשתמש קיבל מחשב נייד. המחשב הנייד הוא ישות קשורה. המידע על המחשב הנייד מאוחסן כרשומה entity עם metadata.entity_type = ASSET. המידע על המשתמש מאוחסן כרשומת entity עם הערך metadata.entity_type = USER.

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

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

בשדה relation.direction מאוחסנת הכיווניות של הקשר בין המשתמש לבין המחשב הנייד, כלומר אם הקשר הוא דו-כיווני או חד-כיווני.

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