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

נתמך ב:

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

סקירה כללית של כללי הזיהוי

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

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

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

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

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

‫Google SecOps יוצרת זיהויים של כללים באמצעות צינורות ההפעלה הבאים:

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

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

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

סוגי כללים ומורכבות

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

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

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

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

הכללים האלה מעריכים אירועים בודדים, אבל הם כוללים תלות נוספת בנתונים:

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

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

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

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

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

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

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

משך חלון ההתאמה

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

השהיה בהטמעת יומן

זמן השהיה של ההטמעה הוא הזמן שחולף בין התרחשות אירוע במקור לבין הרגע שבו Google SecOps מקבל ומנתח את היומן.

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

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

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

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

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

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

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

צירופים הקשריים והעשרת נתונים

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

מנגנונים של יצירת כינויים והעשרה

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

  • יצירת כינויים: זיהוי וקישור של מזהים שונים לאותו ישות במקורות נתונים שונים (למשל, מיפוי של כתובת IP מיומני DHCP לכתובת MAC ולשם מארח כמו alex-macbook, או מיפוי של מזהה משתמש לתפקיד של עובד).
  • העשרה: מאכלסת שדות של אירועים ב-UDM עם ההקשר שקיבל כינוי (למשל, מאכלסת את $udm.event.principal.hostname כשכתובת IP בלבד מופיעה באירוע הגולמי).

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

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

המערכת מעדכנת באופן רציף אירועים היסטוריים ככל שמקורות ההקשר מתפתחים:

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

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

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

הפעלות היסטוריות של כללים וחיפושים רטרואקטיביים

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

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

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

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

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

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

הגבלות על עיבוד נתונים ועל התאמות

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

  • עיבוד להעשרת נתונים: העשרה של הקשר יכולה לעדכן אירועים היסטוריים של UDM עד 24 שעות אחרי ההטמעה הראשונית.
  • מחזורי עדכון: כללים מרובי-אירועים מופעלים מחדש באופן אוטומטי כ-4 שעות (ואופציונלית כ-30 שעות) אחרי ההפעלה הראשונית, כדי לתעד נתונים שמגיעים באיחור. מידע נוסף זמין במאמר הסבר על הפעלה מחדש של כללים ועל MTTD.
  • מגבלות זיהוי: למידע על קיבולת הפלטפורמה ומגבלות הווסת, אפשר לעיין במאמר הסבר על מגבלות זיהוי.

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

כדי לאבחן למה כלל מסוים יצר זיהוי מושהה, בודקים את ההיוריסטיקות ואת שלבי הצינור הבאים במסוף Google SecOps:

  • בדיקת המטא-נתונים והתזמון של הכלל: בלוח הבקרה של הכללים, בודקים את העמודות שם הכלל, סוג הכלל ותזמון הכלל כדי לזהות את מנוע ההפעלה של הכלל ואת תדירות ההערכה של בסיס ההשוואה.
  • השוואה בין זמן האירוע לבין זמן ההטמעה: מאתרים את הזיהוי בכרטיסייה זיהויים ומשווים בין חותמת הזמן של האירוע לבין חותמת הזמן של ההטמעה. אם הפער בין זמן האירוע לבין זמן ההטמעה גדול מ-30 דקות, השהייה נגרמה בגלל עיכובים במסירת היומן במקור או במהלך האיסוף. אם הזיהויים נוצרו מנתוני אירועים שהגיעו באיחור של יותר מ-30 דקות, מהפעלות אוטומטיות של עדכון נתונים, מצינורות לעיבוד מחדש או מחיפושים רטרואקטיביים, יופיע הסמל בעמודה סוג הזיהוי.
  • בדיקת התלויות במקור ההקשר: בודקים אם הכלל מפנה להעשרה של principal, לכינוי של UDM או לשדות graph.entity. צינורות הקשר מעבדים באופן אסינכרוני, ויכול להיות שהם יציגו זיהויים במהלך הפעלות עתידיות של עדכון הנתונים.
  • אימות התאימות של התדירות וחלון ההתאמה: מוודאים שתדירות ההפעלה שהוגדרה תואמת לגודל חלון ההתאמה (לדוגמה, מוודאים שכלל עם חלון התאמה של 15 דקות מתוזמן ל-10 דקות או לשעה).
  • בודקים אם יש שיבושים בפיד הנתונים: בודקים את יומני ההטמעה ואת לוחות הבקרה לניהול פידים כדי לראות אם יש עיכובים בהטמעה או הפסקות זמניות במקור.

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

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

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

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

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

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