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

נתמך ב:

Google SecOps SIEM

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

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

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

חלק מהיתרונות של UDM:

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

הערה: מנוע הכללים של Google SecOps משתמש באותם שמות של שדות 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). לכל סוג אירוע צריך גם לאכלס קבוצה של שדות וערכים אחרים עם המידע שקשור לאירוע המקורי. כדי לדעת אילו שדות צריך לכלול בכל סוג אירוע, אפשר לעיין בקטע שדות חובה ושדות אופציונליים לכל סוג אירוע.

הדוגמה הבאה ממחישה איך לציין את 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 יש מגבלה של 256 תווים (לדוגמה, principal.hostname או target.hostname). מיפוי של יומנים גולמיים (ממקור כמו ArcSight) שחורגים מהמגבלה הזו גורם לכשלים באימות וליומנים שנמחקים. ההגדרה הזו לא ספציפית למנתחים מסוימים.

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

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

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

הערה: אל תתארו אמצעי אבטחה בשדה principal, גם אם הם המקור לאירוע. במקום זאת, צריך להשתמש בשדות observer או intermediary. אם תוכנת האבטחה פועלת באותו מכשיר שממנו בוצעה הפעילות (כמו סוכן EDR בנקודת קצה של Windows), המכשיר הזה הוא עדיין חשבון המשתמש.

בדוגמה הבאה אפשר לראות איך אפשר לאכלס את השדות של 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

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

target {
   ip: "198.51.100.31"
   port: 80
}

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

גם principal וגם target (ושמות עצם אחרים) יכולים להתייחס לגורמים באותו מכשיר. לדוגמה, אם תהליך א' (חשבון משתמש) שפועל במכונה 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" ולקבוע מתי המשתמש עם מזהה המשתמש הזה התחבר בהצלחה. אפשר להשלים את החיפוש הזה באמצעות הקטע "יעד". הקטע target כולל סעיפי משנה ושדות שמתארים את היעד. לדוגמה, היעד במקרה הזה הוא משתמש ויש לו כמה מאפיינים משויכים, אבל היעד יכול להיות גם קובץ, הגדרת מרשם או נכס. בדוגמה הזו, החיפוש של "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.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 של Microsoft Sysmon‏ (ProcessCreate).

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

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

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

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

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

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

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

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

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

המאפיינים של ה-principal

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

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

הערה: מכשיר אבטחה יכול לתעד אירוע, אבל הוא לא יתואר במאפיין הראשי. הוא יתואר במאפיין observer או במאפיין intermediary. אם תוכנת האבטחה (לדוגמה, Carbon Black) פועלת באותו מכשיר שממנו בוצעה הפעילות (לדוגמה, נקודת קצה של Windows שבה זוהתה תוכנה זדונית), מכשיר Windows יהיה החשבון הראשי.

קטע ה-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 הוא ה-principal ותהליך D הוא היעד.

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

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

target {
   ip: "192.0.2.31"
   port: 80
}

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

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

המאפיין src

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

המאפיין "מתווך"

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

המאפיין observer

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

המאפיין about

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

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

המאפיין security_result

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

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

• שרת proxy לאבטחת אימייל זיהה ניסיון פישינג (security_result.category = MAIL_PHISHING) וחסם (security_result.action = BLOCK) את האימייל.
• חומת אש של שרת פרוקסי לאבטחת אימייל זיהתה שני קבצים מצורפים נגועים (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) למשתמש בתיבת הדואר הנכנס שלו.

המאפיין network

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

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

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

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

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

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

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

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

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

מאפיין הישות

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

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

מאפיין הקשר

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