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

נתמך ב:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • דוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • לדוגמה:

    1. משתמש נכנס לאתר זדוני (אירוע רשת ראשוני).

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

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

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

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

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

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

  • לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמה: זיהוי ראשוני יכול להתריע על סיכון פוטנציאלי, כמו קריאת 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.

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

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

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

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

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

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

לדוגמה, אם לכמה כללים יש את אותה תווית מטא 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.