הסבר על זמינות הנתונים לחיפוש

נתמך ב:

Google SecOps

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

קליטה ועיבוד של נתונים ב-Google SecOps

בקטע הזה מוסבר איך Google SecOps קולטת נתוני אבטחה, מעבדת אותם ומנתחת אותם.

הטמעת נתונים

תהליך הטמעת הנתונים מתחיל באיסוף נתוני האבטחה הגולמיים ממקורות כמו:

• יומני אבטחה מהמערכות הפנימיות
• נתונים שמאוחסנים ב-Cloud Storage
• מרכז האבטחה (SOC) ומערכות פנימיות אחרות

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

אלה הן שיטות ההטמעה העיקריות:

• הטמעה Google Cloud ישירה

  ‫Google SecOps משתמש בהטמעה Google Cloud ישירה כדי לשלוף באופן אוטומטי יומנים ונתוני טלמטריה מ Google Cloudשל הארגון, כולל Cloud Logging, מטא-נתונים של מאגר משאבי ענן וממצאים של Security Command Center Premium.

• Ingestion APIs

  שליחת נתונים ישירות אל Google SecOps באמצעות ממשקי ה-API להעברת נתונים הציבוריים שלו בארכיטקטורת REST. אתם יכולים להשתמש בשיטה הזו לשילובים בהתאמה אישית או כדי לשלוח נתונים כיומנים לא מובנים או כאירועים בפורמט מוגדר מראש של מודל נתונים מאוחד (UDM).

• Bindplane agent

  אתם יכולים לפרוס את הסוכן הרב-תכליתי Bindplane בסביבה שלכם (במקום או בענן אחר) כדי לאסוף יומנים ממגוון רחב של מקורות ולהעביר אותם אל Google SecOps.

• פידים של נתונים

  ב-Google SecOps, מגדירים פידים של נתונים כדי לשלוף יומנים ממקורות של צד שלישי, כמו באקטים ספציפיים של אחסון בענן של צד שלישי (למשל Amazon S3) או ממשקי API של צד שלישי (למשל Okta או Microsoft 365).

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

אחרי שהנתונים מגיעים ל-Google SecOps, הפלטפורמה מעבדת אותם בשלבים הבאים:

1. ניתוח ונרמול

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

2. הוספה לאינדקס

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

3. כינויים והעשרה של UDM

   • ‫Google SecOps מבצע כינוי והעשרה של UDM כדי להעשיר אירועי UDM בהקשר חשוב. הוא מזהה ומוסיף נתוני הקשר ואינדיקטורים לישויות ביומן. לדוגמה, הוא מקשר את login name של משתמש לIP addresses, ל-hostnames ול-MAC addresses השונים שלו.
   • מיקום גיאוגרפי: מערכת Google SecOps מעשירה כתובות IP בנתוני מיקום גיאוגרפי.

4. העשרה של נתוני ECG

   • ‫Google SecOps מבצעת ECG aliasing, שמאחדת הקשר ממקורות שונים (כמו ספקי זהויות, CMDB ומודיעין איומי סייבר), כדי ליצור פרופיל ישות מאוחד בתרשים הקשר של הישות.

   • מודיעין איומי סייבר:‏ Google SecOps משווה באופן אוטומטי נתוני אירועים למודיעין איומי הסייבר הנרחב של Google, כולל מקורות כמו Google Threat Intelligence וגלישה בטוחה, כדי לזהות איומים זדוניים מוכרים, כמו domains,‏ IP addresses ו-file hashes.

   • ‫WHOIS:‏ Google SecOps מעשיר את שמות הדומיינים במידע הרישום הציבורי שלהם ב-WHOIS.

זמינות הנתונים לניתוח

אחרי העיבוד וההעשרה, הנתונים ב-UDM זמינים מיד לניתוח:

• זיהוי בזמן אמת

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

• חיפוש וחקירה

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

שיטות חיפוש

ב-Google SecOps יש כמה שיטות שונות לחיפוש הנתונים, ולכל אחת מהן יש מטרה אחרת.

חיפוש UDM

חיפוש UDM הוא שיטת החיפוש העיקרית והמהירה ביותר, והיא משמשת לרוב החקירות.

• מה הוא מחפש: הוא שולח שאילתות לאירועי UDM מנורמלים ומאונדקסים. מכיוון שכל הנתונים מנותחים בפורמט הסטנדרטי הזה, אפשר לכתוב שאילתה אחת כדי למצוא את אותה פעילות (למשל, התחברות) בכל המוצרים השונים (לדוגמה, Windows,‏ Okta,‏ Linux).
• איך זה עובד: אתם משתמשים בתחביר ספציפי כדי לשלוח שאילתות לשדות, לאופרטורים ולערכים.

• דוגמה: principal.hostname = "win-server" AND target.ip = "10.1.2.3"

  בדרך כלל התוצאות זמינות תוך 2 עד 15 דקות מהרגע שהן נקלטו.

חיפוש ביומן הגולמי

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

• מה הוא מחפש: הוא סורק את הטקסט המקורי והלא מעובד של היומנים לפני שהוא עבר ניתוח ונורמליזציה. האפשרות הזו שימושית לחיפוש מחרוזות ספציפיות, ארגומנטים של שורת פקודה או פריטים אחרים שלא מופיעים בשדות של UDM באינדקס.
• איך זה עובד: משתמשים בקידומת raw =. החיפוש יכול להיות איטי יותר מחיפוש ב-UDM כי הוא לא מחפש שדות מאונדקסים.
• דוגמה (מחרוזת): raw = "PsExec.exe"
• דוגמה (ביטוי רגולרי): raw = /admin\$/

חיפוש נתונים סטטיסטיים

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

חיפוש בשפה טבעית (Gemini)

חיפוש בשפה טבעית (Gemini) מאפשר לכם לשאול שאלות באנגלית פשוטה, ו-Gemini מתרגם אותן לשאילתת UDM רשמית.

• מה הוא מחפש: הוא מספק ממשק שיחה ליצירת שאילתות על נתוני UDM.
• איך זה עובד: אתם מקלידים שאלה, ו-Gemini יוצר בשבילכם את שאילתת החיפוש הבסיסית של UDM, שאותה תוכלו להריץ או לשפר.
• דוגמה: "Show me all failed logins from user 'bob' in the last 24 hours" (הצגת כל ניסיונות הכניסה שנכשלו של המשתמש bob ב-24 השעות האחרונות)

חיפוש SOAR

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

• מה הוא מחפש: הוא מחפש תיקים וישויות (כמו משתמשים, נכסים, כתובות IP) בפלטפורמת SOAR.
• איך זה עובד: אתם יכולים להשתמש במסננים של טקסט חופשי או של שדות כדי למצוא בקשות לפי המזהה, שם ההתראה, הסטטוס והמשתמש שהוקצו להן.
• דוגמה: חיפוש של CaseIds:180 או AlertName:Brute Force

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

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

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

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

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

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

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

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

העיכובים האלה משתנים בהתאם למקור הנתונים ולסוג היומן. פרטים נוספים על שיטות ההטמעה מופיעים במאמר סקירה כללית על הטמעת נתונים. במסמכי העזר של Feed management API מפורטים שיקולים ספציפיים לסוגי יומנים כמו Microsoft Graph,‏ SentinelOne,‏ Okta ו-CrowdStrike.

זמן העיבוד ב-Google SecOps

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

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

שיטת החיפוש	הנתונים שנכללים בחיפוש	שלבי העיבוד שמשפיעים על זמן הזמינות
חיפוש ב-UDM חיפוש בשפה טבעית (Gemini)	אירועים ב-UDM שעברו נרמול והעשרה	קליטה: היומן מגיע לנקודת הקליטה של Google SecOps. ניתוח: היומן הגולמי מזוהה ומעובד על ידי מנתח ספציפי. נרמול: הנתונים מחולצים וממופים לסכימת UDM. יצירת אינדקס (UDM): רשומת ה-UDM המנורמלת נכללת באינדקס כדי לאפשר חיפוש מהיר ומובנה. העשרה: נוסף הקשר (מודיעין איומי סייבר, מיקום גיאוגרפי, נתוני משתמש או נכס).
חיפוש ביומן גולמי	טקסט יומן מקורי שלא עבר ניתוח	קליטה: היומן מגיע לנקודת הקליטה של Google SecOps.
מנוע הזיהוי (כללים)	אירועים שעברו נורמליזציה	זמינות של אירועים ב-UDM: אותם שלבים שמופיעים בחיפוש ב-UDM. הערכת זיהוי: מנוע הכללים מעריך יומנים ב'מיקרו-מנות', ובדרך כלל מפעיל זיהויים תוך 5 עד 10 דקות מרגע הגעת האירוע.
חיפוש ב-SOAR	כיסויים וישויות	זהו מחזור חיים שונה, כי הוא מחפש התראות ואירועים, ולא יומנים. השעה מבוססת על: זמינות אירועים ב-UDM: נעשה שימוש באותם שלבי עיבוד שמפורטים בקטע 'חיפוש ב-UDM'. ‫Detection: כלל של מנוע זיהוי חייב להתאים לאירועים ב-UDM. יצירת התראה: המערכת יוצרת התראה רשמית מהזיהוי. יצירת בקשת תמיכה: פלטפורמת SOAR קולטת את ההתראה ויוצרת בקשת תמיכה.

דוגמה לזרימת נתונים

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

דוגמה לשלבים של עיבוד נתונים

1. שולף נתוני אבטחה משירותי ענן כמו Amazon S3 או מ-Google Cloud. הנתונים האלה מוצפנים בזמן ההעברה ב-Google SecOps.
2. מפריד את נתוני האבטחה המוצפנים ומאחסן אותם בחשבון שלכם. הגישה מוגבלת לכם ולמספר קטן של עובדי Google לצורך תמיכה, פיתוח ותחזוקה של המוצר.
3. מנתח ומאמת נתוני אבטחה גולמיים, וכך מקל על העיבוד והצפייה בהם.
4. מנרמל ומאנדקס את הנתונים כדי לאפשר חיפושים מהירים.
5. הנתונים המנותחים והממוינדקסים מאוחסנים בחשבון שלכם.
6. העשרה בנתוני הקשר.
7. מאפשרת למשתמשים גישה מאובטחת לחיפוש ולבדיקה של נתוני האבטחה שלהם.
8. משווה את נתוני האבטחה שלכם למאגר המידע של Google Threat Intelligence על תוכנות זדוניות כדי לזהות התאמות. בתצוגת אירועים ב-Google SecOps, כמו תצוגת הנכסים, לוחצים על הקשר של VT כדי לראות מידע מ-Google Threat Intelligence. ‫Google SecOps לא משתף את נתוני האבטחה שלכם עם Google Threat Intelligence.

דוגמאות לזמן הצפוי עד שהחיפוש יהיה זמין

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

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

שלב בזרימת הנתונים	תיאור	משך הזרימה
‫Cloud Storage אל Raw logs	קליטת יומנים גולמיים מ-Cloud Storage.	פחות מ-30 שניות
יומני אבטחה אל השירות להעברת נתונים	הפלטפורמה מקבלת יומני אבטחה ממערכות פנימיות.	לא רלוונטי
השירות להעברת נתונים אל יומנים גולמיים	שולח נתוני אבטחה גולמיים שהתקבלו ממקורות שונים לצינור ההטמעה.	פחות מ-30 שניות
יומנים גולמיים אל ניתוח ואימות	מנתח ומאמת יומנים גולמיים לפורמט UDM.	פחות מ-3 דקות
ניתוח ואימות עד הוספה לאינדקס	מבצע אינדוקס של נתוני ה-UDM שנותחו כדי לאפשר חיפוש מהיר.	לא רלוונטי
אינדקס לנתוני לקוחות מפוענחים	הופך את הנתונים שעברו אינדוקס לזמינים כנתוני לקוחות מפוענחים לצורך ניתוח.	פחות מ-2 דקות

פתרון בעיות

בקטע הזה מפורטות הנחיות לפתרון בעיות.

זמן אחזור ומגבלות

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

• נראות בחיפוש: 2 עד 15 דקות אחרי ההטמעה.
• ביצוע הכלל: 5 עד 10 דקות אחרי שהאירוע מגיע.

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

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

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

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