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

נתמך ב:

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

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

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

בנוסף למסמך הזה, מומלץ לקרוא על ניהול לוח הזמנים להפעלת הכללים.

מונחים חשובים

  • הפעלה ראשונה (𝑇 + offset): ההפעלה הראשונית של הלוגיקה של הכלל. ההיסט מייצג את העיכוב שנוסף כדי להתחשב בנתונים שמגיעים באיחור.
  • הרצה של True-up: הערכה מחדש ברקע של אותו חלון זמן, כדי לתעד יומנים או נתונים להעשרה שהגיעו אחרי ההרצה הראשונה.
  • העשרה: מטא-נתונים חיצוניים (כמו תגי נכסים או כינויים של משתמשים) שנוספים ליומנים במהלך העיבוד.

לפני שמתחילים

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

  • הרשאות: כדי לשנות את לוחות הזמנים של הכללים, צריך להיות לכם תפקיד IAM שמעניק את הפעולה detection:ModifyRuleSchedule:

    • roles/detectionEngine.admin

    • roles/detectionEngine.editor

  • בדיקת הסביבה:

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

הגדרת התזמון של כלל עם כמה אירועים

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

  1. ב-Google SecOps, עוברים אל Detection > Rules & Detections (זיהוי > כללים וזיהויים).
  2. לוחצים על לוח הבקרה של הכללים.
  3. מחפשים את הכלל, לוחצים על סמל האפשרויות הנוספות more_vert ובוחרים באפשרות הפעלת התזמון.
  4. בכרטיסייה Rule schedule (תזמון הכלל), בוחרים ערך בשדה First run schedule (תזמון ההפעלה הראשונה) ובוחרים את תדירות ההפעלה של הכלל.
  5. מעבירים את המתג התאמת ההפעלה הראשונה לנתונים שמגיעים באיחור למצב מופעל.
    • כשל צפוי: יכול להיות שעדיין לא יופיעו יומנים בהפעלה הראשונה אם ההיסט קצר יותר מהשהיית ההטמעה בפועל של המקור.
    • פעולה מתקנת: מגדילים את ההיסט או מסתמכים על הפעלות של True-up לאימות סופי.
  6. מפעילים את המתג Ensure enrichment completeness (הבטחת השלמת ההעשרה).
    • כשל צפוי: יכול להיות שההתראות יופיעו הרבה אחרי חותמת הזמן של האירוע.
    • שלב לתיקון: משתמשים באפשרות הזו רק עבור כללי תאימות לא קריטיים, שבהם הדיוק חשוב יותר מהמהירות.
  7. בודקים את התצוגה המקדימה של לוח הזמנים של הכלל כדי להבין את ציר הזמן של ההפעלה:
    • הפעלה ראשונה (𝑇 + היסט): המערכת מפעילה את הלוגיקה של הכלל אחרי העיכוב שצוין לנתונים שמגיעים באיחור.
    • הרצת עדכון 1 (𝑇 + 4 שעות): המערכת סורקת מחדש את חלון הזמן 4 שעות אחרי ההרצה הראשונה כדי לזהות נתונים שהוחמצו או הגיעו באיחור. אם מפעילים את המתג הבטחת השלמת ההעשרה, ההרצה הזו גם מחכה שכל נתוני ההעשרה המשויכים יעברו עיבוד.
    • הפעלה של עדכון נתונים 2 (שעה 𝑇 + 30): ההפעלה הזו מופיעה רק אם מפעילים את המתג Ensure enrichment completeness (הבטחת השלמת העשרת הנתונים). המערכת מבצעת סריקה סופית 30 שעות אחרי ההרצה הראשונה כדי לספק את רמת הדיוק הגבוהה ביותר של הנתונים.
  8. לוחצים על Save.

הסבר על התצוגה המקדימה של לוח הזמנים

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

  • הפעלה ראשונה (𝑇 + offset): זיהוי איומים במהירות האפשרית. יכול להיות שחלק מהנתונים עדיין בתהליך העברה או העשרה, ולכן יכול להיות שהממצאים מההרצה הראשונה יגיעו מאוחר מהצפוי.

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

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

זיהוי מקורות הזיהוי

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

אינדיקטורים של זיהוי

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

  • אם הסמל הזה מופיע, הזיהוי התרחש במהלך הרצה של עדכון (𝑇+4$ או 𝑇+30$) ולא במהלך ההרצה הראשונית (𝑇).
  • בדרך כלל, זיהויים עם הסמל הזה מציינים שהפלטפורמה זיהתה את האיום אחרי ההטמעה הראשונית, בדרך כלל בגלל יומנים שהגיעו באיחור או עיכובים בהעשרת הנתונים.

אימות שלמות ההתראה בדף ההתראות

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

פתרון בעיות

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

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

אם זיהוי לא מופיע במהלך ההרצה הראשונה (𝑇), אבל מופיע בהרצה של עדכון הנתונים (𝑇+4$ או 𝑇+30$), כדאי לבדוק את הדברים הבאים:

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

חסרות אפשרויות להתאמה אישית

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

  • בודקים את סוג הכלל: לוחות זמנים שאפשר להתאים אישית חלים רק על כללים מרובי-אירועים. כללים של אירוע יחיד משתמשים במנוע רציף (בזמן אמת) ולא תומכים בלוחות זמנים מותאמים אישית.
  • אימות matchהחלון:כללים עם matchחלון של יותר מ-48 שעות מוגבלים לתדירות הפעלה של פעם ביום, ואי אפשר להתאים אותם אישית.
  • זיהוי כללים שנבחרו בקפידה: אי אפשר לשנות את לוח הזמנים של כללים שנבחרו בקפידה. מחפשים את ההודעה Curated rules uses a legacy schedule כדי לוודא שהכלל הוא כלל מערכת מוגן.

עיכוב לא צפוי בהתראות על הפעלה ראשונה

אם זיהוי מגיע אחרי המרווח המתוזמן:

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

נראה שהמדידות של MTTD גבוהות

המדדים של MTTD כוללים את תקופת החיץ שנדרשת להשלמת הנתונים.

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

מגבלות

  • רק בכללים שמבוססים על כמה אירועים: התכונה הזו לא זמינה בכללים שמבוססים על אירוע יחיד.
  • כללים בהתאמה אישית בלבד: כללים שנבחרו בקפידה משתמשים בלוחות זמנים קבועים שאי אפשר לשנות. אם צופים בכלל שנבחר, המערכת מציגה את ההודעה: Curated rules use a legacy schedule.

תיקון שגיאות

שגיאה שגיאה תיקון
אפשרויות חסרות הכרטיסייה 'לוח זמנים של הכלל' מושבתת או שאפשרויות חסרות. מוודאים שהכלל הוא כלל מותאם אישית מרובה אירועים וחלון ההתאמה הוא פחות מ-48 שעות.
התראות מושהות הזיהויים מגיעים אחרי מרווח הזמן המתוזמן. בודקים אם המתג Ensure enrichment completeness (הבטחת השלמת ההעשרה) מופעל. יכול להיות שהמערכת ממתינה לעיבוד המטא-נתונים.
רק התראות על עדכון נתונים הזיהויים אף פעם לא מופיעים בהפעלה הראשונה (𝑇). לוחצים על זמן האחזור של ההטמעה כדי לאמת. אם היומנים מגיעים באיחור של 15 דקות, אבל ההיסט שלכם הוא 10 דקות, צריך להגדיל את ההיסט של ההפעלה הראשונה.

אימות ובדיקה

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

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

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