Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שימוש בתרשים הקשר של הישות (ECG)

נתמך ב:

Google secops SIEM

במסמך הזה מופיע סקירה כללית של Entity Context Graph (ECG), כולל מקורות הנתונים, צינור העיבוד והיישומים שלו בכללים ובחיפוש. ה-ECG הוא מודל נתונים של ישויות ליבה שמספק הקשר חיוני לזיהוי מתקדם של איומים, לחקירה ולציד איומים בכללי זיהוי, בחיפוש ובלוחות בקרה. צינור העיבוד של ה-ECG (מיזוג) הוא מידע הקשרי מכל סביבת Google SecOps.

בנוסף, ה-ECG מחשב מדדי סיכום לישויות. הם כוללים את השכיחות (התדירות שבה ישות ספציפית מופיעה בנתוני ה-UDM בהשוואה לישויות אחרות), ואת first-seen-time ו-last-seen-time של ישות. הוא גם מזהה מקורות חשובים להעשרת הנתונים ומקורות של אינדיקטורים לפריצה (IOC), כמו נתונים מ-Google Threat Intelligence‏ (GTI), גלישה בטוחה, WHOIS ו-VirusTotal.

אפליקציית אק"ג משתמשת באירועי UDM כדי:

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

מקורות הנתונים של בדיקת האק"ג

צינור הנתונים של האק"ג משלב נתונים מהמקורות הבאים:

מקור ההקשר	מקור	תיאור
הקשר של הישות	מקורות מידע שהלקוח סיפק	‫Google SecOps קולטת ישירות נתונים ארגוניים מובנים, כמו פרטים מהימנים על משתמשים ונכסים, ממערכות חיצוניות. המקורות האלה כוללים ספקי זהויות (IDP), מערכות של מסד נתונים לניהול הגדרות (CMDB) (כמו ServiceNow CMDB,‏ Duo User Context) ומערכות לניהול נקודות חולשה.
הקשר נגזר	נוצר על ידי Google SecOps	‫Google SecOps יוצר נתונים סטטיסטיים על סמך ניתוח של פעילות שהמערכת קולטת. הוא מעשיר אירועים וישויות ממקורות שונים בסביבה שלכם (לדוגמה, Windows AD, ‏ Azure AD, ‏ Okta,‏ Google Cloud, IAM). לדוגמה: מחשב ומעשיר כל ישות בנתון שכיחות שמציין את הפופולריות שלה בסביבה. מחשבת ומעשירה את השדות entity first-seen-time ו-entity last-seen-time.
הקשר גלובלי	מקורות של Google	מקורות גלובליים מספקים מודיעין פנימי וחיצוני לגבי איומים ונתוני מוניטין. לדוגמה: קליטה ואחסון של נתוני Google Threat Intelligence. מעשיר ישויות במידע מרשימות האיומים של הגלישה הבטוחה. מעשיר את הישויות בנתוני WHOIS.

צינור לעיבוד נתונים של אק"ג

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

הוספת קשרים, נכסים ויחסים חדשים ל-ECG.
יצירה ועדכון של הקשר נגזר.

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

כינויים ב-UDM ומיזוג של ECG

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

ישויות מתוזמנות וישויות על-זמניות

ה-ECG יוצר ישויות מתוזמנות (זמניות) ולא מתוזמנות (לא זמניות). הערכה של ישויות עם חותמת זמן מתבצעת בטווחים של זמן החיפוש ושל הכלל שצוינו. הערכה של ישויות נצחיות מתבצעת בלי להתחשב בטווח הזמן של החיפוש או הכלל.

מקשי מיזוג של אק"ג

ה-ECG ממזג רשומות של הקשר על ידי התאמה של מזהי מפתח משותפים במקורות נתונים שונים. דוגמאות למזהים האלה כוללות את hostname,‏ MAC address,‏ user ID או email address. ה-ECG ממזג רשומות שתואמות לאחד מהערכים האלה כדי ליצור תצוגה מקיפה ומועשרת של ישות.

הכינוי של ה-אק"ג משתמש בשדות ה-UDM הבאים כמפתחות מיזוג:

Asset
- entity.asset.product_object_id
- entity.asset.hostname
- entity.asset.asset_id
- entity.asset.mac
User
- entity.user.product_object_id
- entity.user.userid
- entity.user.windows_sid
- entity.user.email_addresses
- entity.user.employee_id
Resource
- entity.resource.product_object_id
- entity.resource.name
Group
- entity.group.product_object_id
- entity.group.email_addresses
- entity.group.windows_sid

מיזוג של סוגי ישויות ספציפיים (קובץ, כתובת URL, דומיין)

בנוסף ל-merge-keys, ה-ECG ממזג הקשרים של סוגי ישויות ספציפיים (קובץ, כתובת URL ודומיין) באמצעות המזהים הייחודיים הבאים:

File
- entity.file.md5
- entity.file.sha1
- entity.file.sha256
- (וגם entity.file.product_object_id אם הוא זמין)
URL
- entity.url.url
- (וגם entity.url.product_object_id אם הוא זמין)
Domain
- entity.domain.domain
- (וגם entity.domain.product_object_id אם הוא זמין)

מערכת ה-ECG ממזגת רשומה של הקשר ישות עבור File, URL או Domain עם רשומה אחרת רק אם כל המזהים הייחודיים שמופיעים בשתי הרשומות זהים.

לדוגמה, אם ה-ECG שוקל שני הקשרים של ישות File למיזוג:

אם לשניהם יש גיבוב md5, הם צריכים להיות זהים כדי שאפשר יהיה לבצע את בדיקת האק"ג.
אם באחת יש md5 ובשנייה יש sha256, האק"ג לא תמזג אותן על סמך הגיבוב.
אם מצוין product_object_id, האק"ג צריך להיות זהה גם לו אם הוא מופיע בשני הרשומות שמושווות, בנוסף למזהים שמבוססים על תוכן (כמו md5,‏ url או domain).

כלומר, בשדות מהסוגים האלה, שדות כמו entity.file.md5, entity.url.url ו-entity.domain.domain חייבים להיות נוכחים ולהתאים לתהליך המיזוג, בנוסף לכל product_object_id שסופק.

יישוב סכסוכים

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

ביטול כפילויות ומרווחי זמן

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

לדוגמה, נניח שיש שתי ישויות e1 ו-e2 עם חותמות זמן t1 ו-t2, בהתאמה. אם e1 ו-e2 זהים בכל שאר המובנים, האק"ג מבטל את הכפילות שלהם על ידי התעלמות מההבדלים בחותמות הזמן בשדות הבאים:

collected_timestamp
creation_timestamp
interval

חלון מבט לאחור

ה-ECG יוצר נתונים בהקשר של ישות עם חלון מבט לאחור של חמישה ימים. התהליך הזה עוזר לטפל בנתונים שמגיעים באיחור וקובע אורך חיים (TTL) משתמע לנתוני הקשר של הישות.

ה-ECG מבחין בין נתונים הקשריים (assets, users, resources, groups) לבין אינדיקטורים לפריצה (IOC).

דוגמה: מיזוג נתוני משתמשים עם מיזוג של נתוני אק"ג

לדוגמה, Google SecOps קולטת נתוני משתמשים של jdoe משלושה מקורות: Okta,‏ Azure AD וסורק נקודות חולשה. ה-ECG ממזג את שלושת הרשומות האלה על סמך מזהים תואמים (כמו jdoe@example.com). כך נוצרת ישות משתמש מאוחדת של jdoe ב-ECG, שמכילה מאפיינים מכל שלושת המקורות.

מקורות נתונים של ECG עם הקשר של ישויות ואירועים קריטיים

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

מקורות נתונים קריטיים של ECG בהקשר של ישות

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

קטגוריה	מקורות נתונים קריטיים	ישויות שאוכלסו
ניהול זהויות והרשאות גישה	Active Directory, ‏ Azure AD, ‏ Okta,‏ Google Cloud Identity	`user`, `group`
מאגר נכסים	CMDBs, ‏ JAMF, ‏ Microsoft Intune	`asset`
Threat intelligence	פידים בהתאמה אישית או של צד שלישי, מודיעין איומים של Google‏ (GTI)	‫`ip_address`,‏ `domain_name`,‏ `file`

חיפוש לדוגמה

כדי לראות רשימה של מנתחי נתונים שתומכים בכל קטגוריה:

סוגי יומנים נתמכים עם מנתח ברירת מחדל
מקלידים קטגוריה בסרגל החיפוש, למשל:
- כדי לראות מנתחי נתונים שרלוונטיים למלאי הנכסים, מקלידים inventory או asset.
- כדי לראות מנתחי נתונים שרלוונטיים לניהול זהויות והרשאות גישה, מקלידים identity.
- כדי לראות מנתחי נתונים שרלוונטיים למודיעין איומים, מקלידים IOC.

מקורות נתונים ושדות קריטיים של UDM ליצירת פרופיל של ישות

‫Google SecOps משפר את פרופילי הישויות על סמך מקורות נתונים מהימנים של הקשר הישות ושדות קריטיים של UDM:

סוג ישות	מקורות נתונים	שדות קריטיים ב-UDM (לכינוי ולהוספה לאינדקס)
Process	יומני נקודות הקצה מספקים את ה-PSPI ‏ (principal.process.product_specific_process_id), מזהה יציב שחשוב מאוד ליצירת כינויים חזקים לתהליכים. לדוגמה: CrowdStrike EDR‏ (CS_EDR) ו-Windows Sysmon‏ (WINDOWS_SYSMON).	`source.process.product_specific_process_id`
משתמש	המקורות האלה מספקים מאפיינים של משתמשים ופרטי זהות. לדוגמה, נתוני הקשר של ישות Duo‏ (DUO_CONTEXT) ו-Okta‏ (OKTA).	`source.user.userid`, `source.user.email_address`, `source.user.windows_sid`, `source.user.product_object_id`
נכס או נקודת קצה	המקורות האלה מספקים מידע מהימן על נכסים. לדוגמה, ServiceNow CMDB‏ (SERVICENOW_CMDB) ו-Tanium Asset‏ (TANIUM_ASSET).	`source.ip`, `source.hostname`, `source.asset_id`, `principal.asset.hostname`
גיבוב קבצים	הפונקציה מספקת 'טביעת אצבע דיגיטלית' ייחודית של תוכן הנתונים כדי לאמת את תקינות הנתונים.	‫`source.file.sha256`, ‏ `source.file.sha1`, ‏ `source.file.md5`

שדות UDM של נתוני הקשר של אירועים קריטיים

מערכת Google SecOps דורשת כמה שדות UDM של נתוני הקשר של אירועים קריטיים.

השדות הקריטיים ביותר ב-UDM משמשים כמזהים יציבים וכאינדיקטורים של קשרים (השדות principal.*,‏ target.*,‏ src_* ו-dst_*).
כאן מפורטת רשימת השדות העיקריים של UDM ששייכים לאזור התכונה Entity graph.

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

סוג הישות	מקורות נתונים קריטיים	שדות UDM קריטיים ליצירת ישויות
נכס (מארח)	EDR ו-XDR, ‏ DNS ו-DHCP, חומת אש, Google Cloud יומני ביקורת של המסוף	`metadata.event_type`, `principal.asset.asset_id`, `principal.asset.hostname`, `principal.ip`
משתמש	יומנים של ספק הזהויות (IdP), פיד של נתוני משאבי אנוש (הקשר), יומנים של Cloud Identity, שער דואר אלקטרוני	`principal.user.userid`, `principal.user.email_addresses`, `target.user.userid`, `principal.ip`
רשת	חומת אש, VPN, ‏ DNS, ‏ VPC Flow Logs	`principal.ip`, `target.ip`, `src_ip`, `dst_ip`, `network.direction`
קובץ ותהליך	EDR ו-XDR, יומני אפליקציות	`target.file.full_path`, `target.process.file.full_path`, `target.process.command_line`

דוגמה

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

לדוגמה, אפשר לצרף נתוני הקשר של משתמש לכלל מעקב מסוג "כוח ברוטלי" כדי לקבל התראה רק אם המשתמש המעורב הוא גם חלק מהקבוצה Domain Admins (אדמינים בדומיין) והנכס המעורב הוא בקר דומיין:

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

העשרות של הקשרים שמקורם בנתונים

‫Google SecOps יוצר נתוני הסקה דינמיים מבוססי-אירועים לכל ישות בכל מרחבי השמות מנתוני האירועים של הארגון. הוא משתמש במידע על כינויים, בנתונים מתהליכי העשרה פנימיים ובנתוני אירועי אבטחה כדי ליצור קשרים (לדוגמה, asset שמשויך ל-IP address).

התהליך הזה מוסיף הקשר חשוב לשיפור פרופילי הישויות. לדוגמה, אפשר להוסיף:

‫entity.file.sha256 עד file (hash) ישויות
(principal or target).ip_geo_artifact.location.country_or_region עד network (geolocation) ישויות

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

נתונים סטטיסטיים על שכיחות

צינור הנתונים של האפליקציה מנתח נתונים קיימים ונכנסים כדי לחשב ולאחסן מדדי שכיחות כשדה הקשר נגזר. המדדים האלה מייצגים ערך מספרי של 'פופולריות' לישויות כמו domain,‏ file hash או IP address בסביבה שלכם. כך תוכלו לזהות פעילות נדירה או חריגה, כי בדרך כלל יש פחות סיכון בישויות פופולריות יותר.

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

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

סוג ישות	שדות UDM
דומיין	`entity.domain.prevalence.day_count` `entity.domain.prevalence.day_max` `entity.domain.prevalence.day_max_sub_domains` `entity.domain.prevalence.rolling_max` `entity.domain.prevalence.rolling_max_sub_domains`
קובץ (גיבוב)	`entity.file.prevalence.day_count` `entity.file.prevalence.day_max` `entity.file.prevalence.rolling_max`
כתובת IP	`entity.artifact.prevalence.day_count` `entity.artifact.prevalence.day_max` `entity.artifact.prevalence.rolling_max`

מערכת Google SecOps מחשבת את הערכים day_max ו-rolling_max באופן שונה, כפי שמתואר בהמשך:

day_max מייצג את ציון השכיחות המקסימלי של הארטיפקט במהלך היום (היום מוגדר מ-00:00:00 עד 23:59:59 UTC).
‫rolling_max מייצג את ציון השכיחות המקסימלי ליום (כלומר, day_max) של הארטיפקט במהלך חלון 10 הימים הקודם.
הפונקציה day_count משמשת לחישוב rolling_max, והערך שלה הוא תמיד 10.

כשמחשבים את הערכים האלה עבור domain, ההבדל בין day_max ל-day_max_sub_domains (ובין rolling_max ל-rolling_max_sub_domains) הוא כדלקמן:

‫rolling_max ו-day_max מייצגים את מספר כתובות ה-IP הפנימיות הייחודיות ביום שניגשות לדומיין נתון (לא כולל תת-דומיינים).
‫rolling_max_sub_domains ו-day_max_sub_domains מייצגים את מספר כתובות ה-IP הפנימיות הייחודיות שניגשות לדומיין מסוים (כולל תת-דומיינים).

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

דוגמה

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

לדוגמה, אתם יכולים להשתמש בנתוני prevalence באק"ג כדי לזהות חיבורים לדומיינים 'נדירים' ביומני האבטחה:

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

השעה שבה ישויות נראו בפעם הראשונה והשעה שבה הן נראו בפעם האחרונה

‫Google SecOps מנתחת נתונים נכנסים כדי להעשיר רשומות של הקשר של ישויות בשדות הקריטיים הבאים:

‫first-seen-time: התאריך והשעה שבהם הישות נצפתה לראשונה בסביבה שלכם.
‫last-seen-time: התאריך והשעה של התצפית האחרונה.

השדות הנגזרים האלה מאפשרים לכם ליצור קורלציה בין פעילויות בישויות domain,‏ file hash,‏ asset,‏ user או IP address.

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

סוג ישות	שדות UDM
דומיין	`entity.domain.first_seen_time` `entity.domain.last_seen_time`
קובץ (גיבוב)	`entity.file.first_seen_time` `entity.file.last_seen_time`
כתובת IP	`entity.artifact.first_seen_time` `entity.artifact.last_seen_time`
נכס	`entity.asset.first_seen_time`
משתמש	`entity.user.first_seen_time`

חריגים לחישובים של זמן הצפייה הראשון וזמן הצפייה האחרון:

במקרה של ישויות asset ו-user, Google SecOps מאכלס רק את השדה first_seen_time, ולא את השדה last_seen_time.
‫Google SecOps לא מחשב את הנתונים הסטטיסטיים של כל ישות במרחבי שמות נפרדים.
‫Google SecOps לא מייצא את הנתונים הסטטיסטיים האלה אל סכימת events של Google SecOps ב-BigQuery.
‫Google SecOps לא מחשב את הערכים האלה עבור סוגים אחרים של ישויות, כמו group או resource.

העשרות של הקשר גלובלי

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

הטמעת נתונים של Google Threat Intelligence

‫Google SecOps קולטת נתונים ממקורות נתונים של Google Threat Intelligence ‏ (GTI), ומספקת מידע הקשרי לחקירת פעילות בסביבה שלכם.

שליחת שאילתות למקורות הנתונים הבאים:

GTI Tor Exit Nodes: כתובות IP שהן צמתי יציאה ידועים של Tor.
‫GTI Benign Binaries: קבצים שהם חלק מהפצת מערכת ההפעלה המקורית או שעודכנו על ידי תיקון רשמי של מערכת ההפעלה. קבצים בינאריים רשמיים של מערכת ההפעלה שנוצלו לרעה על ידי גורם עוין באמצעות פעילות שכיחה במתקפות מסוג Living-off-the-land (ניצול משאבים קיימים), לא נכללים במקור הנתונים הזה, כמו קבצים שמתמקדים בווקטורים של כניסה ראשונית.
כלי גישה מרחוק של GTI: קבצים שנעשה בהם שימוש לעיתים קרובות על ידי גורמים זדוניים. הכלים האלה הם בדרך כלל אפליקציות לגיטימיות, אבל לפעמים נעשה בהם שימוש לרעה כדי להתחבר מרחוק למערכות שנפרצו.

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

‫graph.metadata.vendor_name = Google Threat Intelligence
‫graph.metadata.product_name = GTI Feed

מקורות נתונים של Google Threat Intelligence עם תוקף מוגבל לעומת מקורות נתונים ללא תוקף מוגבל

מקורות הנתונים של Google Threat Intelligence כוללים סוגים מוגבלים בזמן או לא מוגבלים בזמן.

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

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

נתונים על כתובות IP של צמתי יציאה של Tor

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

‫Google SecOps מאחסן מידע שנקלט ממקור הנתונים הזה בשדות הבאים של UDM:

שדה UDM	תיאור
`<variable_name>.graph.metadata.vendor_name`	מאחסן את הערך `Google Threat Intelligence`.
`<variable_name>.graph.metadata.product_name`	מאחסן את הערך `GTI Feed`.
`<variable_name>.graph.metadata.threat.threat_feed_name`	מאחסן את הערך `Tor Exit Nodes`.
`<variable_name>.graph.entity.artifact.ip`	אחסון כתובת ה-IP שהוטמעה ממקור הנתונים של GTI.

חיפוש לדוגמה

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

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

‫Google SecOps קולט ומאחסן גיבובים של קבצים ממקור הנתונים GTI Benign Binaries. ‫Google SecOps מאחסן מידע שנקלט ממקור הנתונים הזה בשדות הבאים של UDM. הנתונים של קבצים בינאריים תמימים הם נצחיים.

שדה UDM	תיאור
`<variable_name>.graph.metadata.vendor_name`	מאחסן את הערך `Google Threat Intelligence`.
`<variable_name>.graph.metadata.product_name`	מאחסן את הערך `GTI Feed`.
`<variable_name>.graph.metadata.threat.threat_feed_name`	מאחסן את הערך `Benign Binaries`.
`<variable_name>.graph.entity.file.sha256`	מאחסן את ערך הגיבוב (hash) SHA256 של הקובץ.
`<variable_name>.graph.entity.file.sha1`	מאחסן את ערך הגיבוב (hash) SHA-1 של הקובץ.
`<variable_name>.graph.entity.file.md5`	מאחסן את ערך הגיבוב (hash) MD5 של הקובץ.

חיפוש לדוגמה

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

נתונים על כלים לגישה מרחוק

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

שדה UDM	תיאור
`<variable_name>.graph.metadata.vendor_name`	מאחסן את הערך `Google Threat Intelligence`.
`<variable_name>.graph.metadata.product_name`	מאחסן את הערך `GTI Feed`.
`<variable_name>.graph.metadata.threat.threat_feed_name`	מאחסן את הערך `Remote Access Tools`.
`<variable_name>.graph.entity.file.sha256`	מאחסן את ערך הגיבוב (hash) SHA256 של הקובץ.
`<variable_name>.graph.entity.file.sha1`	מאחסן את ערך הגיבוב (hash) SHA-1 של הקובץ.
`<variable_name>.graph.entity.file.md5`	מאחסן את ערך הגיבוב (hash) MD5 של הקובץ.

חיפוש לדוגמה

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

העשרת ישויות במידע מרשימות האיומים של הגלישה הבטוחה

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

‫Google SecOps שומרת את הפרטים הבאים ברשומה של הקשר של הישות.

שדה UDM	תיאור
`entity.metadata.product_entity_id`	מזהה ייחודי של הישות.
`entity.metadata.entity_type`	הערך הוא `FILE`, שמציין שהישות מתארת קובץ.
`entity.metadata.collected_timestamp`	התאריך והשעה שבהם נצפתה הישות או התרחש האירוע.
`entity.metadata.interval`	השדות האלה מכילים את שעת ההתחלה ושעת הסיום שבהן הנתונים האלה תקפים. מכיוון שהתוכן של רשימת האיומים משתנה עם הזמן, הערכים `start_time` ו-`end_time` משקפים את מרווח הזמן שבו הנתונים על הישות תקפים. לדוגמה, ערך הגיבוב של קובץ מסוים זוהה כזדוני או חשוד בין התאריכים `start_time` ל-`end_time`.
`entity.metadata.threat.category`	הערך של Google SecOps `SecurityCategory` מוגדר לאחד או יותר מהערכים הבאים: ‫`SOFTWARE_MALICIOUS`: מציין שהאיום קשור לתוכנה זדונית. ‫`SOFTWARE_PUA`: מציין שהאיום קשור לתוכנה לא רצויה.
`entity.metadata.threat.severity`	זהו `ProductSeverity` של Google SecOps. אם הערך הוא `CRITICAL`, המשמעות היא שהארטיפקט נראה זדוני. אם לא מציינים את הערך, אין מספיק נתונים כדי לציין שהארטיפקט זדוני.
`entity.metadata.product_name`	מאחסן את הערך `Google Safe Browsing`.
`entity.file.sha256`	ערך הגיבוב (hash) ‏SHA256 של הקובץ.

דוגמה לכלל

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

העשרת ישויות בנתוני WHOIS

‫Google SecOps מבצעת העשרה יומית של נתוני WHOIS, שהיא פונקציה קריטית, באמצעות נתונים שהם מוגבלים בזמן וגם לא מוגבלים בזמן.

במהלך הטמעת נתוני המכשיר, מערכת Google SecOps מעריכה את הדומיינים בהשוואה לנתוני WHOIS. כשיש התאמה בין הדומיינים, מערכת Google SecOps מאחסנת את נתוני WHOIS הרלוונטיים ברשומה של ישות הדומיין. לכל ישות עם entity.metadata.entity_type = DOMAIN_NAME, מערכת Google SecOps מעשירה את הרשומה במידע מ-WHOIS.

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

entity.domain.admin.attribute.labels
entity.domain.audit_update_time
entity.domain.billing.attribute.labels
entity.domain.billing.office_address.country_or_region
entity.domain.contact_email
entity.domain.creation_time
entity.domain.expiration_time
entity.domain.iana_registrar_id
entity.domain.name_server
entity.domain.private_registration
entity.domain.registrant.company_name
entity.domain.registrant.office_address.state
entity.domain.registrant.office_address.country_or_region
entity.domain.registrant.email_addresses
entity.domain.registrant.user_display_name
entity.domain.registrar
entity.domain.registry_data_raw_text
entity.domain.status
entity.domain.tech.attribute.labels
entity.domain.update_time
entity.domain.whois_record_raw_text
entity.domain.whois_server
entity.domain.zone

‫Google SecOps מעשיר ישויות domain (entity.metadata.entity_type = "DOMAIN_NAME") בנתונים של registrant, creation ו-expiration time מתוך רשומות WHOIS של global context.

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

חיפוש לדוגמה

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

שיטות מומלצות: זיהוי מקורות נתונים גלובליים עם הקשר מועשר

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

פרמטרי הסינון הבאים מזהים את סוג ההעשרה או המקור: entity_type,‏ product_name ו-vendor_name.

לדוגמה, כוללים את שדות הסינון הבאים בקטע events של הכלל שמצטרף לנתוני WHOIS:

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

שיטות מומלצות לשימוש באק"ג

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

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

פרטים על מגבלות כלליות בשירותי Google SecOps זמינים במאמר מגבלות שירות.

תוכן חיצוני קשור

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