IOS XE وصيد مستوى الإدارة: اختبار مساءلة

الملخص

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

لماذا تنتمي هذه الحالة إلى ملف المخاطر والمساءلة

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

بالنسبة لشركة Cisco Systems, Inc.، تدور القضية حول واجهة المستخدم ويب لـ IOS XE، CVE-2023-20198، CVE-2023-20273، إنشاء حسابات مميزة، كتابة برمجيات خبيثة، تعرض خادم HTTP، إرشادات CISA، الإصدارات المُصلحة، وأدلة التعافي بعد الاستغلال. هذه أسماء تشغيلية، لكنها أيضًا أسماء حوكمة. إنها تسمي من كان بإمكانه منع الحدث، ومن كان بإمكانه الحد من نصف قطر الانفجار، ومن كان بإمكانه جعل الحدث أسهل للكشف، ومن كان بإمكانه جعل الإصلاح مرئيًا لأولئك الذين اعتمدوا عليه. سجل المساءلة الناضج لا يكتفي ببيان أن التحقيق قد اكتمل أو أن الأنظمة قد تم استعادتها.

إنه يسأل عن الدليل الذي جعل هذا البيان صحيحًا، وما الدليل الذي ظل غير مكتمل، ومن كان عليه التصرف قبل توفر هذا الدليل.

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

واجب الإثبات الأول هو التحكم، وليس اللوم

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

في هذه الحالة، يشمل سطح التحكم ذلك واجهة المستخدم ويب لـ IOS XE، CVE-2023-20198، CVE-2023-20273، إنشاء حسابات مميزة، كتابة برمجيات خبيثة، تعرض خادم HTTP، إرشادات CISA، الإصدارات المُصلحة، وأدلة التعافي بعد الاستغلال. هذه العناصر ليست قائمة زخرفية. إنها الأماكن التي تصبح فيها المساءلة إما مرئية أو تذوب في الذاكرة المؤسسية.

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

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

حد مصدر واحد لهذا القسم هوhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

تعالج هذه المقالة بيانات الشركة كدليل على ما قالته الشركة وأبلغت عنه، وليس كدليل مستقل على كل حقيقة جنائية خاصة. حد مصدر ثانٍ هوhttps://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

يجب أن يتطابق ملف الأدلة مع سطح التشغيل

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

حد مصدر واحد لهذا القسم هوhttps://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

تُستخدم سجلات الحكومة والجهات التنظيمية للواجبات العامة والإشعارات وفئات التحكم، بينما لا تُعامل كإعادة بناء تقنية ضحية بضحية. حد مصدر ثانٍ هوhttps://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-dublin-17121/221128-software-fix-availability-for-cisco-ios.html. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

إجراء العميل عادل فقط عندما تكون أدلة المزود قابلة للاستخدام

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

حد مصدر واحد لهذا القسم هوhttps://sec.cloudapps.cisco.com/security/center/softwarechecker.x. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

يُستخدم تحليل بائع الأمان للتقنيات المرصودة وإرشادات المدافع والتسلسل الزمني، لكن المقالة لا تحول لغة الحملة الواسعة إلى ادعاء حول كل عميل أو منشأة. حد مصدر ثانٍ هوhttps://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

مراجعة موثوقة تفصل ما كان معروفًا عما تم استنتاجه

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

حد مصدر واحد لهذا القسم هوhttps://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

وثائق المنتج الحالية مفيدة لتصميم التحكم الحالي ومفردات القارئ، وليس كدليل على أن الميزة تم نشرها بنفس الطريقة خلال فترة الحادث. حد مصدر ثانٍ هوhttps://nvd.nist.gov/vuln/detail/CVE-2023-20198. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

يجب أن يكون الإصلاح قابلاً للقياس بعد الإعلان

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

حد مصدر واحد لهذا القسم هوhttps://nvd.nist.gov/vuln/detail/CVE-2023-20273. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

حيثما تظهر ملفات قانونية أو إجراءات عامة، يتم التعامل معها كسجلات إجرائية أو إفصاحية ما لم يكن الحكم النهائي واضحًا في المصدر المذكور. حد مصدر ثانٍ هوhttps://www.cve.org/CVERecord?id=CVE-2023-20198. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

يجب أن يحافظ التدقيق التالي على عدم اليقين بدلاً من تنعيمه

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

حد مصدر واحد لهذا القسم هوhttps://www.cve.org/CVERecord?id=CVE-2023-20273. إنه مفيد لملف الأدلة العامة، لكنه لا يستطيع الإجابة على كل سؤال ملكية داخلي. الهدف ليس تضخيم المصدر. الهدف هو توضيح ما يمكنه إثباته، وما يمكنه فقط وضعه في سياق، وما يظل خارج الملف العام. هذا الانضباط مهم بشكل خاص عندما تستخدم النسخة العامة عبارات مثل حادث، اختراق، وصول، تأثر، استعادة، آمن، أو علاج. يمكن أن تكون هذه الكلمات دقيقة ومع ذلك غامضة جدًا لدعم قرار ما لم تكن مرتبطة بالتواريخ والأنظمة والأشخاص والجماهير المتأثرة والاستثناءات المتبقية.

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

تحافظ المقالة على الأسئلة غير المحلولة لأن الأسئلة غير المحلولة جزء من سجل المساءلة وليس عيبًا في الكتابة لإخفائه. حد مصدر ثانٍ هوhttps://www.cisa.gov/known-exploited-vulnerabilities-catalog. عند قراءتهما معًا، تدعم المصادر أسلوب مراجعة مسؤولة: ليس حكمًا، ولا ضمانًا تسويقيًا، ولا إعادة بناء جنائية لا يسمح بها السجل العام، بل خريطة لما يمكن للقارئ معرفته بمسؤولية. لهذا السبب تعود هذه المقالة باستمرار إلى السيطرة العملية. المساءلة ليست نفس المعرفة المطلقة. إنها الالتزام بالقول أي دليل غير أي قرار، ومن كان لديه القدرة على تغيير التحكم ذي الصلة، وأي الأشخاص تحملوا التكلفة بينما كانت المؤسسة لا تزال تجمع الأدلة.

كيف ستبدو الأدلة الأفضل

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

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

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

ملف أدلة القارئ

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

المصدر العام المستخدم لملف الأدلة:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z
المصدر العام المستخدم لملف الأدلة:https://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities
المصدر العام المستخدم لملف الأدلة:https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/
المصدر العام المستخدم لملف الأدلة:https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-dublin-17121/221128-software-fix-availability-for-cisco-ios.html
المصدر العام المستخدم لملف الأدلة:https://sec.cloudapps.cisco.com/security/center/softwarechecker.x
المصدر العام المستخدم لملف الأدلة:https://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening
المصدر العام المستخدم لملف الأدلة:https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
المصدر العام المستخدم لملف الأدلة:https://nvd.nist.gov/vuln/detail/CVE-2023-20198
المصدر العام المستخدم لملف الأدلة:https://nvd.nist.gov/vuln/detail/CVE-2023-20273
المصدر العام المستخدم لملف الأدلة:https://www.cve.org/CVERecord?id=CVE-2023-20198
المصدر العام المستخدم لملف الأدلة:https://www.cve.org/CVERecord?id=CVE-2023-20273
المصدر العام المستخدم لملف الأدلة:https://www.cisa.gov/known-exploited-vulnerabilities-catalog
المصدر العام المستخدم لملف الأدلة:https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
المصدر العام المستخدم لملف الأدلة:https://www.cisa.gov/news-events/directives/bod-23-02-mitigating-risk-internet-exposed-management-interfaces
المصدر العام المستخدم لملف الأدلة:https://www.cisa.gov/securebydesign
المصدر العام المستخدم لملف الأدلة:https://csrc.nist.gov/pubs/sp/800/61/r2/final
المصدر العام المستخدم لملف الأدلة:https://csrc.nist.gov/pubs/sp/800/40/r4/final
المصدر العام المستخدم لملف الأدلة:https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/cisco-ios-xe-software-web-ui-zero-day-vulnerability
المصدر العام المستخدم لملف الأدلة:https://www.cyber.gc.ca/en/alerts-advisories/vulnerability-impacting-cisco-devices-cve-2023-20198

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

أسئلة مراجعة مجلس الإدارة

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

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

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

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