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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. עוברים לכרטיסייה החרגות כדי לראות את רשימת ההחרגות. אפשר לבצע את הפעולות הבאות:

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

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

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

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

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

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

מגבלות

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

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

  כדי למצוא את הכלל הבסיסי:

  1. עוברים אל Content Hub במסוף Google SecOps.
  2. לוחצים על הכרטיסייה Curated Detections (או מחפשים את חבילת הכללים הספציפית).
  3. מאתרים את הכלל המורכב ולוחצים על הצגה וניהול.
  4. בוחרים באפשרות הגדרת כלל כדי לראות את קוד המקור הבסיסי של YARA-L.
  5. בודקים את הקטע events: בלוגיקה של YARA-L כדי לזהות את שמות הכללים הבסיסיים.

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

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

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

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

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

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

תרחיש שימוש

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

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

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

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

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