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

נתמך ב:

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

כללי זיהוי

כללי זיהוי בודקים אירועים רגילים ואירועים של מודל נתונים אוניברסלי (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. מנוע סטרימינג

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

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

    מנוע השאילתות מעבד את הכללים באופן הבא:

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

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

    • כללים מרובי-אירועים: הכללים האלה מבצעים שאילתות על נתונים במקטעים של זמן האירוע (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. בודקים את התדירות של הפעלת הכלל ואת ההגדרה של חלון ההתאמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוגי כללים

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

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

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

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

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

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

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

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

  • הפניה לכללים של אירוע בודד

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

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

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

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

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

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

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

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

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

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

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

  • כמעט בזמן אמת: כללים מופעלים בתדירות גבוהה יותר עבור נתונים בזמן אמת. זה חל רק על כללים של אירוע יחיד.
  • תדירויות אחרות: לסוגים אחרים של כללים, אפשר להגדיר את התדירויות הבאות:
    • תדירות של 10 דקות תקפה לחלונות של משחקים באורך של פחות מ-60 דקות.
    • תדירויות של שעה אחת ו-24 שעות תקפות לחלונות התאמה של פחות מ-48 שעות.
    • תדירות של 24 שעות תקפה לכל חלונות ההתאמה של 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 של המשתמש (מנתוני ההקשר של המשתמש).
  • העשרה: זהו התהליך שבו נעשה שימוש במידע שנאסף מכינויים כדי להוסיף הקשר לאירוע 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) או נתוני הקשר של נכס. מכיוון שצינור ה-ECG מסתמך בעיקר על עיבוד באצווה, נתוני הקשר של הישות מתעדכנים לעיתים קרובות רק אחרי שהפעלת כלל יוצרת זיהוי.

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

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

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

  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.