שלמות פריסת עדכוני תוכנה
ב-19 ביולי 2024, קובץ תצורה בודד הקריס 8.5 מיליון מכונות Windows בפחות מ-90 דקות. לא תוכנה זדונית. לא פגיעות יום-אפס. עדכון שגרתי מספק מהימן שדילג על שלב ההיערכות (staging), דילג על canary, ופגע בכל נקודת קצה בגל אחד.
אם כבר בחנתם את סיכון העדכונים שלכם בעקבות CrowdStrike, השאלה היא האם אותה בחינה הייתה מהלך חד-פעמי או יכולת קבועה. אם לא בחנתם, הנוף המשפטי והרגולטורי השתנה תחת רגליכם מאז יולי 2024. כך או כך, הפער זהה: אין שכבה עצמאית שיושבת בין צינורות העדכון של הספקים שלכם לבין נקודות הקצה בייצור שלכם.
$10B+
נזקים גלובליים מהשבתת CrowdStrike
Fortune/Parametrix, 2024
$2M/hr
עלות חציונית של השבתת IT משמעותית
New Relic, ספטמבר 2025
8-12
סוכנים ברמת הליבה (kernel) על נקודת קצה ארגונית טיפוסית
נתוני סקר בענף
חיישן Falcon של CrowdStrike משתמש במנגנון "Rapid Response Content" כדי לדחוף עדכוני לוגיקת זיהוי מבלי לדרוש עדכון בינארי מלא. ב-19 ביולי, שני Template Instances חדשים נפרסו לזיהוי תקשורת בין-תהליכית. מופעים אלה הפנו לפרמטר קלט מספר 21. מאמת התוכן (Content Validator) מבוסס-הענן בדק את העדכון מול הסכמה החדשה בת 21 השדות ואישר אותו. אך מפרש התוכן (Content Interpreter) שרץ בליבת Windows עדיין ציפה ל-20 שדות בלבד.
| רכיב | מיקום | שדות צפויים | מה קרה |
|---|---|---|---|
| Content Validator | ענן | 21 שדות | אישר את העדכון (תאם לסכמה החדשה) |
| Content Interpreter | ליבת נקודת הקצה (Ring 0) | 20 שדות | קריאת זיכרון מחוץ לתחום, BSOD מיידי |
מקור: ניתוח שורש הבעיה החיצוני של CrowdStrike, 6 באוגוסט 2024
הקריסה התרחשה כה מוקדם ברצף האתחול שסוכן הניהול של Falcon מעולם לא אותחל. הדבר יצר לולאת "סוכן מת": נקודות הקצה לא יכלו לקבל פקודת rollback מ-CrowdStrike משום שהתוכנה שאמורה לקבל את הפקודה הייתה גורם הקריסה. צוותי IT נאלצו לאתחל כל מכונה ל-Safe Mode, לנווט אל C:\Windows\System32\drivers\CrowdStrike\, ולמחוק ידנית את הקובץ הפגום C-00000291-*.sys . Delta Air Lines עשתה זאת ברחבי 40,000 שרתים. ההתאוששות ארכה חמישה ימים.
CrowdStrike היא חקר המקרה, אך התבנית חלה על כל ספק שדוחף עדכונים בעלי הרשאות. הצי שלכם מריץ סוכן EDR, סוכן DLP, סוכן הצפנה, סוכן עדכונים (patching), לקוח VPN, וסוכן ניהול מכשירים. כל אחד פועל ברמת הליבה או עם הרשאות מערכת מוגברות. לכל אחד יש ערוץ עדכון משלו. כל אחד דוחף עדכונים בלוח הזמנים שלו. ועדת ייעוץ השינויים (CAB) שלכם בוחנת פריסות פנימיות אך מעבירה עדכוני ספקים בלי בדיקה כי "אנחנו סומכים על הספק".
מצב הכשל השני שאיש אינו דן בו: מפלי קונפליקט בין סוכנים. כששני ספקים מעדכנים ממשקי ליבה באותו יום, בעיות תאימות מנהלי התקנים יכולות להפיק את אותה תוצאת מסך כחול כמו כשל של ספק יחיד. אך ניתוח שורש הבעיה אורך שבועות במקום שעות כי אתם מבצעים שילוב נקודות בין שני צוותי תמיכה של ספקים שכל אחד מאשים את העדכון של האחר.
העלות של "אנחנו סומכים על הספק"
41% מהארגונים בגודל בינוני עד גדול מעריכים את עלות ההשבתה שלהם ב-$1M-$5M לשעה. ארגונים בתחומי הפיננסים והבריאות מדווחים על $5M+ לשעה. השבתה בת 4 שעות מעדכון ספק שה-CAB שלכם מעולם לא בחן עולה יותר מכל ההוצאה השנתית שלכם על כלי אבטחה. (ITIC / New Relic, 2025)
השבתת CrowdStrike הפיקה יותר מתיקון טכני. היא שינתה את המסגרת המשפטית סביב אחריות ספקי תוכנה. שלוש התפתחויות חשובות לחידוש חוזה הספק הבא שלכם.
מאי 2025 | בית המשפט העליון של מחוז Fulton
השופט Ellerbe התיר את התביעות בגין רשלנות חמורה, הסגת גבול מחשבית, ו מרמה במחדל להתקדם חרף תקרת האחריות החוזית של CrowdStrike. Delta בחרה לבטל את העדכונים האוטומטיים, אך קובץ הערוץ עקף את ההעדפה הזו ברמת הליבה.
החשיפה שלכם: אם הספק שלכם יכול לדחוף תוכן ל-Ring 0 דרך ערוץ שההגדרות שלכם אינן שולטות בו, ייתכן שהעדפות העדכון בחוזה שלכם בלתי-אכיפות. בחנו האם ההסכם שלכם מבחין בין עדכוני חיישן מלאים לבין rapid response content.
הדיווח מתחיל ב-11 בספטמבר 2026
דיווח חובה על פגיעויות תוך 24 שעות ל-ENISA. ספקי תוכנה חייבים להוכיח security-by-design בתהליכי העדכון שלהם, כולל אימות מתועד ויכולת rollback.
החשיפה שלכם: אם עדכון ספק גורם להשבתה בפעילות שלכם באיחוד האירופי, ייתכן שיש לכם חובות דיווח תוך 24 שעות, בנפרד מאלו של הספק. השעון מתחיל לרוץ כשאתם נעשים מודעים, לא כשהספק מודיע לכם.
תוקנה ב-2024, נכנסת לתוקף ב-2026
תוכנה מסווגת כעת במפורש כ"מוצר" תחת אחריות מוחלטת (strict liability). חברות אינן יכולות לשלול אחריות באופן חוזי בגין פגמי תוכנה ואבטחת סייבר. הדבר חל על תוכנה עצמאית ועל תוכנה המוטמעת במוצרים.
החשיפה שלכם: ייתכן שתקרות אחריות הספק בהסכמי המינוי שלכם לא יחזיקו מעמד בתחומי השיפוט של האיחוד האירופי. אם אתם פועלים בשווקי האיחוד האירופי, החוזים שלכם צריכים לשקף את השינוי הזה.
דרישת הגילוי של ה-SEC
חברות ציבוריות חייבות כעת לגלות אירועי אבטחת סייבר מהותיים תוך 4 ימי עסקים ולתאר את חשיפת הסיכון בשרשרת אספקת התוכנה במסגרת גורמי הסיכון בדיווחי ה-10-K. השבתה שנגרמה על-ידי ספק שעולה $2M לשעה במשך 4+ שעות צפויה לחצות את סף המהותיות. צוות יחסי המשקיעים (IR) שלכם זקוק ל-playbook להשבתת ספק, לא רק ל-playbook לפרצה. (כלל סופי של ה-SEC, נכנס לתוקף ב-2024)
כל שחקן במרחב הזה פותר חלק מהבעיה. אף אחד לא פותר את כל הדבר. הפער הוא בין מה שספקים עושים לתהליכי העדכון שלהם עצמם לבין מה שאתם יכולים לאמת באופן עצמאי.
| שחקן | מה הם מציעים | הפער |
|---|---|---|
| CrowdStrike (לאחר האירוע) | מצב התאוששות עצמית, נעילת תוכן (content pinning), בקרות פריסה ללקוח, Digital Operations Center. שימור ברבעון השלישי של 2025: 97%+ | פיקוח עצמי של הספק. שיפורי האימות שלהם משמעותיים, אך אתם סומכים על אותו ארגון לאמת את עדכוניו שלו. אין שכבת אימות עצמאית. |
| Microsoft (Windows Resiliency Initiative) | Quick Machine Recovery (זמין כללית ב-Win 11 24H2). Endpoint Security Platform מעבירה מוצרי אבטחה ממצב ליבה (kernel) למצב משתמש (user mode). לוח זמני מעבר 2026-2027. | ברמת הפלטפורמה, לא ברמת הביקורת. מטפל בהתאוששות אתחול ומצמצם את שטח הפנים של הליבה, אך אינו מאמת כיצד ספקים אחרים פורסים עדכונים לצי שלכם. |
| SentinelOne / Palo Alto (Cortex XDR) | הגנת נקודות קצה אוטונומית עם צינורות העדכון שלהם עצמם. חלופות תחרותיות ל-CrowdStrike. | אותו סיכון מבני. הם דוחפים עדכונים ברמת הליבה דרך הערוצים שלהם עצמם. ספק שונה, אותה בעיית "מי שומר על השומרים?". |
| Datadog / Dynatrace / Splunk | תצפיתיות (observability) מונעת-AI, זיהוי חריגות, התראות בזמן אמת. קליטת נתונים בשלה בקנה מידה ארגוני. | תגובתי, לא מונע. הם מזהים חריגות לאחר שהעדכון מגיע לייצור. עד ש-Datadog מתריע, ה-BSoD כבר התפשט במפל. |
| כלי SBOM / SCA (Snyk, Sonatype) | סריקת תלויות קוד פתוח, ניתוח הרכב תוכנה (software composition analysis), מעקב אחר פגיעויות. | שכבה שגויה לחלוטין. הם מבקרים ספריות קוד פתוח בקוד שלכם. קובץ הערוץ של CrowdStrike היה תצורת ספק קניינית, לא תלות קוד פתוח. הכלים האלה מעולם אינם רואים אותו. |
| פלטפורמות ITSM (ServiceNow, Jira) | תהליכי ניהול שינויים, בחינת CAB, מסלולי ביקורת לפריסות פנימיות. | עדכוני ספקים עוקפים את ה-CAB. ה-ITSM שלכם עוקב אחר שינויים שהצוות שלכם מבצע. עדכונים שספקים דוחפים לסוכני ליבה עוקפים את התהליך לחלוטין. אין קריאת שירות, אין בחינה, אין מסלול ביקורת. |
| Big 4 / משלבי מערכות גדולים (SIs) | הערכות סיכוני IT, ביקורות ציות, עיצוב מסגרות ממשל. ל-Deloitte, Accenture, KPMG יש לכולן תחומי עיסוק באבטחת סייבר. | עתיר-מסגרות, לא טכני. הם מספקים מודלים של בשלות ממשל, לא ארגזי חול (sandboxes) טרום-פריסה. הערכה בת 6 חודשים מפיקה דוח. אתם זקוקים למערכת אוטומטית שמיירטת עדכונים בזמן אמת. בנוסף: מינימום התקשרות של $500K+ להערכות בקנה מידה ארגוני. |
הסתייגות כנה: חלק מהפערים ברשימה הזו אינם פתירים על-ידי שום ייעוץ חיצוני. ניהול שינוי ארגוני (לגרום ל-CAB שלכם באמת לבחון עדכוני ספקים), פוליטיקת יחסי הספקים (לומר ל-CrowdStrike שאתם לא סומכים על תהליך העדכון שלהם), ומגוון נקודות קצה מדור קודם (legacy) (מכונות שמריצות Windows Server 2012 שלא ניתן לווירטואליזציה בארגז חול) דורשים בעלות פנימית. אנחנו בונים את התשתית הטכנית. הצוות שלכם חייב להשתמש בה.
חמש יכולות, שכל אחת מטפלת בפער מסוים בנוף שלמעלה. כל התקשרות מותאמת אישית, אך הארכיטקטורה עוקבת אחר תבניות שעיצבנו לסביבות עם 5,000+ נקודות קצה ו-6+ סוכנים ברמת הליבה.
אנחנו ממפים כל סוכן ברמת הליבה ובעל הרשאות שרץ בצי שלכם. לכל סוכן, אנחנו מתעדים את מכניקת ערוץ העדכון, יכולת ה-rollback, בקרות ההיערכות (staging) (או היעדרן), ומה קורה כשהסוכן עצמו הוא מקור הקריסה.
תוצר: מצאי סוכנים מדורג-סיכון המראה אילו ספקים יכולים לדחוף עדכונים ל-Ring 0 ללא בחינת CAB, אילו סוכנים יוצרים לולאות סוכן-מת אם הם מקריסים את רצף האתחול, ואילו חוזי ספקים חסרים ערובות לפריסה מדורגת. רוב הארגונים מגלים סוכנים שלא ידעו שרצים ברמת הליבה.
אנחנו בונים סביבה וירטואלית שמשקפת את מגוון נקודות הקצה האמיתי שלכם: גרסאות מערכת הפעלה, רמות תיקון (patch levels), פרופילי חומרה, ומחסנית הסוכנים המלאה שאתם מריצים בייצור. קריסת CrowdStrike באה לידי ביטוי רק עם בנייות (builds) מסוימות של Windows ותצורות מנהלי התקנים מסוימות. מכונה וירטואלית נקייה בודדת הייתה מחמיצה אותה.
כשספק קריטי דוחף עדכון, ארגז החול מקבל אותו ראשון, מריץ אותו דרך 5 מחזורי אתחול על-פני תצורות מייצגות, ומאמת תאימות סכמה. אנחנו מדגמים את שילובי מחסנית הסוכנים הספציפיים שלכם, משום שקונפליקטים בין סוכנים (לדוגמה, EDR והצפנה שמעדכנים את אותה טבלת callback של הליבה באותו יום) הם מצב הכשל שאיש אינו בודק.
לאחר Delta v. CrowdStrike, כל הסכם מינוי לספק דורש בחינה. אנחנו מנתחים את החוזים שלכם לאיתור תקרות אחריות, סעיפי עדכון כפוי, חשיפה ל"הסגת גבול מחשבית", חובות הודעה, ופערי SLA. אנחנו מצליבים מול ה-EU CRA, הוראת אחריות המוצר, ודרישות הגילוי של ה-SEC כך שהתיקונים יחזיקו מעמד על-פני תחומי שיפוט.
תוצר: ניסוח ספציפי לתיקון חוזה שהצוות המשפטי שלכם יכול להשתמש בו בחידוש הבא. אנחנו מסמנים אילו ספקים מבחינים בין עדכונים בינאריים מלאים לבין rapid response content בהסכמיהם, לאילו חוזים יש החרגות לגישה ברמת הליבה, ואילו תקרות אחריות בסיכון תחת התקדים של Delta.
אנחנו בונים תהליכים אוטומטיים שמיירטים עדכוני ספקים לפני שהם מגיעים לנקודות הקצה בייצור. המערכת משתלבת עם ה-ITSM שלכם (ServiceNow, Jira Service Management), יוצרת מסלולי ביקורת שה-CAB חסר כיום עבור עדכונים שספקים דוחפים, ואוכפת מדיניות פריסה מדורגת שהספק עשוי שלא לתמוך בה באופן מובנה.
המערכת עוקבת אחר שינויי סכמה בעדכונים ברמת התצורה, חריגות הפרש בינארי (binary diff) שמצביעות על שינוי גדול ממה שהספק תיעד, וקפיצות במהירות הפריסה (כל נקודות הקצה בגל אחד, התואמות את תבנית הכשל של CrowdStrike). התראות מנותבות לצוות תפעול האבטחה שלכם עם מספיק הקשר כדי לקבל החלטת עצירה/המשך תוך דקות.
רק 29% מחברי הדירקטוריון מוצאים את דוחות אבטחת הסייבר של ה-CISO כ"אפקטיביים מאוד" (IANS Research, 2026). אנחנו בונים מסגרת דיווח שמכמתת את סיכון פריסת עדכוני התוכנה שלכם במונחים שהדירקטוריון מבין: חשיפה כספית לכל שעת השבתה בהתבסס על הפעילות העסקית בפועל שלכם, אחריות רגולטורית הממופה לחוקים ספציפיים (EU CRA, לוחות זמני הגילוי של ה-SEC), וסיכון ריכוז ספקים המראה איזה כשל של ספק יחיד יגרום להשבתה הרחבה ביותר.
זהו תוצר רבעוני, לא לוח מחוונים. כל דוח כולל ציוני סיכון מעודכנים, שינויים מאז הרבעון הקודם (עדכוני ספקים חדשים, חידושי חוזים, התפתחויות רגולטוריות), והמלצות ספציפיות המדורגות לפי עלות-תיקון מול הפחתת-חשיפה. ה-CISO שלכם נכנס לוועדת הביקורת עם מספרים, לא עם נרטיב.
ארבעה שלבים. השניים הראשונים רצים במקביל ומושלמים בדרך כלל תוך 4-6 שבועות. היישום אורך 6-10 שבועות בהתאם לגודל צי נקודות הקצה ומספר הספקים. התמיכה השוטפת היא רבעונית.
שבועות 1-3
שבועות 2-5 (במקביל לשלב 1)
שבועות 6-14
רבעונית
הסתייגות: התמיכה השוטפת היא אופציונלית. המערכת שאנחנו בונים בשלב 3 מתוכננת לרוץ עם הצוות הפנימי שלכם. אנחנו נשארים מעורבים כשתרצו מומחיות ניטרלית-לספק סביב השולחן במהלך חידושים או שינויים רגולטוריים.
עשר שאלות על ממשל העדכונים הנוכחי שלכם. התוצאות נותנות לכם רשימת פעולה מתועדפת שתוכלו לבצע ללא קשר אם אתם עובדים איתנו. לוקח כ-3 דקות.
התחילו במיפוי כל סוכן ברמת הליבה ובעל הרשאות שרץ בצי שלכם. רוב הארגונים מגלים שהם מריצים 8-12 סוכנים (EDR, DLP, הצפנה, VPN, MDM, patching) ואין להם רישום מרכזי של איזה ספק יכול לדחוף עדכונים ל-Ring 0 מבלי לעבור דרך בחינת ועדת ייעוץ השינויים (CAB).
עבור כל סוכן, תעדו שלושה דברים: מכניקת ערוץ העדכון (האם הוא דוחף rapid response content כמו קובצי הערוץ של CrowdStrike, או רק בנייות חיישן מלאות?), יכולת ה-rollback (האם הסוכן יכול לשחזר את עצמו אם הוא מקריס את רצף האתחול, או שהוא יוצר לולאת סוכן-מת כפי שעשה Falcon של CrowdStrike?), ובקרות ההיערכות (staging) שהחוזה שלכם באמת מעניק לכם (לא מה ששיווק הספק אומר, אלא מה שהסכם המינוי מתיר לכם לעכב או לדחות).
לאחר מכן בססו ארגז חול טרום-פריסה שמשקף את מגוון נקודות הקצה האמיתי שלכם. עדכון ה-19 ביולי של CrowdStrike הקריס בנייות Windows ספציפיות עם תצורות מנהלי התקנים ספציפיות. ארגז חול שמריץ מכונה וירטואלית נקייה בודדת היה מחמיץ אותו. אתם זקוקים לפרופילי חומרה מייצגים, רמות תיקון מערכת הפעלה, ושילובי סוכנים. הריצו כל עדכון ספק קריטי דרך 5 מחזורי אתחול על-פני התצורות האלה לפני שהוא מגיע לייצור.
לבסוף, בחנו את חוזי הספקים שלכם. לאחר Delta v. CrowdStrike, סעיפי עדכון כפוי ותקרות אחריות הם יעדים להתדיינות משפטית. אם בהסכם שלכם עדיין יש תקרת אחריות חד-ספרתית במיליונים ואין ערובה לפריסה מדורגת, יש לכם פער חוזי שתואם את הפער הטכני.
ביקורת עדכוני ספקים דורשת נראות לשלוש שכבות שלרוב הארגונים חסרות. שכבה 1: ארכיטקטורת ערוץ העדכון. בקשו תיעוד טכני מכל ספק על האופן שבו העדכונים שלהם חוצים מהפיתוח אל נקודות הקצה שלכם. במיוחד, שאלו האם עדכונים ברמת התצורה (כמו קובצי הערוץ של CrowdStrike) עוקבים אחר אותו צינור אימות כמו עדכונים בינאריים מלאים, או שהם נוקטים בקיצור דרך. ל-Content Validator ול-Content Interpreter של CrowdStrike היו ציפיות סכמה שונות. אי-ההתאמה הזו הייתה שורש הבעיה.
שכבה 2: מהירות פריסה ובקרות רדיוס הדף. בקשו מכל ספק לתעד את קצב הפריסה המדורגת שלהם. בכמה טבעות פנימיות הם משתמשים? איזה אחוז מהלקוחות החיצוניים מקבלים את העדכון בגל הראשון? CrowdStrike דחפה לכל 8.5 מיליון נקודות הקצה בגל אחד. החוזה שלכם צריך לציין רדיוס הדף מרבי לכל שלב פריסה.
שכבה 3: יכולת rollback והתאוששות. עבור כל ספק, בדקו מה קורה כשהסוכן שלהם גורם לכשל אתחול. האם תהליך הניהול של הסוכן יכול לקבל פקודת rollback אם הסוכן עצמו הוא מקור הקריסה? סוכן הניהול של CrowdStrike מעולם לא אותחל כי הקריסה התרחשה מוקדם מדי ברצף האתחול, ויצרה נקודות קצה יתומות שדרשו התערבות Safe Mode ידנית בכל מכונה.
אנחנו בונים מסגרות ביקורת אוטומטיות שמאמתות ברציפות את שלוש השכבות האלה, מסמנות סטיות מנהלים מתועדים, ומפיקות כרטיסי ניקוד ספקים שצוות האבטחה שלכם יכול לבחון מדי רבעון.
פריסת canary לאבטחת נקודות קצה שונה תפעולית מפריסת canary לשירותי אינטרנט. אינכם יכולים לנתב 1% מהתעבורה לגרסה חדשה. אתם זקוקים לטבעות מגוון חומרה שתואמות את הרכב הצי האמיתי שלכם.
Ring 0 הוא ארגז החול הטרום-פריסה שלכם: סביבות וירטואליות המכסות את מטריצת מערכות ההפעלה שלכם (Windows Server 2019, 2022, Windows 10 22H2, 11 23H2, וכו'), רמות תיקון, ומחסנית הסוכנים המלאה שאתם מריצים בייצור. הטבעת הזו תופסת אי-התאמות סכמה וקונפליקטים של מנהלי התקנים לפני שנקודת קצה אמיתית כלשהי נחשפת. Ring 1 הוא המכונות של מחלקת ה-IT שלכם עצמה, בדרך כלל 50-200 נקודות קצה. אלה מאוישות על-ידי אנשים שיכולים לדווח על חריגות בפירוט ולשאת בנייה מחדש אם משהו נכשל.
Ring 2 הוא מדגם מייצג של נקודות קצה בייצור, נבחר למגוון חומרה, לא לנוחות. אם הצי שלכם כולל thin clients, מכונות קיוסק, ובקרי דומיין, Ring 2 חייב לכלול את כל השלושה. אל תבחרו סתם 500 מחשבים שולחניים סטנדרטיים. Ring 3 הוא גל רחב יותר, בדרך כלל 10-20% מהייצור, עם חלונות מעקב בני 24 שעות בין שלבים. Ring 4 הוא היתרה.
כל טבעת זקוקה לחלון מעקב מוגדר (מינימום 4 שעות ל-Ring 1, 24 שעות ל-Ring 2+), בדיקות תקינות אוטומטיות (הצלחת אתחול, פעימת לב של סוכן, דוחות קריסת ליבה), ומפעיל rollback שעוצר את הפריסה אם שיעור הכשל חורג מסף שאתם קובעים, לא הספק. המפתח הוא שהטבעות שלכם חייבות להיאכף בצד שלכם, לא להיות מואצלות לבקרות הפריסה של הספק. אנחנו בונים את תשתית הטבעות, ניטור התקינות האוטומטי, ומפעילי ה-rollback כמערכת שיושבת בין הצי שלכם לבין ערוץ העדכון של כל ספק.
פסיקת מאי 2025 בבית המשפט העליון של מחוז Fulton שינתה את חישוב הסיכון עבור כל ארגון שמריץ תוכנת אבטחה של צד שלישי. השופטת Kelly Lee Ellerbe התירה את תביעות Delta בגין רשלנות חמורה, הסגת גבול מחשבית, ומרמה במחדל להתקדם חרף טענת CrowdStrike כי הסכם שירותי המינוי (Subscription Services Agreement) הגביל את האחריות לערך החוזה.
שלוש השלכות חשובות לחוזי הספקים שלכם. ראשית, סעיפי עדכון כפוי הם כעת יעדים להתדיינות משפטית. Delta בחרה לבטל עדכונים אוטומטיים בהגדרותיה, אך מנגנון קובץ הערוץ ברמת הליבה של CrowdStrike עקף את ההעדפה הזו. אם הספק שלכם יכול לדחוף תוכן ל-Ring 0 דרך ערוץ שההגדרות שלכם אינן שולטות בו, ייתכן שהעדפות העדכון בחוזה שלכם בלתי-אכיפות. בחנו האם ההסכם שלכם מבחין בין עדכוני חיישן מלאים לבין rapid response content.
שנית, ייתכן שתקרות אחריות לא יחזיקו מעמד תחת תביעות נזיקין. בית המשפט פסק שחובות סטטוטוריות בנוגע להסגת גבול מחשבית קיימות באופן עצמאי מהסכם המינוי. אם עדכון של ספק מהווה גישה בלתי-מורשית למערכות שלכם, התקרה החוזית אינה רלוונטית. הצוות המשפטי שלכם צריך לנהל משא ומתן על החרגות מפורשות לגישה ברמת הליבה ועל חובות פריסה מדורגת מחייבות.
שלישית, הוראת אחריות המוצר של האיחוד האירופי מסווגת כעת תוכנה כמוצר תחת אחריות מוחלטת. חברות אינן יכולות לשלול אחריות באופן חוזי בגין פגמי תוכנה החל מ-2026. אם אתם פועלים בתחומי שיפוט של האיחוד האירופי, הסכמי הספקים שלכם צריכים לשקף זאת. אנחנו מבקרים חוזי ספקים מול שלושת הממדים האלה ומנסחים ניסוח תיקון ספציפי למחזור החידוש הבא שלכם.
חובות דיווח הפגיעויות של חוק החוסן הקיברנטי של האיחוד האירופי מתחילות ב-11 בספטמבר 2026. אם אתם מייצרים, מפיצים, או מייבאים תוכנה עם רכיבים דיגיטליים לשוק האיחוד האירופי, עליכם לדווח על פגיעויות המנוצלות באופן פעיל תוך 24 שעות ל-ENISA, לספק הודעה מפורטת תוך 72 שעות, ולהנפיק דוח סופי תוך 14 ימים.
עבור ארגונים שצורכים תוכנת צד שלישי (כולל סוכני אבטחת נקודות קצה), ה-CRA יוצר שלוש חובות ציות. ראשית, בדיקת נאותות לגבי ספקים. עליכם לוודא שספקי התוכנה שלכם עומדים בדרישות ה-CRA, כולל security-by-design בתהליכי העדכון שלהם, טיפול מתועד בפגיעויות, וערובות שלמות עדכון. אם הספק שלכם דחף עדכון מסוג CrowdStrike ללא פריסה מדורגת, ייתכן שזה אינו עומד בתקן security-by-design של ה-CRA.
שנית, תהליכי העדכון שלכם עצמכם. אם אתם בונים או משלבים תוכנה הנפרסת בשווקי האיחוד האירופי, צינורות ה-CI/CD שלכם חייבים להוכיח אימות אבטחה, אימות שלמות עדכון, ויכולת rollback מתועדת.
שלישית, שרשרת דיווח אירועים. אם עדכון ספק גורם להשבתה בפעילות שלכם באיחוד האירופי, ייתכן שיש לכם חובות דיווח ל-ENISA תוך 24 שעות, בנפרד מחובותיו של הספק עצמו. שעון הדיווח מתחיל לרוץ כשאתם נעשים מודעים, לא כשהספק מודיע לכם. מעבר ל-CRA, הוראת אחריות המוצר המתוקנת של האיחוד האירופי מסווגת תוכנה כמוצר תחת אחריות מוחלטת, ויצרנים אינם יכולים לשלול אחריות באופן חוזי בגין פגמי אבטחה. אנחנו בונים מסגרות ממשל עדכונים מוכנות-ל-CRA: שאלוני הערכת ספקים המיושרים לדרישות ה-CRA, כלי אימות צינור פנימי, ותהליכי דיווח אירועים העומדים בלוחות הזמנים של 24/72 שעות.
ה-Windows Resiliency Initiative של Microsoft, שהוכרזה לאחר השבתת CrowdStrike, כוללת שינוי יסודי: העברת מוצרי אבטחת נקודות קצה של צד שלישי ממצב ליבה (Ring 0) למצב משתמש. תכונת Quick Machine Recovery כבר זמינה כללית ב-Windows 11 24H2, ומאפשרת תיקון מרחוק גם כשמכונות אינן יכולות לאתחל באופן רגיל. השינוי הגדול יותר, ה-Windows Endpoint Security Platform, הוא מסלול מעבר מובנה לספקי אבטחה לפעול מחוץ לליבה תוך שמירה על יכולת זיהוי.
המעבר הזה יתפרס לאורך 2026-2027 ויוצר שלושה אתגרים מעשיים לארגונים. ראשית, ספקי האבטחה שלכם ישלחו עדכונים ארכיטקטוניים משמעותיים יותר מכל קובץ ערוץ. המעבר ממצב-ליבה למצב-משתמש הוא שכתוב יסודי של האופן שבו הסוכן מיירט קריאות מערכת, מנטר פעולות קבצים, ובוחן תעבורת רשת. בדקו את המעברים האלה בנחישות. השינוי הארכיטקטוני עצמו נושא את אותו סיכון רדיוס-הדף כמו אירוע CrowdStrike.
שנית, במהלך תקופת המעבר, תריצו צי מעורב: חלק מנקודות הקצה על סוכני מצב-ליבה, חלק על סוכני מצב-משתמש, חלק על גרסאות שחוצות את שניהם. אכיפת מדיניות האבטחה שלכם, כללי הזיהוי, ו-playbooks של תגובה לאירועים צריכים להביא בחשבון את חוסר העקביות הזה.
שלישית, לא כל הספקים יעברו באותו קצב. ל-CrowdStrike, SentinelOne, ו-Palo Alto יש לכל אחד לוחות זמנים שונים. אם אתם מריצים מספר סוכני אבטחה, לוחות הזמנים של המעבר שלהם יחפפו באופן שונה, ויצרו סיכוני תאימות חדשים. אנחנו ממפים את ארכיטקטורת הסוכנים הנוכחית שלכם, בונים תוכנית מעבר מדורגת שמסדרת את מעברי הספקים כדי למזער סיכון חפיפה, ומבססים שערי אימות לכל שלב במעבר ממצב-ליבה למצב-משתמש.
המחקר שמאחורי עמוד הפתרון הזה, כולל ניתוח CrowdStrike הטכני המלא וארכיטקטורת מערכות חסינות.
ניתוח שלאחר-מוות (post-mortem) טכני של השבתת CrowdStrike, ניתוח משפטי של ההתדיינות Delta v. CrowdStrike, ומסגרת ארכיטקטונית לאימות עדכונים מונע-AI ומערכות מרפאות-עצמן.
ההערכה שמונעת זאת עולה פחות משעת השבתה אחת.
אנחנו בונים מערכות ממשל עדכונים עצמאיות שיושבות בין הספקים שלכם לבין נקודות הקצה בייצור שלכם. ללא הטיית פלטפורמה. ללא שותפויות ספקים שמתנגשות בהערכה כנה.