זיהויים משולבים

נתמך ב:

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

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

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

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

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

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

  • כללים לזיהוי בלבד: כללים מורכבים שמשתמשים רק בזיהויים או בהתראות כקלט.

מתי כדאי להשתמש בזיהויים מורכבים

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

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

  • הוספת נתונים של אירועים קשורים להתראות.

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

  • יצירת התראה למתקפה מורכבת ורב-שלבית, שכל שלב בה כבר מזוהה על ידי כלל משלו.

היתרונות של זיהויים מורכבים

היתרונות של זיהויים מורכבים:

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

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

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

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

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

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

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

הוספת הקשר לזיהויים מאירועים גולמיים

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

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

  • לדוגמה:

    1. התקבלה התראה ב Google Cloud Event Threat Detection כי עומס עבודה ביצע קריאת DNS לדומיין זדוני. זהו הזיהוי.

    2. הזיהוי הזה מפעיל כלל מורכב.

    3. לאחר מכן, הכלל מחפש ביומני Endpoint Detection and Response (EDR) גולמיים (האירועים) מאותה עומס עבודה בחלון של דקה אחת, ומחפש פעולות בשורת הפקודה שהכילו את אותו דומיין זדוני.

    ההתראה הסופית מספקת הקשר עשיר: היא מראה שנוצר קשר עם דומיין זדוני ומה הייתה הפקודה הספציפית שבה נעשה שימוש. המידע הזה הופך את התוצאה למעשית הרבה יותר מהזיהוי המקורי.ssh

מעקב אחרי פעילות המשתמשים אחרי ההתחברות

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

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

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

    • משתמש מוחק את היסטוריית שורת הפקודה שלו.

    • יצירה של חשבון אדמין מקומי חדש.

    • העלאה של נתונים בכמות גדולה לאתר אישי ב-Cloud Storage.

שילוב עם מדדי UEBA

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

  • מטרה: מציאת קורלציה בין עלייה חדה במדד UEBA לבין פעילות חריגה אחרת.

  • דוגמה:

    1. כלל UEBA מזהה מספר מוגזם של ניסיונות כניסה כושלים של משתמש.

    2. כלל UEBA אחר מזהה מספר גדול של בייטים של יציאה מאותו משתמש.

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

זיהוי ניסיונות לזליגת נתונים

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

  • יעד: בניית פרופיל של טיפול מסוכן בנתונים על ידי משתמש יחיד במכשירים ובפעולות שונות.

  • פעולות שקשורות זו לזו:

    • מתחברים מכמה מכשירים (למשל, מחשב בבית ומחשב בעבודה).

    • גישה ליותר מקורות נתונים מהרגיל.

    • הורדה, הדפסה ושליחה באימייל של נתונים בו-זמנית.

    • ספירה של מספר המסמכים המסווגים שמשתמש פותח בפרק זמן מסוים.

    • הגשת מכתב התפטרות.

זיהוי של תוכנות זדוניות רב-שלביות

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

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

  • לדוגמה:

    1. משתמש מבקר באתר זדוני (אירוע רשת ראשוני).

    2. קובץ dropper מורד ומופעל (האירוע הראשון בתהליך).

    3. הרבה יותר מאוחר, קובץ ההדבקה מוריד ומריץ קובץ הפעלה אחר (אירוע תהליך שני).

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

הפחתת רעשי התראות

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

  • המטרה: לשפר כלל רועש בלי להשבית אותו או ליצור החרגות מורכבות.

  • לדוגמה:

    1. מגדירים זיהוי עם רעשי רקע ל'זיהוי בלבד' כדי שלא יופקו יותר התראות.

    2. יוצרים זיהוי מורכב שמשתמש בפלט של הכלל שנבחר כתנאי הראשון שלו.

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

איך פועלות תכונות זיהוי מורכבות

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

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

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

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

הגדרת האסטרטגיה

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

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

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

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

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

בחירת השיטה המתאימה

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

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

    דוגמה: מתאם בין זיהוי מכלל Malware Downloaded (הורדת תוכנה זדונית) לבין זיהוי עוקב מכלל C2 Beaconing Detected (אותות C2 זוהו).

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

    דוגמה: זיהוי אוטומטי של משתמש שהוריד 100GB של נתונים היום, כשבדרך כלל הוא מוריד רק 1GB.

ניהול מכסות של כללים וציוני סיכון

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

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

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

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

הסבר על ההבדל בין סיכון להקשר

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

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

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

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

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

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

שימוש בזיהויים להדמיה

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

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

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

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

דוגמה: מעקב אחרי סיכוני DLP ספציפיים:

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

יצירת זיהויים מורכבים

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

  1. הגדרת תרחיש האיום: הגדרת האיום הספציפי שרוצים לזהות.

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

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

  4. יוצרים את הכלל המורכב: כותבים את הכלל שקולט את הזיהויים מהכללים של הקלט.

    • מגדירים את הקטע events, ומפנים לכללי הקלט לפי השם, המזהה או תווית המטא המשותפת שלהם.

    • מגדירים את הקטע match כדי לציין את מפתח הצירוף ואת חלון הזמן להתאמה.

    • מגדירים את הקטע condition כדי להגדיר את התנאי שצריך להתקיים כדי שההתראה הסופית תופעל.

  5. בדיקה ופריסה של שרשרת הכללים: מומלץ להריץ ידנית בדיקה רטרוספקטיבית לכל כלל ברצף.

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

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

    1. התחלה ידנית של חיפוש רטרו מתוך הכלל הראשון ברצף.

    2. מחכים עד שהיא תסתיים.

    3. ממשיכים לכלל הבא.

דוגמה:


rule CheckCuratedDetection_with_EDR_and_EG {

  meta:
    author = "noone@cymbal.com"

  events:

    $d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
    $d.detection.collection_elements.references.event.network.dns.questions.name = $domain
    $d.detection.collection_elements.references.event.principal.asset.hostname = $hostname

    $e.metadata.log_type = "LIMACHARLIE_EDR"
    $e.metadata.product_event_type = "NETWORK_CONNECTIONS"
    $domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
    $hostname = re.capture($e.principal.hostname, "([^.]*)")

    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 5
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0

  match:
    $hostname over 1h

  outcome:
    $risk_score = 80
    $CL_target = array($domain)

  condition:
    $e and $d and $prevalence

}

צפייה בממצאים של זיהוי מורכב

אפשר לראות תוצאות משולבות של זיהוי בדף זיהויים. התראה היא זיהוי מורכב אם בעמודה Inputs מופיע Detection כמקור, ובעמודה Detection type מופיעה התווית Alert עם מספר לידה (לדוגמה, Alert (3)).

הערה: אם יש לכם גם SIEM וגם SOAR, תוכלו גם לראות את התוצאות בכרטיסייה Cases.

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

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

אופטימיזציה של זמן האחזור

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

שימוש בשיטות יעילות לצירוף זיהויים

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

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

כשמשתמשים ב-nocase עם משתני צירוף בזיהויים מורכבים, יכול להיות שתקבלו את שגיאת הניתוח הסמנטי הבאה:

semantic analysis: match variable <variable_name> is not assigned to an event field.

בזיהויים מורכבים, ההקצאה הראשונה של משתנה (לדוגמה, $username = $fact1...) מגדירה את המאפיינים של המשתנה, כולל אי-תלות באותיות רישיות כשמשתמשים ב-nocase. החלת nocase על הקצאות משתנים עוקבות של אותו משתנה join (לדוגמה, $username = $fact2...) מתפרשת על ידי הקומפיילר כהגדרה מחדש סותרת או כאילוץ מיותר, וכתוצאה מכך מתקבלת שגיאה סמנטית.

שיפור הזיהויים באמצעות ספריית הפונקציות

אפשר להשתמש בספריית הפונקציות של YARA-L בנקודות אסטרטגיות בתוך כלל מורכב כדי להגדיל את האות ולהוסיף לוגיקה מורכבת יותר.

ניהול עדכונים של כללים

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

מגבלות

כשמתכננים ומטמיעים זיהויים מורכבים, חשוב להביא בחשבון את המגבלות הבאות:

  • זמינות של נתוני פניות ב-SOAR: לזיהויים מורכבים אין גישה לכל נתוני הפניות ב-SOAR. לא ניתן להשתמש בלוגיקה של כללים שמנסה לסנן או להחריג מקרים על סמך סטטוס (לדוגמה, $edetection.feedback_summary.status != "CLOSED").

  • כללים מורכבים: ב-Google SecOps יש תמיכה בעומק של עד 10 לכללים מורכבים. עומק הוא מספר הכללים מכלל בסיסי ועד לכלל המורכב הסופי.

  • כללים לזיהוי בלבד: חלון ההתאמה המקסימלי הוא 14 ימים, ויש מגבלה יומית של 10,000 זיהויים לכל כלל.

  • משתני תוצאה: כל כלל מוגבל ל-20 משתני תוצאה לכל היותר. בנוסף, כל משתנה תוצאה שחוזר על עצמו מוגבל ל-25 ערכים.

  • דוגמאות לאירועים: רק 10 דוגמאות לאירועים מאוחסנות לכל משתנה אירוע בכלל, למשל 10 ל-$e1 ו-10 ל-$e2.

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

המאמרים הבאים

מידע על יצירת כללי זיהוי מורכבים זמין במאמרים בנושא כללי זיהוי מורכבים ודוגמאות.

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