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

נתמך ב:

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

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

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

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

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

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

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

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

  • הרשאות: כדי לשנות את לוחות הזמנים של הכללים, אתם צריכים את הרשאות ה-IAM הבאות:

    • chronicle.ruleDeployments.update לשימוש ב-API לעדכונים של לוחות זמנים ספציפיים.

    • chronicle.rules.modifyRules לעדכונים באמצעות API לפעולות מקובצות ולשימוש בממשק המשתמש.

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

    • סוג הכלל: לוחות זמנים שניתנים להתאמה אישית חלים רק על כללים של מספר אירועים. כללים של אירוע יחיד וכללים שנבחרו בקפידה לא נכללים.
    • חלון של 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. בודקים את התצוגה המקדימה של לוח הזמנים של הכלל כדי להבין את ציר הזמן של ההפעלה:
    • הפעלה ראשונה (𝑇 + היסט): המערכת מפעילה את הלוגיקה של הכלל אחרי העיכוב שצוין לנתונים שמגיעים באיחור.
    • הפעלה ראשונה של עדכון הנתונים (𝑇 + 4 שעות): המערכת סורקת מחדש את חלון הזמן 4 שעות אחרי ההפעלה הראשונה כדי לתעד נתונים שהוחמצו או הגיעו באיחור. אם מפעילים את המתג Ensure enrichment completeness (הבטחת השלמת ההעשרה), הריצה הזו ממתינה גם לעיבוד של כל נתוני ההעשרה המשויכים.
    • הפעלה של עדכון נתונים 2 (𝑇 + 30 שעות): ההפעלה הזו מופיעה רק אם מפעילים את המתג הבטחת השלמת העיבוד. המערכת מבצעת סריקה סופית 30 שעות אחרי ההרצה הראשונה כדי לספק את רמת הדיוק הגבוהה ביותר של הנתונים.
  8. לוחצים על Save.

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות

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

תיקון שגיאות

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

אימות ובדיקה

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

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

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