הסבר על המכסות של הכללים

נתמך ב:

Google SecOps SIEM

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

הקיבולת של הכללים מנוהלת באמצעות שתי הקטגוריות הבאות:

• כללים בהתאמה אישית: כללים שנכתבו ומנוהלים על ידי הצוות שלכם.

• גלאים מוכנים מראש: כללים שנכתבו ומנוהלים על ידי Google.

מכסות של כללים מותאמים אישית לפי חבילה

כללים בהתאמה אישית כפופים למכסות ביצועים שמבוססות על חבילת Google SecOps שלכם.

בטבלה הבאה מפורטות מכסות הכללים לכל חבילה:

חבילה	מכסת הכללים הכוללת	מכסה של כללים עם כמה אירועים
רגילה	1,000	75
Enterprise	2,000	200
Enterprise Plus	3,500	400

מעקב אחרי מכסת כללים בהתאמה אישית

כללים בהתאמה אישית כפופים למכסות ביצועים מחמירות שמבוססות על המורכבות שלהם.

כדי לעקוב אחרי מכסת כללים בהתאמה אישית:

1. ב-Google SecOps, עוברים אל Detection > Rules & Detections.

2. לוחצים על הכרטיסייה מרכז הבקרה של הכללים.

3. לוחצים על קיבולת הכללים. בתפריט הקופץ של פרטי הקיבולת מוצגות המכסות הבאות:

   • מכסת כללים מרובי-אירועים: מספר הכללים מרובי-אירועים שהופעלו לעומת המקסימום המותר.
   • ‫Total Rules Quota (מכסת הכללים הכוללת): המספר הכולל של הכללים המופעלים לעומת המספר המקסימלי המותר.

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

• כללים של אירוע יחיד נכללים רק במכסת הפעילות הכוללת.

• כללים מרובי-אירועים צורכים קיבולת גם מהמכסה הכוללת של משתמשים פעילים וגם מהמכסה של כללים מרובי-אירועים בו-זמנית.

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

קיבולת של גלאים מוכנים מראש

גלאים מוכנים מראש (נקראים גם כללי Google SecOps) הם קבוצות של כללים שנוצרו על ידי Google Threat Intelligence‏ (GTI).

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

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

איך מחושב נפח האחסון המנוהל

הקיבולת המותאמת לא מבוססת על מספר הכללים, אלא על סכום המשקלים שמוקצים לכל קבוצת כללים מופעלת. קיבולת ברירת המחדל היא 150.

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

• צריכה: כשמופעלים כללים (מדויקים, רחבים או שניהם) עבור קבוצת כללים, המשקל המלא של הקיבולת של קבוצת הכללים נספר בשימוש הכולל.

צפייה בפרטי הקיבולת שנאספו

כדי לראות את הקיבולת והשימוש של הגלאים המוכנים מראש:

1. ב-Google SecOps, עוברים אל זיהוי > כללים וזיהויים > זיהויים שנאספו.

2. לוחצים על הכרטיסייה קבוצות כללים. בעמודה קיבולת מוצג המשקל של כל קבוצת כללים.

3. לוחצים על לחצן הסטטוס Curated Detections Capacity כדי לראות את השימוש הכולל בקיבולת של החשבון.

הפעלת קבוצות כללים שנבחרו בקפידה

אם החבילה שלכם תומכת בכך, אתם יכולים להפעיל כללים במערכות כללים שנבחרו בקפידה:

1. ב-Google SecOps, עוברים אל זיהוי > כללים וזיהויים > זיהויים שנאספו.

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

3. בתפריט עדכונים בכמות גדולה, בוחרים באפשרות הפעלה של כל הפריטים שנבחרו.

4. כדי לאשר את השימוש בקיבולת, לוחצים על Curated Detections Capacity, או עוברים אל Detection > Rules & Detections, בוחרים בכרטיסייה Rules Dashboard ולוחצים על Rules Capacity.

אופטימיזציה של ביצועי המערכת

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

חלוקת לוגיקה מורכבת למודולים

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

1. זיהוי אותות באמצעות כללים של אירוע יחיד

   • יוצרים כללים לאירועים בודדים להתנהגויות ספציפיות (לדוגמה, User Login Failed, ‏ Process Launched).

   • השפעה: צורך את המכסה הפעילה הכוללת (שפע) ופועל כמעט בזמן אמת.

2. התאמה בין התראות לכלל מורכב או לכלל של כמה אירועים

   • כותבים כלל מורכב שמשתמש בתוצאות הזיהוי שנוצרו בשלב 1 כקלט.

   • ההשפעה: צריכת מכסת אירועים מרובים (יקר).

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

יצירת עיצוב יעיל של כלל

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

• שימוש ברשימות הפניה: במקום N כללים ל-N אינדיקטורים, אפשר להשתמש בכלל אחד שמפנה לרשימת הפניה (לדוגמה, target.ip in %suspicious_ips). כך משתמשים רק ביחידה אחת של מכסת הכללים.

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

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

תרחיש: זיהוי תוקף שמנסה לפרוץ לשרת באמצעות פרוטוקול Risk Data Platform ‏ (RDP) ומריץ באופן מיידי כלי ניהול חשוד (כמו PsExec) כדי לנוע לרוחב.

שלב 1: זיהוי אותות באמצעות כללים של אירוע יחיד

יוצרים שני כללים קלי משקל שפועלים על המכסה הכוללת הפעילה הגדולה. הם יוצרים זיהויים.

• כלל א' (אות של ניסיון פריצה):

  • הלוגיקה:

    • בודקים אם יש auth.status = FAILURE.

    • אירועי התחברות לקבוצה.

    • הפעלת הטריגר אם יש יותר מ-5 ניסיונות כושלים בדקה אחת.

  • קלט: אירועי UDM גולמיים.

  • פלט: התראת זיהוי בשם Possible_RDP_Brute_Force.

  • עלות: נמוכה (השימוש הוא במכסה הכוללת הפעילה).

• כלל ב' (אות חשוד מכלי):

  • לוגיקה: הטריגר יופעל אם התהליך הוא psexec.exe.

  • קלט: אירועי UDM גולמיים.

  • פלט: התראת זיהוי בשם PsExec_Usage.

  • עלות: נמוכה (השימוש הוא במכסה הכוללת הפעילה).

שלב 2: מתאימים התראות לכלל מורכב

כותבים כלל מורכב אחד שמתייחס לזיהויים שנוצרו בשלב 1, ולא ליומנים הגולמיים.

• כלל ג':

  • לוגיקה: חיפוש של Possible_RDP_Brute_Force AND PsExec_Usage שמתרחש באותו principal.hostname תוך 10 דקות.

  • קלט: זיהויים מכללים א' וב'.

  • עלות: גבוהה (נעשה שימוש במכסת אירועים מרובים), אבל רק כמה התראות שנוצרו בשלב 1 מעובדות.

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

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