SOC Metrics: המדדים שבאמת משפרים איתור ותגובה

מה מטרת המדידה

לפני בחירת KPI, הגדירו החלטה. אם המדד עולה או יורד, מה תעשו? זמן Triage גבוה עשוי להצדיק שינוי Queue, אוטומציה או הכשרה. שיעור False Positive גבוה מצדיק Tuning. חוסר לוגים מנכס קריטי דורש טיפול ב-Data Pipeline.

הפרידו בין Volume, Efficiency, Quality, Coverage ו-Outcome. נפח מתאר כמה עבודה נכנסה; יעילות — כמה זמן ומשאבים נדרשו; איכות — האם ההחלטות היו נכונות; כיסוי — מה ניתן לזהות; תוצאה — האם פגיעה נבלמה והאם היא חוזרת.

לכל מדד הגדירו Owner, מקור נתונים, נוסחה, תדירות, פילוחים וגבולות שימוש. ללא Data Dictionary, שני מנהלים יכולים לחשב “MTTR” באופן שונה.

מדדי זמן

Mean Time to Triage מודד את הזמן מיצירת Incident עד מגע אנליסטי משמעותי או שינוי ראשון, בהתאם להגדרה. Time to Assign מודד זמן עד Owner. Time to Contain מודד זמן עד פעולה שמפסיקה התפשטות. Time to Close מודד עד סגירה מנהלית. אלה נקודות שונות ואסור לערבב ביניהן.

MTTD — Mean Time to Detect — קשה יותר למדידה משום שזמן תחילת התקיפה אינו תמיד ידוע. אפשר להשתמש ב-First Activity Time לעומת Created Time, אך יש לציין שמדובר בקירוב. MTTR הוא מונח עמום: Respond, Remediate, Recover או Resolve. כתבו את המילה המלאה בכל דוח.

פילחו לפי Severity, סוג Use Case, מקור Detection, שעות עבודה, Owner ונכס. ממוצע כללי מסתיר אירועי High איטיים בתוך נפח גדול של Low מהירים.

למה Percentiles חשובים

ממוצע מושפע מאירועים חריגים. אם תשעה Incidents נסגרו בשעה ואחד לאחר מאה שעות, הממוצע יהיה 10.9 שעות — נתון שלא מתאר את רוב המקרים ולא את הזנב. Median (P50) מתאר את המקרה האמצעי; P90 מציג את הזמן שמתחתיו נסגרו 90% מהמקרים.

Microsoft מציגה דוגמאות KQL לחישוב אחוזוני Time to Triage ו-Time to Closure מתוך SecurityIncident. לצוות מומלץ לעקוב לפחות אחר P50 ו-P90, ולחקור את ה-P90: האם מדובר באישור IT, חוסר Owner, Data Gap או תהליך ידני.

אל תשוו אחוזונים בין תקופות אם הגדרת CreatedTime, FirstModifiedTime או ClosedTime השתנתה. תעדו שינויים במערכת וב-Workflow.

מדדי איכות זיהוי

False Positive Rate לבדו אינו מספיק, משום ש-Benign Positive יכול להיות Detection נכון על פעילות מורשית. עדיף לסווג: True Positive, Benign Positive, False Positive, Undetermined ו-Duplicate. נתחו לפי Rule ולא רק ברמת SOC.

מדדו גם Actionability: באיזה אחוז מה-Alerts קיימים Context ו-Entities שמאפשרים חקירה? כמה Tickets נסגרו ללא ראיות? כמה Incidents נפתחו מחדש? כמה הסלמות הוחזרו להשלמות? מדדים אלה משקפים איכות תפעולית.

ל-Detection Engineering הוסיפו Precision ו-Coverage כאשר ניתן, אך היזהרו מחישוב Recall ללא Ground Truth. Purple Team, Simulation ו-Atomic tests יכולים לספק בדיקה מבוקרת של Use Cases.

מדדי כיסוי ונראות

SOC אינו יכול לזהות מה שאינו נאסף. מדדו אחוז נכסים קריטיים ששולחים לוגים, Freshness, נפח חריג, Parsing failures, שדות חסרים, Retention ו-Clock Sync. Data Source Availability צריך להיות KPI תפעולי, לא רק בעיית תשתית.

בנו Coverage Map מול Use Cases ו-MITRE ATT&CK: אילו טכניקות רלוונטיות לארגון, אילו Data Sources נדרשים, אילו Rules קיימים ומתי נבדקו. מספר טכניקות “מכוסות” אינו הוכחה לאיכות, אך הוא מסייע לזהות פערים.

מדדו גם Detection Debt: Rules ללא Owner, ללא Test, ללא תיעוד, ללא Review או עם Data Source שהשתנה. חוב כזה מגדיל סיכון גם אם הדשבורד מציג Alerts.

מדדי עומס ותהליך

עקבו אחר Backlog, Aging, Alerts per Analyst, Incidents ללא Owner, זמן המתנה לצוותים חיצוניים, שיעור Reassignment ושעות On-call. עומס גבוה אינו בהכרח בעיית כוח אדם; ייתכן Rule רועש או Workflow מיותר.

אל תדרגו אנליסטים לפי מספר Tickets שנסגרו. מדד כזה מעודד בחירת מקרים קלים וסגירה מהירה. עדיף להשתמש במדדים קבוצתיים ולשלב Review איכות, מורכבות, תיעוד, תרומה ל-Tuning ויכולת לזהות Scope.

מדדו Standardization: אחוז Incidents שבהם הושלמו Tasks נדרשים, Playbook הופעל, Classification כלל נימוק ו-Timeline נכתב. המטרה היא לא ליצור טופס, אלא לוודא מינימום מקצועי.

מדדי השפעה ושיפור

התוצאה החשובה היא הפחתת השפעה וחזרתיות. מדדו Time to Contain באירועים מאומתים, מספר נכסים שנפגעו לפני ואחרי Detection, אירועים חוזרים מאותו Root Cause, Recommendations שיושמו וזמן לסגירת פער Logging או Control.

Post-Incident Review צריך ליצור Actions מדידים: Rule חדש, שינוי Policy, הדרכה, Asset tagging או שיפור Backup. עקבו אחר אחוז Actions שהושלמו ובדקו האם האירוע חזר.

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

Scorecard חודשי לצוות SOC קטן

איך למנוע Gaming

לכל KPI הגדירו Anti-Metric. אם מודדים זמן סגירה, בדקו Reopen Rate ואיכות Classification. אם מודדים פחות Alerts, בדקו Coverage ו-Detection tests. אם מודדים פחות False Positives, בדקו שלא נוצרו Missed Detections.

הציגו מגמות ולא “ציון יחיד”. שינוי גדול מחייב בדיקת Data Quality: האם מקור הפסיק לשלוח? האם ה-Workflow השתנה? האם Incident updates יוצרים כפילויות בטבלה? Microsoft מזהירה שכל Update ל-Incident יוצר רשומה חדשה ב-SecurityIncident, ולכן Queries צריכים לבחור את הרשומה האחרונה.

קיימו Review חודשי שבו האנליסטים מסבירים מה המדדים אינם מראים. מדידה בריאה יוצרת שאלות, לא רק צבע ירוק.

Checklist מעשי

• ✓לכל KPI קיימת החלטה שהוא אמור לשפר.
• ✓הנוסחה ומקור הנתונים מתועדים.
• ✓אני משתמש ב-P50/P90 ולא רק בממוצע.
• ✓MTTR מוגדר במילה מלאה.
• ✓המדדים מפולחים לפי Severity ו-Use Case.
• ✓מדדי איכות וכיסוי מאזנים מדדי מהירות.
• ✓יש Anti-Metric למניעת Gaming.
• ✓Data Quality נבדקת לפני מסקנות.
• ✓הצוות מבצע Review ומייצר Actions.

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

• למדוד רק מספר Alerts ו-Tickets.
• להשוות תקופות עם הגדרות שונות.
• לדרג אנליסטים לפי כמות סגירות.
• להציג Average ללא Percentiles.
• להתעלם מאירועים ללא Owner ומ-Backlog.
• להפחית רעש באמצעות כיבוי Detection בלי לבדוק Coverage.
• להציג KPI ירוק כאשר מקור לוג הפסיק לשלוח.

סיכום ו-CTA

בחרו חודש אחד ובנו Scorecard קטן עם P50/P90 Triage, Classification לפי Rule, זמינות לוגים, Backlog ו-Time to Contain. ליד כל מדד כתבו איזו החלטה הוא אמור לייצר. בקורס Cybersecurity & AI של HPI מתרגלים חקירה ו-SIEM, בסיס שמאפשר להבין את המשמעות מאחורי המדדים ולא רק להציג Dashboard.

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

מקורות

• Microsoft Learn — Manage your SOC better with incident metrics in Microsoft Sentinel
• NIST SP 800-61 Rev. 3
• NIST Cybersecurity Framework 2.0
• Microsoft Learn — Prioritize incidents in the Microsoft Defender portal
• Microsoft Learn — Use tasks to manage incidents in Microsoft Sentinel