העשרה

נתמך ב:

ההעשרה משתמשת בשיטות הבאות כדי להוסיף הקשר לאינדיקטור או לאירוע במודל נתונים מאוחד (UDM):

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

צפייה באירועים

אפשר לראות את האירועים בכרטיסייה Event Fields (שדות אירועים) במציג האירועים. בכרטיסייה הזו מוצגים שדות של אירועי UDM במבנה עץ היררכי, עם התווית Selected (נבחר). כל שדה ב-UDM מסומן בסמל שמציין אם השדה מכיל נתונים מועשרים או לא מועשרים. אלה התוויות של הסמלים:

  • U: שדות לא מועשרים שואבים ערכים ישירות מיומן הגולמי המקורי במהלך תהליך הנרמול.
  • ‫E: שדות מועשרים מכילים ערכים שנוצרו על ידי Google SecOps כדי לספק הקשר נוסף לגבי ארטיפקטים בסביבה שלכם.

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

הסבר על דפוסי לוגיקה של העשרה

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

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

העשרת נכסים

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

‫Google SecOps מעשיר אירועים של נכסים שמסווגים עם אותו מרחב שמות.

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

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

לכל אירוע של נכס, צינור העיבוד מחלץ את השדות הבאים של UDM מהישויות principal,‏ src ו-target:

שדה UDM סוג האינדיקטור לוגיקה / קדימות
hostname שם מארח מיזוג: התוצאות של הכינויים מהשדות האלה משולבות כדי ליצור את רשומת הנכס הסופית המועשרת.
asset_id PRODUCT_SPECIFIC_ID מיזוג: מזהה ראשי שמשמש לאיחוד ההקשר של הנכס.
mac MAC מוזג: נעשה בו שימוש בשילוב עם מזהים אחרים כדי לזהות את הנכס.
ip קניין רוחני (IP) Fallback: נכלל בשאילתת ההעשרה רק אם asset_id לא זמין.

העשרת נתוני משתמשים

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

לכל אירוע משתמש, צינור עיבוד הנתונים מחלץ את השדות הבאים של UDM מ-principal, src ו-target:

שדה UDM סוג האינדיקטור לוגיקה או קדימות
user.email_addresses אימייל העדיפות הכי גבוהה: הצינור מנסה קודם להעשיר את הנתונים על סמך כתובות האימייל הראשיות או המשניות של המשתמש.
user.windows_sid WINDOWS_SID עדיפות שנייה: אם אין כתובת אימייל זמינה, צינור הנתונים משתמש במזהה האבטחה (SID) של Windows.
user.userid USER_ID עדיפות שלישית: משמשת רק אם חסרים כתובת אימייל ומזהה SID. בדרך כלל ממופה למזהים מקומיים או למזהים ספציפיים לאפליקציה.
user.employee_id EMPLOYEE_ID העדיפות הכי נמוכה: הגיבוי האחרון לפתרון בעיה שקשורה לזהות המשתמש.

לכל אינדיקטור, צינור הנתונים מבצע את הפעולות הבאות:

  • מאחזר רשימה של ישויות משתמשים. לדוגמה, הישויות של principal.email_address ושל principal.userid יכולות להיות זהות או שונות.
  • המערכת בוחרת את הכינויים מסוג האינדיקטור עם העדיפות הכי גבוהה, לפי סדר העדיפות הבא: WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID ו-PRODUCT_OBJECT_ID.
  • השדה noun.user מאוכלס עם הישות שהמרווח שבו היא תקפה מצטלב עם זמן האירוע.

העשרה של תהליכים

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

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

ישות UDM מקור השדה לוגיקה או עדיפות
ישויות ראשיות principal, src, target חילוץ: צינור הנתונים מחלץ את ה-PSPI מהישויות ברמה העליונה כדי להתחיל את החיפוש.
תהליכים ראשיים principal.process.parent_process,
src.process.parent_process,
target.process.parent_process 		מיפוי: ה-PSPI מאחזר פרטים על תהליך האב באמצעות כינוי תהליכים.
מיזוג נתונים noun.process (לדוגמה, principal.process) כלל החלפה: לשדות עם כינוי יש עדיפות מוחלטת. אם קיימים גם נתונים מנותחים וגם נתונים עם כינוי לאותו שדה, צינור הנתונים מחליף את הנתונים המנותחים בנתונים עם הכינוי.

הפייפליין משתמש בכינוי תהליך כדי לזהות את התהליך בפועל מתוך ה-PSPI, ומאחזר מידע על תהליך האב. לאחר מכן, המערכת ממזגת את הנתונים האלה בשדה noun.process המתאים בהודעה המועשרת.

שדות שאפשר להוסיף לאינדקס ב-EDR לצורך כינוי תהליכים

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

בטבלה הבאה מפורטים השדות שמתווספים לאינדקס במהלך אירוע של הפעלת תהליך:

שדה UDM סוג האינדיקטור
target.product_specific_process_id PROCESS_ID
target.process התהליך כולו, לא רק האינדיקטור

בנוסף לשדה target.process מהאירוע שעבר נורמליזציה, Google SecOps אוסף ומבצע אינדוקס של מידע על תהליך האב.

העשרה של פריט מידע שנוצר בתהליך פיתוח (Artifact

העשרה של ארטיפקטים מוסיפה מטא-נתונים של גיבוב קבצים מ-VirusTotal ונתוני מיקום גיאוגרפי של כתובות IP. במקרה של גיבוב קבצים, הצינור מפסיק כשנמצא הערך הראשון ברשימה לפי סדר עדיפות. עם זאת, בכתובות IP, הוא מעבד את כל הרשומות במקביל. לכל אירוע UDM, צינור העיבוד מחלץ ומבצע שאילתות על נתוני הקשר של האינדיקטורים הבאים של ארטיפקטים מהישויות principal, src ו-target, כאשר התנהגות ההעשרה משתנה בהתאם לסוג האינדיקטור:

סוג האינדיקטור לוגיקת החילוץ סדר קדימות / סדר פעולות
גיבובים (hash) של קבצים משחק ראשון הצינור מחפש גיבובים בסדר הבא ובוחר רק את הגיבוב הראשון שזמין לשאילתת VirusTotal:
  1. file.sha256
  2. file.sha1
  3. file.md5
  4. process.file.sha256
  5. process.file.sha1
  6. process.file.md5
כתובת IP מקביל (חוזר) כל כתובת IP ציבורית או ניתנת לניתוב נחשבת כרשומה עצמאית. אין סדר עדיפות, וכל כתובת IP מקבלת תוצאות העשרה משלה.

הצינור משתמש בראשית זמן יוניקס (Unix epoch) ובשעת האירוע כדי להגדיר את טווח הזמן של השאילתות של ארטיפקט הקובץ. אם נתוני מיקום גיאוגרפי זמינים, הצינור מחליף את השדות הבאים ב-UDM עבור הישויות principal, src ו-target, על סמך המקור של נתוני המיקום הגיאוגרפי:

  • artifact.ip
  • artifact.location
  • ‫artifact.network (רק אם הנתונים כוללים הקשר של רשת IP)
  • ‫location (רק אם הנתונים המקוריים לא כוללים את השדה הזה)

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

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

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

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

הוספת מטא-נתונים של קבצים מ-VirusTotal לאירועים

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

‫Google SecOps משלב מטא-נתונים של קבצים ושיפורים של קשרים מ-VirusTotal כדי לזהות דפוסים של פעילות זדונית ולעקוב אחרי תנועות של תוכנות זדוניות ברשת.

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

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

סוג הנתונים שדה UDM
sha-256 ( principal | target | src | observer ).file.sha256
md5 ( principal | target | src | observer ).file.md5
sha-1 ( principal | target | src | observer ).file.sha1
size ( principal | target | src | observer ).file.size
ssdeep ( principal | target | src | observer ).file.ssdeep
vhash ( principal | target | src | observer ).file.vhash
authentihash ( principal | target | src | observer ).file.authentihash
מטא-נתונים של קובץ PE‏ Imphash ( principal | target | src | observer ).file.pe_file.imphash
security_result.threat_verdict ( principal | target | src | observer ).(process | file).security_result.threat_verdict
security_result.severity ( principal | target | src | observer ).(process | file).security_result.severity
last_modification_time ( principal | target | src | observer ).file.last_modification_time
first_seen_time ( principal | target | src | observer ).file.first_seen_time
last_seen_time ( principal | target | src | observer ).file.last_seen_time
last_analysis_time ( principal | target | src | observer ).file.last_analysis_time
exif_info.original_file ( principal | target | src | observer ).file.exif_info.original_file
exif_info.product ( principal | target | src | observer ).file.exif_info.product
exif_info.company ( principal | target | src | observer ).file.exif_info.company
exif_info.file_description ( principal | target | src | observer ).file.exif_info.file_description
signature_info.codesign.id ( principal | target | src | observer ).file.signature_info.codesign.id
signature_info.sigcheck.verfied ( principal | target | src | observer ).file.signature_info.sigcheck.verified
signature_info.sigcheck.verification_message ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message
signature_info.sigcheck.signers.name ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name
signature_info.sigcheck.status ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status
signature_info.sigcheck.valid_usage ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage
signature_info.sigcheck.cert_issuer ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer
file_type ( principal | target | src | observer ).file.file_type

פתרון בעיות בהעשרה

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

העשרה כללית

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

העשרה של פריט המידע שנוצר בתהליך הפיתוח (Artifact) (לוגיקה של התאמה ראשונה)

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

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

העשרה של נכסים (מיזוג ולוגיקה של חזרה למצב קודם)

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

העשרה של נתוני המשתמש (העדפה של סדר)

אם בשדה Department מופיע "IT" כשבלוגים המקומיים מופיע "Security", המשמעות היא ששיפור הנתונים של המשתמש מעדיף שדות מנותחים על פני שדות עם כינוי. אם הלוג הגולמי נותח באמצעות "IT", צינור העיבוד של שיפור הנתונים לא יחליף אותו בערך "Security" ממקור הזהויות (לדוגמה, Okta או AD).

העשרת תהליך (מיפוי והחלפה)

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

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

במאמרים הבאים מוסבר איך להשתמש בנתונים מועשרים עם תכונות אחרות של Google SecOps:

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