שיטות מומלצות לחיפוש

נתמך ב:

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

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

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

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

שדות של חשבונות משתמשים

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sid

שדות מקור

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

שדות יעד

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

שדות נוספים

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

איך מריצים שאילתות על נתוני ישויות והקשר

אם מחפשים סוגים של יומנים של ישויות או הקשרים (כמו AZURE_AD_CONTEXT או WORKSPACE_USERS) באמצעות metadata.log_type = "<LOG_TYPE>", החיפוש לא יחזיר תוצאות גם אם יומנים גולמיים גלויים בחיפוש יומנים גולמיים. הסיבה לכך היא שחיפוש ב-UDM מחפש רק רשומות של אירועים ב-UDM.

כדי לחפש נתוני ישויות ונתונים מבוססי הקשר, משתמשים בתחביר graph:

  • כדי לחפש סוג יומן של ישות או הקשר, שולחים שאילתה לשדות המטא-נתונים graph. לדוגמה:

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • כדי לחפש שדות של ישויות, משתמשים בקידומת graph.entity.noun.field. לדוגמה:

    graph.entity.user.email_addresses = "foo_email"

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

איך ליצור שאילתות חיפוש יעילות לשיפור הביצועים

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

udm-field operator value

לדוגמה: principal.hostname = "win-server"

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

שימוש בביטויים רגולריים בשאילתת חיפוש

אתם יכולים להשתמש באופרטורים לוגיים ולהשוואה רגילים כשאתם יוצרים שאילתות חיפוש ב-UDM כדי ליצור ביטויים מורכבים:

  • אופרטורים לוגיים: משתמשים באופרטורים AND, OR ו-NOT כדי לשלב תנאים. ‫AND אם משמיטים אופרטור בין שני תנאים.
  • עדיפות האופרטורים: כדי לשנות את סדר העדיפות שמוגדר כברירת מחדל, משתמשים בסוגריים (‎). יש מגבלה מקסימלית של 169 אופרטורים לוגיים (OR, ‏ AND, ‏ NOT) שאפשר להשתמש בהם בתוך סוגריים.
  • אופרטורים להשוואה: בהתאם לסוג השדה ב-UDM (מחרוזת, מספר שלם, חותמת זמן), אופרטורים של שדות יכולים לכלול: =, !=, >=, >, <, <=

ב-Google SecOps נעשה שימוש במנוע הביטויים הרגולריים RE2.

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

שימוש ב-nocase כמקש צירוף לחיפוש

אפשר לצרף את משנה התנאי nocase לתנאי השוואה של מחרוזת כדי שהחיפוש לא יהיה תלוי באותיות רישיות.

לדוגמה, החיפוש הבא מתעלם מהרישיות ומתאים לכל השילובים שמכילים את tim.smith, ללא קשר לרישיות:

target.user.userid = "TIM.SMITH" nocase

הימנעו משימוש בביטויים רגולריים בשדות ממוספרים

אי אפשר להשתמש בביטויים רגולריים כשמחפשים שדות ממוספרים (שדות עם טווח של ערכים מוגדרים מראש) כמו metadata.event_type או network.ip_protocol

הדוגמה הבאה היא חיפוש לא תקין: metadata.event_type = /NETWORK_*/

לעומת זאת, הדוגמה הבאה היא חיפוש תקין: (metadata.event_type = "NETWORK_CONNECTION" או metadata.event_type = "NETWORK_DHCP")

שימוש בכל האופרטורים בשדה Events

ב-Search, חלק מהשדות של UDM (כמו principal.ip או target.file.md5) מסומנים כrepeated, כי הם יכולים להכיל רשימה של ערכים או סוגי הודעות באירוע יחיד. שדות חוזרים תמיד מטופלים באמצעות האופרטור any כברירת מחדל (אין אפשרות לציין all).

כשמשתמשים באופרטור any, ערך החיזוי הוא true אם יש ערך בשדה החוזר שמקיים את התנאי. לדוגמה, אם מחפשים את principal.ip != "1.2.3.4" והאירועים בחיפוש כוללים גם את principal.ip = "1.2.3.4" וגם את principal.ip = "5.6.7.8", נוצרת התאמה. החיפוש יורחב כך שיכלול תוצאות שתואמות לאחד מהאופרטורים במקום לכולם.

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

כשמשתמשים באופרטור any, הניבוי מוערך כ-true אם ערך כלשהו בשדה החוזר עומד בתנאי.

שימוש בזמן ראשית יוניקס (Unix epoch) לחותמות זמן או שימוש בפונקציות YARA-L להמרת תאריכים

התאמה של שדות חותמת זמן מתבצעת באמצעות זמן יוניקס (מספר השניות הכולל שעברו מאז יום חמישי, 1 בינואר 1970, בשעה 00:00:00 UTC), או שאתם יכולים להשתמש בפונקציות YARA-L להמרת תאריכים.

כשמחפשים חותמת זמן ספציפית, אפשר להשתמש בפורמט הבא (בזמן אפוק):

metadata.ingested_timestamp.seconds = 1660784400

חותמת הזמן הבאה לא תקינה:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

כשמחפשים חותמת זמן ספציפית, הביטוי הבא (שמשתמש בפונקציית YARA-L להמרת תאריך) הוא תקין:

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

בדוגמה הבאה של YARA-L נעשה שימוש בפונקציות timestamp כדי לבדוק טווחי זמן של הטמעה:

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

איך מבצעים שאילתה על נתונים חדשים עם חותמות זמן ישנות יותר

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

כדי לחפש אירועים ב-UDM ביומנים שהועברו עם חותמות זמן ישנות יותר, אפשר להשתמש באפשרות כל הזמן כדי לחפש ולשאול שאילתות על metadata.ingested_timestamp.

שדות שמוחרגים מהמסננים

השדות הבאים מוחרגים בכוונה ממסנני החיפוש:

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

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

פתרון בעיות

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

  • מתחברים ל-Google SecOps מרשת אחרת. לדוגמה, אפשר להשתמש במכונה וירטואלית בענן כדי לזהות בעיות ברשת.
  • מוודאים שההגדרות או המדיניות של חומת האש או שרת ה-Proxy של הארגון מאפשרות קריאות ל-Chronicle API.
  • מוודאים שלא הוגבלה כמות הנתונים לשימוש ב-Search API, כי החיפושים יכולים להחזיר מערכי נתונים גדולים.
  • אפשר להריץ שאילתות חיפוש באופן אסינכרוני, ויכול להיות שיידרש יותר זמן כדי לקבל את הנתונים. אפשר לראות חיפושים קודמים בהיסטוריית החיפושים ולבחור אותם כדי לראות את התוצאות מאוחר יותר.

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