הסבר על הפעלה מחדש של כללים ועל 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: המערכת מריצה את ההפעלה הראשונה של True-up בערך 4 שעות אחרי ההפעלה הראשונית. כך המערכת יכולה לכלול אירועים שמגיעים באיחור.
      • הפעלה שנייה של השלמת נתונים (מותנית): אם מפעילים את האפשרות הבטחת השלמת העשרה, המערכת מפעילה השלמת נתונים סופית כ-30 שעות אחרי ההפעלה הראשונית. כך חלון הזמן שבו המערכת יכולה לעבד נתונים שמגיעים באיחור והעשרות הקשר מתארך לכ-30 שעות.
      • השלכות נקודת סף: ריצת ה-true-up הסופית מכתיבה את נקודת הסף האפקטיבית להכללת נתונים מאוחרים. התהליך הזה מתרחש בדרך כלל כ-4 שעות אחרי ההרצה הראשית (או כ-30 שעות אחרי ההרצה הראשית אם מפעילים את האפשרות Ensure enrichment completeness). אירועים או העשרות שמגיעים אחרי ההרצה הסופית של ההתאמה לנתונים בחלון זמן מסוים לא יעברו עיבוד על ידי הכלל הזה בחלון הזמן הזה.

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

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

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

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

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

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

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

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

    • אתם מגדירים כלל מרובה אירועים עם היסט של שעה אחת מההפעלה הראשית בלי להפעיל את האפשרות Ensure enrichment completeness (הבטחת השלמת ההעשרה). אירוע מגיע 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.
כלל מרובה אירועים (הפעלה ראשית) שעה עד שעתיים אחרי ההגעה (בנוסף לעיכוב ההתחשבנות שהוגדר) כולל את חלון הזיכרון הזמני של אצווה שאי אפשר להימנע ממנו, שנדרש לצורך צבירה של מצבי קורלציה של כמה אירועים.
כלל מרובה-אירועים (הפעלות של עדכון נתונים) 4 שעות או 30 שעות אחרי ההרצה הראשית הפעלה משנית (הפעלה חוזרת) שמשלבת נתוני העשרה מאוחרים גורמת לכך שהזמן הזה יופיע מאוחר או באיחור ביחס לחותמת הזמן של האירוע. ההפרש הזה משפיע לרעה על החישוב של MTTD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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