הסבר על תזמון ההפעלה של כללים

נתמך ב:

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

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

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

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

  • תדירות דטרמיניסטית: התדירות ניתנת לחיזוי ונקבעת על ידי חלון ההתאמה של הכלל.

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

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

  • עיכוב בזיהוי: ההפרש בין הזמן שבו האירוע נקלט לבין הזמן שבו הכלל מוערך.

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

לפני שמתחילים, צריך לוודא שהתנאים המוקדמים הבאים מתקיימים:

  • הרשאות: צריכה להיות לכם גישת צפייה בלוח הבקרה Rules ב-Google SecOps.

הצגת תדירות הביצוע של הכלל

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

  2. פותחים את מרכז הבקרה של הכללים ב-Google SecOps ומאתרים את הכלל ברשימה.

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

הגדרת התדירות שבה הכלל יופעל

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

  1. כדי לזהות את גודל החלון, בודקים את הקטע match של הכלל.

  2. ממפים את גודל החלון לתדירות המערכת (לדוגמה, No window = Near real-time).

מיפוי של הפעלת לוח זמנים

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

סוג הכלל וגודל החלון תדירות ההפעלה דוגמה לתרחיש שימוש
כלל של אירוע יחיד זמן אמת התרעה מיידית על אינדיקטורים קריטיים (IOC).
כלל שמתייחס לכמה אירועים (window <= 48 hours) מדי שעה זיהוי ניסיונות של מתקפות כוח ברוטליות בחלון קצר (לדוגמה, 15m ו-1h).
כלל שמתייחס לכמה אירועים (window > 48 hours) יומי (24 hours) מעקב אחרי העברה איטית של נתונים במשך כמה ימים.

דוגמה: כלל מרובה אירועים עם הפעלה שעתית

בדוגמה הבאה מוצג כלל רב-אירועי שהמערכת מפעילה מדי שעה בגלל חלון הזמן של 15 דקות:


  rule fifteen_minute_window_example {

  meta:
    description = "Runs hourly because window is <= 48h"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 15m

  condition:
    $e
}

התנהגויות ומגבלות של המערכת

  • אין מרווחי זמן מותאמים אישית: אי אפשר להגדיר כלל שיפעל כל 10 דקות או בשעה 2:00. המערכת מנהלת את כל זמני ההתחלה באופן פנימי.

  • עיכובים בזיהוי: יכולים להיות עיכובים בזיהוי, בהתאם למהירות של העברת הנתונים. מידע נוסף זמין במאמרים הסבר על הפעלה מחדש של כללים ועל MTTD והסבר על עיכובים בזיהוי כללים.

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

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