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

נתמך ב:

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

השהיית הזיהוי הכוללת

במרכז אבטחה (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 דקות, כל שעה או 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.