8.5 מיליון מחשבים קרסו מקובץ יחיד שאיש מהצד שלכם לא בדק

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

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

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

השדה ה-21

קראתי את ה-External Root Cause Analysis של CrowdStrike בלילה שבו פורסם, באוגוסט 2024, והסיבה הייתה כה קטנה עד שזה היה כמעט מעליב.

Falcon, החיישן של CrowdStrike, מספק לוגיקת זיהוי דרך מנגנון שהוא מכנה Rapid Response Content — עדכוני תצורה קטנים שמאפשרים לו להגיב לאיומים חדשים בלי לדחוף בינארי חדש לחלוטין. ב-19 ביולי, הוא שלח שני Template Instances חדשים לזיהוי תקשורת בין-תהליכית. אותם instances הפנו לפרמטר קלט 21. ה-Content Validator מבוסס-הענן של CrowdStrike בדק את העדכון מול הסכימה החדשה בת 21 השדות, ראה שהוא תקין, ואישר אותו.

הבעיה הייתה ה-Content Interpreter שרץ בתוך הקרנל של Windows, ב-Ring 0, השכבה בעלת ההרשאות הגבוהות ביותר של מערכת ההפעלה. הוא עדיין ציפה ל-20 שדות. כשהוא ניסה לגשת ל-21, הוא קרא זיכרון שלא היה קיים, והמכונה קרסה למסך כחול באופן מיידי.

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

הנה החלק שעדיין מטריד אותי הכי הרבה כמהנדס. הקריסה התרחשה כה מוקדם ברצף האתחול, עד שסוכן הניהול של Falcon עצמו כלל לא עלה. כך שנקודות הקצה לא יכלו לקבל את פקודת הביטול (rollback) ש-CrowdStrike שלחה, משום שהתוכנה שנועדה לקבל את הפקודה הזו הייתה הדבר שהקריס את המכונה. לתעשייה יש שם עגום לכך — לולאת הסוכן המת. השחזור לא היה כפתור. זה היה בן אדם, ליד כל מכונה, שמאתחל למצב בטוח (Safe Mode), מנווט אל C:\Windows\System32\drivers\CrowdStrike\, ומוחק את הקובץ הפגום C-00000291-*.sys ביד. דלתא עשתה זאת על פני 40,000 שרתים. השחזור ארך חמישה ימים.

זה מעולם לא היה קשור לספק אחד

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

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

המשכתי לשאול מנהלי אבטחת מידע (CISO) את אותה שאלה באותו קיץ: מי בודק את עדכוני הספקים האלה לפני שהם מגיעים לייצור? התשובה, בכל פעם, הייתה גרסה כלשהי של "יש לנו ועדת ייעוץ לשינויים." ואז, רגע לאחר מכן, החלק הכן: ועדת הייעוץ לשינויים בודקת פריסות פנימיות שורה אחר שורה, אבל עדכוני ספקים מדלגים על תור הכרטיסים, מדלגים על שלב ההכנה (staging), והולכים ישירות לכל נקודת קצה — משום ש"אנחנו סומכים על הספק." המשפט הזה נשא על גבו את כל התעשייה, ולא היה שום מנגנון מאחוריו.

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

הגרסה שבנינו תחילה, ומדוע היא נכשלה

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

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

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

Observability אומר לכם שהבניין בוער. עד אז השאלה היחידה שנותרה היא כמה ימים ייקח השחזור.

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

אז מדוע הכלים הקיימים אינם תופסים את זה?

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

כלי SBOM וניתוח הרכב תוכנה (software-composition-analysis) — Snyk, Sonatype — מבקרים את עץ התלויות של קוד פתוח שלכם. הם בנויים לומר לכם שאיזו חבילת npm בעומק שלוש רמות מכילה פגיעות ידועה. אבל ה-Rapid Response Content של ספק, קובץ ערוץ (channel file), בלוב תצורה קנייני שנחתם ונדחף על ידי CrowdStrike או כל עמית לה — זה בלתי נראה עבורם. זה לא נמצא בעץ התלויות שלכם. זה נדחף מסביב לו, הישר אל תוך הקרנל. הכלים שנועדו לאבטח את שרשרת האספקה של התוכנה שלכם מבקרים לחלוטין את השכבה הלא נכונה.

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

והתיקון של CrowdStrike עצמה — מצב שחזור-עצמי, נעיצת תוכן (content pinning), "בקרות פריסה ללקוח" מדורגות, מסגרת Resilient-by-Design ששאולה מ-CISA — היא עבודה אמיתית, ואני לא מזלזל בה. אבל קראו מה זה באמת: כל אחת מהבקרות האלה היא פיקוח-עצמי של הספק. אותה חברה ששלחה את השדה ה-21 היא זו שמאשרת שזה בטוח כעת. עדיין אין שום גורם עצמאי שעומד בין הדחיפה של הספק לבין נקודת הקצה שלכם. שימור ההכנסות הגולמי של CrowdStrike עמד מעל 97% ברבעון שאחרי ההשבתה, מה שמלמד אתכם שהשוק לא העניש אותה — ולא מלמד אתכם דבר על השאלה אם הפער הבסיסי נסגר. הוא לא.

הפער הזה הוא כל המוצר. המקום הנכון לעמוד בו אינו בנקודת הקצה, מחכה לאש, ואינו בתוך הספק, סומך על מילתו. הוא באמצע: מחסום בקרה נייטרלי-לספק שלוקח את העדכון לפני שהוא מגיע לייצור, מריץ אותו דרך ארגז חול (sandbox) שמשקף את הצי האמיתי שלכם, בודק את התוכן מול מה שהקרנל שלכם באמת מצפה לו, ומדמה את רדיוס הפגיעה אם הוא שגוי. זו השכבה שבסופו של דבר בנינו, ותוכלו לראות את צורתה בעמוד הפתרון שלנו. אי-התאמת סכימה כמו הבאג של 21-מול-20 שדות היא בדיוק סוג הדבר שארגז חול טרום-פריסה חושף בטבעת canary במקום על פני 8.5 מיליון מכונות בבת אחת.

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

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

נתחיל עם Delta נגד CrowdStrike. במאי 2025, בבית המשפט המחוזי של מחוז פולטון, השופט Ellerbe התיר להמשיך בתביעות בגין רשלנות חמורה, חדירה למחשב, ותרמית במחדל — מעבר לתקרת האחריות החוזית של CrowdStrike. רכיב החדירה-למחשב הוא זה שאמור לגרום לכל מנהל אבטחת מידע להזדקף: דלתא ביטלה את ההסכמה לעדכונים אוטומטיים, וקובץ הערוץ הגיע לקרנל בכל זאת. אם ספק יכול לדחוף תוכן Ring 0 דרך ערוץ שההגדרות שלכם אינן שולטות בו, ייתכן שהעדפות העדכון בהסכם שלכם אינן ניתנות לאכיפה. רוב הסכמי ה-MSA הארגוניים אפילו אינם מבחינים בין עדכון חיישן מלא לבין rapid-response content. הם צריכים.

ואז האיחוד האירופי פעל, וזה החלק שאני מעלה כעת בכל משא ומתן מחודש על חוזה שאני יושב בו. הדירקטיבה המתוקנת לאחריות למוצר מסווגת כעת תוכנה במפורש כ"מוצר" תחת אחריות מוחלטת, ואומרת שחברות אינן יכולות לשלול חוזית אחריות לפגמים בתוכנה ובאבטחת סייבר. תקרת האחריות של מיליונים בודדים שהספק שלכם הקיף בעיגול בחוזה עשויה פשוט לא לעמוד בתוקף בתחומי השיפוט של האיחוד האירופי. לצדה, ה-EU Cyber Resilience Act מתחיל דיווח חובה על פגיעויות ב-11 בספטמבר 2026 — שעון בן 24 שעות אשר, וזה קריטי, מתחיל לפעול כאשר אתם נעשים מודעים, לא כאשר הספק מודיע לכם. השבתה של ספק יכולה להפוך לחובת הדיווח שלכם, במהירות.

ובארצות הברית, ה-SEC דורש כעת מחברות ציבוריות לחשוף אירועי אבטחת סייבר מהותיים בתוך ארבעה ימי עסקים ולתאר את הסיכון בשרשרת אספקת התוכנה בדיווחי ה-10-K שלהן. עשו את החשבון עם נתוני העלות: מחקר New Relic מספטמבר 2025 העמיד את העלות החציונית של השבתת IT משמעותית על 2 מיליון דולר לשעה, ו-41% מהארגונים הבינוניים-עד-גדולים נוקבים במספר משלהם, בין 1 מיליון ל-5 מיליון דולר לשעה. השבתה של ארבע שעות מעדכון ספק שוועדת השינויים שלכם מעולם לא ראתה חוצה את סף המהותיות בפני עצמה. צוות קשרי המשקיעים שלכם זקוק לתרחיש פעולה להשבתת ספק, לא רק לתרחיש פעולה לפריצה.

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

"האם זה יכול לקרות לנו?"

אחרי יולי 2024, כל דירקטוריון בעולם שאל את מנהל אבטחת המידע שלו את אותן ארבע מילים. ומנהלי אבטחת המידע שאיתם דיברתי ברובם לא היו להם תשובה מובנית — וזו אינה ביקורת עליהם. נתוני IANS Research מתחילת 2026 מצאו שרק 29% מחברי הדירקטוריון רואים בדיווח האבטחה של מנהל אבטחת המידע שלהם "אפקטיבי מאוד", וסיכון פריסת העדכונים הוא בדיוק סוג הדבר שהוא אמיתי, יקר, וכמעט בלתי אפשרי לנקוב בו במספר עם הכלים שיש לרוב הצוותים.

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

אנשים שואלים אותי אם זה באמת נחוץ עכשיו כשמיקרוסופט דוחפת את ספקי האבטחה אל מחוץ לקרנל — ה-Windows Resiliency Initiative, עם Quick Machine Recovery והמעבר ההדרגתי של אבטחת נקודות הקצה ממצב קרנל (kernel mode) למצב משתמש (user mode). זהו שינוי מבני טוב באמת, והוא יצמצם עם הזמן את רדיוס הפגיעה הגרוע ביותר. אבל לוח הזמנים משתרע על פני 2026 ו-2027, תבלו את כל אותו חלון בהרצת צי מעורב באמצע ההגירה, ו"פחות קטסטרופלי" אינו "מאומת". סוכן במצב משתמש ששולח תצורה פגומה עדיין יכול להפיל את מה שהוא אחראי עליו. הצורך בבדיקה עצמאית אינו נעלם כשהקרנל נעלם; הוא פשוט עולה שכבה אחת מעלה.

הדבר האחר שאנשים אומרים הוא שהוספת מחסום בקרה מאטה הכול — שכל העניין של Rapid Response Content הוא מהירות מול איומים חיים. הוגן. אבל הבחירה מעולם לא הייתה מהירות מול בטיחות. מאמת הענן של CrowdStrike רץ מהר ובכל זאת אישר את העדכון השבור, משום שבדק את הקובץ מול הסכימה החדשה ומעולם לא בדק שהקרנל מסכים. המהירות לא הייתה הכשל. היעדר בדיקה עצמאית היה הכשל. טבעת canary שתופסת אי-התאמת סכימה ב-30 מכונות עולה לכם דקות. החלופה עלתה לדלתא חמישה ימים ו-550 מיליון דולר.

מה בעצם משמעו של הלוח הכחול?

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

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

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