ما الذي اختُرق وما الذي لم يُخترق

محللة أمن سيبراني تراجع سلاسل الشهادات وحالة مخازن الثقة عبر أسطول مؤسسي

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

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

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

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

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

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

لماذا حظي مستخدمو المتصفحات بالحماية أسرع من مستخدمي البرمجيات الأخرى

وصلت الطبقة الأولى من الحماية إلى المتصفحات واسعة الانتشار، لأن مزوّديها يستطيعون توزيع قرارات سحب الثقة عبر آليات تحديث مُدارة مركزياً. استخدم Chrome حظراً قائماً على SPKI ضمن CRLSet لرفض الشهادات المرتبطة بمفاتيح eMudhra الوسيطة المخترقة. والتفصيل المهم هنا أن هذا الإجراء يستهدف هوية المفتاح العام لجهة إصدار الشهادات، لا مجرد الرقم التسلسلي لشهادة واحدة. ويمنح ذلك المتصفح وسيلة لإيقاف السلاسل المتأثرة حتى عندما تكون الشهادة المقدمة جديدة أو مستبدلة أو غير مدرجة بحد ذاتها. وعلى Android، استخدمت Google أيضاً خدمات Google Play لتوسيع الحماية إلى ما هو أبعد من المتصفح نفسه، بما يتيح وصول استجابة سحب الثقة المعنية إلى الأجهزة المدعومة عبر خدمة للمنصة، بدلاً من انتظار أن تشحن كلُّ تطبيقٍ منطق الشهادات الخاص به.

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

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

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

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

وبالنسبة إلى فرق تقنية المعلومات، يكمن الفرق العملي إذاً بين حماية المتصفح التي تتحكم بها الجهة الموردة وقرارات الثقة التي تتحكم بها المؤسسة محلياً. تقلل استجابة CRLSet من Chrome، ووسائل الحماية التي توفرها Google Play Services، وإجراء OneCRL في Firefox، وتغييرات مخزن الجذور، المخاطرَ لدى العملاء الذين يتلقون هذه التغييرات ويفرضونها. لكنها لا تثبت أن كل مكوّن مستهلك للشهادات في الأسطول يتمتع بالتغطية نفسها. فالسؤال المتبقي ليس ببساطة ما إذا كان المستخدمون قد حدّثوا متصفحاتهم، بل ما إذا كانت المؤسسة قد حددت البرمجيات والأجهزة التي تحتفظ بمخازن ثقة منفصلة، أو تنفذ عمليات تحقق مستقلة من الإبطال، أو تواصل العمل عند فشل هذه التحققات.

الأعطال التشغيلية التي ينبغي لفرق تقنية المعلومات توقّعها

إلغاء الثقة بهيئة إصدار شهادات مخترقة أمر ضروري للعملاء القادرين على تطبيق التغيير، لكنه ليس محايدًا تشغيليًا. تحذّر إرشادات Google من أن إزالة emSign ECC Root CA - G3 قد تعطل شهادات سليمة لا تزال تعتمد على ذلك الجذر أو على سلسلة مرتبطة به. كما يحدد تقييم Mozilla عدة مسارات متأثرة للجذور والتوقيع المتقاطع. لذلك لا يقتصر السؤال العملي أمام فرق تقنية المعلومات على ما إذا كان المتصفح يعرض الشهادة على أنها موثوقة، بل يمتد إلى معرفة ما إذا كانت أي خدمة أعمال أو جهاز فحص أو حزمة برمجية أو عملية تحقق لا تزال تعتمد على مسار ستُرفع عنه الثقة قريبًا.

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

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

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

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

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

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

خطة استجابة يمكن الدفاع عنها للبيئات المختلطة

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

استخدموا إرشادات المورّد كنقطة التحكم الأولى. طبّقوا تحديثات Chrome وFirefox وAndroid وUbuntu وحزم البرامج الأخرى ذات الصلة عبر إجراءات التغيير المعتادة، ثم تحققوا من وجود تغيير مخزن الثقة أو الإلغاء المتوقع على أنظمة تمثيلية. ويكتسب تحديث ca-certificates في Ubuntu أهمية خاصة للأنظمة التي تعتمد على حزمة الثقة الخاصة بالتوزيعة، بينما يجب فحص المتصفحات والتطبيقات التي تستخدم مخازنها الخاصة بصورة مستقلة. سجّلوا إصدار الحزمة أو المتصفح، وحالة التحديث، ووضع مخزن الثقة لكل منصة مدعومة، حتى يحمل وصف «مصحح» معنى قابلًا للتحقق بدل استنتاجه من مجرد تسجيل الجهاز دخوله.

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

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

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

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

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