סקירה כללית של מודל הנתונים המאוחד

נתמך ב:

במסמך הזה מפורטת סקירה כללית של מודל הנתונים המאוחד (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 יש דרישות חובה לגבי אכלוס שדות של שמות עצם. הדרישות האלה מתוארות במאמר Required and Optional Fields for Each UDM Event Type (שדות חובה ושדות אופציונליים לכל סוג אירוע 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" ולקבוע מתי המשתמש עם מזהה המשתמש הזה התחבר בהצלחה. אפשר לבצע את החיפוש הזה באמצעות הקטע target. הקטע target כולל שדות ותתי-קטעים שמתארים את היעד. לדוגמה, היעד במקרה הזה הוא משתמש ויש לו מספר מאפיינים משויכים, אבל היעד יכול להיות גם קובץ, הגדרת רישום או נכס. בדוגמה הזו מתבצע חיפוש של userid "fkolzig" באמצעות השדה target.user.userid."fkolzig"

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.