מתי אנליסט SOC צריך להסלים אירוע ל-Tier 2 או ל-IR

מהי הסלמה מקצועית

הסלמה היא העברת אחריות או שיתוף אחריות לגורם בעל סמכות, מומחיות או גישה רחבה יותר. היא נדרשת כאשר נוצר פער בין צורכי האירוע לבין יכולת הטיפול הנוכחית: אין הרשאה לאסוף Artifact מסוים, נדרש לבודד שרת ייצור, קיימת אינדיקציה לתנועה רוחבית, או שההחלטה עשויה להשפיע על פעילות עסקית.

חשוב להבדיל בין הסלמה פונקציונלית להסלמה היררכית. הסלמה פונקציונלית עוברת למומחה — למשל Tier 2, חוקר DFIR, מנהל Active Directory או צוות ענן. הסלמה היררכית עולה למנהל משמרת, CISO, הנהלה או גורם עסקי בגלל השפעה, סיכון או צורך בהחלטה. באירוע מורכב ייתכן ששני המסלולים יתרחשו במקביל.

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

ההבדל בין Tier 1, Tier 2 ו-Incident Response

Tier 1 מאמת שההתראה רלוונטית, בודק הקשר בסיסי, מסיר רעש ברור ומזהה סימנים שמחייבים העמקה. Tier 2 מחבר מקורות נוספים, מבצע Query מורכב, בונה Timeline רחב, בודק Scope ומנסח Hypothesis. צוות Incident Response נכנס כאשר יש אירוע מאומת או חשד משמעותי שמצריך בלימה, איסוף ראיות, תיאום בין מערכות ושחזור.

הגבול אינו נקבע רק לפי זמן. אנליסט Tier 1 יכול לפתור מקרה מורכב אם יש לו הכשרה וסמכות, ואילו Incident פשוט עשוי לדרוש IR בגלל נכס רגיש. לכן כל ארגון צריך להגדיר מראש סמכויות: מי רשאי לבודד Endpoint, להשבית חשבון, לחסום כתובת, לאפס Token, לאסוף Memory Image או לפנות לספק חיצוני.

מודל טוב מציג גם SLA להסלמה: כמה זמן מותר להשאיר אירוע חדש ללא Owner, באיזה חלון זמן יש להעביר אירוע High, ומתי מנהל משמרת חייב לקבל עדכון גם אם החקירה טרם הסתיימה.

טריגרים טכניים להסלמה

טריגר טכני הוא סימן שמעלה את הסבירות לפגיעה, את היקף האירוע או את הצורך ביכולת מיוחדת. דוגמאות מרכזיות הן ביצוע קוד לא מוכר על שרת קריטי, Credential Dumping, שינוי הרשאות Privileged, Persistence, תנועה רוחבית, שימוש בחשבון שירות, מחיקת לוגים, השבתת EDR, תקשורת ל-Infrastructure עוין או רצף של כמה טכניקות MITRE ATT&CK.

גם חוסר בנתונים יכול להצדיק הסלמה. אם ה-EDR לא זמין, השרת אינו שולח לוגים או שיש Clock Skew מהותי, Tier 1 אינו יכול לסגור בביטחון. במקרה כזה חבילת ההסלמה צריכה לציין במפורש מה חסר ומה נדרש לאסוף.

טריגר נוסף הוא Scope שאינו יציב. אם אותו Hash, משתמש או IP מופיע במספר נכסים, אל תטפלו בכל התראה בנפרד. הסלימו לאירוע מאוחד כדי למנוע פעולות סותרות ולהבין אם מדובר בקמפיין רחב.

• נכס קריטי: Domain Controller, שרת גיבוי, מערכת כספית או סביבת Production.
• זהות רגישה: Global Admin, חשבון שירות או משתמש בעל גישה למידע רגיש.
• התנהגות בעלת השפעה: הצפנת קבצים, Exfiltration, Persistence או Lateral Movement.
• פגיעה ביכולת הניטור: מחיקת לוגים, השבתת Agent או שינוי Audit Policy.
• אירוע רב-מערכתי: זהות, Endpoint, דוא״ל וענן באותו Timeline.
• צורך בפעולה בלתי הפיכה או בעלת השפעה עסקית.

טריגרים עסקיים וארגוניים

חומרה טכנית לבדה אינה מספיקה. התחברות חריגה לחשבון בדיקה יכולה להיות Low, בעוד אותה התחברות לחשבון מנהל כספים לפני העברת תשלום עשויה לקבל Priority גבוהה. בדקו את קריטיות השירות, סוג המידע, מספר המשתמשים, חלון הפעילות, רגולציה רלוונטית ותלות של תהליכים עסקיים.

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

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

מה חייב להיכלל בחבילת ההסלמה

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

לאחר מכן הפרידו בין עובדות, פרשנות והשערות. צרפו מזהי Incident ו-Alert, נכסים ומשתמשים, Timeline מרכזי, Queries שבוצעו, ראיות תומכות, פעולות תגובה, מגבלות מידע והערכת השפעה. סיימו בשאלה ברורה: “נדרשת החלטה על בידוד השרת ואיסוף Memory”, לא “נא לבדוק”.

אם האירוע פעיל, ציינו גם Next Check Time ומי שומר על Ownership עד לקבלת ההסלמה. אין לשלוח קבצים חשודים בערוץ לא מאושר או להדביק מידע רגיש במערכת שאינה מיועדת לכך.

• תקציר של 2–4 שורות.
• Severity ו-Priority עם הנמקה.
• Entities: משתמשים, Hosts, IP, Domains, Hashes.
• Timeline מצומצם של האירועים המהותיים.
• פעולות שכבר בוצעו ותוצאותיהן.
• ראיות ומקורות נתונים, כולל פערים.
• Scope ידוע ו-Scope שטרם נבדק.
• השאלה או ההחלטה הנדרשת מהצוות הבא.

מתי לערב IT, Legal, הנהלה או גורם חיצוני

צוות IT נדרש כאשר יש לבצע שינוי תפעולי: ניתוק שירות, Reset לחשבון, חסימת Rule, שחזור מגיבוי או בדיקת Change. צוות IR או DFIR נדרש לאיסוף ושימור ראיות, Scope רחב ובלימה מתואמת. Legal ו-Privacy מעורבים כאשר קיימת אפשרות לחשיפה משפטית, חוזית או רגולטורית. הנהלה נדרשת כאשר ההחלטה משפיעה על המשכיות עסקית, לקוחות או תקשורת.

פנייה לספק MSSP, Cloud Provider, Cyber Insurance או גורמי אכיפה תבוצע לפי ההסכם והנוהל. תעדו מי אישר, מה הועבר, באיזה ערוץ ומה נשמר. מטרת התיעוד אינה ביורוקרטיה אלא שמירה על רציפות ואחריות.

תרגיל: שמונה תרחישים

מדידת איכות ההסלמות

אל תמדדו רק כמה אירועים הוסלמו. בדקו כמה הסלמות התקבלו ללא בקשת השלמות, כמה הוחזרו בגלל חוסר בראיות, זמן מהזיהוי להסלמה, שיעור אירועים שהתבררו כקריטיים, ואילו טריגרים חוזרים לא הוגדרו ב-Playbook.

יש להיזהר מ-Gaming: יעד של “פחות הסלמות” עלול לעודד סגירה מוקדמת; יעד של “הסלמה בתוך חמש דקות” עלול ליצור העברות ריקות. המדד הנכון משלב מהירות, איכות, דיוק והשפעה.

Checklist מעשי

• ✓האם האירוע חורג מסמכות הפעולה שלי?
• ✓האם נכס או זהות קריטיים מעורבים?
• ✓האם קיימת אינדיקציה לפגיעה פעילה או להתרחבות Scope?
• ✓האם חסר מידע שלא אוכל להשיג בעצמי?
• ✓האם נדרשת פעולה בעלת השפעה עסקית?
• ✓האם בניתי תקציר, Timeline ורשימת ראיות?
• ✓האם ניסחתי שאלה ברורה לגורם הבא?
• ✓האם תיעדתי Owner וזמן בדיקה הבא?

טעויות נפוצות

• להסלים בלי לסכם מה כבר נבדק.
• להמתין ל-100% ודאות בזמן שהפגיעה פעילה.
• להשתמש ב-Severity של הכלי כקריטריון יחיד.
• להעביר אחריות בלי לוודא שהצד הבא קיבל.
• לערב גורמים רבים מדי ללא צורך וליצור ערוצי תקשורת מקבילים.
• לבצע בידוד או השבתה מעבר לסמכות ללא אישור.

סיכום ו-CTA

בחרו שלושה אירועים שטיפלתם בהם במעבדה וכתבו עבור כל אחד חבילת הסלמה של עמוד אחד. לאחר מכן השוו אותה למבנה החקירה במאמר “איך חוקרים התראת אבטחה ב-SOC מקצה לקצה”. בקורס Cybersecurity & AI של HPI מתרגלים עבודה עם התראות, SIEM, תיעוד והסלמה כחלק מתהליך SOC מעשי.

שאלות ותשובות

מקורות

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• Microsoft Learn — Plan an incident response workflow in the Microsoft Defender portal
• Microsoft Learn — Manage incidents in Microsoft Defender
• CISA — Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• Microsoft Learn — Microsoft cloud security benchmark v2: Incident Response