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

נתמך ב:

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 עם Live Rule על נתונים נכנסים בזמן אמת כדי לזהות איומים וליצור התראות.

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

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

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

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

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

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

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