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

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

המדריך הזה מיועד לצוותי הנדסת זיהוי ו-SOC שרוצים להעביר באופן פרוגרמטי רצפים ריאליסטיים של איומים אל צינור ההזנה בזמן אמת באמצעות סימולציה של אירועים. סימולציית אירועים היא מסגרת להערכת כיסוי של זיהוי ואיומים, שמוטמעת ישירות ב-Google Security Operations. סימולציה של אירועים היא יכולת בסיסית בארכיטקטורה של הסוכן Detection Engineering Agent‏ (DEA). היא מאפשרת לאמת את מחזור החיים של הזיהוי, החל מהטמעה ונורמליזציה של טלמטריה ועד לקורלציה של כמה אירועים והתראות, תוך שמירה על תהליכי עבודה תפעוליים של SOC.

חיבור של כלים של Google SecOps MCP עם עזרה מ-AI (כמו Gemini או Claude Code) מאפשר לבצע סימולציה של אירועים כדי לאוטומט את מחזור החיים של הנדסת הזיהוי: קליטה של דוחות איומים גולמיים, ארגון של טקטיקות איום בהזדמנויות לזיהוי איומים (TDO) שניתנות לפעולה, סינתזה של טלמטריה ריאליסטית של מודל נתונים מאוחד (UDM), הערכה של הכיסוי של כללי YARA-L 2.0 קיימים בכללים של אירוע יחיד, אירועים מרובים וכללים מורכבים, וניסוח של כללי זיהוי חדשים כדי לסגור פערים מזוהים באבטחה.

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

סימולציית אירועים והסוכן Detection Engineering Agent ‏ (DEA) תומכים בתהליכי העבודה הבסיסיים הבאים:

• בדיקות של הטמעה ונורמליזציה של צינורות בזמן אמת: הזרמת טלמטריה סינתטית של Unified Data Model‏ (UDM) באופן פרוגרמטי דרך צינורות הטמעה בזמן אמת, מודולים להעשרת הקשר וגרפים של ישויות, כדי להשיג מוכנות מלאה לזיהוי מקצה לקצה.
• כיסוי מתמשך של איומים ואימות רגרסיה: הערכה של כללי YARA-L 2.0 מנוהלים ומותאמים אישית בהשוואה לטקטיקות, לטכניקות ולנהלים (TTP) ספציפיים של יריבים, הקמת בדיקות יחידה אוטומטיות ובדיקות רגרסיה מתמשכות בכל מערכי הכללים לפני פריסה בסביבת הייצור.
• יצירת טלמטריה סינתטית: יצירת אירועי UDM שתואמים לסכימה ומדמים שרשראות מורכבות של התקפות (כמו ניצול לרעה של אפליקציות אינטרנט, גישה לפרטי כניסה או תנועה לרוחב) כדי לבדוק כללים בסביבות ייצור אמיתיות.

יתרונות מרכזיים והצעת ערך

• אימות יזום של מצב האבטחה ואיומים: בדיקת כללי YARA-L 2.0 מול פגיעויות חדשות והתנהגויות של גורמי איום לפני שמתרחשים אירועים בעולם האמיתי.
• סינתזה ישירה והבטחת הטמעה: סינתזה של אירועי UDM שתואמים לסכימה ישירות מטקסט של מודיעין איומים שעובר דרך צינור ההטמעה של Google SecOps בשידור חי (ImportEvents) כדי לעבור נורמליזציה מלאה, התאמת שדות והעשרת הקשר.
• טלמטריה מבודדת ובטיחות בייצור: אירועים סינתטיים שנוצרים על ידי סימולציית אירועים מתויגים במטא-נתונים של הסימולציה (SIMULATION תוויות הטמעה) ומובילים לזיהויים שתויגו כ-INCLUDES_SIMULATION_DATA. הזיהויים מנתונים מסימולציות לא נכללים אוטומטית במקרים של ייצור, בחוברות הפעלה, במקורות נתונים של ניתוח סיכונים (RBA) ובמרכזי בקרה של תעדוף התראות.

הסבר על המושגים והארכיטקטורה של סימולציית אירועים

הרכיבים הבאים של סימולציית אירועים ושל מסגרת Detection Engineering Agent (DEA) חיוניים לפריסה:

• הזדמנות לזיהוי איומים (TDO): מודל נתונים פורמלי שפועל כבדיקת יחידה ומזהה, מתעדף ומסווג טקטיקות, טכניקות ונהלים (TTP) ספציפיים של יריבים, שחולצו מדוחות מודיעין איומי סייבר או מתיאורים בשפה טבעית. המזהים של TDO צריכים לעמוד בדרישות פורמט מחמירות (לדוגמה, t01, t02, בהתאם לביטוי הרגולרי ^[a-zA-Z]\d{2}$).
• אירועי UDM סינתטיים: אירועים ביומן שנוצרו על ידי מכונה, שעברו עיצוב קפדני לפי סכימת מודל הנתונים המאוחד (UDM) של Google SecOps. האירועים האלה מדמים פעולות ספציפיות של תוקפים שנדרשות כדי לבדוק את הלוגיקה של כללי הזיהוי באמצעות ImportEvents.
• תוויות סימולציה ותיוג התראות: לאירועים סינתטיים יש תווית הטמעה (metadata.ingestion_labels["SIMULATION"]). בפרוטוקול Collection, זיהויים שנובעים מנתונים מסימולציה מסומנים ב-tags עם INCLUDES_SIMULATION_DATA. שדות פרוטו של מטא נתונים של זיהוי כוללים את simulated_event_count (המספר הכולל של אירועים מדומיים שתורמים לזיהוי) ואת simulated_event_names (קבוצת ערכי התווית SIMULATION מאירועים שתורמים לזיהוי).
• חשיפת נתונים והסתרת תוצאות חיפוש: חיפושים רגילים ב-UDM של Google SecOps מסתירים כברירת מחדל אירועים עם התווית simulation. אפשר לכלול באופן מפורש נתונים מסימולציות בשאילתות חיפוש ובתצוגות בממשק המשתמש באמצעות פרמטר ההגדרה simulated_data_visibility או המתג של העדפות המשתמש.
• פעולות ארוכות טווח (LRO): מנגנון הפעלה לא סנכרוני של קצה עורפי (evaluate_rule_coverage_long_running) שמבצע תזמור של קבוצות של הפעלת כללים על פי דרישה, בלי להיתקל בפסק זמן של HTTP API.

לפני שמתחילים

הסימולציה של אירועים חולקת את הדרישות המוקדמות של סביבת הבסיס, הרשאות ה-IAM והגדרת השרת עם ערכת הכלים של Detection Engineering Agent. לפני שמתחילים, צריך לוודא שהתנאים המוקדמים הבאים מתקיימים:

• תפקידים ב-IAM: נדרשים התפקידים Chronicle API Viewer,‏ Chronicle API Editor ו-MCP Tool User.
• הגדרה של שרת MCP ושל מיומנויות: כדי לקבל הנחיות מפורטות להגדרת מטען ייעודי (payload) של שרת MCP‏ settings.json, להגדרת הקשר של סביבת העבודה (Gemini.md) ולהפעלת מיומנויות של Detection Engineering, אפשר לעיין במאמרים שימוש ב-Detection Engineering Agent כדי להעריך את כיסוי האיומים ושימוש בשרת Google SecOps MCP.

איך מוסיפים טלמטריה סינתטית

נתוני טלמטריה סינתטיים מוזרקים ל-Google SecOps באמצעות ערכת הכלים של סוכן MCP או באמצעות קריאות ישירות ל-Chronicle API:

1. הפעלת סוכן משנה של MCP: הפעלת הכלי generate_synthetic_events עם מזהים של הזדמנויות לזיהוי איומים (TDO) ומפרטי התנהגות.
2. נקודת קצה ל-API של Chronicle: אפשר להזרים באופן פרוגרמטי אירועי UDM סינתטיים באמצעות נקודת הקצה של ImportEvents API בארכיטקטורת REST‏ (POST /v1alpha/projects/{project}/locations/{location}/instances/{instance}/events:import).
3. תוויות סימולציה: כשמתקשרים ישירות אל ImportEvents API, המתקשרים צריכים לכלול ידנית את metadata.ingestion_labels שמכיל את המפתח "SIMULATION" ומזהה ייחודי של סימולציה או של הרצת בדיקה כערך במטען הייעודי (payload) של הבקשה (לדוגמה, "key": "SIMULATION", "value": "TEST123" או "t01"). ה-API לא מאכלס אוטומטית תוויות סימולציה.

דוגמה לקריאה להטמעה של UDM

בקשת HTTP:

POST https://chronicle.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/events:import

גוף הבקשה:

{
  "events": [
    {
      "metadata": {
        "event_type": "PROCESS_LAUNCH",
        "event_timestamp": "2026-08-05T20:00:00Z",
        "ingestion_labels": [
          {
            "key": "SIMULATION",
            "value": "TEST123"
          }
        ]
      },
      "principal": {
        "user": {
          "userid": "victim_user"
        }
      },
      "target": {
        "process": {
          "command_line": "powershell.exe -ExecutionPolicy Bypass -File dump.ps1"
        }
      }
    }
  ]
}

סימולציית אירועים מחדירה אירועי UDM מסונתזים ישירות באמצעות ImportEvents, ומעריכה את הנורמליזציה של UDM, העשרת ההקשר וזיהוי הכללים. ניתוח יומנים גולמי נבדק במהלך יצירת אירועים סינתטיים בתוך הכלי Detection Engineering Agent (DEA).

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

הגדרת העדפות משתמשים לנתוני בדיקה סינתטיים

כדי להציג אירועי בדיקה סינתטיים והתראות מסימולציות ב-Google SecOps בממשק המשתמש, ב-API או בכלי MCP, צריך להגדיר את ההרשאות בהתאם לממשק:

מסוף Google SecOps

כדי לראות אירועים סינתטיים בדף SIEM Search או במסופי ממשק המשתמש:

1. בסרגל הניווט במסוף Google SecOps, לוחצים על תמונת הפרופיל ובוחרים באפשרות User preferences (העדפות משתמש).
2. עוברים אל רמת החשיפה של הנתונים.
3. מגדירים את האפשרות הצגת נתוני בדיקה סינתטיים למצב מופעל.
4. לוחצים על Save.

Chronicle API

כששולחים שאילתות API באופן פרוגרמטי, צריך לציין את simulated_data_visibility = "SIMULATED_DATA_INCLUDED" כששולחים שאילתות לנקודות הקצה של UDM Search, כללים או זיהוי באמצעות Chronicle API:

{
  "query": "metadata.event_type = \"USER_LOGIN\"",
  "simulated_data_visibility": "SIMULATED_DATA_INCLUDED"
}

ערכי enum נתמכים של הפרמטר simulated_data_visibility:

• ‫SIMULATED_DATA_EXCLUDED (ברירת מחדל): דיכוי של אירועים והתראות עם התווית 'סימולציה'.
• ‫SIMULATED_DATA_INCLUDED: מחזירה גם נתוני ייצור וגם נתוני בדיקה סינתטיים בתוצאות השאילתה.

שרת Google SecOps MCP

כשמבצעים אינטראקציה עם Google SecOps באמצעות לקוח MCP (לדוגמה, Gemini CLI או AntiGravity), צריך להגדיר את רמת החשיפה של הסימולציה ברמת הדייר בקובץ ההקשר של סביבת העבודה (Gemini.md או settings.json):

כשמשתמשים בשרת ה-MCP של GoogleSecOps, צריך להגדיר את simulated_data_visibility = "SIMULATED_DATA_INCLUDED" לכל החיפושים ב-UDM, להערכת הכללים ולכלי השאילתות לזיהוי.

הערה: בחיפושים רגילים ב-Google SecOps, אירועים עם התווית 'סימולציה' מושבתים כברירת מחדל כדי לשמור על תהליכי עבודה תפעוליים של SOC ולמנוע תוצאות חיוביות שגויות בתורים של אירועי ייצור.

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

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

מערכת או תכונה	טיפול בנתונים סינתטיים	מנגנון בידוד
מאגר של זיהויים והתראות	מבודד ומתויג	ב-proto‏ Collection, זיהויים שנובעים מטלמטריה מדומה מסומנים בקטע tags באמצעות INCLUDES_SIMULATION_DATA וכוללים את שדות ה-proto של מטא-נתוני הזיהוי simulated_event_count ו-simulated_event_names. האות מושבתת בממשקי API רגילים לקריאה ולרשימה, אלא אם מתבצעת בקשה של simulated_data_visibility = "SIMULATED_DATA_INCLUDED".
חיפוש ומרכזי בקרה ב-UDM	מוסתר כברירת מחדל	התוצאות מסוננות אלא אם מציינים את simulated_data_visibility = "SIMULATED_DATA_INCLUDED".
טריאז' של אירועים וכרטיסים	החרגות	מערכת זיהוי האיומים מדלגת על זיהויים עם תגי סימולציה ולא יוצרת מהם כרטיסי תמיכה באופן אוטומטי.
אוטומציה באמצעות Playbook ו-SOAR	החרגות	ספרי הפעלה אוטומטיים של SOAR לא מופעלים בהתראות מסימולציות.
ניתוח סיכונים (RBA)	החרגות	בצינורות (pipelines) של צבירת נתוני סיכון בסטרימינג, אירועים עם תוויות סימולציה מושמטים.
סוכן לחיפוש איומים (THA)	החרגות	שאילתות של מערכי נתונים לחיפוש איומים מדחיקות באופן אוטומטי טלמטריה עם תוויות של סימולציה.

יכולות של חבילת כלים אגנטית

סימולציית האירועים מתבססת על היכולות של כלי הסוכן המשני שנחשפות על ידי שרת ה-MCP של Google SecOps. למידע מפורט על הכלים הזמינים של הסוכן המשני (כולל generate_threat_detection_opportunity,‏ generate_synthetic_events,‏ evaluate_rule_coverage_long_running,‏ get_operation,‏ generate_rules ו-create_rule), על קלט המפתח ועל סכימות הפלט, אפשר לעיין במאמר שימוש בסוכן Detection Engineering Agent להערכת כיסוי האיומים.

הסבר על מחזור החיים ועל תהליך העבודה של הנדסת זיהוי

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

1. עיבוד של נתוני מודיעין איומים והעברה שלהם ל-Google SecOps: העברת טקסט גולמי של מודיעין איומים אל generate_threat_detection_opportunity כדי לחלץ ממנו נתונים מובנים של TDO (לדוגמה, t01,‏ t02), להחיל שינוי של חותמות הזמן לפני ההעברה ולהפעיל את generate_synthetic_events כדי להזרים יומנים של UDM עם התווית SIMULATION דרך צינור ההעברה של Google SecOps (ImportEvents).
2. הערכת כיסוי אסינכרונית: מריצים את הפקודה evaluate_rule_coverage_long_running כדי להעריך את כיסוי הכללים של YARA-L 2.0 בטלמטריה סינתטית, ומבצעים סקר get_operation עד להשלמה כדי לאחזר את מטריצת ההתאמה של הכללים.
3. תיקון פערים וניהול מחזור החיים של הכללים: אפשר להתקשר אל generate_rules כדי ליצור טיוטות מאומתות של כללי YARA-L 2.0 לכל TDO שלא נכלל, ולפרוס כללים שנבדקו בסביבת הייצור באמצעות create_rule.

כדי לקבל מידע מפורט על מטען ייעודי (payload) של הפעלת כלי ודוגמאות קוד מלאות בכל שלב במחזור החיים של הזיהוי, אפשר לעיין במאמר שימוש ב-Detection Engineering Agent להערכת כיסוי האיומים.

פתרון בעיות

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

שאלה: למה אירועי UDM סינתטיים לא מופיעים בחיפוש UDM רגיל?

כברירת מחדל, חיפושים רגילים ב-Google SecOps UDM מסתירים אירועים עם התווית SIMULATION ingestion כדי לשמור על היגיינה תפעולית של SOC. כדי לראות אירועים סינתטיים בחיפוש UDM או במסופי ממשק המשתמש, צריך לוודא שהאפשרות הצגת נתוני בדיקה סינתטיים מופעלת בהעדפות המשתמש, או להגדיר את simulated_data_visibility = "SIMULATED_DATA_INCLUDED" בבקשת השאילתה.

ש: איך מונעים מהתראות על זיהויים מנתונים מדומיים להגיע לניתוח SOC?

כשכלל מופעל על אירועים סינתטיים, קומפיילר הקצה העורפי מתייג את הזיהוי שמתקבל בסימן INCLUDES_SIMULATION_DATA. כברירת מחדל, זיהויים עם התג הזה לא נכללים במקרים של הפקה, ב-Playbooks, ב-Risk Analytics (RBA) ובמרכזי בקרה של סיווג התראות.

ש: למה evaluate_rule_coverage_long_running לא מצא התאמות לאירועים הסינתטיים שלי?

מוודאים שחותמות הזמן של האירועים הסינתטיים נמצאות בתוך חלון הביצוע המתגלגל של שעה אחת ([StartTime - 1 hour, StartTime]). מוודאים שמזהי ה-TDO תואמים לביטוי הרגולרי הנדרש (^[a-zA-Z]\d{2}$, לדוגמה, t01).

שאלה: איך צריך לטפל באינדיקטורים אטומיים (כתובות IP, שמות דומיינים, גיבוב קבצים) לעומת כללים התנהגותיים?

מומלץ לנהל אינדיקטורים אטומיים באמצעות התכונה 'התאמת IOC' ב-Google SecOps או באמצעות טבלאות נתונים, ולא באמצעות קידוד קשיח של כתובות IP סטטיות או ערכי גיבוב ישירות לכללי זיהוי ב-YARA-L 2.0. מומלץ להשתמש ב-YARA-L 2.0 לתבניות התנהגותיות ולמתאם TTP.

שאלה: מהו גודל האצווה המקסימלי עבור קריאות להערכת כיסוי של TDO?

כדי לשפר את הביצועים ולעמוד בדרישות הפרמטרים של API Gateway, בקשות להערכת כיסוי של קבוצות מוגבלות למקסימום של שלושה TDO או 40 אירועים סינתטיים לכל evaluate_rule_coverage_long_running קריאה.

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