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

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

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

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

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

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

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

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

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

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

תעדוף לפי סיכון עסקי, לא רק לפי ציון חולשה

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

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

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

תהליך בדיקה שלא מעכב כל תיקון

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

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

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

חלונות תחזוקה הם הסכם עם העסק

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

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

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

מדדו תאימות, לא רק הצלחת הפצה

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

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

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

מי אחראי כשעדכון לא הותקן

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

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

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

מתי לעדכן את המדיניות עצמה

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

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