שימוש בסוכן Detection Engineering Agent כדי להעריך את הכיסוי של האיומים

שימוש בסוכן Detection Engineering Agent כדי להעריך את הכיסוי של האיומים

‫Detection Engineering Agent הוא עוזר הנדסי מבוסס-AI שמוטמע ב-Google Security Operations. הוא מעריך ומעדכן את מצב האבטחה של Google SecOps בהתאם לאיומים חדשים וקיימים. הגישה לסוכן הזה מתבצעת קודם באמצעות כלי MCP, שמופעלים על ידי לקוחות AI (לדוגמה, AntiGravity או Claude Code).

מושגים

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

תפקידי משתמשים

לכל חשבון משתמש שמבצע קריאה ל-Detection Engineering Agent צריכים להיות התפקידים הבאים: MCP Tool User ו-Chronicle API Viewer. חשוב לוודא שאדמין מערכת מעדכן את התפקידים האלה לכל המשתמשים העיקריים של סוכן הנדסת הזיהוי. טיפ: הנחיות נוספות זמינות במסמכי התיעוד של Google SecOps MCP.

הגדרת שרת ה-MCP

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

{
  "name": "my_extension_name",
  "version": "1.0.0",
  "mcpServers": {
    "GoogleSecOps": {
      "httpUrl": "https://chronicle.us.rep.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": [
          "https://www.googleapis.com/auth/cloud-platform",
          "https://www.googleapis.com/auth/chronicle"
        ]
      },
      "timeout": 300000,
      "headers": {
        "x-goog-user-project": "my-cloud-project-name"
      }
    }
  }
}

הגדרת ההקשר

כדי להתחיל, צריך להגדיר הקשר. כדי לשמור על קובץ קל משקל, מומלץ להתחיל עם התוכן הבא בקובץ Gemini.md ואז להוסיף לו. מעדכנים את המידע הנכון לגבי מכונת Google SecOps והסביבה שלכם:

When using the GoogleSecOps MCP Server, use these parameters for EVERY request: Customer ID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa Region: us Project ID: my-cloud-project-name

הגדרת המיומנות

מומלץ מאוד להשתמש במיומנות detection-engineering-coverage-evaluation כדי ליצור אינטראקציה עם הכלים. ‫Gemini אוהב לקצר תהליכים (לדוגמה, סיכום של פלט כלי) שמובילים לתוצאות שליליות בביצוע איטרטיבי.

המיומנות הזו מובנית עכשיו כ-detection-engineering-coverage-evaluation והיא מתארחת באופן ציבורי במאגר Google Agent Skills GitHub.

תכונות עיקריות

הסוכן Detection Engineering מספק כמה יכולות מרכזיות לניתוח איומים וליצירת כללים.

יצירת הזדמנויות לזיהוי איומים

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

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

יצירת אירועים סינתטיים

יוצר יומנים של מודל נתוני משתמשים (UDM) שמדמים קלט TDO. אנחנו ממליצים מאוד להשתמש במיומנות detection-engineering-coverage-evaluation כדי ליצור אינטראקציה עם המערכת, מהסיבה הבאה: יכול להיות ש-Gemini ינסה לצמצם את ה-TDO בצורה מוגזמת לפני שישלח אותו כקלט לכלי הזה. יכול להיות שתתקבל רשימה מקוצרת של סוגי יומנים שמשויכים ל-TDO, ויכול להיות שייבחרו סוגי יומנים שאין להם מנתחי נתונים זמינים במופע Google SecOps שלכם. בנוסף, אם הכלי הזה נכשל שוב ושוב, כדאי לבדוק את ה-TDO שסיפקתם ולוודא שיש בסביבה שלכם מנתח לפחות לאחד מ-TDO של הקלט. אם לא, יכול להיות שהמערכת לא תספק כיסוי ל-TDO הספציפי הזה, לפי ההערכה של המערכת. ממשיכים את התהליך עם הפלט של כלי TDO אחר שנוצר על ידי הכלי הראשון.

הערכת הכיסוי

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

יצירת כללים

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

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