בעולם האבטחה של היום מרכזי SOC אינם סובלים ממחסור בכלים אלא ממחסור ברציפות תפעולית. אנליסט ממוצע מתחיל חקירת malware בתוך פורטל דפנדר, ואז נאלץ לקפוץ בין תצוגת האירועים, טבלאות Advanced Hunting, שאילתות KQL ידניות, כלי enrichment חיצוניים ולבסוף פעולות תגובה.
כל מעבר כזה שובר את שרשרת ההקשר כי אירוע malware בודד עשוי להתחיל כ SecurityIncident, לדרוש חילוץ ישויות מתוך SecurityAlert, להמשיך לשאילתות על DeviceProcessEvents ו DeviceFileEvents ב data lake, ולהסתיים בהחלטה על בידוד endpoint. החיכוך הזה מאריך את זמן התגובה, מגביר שחיקה אנליסטים ומגדיל את הסיכון להחמצת ראיות קריטיות.
כדי לבחון בפועל איך נראה SOC אגנטי, צריך להבין שישנו צורך בסוכן נייד שמופעל בפרומפט אחד ומלווה את האירוע מהחקירה הראשונית דרך קורלציית ראיות ועד לסיווג ולפעולה תגובה (מיטגיציה) מבוקרת. המטרה אינה אוטומציה עיוורת אלא מחזור חיים שלם שעובר מ Investigate ל Decide ל Act בתוך אותה סביבה מאוחדת של דפנדר (עם Microsoft Sentinel). הסוכן פועל כ agentic workflow דטרמיניסטי כאשר הוא מקבל מטרה, מתכנן את הצעדים, מבצע שאילתות ממוקדות, מעריך ראיות ומחזיר תוצאה מוסברת.
טיפ: התחילו תמיד מפרומפט שמכיל את מזהה האירוע המדויק, לדוגמה: חקור את אירוע Defender 1939 כולל קורלציה מלאה של process tree, כך הסוכן נמנע מהרחבה מיותרת של היקף החקירה.
פערים בשטח
בחקירה קונבנציונלית האנליסט מבזבז חלק ניכר מזמנו על חיבור חלקי תהליך שאינם מדברים זה עם זה באופן טבעי. למשל, הוא שולף את מבנה האירוע מטבלת SecurityIncident, מחלץ ישויות מתוך SecurityAlert, כותב שאילתות קוסטו ממוקדות על DeviceNetworkEvents או DeviceFileEvents, בודק prevalence והקשר ארגוני, ואז חוזר ידנית לפורטל כדי להוסיף הערה או לתייג.
כל שלב כזה דורש החלפת הקשר מנטלית ובמצבים כאלה התוצאה היא MTTR גבוה יותר, איכות חקירה לא אחידה בין אנליסטים, וחוסר יכולת לשחזר בדיוק את אותו תהליך בסביבה אחרת. הפיצול הזה הוא בדיוק מה שהמעבר של Sentinel לתוך פורטל דפנדר נועד לצמצם, והסוכן מדגים איך אפשר לנצל את האחדות הזו בצורה מבצעית.
מהיבט תחקור, הבעיה מתבטאת גם באובדן ראיות. כאשר האנליסט עובר ידנית בין כלים הוא עלול לפספס קשר בין process parent ל child או בין קובץ לכתובת IP חיצונית. סוכן אגנטי שומר על רציפות ההקשר ומבצע entity pivoting אוטומטי.
דוגמה מהשטח: באירוע malware קלאסי האנליסט רואה התראה על קובץ חשוד. בלי סוכן הוא צריך לכתוב ידנית שאילתה על DeviceFileEvents ואז על DeviceProcessEvents אבל הסוכן עושה את שני הצעדים ברצף ומחזיר עץ תהליכים מלא. אפשר לומר שכתיבת מבוססת join יכולה לקצר את התהליך הידני אבל ישנם מצבים שלא כך הדבר.
טיפ: כדאי להגדיר מראש אילו טבלאות Device* הן קריטיות וכך ניתן לכוון את הסוכן להעדיף אותן ולהפחית עלויות שאילתה.
הסוכן הנייד
הסוכן אינו מסתפק ב enrichment או בסיכום והוא מבצע חקירת malware מקצה לקצה, מפיק סיווגים מבוססי ראיות בלבד, מייצר סיכום סטנדרטי שמוכן לסקירת אנליסט, ומאפשר פעולות תגובה אופציונליות תחת בקרה אנושית. מכיוון שהוא מוגדר כסוכן נייד, אותה לוגיקה ניתנת להעברה בין workspaces שונים בלי לשכתב את הקוד. הוא מתבסס על Microsoft Sentinel MCP server, שחושף כלי Triage ו Data Lake exploration, ועל נתוני Defender for Endpoint שכבר זמינים באותו פורטל.
מהיבט agentic הסוכן פועל כמערכת מטרה מונחית ובמצב כזה הוא מקבל את המטרה לחקור אירוע, מפרק אותה לשלבים, מבצע כל שלב עם כלי MCP מתאים, מעריך את התוצאה ומחליט על הצעד הבא. זה בדיוק ההבדל בין playbook קשיח לבין agent אגנטי.
– קלט משתמש: "חקור אירוע 1939"
– הסוכן שולף SecurityIncident ו-SecurityAlert
– מחלץ ישויות Device, User, File, IP
– מריץ שאילתות ממוקדות ב-data lake
– מבצע קורלציה
– מפיק סיווג
– מציע פעולות
טיפ: שמרו את הלוגיקה של הסוכן כקובץ skills נפרד בתוך ה repository וכך תוכלו לעדכן את שלבי החקירה בלי לגעת בקוד הראשי של ה MCP.
דרישות מקדימות ודרכי פעולה
כדי שהסוכן יפעל נדרשים מספר רכיבים, כמו VS Code עם GitHub Copilot שמספק את סביבת העבודה שבה הסוכן רץ. Microsoft Sentinel MCP server שמספק את כלי החקירה והגישה ל data lake. נתוני Microsoft Defender for Endpoint חייבים להיות זמינים, במיוחד טבלאות DeviceProcessEvents, DeviceFileEvents ו DeviceNetworkEvents. לפעולות תגובה נדרשות הרשאות API מתאימות, כגון אפשרות לבודד endpoint.
התהליך מתחיל בפרומפט בשפה טבעית, למשל תחקור את אירוע Defender מספר 1939. הסוכן מזהה את מזהה האירוע, ובמידת הצורך שואל על workspace ספציפי של Sentinel. אם לא צוין workspace הוא מנסה לזהות אוטומטית את הזמינים. כאשר קיים workspace יחיד הוא משתמש בו. כאשר יש כמה הוא מבקש מהמשתמש לבחור. אם חסרות הרשאות הוא עובר למצב קריאה בלבד.
דוגמה ללוגיקת portability:
– אם סופק workspace השתמש בו.
– אם לא סופק וקיים workspace יחיד השתמש בו אוטומטית.
– אם קיימים כמה שאל את המשתמש.
– אם חסרות הרשאות עבור למצב read-only ודווח על כך.
השלב הראשון הוא חקירה שמתחילה בפורטל דפנדר. הסוכן שולף את רשומת ה SecurityIncident, את ההתראות המקושרות מטבלת SecurityAlert, את רמת החומרה, את ציר הזמן ואת הקשרים בין ההתראות. גישה זו מבטיחה מישור נתונים עקבי ומפחיתה תלות בקריאות API מרובות ומנותקות.
טיפ לתחקור: בקשו מהסוכן תמיד להחזיר גם את ה AlertId ואת ה Timestamp המדויקים כי זה מאפשר לאנליסט לקפוץ ישירות לתצוגת האירוע בפורטל לצורך אימות ידני.
לאחר מכן מתבצעת קורלציה מונעת ישויות. במקום להריץ שאילתות רחבות על כל הסביבה, הסוכן מצמצם את ההיקף לישויות שכבר זוהו באירוע: מכשיר, משתמש, קובץ או כתובת IP. הוא מריץ שאילתות ממוקדות בלבד על הטבלאות הרלוונטיות. גישה זו משפרת ביצועים, מורידה עלויות שאילתה ומגדילה דיוק, כי היא נמנעת מנפח נתונים מיותר.
דוגמה לשאילתה ממוקדת שהסוכן מבצע מאחורי הקלעים:
חיפוש ב DeviceProcessEvents לפי DeviceId ו FileName, ואז הצטרפות ל DeviceFileEvents לפי SHA256 כדי לבדוק את מקור ההורדה.
טיפ: הגבילו את חלון הזמן של השאילתות לפרקי זמן קצרים, למשלעד 48 שעות סביב האירוע. זה מפחית משמעותית את נפח הנתונים ומאיץ את התגובה.
בשלב הבא הראיות עוברות קורלציה והסוכן מפיק אחד משלושה סיווגים מפורשים: True Positive, False Positive או Benign True Positive. הוורדיקט מבוסס אך ורק על הראיות שנאספו, ללא ניחושים או היוריסטיקות רופפות. הפלט הסופי מעוצב באופן סטנדרטי. הוא כולל שורת וורדיקט אחד, טבלת ממצאים מפורטת, סיכום קצר לאנליסט, רשימת פעולות שבוצעו והמלצה אופציונלית להכלה.דוגמה לפלט סטנדרטי:
– וורדיקטן: True Positive
– קטגוריה | ממצאים
– פרטי אירוע | חומרה גבוהה
– פרטי malware | זוהה Trojan X
– מצב מכשיר | הגנה בזמן אמת פעילה
– הקשר משתמש | משתמש סטנדרטי
– פעילות שנצפתה | עץ תהליכים חשוד
– המלצה | מומלץ בידוד
כאשר קיימות הרשאות, הסוכן יכול להוסיף הערה לאירוע, לתייג אותו, לעדכן סיווג, לסגור אותו או לבצע בידוד endpoint. כל פעולה כזו מתבצעת עם בקרת אדם בלולאה, אימות הרשאות מפורש ומעקב ביקורת מלא.במצב כזה, הסוכן אינו שומר מידע רגיש כמו מפתחות או סיקרטים והוא משתמש בהקשר האימות הקיים ומדווח בבירור כאשר הרשאה חסרה.
טיפ: הגדירו מראש אילו פעולות דורשות אישור אנושי מפורש. בידוד endpoint תמיד צריך להיות מאחורי human-in-the-loop, בעוד הוספת תג יכולה להיות אוטומטית.
למה הדפוס הזה חשוב למעבר ל SOC אגנטי?
הסוכן מדגים שלושה עקרונות מרכזיים. הראשון הוא ביצוע דטרמיניסטי. אותו workflow מפיק תוצאות חוזרות ועומק חקירה עקבי בכל הרצה. השני הוא שליטה אנושית. האנליסט נשאר האחראי על החלטות בעלות השפעה גבוהה, והסוכן מספק הסבר ברור לכל שלב. השלישי הוא סגירה מקצה לקצה. רוב האוטומציה הקיימת ב-SOC עוצרת ב playbook או ב enrichment. כאן מתקבל מחזור חיים שלם שמתחיל באות ומסתיים בהחלטה ובפעולה מבוקרת.
מהיבט תחקור, הדפוס מאפשר לשחזר את כל שרשרת הראיות. כל שאילתה, כל ישות וכל מסקנה מתועדים, כך שאפשר לבצע post-incident review מדויק.
דוגמה להרחבה עתידית יכולה להיות שאותו סוכן יכול לקבל פרומפט כמו "חקור אירוע זהות 4567" ולעבור אוטומטית לטבלאות identity ולשאילתות על SigninLogs במקום על Device*.
טיפ: התחילו עם סוכן malware אחד בסביבת lab. מדדו כמה זמן נחסך בכל חקירה, ואז הרחיבו בהדרגה לסוכנים נוספים.
הדפוס ניתן להרחבה ואפשר ליישם אותו על חקירות זהות, סיכונים פנימיים, קורלציה בין ספקי ענן שונים או סוכנים נוספים כמו זה של Security Copilot, כאשר היעד הוא SOC אגנטי, סוכני חקירה ניידים מהסוג הזה הם נקודת התחלה מעשית שכבר היום ניתנת ליישום בתוך הסביבה המאוחדת של Defender ו Sentinel. הקוד המלא, הוראות ההתקנה והדוגמאות זמינים ב-GitHub תחת SOC Malware Investigator Portable. מומלץ גם לעיין בתיעוד של Microsoft Sentinel MCP server ובתיעוד data lake של Sentinel כדי להבין את התשתית שעליה הסוכן נשען.
לסיכום
ב SOC מודרני לא חסר כלים רגילים הוא הוא חסר רציפות וכלים מתקדמים. אנליסט שמתחיל חקירת malware בפורטל Defender קופץ בין מסכים, שאילתות ופעולות, ומאבד הקשר בדרך. הסוכן פותר את זה עם פרומפט אחד, והוא עובר את כל המחזור של שליפת האירוע, מחלץ ישויות, מריץ שאילתות ממוקדות בלבד, ומגיע לוורדיקט ברור של True Positive, False Positive או Benign True Positive. הכל מבוסס ראיות, בלי ציד רחב ובלי ניחושים והזיות מיותרות. משם, פעולות כמו בידוד endpoint נשארות תחת אישור האנליסט.
זה צעד ממשי לכיוון SOC אגנטי.
קישורים נוספים
תחקור עם SOC Malware Investigator
