סקירה כללית על 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: מערכות כמו packet sniffers שמנטרות את התנועה באופן פסיבי.

עיצוב אירוע 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 הוא היעד.

principal versus target in udm

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

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

target {
   ip: "198.51.100.31"
   port: 80
}

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

גם הגורם הראשי וגם היעד (ושמות עצם אחרים) יכולים להתייחס לשחקנים באותה מכונה. לדוגמה, אם תהליך א' (הגורם המבצע) שפועל במכונה X מבצע פעולה בתהליך ב' (היעד) שפועל גם הוא במכונה 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 הוא USER_LOGIN) שמשויכים למחלקת השיווק (target.user.department היא 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)
  • target
  • 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, שהיא חותמת הזמן לפי שעון GMT שבה האירוע התרחש. הערך חייב להיות מקודד לפי אחד מהתקנים הבאים: 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 field list.

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

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

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

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

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

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

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

  • ‫intermediary: כל אובייקט ששימש כמתווך באירוע. זה יכול לכלול אובייקטים כמו שרתי פרוקסי ושרתי אימייל.
  • ‫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:

  • שרת proxy לאבטחת אימייל זיהה ניסיון פישינג (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), ואז העבירה את האימייל המחוטא.
  • מערכת 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.

מאפיין הקשר

בשדות של מאפיין הקשר מאוחסן מידע על ישויות אחרות שהישות הראשית קשורה אליהן. לדוגמה, אם הישות הראשית היא 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.