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

נתמך ב:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף זמין במאמר שאילתות לדוגמה ב-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 במענה להתראה שנוצרה.

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

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

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