ملخص

  • قالت كومودو إن حساب سلطة تسجيل تم اختراقه في 15 مارس 2011 واستخدم لإصدار تسع شهادات احتيالية عبر سبعة نطاقات؛ يدعم السجل العام فشلًا في الإصدار المفوض، وليس اكتشافًا أن مفاتيح الجذر لكومودو أو وحدات أمان الأجهزة سُرقت.
  • كانت قضية المساءلة أوسع من الشهادات التسع. استهدفت الشهادات وجهات رئيسية لتسجيل الدخول والبريد وملحقات المتصفح والاتصالات، لذا كان على كل متصفح ومنصة ومؤسسة وشبكة عامة تعتمد عليها أن تثق في أن الإلغاء وعدم الثقة الطارئ سيصلان فعليًا إلى المستخدمين.
  • لم تعتبر موزيلا ومايكروسوفت إلغاء المُصدر كافيًا بذاته. أصدرت موزيلا تحديثًا للقائمة السوداء ووضعت مايكروسوفت الشهادات في مخزن الشهادات غير الموثوق به في ويندوز لأن سلوك CRL و OCSP لم يستطع ضمان الحماية في جميع ظروف الشبكة.
  • سيطرت كومودو على نموذج الإصدار المفوض ومصادقة الشريك وأدلة الحادث؛ سيطر موردو المتصفحات وأنظمة التشغيل على الإنفاذ الطارئ؛ سيطرت برامج الجذر على الثقة المستمرة؛ وتحمل مالكو النطاقات والوكالات العامة المخاطر النهائية دون رؤية حساب سلطة التسجيل أو سجلات المُصدر.
  • الدرس الدائم هو أن مساءلة PKI على الويب يجب أن تقيس الإخطار والإنفاذ والإصلاح، وليس فقط عدد الشهادات. يمكن لسلطة الشهادات إلغاء شهادة بسرعة وتبقي الأطراف المعتمدة معرضة للخطر إذا لم يكن عدم الثقة قابلاً للمراقبة والإنفاذ.

سجل الأدلة وكيفية استخدامه

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

#السجل العامالاستخدام في هذا التحليل
1تقرير حادث كومودومصدر حادث CA الأساسي لاختراق حساب RA في مارس 2011، الشهادات التسع، النطاقات المتأثرة، ادعاءات الإلغاء، بيان مراقبة OCSP، وحدود عدم اختراق HSM.
2متابعة موزيلامصدر مورد المتصفح لوصف اختراق شريك RA، استجابة القائمة السوداء في فايرفوكس، وقلق برنامج جذر موزيلا.
3نشرة أمان موزيلا 2011-11نشرة المتصفح الأساسية لتحديث القائمة السوداء للشهادات والمعالجة عالية التأثير للشهادات الاحتيالية.
4موزيلا بجزيلا 642395سجل الهندسة العامة لعمل الحظر من موزيلا وأثر الأدلة التشغيلية.
5نشرة أمان مايكروسوفت 2524375نشرة المنصة للانتحال والتصيد وخطر الوسيط وحدود CRL/OCSP وتحديث المخزن غير الموثوق به في ويندوز.
6صفحة إعادة تسمية كومودو CA من سكتيغومصدر تاريخ الشركة الحالي يُستخدم فقط لتأطير سكتيغو كعلامة تجارية خلف لأعمال كومودو CA.
7صفحة عن سكتيغوسياق الشركة الحالي لتأطير أعمال دورة حياة الشهادات والثقة الرقمية.
8المتطلبات الأساسية لمنتدى CA/المتصفحمتطلبات PKI الحالية للتحقق والإصدار والإلغاء وعمليات CA.
9سياسة مخزن جذر موزيلامصدر حوكمة برنامج الجذر للثقة المشروطة والتزامات CA.
10إرشادات استجابة CA للحوادث من موزيلاإرشادات موزيلا لسوء إصدار CA والمعالجة وتوقعات الاتصال.
11سياسة برنامج جذر كروميومسياق سياسة جذر المتصفح للثقة من جانب المنصة ومساءلة CA.
12برنامج شهادات جذر أبلسياق سياسة جذر المنصة لحوكمة مخزن الثقة.
13برنامج الجذر الموثوق به من مايكروسوفتمصدر سياسة جذر المنصة لمتطلبات مخزن الجذر وسطح الإنفاذ.
14CCADBقاعدة بيانات CA العامة وسياق التنسيق لبرامج الجذر ورؤية الحوادث.
15RFC 5280معيار ملف شهادة X.509 وCRL المستخدم لهندسة الإصدار والإلغاء.
16RFC 6960معيار OCSP المستخدم لمناقشة حالة الشهادة والإلغاء.
17RFC 6962RFC تجريبي لشفافية الشهادة يستخدم لسياق الرؤية اللاحق.
18RFC 9162معيار شفافية الشهادة الإصدار 2 يستخدم لسياق التدقيق والمراقبة.
19سياسة شفافية الشهادة من كروممصدر سياسة المتصفح لتوقعات تسجيل CT.
20إرشادات HTTPS من CISAسياق موجه للمستخدم في القطاع العام لكيفية اعتماد ثقة HTTPS على الشهادات والمتصفحات.

عدد الشهادات الصغير أخفى مشكلة تفويض كبيرة

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

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

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

لهذا السبب ينتمي الحادث إلى قوة تفويض DNS على الرغم من أن الفشل المباشر كان إصدار شهادة. DNS و TLS نظامان منفصلان، لكن المستخدم يختبرهما معًا كادعاء حول مكان وجوده على الإنترنت. يمكن لـ DNS توجيه المستخدم نحو عنوان. يخبر TLS المتصفح ما إذا كان يُسمح لنقطة النهاية هذه بالتحدث باسم اسم. عندما يتم تفويض إصدار الشهادة من خلال ضوابط ضعيفة، يمكن لمالك النطاق أن يفقد ضمان الهوية العملية دون تغيير DNS الخاص به أو خوادمه أو مفاتيحه الخاصة.

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

الإلغاء كان ضروريًا ولكنه لم يكن كافيًا

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

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

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

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

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

الإخطار كان يجب أن يصل إلى أطراف ذات مهام مختلفة

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

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

يجب أن يفصل الإخطار الجيد أيضًا بين الأدلة والضمان. من المفيد أن تقول كومودو إن البنية التحتية لـ CA ومفاتيح HSM لم تخترق، لأن ذلك يمنع الذعر الواسع حول كل شهادة في السلسلة. من الضروري أيضًا القول إن الإصدار المفوض فشل، وإلا قد يستنتج المستخدمون والمشترون أن غياب سرقة المفتاح الجذري يعني أن نظام الثقة عمل. الرسالة الصحيحة أضيق وأكثر جدية: قد يكون الجذر الرياضي قد ظل آمنًا بينما أنتجت حافة الإصدار الإدارية هويات احتيالية.

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

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

مخازن الجذر هي برامج خاصة بعواقب عامة

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

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

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

تمثل متطلبات منتدى CA/المتصفح الحالية وسياسة موزيلا وسياسة كروميوم ومواد برنامج أبل ومتطلبات مايكروسوفت وتنسيق CCADB بيئة حوكمة أكثر وضوحًا مما كانت موجودة في 2011. لا ينبغي إساءة استخدامها كدليل بأثر رجعي على أن عنصر تحكم قديم واحد انتهك بندًا حاليًا. صلتها استشرافية: تُظهر أن النظام البيئي تعلم التعبير عن ثقة المتصفح كثقة تشغيلية مشروطة بدلاً من سمعة دائمة.

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

يجب أن يكون سجل الإنفاذ قابلاً للتحقق

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

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

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

يجب أن يغير حادث كومودو أيضًا كيف تفكر المنظمات في مخاطر "الطرف الثالث". قد لا يتعاقد مالك النطاق مع CA المخترقة، ومع ذلك يمكن لشهادة من تلك CA انتحال شخصية النطاق إذا وثقت المتصفحات في السلسلة. هذا نوع مختلف من التعرض للمورد: إدراج مخزن الثقة يخلق مجموعة موردين مشتركة للويب بأكمله. يمكن لمالكي النطاقات تقليل المخاطر من خلال مراقبة CT وسجلات CAA وجهات اتصال الحوادث والتصعيد السريع، لكنهم لا يستطيعون الانسحاب بالكامل من نظام الثقة العام.

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

الإنفاذ هو سلسلة، وليس حدث إلغاء واحد

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

لم تكن أي من هذه الخطوات اختيارية إذا كان الهدف هو حماية المستخدم العملية.

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

هذا الغياب ليس غير معتاد. حوادث PKI على الويب موزعة بطبيعتها. لا يعرف موردو المتصفحات دائمًا أي المستخدمين تلقوا تحديثًا في أي وقت. قد تعرف CA حالة الإلغاء ولكن ليس إنفاذ نقطة النهاية. قد يرى مالك النطاق سجلات CT أو حركة OCSP ولكن ليس كل اعتراض محاول. لكن غياب الرؤية المثالية لا ينبغي أن يعفي من غياب المؤشرات المفيدة. لا يزال بإمكان برامج الجذر و CAs نشر الأرقام التسلسلية للشهادات وأوقات الإلغاء وأوقات الإفصاح وأوقات إخطار المتصفح ومراجع سجل CT ومسارات التحقق المتأثرة وفئات المعالجة. تتيح هذه المؤشرات للمنظمات التابعة أن تقرر ما إذا كانت نافذة المخاطرة الخاصة بها لا تزال مفتوحة.

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

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

الإصدار المفوض يحول أمن الشريك إلى بنية تحتية عامة

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

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

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

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

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

ما الذي سيتضمنه تقرير ما بعد الحادث الحديث الأقوى

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

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

الطبقة الثالثة ستقيس إنفاذ النظام البيئي. متى تم إخطار موزيلا ومايكروسوفت وأبل وكروميوم وبرامج الجذر أو المنصات الأخرى ذات الصلة؟ أي تحديثات أو آليات عدم ثقة تم شحنها؟ هل تحققت CA من أن مستجيبي الإلغاء لديهم سعة كافية وحالة صحيحة؟ هل تم مراقبة استجابات OCSP و CRL للاستخدام المحاول بعد الإلغاء؟ هل تلقى مالكو النطاقات إخطارًا مباشرًا؟ هل تلقت فرق القطاع العام والمؤسسات إرشادات قابلة للتنفيذ؟ لا يتم إصلاح حادث شهادة حتى تحصل الأطراف التي يمكنها إنفاذ عدم الثقة على أدلة كافية للقيام بذلك.

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

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

قرار القارئ لثقة الشهادة

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

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

بالنسبة لبرامج الجذر، يظل حدث كومودو تذكيرًا بأن الثقة العامة يجب أن تكون مشروطة ومستندة إلى أدلة. يمكن لـ CA الاستجابة بسرعة لحادث واحد وتظل بحاجة إلى مراجعة أعمق لسلطة الشريك. لا ينبغي أن يكون الإنفاذ مرتجلًا حالة بحالة؛ يجب أن يكون مرتبطًا بسياسة منشورة وتوقعات تقارير الحوادث وأدلة التكرار. لا يحتاج الجمهور إلى كل تفاصيل التدقيق السرية، لكنه يحتاج إلى ما يكفي من النمط لمعرفة ما إذا كان الإصدار المفوض أكثر أمانًا بعد الحادث مما قبله.

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

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

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

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

الخلاصة

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

حد أدلة إضافي

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

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

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