ב' חשון התשפ"ה
03.11.2024
מסכים כחולים

הכישלון שיכול להוביל להשלכות קטסטרופליות

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

הכישלון שיכול להוביל להשלכות קטסטרופליות
אילוסטרציה צילום: pixabay.

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

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

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

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

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

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

מה עלינו ללמוד מהתקרית הזאת?

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

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

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

הכותב הוא טוני אנסקומבה, מומחה אבטחת מידע ESET
מסכים כחולים ESET CrowdStrike אבטחת סייבר

art

'בחדרי' גם ברשתות החברתיות - הצטרפו!

הוספת תגובה

לכתבה זו טרם התפרסמו תגובות

תגובות

הוסיפו תגובה
{{ comment.number }}.
{{ comment.date_parsed }}
הגב לתגובה זו
{{ reply.date_parsed }}