הגדרת השבתה של התראות

נתמך ב:

במסמך הזה מתוארים המנגנונים שזמינים ב-Google Security Operations לביטול התראות שגויות ולתעדוף איומים קריטיים. השבתת התראות מסננת באופן אוטומטי התראות כפולות והתראות לא חשובות על סמך קריטריונים מוגדרים מראש. ההשבתה הזו מאפשרת לצוות SOC להתמקד בתקריות אבטחה בעדיפות גבוהה.

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

‫Google SecOps מספקת את השיטות הבאות לניהול נפח ההתראות:

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

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

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

  • קיבוץ התראות SOAR: קיבוץ אוטומטי של התראות דומות למקרה אחד על סמך הקריטריונים שלכם, כדי לייעל את החקירות.

השבתת התראות באמצעות הגבלת קצב הבקשות

ויסות נתונים (throttle) משבית את הזיהויים למשך זמן מסוים אחרי התאמה ראשונית לכלל. כשמשתמשים באפשרויות suppression_window ו-suppression_key בלוגיקה של הכלל, המערכת יוצרת זיהוי רק לשילוב הייחודי הראשון של מפתח ההשבתה. ‫Google SecOps מדכא את כל ההתאמות הבאות לאותו שילוב עד שחלון הזמן שהוגדר יפוג.

השיטה הזו מצמצמת ביעילות את הכפילויות בזיהוי שנובעות מאותה פעילות בסיסית.

תרחישים לדוגמה

  • הפעלה של PowerShell: דיכוי של התראות חוזרות ונשנות עבור אותו משתמש ואותו מארח למשך שעה אחת אחרי האירוע הראשוני.

  • סריקת רשת: דיכוי התראות חוזרות מסורק יציאות זדוני למשך שש שעות אחרי הזיהוי הראשון.

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

כדי לזהות כללים שיוצרים רעשי רקע:

  1. נכנסים ל-Google SecOps.

  2. לוחצים על תפריט, בוחרים באפשרות זיהוי > כללים וזיהויים.

  3. בכרטיסייה כלי לעריכת כללים, בוחרים את הכלל ולוחצים על בדיקה.

  4. משנים את הבורר של טווח הזמן כדי לנתח את הנתונים של 7 הימים האחרונים. אם כלל מסוים יוצר יותר מ-100 זיהויים ביום, סביר להניח שהוא רחב מדי.

  5. לוחצים על תפריט ואז על הצגת זיהויים של כללים. יופיע דף הפרטים של הזיהוי.

  6. בחלונית Procedural Filtering, מזהים את שדות ה-UDM שמשפיעים על התוצאות.

  7. כדי להפחית את עוצמת הקול של הזיהויים, משנים את הקטע match או את $suppression_key.

דוגמה: זיהוי של התחברויות ייחודיות לפי מיקום

כדי לזהות כניסות ייחודיות לפי מיקום ולמנוע עייפות מהתראות, אפשר להשבית את הזיהויים מאותה מדינה. מחפשים את השדה UDM event.principal.location.state כדי לראות את מספר הזיהויים לכל מצב.

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

הגדרת הגבלת קצב של זיהויים

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

  • כללים של אירוע יחיד: מגדירים את המשתנה $suppression_key בקטע outcome כמפתח לביטול כפילויות.

  • כללים של כמה אירועים: משתמשים במשתנים בקטע match כמפתח לביטול כפילויות.

  • משך החלון: מוודאים שמשך החלון suppression_window גדול מגודל החלון match או שווה לו. אם מגדירים את אותו משך, הכלל מתנהג כאילו לא הוחלה השהיה.

  • מגבלה: אין מגבלה על משך חלון ההשבתה.

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

דוגמה: מעקב אחרי פעילות בשיתוף קבצים ב-Windows

הכלל הבא עוקב אחרי פעילות של שיתוף קבצים ב-Windows. הוא יוצר זיהוי אחד לכל משתמש ייחודי ושם מארח בחלון של 60 דקות (1hr), ואז מדכא התאמות חוזרות לאותו שילוב למשך 24 שעות (24h).


rule rule_noisy_winshares {

  meta:
   author = "Google Cloud Security"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.target.resource.name = /(C|ADMIN|IPC)\$/ nocase
    $user = $e.principal.user.userid
    $hostname = $e.target.hostname

  match:
    $hostname, $user over 1h

  outcome:
    $sharename = array_distinct($e.target.resource.name)

  condition:
    $e

  options:
    suppression_window = 24h
}

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

השבתת התראות באמצעות החרגות של כללים

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

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

במאמר ניהול החרגות של כללים באמצעות API מוסבר איך ליצור החרגות באמצעות API.

תרחישים לדוגמה

  • הדחקת ביצוע לגיטימי של PowerShell על ידי כלי IT מורשים.

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

יצירת החרגות של כללים

כדי ליצור החרגות לכלל שיוצר הרבה רעשי רקע:

  1. נכנסים ל-Google SecOps.

  2. עוברים אל תפריט > זיהוי > כללים וזיהויים.

  3. בכרטיסייה מרכז הבקרה של הכללים, מחפשים כללים עם מספרים גבוהים של זיהויים.

  4. לוחצים על שם הכלל כדי לפתוח את הדף זיהויים.

  5. לוחצים על אפשרויות של כלל > החרגה.

  6. כדי להוסיף את מסנן ההחרגה, צריך לציין את הפרטים הבאים:

    • שם ההחרגה

    • כללים או קבוצות כללים שהיא חלה עליהם

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

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

        לדוגמה, principal.ip IS 192.158.1.38 OR principal.ip IS 192.186.0.2

      2. לוחצים על + משפט מותנה כדי להוסיף משפט חדש שיש לו קשר לוגי AND עם המשפט הקודם.

        לדוגמה, (principal.ip IS 192.158.1.38 OR principal.ip IS 192.186.0.2) AND (principal.user.userid CONTAINS sensitive)

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

  8. לוחצים על יצירה כדי להפעיל את ההחרגה.

ניהול החרגות של כללים

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

  1. נכנסים ל-Google SecOps.

  2. עוברים אל תפריט > זיהוי > כללים וזיהויים.

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

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

    • כדי לסנן את ההחרגות, לוחצים על סינון.

    • כדי לערוך החרגה, לוחצים על תפריט > עריכה.

    • כדי להעביר החרגה לארכיון, לוחצים על תפריט > העברה לארכיון.

    • כדי לשחזר החרגה, לוחצים על תפריט > ביטול העברה לארכיון.

במאמר ניהול החרגות של כללים באמצעות API מוסבר איך ליצור ולנהל החרגות של כללים באמצעות API.

מגבלות

כשמגדירים החרגות, חשוב לשים לב להבדלים הפונקציונליים האלה בין המסוף לבין ה-API:

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

  • משתני תוצאה: כדי ליצור החרגות שמשתמשות בלוגיקה שמבוססת על משתני תוצאה, צריך להשתמש ב-API.

השבתת התראות באמצעות מחברות הפעלה של SOAR

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

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

תרחיש שימוש

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

קיבוץ התראות ב-SOAR

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

מידע נוסף זמין במאמר בנושא מנגנון קיבוץ ההתראות.

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