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

נתמך ב:

Google secops SIEM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.