אופטימיזציה של הביצועים של זיהוי האיומים והדיווח

נתמך ב:

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

זמן האחזור הכולל של הזיהוי

במרכז אבטחה (SOC), הזמן הממוצע הכולל לזיהוי (MTTD) הוא סכום עיכובים בזמן לאורך צינור האבטחה. כדי למדוד את ה-MTTD בצורה מדויקת ולקצר אותו, צריך לעקוב אחרי שלושה רכיבים עיקריים:

זמן האחזור של הטמעת היומן (יצירת היומן עד הטמעת הנתונים)

השהיית הטמעת היומן היא הזמן שחלף בין המועד שבו אירוע האבטחה התרחש במערכת המקור (metadata.event_timestamp) לבין המועד שבו היומן הוטמע ונותח בהצלחה ב-Google Security Operations‏ (metadata.ingested_time).

גורמים תורמים:

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

כדי לצמצם את זמן הטעינה של היומנים, אפשר:

  • מעקב אחרי תקינות מקור היומן ואופטימיזציה של ההגדרות של כלי האיסוף או המעביר.
  • כדי לעקוב אחר הדלתא, ב-YARA-L או ב-Data Lake, משווים את חותמות הזמן של UDM –‏ metadata.ingested_timestamp לעומת metadata.event_timestamp.

זמן האחזור של עיבוד הכללים (הכנסת נתונים ליצירת זיהוי)

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

גורמים תורמים:

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

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

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

מידע נוסף זמין במאמר שאילתות לדוגמה ב-YARA-L 2.0 לשימוש במרכזי בקרה.

כלל YARA-L למעקב אחרי זמן האחזור של עיבוד כללים

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

כדאי לפרוס את הכלל הזה בסביבת הבדיקה כדי ליצור בסיס להשוואה של מקורות היומן.

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

הכלל משווה בין metadata.event_timestamp (הזמן שבו הפעילות התרחשה) לבין metadata.ingested_time (הזמן שבו Google SecOps קיבלה את היומן). 

rule rule_processing_latency_monitor {
  meta:
    author = "SecOps Engineering"
    description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
    severity = "Low"

  events:
    $event.metadata.event_timestamp.seconds = $event_ts
    $event.metadata.ingested_time.seconds = $ingest_ts
    
    // Calculate the delta in seconds
    $latency_delta = $ingest_ts - $event_ts

    // Threshold: 900 seconds (15 minutes)
    $latency_delta > 900

  match:
    $event.metadata.log_type over 1h

  outcome:
    $max_latency = max($latency_delta)
    $log_source = array_distinct($event.metadata.log_type)

  condition:
    $event
}

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

הקטע הזה לא רלוונטי ללקוחות שמשתמשים בפלטפורמה העצמאית Google SecOps SIEM.

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

המדד הזמן הממוצע לקבלת אישור (MTTA) עוקב באופן ספציפי אחרי היעילות של צוות SOC במענה להתראה שנוצרה.

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

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

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

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