انهيار CrowdStrike انحصر في عدد الحقول: 21 حقلاً حيث توقعت النواة 20. لم تكن هناك أي طبقة مستقلة تدقق.
في 19 يوليو 2024، أدى تحديث منفرد من أحد الموردين إلى تعطل ملايين أجهزة Windows في أقل من 90 دقيقة، وكان السبب مجرد رقم. أعلن ملف قناة «Rapid Response Content» التابع لشركة CrowdStrike عن 21 حقلاً في حين كان مفسر النواة (kernel interpreter) المنشور يتوقع 20 حقلاً فقط. تسبب الحقل الإضافي في قراءة خارج الحدود (out-of-bounds read)، وشاشة زرقاء فورية، ولأن الانهيار حدث في مرحلة مبكرة جداً من الإقلاع، لم يتمكن الوكيل المنهار من إعادة التشغيل لتلقي أمر التراجع (rollback). وكان التعافي يعني الانتقال الفعلي إلى كل جهاز وإصلاحه يدوياً في الوضع الآمن (Safe Mode).
قرأت تحليل الأسباب الجذرية الصادر عن CrowdStrike نفسها، والذي نُشر في أغسطس من ذلك العام، أكثر من مرة قبل أن يتبلور في ذهني ما يزعجني حقاً. لم تكن هذه عملية اختراق. ولم يكن نموذج ذكاء اصطناعي معيباً. بل كانت حقيقة حسابية قابلة للحسم، 21 مقابل 20، قابعة في حمولة لم تفحصها أي طبقة مستقلة على الإطلاق قبل وصولها إلى بيئة الإنتاج. لقد وافق مدقق المورد عليها. أما المؤسسات التي أصيبت بالشلل فلم تكن تملك ذلك المدقق، بل تحملت العواقب وحدها.
قضيت الفترة الأخيرة في بناء عرض توضيحي حول تلك الفجوة: لوحة تحكم أطلقت عليها اسم Kestrel تتوسط بين مورد البرمجيات وأسطول الإنتاج، وتحدد برمجياً ما يُسمح للمورد بشحنه ونشره. يمكنك الاطلاع على طريقة عملها عبر veriprajna.com/demos/software-update-integrity. وما فاجأني أثناء بنائها هو المكان الذي تبين أن الحل يكمن فيه. لقد بدأت العمل وأنا على يقين بأنني سأحتاج إلى نموذج أكثر ذكاءً، لكن بضعة أسطر من كود Python البسيط كانت أول من رصد الانهيار واقتنصه.
أعدت بناء الانهيار ثم تركت الكود يقرر
أعدت بناء بصمة فشل 19 يوليو كحالة اختبار ثابتة (fixture) ووجهت نظامي إليها، وأنا شبه متوقع أن أصاب بخيبة أمل من إعادة التشغيل الخاصة بي. الحزمة هي C-00000291، وهي ملف قناة Rapid Response Content من مورد وهمي أطلقت عليه اسم SentinelEdge، تم دفعه إلى أسطول تركيبي يضم 8,500 نقطة نهاية أسميته Acme Financial. ليست أي من هذه شركات حقيقية. لكن بصمة الفشل حقيقية تماماً: مخطط معلن يحتوي على 20 حقلاً زاد إلى 21، ودُفع إلى 100% من الأسطول في موجة واحدة، دون أي خطة نشر تدريجي (canary).
تنطلق البوابة عبر أربعة فحوصات متزامنة، وكل منها حسابي بحت أو بحث مباشر في جدول، دون أي أحكام تقديرية شخصية. يكتشف فارق المخطط (schema diff) وجود 21 حقلاً في حين يتوقع المفسر 20 حقلاً، ويضع علامة على القراءة خارج الحدود. وتقوم بيئة معزولة (sandbox) محاكاة — وهي نموذج نتائج حتمي لكل ملف تعريف وليست مزرعة من أجهزة Windows الافتراضية الفعلية — بإدخال 5 من أصل 6 ملفات تعريف للأسطول في حلقة إعادة تشغيل لا نهائية عبر دورات إعادة الإقلاع. وتستنتج ذلك من إشارة توافق برنامج التشغيل المستقلة تماماً عن فحص المخطط، بحيث تؤكد النتيجتان بعضهما البعض بدلاً من أن تكونا مجرد صدى متكرر. ويحدد كاشف الوكيل الميت (dead-agent) حلقة التراجع على أنها true، لأن الوكيل المنهار هو نفسه الكيان الذي يفترض أن يتلقى أمر التراجع، ولكنه ميت قبل اكتمال الإقلاع. ويصل نطاق التأثير (blast radius) إلى 100% مقابل سياسة نشر تدريجي قدرها 5%. الحكم: BLOCK. ويظهر على الشاشة: تم الحظر قبل إعادة تشغيل أي نقطة نهاية في بيئة الإنتاج.
يُظهر وقت التوقف المتجنب المقدر لهذا التحديث الفردي 5,000,000 $، وأريد أن أكون دقيقاً بشأن ماهية هذا الرقم. إنه النموذج الخاص بالعرض التوضيحي: الحصة المتأثرة مضروبة في مدخل قدره 5 ملايين دولار في الساعة مضروباً في حد أدنى للتعافي مدته ساعة واحدة، مع طباعة الصيغة على الشاشة. إنه ليس مالاً ادخره عميل فعلياً. فالتعافي الحقيقي في 19 يوليو استغرق أياماً وليس ساعة واحدة، لذا فإن الحد الأدنى متحفظ عن قصد.
الحالة الخضراء أخافتني أكثر من الحمراء
كنت أكثر توتراً بشأن الحالة الخضراء مقارنة بالحمراء، لأن طبقة الحوكمة التي تحظر التحديث الخطير وتخنق في الوقت نفسه التحديث الآمن ليست سوى انقطاع خدمة قمت بجدولته لنفسك. يقوم المورد الوهمي نفسه بدفع RRC-7741، وهو تحديث سليم لبصمات الاكتشاف، بمخطط معلن 20 إلى 20، مع خطة نشر تدريجي مرحلية بنسبة 1.2%. يعمل فريق الوكلاء، ويتطابق المخطط، وتجتاز 5 من أصل 6 ملفات تعريف دورات إعادة التشغيل بنجاح، وتكون حلقة الوكيل الميت false، ويقع نطاق التأثير ضمن حدود السياسة. الحكم: APPROVE ROLLOUT، طُرح لحلقة نشر تدريجي تضم 102 نقطة نهاية. أخضر، سريع، وخالٍ من التعقيدات.
عبر التحديثات السليمة الستة في المجموعة، أثمرت البوابة عن صفر من عمليات الحظر الخاطئ (false blocks). وأقول هذا مع ذكر المقام بوضوح، لأن ستة تعني ستة، ولن أسمح بأن يتم تقريبها إلى وعد فضفاض بشأن أسطولك. إن قيمة حالة ALLOW أضيق نطاقاً وأهم بكثير من مجرد نسبة مئوية. فالبوابة لا تحظى بالمصداقية إلا إذا كانت غير مرئية في حركة البيانات العادية وثابتة لا تتزعزع في اللحظة الوحيدة التي يمكن أن تسقط فيها بنيتك التحتية.
لماذا انتزعت سلطة الحكم من النموذج
بدأت هذا المشروع بافتراض أن الجزء الصعب يكمن في الاستدلال، وأن نموذجاً أكثر حدة أو ناقداً أكثر مهارة سيكون هو العنصر الذي يرصد التحديث المعيب. كنت مخطئاً بطريقة استغرقت وقتاً للاعتراف بها. هناك بالفعل فريق نماذج لغوية داخل Kestrel: أداة توحيد (normalizer)، ومفسر بيئة معزولة، وناقدان متخاصمان، أحدهما يدافع عن أن التحديث آمن للنشر والآخر يجادل بأنه سيسبب انهياراً. ويكتسب هذا الزوج التنافسي مكانته لأنه يختبر الحكم اختباراً أمنياً أحمر (red-teams) من كلا الاتجاهين قبل اتخاذ أي قرار. ومع ذلك، لا يوجد وكيل واحد من هؤلاء يصدر الحكم النهائي.
يتم تحديد الحكم بواسطة ملفي بايثون عاديين، verifier.py و gate.py، واللذين يقعان تماماً خارج إطار عمل الوكلاء. يعمل الفريق على Pydantic AI بنموذج افتراضي هو claude-opus-4-8، ويعمل النظام بأكمله أيضاً دون اتصال بالإنترنت وبدون مفتاح API من خلال آلية استشارية احتياطية حتمية. وفي كل تلك الأنماط، تكون البوابة متطابقة وتعيد نفس القرار بالضبط، لأن القرار حسابي وليس استدلالاً احتمالياً. الوكلاء يقدمون المشورة، والكود هو من يحسم. فالوكيل الاستشاري الذي يميل نحو «السماح» لا يمكنه تجاوز نتيجة حتمية حرجة، وهذه ليست مسألة ذوق شخصي.
إن الطبقة المبنية للتدقيق في المورد لا يمكنها أن تأخذ كلام المورد كمسلّمة فيما يتعلق بالأمان. كما لا يمكنها أن تأخذ كلام نموذجها الخاص كمسلّمة أيضاً.
تلك الجملة هي السبب في أن المعمارية تبدو بالشكل الذي هي عليه. فالثقة في منتج وظيفته الوحيدة هي إدارة ما يقوم المورد بشحنه يجب ألا تمر أبداً عبر مكون يمكن استمالته ليقول نعم.
ما الذي سأسلمه للمدقق
أبقيت قانون الصمود السيبراني الأوروبي (CRA) مفتوحاً على شاشة ثانية أثناء قيامي ببناء سجل الأدلة، لأن ذلك السجل هو الوثيقة الملموسة التي سيتعين عليّ الدفاع عنها فعلياً. كل قرار يُصدر ملف HTML غير قابل للتغيير وملف JSON موقعاً يحمل تجزئة محتوى SHA-256، والحكم، والأدلة الحتمية، ونتائج البيئة المعزولة لكل ملف تعريف، وأحكام الوكلاء الاستشاريين مع معرف النموذج الخاص بهم، وقواعد السياسة التي تم إطلاقها، ومسار تقييم خطوة بخطوة حيث تحمل كل خطوة زمن الاستجابة الخاص بها.
إن مسار التتبع هو العنصر الذي قللت من تقديره حتى نقرت على خطوة منفردة. يقرأ أحد الأحداث: «توحيد بيان المورد الموقع، اكتمل في 184 مللي ثانية»، ويتم الاحتفاظ به مع مخرجات القرار للمراجعة التدقيقية. كل خطوة قابلة لإعادة الاشتقاق والحساب. لا يتعين على المنظمين الوثوق بلوحة التحكم الخاصة بي على نحو أعمى؛ بل يمكنهم إعادة تشغيل الحسابات وسيحصلون على النتيجة ذاتها بالضبط.
أنا حريص جداً بشأن ما تعنيه عملية التوقيع وما لا تعنيه. إنها تجزئة SHA-256 محلية وليست بنية تحتية للمفاتيح العامة (PKI) على مستوى المؤسسة. إن موجز تحديثات المورد وتذاكر ITSM خلفه هي كتل اختبار تمثيلية وليست موصلات حية. السجل مصمم ليتوافق مع متطلبات الإيداع: إبلاغ الحوادث في النوافذ الزمنية القصيرة للائحة CRA، وإفصاح هيئة الأوراق المالية والبورصات (SEC) خلال أربعة أيام عمل عن أي حادث سيبراني جوهري، وأسئلة مسؤولية المورد التي أثيرت في قضية Delta v. CrowdStrike في مقاطعة فولتون عام 2025. مصمم ليتوافق مع. إنه لا يصادق على أي شخص، ولا يعد مشورة قانونية، وكل من يبيعك سجل تدقيق يزعم أنه يجعلك ممتثلاً فهو يحاول فقط أن يبيعك سلعة.
هناك قرار آخر أنا فخور به، وهو قرار «الرفض». حالة الاختبار XX-0000 عبارة عن كتلة بيانات مشفرة من محتوى خاص لا تستطيع البوابة تحليله، ولذا فهي لا تخمن. إنها تعيد ABSTAIN (امتناع) وتحيل الأمر إلى إنسان، لأن البوابة التي تمنح الضوء الأخضر لما لا تستطيع قراءته هي أسوأ من عدم وجود أي بوابة على الإطلاق. الأجهزة القديمة التي لا تستطيع البيئة المعزولة نمذجتها يتم وضع علامة عليها واستبعادها، ولا يُفترض أبداً أنها آمنة. تتكون المفردات من أربع كلمات: ALLOW و HOLD و BLOCK و ABSTAIN، والكلمة الأخيرة هي أكثر كلمة سأدافع عنها بشراسة.
ما يحق لـ 12 من أصل 12 أن تعنيه
عليّ أن أبطئ هنا، لأن هذا هو بالضبط الموضع الذي يبدأ فيه المؤسس بالتقريب للأعلى وتضخيم الأرقام، وبما أنني سميت الشركة Veriprajna، أي الحكمة الحقيقية، فإن التضخيم غير وارد إطلاقاً. عبر مجموعة محددة ومصنفة من اثني عشر تحديثاً، تعيد البوابة القرار الصحيح في جميع الحالات الاثنتي عشرة. ست منها سليمة ولا تحظر أياً منها. وواحدة هي الامتناع الصادق ABSTAIN. وتظهر لوحة النتائج: 12/12 قراراً تم التحقق منه، 0/6 حظر خاطئ، وتكلفة توقف مقدرة تم تجنبها بقيمة 13.3M $ عبر المجموعة، منها 5 ملايين دولار تعود إلى الحظر الفردي من فئة CrowdStrike.
والآن إلى الجزء الذي أرفض اختصاره. هذه نتائج على اثني عشر عنصراً مصنفاً، وليست وعداً بشأن التحديث التالي الذي يصل إلى أسطولك. ستة عناصر سليمة تظل ستة. هذا لا يعني «حظر 100% من التحديثات السيئة»، ولن يعني ذلك أبداً، وإذا ضبطتني يوماً أكتب تلك الجملة، فيجب عليك التوقف عن قراءتي. إن الرقم الذي أقف خلفه هو من طبيعة مختلفة: نفس المدخلات، نفس القرار، في كل تشغيل، لأن الحكم لا يحمل أي درجة حرارة للنموذج. أعد تشغيل مجموعة الاختبار غداً وستحصل على نتائج متطابقة بايت مقابل بايت، وهو ما يتيح تدقيق الطبقة الحتمية بطريقة يستحيل تطبيقها على الطبقة الاحتمالية.
السؤال الذي يظل يشغلني
إن ما يعلق في ذهني من هذا البناء هو مدى اعتيادية الفشل وبساطته. واحد وعشرون حقلاً حيث كان المتوقع عشرين. رقم كان بإمكان أي مدقق مستقل رصده بالحسابات البسيطة قبل إعادة تشغيل جهاز واحد، لو كان هناك مدقق مستقل يقف بين المورد والأسطول. لم يكن هناك أحد. وحتى يومنا هذا، في الغالب، لا يزال لا يوجد أحد.
تقوم كل مؤسسة بتشغيل ما بين ثمانية إلى اثني عشر وكيلاً يتمتعون بامتيازات على مستوى النواة من موردين لا تتحكم فيهم، ويمكن لكل منهم دفع ملف مباشرة إلى ring 0. أدوات SBOM تراقب تبعيات المصادر المفتوحة. إدارة الهوية تراقب الوصول. ولكن لا أحد يقرأ التحديث الخاص بالمورد عند وصوله ويثبت أمانه. Kestrel ليس نظام EDR ولا يلمس النواة أبداً. إنه يجلس فوق هؤلاء الوكلاء ويدير ما يُسمح لهم بشحنه. تلك هي الطبقة التي حاولت بناءها، والتحليل الكامل متاح في veriprajna.com/demos/software-update-integrity.
وإذا كنت تفضل مشاهدته عملياً بدلاً من قراءتي وأنا أصفه، فإليك النظام كاملاً وهو يعمل من البداية إلى النهاية.
إذن هذا هو ما أسأله الآن بشأن كل أسطول أراه: عندما يصل تحديث المورد التالي، ما الذي يقف بين ذلك الملف وبيئة الإنتاج، وهل يمكنه إثبات صحة عمله؟ إذا كانت الإجابة هي لجنة استشارية للتغيير (CAB) تثق في المورد ثقة عمياء، فإن الخطأ الحسابي الذي أسقط ملايين الأجهزة لا يزال يعمل بلا رادع. ولن يعلن عن نفسه؛ بل سيبدو تماماً مثل كل تحديث سبقه، حتى لحظة إعادة التشغيل بالضبط.
