סקירה כללית על מרכזי הבקרה

נתמך ב:

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

מסגרת לוחות הבקרה מבוססת על ארכיטקטורה מודולרית שבה ווידג'טים (תרשימים) בודדים מתקשרים עם מקורות נתונים ספציפיים באמצעות תחביר YARA-L 2.0. בעזרת המאפיינים של סכימת YARA-L ופונקציות צבירת הנתונים, אתם יכולים ליצור תצוגות חזותיות למעקב בזמן אמת, לניתוח איומים ולביקורת תפעולית.

למידע מעמיק על התשתית הבסיסית של מרכז הבקרה, קראו את הסקירה הכללית על מרכזי הבקרה.

לפני שמתחילים

מוודאים שמופע Google SecOps עומד בדרישות התצורה הבאות:

הרשאות IAM נדרשות

כדי לגשת למרכזי בקרה, נדרשות ההרשאות הבאות:

הרשאת IAM מטרה
chronicle.nativeDashboards.list לרשימה של כל לוחות הבקרה
chronicle.nativeDashboards.get צפייה במרכז הבקרה, הפעלת מסנן במרכז הבקרה ו הפעלת המסנן הגלובלי.
chronicle.nativeDashboards.create יצירת מרכז בקרה חדש.
chronicle.nativeDashboards.duplicate יצירת עותק של מרכז בקרה קיים.
chronicle.nativeDashboards.update להוסיף ולערוך תרשימים, להוסיף מסנן, לשנות את הגישה למרכז הבקרה וגם לנהל את מסנן הזמן הגלובלי.
chronicle.nativeDashboards.delete מחיקת מרכז בקרה

הסבר על מרכזי בקרה

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

קטלוג של מרכזי בקרה מוגדרים מראש

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

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

  • investigation
  • response_platform_info
  • case_name
  • feedback_summary
  • feedback_history
  • soar_alert
  • soar_alert_metadata

מקורות נתונים נתמכים

לוחות הבקרה כוללים את מקורות הנתונים הבאים, שלכל אחד מהם יש מגבלת זמן שאילתה משלו וקידומת YARA-L משלו:

מקור הנתונים מרווח הזמן של השאילתה קידומת YARA-L סכימה דוגמאות למרכזי בקרה
היסטוריית בקשות התמיכה 365 ימים case_history שדות (SOAR) | תבנית דוגמאות
פניות והתראות 365 ימים case Fields (SOAR) | Template דוגמאות
טבלאות נתונים אין מגבלת זמן עצמאית (היא נקבעת על ידי מקור הנתונים המצורף) % בהגדרת המשתמש דוגמאות
זיהויים 365 ימים detection שדות | תבנית דוגמאות
תרשים ישויות 365 ימים graph שדות | תבנית דוגמאות
אירועים 90 ימים no prefix שדות (UDM) | תבנית דוגמאות
מדדי הטמעה 365 ימים ingestion שדות | תבנית דוגמאות
IoCs 365 ימים ioc שדות | תבנית דוגמאות
פלייבוקים 365 ימים playbook שדות (SOAR) | תבנית דוגמאות
קבוצות כללים 365 ימים ruleset שדות | תבנית דוגמאות
כללים ללא מגבלת זמן rules שדות | תבנית דוגמאות
סוכן למיון ולחקירה 365 ימים gemini_investigation, gemini_investigation_feedback שדות | תבנית דוגמאות

ההשפעה של בקרת גישה מבוססת-תפקיד (RBAC) על הנתונים

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

אירועים, גרף ישויות והתאמות ל-IOC

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

כללים

המשתמשים יכולים לראות רק כללים שמשויכים להיקפים שהוקצו להם.

זיהוי וקבוצות כללים עם זיהויים

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

מקורות נתונים של SOAR

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

לוחות הבקרה של בקשות התמיכה והיסטוריית בקשות התמיכה לא תומכים במנגנוני גישה של SOAR (כמו סביבות ותפקידי SOC). משתמש עם הרשאות גישה למרכזי בקרה יכול לראות את הפניות בכל הסביבות והתפקידים ב-SOC.

מדדי הטמעה

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

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

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

אפשר לסנן לפי התוויות הבאות:

  • מרחב שמות: השיטה העיקרית להפרדה (לדוגמה, Eu-Prod, ‏ Alpha-Corp).
  • סוג היומן: הפרדה מבוססת-תפקידים (לדוגמה, GCP_VPC_FLOW, CROWDSTRIKE_EDR).
  • מקור הטמעה: מעקב מפורט אחרי המקור (לדוגמה, מזהה ספציפי של מעביר).

סוגי יומנים לא צפויים במדדי ההטמעה

בחלק מלוחות הבקרה מוצגים רשומות של סוגי יומנים כמו UNSPECIFIED_LOG_TYPE או מזהים פנימיים, כולל LT_X (כאשר X הוא מספר). המזהים האלה של LT_X משמשים במערכת Google SecOps כדי לזהות באופן ייחודי סוגי יומנים בהתאמה אישית שנוצרו על ידי לקוח.

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

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

פערים בין נפח היומנים הגולמיים לנפח היומנים במרכז הבקרה

הנפח הכולל של ingestion.log_volume שמוצג בתרשים במרכז הבקרה (לדוגמה, שאילתה שמסננת לפי ingestion.component = "Ingestion API" ב-365 הימים האחרונים) יכול להיות שונה מהנפח המצטבר של היומנים הגולמיים מהסיבות הבאות:

  • טווח הזמן ומגבלות המבט לאחור: בממשק של Google SecOps לא מוצג מונה מצטבר של כל ההטמעות מאז שהמכונה הוקצתה. אי אפשר לחשב סכום כולל לכל התקופה מעבר למגבלת השאילתות של 365 ימים בלוחות הבקרה של Google SecOps, גם לא בתרשים Ingestion - Throughput (All-Time) שנבחר בקפידה. במכונות מסוג Bring Your Own Project ‏ (BYOP), אפשר לשלוח שאילתות על נתונים של עד 24 חודשים ב-Cloud Monitoring.
  • מקור נתונים וצינור: נפח היומן הגולמי משקף את גודל אצוות היומן הגולמי באחסון בבייטים. לוחות הבקרה מריצים שאילתות על הטבלה ingestion_metrics, שבה נאספים נתוני טלמטרייה באופן אסינכרוני במרווחי זמן של כ-5 דקות. יכול להיות שיהיו עיכובים באיסוף הנתונים או ירידות זמניות במדדים בצינור המדדים, ולכן כדאי להתייחס לסיכומים בלוח הבקרה ingestion.log_volume כאל אינדיקטורים משוערים ולא כאל ספירות מדויקות של בייטים. במאמר איפה אפשר לחשב את נפח ההטמעה ומה ההבדלים בין הערכים מוסבר איפה אפשר לחשב את נפח ההטמעה ומה ההבדלים בין הערכים.

מגבלות

  • תווית בהתאמה אישית: אם מקצים למשתמש היקף הרשאות שמכיל תווית בהתאמה אישית (למשל, תווית שנוצרה באמצעות ביטוי רגולרי של UDM או טבלאות נתונים), המערכת משביתה באופן אוטומטי את ה-RBAC למדדי הטמעה של המשתמש הזה. כתוצאה מכך, המשתמש לא יראה נתונים במרכזי הבקרה שלו. במסגרות של מעקב אחר הטמעה, צריך להשתמש רק בתוויות רגילות כמו Log Type,‏ Namespace ו-Ingestion Source.

  • מגבלות על מקור ההטמעה: אפשר לסנן לפי מקור ההטמעה רק את המדד "מספר היומנים". יכול להיות שלא יוצגו נתונים בתרשימים שמציגים מדדים של רוחב פס (בייטים) או שיעורי שגיאות, אם מסננים אותם רק לפי מקור ההטמעה. ‫Google ממליצה לסנן לפי מרחב שמות כדי לעקוב אחרי התקינות באופן רחב יותר.

תכונות מתקדמות ומעקב

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

מאפייני YARA-L 2.0

ל-YARA-L 2.0 יש את המאפיינים הייחודיים הבאים כשמשתמשים בו במרכזי בקרה:

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

  • פונקציות YARA-L 2.0 למרכזי הבקרה של Google Security Operations ופונקציות צבירה שכוללות מדדים סטטיסטיים.

  • השאילתה ב-YARA-L 2.0 חייבת להכיל מקטע match או מקטע outcome, או את שניהם.

  • הקטע events של כלל YARA-L משתמע ואין צורך להצהיר עליו בשאילתות.

  • הקטע condition של כלל YARA-L לא זמין למרכזי בקרה.

  • לוחות בקרה לא תומכים בכללים מהקטגוריה Risk Analytics for UEBA (ניתוח סיכונים ל-UEBA).

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