הסבר על תזמון ההפעלה של כללים
המסמך הזה מיועד לאנליסטים, למהנדסים ולאדמינים של פלטפורמות אבטחה שרוצים להבין ולנהל את התזמון של הפעלת כללים ב-Google Security Operations. במאמר מוסבר איך הגדרות הכללים קובעות את תדירות העיבוד, איך המערכת מאזנת בין סטרימינג כמעט בזמן אמת לבין עיבוד אצווה מתוזמן, ואיך הרצות ברקע מטפלות ביומנים שמגיעים באיחור ובהעשרת ההקשר.
תרחישים נפוצים לדוגמה
בחירת לוח הזמנים הנכון או הבנתו תלויה בחומרת האיום ובמורכבות הלוגית:
- התראות בעדיפות גבוהה: זיהוי איומים קריטיים כמעט בזמן אמת להתאמות של אירועים בודדים שלא דורשות קורלציה נוספת של אירועים, וכך מקטינים את זמן השהייה של התוקף.
- מתאם ודיווח מורכבים: אפשר להשתמש במרווחי זמן מתוזמנים (למשל, 10 דקות או שעה) עבור כללים מרובי-אירועים שמחשבים ספירות, סכומים או חלונות תואמים נעים. מרווחי זמן מתוזמנים מבטיחים שהמערכת תבצע קליטה והעשרה של יומנים קשורים לפני ההפעלה, וכך תשפר את הדיוק של ההתראות לצורך ניתוח מגמות ועמידה בדרישות.
מונחים חשובים
- תדירות דטרמיניסטית: מרווח הביצוע הבסיסי שהמערכת מקצה באופן אוטומטי על סמך חלון ההתאמה של הכלל וסוג הכלל.
- הפעלה ראשונית (T + היסט): ההפעלה הראשונית של לוגיקת הזיהוי מול בלוק של זמן אירוע. ההשהיה בהעברת הנתונים מייצגת את ההפרש שנוסף כדי להתחשב בנתונים שמגיעים באיחור.
- השהיה בהסדרת התשלום: תקופת ההמתנה שנוספת להרצה הראשית כדי לאפשר עיבוד של יומנים שמגיעים באיחור לפני שמתחילים להעריך את הכלל.
- הרצות של תיקון טעויות (הפעלה מחדש של כללים): הרצות אוטומטיות ברקע שמעריכות מחדש חלונות זמן שעברו עיבוד כדי לתעד יומנים או נתוני העשרה שהגיעו אחרי ההרצה הראשונית.
- העשרה: תהליך של הוספת הקשר ליומן (כמו מטא-נתונים של נכסים, זהות משתמש או אינדיקטורים של מודיעין איומי סייבר) במהלך עיבוד צינור הנתונים.
- עיכוב בזיהוי: הזמן הכולל שחלף בין חותמת הזמן של האירוע לבין יצירת הזיהוי.
לפני שמתחילים
צריך לוודא שהסביבה עומדת בדרישות הבאות:
- הרשאות: כדי לשנות את לוחות הזמנים של הכללים, צריך להיות לכם תפקיד אדמין של Chronicle API (
roles/chronicle.admin) או עורך של Chronicle API (roles/chronicle.editor) ב-IAM. כדי לבדוק את לוחות הזמנים בלוח הבקרה של הכללים, צריך להיות לכם תפקיד צפייה של Chronicle API (roles/chronicle.viewer). - בדיקת הסביבה: מוודאים שהיומנים ממופים למודל הנתונים המאוחד (UDM) כדי לתמוך בצבירות של מרווחי זמן מתוזמנים.
איך עובד תזמון של כללים
Google SecOps מאזן בין זמן האחזור של זיהוי כמעט בזמן אמת לבין יציבות הפלטפורמה באלפי כללים. הפלטפורמה משתמשת בשני מודלים עיקריים של ביצוע:
- מנוע סטרימינג: מעריך כל הזמן כללים רגילים וכללים של אירוע יחיד עם חלון זמן (גם אם חלון הזמן גדול מ-48 שעות) בזמן אמת (בדרך כלל תוך 5 דקות מההטמעה). אירועים שמגיעים באיחור והעשרות רטרואקטיביות מוערכים באופן רציף במהלך הביצוע הרגיל.
- מנוע שאילתות מתוזמן: מעריך כללים מורכבים של אירוע יחיד (עם רשימות הפניה או טבלאות נתונים) כמעט בזמן אמת, וכללים של כמה אירועים בחבילות של זמן אירוע (למשל, מרווחים של 10 דקות או שעה, או
match_window / 10לחלונות של יותר מ-48 שעות). כללים שמתייחסים לכמה אירועים מחייבים חלון זמן לצורך צבירה ומתאם של אירועים ממקורות שונים.
הגדרות ברירת המחדל של התזמון
כשמפעילים כלל, מערכת Google SecOps קובעת באופן אוטומטי את תדירות הביצוע שמוגדרת כברירת מחדל על סמך הלוגיקה של הכלל וחלון ההתאמה:
| סוג הכלל וגודל החלון | תדירות ההפעלה | תזמון ההערכה | הפעלות של True-up |
|---|---|---|---|
| כלל של אירוע יחיד (רגיל או עם חלון זמן) | זמן אמת | זמן קצר אחרי ההגעה (פחות מ-5 דקות) | לא. המערכת מעריכה נתונים מאוחרים ונתונים מועשרים באופן רציף בהפעלה רגילה. |
| כלל של אירוע יחיד (עם רשימות הפניה או טבלאות נתונים) | כמעט בזמן אמת | זמן קצר אחרי ההגעה (פחות מ-5 דקות) | לא. המערכת מעריכה נתונים מאוחרים ונתונים מועשרים באופן רציף במהלך ההפעלה של שאילתה רגילה. |
כלל של כמה אירועים (window <= 48h) |
כל שעה (או כל 10 דקות – אפשרות להתאמה אישית לחלונות של פחות משעה) | שעה עד שעתיים אחרי ההגעה | כן. התכונה כוללת הפעלה אוטומטית של תהליך התאמה למשך 4 שעות, והפעלה אופציונלית של תהליך התאמה למשך 30 שעות. |
כלל של כמה אירועים (window > 48h) |
match_window / 10 (לדוגמה, כל יום אחד לחלון התאמה של 10 ימים) |
משתנה בהתאם לחלון ההתאמה (match_window / 10) |
לא. המערכת בודקת נתונים מאוחרים ונתונים מועשרים במהלך הפעלות חופפות עוקבות. |
הפעלות אוטומטיות של עדכון נתונים
כדי למנוע פספוסים בזיהוי שנגרמים בגלל זמן טעינה או מטא-נתונים של העשרה שמגיעים באיחור (כמו תגי נכסים או כינויים של משתמשים), המערכת מבצעת באופן אוטומטי הרצות של תיקון נתונים ברקע עבור כללים מרובי-אירועים (window <= 48h):
- הפעלה ראשונית: מבוצעת במהירות האפשרית על סמך המרווח שנקבע בלוח הזמנים, כדי לחשוף איומים מיידיים.
- ההרצה הראשונה של בדיקת ההתאמה (4 שעות): הערכה מחדש של בלוק הזמן כ-4 שעות אחרי ההרצה הראשונית, כדי לכלול יומנים שהגיעו באיחור. בשלב הזה לא ממתינים להעשרת נתונים מלאה.
- הפעלה שנייה של עדכון הנתונים (30 שעות): (אופציונלי) מתבצעת כ-30 שעות אחרי ההפעלה הראשונית, אחרי שכל צינורות ההקשר הנוסף והעשרת הנתונים מסתיימים.
מידע נוסף על התנהגות של עדכון נתונים ותרחישים זמין במאמר הסבר על הפעלה מחדש של כללים ועל MTTD.
תזמונים בהתאמה אישית
בכללים מותאמים אישית של כמה אירועים עם חלון התאמה של 48 שעות או פחות, Google SecOps מאפשר להתאים אישית את פרמטרים של התזמון במקום להסתמך באופן מלא על ברירות המחדל של המערכת:
- בחירת תדירות: בוחרים תדירויות הפעלה כמו כל 10 דקות (למשכי זמן של התאמה של פחות מ-60 דקות) או כל שעה.
- השהיית הסדר: הוספת השהיה (T + offset) כדי להתאים את עצמכם לזמן האחזור הידוע של קליטת מקורות יומנים.
- השלמת העיבוד של העשרת הנתונים: הארכת העיבוד של התאמת הנתונים ל-30 שעות כדי לוודא שכל השילובים של מטא-נתונים חיצוניים הושלמו לפני ההערכה הסופית.
שלבי ההגדרה המלאים מופיעים במאמר הגדרת לוחות זמנים מותאמים אישית לכללים.
הגדרת הרשאות הגישה ללוח הזמנים במרכז הבקרה של הכללים
במרכז הבקרה של הכללים מוצג לוח הזמנים שהוקצה להפעלה של כל כלל פעיל בעמודה לוח זמנים של כללים. כללים לא פעילים לא מציגים לוח זמנים פעיל עד שהם מופעלים.
כדי לשנות את תדירות ההפעלה, להוסיף עיכובים בהסדרת התשלומים או לשנות את זמני ההמתנה להעשרה של כלל מותאם אישית עם כמה אירועים, אפשר לעיין במאמר הגדרת לוחות זמנים מותאמים אישית לכללים.
אינדיקטורים של מקור הזיהוי
בדף התראות ובמרכז הבקרה של הכללים, בעמודה סוג הזיהוי מצוין אם הזיהוי נוצר מהפעלה ראשונית או מהפעלה אוטומטית ברקע:
- ללא סמל: הזיהוי נוצר במהלך ההפעלה הראשית (T) או באמצעות מנוע הסטרימינג הרציף.
- סמל הנורה : הזיהוי נובע מנתוני אירועים שהגיעו באיחור של יותר מ-30 דקות, מהפעלות אוטומטיות של עדכון נתונים, מצינורות לעיבוד מחדש או מחיפושים רטרואקטיביים.
שיקולים לגבי זמן אחזור ופתרון בעיות
תדירות הפעלת הכללים משפיעה ישירות על מהירות הזיהוי. כשמעצבים כללים ועוקבים אחריהם, חשוב לזכור את ההתנהגויות הבאות:
- תזמונים שעתיים: הפעלה כל שעה באמצעות הנתונים העדכניים ביותר שזמינים. לא מוחל מאגר נוסף כברירת מחדל.
- חלונות התאמה ארוכים מ-48 שעות: המערכת מפעילה את הכללים האלה בקצב של
match_window / 10ולא מבצעת ריצות של עדכון נתונים. - אי התאמות בין הרצות: יכול להיות שזיהוי שלא מופעל בהרצה הראשונה יופעל במהלך הרצת עדכון אם חל עיכוב בהטמעת היומן או אם העשרת ההקשר (למשל, פתרון גרף הישויות) הושלמה אחרי ההערכה הראשונית.
- אפשרויות התאמה אישית חסרות: כללי אירוע יחיד מוערכים כמעט בזמן אמת ולא תומכים בהתאמה אישית של מרווחים. כללים שנבחרו בקפידה פועלים לפי לוחות זמנים קבועים של המערכת. כללים מותאמים אישית של כמה אירועים עם חלון התאמה של יותר מ-48 שעות מופעלים בתדירות של
match_window / 10ואי אפשר להתאים אותם אישית. - מרווחי זמן שלא נתמכים: אם אי אפשר לבחור ביצוע כמעט בזמן אמת, הכלל הוא כלל מרובה אירועים שדורש קורלציה של אירועים לאורך זמן או כולל צבירות (כמו
countאוsum), שדורשות את מנוע השאילתות המתוזמן של אצווה.
שלבים מפורטים לפתרון בעיות זמינים במאמר הסבר על עיכובים בזיהוי כללים.
המאמרים הבאים
כדי לקרוא על מושגים קשורים בנושא תזמון ועל תהליכי עבודה להגדרה, אפשר לעיין במסמכים הבאים:
- הגדרת לוחות זמנים מותאמים אישית לכללים: אפשר להתאים אישית את תדירות ההפעלה, את העיכובים בהסדרת התשלומים ואת השלמת ההעשרה של נתוני ה-true-up לכללים שכוללים כמה אירועים.
- הסבר על הפעלות חוזרות של כללים ועל MTTD: במאמר הזה מוסבר איך הפעלות חוזרות אוטומטיות של כללים מטפלות בנתונים שמתקבלים באיחור ובעדכוני הקשר, ואיך הן משפיעות על מדדי הזמן הממוצע לגילוי (MTTD).
- הסבר על עיכובים בזיהוי כללים: אבחון ופתרון של עיכובים צפויים ובלתי צפויים בצינורות ההטמעה והעיבוד.
- ניהול כללים באמצעות כלי העריכה של הכללים: יצירה, עריכה וניהול של כללי זיהוי בהתאמה אישית ב-Google SecOps.
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.