ملخص
- حول Log4Shell مكون تسجيل Java إلى اختبار مساءلة عالمي لأن العديد من المؤسسات لم تستطع تحديد وجود Apache Log4j مباشرة أو مضمنًا أو ضمن أجهزة أو خدمات مُدارة.
- جعل توجيه CISA العام والتوجيه الطارئ 22-02 مشكلة الإصلاح مرئية: لم يكن التصحيح مجرد شعار. كان على الوكالات الفيدرالية المدنية المشمولة تحديد الأصول المتأثرة وتخفيفها أو تحديثها والإبلاغ عن الحالة والاستمرار في البحث مع تغير المنتجات والتوجيهات.
- قضية المساءلة المركزية هي الإصلاح القابل للتحقق. البيان العام بأننا "صححنا" لا يثبت اكتمال المخزون أو اكتشاف التبعيات المتداخلة أو الضوابط التعويضية أو التنسيق مع البائعين أو مراقبة الاستغلال أو أدلة الإغلاق.
- تم توزيع المسؤولية. حافظت Apache على المشروع وأصلحت الإصدارات. سيطرت الوكالات والمؤسسات على اكتشاف الأصول. سيطر البائعون على تنبيهات المنتجات. لاحظ مزودو الخدمات السحابية والأمن الاستغلال والحظر. احتاج العملاء إلى دليل على أن مورديهم قد قللوا بالفعل من التعرض.
- الدرس الدائم هو أن حوكمة سلسلة توريد البرامج تفشل عندما لا تستطيع المؤسسات إثبات ما تديره. جعل Log4Shell المخزون وفواتير المواد البرمجية وإدارة الثغرات ومراقبة ما بعد التصحيح ضرورات تشغيلية وليس مجرد أوراق امتثال.
كانت حالة الطوارئ فشلًا في المخزون بقدر ما هي خلل في الكود
تبدأ قصة Log4Shell بثغرة، لكن قصة المساءلة تبدأ بالاكتشاف. تصف صفحة أمان Log4j من Apache والإدخال الخاص بـ CVE-2021-44228 الحقائق على مستوى المشروع: الإصدارات المتأثرة والإصدارات الثابتة والثغرات ذات الصلة وسياق التخفيف. يوفر سجل CVE-2021-44228 في NVD بيانات وصفية عامة للثغرة وتأطير شدتها. تثبت هذه المصادر سبب إلحاح الثغرة. لكنها لا تثبت ما إذا كانت أي مؤسسة معينة قد عثرت على كل نسخة من Log4j تعمل لديها.
هذا التمييز حدد الأزمة. عرفت العديد من المؤسسات أن لديها تطبيقات Java. قلائل عرفوا أي الخدمات الداخلية ومنتجات البائعين والأجهزة وأدوات التطوير وأحمال العمل السحابية تضمنت Log4j. يمكن أن يكون المكون داخل تطبيقات لم يعد لها ملاك نشطون. يمكن أن يكون مدمجًا في منتجات تحت اسم البائع وليس Apache. يمكن أن يكون في بيئات اختبار أو إصدارات أقدم أو وحدات تحكم إدارية أو مجمعات سجلات أو برامج طرف ثالث. يمكن لفريق تصحيح الخادم الواضح وترك منتج مكشوف في مكان آخر.
التنبيه الأول لتوجيه CISA حول ثغرة Apache Log4j التقط الإلحاح العام. جمع مورد التوجيه الأوسع لـ ثغرة Apache Log4j المراجع التشغيلية. لكن المساهمة الأعمق لم تكن مجرد نشر استشارة أخرى. ساعدت CISA في تحويل المحادثة من "هناك CVE حرجة" إلى "أظهر عملك". أصبح السؤال أي الأنظمة تم فحصها، وأيها كانت ضعيفة، وأيها تم تصحيحها، وأيها لديها ضوابط تعويضية، وأيها تنتظر البائعين.
هنا أصبحت كلمة "تصحيح" صغيرة جدًا. تصحيح تطبيق مملوك داخليًا هو فعل واحد. العثور على Log4j مضمنًا داخل جهاز بائع هو آخر. تطبيق تخفيف لأن الإصدار الثابت غير متوفر بعد هو آخر. التحقق من السجلات للاستغلال هو آخر. إعادة الاختبار بعد مراجعة البائع للتوجيه هو آخر. إزالة المكتبات القديمة الضعيفة من البناء هو آخر. يحتاج الجمهور إلى مفردات يمكنها فصل هذه الأفعال.
السؤال المسؤول بعد Log4Shell لم يكن "هل صححت؟" بل "هل يمكنك إثبات أن المكون الضعيف لم يعد قابلًا للاستغلال في الأنظمة التي تتحكم فيها، وهل يمكنك إثبات ما تبقى غير مؤكد؟" المؤسسة التي يمكنها الإجابة على هذا السؤال لديها مخزون وقاعدة أدلة. المؤسسة التي لا تستطيع لديها مشكلة حوكمة حتى لو عمل مهندسوها خلال عطلة نهاية الأسبوع.
جعل التوجيه الطارئ 22-02 الإصلاح قابلاً للقياس للوكالات المشمولة
طُبق التوجيه الطارئ 22-02 الصادر عن CISA على الوكالات الفيدرالية المدنية للسلطة التنفيذية في الولايات المتحدة. هذا النطاق مهم. لم يخلق التوجيه التزامات لكل شركة خاصة على وجه الأرض، ويجب ألا يلمح مقال مسؤول إلى ذلك. تكمن أهميته في نموذج الإصلاح الذي جعله مرئيًا: تحديد الأصول المتأثرة والتخفيف والإبلاغ والاستمرار في تحديث الحالة مع تغير المعلومات.
قيمة المساءلة للتوجيه كانت إجرائية. أدرك أنه لا يمكن إدارة الاستجابة لثغرة طارئة بإعلان واحد. كان على الوكالات المشمولة مراجعة الأصول المتصلة بالإنترنت واستخدام أدوات CISA أو طرق مكافئة وتحديث البرامج المتأثرة أو تخفيفها والإبلاغ عن الحالة. أدرك التوجيه أيضًا أن قوائم المنتجات ومعرفة الثغرات ستتطور. هذا يعني أن الوكالات لم تستطع ببساطة إعلان الإغلاق في اليوم الأول والمغادرة.
هذه مشكلة الإثبات. إذا قالت وكالة إنه لا توجد أصول متأثرة، فما المخزون الذي يدعم هذا البيان؟ إذا قالت إن أحد الأصول تم تخفيفه، فما الضابط المطبق وكيف تم اختباره؟ إذا كان منتج بائع لا يزال ينتظر تصحيحًا، فما الضابط التعويضي الذي قلل التعرض؟ إذا ظهر منتج متأثر جديد لاحقًا، كيف أعادت الوكالة تقييم الوضع؟ كان الإصلاح حلقة أدلة.
ينطبق نفس المنطق خارج النطاق الفيدرالي حتى عندما لم يلزم التوجيه المؤسسات الخاصة قانونيًا. واجهت المؤسسات والولايات والجامعات والمستشفيات ومزودو الخدمات السحابية والشركات الصغيرة جميعًا نفس المشكلة التقنية: ابحث عن المكون، وافهم التعرض، وأصلح أو خفف، وراقب الاستغلال، ووثق المخاطر المتبقية. أعطاهم توجيه CISA مثالًا عامًا على الحوكمة الطارئة المنضبطة.
يعزز كتالوج الثغرات المستغلة المعروفة النقطة. عندما تكون الثغرة معروفة بالاستغلال، لم تعد إدارة الثغرات تمرينًا نظريًا للترتيب. تصبح واجبًا تشغيليًا. لا يثبت الكتالوج أي مؤسسة تم استغلالها. يخبر المدافعين أن الاستغلال النشط هو مدخل حوكمة. بالنسبة لـ Log4Shell، جعل سياق الاستغلال موقف "سنصحح لاحقًا" موقفًا أضعف بكثير.
تكشف التوجيهات الطارئة أيضًا عن مشكلة نقل التكلفة. كانت الوكالات والمؤسسات تعتمد على البائعين للكشف عما إذا كانت المنتجات تتضمن Log4j، وتوفير التصحيحات، وشرح التخفيفات، وتحديث الاستشارات. يمكن للعميل تحمل المخاطرة ولكن ليس المعرفة الكاملة. إذا كانت استشارة البائع متأخرة أو غامضة، كان سجل إصلاح العميل أضعف. أصبح هذا الاعتماد قضية مساءلة عامة لأن الأنظمة المتأثرة غالبًا ما دعمت الخدمات الأساسية.
سيطر البائعون على حقائق لم يستطع العملاء رؤيتها بشكل مستقل
كشف Log4Shell عن عدم تناسق أساسي في سلاسل توريد البرامج. يمكن للعملاء فحص أنظمتهم الخاصة، لكنهم غالبًا لا يستطيعون رؤية داخل المنتجات الخاصة أو الخدمات السحابية المدارة. يحتاجون إلى البائعين ليقولوا ما إذا كان المنتج متأثرًا، وأي الإصدارات ضعيفة، وما إذا كان هناك تصحيح، وما إذا كان التخفيف آمنًا، وما إذا تم ملاحظة الاستغلال. أصبحت استشارات البائعين أشياء أدلة.
سيطرت Apache على سجل المشروع مفتوح المصدر لـ Log4j نفسه. سيطر بائعو المنتجات على كيفية ظهور هذا المكون داخل برامجهم الخاصة. سيطر مزودو الخدمات السحابية على وضع الخدمات المُدارة. سيطرت شركات الأمن على القياس عن بعد وإرشادات الكشف. سيطر العملاء على النشر والتعرض والتخفيف المحلي. سافرت الثغرة عبر كل هذه الطبقات. تطلبت المساءلة أن تكون كل طبقة محددة بشأن ما تعرفه.
لهذا السبب أصبحت فواتير المواد البرمجية أكثر من مجرد عبارة سياسة. تصف موارد SBOM من CISA طريقة لتحسين الرؤية في مكونات البرامج. لا تقوم SBOM وحدها بتصحيح الثغرة. لا تثبت أن المنتج آمن. لكن عندما تضرب أزمة، يمكن لمخزون موثوق للمكونات تقصير الوقت بين "Log4j ضعيف" و"هذه المنتجات والإصدارات والخدمات متأثرة". بدون ذلك المخزون، يقوم العملاء والبائعون بالصيد يدويًا تحت الضغط.
يقدم NIST SP 800-161 Revision 1، ممارسات إدارة مخاطر سلسلة توريد الأمن السيبراني للأنظمة والمؤسسات، الإطار الحوكمي. خطر سلسلة التوريد ليس مجرد أوراق شراء. إنها حقيقة أن نتائج الأمان تعتمد على مكونات وموردين خارج سيطرة المشتري. أظهر Log4Shell النسخة التشغيلية لتلك الحقيقة. بدأت ساعة استجابة الحوادث للمشتري قبل أن يعرف العديد من المشترين أي الموردين كانوا في النطاق.
يضيف توجيه CISA آمن بالتصميم عدسة واجب المورد. يجب على صانعي البرامج تقليل العبء الذي يضعونه على العملاء. أثناء Log4Shell، هذا يعني إصدار استشارات في الوقت المناسب، ومصفوفات إصدارات متأثرة واضحة، وتعليمات تخفيف آمنة، وتأكيد لاحق على اكتمال الإصلاحات. البائع الذي انتظر أو تحوط أو نشر بيانات غامضة دفع التكلفة على العملاء الذين اضطروا إلى الاستمرار في السؤال عما إذا كانوا مكشوفين.
كانت استجابة البائع المسؤولة تحتوي على عدة سمات. حددت المنتجات والإصدارات المتأثرة. ميزت بين "غير متأثر" و"قيد التحقيق". حددت الحلول البديلة ومخاطرها. حدّثت الاستشارات عندما تغيرت الحقائق. شرحت ما إذا تم ملاحظة الاستغلال في منتج البائع. قدمت للعملاء طريقة للتحقق من الإصدارات المثبتة. أبقَت الاستشارات القديمة متاحة للتدقيق. حولت تلك السمات اتصالات البائعين إلى أدلة إصلاح قابلة للاستخدام.
كانت مراقبة الاستغلال جزءًا من الإصلاح
إصلاح مكتبة ضعيفة لا يجيب على سؤال ما إذا كانت الثغرة قد استُغلت قبل الإصلاح. لذلك تطلبت استجابة Log4Shell الكشف والصيد. أظهرت إرشادات Microsoft، إرشادات لمنع وكشف وصيد استغلال CVE-2021-44228، كيف تعامل المدافعون مع السجلات والمؤشرات والنشاط المشبوه. وصف من داخل ثغرة Log4j2 من Cloudflare ملاحظات الاستغلال والتخفيف من وجهة نظر موفر الحافة.
هذه المصادر مهمة لأنها تجعل الإصلاح ثنائي الأبعاد. بعد واحد هو التعرض: أين يوجد Log4j الضعيف وهل يمكن الوصول إليه. الآخر هو الاختراق: هل استخدم المهاجمون الثغرة قبل التصحيح أو أثناءه أو بعده. المؤسسة التي صححت كل مثيل معروف لكنها لم تراجع السجلات قد تفوت مهاجمًا دخل قبل الإصلاح. المؤسسة التي صيدت الاستغلال لكنها تركت منتجات ضعيفة غير معروفة مكشوفة تظل في خطر.
علنًا، غالبًا ما يُفقد هذا التمييز. قد تقول شركة إنها عالجت الثغرة. قد يسمع العملاء ذلك على أنه "لم يحدث حادث". هذان ادعاءان مختلفان. المعالجة تعني أنه تم التعامل مع الثغرة. التحقيق يعني أنه تم مراجعة الأدلة للاستغلال. إغلاق الحادث يعني أن المنظمة لديها حقائق كافية لتقول ما حدث، وما لم يحدث، وما لا يزال غير مؤكد. تطلب Log4Shell الثلاثة جميعًا.
كانت الصعوبة أن محاولات الاستغلال كانت صاخبة وواسعة الانتشار. قام المهاجمون والباحثون بمسح الإنترنت. حظرت منتجات الأمان المحاولات. احتوت السجلات على فحوصات وحمولات وأحيانًا سلاسل غامضة. كان لدى بعض المؤسسات سجلات مفصلة؛ والبعض الآخر لم يكن. سجلت بعض المنتجات الحقول الصحيحة؛ وفقدت أخرى الأدلة. كانت بعض الأنظمة متصلة بالإنترنت؛ والبعض الآخر كان قابلًا للوصول داخليًا فقط. وجود فحص لا يعني دائمًا اختراق. عدم وجود إدخال سجل لا يثبت دائمًا السلامة.
لهذا السبب كان يجب أن يكون الإثبات متواضعًا. يمكن لمنظمة مسؤولة أن تقول: هذه الأنظمة كانت ضعيفة، وتم تصحيح هذه، وتم مراجعة هذه السجلات خلال هذه الفترة، وتم العثور على هذه المؤشرات أو لم توجد، وتفتقر هذه الأنظمة إلى سجلات تاريخية كافية، وتبقى هذه الضوابط التعويضية. هذا البيان أقل ترتيبًا من "أصلحناها"، لكنه أكثر فائدة. يخبر صانعي القرار أين الثقة عالية وأين لا يزال عدم اليقين متبقيًا.
يجب أن ينطبق نفس المعيار على البائعين. إذا قال بائع منتج إن المنتج كان متأثرًا لكن لم يتم ملاحظة أي استغلال، فيجب على العميل أن يسأل كيف سيعرف البائع. هل كان للمنتج قياس عن بعد؟ هل تلقى البائع تقارير عملاء؟ هل كانت السجلات متاحة؟ هل تم حظر محاولات الاستغلال قبل الوصول إلى الوظيفة الضعيفة؟ هل كان البيان مبنيًا على غياب الأدلة أم أدلة الغياب؟ هذا المستوى من الدقة ليس تحذلقًا. إنها كيف يقرر العملاء ما إذا كان هناك حاجة إلى إجراء آخر.
ملاحظة حول الطباعة
يجب التعامل مع المخزون كضابط حي
أحرج Log4Shell مخزونات الأصول. اكتشفت العديد من المؤسسات أن قواعد بيانات إدارة الثغرات وسجلات الشراء ومخزونات السحابة وجداول بيانات مالكي التطبيقات لم تتفق. قد يعرفون اسم خدمة أعمال لكن ليس مكتباتها. قد يعرفون خادمًا لكن ليس حزمة Java داخل حاوية. قد يعرفون منتج بائع لكن ليس المكونات التي يضمها. قد يعرفون الإنتاج لكن ليس بيئات الاختبار القديمة.
NIST SP 800-40 Revision 4، دليل تخطيط إدارة تصحيح المؤسسات، مفيد لأنه يعامل إدارة التصحيح كبرنامج، وليس تدافعًا. يحتاج البرنامج إلى تحديد الأصول، والوعي بالثغرات، وتحديد الأولويات، والاختبار، والنشر، والتحقق، وإدارة الاستثناءات. أظهر Log4Shell ما يحدث عندما تكون هذه الخطوات بطيئة جدًا لحالة طوارئ. كان الاستغلال التقني سريعًا؛ كانت الخريطة التنظيمية غالبًا بطيئة.
يجب أن يشمل الإصلاح المسؤول بعد Log4Shell تحسين المخزون. أي الأنظمة تفتقد إلى ملاك؟ أي المنتجات لا يمكن فحصها؟ أي البائعين لم يستطيعوا الإجابة بسرعة؟ أي التطبيقات الداخلية لديها تبعيات قديمة؟ أي أحمال العمل السحابية كانت غير معروفة لفريق الأمان؟ أي الضوابط التعويضية كانت مرتجلة لأن المنظمة لم تكن تعرف ما تديره؟ هذه الأسئلة غير مريحة لأنها لا تقتصر على CVE واحد. إنها تكشف ضعفًا هيكليًا.
المخزون ليس قائمة ثابتة. يتغير مع قيام المطورين بنشر خدمات جديدة، وتحديث البائعين للمنتجات، وتوسع أحمال العمل السحابية، وإعادة بناء الحاويات، وبقاء الأنظمة القديمة. القائمة الدقيقة مرة واحدة في السنة لن تنجو من استجابة ليوم الصفر. يجب أن يكون الضابط حيًا بما يكفي للإجابة على الأسئلة العاجلة: أين هذا المكون، من يملكه، ما هو مكشوف، أي إصدار يعمل، كيف نحدثه، وكيف نعرف أن التحديث عمل؟
يمكن لـ SBOMs المساعدة، لكن فقط إذا كانت حالية وقابلة للاستخدام ومتصلة بالعمليات. قائمة مكونات PDF موجودة في ملفات الشراء لن تجد خادمًا مكشوفًا. يمكن لـ SBOM قابل للقراءة آليًا ومرتبط بالمنتجات والإصدارات وخلاصات الثغرات والمالكين تقصير وقت الاستجابة. يجب أن يكون معيار المساءلة عمليًا: هل ساعد المخزون الفرق في العثور على Log4j أسرع من البحث اليدوي وحده؟ إذا لم يكن كذلك، لم يكن تشغيليًا بعد.
زاوية استمرارية الخدمة العامة كانت حقيقية
أثر Log4Shell على أكثر من مجرد مخاطر المؤسسات الخاصة. الخدمات الحكومية والوكالات العامة والجامعات والأنظمة الصحية ومشغلي البنية التحتية الحيوية كان عليهم جميعًا تقييم التعرض. تظهر ملاحظة ثغرة Log4Shell من ENISA وتوجيهات ثغرات Apache Log4j من NCSC البريطاني كيف تعاملت سلطات الأمن السيبراني الوطنية مع القضية على أنها نظامية. كان ذلك مناسبًا لأن المكون الضعيف يمكن أن يكون داخل أنظمة يعتمد عليها المواطنون.
استمرارية الخدمة العامة تغير سؤال المساءلة. لا يمكن لوكالة حكومية أن تتعامل مع الإصلاح فقط على أنه نظافة سيبرانية داخلية إذا كانت البوابات العامة أو أنظمة المزايا أو خدمات الطوارئ أو منصات الضرائب أو الخدمات الصحية أو أنظمة الهوية قد تكون متأثرة. التوفر والنزاهة والثقة العامة مهمة. تصحيح متسرع يعطل الخدمة يمكن أن يضر بالمستخدمين. تصحيح متأخر يمكن أن يترك الخدمة مكشوفة. بيان عام غامض يمكن أن يقوض الثقة. يحتاج الإصلاح إلى أدلة وتنسيق.
لذلك كان دور CISA في الولايات المتحدة ليس تقنيًا فقط. ساعد في خلق توقعات مشتركة للوكالات المشمولة ونقطة مرجعية للآخرين. أعطى التوجيه والإرشاد ومركز الموارد الهيكل للوكالات للعمل. أعطى أيضًا الكونغرس وهيئات الرقابة والجمهور طريقة للسؤال عما إذا كانت الوكالات تتابع. هذه وظيفة حوكمة.
ظهرت نفس مشكلة الاستمرارية للخدمات الخاصة ذات الاعتماد العام. كان على مزودي الخدمات السحابية ومزودي المصادقة ومعالجي الدفع ومزودي الخدمات المُدارة والمستشفيات والمنصات المتعلقة بالاتصالات الحفاظ على الخدمة أثناء إصلاح التعرض. لم يهتم العملاء ما إذا كان المكون الضعيف مدفونًا ثلاث تبعيات عميقة. كانوا يهتمون ما إذا كانت الخدمة تظل جديرة بالثقة ومتاحة.
لذلك طمس Log4Shell الخط الفاصل بين إدارة الثغرات والمرونة. كان على فرق الإصلاح التصحيح دون كسر الإنتاج. كان على فرق الأمان التخفيف دون حظر حركة المرور المشروعة. كان على البائعين إصدار استشارات دون التسبب في الذعر. كان على التنفيذيين تخصيص موارد الطوارئ. كان على فرق الاتصالات تجنب اليقين الزائف. كان على السلطات العامة تنسيق التوجيه عبر الولايات القضائية. لم يكن هذا مجرد تحديث برنامج. كان تمرين استمرارية.
المجاهيل المتبقية وسؤال المساءلة
ربما لن يعرف الجمهور أبدًا سجل الإصلاح العالمي الكامل لـ Log4Shell. لا نعرف أي المنظمات وجدت كل مثيل بسرعة، وأيها ترك منتجات ضعيفة مكشوفة، وأيها تم استغلاله لكن لم يُكتشف أبدًا، أو أي استشارات البائعين كانت متأخرة جدًا لمنع الضرر. لا نعرف عدد الأنظمة الداخلية فقط التي كانت ضعيفة لكن غير قابلة للوصول من المهاجمين. لا نعرف عدد المكونات القديمة الضعيفة التي ظلت خاملة حتى وقت لاحق.
تلك المجاهيل لا تجعل المساءلة مستحيلة. إنها تحدد الأدلة المهمة. من سيطر على مخزون البرامج؟ من سيطر على استشارات البائعين؟ من سيطر على التخفيف الطارئ؟ من سيطر على الاحتفاظ بالسجلات؟ من سيطر على التنسيق مع البائعين؟ من قرر متى يكون النظام آمنًا بما يكفي للعودة إلى التشغيل العادي؟ من تحقق من أن الإصلاح طُبق على المكون الفعلي قيد التشغيل، وليس مجرد قائمة حزم؟
الجواب كان موزعًا. سيطرت Apache على إصلاحات المشروع وسجل الإفصاح لـ Log4j. سيطرت CISA على التوجيه الطارئ الفيدرالي ضمن نطاقها والتنسيق العام الأوسع. سيطرت الوكالات والمؤسسات على مخزونها وتخفيفها ومراقبتها. سيطر البائعون على الاستشارات والتصحيحات الخاصة بالمنتج. سيطر مزودو الخدمات السحابية والأمن على القياس عن بعد الدفاعي وتوجيه العملاء. سيطر العملاء على أسئلة المتابعة الخاصة بهم وقبول المخاطر المتبقية.
لا يمكن لأي ممثل واحد إغلاق المخاطر العالمية بأكملها. لكن يمكن لكل ممثل تقديم دليل أفضل للطبقة التي يتحكم فيها. هذا هو معيار المساءلة الدائم بعد Log4Shell. لا يكفي أن نقول "صححنا". يجب على الجمهور أن يسأل: ماذا وجدت، ماذا أصلحت، ماذا خففت، ماذا راقبت، ماذا فاتك، وكيف تعرف؟
من الطوارئ إلى الإصلاح الدائم
أفضل درس من Log4Shell ليس أن المنظمات تحتاج إلى الرد بشكل أسرع في المرة القادمة، رغم أنها بحاجة. الدرس الأفضل هو أن السرعة في الطوارئ تعتمد على الإعداد العادي. لا يمكنك اختراع مخزون دقيق للأصول في منتصف ثغرة يوم صفر عالمية. لا يمكنك إنشاء تعاون البائعين بعد عقود تتجاهل واجبات الأدلة. لا يمكنك صيد الاستغلال بفعالية إذا لم يتم الاحتفاظ بالسجلات أبدًا. لا يمكنك التحقق من المعالجة إذا كان الملاك والإصدارات والتبعيات غير معروفة.
لذلك يجب أن يغير الإصلاح الدائم الميزانيات والحوكمة. يجب أن تشمل مخزونات الأصول رؤية المكونات. يجب أن يتطلب الشراء الإفصاح في الوقت المناسب عن الثغرات وأدلة مكونات المنتج. يجب أن تقلل فرق التطوير من انتشار التبعيات وتحديث المكتبات القديمة. يجب أن تختبر فرق العمليات إجراءات التصحيح والتراجع الطارئة. يجب أن تحتفظ فرق الأمان بسجلات مفيدة وتحافظ على محتوى الكشف. يجب أن يعرف التنفيذيون أي الأنظمة سيكون من الأصعب تقييمها في الثغرة النظامية التالية.
هذا هو المكان الذي تصبح فيه مشكلة الإثبات منتجة. الإثبات ليس فقط للمدققين. يخبر المنظمة ما إذا كانت تستطيع التصرف. إذا كان الفريق يمكنه إثبات مكان تشغيل المكون، يمكنه التصحيح بشكل أسرع. إذا كان البائع يمكنه إثبات أي المنتجات متأثرة، يمكن للعملاء تحديد الأولويات. إذا كانت السجلات يمكنها إثبات عدم حدوث استغلال مشبوه في نافذة محددة، يمكن للقادة اتخاذ قرارات أكثر هدوءًا. إذا تم توثيق عدم اليقين المتبقي، يمكن لمالكي المخاطر أن يقرروا ما إذا كانوا سيضيفون مراقبة أو ضوابط تعويضية.
كان Log4Shell مخيفًا لأنه كان في كل مكان وعاجلاً. كان أيضًا توضيحيًا. أظهر أن استجابة الثغرات هي سلسلة من الأدلة: إفصاح المشروع، بيانات تعريف الثغرة، مخزون الأصول، استشارات البائعين، التصحيحات، التخفيفات، مراقبة الاستغلال، إشعار العملاء، ومراجعة الحوكمة. اكسر أي حلقة ويضعف سجل الإصلاح.
جعل الدور العام لـ CISA هذه السلسلة أصعب في التجاهل. من خلال تأطير Log4Shell كطوارئ تتطلب إجراءً منظمًا وإبلاغًا للوكالات المشمولة، ساعد في تحويل المحادثة بعيدًا عن شعارات التصحيح نحو الإصلاح القابل للقياس. هذا هو المعيار الذي يجب أن ترثه الثغرة النظامية التالية.
شرح مبكر حول التجريد إلى مخاطر تشغيلية
أحد الأسباب التي جعلت Log4Shell ينتشر بسرعة عبر اهتمام التنفيذيين هو أن الممارسين ترجموا الثغرة إلى عواقب تشغيلية بسيطة. ساعد الشرح التقني المبكر من LunaSec، العديد من القراء في فهم لماذا يمكن أن يصبح تسجيل المدخلات غير الموثوقة تنفيذ كود عن بعد في التكوينات المتأثرة. النقطة للمساءلة ليست أن كل تنفيذي يحتاج إلى فهم كل تفاصيل Java. إنها أن القادة بحاجة إلى فهم لماذا يمكن لمكون روتيني تحويل معالجة الطلبات العادية إلى تعرض خطير.
هذا الترجمة كانت مهمة لأن الاستجابة للطوارئ تعتمد على دعم الإدارة. لا يمكن لفرق الأمان انتظار نوافذ الصيانة العادية إذا كانت الأنظمة المتصلة بالإنترنت مكشوفة. كان على فرق الشراء الضغط على البائعين. كان على فرق العمليات الموافقة على التخفيفات التي قد تؤثر على سلوك الخدمة. كان على فرق الاتصالات شرح الحالة تحت عدم اليقين. كان على فرق المالية دعم العمل الإضافي والأدوات والمشاركة الطارئة مع البائعين. بدون شرح واضح لماذا الثغرة مهمة، يمكن أن يتعطل الإصلاح خلف العملية العادية.
كما خلقت الشروح العامة المبكرة مفردات مشتركة لغير المتخصصين. أظهرت لماذا لم يكن "نحن لا نستخدم Log4j مباشرة" إجابة كافية. يمكن لمنتج استخدام إطار، استخدم مكتبة، ضمت إصدارًا ضعيفًا. يمكن لبائع استخدامها داخل جهاز. يمكن لأداة داخلية أن تكون قد نُشرت منذ سنوات ونسيت. يمكن لمسار التسجيل استقبال سلاسل يتحكم فيها المستخدم بطرق لم يتوقعها مالكو التطبيق. هذا الواقع المتداخل جعل الاكتشاف صعبًا.
يجب على المنظمة الناضجة الحفاظ على وظيفة الترجمة هذه للثغرات النظامية المستقبلية. عندما يظهر عيب مكون عالي التأثير، يجب أن تفصل الإحاطة الأولى الآلية ومسار التعرض وفئات الأصول المتأثرة ونشاط الاستغلال العام والإصلاحات المتاحة والتخفيفات والمراقبة والأسئلة المفتوحة. لا ينبغي إجبار القادة على الاختيار بين التفاصيل التقنية التي لا يمكنهم تحليلها والإلحاح الغامض الذي لا يمكنهم حوكمته. أظهر Log4Shell أن الشرح الواضح هو بحد ذاته ضابط.
الاستثناءات كانت جزءًا من سجل المخاطر
كل موجة إصلاح كبيرة تخلق استثناءات. لا يمكن تصحيح بعض الأنظمة فورًا لأن البائع لم يصدر إصلاحًا. بعض الأنظمة هشة وتتطلب اختبارًا. بعضها لم يعد مدعومًا. بعضها لديه ملاك تشغيليون غير متاحين. بعضها معزول بما يكفي ليكون التخفيف مؤقتًا مقبولًا. بعضها حاسم للمهمة ولا يمكن إيقافه دون ضرر عام. الاستثناءات ليست تلقائيًا فشلًا. الاستثناءات غير المُدارة هي.
لذلك يجب أن يتضمن سجل إصلاح Log4Shell حوكمة الاستثناءات. أي الأنظمة المتأثرة لم تستطع التصحيح بحلول التاريخ المستهدف؟ لماذا؟ ما الضوابط التعويضية المطبقة؟ من وافق على التأخير؟ ما الدليل على أن الضابط التعويضي عمل؟ ما التاريخ المخصص للمعالجة النهائية؟ من تلقى التصعيد إذا تأخر التاريخ؟ بيان أن "الأنظمة المتبقية قيد المعالجة" أضعف من سجل استثناءات مع ملاك ومواعيد نهائية.
هذا مهم بشكل خاص لبيئات الخدمة العامة. النظام الذي يدعم وصول المواطنين قد يكون مهمًا جدًا لتصحيحه بتهور، لكنه مهم جدًا لتركه مكشوفًا. الجواب الحوكمي ليس الارتجال البطولي. إنه قرار مخاطر موثق يزن نشاط الاستغلال والتعرض والتخفيفات المتاحة واستمرارية الخدمة وخطة التعافي. يجب أن يكون رئيس المجلس أو رئيس الوكالة أو مالك المخاطر التنفيذي قادرًا على رؤية أي استثناءات متبقية ولماذا.
تكشف الاستثناءات أيضًا عن اعتماد البائعين. إذا لم تستطع المنظمة التصحيح لأن المورد لم يصدر تحديثًا مدعومًا، فهذه الحقيقة تنتمي إلى ذاكرة الشراء. يجب أن يتطلب العقد التالي استشارات أسرع وإفصاحًا أوضح للمكونات ودعمًا طارئًا. المورد الذي يترك العملاء غير قادرين مرارًا على إغلاق الثغرات الحرجة ليس بطيئًا فقط؛ إنه ينقل مخاطر الأمان إلى المشترين الذين لا يستطيعون إصلاح المنتج بأنفسهم.
أفضل سجل استثناءات هو مؤقت. يجب أن يتقلص بمرور الوقت، وليس أن يصبح قائمة دائمة من التعرض المقبول. بعد Log4Shell، المنظمات التي لا تزال لديها أنظمة متأثرة بعد أشهر تحتاج إلى شرح السبب: برامج غير مدعومة، مالك مفقود، مقاومة الأعمال، فشل البائع، أو قيد تقني حقيقي. كل سبب يشير إلى إصلاح مختلف. بدون هذا الشرح، يصبح الخطر المتبقي طبيعيًا.
إعادة الفحص كانت مهمة لأن الحقائق استمرت في التغير
لم تكن استجابة Log4Shell تمرينًا ليوم واحد. ظهرت منتجات متأثرة جديدة. نُشرت استشارات بائعين جديدة. دخلت ثغرات Log4j إضافية وإصدارات ثابتة إلى السجل العام. تطور محتوى الكشف. تحسنت الماسحات. المنظمات التي فحصت مرة واحدة وتوقفت خاطرت بفقدان حقائق لاحقة. لهذا السبب كان مركز موارد CISA ونموذج التوجيه مهمين: كان يجب أن تظل عملية الإصلاح حية مع تغير الأدلة.
يجب أن تكون إعادة الفحص رسمية. يجب أن يعرف الفريق متى آخر مرة بحث فيها عن الأصول المتأثرة، ومصدر استخبارات الثغرات الذي استخدمه، وأي استشارات البائعين راجعها، وأي نتائج الفحص تم تأكيدها، وأي الأنظمة أعيد اختبارها بعد التصحيح. إذا سميت استشارة بائع جديد منتجًا تستخدمه المنظمة، فلا يجب أن تعتمد على ذاكرة "الكل واضح" السابقة. يجب إعادة فتح العنصر.
ينطبق الشيء نفسه على عمليات البناء والنشر. قد يقوم فريق بتصحيح الإنتاج لكنه يترك تبعية قديمة في مستودع المصدر أو تعريف الحاوية. يمكن للبناء التالي إعادة إدخال المكون الضعيف. قد يقوم فريق بتصحيح فرع خدمة واحد لكنه يترك فرعًا آخر خلفه. قد ينسخ مطور مكتبة قديمة إلى مشروع جديد. يجب أن تتضمن أدلة الإصلاح منع إعادة الإدخال، وليس فقط التنظيف الطارئ.
هنا تتصل إدارة الثغرات بالتطوير الآمن. فحص التبعيات، وتثبيت الإصدارات، ومخزونات القطع الأثرية، والصور الأساسية المعتمدة، ومراجعة الإصدار ليست ضوابط براقة. إنها تمنع نفس الثغرة من الظهور مجددًا بعد حالة طوارئ عامة. المنظمة التي لا تستطيع منع إعادة الإدخال لم تصلح بيئة التحكم؛ لقد نجت فقط من الموجة الأولى.
إعادة الفحص مهمة أيضًا لثقة العملاء. البائع الذي يحدث استشارته مع تغير الحقائق قد يبدو أقل يقينًا في اللحظة، لكنه أكثر جدارة بالثقة بمرور الوقت من البائع الذي ينشر بيانًا ثابتًا ولا يعود إليه أبدًا. يعرف العملاء أن الثغرات النظامية تتطور. يحتاجون إلى البائعين ليقولوا متى تغيرت الحقائق وماذا يعني ذلك. الصمت بعد الاستشارة الأولى يمكن أن يُقرأ خطأً على أنه إغلاق حتى عندما يستمر التحقيق.
يجب الاحتفاظ بالأدلة لمراجعة الحسابات التالية
لا ينبغي أن تختفي أدلة الإصلاح التي تم إنشاؤها أثناء Log4Shell بعد الأزمة. السجلات ونتائج الفحص واستشارات البائعين وتذاكر التصحيح وموافقات الاستثناءات وإشعارات العملاء والإحاطات التنفيذية مفيدة بعد أشهر. تساعد المدققين في تقييم ما إذا كانت المنظمة قد استجابت بشكل معقول. تساعد المستجيبين للحوادث في فهم ما إذا كان النشاط المشبوه اللاحق يمكن أن يعود إلى نافذة الثغرة. تساعد فرق الشراء في تحديد الموردين الضعفاء. تساعد المهندسين في تحسين مخزون المكونات.
الاحتفاظ ليس مثل تخزين كل شيء إلى الأبد. يجب أن تحافظ المنظمة على الأدلة اللازمة لإعادة بناء القرارات. أي الأنظمة كانت متأثرة؟ ما الإجراء المتخذ؟ متى اتخذ؟ من وافق على الاستثناءات؟ ما المراقبة التي تم إجراؤها؟ ما الاتصال مع العملاء أو المنظمين الذي حدث؟ ما بقي غير مؤكد؟ يجب تخزين هذه الأدلة بطريقة تبقى على قيد الحياة لتغير الموظفين وانتشار أدوات الطوارئ.
يجب أن تقارن المراجعة طويلة الأجل أيضًا القدرة المتوقعة مع القدرة الفعلية. هل عرفت قاعدة بيانات الثغرات أين كان Log4j؟ هل وجدت الماسحات ما وجده مالكو التطبيقات يدويًا؟ هل تطابقت سجلات البائعين مع النشر الفعلي؟ هل شملت مخزونات السحابة جميع أحمال العمل الجارية؟ هل دعمت السجلات مراجعة الاستغلال؟ هل وصلت قنوات الاتصال إلى الفرق الصحيحة؟ كل فجوة يجب أن تصبح بند تحسين تحكم.
هذا يحول Log4Shell من أزمة منعزلة إلى بروفة للأزمة التالية. الثغرة النظامية التالية قد تؤثر على لغة مختلفة أو مدير حزم أو خدمة سحابية أو مكتبة مصادقة أو مكون أجهزة. سيختلف التصحيح المحدد. سلسلة الأدلة ستبدو مألوفة: حدد التعرض، نسق مع الموردين، أصلح أو خفف، راقب الاستغلال، أدر الاستثناءات، أبلغ النطاق، وأثبت الإغلاق. المنظمات التي احتفظت بأدلة Log4Shell وراجعتها يجب أن تكون أكثر استعدادًا.
يجب أن تصبح أسئلة العملاء لغة تعاقدية
طرح العملاء أسئلة عاجلة على البائعين أثناء Log4Shell: هل أنت متأثر؟ أي المنتجات؟ أي الإصدارات؟ ماذا نفعل؟ متى ستصل التصحيحات؟ هل رأيت استغلالًا؟ هل ستخطرنا إذا تغيرت الحقائق؟ يجب ألا تختفي هذه الأسئلة بعد الطوارئ. يجب أن تصبح متطلبات تعاقدية وضمانية.
سيتطلب عقد أقوى من الموردين الحفاظ على مخزونات المكونات، وتقديم استشارات الثغرات ضمن أطر زمنية محددة، ونشر مصفوفات الإصدارات المتأثرة، ودعم التخفيف الطارئ، والاحتفاظ بالسجلات ذات الصلة، والتعاون مع طلبات أدلة العملاء، وتحديث الإشعارات عندما تتغير الحقائق. سيوضح أيضًا ما إذا كان المورد يمكنه تقديم SBOMs، وما إذا كانت SBOMs حالية، وكيف يمكن للعملاء استهلاكها. الهدف ليس الأوراق. الهدف هو إصلاح أسرع عندما يظهر العيب النظامي التالي.
يجب أن يختبر ضمان المورد الممارسة أيضًا، وليس السياسة فقط. قد يدعي البائع أن لديه إدارة ثغرات، لكن يجب على العملاء أن يسألوا كم سرعة تحديد البائع لتعرض Log4j، وكيف تم إصدار الاستشارات، وكيف تم تتبع الاستثناءات، وماذا تغير بعد ذلك. البائع الذي لا يستطيع الإجابة على هذه الأسئلة قد يكون قد نجا من الحدث من خلال الجهد بدلاً من نضج التحكم.
ينطبق نفس الدرس داخليًا. يجب ألا توقع وحدات الأعمال التي تشتري البرامج عقودًا تترك فريق الأمان أعمى أثناء الطوارئ. يجب أن يعرف المشتري أي الأنظمة حرجة، وأي البائعين يحملون وظائف أساسية، وأي العقود تتضمن واجبات أدلة. يجب أن تدعم الإدارة القانونية لغة تجعل التعاون الطارئ إلزاميًا. يجب أن يفهم التنفيذيون أن البرامج الرخيصة يمكن أن تصبح باهظة الثمن إذا لم يستطع المورد الإجابة على أسئلة المكونات الأساسية أثناء الأزمة.
هذا هو قوس المساءلة من Log4Shell: ثغرة في مكون واسع الاستخدام كشفت عن مخزون ضعيف وأدلة بائعين ضعيفة وحوكمة استثناءات ضعيفة. الإصلاح ليس مجرد إصدار ثابت. إنه اتفاق أفضل حول من يجب أن ينتج أي حقائق عندما يكون الوقت قصيرًا.
يجب أن يكون معيار الإثبات إنسانيًا لكن حازمًا
سيكون من غير المنصف التظاهر بأن كل منظمة يمكنها العثور فورًا على كل مكون متأثر في ديسمبر 2021. الثغرة كانت شديدة، والمكون كان واسع الانتشار، والمعلومات العامة تطورت بسرعة. عمل العديد من المدافعين تحت ضغط شديد. يجب أن تعترف المساءلة بتلك الواقعية. لا ينبغي أن تطالب بالعلم المطلق المثالي.
لكن المساءلة الإنسانية ليست مساءلة لينة. تسأل ما إذا كانت المنظمات تحسنت بمجرد أن أصبحت الفجوة مرئية. هل وثقت عدم اليقين بدلاً من إخفائه؟ هل أعطت الأولوية للأنظمة المكشوفة؟ هل استمرت في البحث بعد الموجة الأولى؟ هل تواصلت بصدق مع العملاء؟ هل أصلحت نقاط ضعف المخزون والبائع والتسجيل بعد ذلك؟ هل جعلت الطوارئ التالية أسهل؟
هذا المعيار عادل لأنه يركز على التحكم بمرور الوقت. قد لا يكون لدى المنظمة الصغيرة مخزون كامل للمكونات في اليوم الأول. لا يزال بإمكانها إنشاء واحد أفضل. قد يحتاج البائع إلى وقت لاختبار التصحيح. لا يزال بإمكانه نشر تخفيفات مؤقتة وحالة صادقة. قد يكون لدى الوكالة العامة أنظمة قديمة. لا يزال بإمكانها تتبع الاستثناءات والإبلاغ عن المخاطر. المقياس ليس ما إذا كان كل ممثل مثاليًا. إنه ما إذا كان كل ممثل قد حول الاكتشاف الطارئ إلى تحسن دائم.
يستحق Log4Shell البقاء في سجل المخاطر لهذا السبب. إنه تذكير بأن أخطر عبارة بعد ثغرة نظامية ليست "نحن نحقق". يمكن أن تكون تلك العبارة صادقة. العبارة الخطيرة هي "صححنا" عندما لا يستطيع أحد إظهار ما تم العثور عليه، وما فات، وما تمت مراقبته، وما الأدلة التي تدعم الإغلاق.
سيصل العيب النظامي التالي تحت اسم مختلف. قد يشتمل على مكتبة هوية أو صورة حاوية أو تحكم سحابي أو حزمة تبدو عادية جدًا لتكون استراتيجية. المنظمة المسؤولة ستكون تلك التي يمكنها الإجابة بسرعة لأنها تعرف بالفعل مكوناتها وملاكها ومورديها وسجلاتها واستثناءاتها وواجبات أدلتها. هذا هو الإصلاح الحقيقي الذي يشير إليه سجل Log4Shell الخاص بـ CISA، وهو المقياس الذي يستحق حمله للمرونة.