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

נתמך ב:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • שיפור הדיוק של הזיהוי: שילוב תובנות מאירועים של מודל נתונים מאוחד (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. "קובץ דרופר" יורד ומופעל (אירוע התהליך הראשון).

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

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

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

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

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

  • לדוגמה:

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

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

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

איך פועלים זיהויים משולבים

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

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

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

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

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

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

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

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

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

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

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

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

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

    דוגמה: קישור בין זיהוי מכלל של הורדת תוכנה זדונית לבין זיהוי עוקב מכלל של זיהוי איתות C2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


rule Basic_Rule_Correlation_Template {
    
    meta:
    description = "Triggers when a user triggers two different rules within X days"

    events: 
    // 1. Identify the first sub-rule detection
    $d1.metadata.event_type = "DETECTION" $d1.metadata.rule_name = "INSERT_RULE_NAME_A_HERE" $user = [REDACTED_GENERIC_ID]

    // 2. Identify the second sub-rule detection
    $d2.metadata.event_type = "DETECTION"
    $d2.metadata.rule_name = "INSERT_RULE_NAME_B_HERE"
    $user = [REDACTED_GENERIC_ID]
    match: 
    // 3. Connect the rules by the same user over the specified window
    $user over 14d
    condition: 
    // 4. Fire when both conditions have occurred
    $d1 and $d2
}

דוגמה: הכלל הבא בודק גילויים מוכנים מראש באמצעות כלל לזיהוי אירועים ותרשים אירועים, ומשתמש בכמה פונקציות מתקדמות של YARA-L ובהגדרות של משתנים:


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

}

הצגת ממצאים של זיהוי משולב

אפשר לראות את תוצאות הזיהוי המשולבות בדף Detections. התראה היא זיהוי משולב אם בעמודה 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 על הקצאות משתנים עוקבות של אותו משתנה איחוד (לדוגמה, $username = $fact2...), הקומפיילר מפרש את זה כהגדרה מחדש סותרת או כאילוץ מיותר, וכתוצאה מכך מתקבלת השגיאה הסמנטית.

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

במאמרים כללי זיהוי משולבים ודוגמאות מוסבר איך ליצור כללי זיהוי משולבים.

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