ملخص

  • استخدمت Storm-0558 مفتاح توقيع مستهلك من Microsoft وفشلًا في التحقق للوصول إلى بريد Exchange Online المؤسسي. مما جعل التحكم في الضرر التشغيلي مهمة تقع على عاتق المزود بالدرجة الأولى لأن العملاء لم يتمكنوا من تدوير مفتاح Microsoft أو تحديث مدقق الرموز الخاص بـ Microsoft أو فحص بيئة التوقيع الداخلية لـ Microsoft.
  • جاء اختبار المساءلة العامة الأكثر أهمية بعد فشل الثقة: مدى سرعة تمكن Microsoft من تحديد مسار الرمز المزور، وإيقاف تجديد الرموز، ومنع قبول المفتاح، واستبدال مواد التوقيع، وتوسيع سجلات العملاء، وشرح ما بقي مجهولاً.
  • خلص مجلس مراجعة السلامة الإلكترونية (CSRB) لاحقًا إلى أن الحادثة كان يمكن منعها وانتقد ثقافة الأمان لدى Microsoft وإدارة المفاتيح وضوابط التحقق والوصول إلى السجلات وتصحيح تفسير سابق لاكتساب المفتاح. قبلت Microsoft نتائج CSRB وأعلنت عن عمل مبادرة المستقبل الآمن، لكن الكثير من أدلة التنفيذ لا تزال مقدمة من المزود.
  • مسار الاكتساب غير المحسوم مهم. تم تضييق سردية تفريغ الأعطال من Microsoft إلى فرضية رئيسية بعد أن قالت الشركة إنها لم تعثر على تفريغ أعطال يحتوي على المفتاح المتأثر. وبالتالي تستند المساءلة إلى إخفاقات تحكم مثبتة وعدم يقين متبقٍ، وليس إلى سلسلة سرقة مثبتة بالكامل.

خريطة الأدلة

#المصدر العامالاستخدام في هذا التحليل
1إشعار حادثة Storm-0558 من Microsoft بتاريخ 11 يوليوالإفصاح الأولي للشركة، النطاق المبكر، آلية الرموز المزورة، وإخطار العملاء.
2التحليل الفني من Microsoft لتقنيات Storm-0558تدفق OWA وGetAccessTokenForResource، وخلل التحقق من الرمز، وتسلسل التخفيف.
3منشور تحقيق Microsoft في اكتساب المفتاحفرضية تفريغ الأعطال الأصلية، تصحيح مارس 2024، نقطة نهاية البيانات الوصفية الشائعة، وتفسير التحقق.
4مراجعة CSRB لاختراق Microsoft Exchange Onlineإعادة بناء مستقلة، نتيجة قابلية المنع، دورة حياة المفتاح، السجلات، الثقافة، والتوصيات.
5صفحة نشر CISA لتقرير CSRBسياق النشر الحكومي للمراجعة المستقلة.
6استشارة CISA-FBI AA23-193Aإرشادات المراقبة المعززة، دور سجل MailItemsAccessed، ومسؤولية المزود عن التخفيف.
7بيان سياسة السجلات من CISAموقف السياسة العامة بأن سجلات الأمان الهامة يجب ألا تتطلب ترخيصًا ممتازًا.
8إعلان Microsoft عن توسيع السجلات السحابيةالتزام Microsoft بتوسيع أحداث التدقيق والاحتفاظ بها للعملاء القياسيين.
9إعلان CISA وOMB وONCD وMicrosoft عن السجلات الفيدراليةتأكيد توسيع السجلات للوكالات الفيدرالية والاحتفاظ الافتراضي لمدة 180 يومًا.
10إحاطة وزارة الخارجية الأمريكيةرواية الوكالة المتأثرة عن حوالي 60,000 بريد إلكتروني تم تنزيلها من 10 حسابات تابعة للوزارة.
11تحقيق لجنة الرقابة بمجلس النوابسياق الرقابة من الكونغرس وقلق الوكالات المتأثرة.
12طلب تحقيق من السيناتور وايدنطلب عام لإجراء تحقيق فيدرالي وتدقيق في المساءلة.
13نص جلسة استماع لجنة الأمن الداخلي بمجلس النوابسجل جلسة استماع عامة حول إخفاقات الأمان والاعتماد الفيدرالي والإصلاح.
14شهادة براد سميث الخطيةشهادة Microsoft بقبول مشكلات CSRB ووصف عمل مبادرة المستقبل الآمن.
15إطلاق Microsoft لمبادرة المستقبل الآمنبرنامج الإصلاح الأولي، الإدارة الآلية للمفاتيح، والتزامات التوقيع المحصنة.
16توسيع Microsoft لمبادرة المستقبل الآمنأهداف لعزل المفاتيح، التدوير، التحقق من SDK، السجلات، الحوكمة، والحوافز.
17تحديث تقدم Microsoft لمبادرة المستقبل الآمن سبتمبر 2024تقدم مُبلغ عنه ذاتيًا، حوكمة، وتغييرات في ثقافة الأمان.
18توثيق منصة هوية Microsoft لرموز الوصولالسياق الفني الحالي لجمهور الرمز، المُصدر، التوقيع، والتحقق.
19توثيق Microsoft لـ OpenID Connectالسياق الفني لبيانات وصفية الاكتشاف، مفاتيح التوقيع، والتحقق من الرمز.
20إرشادات Microsoft لتدوير مفاتيح التوقيعالسياق الهندسي لتدوير المفاتيح الدوري والطوارئ.
21متابعة CISA للبنية التحتية لهوية السحابة الأساسيةدروس أوسع لهوية السحابة حول التحقق من الرمز وإدارة الأسرار.
22نظرة عامة على مجلس مراجعة السلامة الإلكترونية CISAالسياق المؤسسي لدور CSRB.

ضرر الرموز هو نمط فشل يتحكم فيه المزود

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

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

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

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

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

بقيت قصة اكتساب المفتاح غير محسومة

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

جعل CSRB عدم اليقين هذا محوريًا. أبلغ أن Microsoft حققت في العديد من الفرضيات ولا تزال لا تعرف بالضبط كيف أو متى حصلت Storm-0558 على المفتاح الخاص لـ MSA لعام 2016. هذا المسار غير المحسوم ليس ملاحظة جانبية. إذا كان مسار الاكتساب غير معروف، فلا يمكن للمزود أن يثبت علنًا أن نفس المسار قد تم إغلاقه بالكامل. يمكنه تعزيز إدارة المفاتيح وعزل أنظمة التوقيع وتحسين السجلات وأتمتة التدوير وتقليل نطاق الضرر المستقبلي. هذه ضوابط حقيقية. لكنها لا تنشئ بأثر رجعي سلسلة السرقة.

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

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

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

بدأ التحكم في الضرر بإجراءات التحقق والمفتاح

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

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

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

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

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

كان التسجيل هو محور المساءلة العامة

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

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

التزم إعلان Microsoft في يوليو 2023 بتوسيع الوصول إلى سجلات البريد الإلكتروني التفصيلية وأكثر من 30 حدث تدقيق آخر للعملاء القياسيين، وزيادة الاحتفاظ الافتراضي لـ Audit Standard من 90 إلى 180 يومًا. أعلنت CISA وOMB وONCD وMicrosoft لاحقًا عن توسيع السجلات للوكالات الفيدرالية، مع تمكين تلقائي واحتفاظ افتراضي لمدة 180 يومًا. كانت هذه التغييرات كبيرة لأنها نقلت الأدلة من إضافة مدفوعة نحو توقع أمان أساسي.

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

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

تشمل استمرارية القطاع العام الاتصالات الموثوقة

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

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

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

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

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

أصبحت ثقافة الأمان تحكمًا تشغيليًا

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

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

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

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

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

يجب أن يكون التحقق من الرمز مملًا ومركزيًا وصعب التجاوز

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

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

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

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

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

يغير عدم اليقين المتبقي عبء الضمان

تنتهي بعض الحوادث بسبب جذري دقيق وإغلاق دقيق. لا تفعل Storm-0558 ذلك، على الأقل في السجل العام. يبقى مسار اكتساب المفتاح غير محسوم. أبلغ CSRB أن Microsoft لم تستطع تحديد كيف أو متى تم الحصول على المفتاح. هذا عدم اليقين لا يمنع الإصلاح. إنه يغير عبء الضمان.

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

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

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

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

حدد عدم تناسق الأدلة سقف العميل

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

هذا عدم التناسق متأصل في الخدمات السحابية، لكنه يصبح حادًا عندما يشمل الفشل البنية التحتية لهوية المزود. في اختراق الحساب العادي، قد يكون العميل قادرًا على مراجعة أجهزة المستخدم ورسائل التصيد ومطالبات MFA وسياسات الوصول المشروط والسجلات المحلية. في Storm-0558، كان السؤال الحاسم هو لماذا قبلت خدمات Microsoft الرموز المزورة وكيف حصل المهاجم على مادة التوقيع التي تتحكم فيها Microsoft. كان هذا السؤال خارج نطاق العميل.

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

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

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

تدوير المفاتيح في حالات الطوارئ هو قدرة استمرارية

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

مناقشة CSRB لتدوير مفتاح توقيع المستهلك تجعل هذه النقطة ملموسة. أوقفت Microsoft التدوير اليدوي مؤقتًا بعد مخاوف الانقطاع ولم تكمل الاستبدال الآلي. قد يكون هذا القرار قد قلل من مخاطر التوفر الفورية، لكنه ترك مفتاحًا قديمًا موثوقًا به. لم يكن الفشل الأعمق ببساطة عمر المفتاح. لقد كان غياب مسار تدوير آمن وآلي وقابل للقياس يمكنه التعامل مع التغيير الروتيني والطارئ.

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

يحتوي التدوير في حالات الطوارئ أيضًا على مكون اتصال بالعملاء. عندما يقوم المزود بتدوير المفاتيح بعد اشتباه في الاختراق، قد يحتاج العملاء إلى معرفة ما إذا كانت تطبيقاتهم أو تكاملاتهم تتطلب إجراءً، وما إذا كانت مخابئ الرموز متأثرة، وما إذا كانت حالات فشل المصادقة متوقعة، وما إذا كانت الرموز القديمة لا تزال صالحة. خلال Storm-0558، سيطرت Microsoft على مسار Exchange Online المتأثر، لكن المبدأ الأوسع ينطبق على هوية السحابة. سلامة المفاتيح واستمرارية العملاء مرتبطان.

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

غير التسجيل الأساسي من دفع ثمن عدم اليقين

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

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

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

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

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

تصحيحات المزود هي جزء من الاستجابة للحوادث

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

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

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

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

تحتاج المسؤولية المشتركة إلى خريطة سطح تحكم

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

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

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

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

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

ملاحظة حول الطباعة وقابلية القراءة

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

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

اختبار المساءلة

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

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

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