ניתוח היעילות של הכללים

נתמך ב:

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

במדריך הזה מוסבר איך לבצע את הפעולות הבאות:

  • איך מעריכים כלל במהלך ההשקה הראשונית שלו, מקבלים התראות ובודקים את מרכז הבקרה של הכללים כדי לעקוב אחרי התקינות שלו.

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

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

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

לפני שמנתחים את היעילות של הכללים ב-Google SecOps, חשוב להבין את שפת YARA-L, את השאילתות של YARA-L, איך ליצור ולנהל כללים ואיך ליצור לוחות בקרה:

מונחים חשובים

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

איך מנתחים כללים

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

בדיקה והערכה של הכללים אחרי הפריסה

כשפורסים כלל חדש בסביבת הייצור, כדאי לעקוב אחריו בRule Observabilityלוח הבקרה במשך 24 עד 48 שעות:

  1. עוברים אל מרכזי שליטה.

  2. חיפוש של Rule Observability.

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

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

זיהוי הסיבה לעיכוב בתוצאת הכלל

כדי לבדוק אם יש עיכוב בתוצאות של כלל מסוים, ואם כן, למה:

  1. עוברים אל Detections > Alerts & IOCs.
  2. בכרטיסייה התראות, מחפשים את העמודה סוג הזיהוי.
  3. חיפוש התראות עם סמל של נורת ליבון צהובה.
  4. מעבירים את העכבר מעל הסמל כדי לראות אם הזיהוי הופעל על ידי אחד מהגורמים הבאים:
    • עיבוד מחדש של כלל: מופעל באופן ידני על ידי משתמש.
    • חיפוש רטרואקטיבי: מופעל ידנית על ידי משתמש.
    • נתוני אירועים עם עיכוב: מציין אם צפוי עיכוב בזיהוי.

סינון התראות לפי זמן הזיהוי

  1. עוברים אל Detections > Alerts & IOCs.

  2. בכרטיסייה Alerts, משתמשים במסנן של העמודה Detection time כדי למיין את הזיהויים לפי זמן ההגעה שלהם.

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

בדיקת מטא-נתונים

כדי לקבל תובנות נוספות לגבי הביצועים של הכללים, אפשר לבדוק את ה-JSON הגולמי של הזיהוי באמצעות latencyMetrics כדי למצוא את ההבדל בין oldestEventTime לבין oldestIngestionTime.

ערכי התזמון של הזיהוי

בטבלה הבאה מפורטים הערכים הממוספרים שמשויכים ל-DetectionTimingDetails:


ערך
תיאור
ההשפעה על MTTD

UNSPECIFIED


הזיהוי נוצר במסגרת חלון התזמון הרגיל.
נתוני אמת לגבי MTTD.

REPROCESSING


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

RETROHUNT


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

דוגמה: מטא-נתונים של latencyMetrics

בדוגמה הבאה, latencyMetrics מוצג ההבדל בין הזמן שבו התרחש אירוע (oldestEventTime לעומת newestEventTime) לבין הזמן שבו האירוע נקלט (oldestIngestionTime לעומת newestIngestionTime). זמן האחזור בין האירוע לבין הקליטה בחשבון Google SecOps הוא כ-53 דקות.

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

פתרון בעיות

בטבלה הבאה מפורטות חלק מהבעיות שאתם עשויים להיתקל בהן במהלך העבודה עם כללים, ומוסבר איך לפתור אותן:


בעיה
הפתרון

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

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

שימוש מוגזם במחשוב.
הכלל כנראה סורק יותר מדי נתונים או שהלוגיקה שלו לא יעילה. עוברים אל Rule Exclusions (החרגות של כללים) או משתמשים בFilter Offloading (העברת מסננים) כדי לשנות את הכלל ולצמצם את החיפוש של הנתונים.

מגבלות ידועות

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

המאמרים הבאים

למידע על הפעלה חוזרת של כללים ועל עיכובים בזיהוי כללים, כדאי לעיין במאמרים הבאים:

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