זמן ממוצע לתיקון (MTTR)

בקצרה

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

מהו MTTR?

זמן ממוצע לתיקון (MTTR) הוא מדד מרכזי בתחום הסייבר שמראה כמה מהר אתה מגיב לאיום ידוע. הוא מודד את הזמן מרגע מציאת פגיעות ועד ליישום תיקון.

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

למה MTTR חשוב

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

• חלון הניצול של 5 ימים: בשנת 2025, הזמן הממוצע לניצול (TTE), הפער בין הזמן שבו פגיעות מתפרסמת לבין הזמן שבו היא מנוצלת בפועל, ירד מ-32 ימים ל-5 ימים בלבד (CyberMindr, 2025).
• עלייה בניצול: השימוש בפגיעות כדרך כניסה עלה ב-34% השנה וכעת גורם ל 20% מכל הפריצות המאושרות.
• הפער בתיקון: תוקפים פועלים בתוך ימים, אך ארגונים לעיתים קרובות לוקחים שבועות. הזמן הממוצע לתיקון פגיעות קריטיות במכשירי קצה ו-VPN נשאר 32 ימים, מה שמשאיר חלון סיכון משמעותי. רק 54% מהפגמים מתוקנים באופן מלא (Verizon DBIR, 2025). האצה יומית: גילוי פגיעות יום אפס מנוצלות עלה ב-46% לעומת השנה שעברה. תוקפים כעת מנצלים את הפגמים הללו בתוך שעות מזיהוי (WithSecure Labs, 2025).
• MTTR גבוה מעלה את עלויות העסק הרבה מעבר לחוב טכני. בשנת 2025, העלות הממוצעת של פריצת נתונים בארה”ב היא 4.4 מיליון דולר, בעיקר בשל תגובה מאוחרת וקנסות רגולטוריים (IBM, 2025).
• קנסות על אי-עמידה בדרישות: תחת כללים כמו DORA, זמני חשיפה ארוכים נחשבים ככישלונות תחת חוסן תפעולי. ארגונים עם MTTR גבוה כעת עומדים בפני דיווח חובה וקנסות גדולים על אי-עמידה. אינך יכול לפעול מהר יותר מתסריטי הניצול; ההגנה שלך היא תאורטית בלבד.

כיצד לחשב MTTR

MTTR מחושב על ידי חלוקת הזמן הכולל שהושקע בתיקון מערכת במספר התיקונים שבוצעו במהלך תקופה מסוימת.

הנוסחה

MTTR-formula

דוגמה לחישוב

דמיינו שהצוות ההנדסי שלכם טיפל ב4 תקריות בחודש שעבר:

1. תקרית A: תקלה במסד נתונים (תוקן ב30 דקות)
2. תקרית B: כשל API (תוקן ב2 שעות / 120 דקות)
3. תקרית C: שגיאת מטמון (תוקן ב15 דקות)
4. תקרית D: תיקון אבטחה (תוקן ב45 דקות)

• זמן תיקון כולל: 30 + 120 + 15 + 45 = 210 דקות
• מספר תיקונים: 4

MTTR-formula-calculation

זה אומר שבממוצע לוקח לצוות שלכם בערך 52 דקות לתקן בעיה מרגע שהם מתחילים לעבוד עליה.

דוגמה בפועל

שקלו שתי חברות המתמודדות עם פגיעות אבטחה קריטית (למשל, Log4Shell).

חברה A (MTTR גבוה):

• תהליך: ידני. התראות נשלחות למייל. מהנדס צריך להתחבר ידנית לשרתים כדי למצוא את קבצי ה-jar הפגיעים ולתקן אותם אחד אחד.
• MTTR: 48 שעות.
• תוצאה: לתוקפים יש יומיים מלאים לנצל את הפגיעות. סביר להניח שהנתונים נפרצו.

חברה B (MTTR נמוך - משתמשת ב-Plexicus לאוטומציה של תיקון):

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

מי משתמש ב-MTTR

• מהנדסי DevOps - לעקוב אחר היעילות של פריסת הצינורות והחזרתן.
• SREs (Site Reliability Engineers) - להבטיח שהם עומדים ב-SLAs (הסכמי רמת שירות) עבור זמינות.
• אנליסטים של SOC - למדוד כמה מהר הם יכולים לנטרל איומי אבטחה פעילים.
• CTOs & CISOs - להצדיק השקעות בכלי אוטומציה על ידי הצגת הפחתה בזמן ההתאוששות.

מתי ליישם MTTR

יש לעקוב אחר MTTR באופן רציף, אך הוא קריטי ביותר במהלך שלב תגובה לאירועים של SDLC (מחזור חיי פיתוח תוכנה)

• במהלך אירועים: הוא פועל כבדיקת דופק חיה. “האם אנחנו מתקנים את זה מספיק מהר?”
• לאחר האירוע: לאחר אירוע, סקירת MTTR עוזרת לזהות אם העיכוב נגרם על ידי זיהוי הבעיה (MTTD) או תיקונה (MTTR).
• משא ומתן על SLA: אינך יכול להבטיח ללקוח “99.99% זמינות” אם ה-MTTR הממוצע שלך הוא 4 שעות.

שיטות עבודה מומלצות להפחתת MTTR

• אוטומציה של הכל: תיקונים ידניים הם איטיים ונתונים לשגיאות. השתמש בInfrastructure as Code (IaC) כדי לפרוס מחדש תשתית שבורה במקום לתקן אותה ידנית.
• ניטור טוב יותר: אי אפשר לתקן מה שלא רואים. כלים של תצפית גרנולרית עוזרים לזהות את שורש הבעיה מהר יותר, ומפחיתים את זמן “האבחון” של תיקון.
• רנבוקים ופלייבוקים: יש להחזיק מדריכים כתובים מראש לכשלים נפוצים. אם מסד נתונים ננעל, המהנדס לא צריך לחפש בגוגל “איך לפתוח מסד נתונים נעול”.
• פוסט-מורטמים ללא האשמות: התמקדו בשיפור תהליכים, לא אנשים. אם מהנדסים חוששים מעונש, הם עשויים להסתיר כשלים, מה שגורם למדדי MTTR להיות לא מדויקים.

מונחים קשורים

• MTTD (Mean Time To Detect)
• MTBF (Mean Time Between Failures)
• SLA (Service Level Agreement)
• ניהול תקריות

מיתוסים נפוצים

• מיתוס: אפשר להגיע ל”אפס פגיעויות.”

  מציאות: המטרה היא לתקן בעיות קריטיות מהר מספיק כדי למנוע ניצול.

• מיתוס: יותר סורקים שווים אבטחה טובה יותר.

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

• מיתוס: כלי אבטחה מאטים את המפתחים.

  מציאות: אבטחה מאטה את המפתחים רק כאשר היא יוצרת התראות “שבורות”. כאשר מספקים בקשת משיכה כתובה מראש, חוסכים להם שעות של מחקר.

שאלות נפוצות

מהו MTTR “טוב”?

צוותי DevOps מובילים שואפים ל-MTTR של פחות מ-24 שעות עבור פגיעויות קריטיות.

איך MTTR שונה מ-MTTD?

MTTD (זמן ממוצע לגילוי) מראה כמה זמן איום קיים לפני שאתה מבחין בו. MTTR מראה כמה זמן הוא נשאר לאחר שמצאת אותו.

האם AI באמת יכול לעזור עם MTTR?

כן. כלים של AI כמו Plexicus מטפלים בתהליך המיון ומציעים תיקונים, אשר בדרך כלל מהווים 80% מתהליך התיקון.

מחשבה סופית

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