הסבר על הפעלה מחדש של כללים ועל MTTD

נתמך ב:

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

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

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

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

  • כללים של אירוע יחיד: כשבתהליך ההעשרה של 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 ימים, הכלל יוערך מחדש.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

העשרה מחדש בגלל נתונים שמגיעים באיחור, או חביון בעדכון של מקור הקשר כמו גרף הקשר של הישות (ECG) גורמים בדרך כלל לחביון גבוה בזיהוי.

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

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

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

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

‫Google SecOps מספקת כמה מדדים שאפשר להשתמש בהם בשאילתות משתמשים כדי למדוד את ה-MTTD בצורה מדויקת. פרטים על המדדים האלה מופיעים במאמר דוגמאות לשאילתות YARA-L 2.0 לדף Dashboards.

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

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

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

בנוסף, השינוי הזה מאפשר שימוש מקיף יותר בזיהויים מורכבים.

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

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

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

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

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

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

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