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

נתמך ב:

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

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

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

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

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

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

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

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

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

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

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

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

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

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