הסבר על הפעלות חוזרות של כללים ועל MTTD

נתמך ב:

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

הפעלות חוזרות של כללים

‫Google Security Operations מעבדת נפחים גדולים של נתוני אבטחה. כדי להבטיח זיהוי מדויק של כללים שתלויים בנתונים הקשריים או בנתונים שקשורים זה לזה, מנוע הכללים מריץ באופן אוטומטי תהליך של הפעלה מחדש של כלל.

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

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

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

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

טריגרים להפעלה מחדש של כללים

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

  • אירועים ממקורות שמגיעים באיחור: האירוע עצמו ביומן הגולמי או ב-UDM מגיע ל-Google SecOps הרבה אחרי חותמת הזמן בפועל של האירוע.
  • נתוני העשרה שמגיעים באיחור: נתונים הקשריים (לדוגמה, משתמש, נכס, מודיעין איומי סייבר) שקשורים לאירוע הופכים לזמינים, או שהמערכת מעדכנת אותם, אחרי שהיא עיבדה את האירוע בפעם הראשונה. לרוב זה קורה כי צינורות העשרה, כמו גרף הקשר של הישות (ECG), מעבדים נתונים באצוות או מסתמכים על מקורות נתונים חיצוניים.
  • עדכונים רטרואקטיביים להעשרת נתונים ב-UDM: נתוני מקור שמגיעים באיחור (כמו רשומות DHCP שמעדכנות שמות מארחים) מפעילים שינויים בשדות של אירועים ב-UDM. כללים שמשתמשים בשדות עם כינוי (שדות מועשרים) בלוגיקה של הזיהוי שלהם, כמו $udm.event.principal.hostname, יכולים להפעיל הפעלות חוזרות כשיש עיכוב בנתוני המקור. העדכון המאוחר הזה משנה את הערכים בשדות האלה באופן רטרואקטיבי.

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

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

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

  • כללים של אירוע יחיד (ללא חלונות התאמה או טבלאות נתונים):

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

  • כללים של אירוע יחיד עם חלון זמן (WSE) וכללים של אירוע יחיד עם טבלאות נתונים:

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

  • כללים שמתייחסים לכמה אירועים:

    • כללים מרובי אירועים מופעלים לפי לוח זמנים ומבצעים הערכה מחדש של בלוקים של זמן כדי להתחשב בנתונים שמתקבלים באיחור. לוח הזמנים של הכלל קובע את חלון הזמן שבו הכלל פעיל:
      • הפעלה ראשונית: המערכת מריצה את ההערכה הראשונה בזמן האירוע בתוספת כל עיכוב ההסדרה שהוגדר (לדוגמה, T + שעה).
      • הפעלה של True-up‏ 1: המערכת מריצה את ההפעלה הראשונה של True-up בערך 4 שעות אחרי ההפעלה הראשונית. כך המערכת יכולה לכלול אירועים שמגיעים באיחור.
      • הפעלה שנייה של השלמת נתונים (מותנית): אם מפעילים את האפשרות הבטחת השלמת העשרה, המערכת מפעילה השלמת נתונים סופית כ-30 שעות אחרי ההפעלה הראשונית. כך חלון הזמן שבו המערכת יכולה לעבד נתונים שמגיעים באיחור והעשרות הקשר מתארך לכ-30 שעות.
      • השלכות של נקודת הסיום: נקודת הסיום האפקטיבית להכללת נתונים מאוחרים נקבעת לפי ההרצה הסופית של תהליך ההתאמה. בדרך כלל זה קורה כ-4 שעות אחרי ההרצה הראשית (או כ-30 שעות אחרי ההרצה הראשית אם מפעילים את האפשרות Ensure enrichment completeness). אירועים או העשרות שמגיעים אחרי ההרצה הסופית של ההתאמה לחלון זמן מסוים לא יעברו עיבוד על ידי הכלל הזה בחלון הזמן הזה.

דוגמאות לתרחישים של נתונים שמגיעים באיחור

  • תרחיש 1: אירוע מאוחר במקור – כלל של אירוע יחיד

    • מערכת Google SecOps קולטת אירוע עם חותמת זמן מלפני 3 ימים. כלל רגיל של אירוע יחיד מעבד את האירוע הזה כנתונים חדשים.

  • תרחיש 2: העשרה מאוחרת – כלל של אירוע יחיד

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

  • תרחיש 3: אירוע מאוחר ממקור – כלל של כמה אירועים (התאמה של 4 שעות כברירת מחדל)

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

  • תרחיש 4: אירוע מאוחר ממקור – כלל מרובה אירועים (ללא השלמת העשרה)

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

  • תרחיש 5: העשרה מאוחרת – כלל מרובה אירועים (עם שלמות העשרה)

    • בכלל שמבוסס על כמה אירועים מוגדר היסט של שעה אחת, ואתם מפעילים את האפשרות Ensure enrichment completeness (הבטחת השלמת ההעשרה). נתוני ההעשרה של אירוע מגיעים 28 שעות אחרי חותמת הזמן של האירוע.
    • המערכת מעריכה מחדש את הכלל באמצעות ההעשרה המאוחרת הזו במהלך ההרצה השנייה של בדיקת הדיוק, בערך בשעה T + 31h.

  • תרחיש 6: אירוע מאוחר ממקור – כלל מרובה אירועים עם חלון התאמה

    • חלון הזמן של כלל עם כמה אירועים הוא 48 שעות match, והוא מתוזמן עם האפשרות Ensure enrichment completeness (התאמה סופית בסביבות T + 30h). אירוע מגיע 36 שעות אחרי חותמת הזמן שלו. האירוע הזה לא יעבור עיבוד כי הוא התקבל אחרי ההרצה הסופית של ההתאמה, גם אם שעת האירוע היא בתוך חלון ההתאמה של הכלל ביחס לאירועים אחרים. המועד האחרון מבוסס על זמן ההגעה ביחס ללוח הזמנים של ההתאמה, ולא רק על חלון ההתאמה.

  • תרחיש 7: אירוע מאוחר ממקור – כלל של אירוע יחיד עם חלון זמן

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

ההשפעה על מדדי התזמון

כשמתקבלת תוצאת זיהוי מהפעלה חוזרת של כלל, המערכת משתמשת במינוח הבא:

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

הפרש בציר הזמן וזמן ממוצע לזיהוי (MTTD)

הזמן שחלף בין חותמת הזמן של האירוע הראשוני לבין יצירת הזיהוי משפיע ישירות על החישוב של MTTD.

שלב בצינור או בלוח הזמנים תזמון ההערכה ההשפעה על מדידת הזמן הממוצע לזיהוי (MTTD)
כלל של אירוע יחיד (סטרימינג) רציף (פחות מ-5 דקות אחרי ההגעה) הזיהויים בזמן אמת מייצגים את המהירות האמיתית של הפלטפורמה עם השפעה מינימלית על MTTD.
כלל מרובה-אירועים (הפעלה ראשית) שעה עד שעתיים אחרי ההגעה (בנוסף לעיכוב שמוגדר לחיוב) כולל את חלון החיץ הבלתי נמנע של אצווה שנדרש לצורך צבירה של מצבי קורלציה של כמה אירועים.
כלל מרובה-אירועים (הפעלות של True-up) 4 שעות או 30 שעות אחרי ההרצה הראשית הפעלה משנית (הפעלה חוזרת) שמשלבת נתוני העשרה מאוחרים גורמת לכך שהזמן הזה יופיע מאוחר או באיחור ביחס לחותמת הזמן של האירוע. הדלתא הזו משפיעה לרעה על חישוב ה-MTTD.

שיטות מומלצות למדידת הזמן הממוצע לזיהוי (MTTD)

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

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

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

תעדוף של מערכות זיהוי בזמן אמת

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

התחשבות בהפעלה חוזרת של כללים בכללים מרובי-אירועים

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

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

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

אופטימיזציה של הכללים כדי להפחית את ההסתמכות על העשרה מאוחרת

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

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

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

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