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

נתמך ב:

במאמר הזה מוסבר על עיכובים בזיהוי כללים ב-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 שעות עם השלמת העשרה) אחרי ההפעלה הראשונית.

  • דוגמה: כלל מבצע קורלציה בין אירוע א' (זמן האירוע 09:03) ואירוע ב' (זמן האירוע 09: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)

‫Entity Context Graph (ECG) מבצע קורלציה בין נתונים של Indicators of Compromise (IOCs) ובין נתונים של גרף נכסי הארגון. מכיוון שצינור הנתונים של ECG מסתמך על עיבוד אצווה (שיכול להימשך 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 דקות או לשעה).
  • בודקים אם יש שיבושים בפיד הנתונים: בודקים את יומני ההטמעה ואת לוחות הבקרה לניהול פידים כדי לראות אם יש עיכובים בהטמעה או הפסקות זמניות במקור.

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

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

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

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

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

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