ניהול לוח הזמנים להפעלת הכלל
המסמך הזה מיועד למהנדסי אבטחה ולמנתחי אבטחה שרוצים לנהל את לוחות הזמנים להרצת כללים ב-Google Security Operations. במאמר מוסבר איך להגדיר את תדירות הסריקה – מסריקה בזמן אמת ועד למרווחי זמן מתוזמנים של 24 שעות – ואיך לפרש את הריצות ברקע שמעבדות נתונים שמגיעים באיחור.
תרחישים נפוצים לדוגמה
בחירת לוח הזמנים הנכון תלויה בחומרת האיום ובמורכבות של הלוגיקה. רוב הצוותים קובעים את סדר העדיפויות של לוחות הזמנים שלהם על סמך המטרות הבאות.
התראות בעדיפות גבוהה
- המטרה: זיהוי איומים קריטיים ברגע שהם מגיעים לפלטפורמה.
- ערך: מקצר את זמן השהייה של התוקף במקרים של התאמות לאירוע יחיד שלא דורשות הקשר נוסף.
מתאם מורכב ודיווח
- מטרה: הפעלת כללים שדורשים ספירות, סכומים או חלונות של כמה אירועים.
- ערך: המערכת מעכלת את כל היומנים הרלוונטיים ומעשירה אותם לפני ההפעלה, וכך מספקת התראות מדויקות יותר לצורך ניתוח מגמות ותאימות.
לפני שמתחילים
לפני שמשנים לוחות זמנים, צריך לוודא שהסביבה עומדת בדרישות הבאות כדי למנוע שגיאות בהגדרות.
- הרשאות: כדי לשנות את לוחות הזמנים של הכללים, צריך להיות לכם תפקיד אדמין של Chronicle API (
roles/chronicle.admin) או עורך של Chronicle API (roles/chronicle.editor). - בדיקת הסביבה: מוודאים שהיומנים ממופים בצורה נכונה למודל הנתונים המאוחד (UDM) כדי לתמוך בצבירות של מרווחי זמן מתוזמנים.
מונחים חשובים
כדי להבין טוב יותר איך המערכת מטפלת בתזמון, כדאי להכיר את המונחים הספציפיים האלה לפלטפורמה.
- הרצות של עדכון נתונים: הרצות אוטומטיות ברקע שמעריכות מחדש את הכללים כדי לתעד נתונים שהגיעו באיחור או שנדרש להם זמן נוסף להעשרה.
- העשרה: תהליך של הוספת הקשר ליומן, כמו מטא-נתונים של נכסים או זהות משתמש, שיכול לקרות זמן קצר אחרי ההטמעה הראשונית.
הסבר על תזמון ההפעלה של כללים
מערכת Google SecOps קובעת באופן אוטומטי את אפשרויות התזמון הזמינות על סמך הלוגיקה של הכלל. בתפריט Run Schedule מוצגות רק אפשרויות שמתאימות לסוג הכלל הספציפי (לדוגמה, אירוע יחיד לעומת אירועים מרובים).
הגדרות ברירת המחדל של התזמון
המערכת מעריכה את האירועים אחרי שהם מגיעים, לפי לוח הזמנים הבא. העיכוב הזה נועד להבטיח שהנתונים יהיו מלאים, ולקחת בחשבון את זמן האחזור של הטמעה או העשרה.
| לוח זמנים | קריטריונים למטלות | תזמון ההערכה | מחזורי התאמה |
|---|---|---|---|
| זמן אמת (10 דקות) | חלון של אירוע או משחק בודד שנמשך פחות משעה | זמן קצר אחרי ההגעה | לא. מעריכה נתונים מאוחרים או נתונים שהועשרו בהפעלה רגילה. |
| מדי שעה (1h) | חלון התאמה בין שעה ל-48 שעות | שעה עד שעתיים אחרי ההגעה | כן. כולל שלבים של 5 שעות ו-24 שעות. |
| מדי יום (24 שעות) | חלון ההתאמה > 48 שעות | 24 עד 25 שעות אחרי ההגעה | כן. כולל שלבים של 5 שעות ו-24 שעות. |
איך מגדירים לכללים לוחות זמנים מותאמים אישית
שלבים אוטומטיים של התאמת מלאי
כדי למנוע מצב שבו המערכת לא תזהה אירועים בגלל עיכובים בהוספה או בהעשרה, היא מבצעת באופן אוטומטי הרצות של כללים מרובי-אירועים.
- הפעלה ראשונית: מבוצעת במהירות האפשרית כדי לחשוף איומים מיידיים.
- הרצה ביניים (כ-5 שעות): הרצה נוספת מתרחשת כחמש שעות אחרי האירוע. הערה: בשלב הזה לא ממתינים להעשרה מלאה של הנתונים.
- התאמה סופית (כ-24 שעות): מתבצעת אחרי שמאשרים את כל הנתונים הנוספים וההעשרה (100% שקיפות).
הערה: כללים של אירוע יחיד מעבדים נתונים שמתקבלים באיחור ונתונים מועשרים במהלך ביצוע רגיל, ולא משתמשים במחזורי עדכון של 5 שעות ו-24 שעות.
שינוי לוח הזמנים להרצה
כדי לשנות את התדירות שבה המערכת מעריכה את לוגיקת הזיהוי המותאמת אישית:
- ב-Google SecOps, עוברים אל Detection (זיהוי) > Rules & Detections (כללים וזיהויים).
- לוחצים על לוח הבקרה של הכללים.
- פותחים את התפריט עוד more_vert של הכלל.
- בוחרים ערך של Run Schedule (תזמון הפעלה) מהתפריט (לדוגמה, 10 minutes (10 דקות)).
- לוחצים על Save. המערכת שומרת את השינויים באופן אוטומטי.
זיהוי של ממצאים
אחרי שהכלל מופעל, אפשר להבחין בין ההתראות הראשוניות לבין ההתראות שנוצרו על ידי ההפעלות החוזרות האוטומטיות של המערכת.
- עוברים לדף Alerts או לRules Dashboard.
- בעמודה סוג הזיהוי, לוחצים על נורת חשמל כדי לראות אם הזיהוי נוצר מהרצה ראשונית, מהרצה של עדכון או מהרצה של חיפוש רטרואקטיבי.
פתרון בעיות
כדאי לבדוק את המאפיינים של הנתונים כדי להבין למה זיהויים ספציפיים מופיעים או משתנים לאורך זמן. המערכת מזהה את רוב האיומים באופן מיידי, אבל כדי לספק דיוק מלא, נדרש עיבוד ברקע של חלק מהניואנסים בנתונים. ההסבר על הרצות הרקע האלה יעזור לכם למדוד בצורה מדויקת את הזמן הממוצע עד לגילוי (MTTD) ולאמת את התקינות של ההתראות.
זמן אחזור ומגבלות
תדירות ההפעלה של הכלל משפיעה ישירות על מהירות הזיהויים. אם בוחרים בלוחות זמנים בתדירות נמוכה יותר, הזמן שחולף בין התרחשות האירוע לבין העיבוד של הזיהוי במערכת מתארך.
תזמונים שעתיים: התזמונים האלה מופעלים כל שעה באמצעות הנתונים העדכניים ביותר שזמינים, ללא שימוש במאגר זמני.
לוחות זמנים יומיים: המערכת מוסיפה מאגר זמני של 24 שעות כדי להבטיח שהנתונים ייקלטו במלואם לפני העיבוד.
פערים בין הרצות
יכול להיות שהרצה ראשונית של כלל לא תזהה זיהוי שיופיע מאוחר יותר במהלך הרצת עדכון. ההתנהגות הזו מבטיחה שהמערכת תזהה את רוב האיומים באופן מיידי, תוך אפשרות לאישור ברמת מהימנות גבוהה בשלב מאוחר יותר. סיבות נפוצות לכך:
- השהיה בהטמעת נתונים: נתוני יומן שמגיעים אחרי שההרצה הראשונה מסתיימת.
- השלמת ההעשרה: הקשר ממקורות חיצוניים (מטא נתונים של נכס או זהויות) עדיין נמצא בתהליך עיבוד במהלך ההרצה הראשונית.
- התאמות של התזמון: התהליך של התאמת הבידינג מתבצע רק אחרי שמתקבל מערך הנתונים המלא ביותר. יכול להיות שהתוצאות של הזיהוי בהרצה הראשונה יגיעו מאוחר מהצפוי.
תיקון שגיאות
כדי לפתור בעיות נפוצות שקשורות לאפשרויות התאמה אישית חסרות או ללוחות זמנים מוגבלים, אפשר להיעזר בטבלה הזו.
| שגיאה | הסיבה והפתרון |
|---|---|
| אפשרויות תזמון מותאמות אישית חסרות | כללים של אירוע יחיד משתמשים במנוע בזמן אמת ולא תומכים במרווחי זמן מתוזמנים. בנוסף, כללים שנבחרו בקפידה פועלים לפי לוחות זמנים קבועים של המערכת שאי אפשר לשנות. |
| אינטרוולים שלא נתמכים | אם אי אפשר לבחור באפשרות כמעט בזמן אמת, סביר להניח שהכלל משתמש בקטע match או בצבירות (כמו count או sum). הפונקציות האלה דורשות מרווחי זמן מתוזמנים כדי לעבד נתונים לאורך זמן. |
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.