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

נתמך ב:

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

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

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

כברירת מחדל, מערכת 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) לבין נתוני תרשים הנכסים של הארגון. צינור עיבוד הנתונים של ECG מסתמך על עיבוד ברצף (batch processing) (שיכול להימשך 30 שעות או עד כמה ימים, בהתאם לנפח הנתונים). לכן, כללים שמפנים לשדות של graph.entity יוצרים גילויים אחרי שהקשרים בתרשים מחושבים באופן מלא.

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

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

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

מגבלות על עיבוד נתונים והתאמה (true-up)

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

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

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

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

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

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

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

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

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

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

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