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

נתמך ב:

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

ההשפעה של RBAC על נתונים

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

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

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

כללים

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

זיהוי וערכות כללים עם זיהויים

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

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

מרכזי בקרה עם נתוני SOAR, כמו Cases, ‏ Case history, ‏ Playbooks ו-Alerts, גלויים רק למשתמשים גלובליים.

לוחות הבקרה של בקשות התמיכה וההיסטוריה שלהן לא תומכים במנגנוני גישה ל-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.

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

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

כדי לשפר את הזיהוי ואת הנראות, אפשר להשתמש בהגדרות מתקדמות, כמו כללי 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.