Custom Incidents ב-Cortex XDR: איך מכניסים התראות מכל מערכת בעולם לתוך ה-XDR (ולמה זה משנה לכם את החיים ב-SOC)

בואו נתחיל מהתמונה המציאותית של רוב הארגונים בישראל: יש Cortex XDR על תחנות הקצה, ולידו עוד שבע-שמונה מערכות שכל אחת מהן מייצרת התראות משלה. פיירוול, WAF, מערכת מייל, כלי DLP, ולפעמים גם סקריפט פייתון פנימי שמישהו כתב לפני שנתיים ועדיין רץ ב-cron ותופס דברים שאף מוצר מדף לא תופס.

ומה קורה בפועל? האנליסט פותח חמישה טאבים. הוא רואה ב-XDR שמשהו חשוד קרה על תחנה, ואת ההתראה מהפיירוול הוא יראה — אם יראה — עשרים דקות אחר כך, בקונסולה אחרת. אף אחד לא מחבר בין השניים, כי אין דבר כזה "אף אחד", יש בן אדם עייף במשמרת.

כאן נכנס לתמונה מנגנון שנקרא Custom Incidents. הרעיון פשוט להחריד: אם יש לך התראה — מאיזו מערכת שלא תהיה — אתה יכול לדחוף אותה לתוך Cortex XDR דרך API, והיא תתנהג שם כמו התראה מקורית. תופיע בטבלת ה-Incidents, תיכנס לתהליך תחקור, תשב לצד עדויות מתחנות הקצה, ותקבל Severity, סטטוס ובעלים.

לחצו להגדלה

מה הבעיה שזה באמת פותר

התועלת האמיתית היא לא "עוד התראות במקום אחד". זה בונוס. התועלת היא Stitching — התפירה. ברגע שההתראה החיצונית יושבת בתוך ה-XDR, המערכת יכולה לקשור אותה לאותו Host, לאותו משתמש, לאותו IP ולאותו חלון זמן שבו קרו דברים אחרים.

התראה בודדת היא רעש. שתי התראות שמצביעות על אותה תחנה בפרש של ארבע דקות — זה סיפור.

דוגמה מהשטח: הפיירוול חוסם ניסיון יציאה לדומיין חשוד. לבד, זו התראה שאף אחד לא בודק — הפיירוול חסם, הכל טוב, ממשיכים. אבל אם באותה דקה ה-Cortex XDR ראה על אותה תחנה תהליך PowerShell שנפתח מתוך Word, פתאום זה לא חסימה מוצלחת. זה נסיון של Loader לתקשר עם C2, ואתם בדיוק בהתחלה של אירוע.

איך זה עובד מבחינה טכנית

המנגנון עצמו לא מסובך. Cortex XDR חושף REST API, ובתוכו יש קריאה שנקראת Insert Parsed Alerts. אתם שולחים אליה התראות בפורמט שה-XDR מבין, והוא קולט אותן ומציג אותן במערכת.

• ▸הנקודה שאליה שולחים: POST /public_api/v1/alerts/insert_parsed_alerts
• ▸אימות: מפתח API בכותרת Authorization, ומזהה המפתח בכותרת x-xdr-auth-id
• ▸מגבלות שכדאי לזכור: עד 60 התראות בבקשה אחת, ועד 600 התראות בדקה
• ▸ההתראות שנקלטו בהצלחה מוצגות במערכת ומשויכות לאירועים הרלוונטיים
• ▸נדרש רישיון Cortex XDR Pro (per Endpoint או per GB)

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

לחצו להגדלה

מבנה ההתראה — פה נמצא כל הסיפור

הטעות הקלאסית היא לשלוח JSON עם שדה description ארוך ולהסתפק בזה. זה יעבוד. זה גם יהיה חסר תועלת, כי בלי שדות זיהוי — שם מכונה, כתובת IP, משתמש, חתימת זמן — ה-XDR לא יכול לקשור את ההתראה לשום דבר, והיא תישאר שורה בודדת שאף אנליסט לא יסתכל עליה פעמיים.

POST /public_api/v1/alerts/insert_parsed_alerts HTTP/1.1
Host: <your-tenant>.xdr.<region>.paloaltonetworks.com
Content-Type: application/json
Authorization: <API_KEY>
x-xdr-auth-id: <API_KEY_ID>

{
  "request_data": {
    "alerts": [
      {
        "external_id": "netme-fw-000123",
        "alert_name": "Outbound connection to suspicious domain",
        "severity": "high",
        "category": "Command and Control",
        "alert_description": "FortiGate blocked DNS request to known C2 domain",
        "vendor": "NETME-FortiGate",
        "product": "FortiGate",
        "local_ip": "10.20.14.87",
        "local_port": 51244,
        "remote_ip": "185.199.110.153",
        "remote_port": 443,
        "event_timestamp": 1789012345000
      }
    ]
  }
}

כמה כללי אצבע שחוסכים כאב ראש: event_timestamp במילישניות ולא בשניות (הטעות הנפוצה ביותר, וההתראה פשוט נוחתת ב-1970); severity אחיד לפי סקאלה שאתם מגדירים מראש, אחרת כל אינטגרציה תמציא לעצמה מה זה "קריטי"; ו-vendor/product ברורים, כדי שבטבלת האירועים יהיה מובן מאיפה זה הגיע.

לחצו להגדלה

מתי לא כדאי לעשות את זה

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

• ▸התראות אינפורמטיביות בלבד — תשאירו ב-SIEM, לא ב-XDR
• ▸כל התראה שנשלחת צריכה לענות על השאלה: מה אנליסט אמור לעשות איתה
• ▸שמרו על מיפוי severity עקבי בין כל המערכות
• ▸תמיד תעבדו מול סביבת בדיקה לפני שמחברים תהליך אוטומטי לפרודקשן
• ▸עקבו אחרי המגבלה של 600 בדקה — אחרת תתחילו לספוג שגיאות ותאבדו התראות

מה זה אומר עליכם, מקצועית

מי שיודע לחבר מערכות ל-XDR הוא לא "אנליסט שמסתכל על מסך". הוא האדם שבונה את היכולת של הארגון לראות. זה בדיוק ההבדל בין תפקיד SOC Tier 1 לבין תפקיד שמתקדם ל-Tier 2, להנדסת אבטחה ולתפקידי XDR Engineer — ובשוק הישראלי זה הבדל שמרגישים גם בשכר וגם בראיונות.

וכדי להגיע לשם, צריך קודם לשלוט במערכת עצמה: להתקין סוכן, להבין Policies ו-Profiles, לדעת לקרוא Causality Chain, ולחקור אירוע אמיתי עם XQL עד השורש. ה-API הוא השלב שבא אחרי — ולא לפני.

שורה תחתונה: Custom Incidents זה לא פיצ'ר נחמד לאנשי אינטגרציה. זו הדרך להפוך את ה-XDR מכלי שמגן על תחנות קצה לכלי שרואה את כל הארגון. וברגע שהוא רואה הכל — גם אתם רואים.

#CortexXDR #PaloAltoNetworks #XDR #SOC #CustomIncidents #אבטחת_מידע #סייבר #מכללת_נטמי