יש טעות אחת שארגונים ממשיכים לעשות שוב ושוב: להתייחס לעדכוני אבטחה כמו לעבודת תחזוקה. זו טעות מסוכנת. עדכון אבטחה הוא לא ניקיון תקופתי ולא משימה למחלקת IT כשיש זמן. הוא מרוץ מול תוקף שכבר קרא את אותו הדיווח, כבר הבין מה תוקן, וכבר מחפש מי עדיין לא סגר את הדלת.
ברגע שיצרן מפרסם תיקון, העולם כולו מקבל איתות. מנהלי מערכות רואים שיצא Patch. גם התוקפים רואים. ההבדל הוא שאנחנו צריכים לאשר, לבדוק, לתזמן, לפרוס ולוודא. הם צריכים רק רשימה של ארגונים שהתעכבו. זאת בדיוק הסיבה שארגונים נפרצים לא בגלל חולשה מסתורית, אלא בגלל חולשה ידועה שאף אחד לא סגר בזמן.
הבעיה האמיתית היא לא הטכנולוגיה אלא המשמעת
רוב הארגונים לא נופלים כי לא ידעו שקיים עדכון. הם נופלים כי לא היה להם מנגנון שמחייב ביצוע, בקרה ותיעדוף. כאן בדיוק נוצר הפער בין ארגון שיש לו כלי עדכונים לבין ארגון שמנהל חשיפה. הראשון מתקין כשנוח. השני עובד לפי סיכון עסקי.
אם שרת VPN, חומת אש, מערכת דוא״ל או תחנת קצה קריטית נשארים בלי עדכון, התוקף לא צריך גאונות. הוא צריך סבלנות. זה נכון במיוחד כשמדובר במערכות חשופות לאינטרנט, אבל גם בתוך הארגון. מספיק קצה אחד לא מעודכן כדי להפוך חדירה קטנה לתנועה רוחבית, גניבת זהויות, הצפנה או דלף מידע.
למה Patch שיצא היום מסוכן יותר ממה שהיה אתמול
הרבה מנהלים חושבים שהסיכון יורד ברגע שיצא תיקון. בפועל, לעיתים קורה ההפך. מרגע שהתיקון פורסם, גם מי שלא גילה את החולשה לבד יכול להבין מה בדיוק השתנה ולבנות ניצול. לכן חלון הזמן שבין פרסום התיקון לבין ההתקנה בפועל הוא חלון התקיפה האמיתי. זה השלב שבו ארגונים חשופים יותר, לא פחות.
זו גם הסיבה שאנחנו ב 010 לא מסתפקים בהמלצה כללית לעדכן. אנחנו מסתכלים על כל שרשרת ההגנה: סקר סיכונים שממפה את נקודות החולשה, שירות עדכוני תוכנה ועדכוני אבטחה שמפיץ תיקונים בצורה שוטפת, ו SIEM ו SOC שמזהים חריגות גם כשמישהו כבר ניסה לנצל את הפער.
שלוש טעויות שמכניסות ארגונים לצרות
טעות ראשונה: לחשוב שכל העדכונים דחופים באותה מידה. זה לא נכון. לא כל Patch הוא קריטי, אבל יש עדכונים שמיועדים לחולשות שכבר מנוצלות בפועל. אלה לא נכנסים לרשימת משימות. אלה צריכים להיכנס לראש סדר העדיפויות.
טעות שנייה: להתמקד רק בתחנות קצה ולהזניח ציוד רשת, מערכות צד שלישי ושירותים חיצוניים. דווקא הרכיבים האלה הופכים לא פעם לשער הכניסה הראשוני.
טעות שלישית: לחשוב שגיבוי פותר את בעיית העיכוב. גיבוי הוא קו הצלה חשוב, אבל הוא לא תחליף לסגירת פרצות. הוא מיועד ליום שבו משהו כבר קרה. המטרה שלנו היא למנוע את האירוע, לא רק לשרוד אותו. לכן אנחנו תמיד מחברים בין הקשחה ועדכונים לבין גיבוי והמשכיות עסקית.
כך בונים משטר עדכונים שבאמת מצמצם סיכון
הגישה הנכונה פשוטה יותר ממה שנהוג לחשוב, אבל דורשת משמעת:
- ממפים נכסים קריטיים ומבינים מה באמת חייב טיפול מיידי.
- מגדירים SLA פנימי לעדכונים לפי רמת חומרה וחשיפה.
- בודקים תאימות מראש כדי למנוע מצב שבו הפחד מתקלה משאיר את המערכת חשופה שבועות.
- מאמתים התקנה בפועל ולא מסתפקים בכך שהעדכון נשלח.
- מחברים נראות רציפה כדי לזהות ניסיונות ניצול, תחנות שלא התעדכנו וחריגות שחוזרות על עצמן.
הנקודה הקריטית היא זו: מי שמנהל Patch Management כמו תהליך תפעולי בלבד, יקבל תוצאה תפעולית בלבד. מי שמנהל אותו כחלק מתפיסת הגנת סייבר רחבה, יוריד סיכון אמיתי.
הסימן שהארגון שלכם עדיין לא באמת שולט בנושא
אם אין לכם תשובה מיידית לשאלות הבאות, אתם כנראה עובדים בחושך: אילו מערכות חשופות לאינטרנט עדיין לא מעודכנות? אילו חולשות רלוונטיות כבר מנוצלות בעולם? כמה זמן עובר מרגע פרסום עדכון קריטי ועד שהוא מותקן בפועל? ואילו נכסים נשארים שוב ושוב מאחור?
כשאין תשובות, אין שליטה. וכשאין שליטה, ההאקרים מנהלים את הקצב.
מה אנחנו ממליצים לעשות עכשיו
אל תחכו לאירוע כדי לגלות שהארגון עובד עם פערי זמן מסוכנים. התחילו בבדיקת חשיפה, הגדירו סדר עדיפויות לפי סיכון, והעבירו את ניהול העדכונים ממגירה תפעולית לליבת ההגנה העסקית. זאת בדיוק הגישה שאנחנו מיישמים אצל לקוחות: לא עוד עדכון כשנוח, אלא סגירת חלונות תקיפה לפני שהם הופכים לכותרת.
לקריאה נוספת, מומלץ להעמיק גם במאמרים העדכון שדחיתם אתמול הוא הפריצה של מחר, כך בונים מעטפת הגנת סייבר שעובדת באמת ו ההאקרים כבר בפנים: 6 סימנים שקטים שהעסק שלך מתעלם מהם.
המסקנה שלנו חדה: עדכון אבטחה שלא הותקן בזמן הוא לא משימה פתוחה. הוא הזמנה פתוחה.
