ביום שישי ה-19.7 התרחשה תקלה קריטית במחשבים ושרתים המוגנים ע"י מוצר ההגנה של CrowdStrike אשר גרמה לתקלות והשבתות נרחבות.
ככל שעובר הזמן, נראה שהתמונה מתבהרת.
נכון לעכשיו, נראה כי עדכון אשר הכינה החברה, עבר בדיקות QA בצורה תקינה, הועבר לתחנות קצה/שרתים ונפגם בדרך.
הדבר גרם לקבלת קובץ פגום במחשבים אשר הוביל לקריסה/BSOD.
האם הדבר יכול להתרחש גם ב-ESET?
קודם כל, תקלות יכולות להתרחש, אך עם זאת, ESET חברה בת 35 שנות ניסיון בהגנה על ארגונים ולקוחות פרטיים.
לאורך השנים סיגלנו ב-ESET שיטות ומנגנוני עבודה אשר ימנעו מבעוד מועד תקלה דומה.
1. כל עדכון או גרסה חדשה, חתומים דיגיטלית ע"י ESET.
בנוסף, כל עדכון מאומת בתחנה על מנת לוודא כי הוא לא שונה בדרך.
כלומר, אם העדכון נפגם בדרך (Corrupted), הוא לא יתקבל בתחנות והתחנות ידחו אותו.
ככל הנראה זו הסיבה שגרמה לתקלה במוצר של CrowdStrike.
באופן זהה, מוצר ההגנה גם לא יקבל עדכון שזוייף ע"י גורם זדוני.
2. ל-ESET יש מנגנון שדרוגים אוטומטיים של מוצרי ההגנה אשר נקרא (uPCU) Micro Program Components Update אשר מספק עדכונים בעיכוב מכוון של 14-28 ימים.
בזמן זה, אם תימצא תקלה כלשהי בגרסה החדשה, היא תאותר ותתוקן.
אם יהיה צורך, ESET תמשוך את הגרסה הפגומה והיא לא תגיע לכל התחנות.
3. ניתן להגביל עדכון לכל מוצרי ההגנה עד גרסה מסויימת לבחירתכם, בפוליסי.
הגדרה זו פחות מומלצת מכיוון שהיא מפסיקה את העדכונים הסדירים.
4. עדכוני מודולים (עדכונים אשר לא מצריכים הפעלה מחדש), מתבצעים בחלקים (ב-Batches) ולא מגיעים לכל המשתמשים בעולם במכה אחת.
כלומר כל עדכון מודול יוצא בעדכון קדם הפצה במשך כשבוע (למי שהגדרה זו מופעלת אצלו), לאחר מכן הוא ממשיך לכמות מצומצמת של משתמשים במנות.
לדוגמה העדכון נשלח ל-2 מיליון משתמשים ברחבי העולם, לאחר 4 שעות נשלח לעוד 5 מיליון משתמשים וכן הלאה.
לכל אורך הדרך, ב-ESET בודקים אם אין דיווחים על תקלות או בעיות כלשהן הקשורות בעדכון.
5. ניתן להגדיר בפוליסי עיכוב מכוון של עדכוני מודולים, אשר מעכב במכוון במספר שעות את קבלת העדכונים.
הגדרה זו פחות מומלצת, מכיוון שמוצרי ההגנה לא יקבלו את המידע הכי עדכני על האיומים אשר מתפרצים בעולם.
6. ב-ESET מכירים בכך שבסוף השבוע יש צוות עובדים מצומצם, ומשתדלים לא לבצע שינויים משמעותיים בסופ"ש.
לקריאה נוספת של המאמר בבלוג באנגלית WeLiveSecurity.
