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

נתמך ב:

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

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

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

תרחישים נפוצים לדוגמה

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

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

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

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

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

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

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

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

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

    אם משתמשים בתפקידים מוגדרים מראש ב-IAM, כמו אדמין Chronicle API‏ (roles/chronicle.admin) או עורך Chronicle API‏ (roles/chronicle.editor), ההרשאות האלה נכללות באופן אוטומטי.

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

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

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

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

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

פתרון בעיות

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

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

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

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

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

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

  • בודקים את סוג הכלל: אפשר להגדיר לוחות זמנים מותאמים אישית רק לכללים של כמה אירועים. כללים של אירוע יחיד (כולל כללים רגילים, כללים מבוססי חלון וכללים מבוססי הפניה) מוערכים כמעט בזמן אמת, ולא תומכים בלוחות זמנים מותאמים אישית.
  • מוודאים את match חלון הזמן: כללים שמבוססים על כמה אירועים עם match חלון זמן של יותר מ-48 שעות מופעלים בתדירות match_window / 10 שמוקצית אוטומטית, ואי אפשר להתאים אותה אישית.
  • זיהוי כללים שנבחרו בקפידה: אי אפשר לשנות את התזמון של כללים שנבחרו בקפידה. אם בודקים כלל שנבחר, בממשק המשתמש מוצגת ההודעה: Multi-event curated rules use a legacy schedule.

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

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

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

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

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

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

מגבלות

  • רק לכללים של כמה אירועים: התכונה הזו לא זמינה לכללים של אירוע יחיד. כללים של אירוע יחיד (כולל כללים רגילים, כללים מבוססי-חלון וכללים מבוססי-הפניה) נבדקים כמעט בזמן אמת.
  • כללים מותאמים אישית בלבד: כללים שנבחרו בקפידה משתמשים בלוחות זמנים קבועים שאי אפשר לשנות. אם צופים בכלל שנבחר, המערכת מציגה את ההודעה: Multi-event curated rules use a legacy schedule. אם צופים בכלל מותאם אישית מדור קודם, המערכת מציגה: Your Multi-Event rule uses a legacy schedule.

תיקון שגיאות

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

אימות ובדיקה

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

  1. ב-Google SecOps, עוברים אל Detection (זיהוי) > Rules & Detections (כללים וזיהויים) ובוחרים באפשרות Rules Dashboard (לוח בקרה של כללים).
  2. בוחרים את הכלל וצופים בכרטיסייה זיהויים.
  3. בודקים את העמודה סוג הזיהוי ומסננים לפי כדי לוודא שהרצות של עדכון הנתונים תופסות נתונים שההרצה הראשית פספסה, ואז משנים את ההשהיה של ההתאמה בהתאם.

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

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

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