8.5 مليون حاسوب تعطّلت بسبب ملف واحد لم يراجعه أحد من جانبك

راسلني صديق يدير الأمن في شركة طيران متوسطة الحجم بصورة على هاتفي أثناء الفطور يوم 19 يوليو 2024. كانت لوحة مغادرة، لكن كل لوحة فيها كانت بالدرجة نفسها من اللون الأزرق، وعليها نص الخطأ الأبيض نفسه مكرراً لوحةً تلو الأخرى عبر الصالة. لم يكتب أي شيء مع الصورة. لم يكن مضطراً لذلك.

بحلول الوقت الذي أنهيت فيه قهوتي، كان الرقم قد بلغ 8.5 مليون جهاز يعمل بنظام Windows، تعطّلت جميعها في أقل من تسعين دقيقة. لم تكن برمجية خبيثة. ولا ثغرة يوم صفر. بل تحديث محتوى روتيني من CrowdStrike، وهو المورّد الذي دفعت تلك الشركات له تحديداً لكي يحميها. الشيء الذي كان يحمي نقاط النهاية هو نفسه الشيء الذي عطّلها بالكامل.

قضيت الوقت منذ ذلك الحين في بناء الطبقة التي كان ينبغي أن تقع بين هؤلاء المورّدين وتلك الأجهزة — وهو ما نسميه الآن سلامة نشر تحديثات البرمجيات، أي نقطة تفتيش مستقلة بين خط أنابيب تحديثات المورّد وأسطول الإنتاج لديك. يتناول هذا المقال سبب عدم وجود تلك الطبقة، ولماذا الطريقة البديهية لبنائها خاطئة، وما الذي تغيّر تحت كل مؤسسة تشغّل وكلاء على مستوى النواة في اللحظة التي أضاءت فيها تلك اللوحة الزرقاء.

الحقل الحادي والعشرون

قرأت تحليل CrowdStrike الخارجي للسبب الجذري في الليلة التي نُشر فيها، في أغسطس 2024، وكان السبب صغيراً إلى درجة تكاد تكون مهينة.

يشحن Falcon، وهو مستشعر CrowdStrike، منطق الكشف عبر آلية يسميها Rapid Response Content — تحديثات إعداد صغيرة تتيح له التفاعل مع التهديدات الجديدة دون دفع ثنائية جديدة بالكامل. في 19 يوليو، شحن نسختين جديدتين من قوالب Template Instances للكشف عن الاتصال بين العمليات. أشارت هاتان النسختان إلى معامل إدخال حادٍ وعشرين. تحقّق مدقّق المحتوى السحابي Content Validator التابع لـ CrowdStrike من التحديث مقابل المخطط الجديد المكوّن من 21 حقلاً، ورأى أنه صالح، ووافق عليه.

كانت المشكلة في مفسّر المحتوى Content Interpreter الذي يعمل داخل نواة Windows، عند Ring 0، وهي الطبقة الأكثر امتيازاً في نظام التشغيل. كان لا يزال يتوقع 20 حقلاً. وعندما امتد إلى الحقل الحادي والعشرين، قرأ ذاكرة غير موجودة، فأصيب الجهاز بالشاشة الزرقاء على الفور.

وافق مدقّق سحابي على تحديث وفق القواعد الجديدة. أما النواة التي استقبلته فكانت لا تزال تعيش وفق القواعد القديمة. ولم يكن أحد يتحقق من أن الاثنين متفقان.

وهنا الجزء الذي لا يزال يزعجني أكثر من غيره كمهندس. حدث التعطل في وقت مبكر جداً من تسلسل الإقلاع لدرجة أن وكيل الإدارة الخاص بـ Falcon لم يبدأ العمل قط. لذا لم تستطع نقاط النهاية استقبال أمر التراجع الذي أرسلته CrowdStrike، لأن البرنامج المفترض أن يستقبل ذلك الأمر كان هو نفسه الشيء الذي يعطّل الجهاز. لدى الصناعة اسم قاتم لهذا — حلقة الوكيل الميت. لم يكن التعافي زر ضغط. بل كان إنساناً، عند كل جهاز، يقلع في الوضع الآمن، ويتنقل إلى C:\Windows\System32\drivers\CrowdStrike\، ويحذف يدوياً الملف المعطوب C-00000291-*.sys ملفاً بملف. فعلت Delta هذا عبر 40,000 خادم. استغرق التعافي خمسة أيام.

لم يكن الأمر يوماً يخص مورّداً واحداً

القصة السهلة هي أن CrowdStrike كانت مهملة. وهي أيضاً الدرس الخاطئ، والسعي وراءها كان سيقودني إلى بناء المنتج الخاطئ.

لأن النمط ليس خاصاً بـ CrowdStrike. استعرض قائمة نقاط النهاية لأي مؤسسة كبيرة وستجد من ثمانية إلى اثني عشر وكيلاً يعمل على مستوى النواة أو بامتيازات مرتفعة — وكيل EDR، ووكيل منع فقدان البيانات، ووكيل تشفير، ووكيل ترقيع، وعميل VPN، ووكيل إدارة الأجهزة. ثمانية صفوف في جدول بيانات، وثماني قنوات تحديث منفصلة، كل منها تدفع وفق جدولها الخاص، وكل منها يُمرَّر دون تدقيق.

ظللت أطرح على مسؤولي أمن المعلومات (CISOs) السؤال نفسه ذلك الصيف: من يراجع تحديثات المورّدين هذه قبل أن تصل إلى الإنتاج؟ كانت الإجابة، في كل مرة، صيغةً ما من لدينا مجلس استشاري للتغييرات. ثم، بعد لحظة، الجزء الصادق: مجلس التغييرات الاستشاري يراجع عمليات النشر الداخلية سطراً بسطر، لكن تحديثات المورّدين تتخطى طابور التذاكر، وتتخطى البيئة المرحلية، وتذهب مباشرة إلى كل نقطة نهاية — لأن "نحن نثق بالمورّد". كانت تلك العبارة تحمل عبء الصناعة بأكملها، ولم يكن وراءها أي آلية.

هناك نمط فشل ثانٍ لا يتحدث عنه أحد تقريباً، وتشخيصه أسوأ. عندما يحدّث مورّدان واجهات النواة في اليوم نفسه، قد تتعارض برامج تشغيلهما وتنتج الشاشة الزرقاء نفسها تماماً كخلل من مورّد واحد. إلا أن تحليل السبب الجذري يستغرق الآن أسابيع بدلاً من ساعات، لأنك تحدّد الموقع بالتثليث عبر فريقي دعم لمورّدين، يلقي كل منهما، بشكل معقول، اللوم على الآخر.

النسخة التي بنيناها أولاً، ولماذا فشلت

عندما بدأنا، كنت متأكداً أن الإجابة هي الكشف. راقب نقاط النهاية، وتعلّم كيف يبدو الوضع الطبيعي، واصرخ في اللحظة التي يبدأ فيها تحديث بالتصرف بشكل خاطئ. إنها الغريزة التي دربنا عليها سوق المراقبة بأكمله — Datadog وDynatrace وSplunk، وكلها بارعة في إخبارك بما حدث للتو.

بنينا نسخة من ذلك. وشغّلناها ضد إعادة تشغيل لحالات فشل ناتجة عن التحديثات. ونجحت، بأكثر الطرق عديمة الجدوى الممكنة: رصدت المشكلة بشكل رائع، بعد أن تعطّلت الأجهزة الأولى بالفعل.

أتذكر المكالمة التي تجسّد فيها هذا. راقب أحد مسؤولي أمن المعلومات في المرحلة التجريبية لوحتنا وهي تضيء بعد ثوانٍ قليلة من بدء طرح سيئ محاكى وقال، إلى حد ما، إنه لا يحتاج إلى طريقة أسرع ليكتشف أنه مشتعل بالفعل. كان يحتاج إلى ألا يصل التحديث أبداً إلى جميع نقاط نهايته دفعة واحدة من الأساس. الكشف بعد النشر، لعطل يستغرق تسعين دقيقة ليصيب 8.5 مليون جهاز، هو جرس إنذار حريق يرن بعد أن يكون المنزل قد زال.

المراقبة تخبرك بأن المبنى يحترق. وعندها يكون السؤال الوحيد المتبقي هو كم يوماً ستستغرق إعادة البناء.

كان ذلك الشهر الذي راهنت فيه بهدوء بالعمل على الطبقة الخاطئة، ومشاهدة تلك اللوحة تثبت ذلك كانت أكثر شيء مفيد حدث لنا. لم تكن المشكلة يوماً سرعة الكشف. بل كانت أنه لم تكن هناك نقطة تفتيش قبل وصول التحديث.

إذن لماذا لا ترصد الأدوات الحالية هذا؟

يفترض الناس أن أمن سلسلة توريد البرمجيات يغطي هذا بالفعل. لكنه لا يفعل، والسبب دقيق.

أدوات SBOM وتحليل تركيب البرمجيات — Snyk وSonatype — تدقّق شجرة اعتماديات مصادرك المفتوحة. إنها مبنية لتخبرك بأن حزمة npm ما على عمق ثلاثة مستويات تحتوي على ثغرة معروفة. لكن Rapid Response Content الخاص بمورّد، وملف قناة، وكتلة إعداد احتكارية موقّعة ومدفوعة من CrowdStrike أو أي نظير — كل ذلك غير مرئي لها. إنه ليس في شجرة اعتمادياتك. بل يُدفَع حول الشجرة، مباشرةً إلى النواة. الأدوات المخصصة لتأمين سلسلة توريد برمجياتك تدقّق الطبقة الخاطئة تماماً.

ITIL ومجلسك الاستشاري للتغييرات؟ إجرائية. إنها قوائم مراجعة وموافقات مصممة للتغييرات التي تُطلِقها أنت، ولم تُربَط قط بإيقاع إصدار المورّد.

وأما المعالجة الخاصة بـ CrowdStrike نفسها — وضع التعافي الذاتي، وتثبيت المحتوى، و"ضوابط نشر العملاء" المرحلية، وإطار عمل Resilient-by-Design المستعار من CISA — فهي عمل حقيقي، ولا أستهين به. لكن اقرأ ما هي فعلاً: كل واحد من تلك الضوابط هو رقابة ذاتية من المورّد. الشركة نفسها التي شحنت الحقل الحادي والعشرين هي التي تشهد بأنه آمن الآن. لا يزال لا يوجد طرف مستقل يقف بين دفع المورّد ونقطة نهايتك. بقي معدل احتفاظ CrowdStrike الإجمالي فوق 97% في الربع التالي للانقطاع، وهو ما يخبرك بأن السوق لم يعاقبها — ولا يخبرك بأي شيء عمّا إذا كانت الفجوة الأساسية قد أُغلقت. لم تُغلَق.

تلك الفجوة هي المنتج بأكمله. المكان الصحيح للوقوف ليس على نقطة النهاية مترقباً الحريق، وليس داخل المورّد واثقاً بكلمته. بل بينهما: نقطة تفتيش محايدة تجاه المورّدين تأخذ التحديث قبل أن يصل إلى الإنتاج، وتشغّله عبر بيئة اختبار معزولة تحاكي أسطولك الحقيقي، وتتحقق من المحتوى مقابل ما تتوقعه نواتك فعلاً، وتنمذج نطاق الانفجار إذا كان خاطئاً. تلك هي الطبقة التي انتهينا إلى بنائها، ويمكنك رؤية شكلها في صفحة الحل لدينا. عدم تطابق مخطط كخلل الحقول الحادي والعشرين مقابل العشرين هو بالضبط فئة الأشياء التي تكشفها بيئة اختبار ما قبل النشر في حلقة كناري بدلاً من انتشارها عبر 8.5 مليون جهاز دفعة واحدة.

تحرّكت الأرضية القانونية، ومعظم العقود لم تلحق بها بعد

لفترة، تعاملت مع الجانب التنظيمي كضجيج خلفية. كنت مخطئاً، والمشترون أروني السبب: العقود الموجودة في أدراجهم لم تعد تحميهم بالطريقة التي يظنونها.

ابدأ بقضية Delta ضد CrowdStrike. في مايو 2025، في محكمة مقاطعة Fulton العليا، سمح القاضي Ellerbe بأن تمضي دعاوى الإهمال الجسيم، والتعدي على الحواسيب، والاحتيال بالإغفال — متجاوزةً سقف المسؤولية التعاقدية لـ CrowdStrike. جزء التعدي على الحواسيب هو الذي ينبغي أن يجعل كل مسؤول أمن معلومات ينتبه: كانت Delta قد ألغت اشتراكها في التحديثات التلقائية، ومع ذلك وصل ملف القناة إلى النواة على أي حال. إذا كان بإمكان مورّد دفع محتوى Ring 0 عبر قناة لا تحكمها إعداداتك، فقد تكون تفضيلات التحديث في اتفاقيتك غير قابلة للتنفيذ. معظم اتفاقيات الخدمة الرئيسية (MSAs) للمؤسسات لا تميّز حتى بين تحديث كامل للمستشعر ومحتوى الاستجابة السريعة. وينبغي أن تفعل.

ثم تحرّك الاتحاد الأوروبي، وهذا هو الجزء الذي أثيره الآن في كل إعادة تفاوض على عقد أحضرها. توجيه مسؤولية المنتج المنقّح يصنّف البرمجيات الآن صراحةً على أنها "منتج" بموجب المسؤولية المشددة، ويقول إن الشركات لا يمكنها أن تستبعد تعاقدياً المسؤولية عن عيوب البرمجيات والأمن السيبراني. سقف المسؤولية البالغ ملايين من خانة واحدة الذي حدّده مورّدك في العقد قد لا يصمد ببساطة في الولايات القضائية للاتحاد الأوروبي. وإلى جانبه، يبدأ قانون الصمود السيبراني للاتحاد الأوروبي (EU Cyber Resilience Act) الإبلاغ الإلزامي عن الثغرات في 11 سبتمبر 2026 — وهي مهلة 24 ساعة، والأهم، تبدأ عندما تصبح أنت على علم، وليس عندما يخطرك المورّد. انقطاع خدمة المورّد يمكن أن يصبح التزامك بالإبلاغ، وبسرعة.

وفي الولايات المتحدة، تطالب هيئة الأوراق المالية والبورصات (SEC) الآن الشركات العامة بالإفصاح عن حوادث الأمن السيبراني الجوهرية خلال أربعة أيام عمل، ووصف مخاطر سلسلة توريد البرمجيات في تقاريرها 10-K. أجرِ الحساب باستخدام بيانات التكلفة: وضعت دراسة New Relic من سبتمبر 2025 متوسط تكلفة تعطّل تقنية المعلومات الكبير عند 2 مليون دولار في الساعة، و41% من المؤسسات المتوسطة إلى الكبيرة تضع رقمها الخاص بين مليون و5 ملايين دولار في الساعة. انقطاع لمدة أربع ساعات من تحديث مورّد لم يره مجلس التغييرات لديك قط يتجاوز عتبة الجوهرية بمفرده. يحتاج فريق علاقات المستثمرين لديك إلى دليل تشغيل لانقطاع المورّد، وليس فقط دليل تشغيل للاختراق.

انقطاع لمدة أربع ساعات من تحديث لم يراجعه أحد من جانبك يبلغ نحو 8 ملايين دولار عند الوسيط — النوع من الأرقام الذي يصل إلى مكتب المدير المالي، لا مكتب مسؤول أمن المعلومات.

"هل يمكن أن يحدث هذا لنا؟"

بعد يوليو 2024، طرح كل مجلس إدارة في العالم على مسؤول أمن المعلومات لديه الكلمات الأربع نفسها. ومسؤولو أمن المعلومات الذين تحدثت معهم لم تكن لديهم في الغالب إجابة منظّمة — وهذا ليس انتقاصاً منهم. وجدت بيانات IANS Research من أوائل 2026 أن 29% فقط من أعضاء مجالس الإدارة يعتبرون تقارير الأمن التي يقدمها مسؤول أمن المعلومات لديهم "فعّالة جداً"، ومخاطر نشر التحديثات هي بالضبط النوع من الأشياء الحقيقية، والمكلفة، والتي يكاد يكون من المستحيل وضع رقم لها بالأدوات التي تمتلكها معظم الفرق.

ذلك هو النصف الأكثر هدوءاً مما بنيناه. ليس فقط نقطة التفتيش التقنية، بل الشيء الذي يحوّل "هل يمكن أن يحدث هذا لنا" إلى إجابة جاهزة للمجلس: جرد لكل وكيل ذي امتيازات وقناة تحديثه، ونموذج مُقدَّر كمياً لنطاق الانفجار لكل مورّد، وسجل بأي التحديثات جرى اختبارها في بيئة معزولة وما فعلته هناك. إنه يحوّل شريحة عرض كانت تقول "نحن نثق بمورّدينا" إلى شريحة تُظهر العمل.

يسألني الناس عمّا إذا كان هذا ضرورياً حقاً الآن بعد أن أصبحت Microsoft تدفع مورّدي الأمن خارج النواة — مبادرة Windows Resiliency Initiative، مع Quick Machine Recovery والنقل التدريجي لأمن نقاط النهاية من وضع النواة إلى وضع المستخدم. إنه تحوّل هيكلي جيد بحق، وسيقلّل أسوأ نطاق انفجار بمرور الوقت. لكن الجدول الزمني يمتد عبر 2026 و2027، وستقضي تلك النافذة بأكملها في تشغيل أسطول مختلط في منتصف الترحيل، و"أقل كارثية" ليست "متحقَّق منها". وكيل وضع المستخدم الذي يشحن إعداداً سيئاً لا يزال بإمكانه إسقاط ما هو مسؤول عنه. الحاجة إلى فحص مستقل لا تختفي عندما تختفي النواة؛ إنها فقط تنتقل طبقة إلى الأعلى.

الشيء الآخر الذي يقوله الناس هو أن إضافة نقطة تفتيش تبطئ كل شيء — وأن الهدف الكامل من Rapid Response Content هو السرعة في مواجهة التهديدات الحية. عادل. لكن الخيار لم يكن يوماً بين السرعة والأمان. مدقّق CrowdStrike السحابي عمل بسرعة ومع ذلك وافق على التحديث المعطوب، لأنه تحقّق من الملف مقابل المخطط الجديد ولم يتحقق قط من أن النواة موافقة. لم تكن السرعة هي الفشل. بل غياب فحص مستقل. حلقة كناري ترصد عدم تطابق مخطط في 30 جهازاً تكلّفك دقائق. البديل كلّف Delta خمسة أيام و550 مليون دولار.

ماذا كانت اللوحة الزرقاء تعني فعلاً؟

أعود مراراً إلى صورة صديقي للوحة المغادرة تلك. لصباح واحد، التجريد الذي تعيش داخله كل مؤسسة — مورّدونا الموثوقون يبقوننا آمنين — جرى تصويره بالأزرق الحرفي، لوحةً تلو الأخرى، في مبنى مليء بأشخاص عالقين.

لم يفشل المورّدون لأنهم كانوا متهورين. فشلوا لأننا، جماعياً، بنينا صناعة يمكن فيها لملف إعداد واحد من مورّد واحد أن يصل إلى كل نقطة نهاية دفعة واحدة دون أن يتحقق أي طرف مستقل من الحسابات. كانت CrowdStrike هي من جاء دورها. البنية التي سمحت بحدوث ذلك موجودة، الآن، في قائمة نقاط النهاية لكل شركة تقريباً يمكنك تسميتها — من ثمانية إلى اثني عشر وكيلاً ذا امتيازات، ومن ثماني إلى اثنتي عشرة قناة، ولا أحد بينها.

يمكنك قراءة البنية الكاملة لنقطة التفتيش التي بنيناها هنا. لكن الجزء الذي أودّ أن يخرج به مسؤول أمن المعلومات أبسط من أي منتج. الانقطاع التالي من هذا النوع لن يعلن عن نفسه كحادث أمني. بل سيصل موقّعاً، وموثوقاً، وموافَقاً عليه — تماماً بالطريقة التي فعلها الأخير. الشيء الوحيد الذي يغيّر النهاية هو شخص يقف بين الدفع وأسطول الإنتاج، يتحقق من أن التحديث والجهاز لا يزالان متفقين قبل أن يكتشف جميعها البالغ عددها 8.5 مليون ذلك دفعة واحدة.