הסבר על עיכובים בזיהוי כללים

נתמך ב:

במסמך הזה מוסבר על עיכובים בזיהוי כללים ב-Google Security Operations, מפורטים גורמים שמשפיעים על העיכובים, מוצגות גישות לפתרון בעיות ומוצעות טכניקות לצמצום העיכובים, איפה שאפשר.

כללי זיהוי

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

עיכובים צפויים ובלתי צפויים

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

אנחנו מסווגים את העיכובים כצפויים או כלא צפויים.

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

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

ניתוח של עיכובים בזיהוי כללים

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

  1. במסוף Google SecOps, עוברים אל Detection > Rules and detections.

    לוח הבקרה Rules מציג מטא-נתונים של כללים כמו Rule name,‏ Rule type ו-Run frequency.

    פרטים נוספים זמינים במאמר הצגת כללים בלוח הבקרה 'כללים'.

  2. בלוח הבקרה של הכללים, לוחצים על שם של כלל כדי לראות את היסטוריית הזיהוי ופרטים אחרים של כלל ספציפי.

  3. יש כמה גורמים שיכולים להשפיע על זמן האחזור של הזיהוי בכל הפעלה של כלל מסוים. מאפיינים כמו Rule type, Run frequency, Event type, Event time ו-Ingested time הם היוריסטיקות טובות להבנת הסיבה לעיכוב בזיהוי מסוים.

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

  1. כדי להבין איך הגורמים האלה משפיעים על העיכובים בזיהוי הכללים, מומלץ לעיין בנושאים הבאים:

שיטות ליצירת זיהוי

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

המערכת יוצרת זיהויים של כללים בדרכים הבאות:

  1. מנוע סטרימינג

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

  2. מנוע שאילתות

    מנוע השאילתות מעריך כללים מורכבים של אירוע יחיד ושל כמה אירועים:

    • כללים מורכבים של אירוע יחיד:

      • כללים של אירוע יחיד עם רשימות הפניה או טבלאות נתונים: כללים שמעריכים אירוע יחיד ומבצעים חיפושים ברשימות הפניה או בטבלאות הנתונים.
      • כללים של אירוע יחיד עם חלון זמן: כללים שבודקים אירוע יחיד עם חלון זמן ותנאי פשוט של קיום (לדוגמה, $e,‏ #e > 0 או #e >= 1).
      • כללים מורכבים של אירוע יחיד משתמשים במנוע השאילתות ולא במנוע הסטרימינג, אבל הם מתוזמנים בתדירות גבוהה כמעט בזמן אמת כשהמערכת קולטת נתונים חדשים. כך מתקבל זמן אחזור נמוך שקרוב לזמן האחזור האופייני של מנוע הסטרימינג. נתונים שמתקבלים באיחור ונתונים מועשרים מוערכים מחדש במהלך ביצוע שאילתה רגילה, בלי שנדרשים מרווחי זמן לתיקון נתונים מרובי-אירועים.

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

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

  3. הכללים מופעלים על נתונים היסטוריים

    לפרטים נוספים, אפשר לעיין במאמר בנושא חיפושים רטרואקטיביים.

  4. העשרה מחדש של אירועים ב-UDM

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

מגבלות ידועות

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

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

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

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

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

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

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

  • המערכת מפעילה מחדש את הכללים בין 5 ל-8 שעות אחרי ההפעלה הראשונית של הכלל, ושוב בין 24 ל-48 שעות אחרי ההפעלה הראשונית. שני הפעלות חוזרות של כללים נפרדות מופעלות על סמך זמני הביצוע של צינור העיבוד מחדש.

  • למידע נוסף על מגבלות זיהוי, אפשר לעיין במאמר הסבר על מגבלות זיהוי.

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

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

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

  1. בודקים אם יש עיכובים ברורים:

    בודקים אם יש עיכוב בהעברה:

    1. במסוף Google SecOps, עוברים אל Detection > Rules and detections.

    2. מחפשים את הכלל שרוצים לנתח במרכז הבקרה של הכללים.

    3. השוואה בין Event time לבין Ingested time.

      לדוגמה, אם יש פער גדול בין Event time לבין Ingested time, סביר להניח שאפשר לשייך את העיכוב בזיהוי לעיכוב צפוי. הסמל בעמודה סוג הזיהוי מופיע אם Ingestion time חל יותר מ-30 דקות אחרי Event time.

  2. בודקים את זמן האיסוף של מקור ההקשר:

    בודקים את זמן האיסוף של מקור ההקשר.

    כללים שמתחשבים בהקשר יכולים לכלול את מקורות ההקשר הבאים. בודקים את שעות האיסוף:

    • שדות שנגזרים מהעשרה של UDM.
    • אירועים שכוללים שדה principal.

    • כללים שמפנים לשדה graph.entity.

      כללים שמפנים לתרשים הקשר של הישות (ECG) עם תחביר graph.entity עלולים לגרום לחביון גבוה במיוחד. לדוגמה, צינור הנתונים של בדיקת האק"ג יוצר נתוני הקשר, תהליך שיכול להימשך 30 שעות או, במקרים מסוימים, עד 8 ימים, בהתאם לסוג הנתונים.

    פרטים נוספים מופיעים במאמר בנושא עיכובים בעיבוד נתונים.

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

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

  4. בדיקת אירועים מהזמן האחרון:

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

טיפים לקיצור העיכובים

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

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

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

    • הגדלת התדירות של הכלל:

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

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

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

    • קיצור משך חלון ההתאמה:

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

  • הימנעות מנתונים שמגיעים באיחור:

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

גורמים שמשפיעים על העיכובים בזיהוי הכללים

סוג הכלל, תדירות ההפעלה והמהירות של הטמעת Google SecOps הם גורמים מרכזיים בעיכובים בזיהוי כללים.

הגורמים הבאים תורמים לעיכובים בזיהוי כללים.

סוגי כללים

הכללים מחולקים לשתי קטגוריות עיקריות:

כללים לאירוע בודד

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

כללים מורכבים של אירוע יחיד

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

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

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

  • כללים של אירוע בודד עם חלון זמן:

    הכללים האלה של אירוע יחיד כוללים חלון התאמה עם תנאי פשוט של ספירת אירועים (למשל $e, #e > 0 או #e >= 1).

כללים עם כמה אירועים

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

  • כללים של כמה אירועים

    הכללים האלה בודקים שני תנאים או יותר של אירועים ב-UDM. בדרך כלל יש להם חלון התאמה וכמה תנאים.

  • כללים מבוססי-הקשר

    כללים מבוססי-הקשר עוזרים לכם לצרף לנתוני האירועים נתונים נוספים של ישויות והקשרים של זיהוי.

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

מידע נוסף על ההבדל בין כללי אירוע יחיד לבין כללי אירועים מרובים

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

תדירות ההרצה של הכלל משפיעה ישירות על עיכוב הזיהוי.

  • כמעט בזמן אמת: הכללים מופעלים עם השהיה מינימלית בזמן שהאירועים נקלטים. הכללים האלה חלים על:
    • כל הכללים של אירוע יחיד (אירוע יחיד רגיל, כללים עם רשימות הפניה או טבלאות נתונים וכללים של אירוע יחיד עם חלון).
    • כללים מרובי-אירועים עם חלונות התאמה של פחות מ-60 דקות.
  • תדירויות אחרות: בהגדרות אחרות של כללים, אפשר להגדיר את התדירויות הבאות:
    • תדירות של 10 דקות תקפה לחלונות התאמה של פחות מ-60 דקות.
    • תוקף התדירויות של שעה אחת ושל יום אחד הוא לחלונות התאמה של עד 48 שעות.
    • התדירות היומית תקפה לכל חלונות ההתאמה שגדולים מ-48 שעות.

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

חלון ההתאמה

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

השהיה בהטמעה

השהיית ההטמעה מתייחסת לזמן שנדרש ל-Google SecOps להטמיע נתונים אחרי שהאירוע מתרחש.

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

לדוגמה: אירוע א' (זמן האירוע 9:03) ואירוע ב' (זמן האירוע 9:05) הם חלק מכלל שמחפש שני אירועים בתוך 30 דקות. אם אירוע א' מגיע בשעה 10:05 (שעה אחרי הזמן), הוא לא נכלל בשאילתות הראשוניות של הבלוק בשעות 9:00-9:30. שאילתת המשך לגבי החסימה הזו בין השעות 14:00 ל-17:00 יוצרת את הזיהוי, וכתוצאה מכך יש עיכובים של 5 עד 8 שעות.

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

בעיות באזור הזמן

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

לדוגמה, יומן עם שעת אירוע של 10:00 לפי שעון החוף המזרחי (15:00 לפי שעון UTC) מגיע בשעה 15:05 לפי שעון UTC, אבל חסר בו אזור זמן. אם ביומן אין אזור זמן, המערכת מפרשת את שעת האירוע כ-10:00 UTC. לאחר מכן המערכת מחשבת עיכוב של 5 שעות בין שעת האירוע שפוענחה (10:00 UTC) לבין שעת ההטמעה בפועל (15:05 UTC). העיכוב המחושב הזה גורם לעיכובים בזיהוי, כי הכללים נותנים עדיפות לעיבוד על סמך קליטה בזמן אמת.

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

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

צירופים לפי הקשר

יכול להיות שיהיו עיכובים ארוכים יותר בכללים של כמה אירועים שמשתמשים בנתונים הקשריים, כמו שדות של UEBA או של תרשים הקשר של ישויות. קודם צריך ש-Google SecOps ייצור את הנתונים ההקשריים.

מערכת העשרה

‫Google SecOps מעשיר אירועי UDM על ידי הוספת נתונים הקשריים ממקורות אחרים. התהליך הזה בדרך כלל מסתיים תוך 30 דקות. עיכובים בהוספת הנתונים המועשרים האלה לאירועים ב-UDM יכולים להאריך את זמני הזיהוי.

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

פרטים נוספים זמינים במאמר בנושא העשרת נתונים.

כינויים והעשרה

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

  • יצירת כינויים: תהליך של זיהוי וקישור של שמות או מזהים שונים לאותה ישות. היא מאתרת נתוני הקשר נוספים שמתארים אינדיקטור. לדוגמה, שימוש בכינויים יכול לקשר בין כתובת IP אחת hostname (כמו alex-macbook) לבין אינדיקטורים קשורים אחרים, כמו IP addresses ו-MAC addresses (מיומני DHCP). אפשר גם להשתמש בכינוי כדי לקשר user ID (כמו alex) לjob title ולemployment status של המשתמש (מנתוני ההקשר של המשתמש).
  • העשרה: זהו התהליך שבו נעשה שימוש במידע שנאסף מכינויי ה-IP כדי להוסיף הקשר לאירוע UDM. לדוגמה, כשמגיע אירוע חדש עם IP address בלבד, תהליך ההעשרה משתמש בנתונים עם הכינוי כדי למצוא את hostname המשויך (לדוגמה, alex-macbook) ומאכלס את השדה $udm.event.principal.hostname.

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

העשרה מחדש של אירועים ב-UDM

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

  • עדכונים במערכת ההעשרה: אם מערכת ההעשרה מעדכנת את המטא-נתונים של ישות או תהליך, את המיקום הגיאוגרפי של כתובת ה-IP או את האינדיקטורים של VirusTotal, מנוע הכללים מעריך מחדש את הבלוקים האלה 24 עד 48 שעות לאחר מכן כדי לתעד את העדכונים.
    לדוגמה, לאירוע שהתרחש בשעה 9:03 יש entity.asset.hostname = hostnameA אבל אין כתובת IP. יומן DHCP מ-8:55 בבוקר מראה hostnameA = IP 1.2.3.4. מנוע הכללים פועל בשעה 9:10 והכלל לא תואם. תהליך העיבוד של ההעשרה מקשר בין hostnameA לבין 1.2.3.4 בחלון הזמן הזה, ומעדכן את אירוע ה-UDM. עכשיו הכלל תואם, והמערכת יוצרת זיהוי.

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

  • שינויים בנתוני ההעשרה: שינויים בנתוני ההעשרה יכולים לגרום להתאמה של כלל מאוחר יותר, גם אם לא הייתה התאמה בהתחלה.
    לדוגמה, אירוע שמתרחש בשעה 9:03 בבוקר יכלול את הערך entity.ip_geo_artifact.country_or_region = USA. מנוע הכללים פועל בשעה 9:10, מבצע שאילתה לגבי השעות 9:00 עד 10:00, והכלל לא תואם. בהמשך, העיבוד מחדש של ההעשרה מעדכן את המיקום הגיאוגרפי לקנדה. כשהכלל יפעל שוב, הוא יתאים עכשיו, והמערכת תיצור זיהוי.

עיבוד של גרף ההקשר של הישות

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

חיפושים בסגנון רטרו

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

דוגמה לתהליך עדכון רטרואקטיבי:

  1. אירוע ראשוני: אירוע מגיע בשעה 13:00 עם ip_address = 10.0.0.5. בשלב הזה, hostname לא ידוע.
  2. מגיע מקור של כינוי: בשעה 14:30 (יותר משעה אחרי), מגיע יומן DHCP לשעה 13:00, שמקשר בין 10.0.0.5 לבין workstation-123.
  3. העשרה רטרואקטיבית: מערכת הכינויים מעבדת את הקישור החדש. העדכון מתבצע רטרואקטיבית לאירוע ב-UDM החל מהשעה 13:00, ומעשיר את השדה $udm.event.principal.hostname שהיה ריק קודם לכן בערך workstation-123.
  4. זיהוי: בהפעלות חוזרות של כללים, המערכת רואה את הערך המועשר (workstation-123) ויכולה להפעיל זיהויים שהוחמצו קודם.

רשימות של הפניות

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

כדי לקצר את משך הזמן עד לגילוי:

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

כללים שמתייחסים לאי-קיום

המערכת ממתינה לפחות שעה לפני הפעלת כללים שבודקים אי-קיום (לדוגמה, כללים שמכילים !$e או #e=0), כדי לוודא שהנתונים יגיעו.

עיכובים בעיבוד נתונים

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

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