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

נתמך ב:

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