סקירה כללית על הטמעת נתונים

נתמך ב:

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

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

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

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

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

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

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

סקירה כללית של שיטות להטמעת נתונים

שירות ההטמעה של Google SecOps פועל כשער לכל הנתונים.

מערכת Google SecOps קולטת נתונים באמצעות המערכות הבאות:

  • ‫Google Cloud: Google SecOps מאחזר נתונים ישירות מהארגון Google Cloud שלכם. זו השיטה העיקרית לכל היומנים הרגילים Google Cloud (לדוגמה, יומני ביקורת, יומני זרימת VPC, יומני DNS ויומני חומת אש). זו הדרך הכי חסכונית ויעילה להעברת טלמטריה אל Google SecOps. Google Cloud מידע נוסף זמין במאמר בנושא הוספת נתונים ל-Google SecOps Google Cloud .

  • סוכן Bindplane: זהו סוכן מנוהל לאיסוף יומנים מסביבות ומשרתים מקומיים (Windows או Linux). ‫Bindplane הוא צינור טלמטריה שיכול לאסוף, לחדד ולייצא יומנים מכל מקור ל-Google SecOps, ולכן הוא מספק גמישות באיסוף סוגים שונים של יומנים שלא פועלים עם שיטות אחרות. אפשר להשתמש בו לנתונים מקומיים, כמו יומני חומת אש, יומני Windows ו-Linux, או לנתוני ענן שרוצים לעבד מראש (לדוגמה, לחדד או לסנן) לפני שמטמיעים אותם ב-Google SecOps. אפשר גם לנהל את הסוכן הזה באמצעות מסוף הניהול של Bindplane OP. מידע נוסף זמין במאמר בנושא שימוש בסוכן Bindplane.

  • פידים של נתונים: פידים של נתונים משמשים בעיקר ליומנים מבוססי-ענן שבהם היומנים של הצד השלישי כבר מצורפים למאגר אובייקטים, כמו Cloud Storage או Amazon S3, או כשהצד השלישי תומך בשיטות מבוססות-push, כמו webhook. פידים של נתונים מספקים גם תמיכה מוכנה לשימוש בקבוצה מוגדרת מראש של שילובים מבוססי-API. אפשר להשתמש בפידים של נתונים ליומנים מבוססי-ענן כמו EDR או כל אפליקציית SaaS, ולשילובים ספציפיים שהוגדרו מראש כAPI ישיר. פידים של נתונים שולחים יומנים ישירות לשירות ההטמעה של Google SecOps. מידע נוסף מופיע במאמרי העזרה בנושא ניהול פידים. פידים של נתונים תומכים בשורות יומן בגודל של עד 4MB. אפשר לעקוב אחרי הפעילות והשגיאות בפיד באמצעות Cloud Logging. מידע נוסף זמין במאמר בנושא ניתוח פעילות בפיד באמצעות Cloud Logging.

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

  • העברת הודעות: התכונה 'העברת הודעות' הגיעה לסוף החיים שלה. ‫Google ממליצה להשתמש במקום זאת בסוכן Bindplane.

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

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

מפרטים:

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

  • קבצים גדולים (בגודל 5-10GB או יותר) עלולים לגרום לעיכוב משמעותי בהעברת הנתונים.

  • הטמעה תומכת רק בקידוד UTF-8.

הסבר על זמני ההטמעה וזמינות הנתונים

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

  • עיכובים במערכת המקור (לפני ההטמעה): למקורות נתונים רבים יש השהיות מובנות. יכול להיות שהנתונים לא יהיו זמינים לאיסוף מיד אחרי שמתרחש אירוע. היא מופיעה בדרך כלל מהסיבות הבאות:

    • לוחות זמנים לעיבוד המקור ולאצווה.
    • הזמן שנדרש לכתיבת אירועים בקובצי יומן או בנקודות קצה של API.
    • מגבלות קצב של ממשקי API.
    • ההבדל בין חותמת הזמן של האירוע לבין הזמן שבו היומן זמין להעברה (לדוגמה, createTime).

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

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

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

רשימה של סוגי יומנים עם עיכובים ידועים בצד המקור מופיעה בהפניה ל-API של ניהול פידים.

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