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

נתמך ב:

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 Rules) הם קבוצות כללים שנוצרו על ידי Google Threat Intelligence (GTI).

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

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

איך מחושבת הקיבולת המותאמת

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

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

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

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

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

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

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

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

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

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

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

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, ולא ליומנים הגולמיים.

• כלל C:

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

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

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

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

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