מדוע AI SOAR נתקע בלי תרחישים מתועדים
אוטומציה של תגובה נתקעת לרוב לא בגלל איכות המודל, אלא בגלל היעדר תיאור פורמלי של מה שהמשמרת עושה בידיים. הפלטפורמה פרוסה, מקורות האירועים מחוברים, אבל שיעור התקריות שנסגרות בלי אדם נשאר נמוך.
האנליסט עדיין פותח התראה, נכנס לקונסולה, משווה כתובות, מעתיק מזהים — וכל הזמן הזה זרם האירועים גדל מהר יותר ממה שהמשמרת מספיקה לפרק תקריות.
הסיבה היא שתרחישי תגובה מתארים «באופן כללי», ולא כרצף של תנאים ניתנים לבדיקה. אם לא נקבע מאיזה מקור מגיע האירוע, אילו שדות נחשבים לסימן הפעלה, במה מקרה אחד שונה ממקרה דומה — האוטומציה לא יכולה לקבל החלטה ועוברת לענף «להעביר לאדם».
שני אנליסטים באותה סיטואציה פועלים אחרת — כלומר אין תרחיש ניתן לשחזור, ואין על מה לאמן על נתונים כאלה.
תרחיש עבודה נראה אחרת: הטריגר קשור למקור ספציפי בזרם האירועים, מוגדרים תנאי העשרה, רשימת הפעולות המותרות וקריטריון שלפיו המקרה נחשב סגור. אז האוטומציה של התגובה סוגרת מקרים טיפוסיים במלואם, והמשמרת התורנית מתחברת רק בנקודות ההחלטה — שם שצריך בחירה, לא שגרה. נפרק איך זה נסגר בפועל.
האפקט של האוטומציה: מהירות תגובה ועומס על המשמרת
האפקט של האוטומציה נמדד לא במספר התרחישים, אלא בשלושה גדלים: הזמן עד לפעולה הראשונה בתקרית, שיעור השגרה שירד מהאנליסט, ונפח הרעש שבכלל לא מגיע למשמרת. לפני האוטומציה, אות שהגיע בסוף המשמרת חיכה לניתוח עד הבוקר — זמן התגובה נמתח לשעות, וההקשר של האירוע אבד חלקית עד רגע הניתוח.
תרחיש תגובה מפרק את האירוע בשניות: מעשיר אותו בנתונים על הנכס, משווה להיסטוריה, מסנן מראש התראות שווא ומבצע את פעולת הבלימה הראשונה — חסימת חשבון או בידוד צומת. האנליסט מקבל תמונה מורכבת במקום זרם גולמי, והזמן עד לפעולה הראשונה יורד מעשרות דקות ליחידות.
פלטפורמות מסוג Cortex XSOAR מריצות תרחישים כאלה כמערכי צעדים ניתנים לשחזור — אפשר לנהל גרסאות ולבצע חזרה לאחור.
פעולות שגרתיות — ייצוא לוגים, השוואת כתובות ו-hashes, שאילתה ל-sandbox, פתיחת כרטיס — עוברות לאוטומציה במלואן. במשמרת נשארות ההחלטות שדורשות הקשר וסמכות: בערך שתיים-שלוש פעולות מתוך חמש מפסיקות לתפוס ידיים, והעומס על האנליסט בשעות שיא מתאזן.
בנפרד יורד סוג של כשלים הקשור להתראות שווא. כלל שמופעל לפי סימן אחד מוחלף בבדיקת התאמה של כמה תנאים, וכללים רועשים מורדים בסדר העדיפויות במקום ניתוח ידני. התור מפסיק לגדול לקראת סוף המשמרת, ומסירת המשמרת מתבצעת ממצב יציב, ולא בירושה של הפעלות שלא טופלו.
AI SOAR: אפשרויות פריסה והמגבלות שלהן
פריסה של קו אוטומציה רק לעתים רחוקות מסתכמת בהתקנה של מוצר אחד. הבחירה היא בין שירות מנוהל אצל הספק, פלטפורמה בתוך ההיקף, הרחבה של קו מתאר קיים והיברידי.
ההבדל מתגלה לא במערכת הפונקציות, אלא היכן נשמרים נתוני התקריות, מי אחראי לאינטגרציה עם מערכות ההגנה וכמה מהר מתוקן תרחיש התגובה.
להלן — האלטרנטיבות כפי שאנחנו רואים אותן בפרויקטים: לפי התאמה, לוחות זמנים להפעלה ולפי המגבלות שיהיה צריך לקבל במודע.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שירות מנוהל אצל הספק | צריך קו אוטומציה מהר, הצוות קטן, הוצאת נתוני אירועים מההיקף מותרת | חלק מנתוני התקריות יוצא החוצה; תיקון תרחישים מוגבל ליכולות הפלטפורמה |
| פלטפורמה בתוך ההיקף | איסור על הוצאת נתונים, דרישות רגולטור, זרם אירועים צפוי | נדרשת תשתית ותמיכה עצמאיות; כל מקור הגנה מתחבר בנפרד |
| הרחבה של קו המתאר הקיים | כבר פועלים איסוף אירועים וחלק מתרחישי האוטומציה | המגבלות הארכיטקטוניות עוברות בירושה: צווארי בקבוק בהחלפת נתונים עוברים לשכבה החדשה |
| היברידי: אורקסטרציה בפנים, אנליטיקה בחוץ | נדרש שליטה על הפעולות בתשתית ואנליטיקה חיצונית על נתונים אנונימיים | מורכב יותר לתמיכה: שני קווי מתאר, שני מודלים להפרדת הרשאות, סנכרון כללים |
ההחלטה נקבעת לפי המגבלות, ולא לפי החוזקות: שירות מנוהל נתקל בדרישות לאחסון נתונים, פלטפורמה בתוך ההיקף — בהיקף התמיכה, הרחבה של קו המתאר הקיים — באיכות האינטגרציות הקיימות. לכן את הניתוח מתחילים מהלַנדסקייפ ההגנה שלכם, ורק אחר כך מציעים אפשרות פריסה.
שלבי היישום: מביקורת תהליכים ועד מסירה לתפעול
אוטומציה מוצדקת במקום שבו הפעולות חוזרות על עצמן ומקורות האירועים ברורים. לכן AI SOAR מתחיל בביקורת תהליכים: בלי לתעד אילו התראות המשמרת מפרקת בידיים וכמה צעדים כל אחת דורשת, האוטומציה תקבע את אי-הסדר הקיים. להלן — סדר העבודות שאנחנו עוברים בפרויקט.
- ביקורת תהליכים. אוספים את מקורות האירועים ואת הפעולות הידניות הנוכחיות: איך מגיעות ההתראות, איך מסווגות, היכן הזמן הולך לאיבוד. בפלט — מפת זרימות ורשימת פעולות שמתאימות לאוטומציה.
- תכנון התגובות. לכל סוג תקרית מתארים ענף: העשרה בנתונים, בידוד צומת, חסימת חשבון, התראה לאחראי. מתאמים גבולות — היכן ההחלטה מתקבלת על ידי המערכת והיכן חובה בדיקה ידנית.
- קו בדיקות. פורסים סביבה מבודדת עם נתונים אנונימיים, שמשחזרת את הטופולוגיה העובדת: תקלה בתרחיש לא עוברת לסביבת העבודה, וחזרה לאחור לוקחת דקות.
- הגדרת תרחישים. מחברים מקורות אירועים, מגדירים כללי קורלציה וספי הפעלה, מרכיבים ענפי טיפול. התראות שווא מסננים בשלב הניתוח, ולא במשמרת.
- בדיקה על תקריות אמיתיות. מריצים את התרחישים על יומנים היסטוריים ועל הזרם החי, סופרים את שיעור ההתראות שנסגרות בלי אדם ואת זמן התגובה. פערים שנמצאו סוגרים לפני המסירה.
- הדרכה ומסירה לתפעול. מוסרים נהלים והוראות למקרים לא טיפוסיים, מאמנים את המשמרת על קו הבדיקות. אחר כך — תמיכה ושיפור תרחישים לפי הסטטיסטיקה שנצברה.
מה אנחנו מוסרים: תצורות, תרחישים, נהלים ותיעוד
קו האוטומציה של SOC חי בתפעול, לא בהדגמה: מהנדס תורן צריך להבין מאיפה הגיע האירוע, למה התרחיש עבד דווקא כך ומה לעשות אם הוא לא הופעל. לכן אנחנו מוסרים לא רק מערכת עובדת, אלא ערכה שאיתה אפשר להוביל אותה הלאה בלי ההשתתפות שלנו.
- תצורות — ייצוא של כללי קורלציה, ניתוב ותעדוף אירועים עם הערות: רואים איזה כלל אחראי למה ומה ישתנה כשמכבים אותו.
- סכמות אינטגרציה — מפה של מקורות אירועים ומערכות חיצוניות: אילו פרוטוקולים בשימוש, היכן נשמרים פרטי הגישה, אילו חזרות מוגדרות כשלגישה למקור אין מענה.
- נהלים למשמרת — הוראות שלב-אחר-שלב למצבים טיפוסיים: מיון ראשוני, אסקלציה, בידוד צומת, סגירת תקרית, פעולות בהתראת שווא.
- תרחישי תגובה — אוטומציות עם ציון טריגרים, תנאים וגבולות: מה המערכת עושה בעצמה והיכן חובה בדיקה של אדם.
- מדיניות גישה — מטריצת תפקידים: מי רואה אירועים, מי משנה כללים, מי מאשר פעולות אוטומטיות, איך מוענקות ומבוטלות הרשאות.
- תיעוד — תיאור הארכיטקטורה, זרימות הנתונים, נקודות הכשל וסדר עדכון הרכיבים.
- נוהל בדיקה — מערכת אירועי בדיקה שבהם המשמרת מאשרת את תקינות התרחישים לאחר שינויים, והקריטריונים שבהם עדכון מוחזר לאחור.
- יומן שינויים — היסטוריית עריכות הכללים עם מחבר וסיבה: ניתוח תקרית נשען על עובדות, לא על זיכרון.
קייס: איך קיצרנו את זמן התגובה של המשמרת התורנית
לפני היישום: התורן כצוואר בקבוק
בתחילת קייס היישום קיבלה המשמרת כ-4,000 הפעלות ביממה מ-SIEM — ברמות מהימנות שונות ובלי תעדוף משותף. האנליסט השווה ידנית בין האירוע לנכסים, הרים הקשר מדואר ומהודעות, והמיון הראשוני ארך 35–45 דקות, ובשעות הלילה התור פשוט חיכה לבוקר. מסירת המשמרת נשענה על סיכום בצ'אט: ההקשר אבד, ולעיתים תקרית אחת נותחה פעמיים.
מה שינו
הרכבנו ספרייה של תרחישי תגובה על טקסונומיה משותפת של טקטיקות MITRE ATT&CK: סיווג האירוע, העשרה אוטומטית בנתונים על הנכס ועל החשבון, בידוד ה-host וחסימת החשבון לפי ספים שהוסכמו מראש. ההעשרה מתבצעת במקביל — בזמן שהאנליסט פותח כרטיס, ההקשר כבר נאסף.
כל פעולה של האוטומט נכתבת ליומן עם ציון התרחיש ונתוני הקלט, ולכן ניתוח תקרית לא הופך לארכיאולוגיה. מסירת המשמרת עברה ל-checklist: תקריות פתוחות, החלטות שנדחו, חריגים שהופעלו.
מדדים לפני ואחרי
זמן התגובה הממוצע ירד מ-42 ל-7 דקות, החציון לסגירת תקריות מאותו סוג — מ-6 שעות ל-40 דקות. שיעור האירועים שנסגרו בלי השתתפות אדם עלה לשני שלישים; הפעולות הידניות לתקרית ירדו פי 4. העומס על משמרת הלילה התאזן: התור הפסיק להצטבר לקראת הבוקר.
איפה היה קשה יותר משציפינו
שני אזורים דרשו איטרציות נפרדות. הראשון — מקורות עם פורמטים לא סטנדרטיים של יומנים: חלק מהם היה צריך להביא לצורה אחידה בצד האיסוף, אחרת המסווג טעה באירועים מאותו סוג.
השני — האמון של האנליסטים באוטומט: בהתחלה חלק מהתרחישים עבד במצב «להציע פעולה» ולא «לבצע», ורק אחרי סטטיסטיקה שנצברה הסרנו את האישור צעד-צעד.
מה לעשות אם האוטומציה של התגובה כבר פרוסה אצלכם?
אוטומציה עצמאית כבר פרוסה — זה לא סיבה להתחיל מאפס, אלא בסיס מוכן: חלק מהתרחישים מתאר את התהליכים שלכם מדויק יותר מכל ערכה טיפוסית.
לכן אנחנו לא מכבים את קו המתאר הקיים, אלא יורשים אותו — מתחברים לאותם מקורות אירועים, שומרים על ניתוב ההתראות, על הרשאות חשבונות השירות ועל מספור התקריות, כדי שהיסטוריית התגובה לא תיקרע.
הלאה — רוויזיה של תרחישים: עורכים ספירת מלאי של מה שעובד עכשיו. בודקים אילו כללים באמת מופעלים, מה שיעור השווא, היכן האנליסט בכל זאת משלים בידיים, אילו תרחישים משכפלים זה את זה במשמעות. כל כלל מקבל פסק דין — להשאיר כמו שזה, לשכתב את הלוגיקה או לשלוח לארכיון. בפועל, חלק ניכר מהכללים שנכתבו בעצמכם או לא הופעל אף פעם, או מתנגש עם שכנים ומשתיק התראות שימושיות.
הגירת תרחישים מתבצעת בשלבים ובלי השבתת המשמרת. כללים חדשים מופעלים במצב צל: הם רואים את אותם אירועים, אבל לא מבצעים פעולות — משווים מה האוטומציה הציעה ומה עשה האנליסט התורן.
קו מתאר על Shuffle או על סקריפטים עצמאיים מנותח אותו דבר: הלוגיקה מועברת ענף-ענף, בשימור נקודות האסקלציה ובאפשרות לחזור לכלל הקודם בהחלפה אחת.
הירושה של קו המתאר מסתיימת במסירה לתמיכה, ולא בהפעלה. קובעים נוהל: מי מוסיף תרחיש, על אילו אירועי בדיקה הוא נבדק, לפי אילו מדדים רואים דגרדציה — זמן עד לפעולה האוטומטית הראשונה, שיעור תקריות שנסגרות בלי אדם, מספר החזרות לאחור של האוטומטיקה. מכאן קו המתאר מתפתח יחד עם התהליכים שלכם, ולא נשאר תצורה קפואה.
אינטגרציות עם מערכות קיימות והתראות שווא
SOAR לא מביא תועלת מעצמו — הוא עובד בדיוק במידה שבה מקורות האירועים מוסרים נתונים במלואם ובמידה שבה הם מובאים לסכמה משותפת באופן נקי.
בתחילת הפרויקט כמעט תמיד עולים אותם ספקות טכניים: מה לעשות עם מערכות שאין להן גישה מכונה, איך לשמור על דיוק ההפעלות אחרי השבועות הראשונים ומי מעדכן תרחישים כשהתשתית משתנה.
מה לעשות עם מקורות אירועים שאין להם API?
מערכות נגישות מחברים ישירות ומנרמלים אירועים לסכמה אחידה. לפתרונות סגורים שמים סוכן-קולקטור לייצוא או מפרקים יומנים טקסטואליים — המקור נכנס לזרם המשותף, ולא נשאר בצד.
אפשרויות שבהן אין גישה מכונה בכלל מועברות למצב חצי-ידני: האנליסט מקבל פלייבוק מוכן ומאשר פעולה, במקום לאסוף הקשר ביד.
איך מפחיתים את שיעור התראות השווא?
כל הפעלה מועשרת בהקשר: מי ומאיזה צומת, מה קרה בצומת הזה קודם, האם התבנית חוזרת. אות בודד נשאר תצפית, פעולה אוטומטית מופעלת בהתאמה של כמה סימנים.
בשבועות הראשונים המערכת עובדת במצב הצטברות: אנחנו משווים את החלטותיה למסקנות האנליסטים ומכווננים ספים, עד ששיעור השווא יורד לרמה שהוסכמה.
מה נכלל בתמיכה ואיך מתעדכנים התרחישים?
הפלייבוקים מנוהלים בגרסאות, ולכל אחד יש מערך אירועים רגרסיבי — עריכה לא יוצאת לעבודה עד שהיא עוברת אותו במלואו. כשהתשתית משתנה מוסיפים מקורות וכללים חדשים, וישנים מוציאים משימוש במקום לצבור אותם.
החזרה לרוויזיה קודמת לוקחת דקות: אם תרחיש מעודכן מתנהג אחרת, מחזירים את הלוגיקה הקודמת בלי לעצור את המשמרת.
נדון במשימה שלכם ונחזור עם הערכה ותוכנית
מתחילים את השיחה מהמשימה, לא ממצגת: אילו סוגי תקריות צריך לסגור אוטומטית, כמה אירועים ביממה מגיעים לקו המתאר ואילו פעולות האנליסט מבצע בידיים הכי часто.
מכם בהתחלה מספיק רשימת מקורות אירועים, דרכי האינטגרציה איתם, נהלי התגובה הנוכחיים ושתיים-שלוש תקריות מנותחות עם תזמון לפי שלבים.
מכאן מדייקים את מה שבדרך כלל לא מתואר בתיעוד: שלמות הנרמול של האירועים, איכות ספרי העזר של הנכסים והחשבונות, הפרדת ההרשאות לפעולות אוטומטיות. אם האינטגרציות הטרוגניות, מתחילים בביקורת של קו המתאר הנוכחי — היא מראה אילו תרחישים מתאוטמטים מיד ואילו ייתקלו בחוסר נתונים.
- מפת מקורות אירועים ומידת המוכנות של האינטגרציות, עם פערים ברורים בנתונים;
- רשימת תרחישי תגובה, ממוינים לפי תדירות הפעלה ועלות עבודה;
- תוכנית עבודה לפי שלבים — מביקורת קו המתאר ועד התרחישים האוטומטיים הראשונים;
- הערכת לוחות זמנים לכל שלב והרכב הצוות המתאים לו;
- תיאור שלב הפיילוט: אילו תרחישים לוקחים ראשונים ואיך מודדים תוצאה;
- דרישות להרשאות, נתוני בדיקה וסביבות, כדי שהפיילוט לא ייתקע באישורים;
- קריטריוני קבלה: שיעור התקריות שנסגרות בלי השתתפות אנליסט, וזמן התגובה.
תארו את המשימה בצורה חופשית — נחזור עם הערכת לוחות זמנים ותוכנית עבודה.







