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

נתמך ב:

Google secops

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

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

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

הטמעת נתונים

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

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

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

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

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

  ‫Google SecOps משתמש בהזנה Google Cloud ישירה כדי לשלוף באופן אוטומטי יומנים ונתוני טלמטריה מ Google Cloudשל הארגון, כולל Cloud Logging, מטא-נתונים של Cloud Asset Inventory וממצאים של 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 (יצירת כינויים ל-ECG), שמאחדת הקשרים ממקורות שונים (כמו ספקי זהויות, CMDB ומודיעין איומים), כדי ליצור פרופיל ישות מאוחד ב-entity context graph (גרף הקשר של הישות).

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

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

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

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