סקר עדכני: ממוצע תיקון פגיעות אבטחת מידע בארגון - ששה חודשים
סקר חדש חושף כי ארגונים חוששים לעדכן חולשות שהתגלו ורשתות נשארות חשופות לפחות חצי שנה לאחר פרסום התיקון על ידי היצרן
עמי רוחקס דומבה
| 20/08/2020
bigstock
חברות גדולות מוצאות בממוצע מאות אלפי כשלי אבטחה בודדים בעת הפעלת סריקות שגרתיות. במשך שישה חודשים, 28 אחוזים מממוצע מהפגיעויות הללו יישארו טלאי. זה משאיר רבים מארגונים אלה ב"עמדת ברווז" מול פושעי רשת. כך עולה ממחקר של חברת Ponemon Institute. המחקר מבוסס על סקר עולמי בקרב 1,848 אנשי מקצוע בתחום אבטחת IT ו- IT בצפון אמריקה, אירופה, המזרח התיכון, אפריקה, אזור אסיה-פסיפיק ואמריקה הלטינית במגוון תעשיות.
53% מהנשאלים אומרים כי הארגון שלהם חווה דליפת נתונים בשנתיים האחרונות, כאשר 42% אמרו שהדליפה התרחשה משום שהתיקון היה זמין לפגיעות ידועה, אך לא מיושם ברשת הארגון. ללא נוסחת עדיפות מבוססת סיכון, צוותי אבטחת המידע עשויים להיאבק לפענח אילו פגיעויות הן אמיתיות ומהוות סיכון גבוה. חלק מהמשיבים לסקר ממשיכים להשתמש בגיליון אלקטרוני ידני בכדי לתעדף.
"בשנים האחרונות אנחנו רואים כי תהליכי ניהול חולשות אבטחה (vulnerability management) נעשים יותר ויותר מורכבים", מסביר יניב בר דיין המנכ"ל של חברת Vulcan Cyber המפתחת מערכת לניהול עדכוני פגיעויות. "הגמישות והגיוון של התשתיות והאפליקציות שלנו מהווים קרקע פורייה, וצוותי אבטחה ואופרציה נאלצים להתמודד עם כמות הולכת וגדלה של חולשות אבטחה. בפועל, הם פשוט מתקשים לעמוד בקצב.
"תוסיפו על זה שעיקר תשומת הלב, ולבטח התקציב, מופנים כלפי זיהוי וניטור של החולשות (vulnerability assessment), כך שתהליך התיקון עצמו (vulnerability remediation), החלק האחרון והמהותי ביותר בתהליך, נזנח. חשוב לציין שאין מקום להאשים את צוותים המעורבים. ברוב המוחלט של המקרים פשוט אין להם את הכלים הנחוצים להצליח להפחית את רמת הסיכון (risk level) בחברה. התהליך מסורבל מדי ולא אפקטיבי.
"לרוב זה נראה ככה: צוותי האבטחה אמונים על זיהוי וניטור חולשות האבטחה. הם עושים את זה באמצעות מספר כלים הסורקים את הסביבות השונות ויוצרים רשימות ארוכות, בלתי נגמרות של חולשות שצריך לתעדף (prioritize) ולתקן. ברוב המוחלט של החברות תהליך התיעדוף נעשה בצורה לא אפקטיבית במקרה הטוב, ומסוכנת המקרה הרע. אחר כך מגיע שלב התיקון, ושם נכנסים לתמונה הצוותים הנוספים: אופרציה, IT, DevOps וכו'. הם האחראים על התיקון בפועל של החולשות וסגירת המעגל.
"כשנכנסים בעובי הקורה נדמה כי צוותי האבטחה והכלים איתם הם עובדים פשוט לא מדברים באותה שפה כמו יתר הצוותים והכלים שלהם. אנו רואים קצר של ממש בתקשורת בין אלו שמזהים את הבעיות לבין אלו שצריכים לפתור אותן. הבעיה רק הולכת ומתעצמת כשבוחנים את תהליך התיקון עצמו: במקרים רבים נרצה לפאצ'פץ' ולעדכן גרסה, אבל מדובר בתהליך מורכב ולעיתים לא צפוי, שיכול להביא לתוצאות גרועות בהרבה מלהישאר חשופים לחולשה עצמה.
"לכן, לפעמים נעדיף לנסות ולמצוא דרכים אלטרנטיביות, כמו workarounds ו-compensating controls למגר את הסכנה, אך גם לפתרונות אלו אין מקור מידע טוב או נגיש מספיק, כזה שיהפוך חלק מהותי מהתהליך."
סקר חדש חושף כי ארגונים חוששים לעדכן חולשות שהתגלו ורשתות נשארות חשופות לפחות חצי שנה לאחר פרסום התיקון על ידי היצרן
bigstock
חברות גדולות מוצאות בממוצע מאות אלפי כשלי אבטחה בודדים בעת הפעלת סריקות שגרתיות. במשך שישה חודשים, 28 אחוזים מממוצע מהפגיעויות הללו יישארו טלאי. זה משאיר רבים מארגונים אלה ב"עמדת ברווז" מול פושעי רשת. כך עולה ממחקר של חברת Ponemon Institute. המחקר מבוסס על סקר עולמי בקרב 1,848 אנשי מקצוע בתחום אבטחת IT ו- IT בצפון אמריקה, אירופה, המזרח התיכון, אפריקה, אזור אסיה-פסיפיק ואמריקה הלטינית במגוון תעשיות.
53% מהנשאלים אומרים כי הארגון שלהם חווה דליפת נתונים בשנתיים האחרונות, כאשר 42% אמרו שהדליפה התרחשה משום שהתיקון היה זמין לפגיעות ידועה, אך לא מיושם ברשת הארגון. ללא נוסחת עדיפות מבוססת סיכון, צוותי אבטחת המידע עשויים להיאבק לפענח אילו פגיעויות הן אמיתיות ומהוות סיכון גבוה. חלק מהמשיבים לסקר ממשיכים להשתמש בגיליון אלקטרוני ידני בכדי לתעדף.
"בשנים האחרונות אנחנו רואים כי תהליכי ניהול חולשות אבטחה (vulnerability management) נעשים יותר ויותר מורכבים", מסביר יניב בר דיין המנכ"ל של חברת Vulcan Cyber המפתחת מערכת לניהול עדכוני פגיעויות. "הגמישות והגיוון של התשתיות והאפליקציות שלנו מהווים קרקע פורייה, וצוותי אבטחה ואופרציה נאלצים להתמודד עם כמות הולכת וגדלה של חולשות אבטחה. בפועל, הם פשוט מתקשים לעמוד בקצב.
"תוסיפו על זה שעיקר תשומת הלב, ולבטח התקציב, מופנים כלפי זיהוי וניטור של החולשות (vulnerability assessment), כך שתהליך התיקון עצמו (vulnerability remediation), החלק האחרון והמהותי ביותר בתהליך, נזנח. חשוב לציין שאין מקום להאשים את צוותים המעורבים. ברוב המוחלט של המקרים פשוט אין להם את הכלים הנחוצים להצליח להפחית את רמת הסיכון (risk level) בחברה. התהליך מסורבל מדי ולא אפקטיבי.
"לרוב זה נראה ככה: צוותי האבטחה אמונים על זיהוי וניטור חולשות האבטחה. הם עושים את זה באמצעות מספר כלים הסורקים את הסביבות השונות ויוצרים רשימות ארוכות, בלתי נגמרות של חולשות שצריך לתעדף (prioritize) ולתקן. ברוב המוחלט של החברות תהליך התיעדוף נעשה בצורה לא אפקטיבית במקרה הטוב, ומסוכנת המקרה הרע. אחר כך מגיע שלב התיקון, ושם נכנסים לתמונה הצוותים הנוספים: אופרציה, IT, DevOps וכו'. הם האחראים על התיקון בפועל של החולשות וסגירת המעגל.
"כשנכנסים בעובי הקורה נדמה כי צוותי האבטחה והכלים איתם הם עובדים פשוט לא מדברים באותה שפה כמו יתר הצוותים והכלים שלהם. אנו רואים קצר של ממש בתקשורת בין אלו שמזהים את הבעיות לבין אלו שצריכים לפתור אותן. הבעיה רק הולכת ומתעצמת כשבוחנים את תהליך התיקון עצמו: במקרים רבים נרצה לפאצ'פץ' ולעדכן גרסה, אבל מדובר בתהליך מורכב ולעיתים לא צפוי, שיכול להביא לתוצאות גרועות בהרבה מלהישאר חשופים לחולשה עצמה.
"לכן, לפעמים נעדיף לנסות ולמצוא דרכים אלטרנטיביות, כמו workarounds ו-compensating controls למגר את הסכנה, אך גם לפתרונות אלו אין מקור מידע טוב או נגיש מספיק, כזה שיהפוך חלק מהותי מהתהליך."
