סקירה כללית של לוחות הבקרה

נתמך ב:

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

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

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

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

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

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

כללים

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

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

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

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

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

מדדי הטמעה

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

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

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

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

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

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

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

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

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

מגבלות

  • תווית מותאמת אישית: הקצאת היקף משתמש שמכיל תווית מותאמת אישית – כמו תווית שנוצרה באמצעות ביטוי רגולרי של 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.

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