ثغرة Fortinet SSL-VPN أظهرت كيف تحتفظ أجهزة الحافة بالمساءلة بعد يوم التصحيح

ملخص

• وصف إعلان PSIRT من Fortinet FG-IR-24-015 CVE-2024-21762 بأنها ثغرة كتابة خارج الحدود في FortiOS وFortiProxy قد تسمح بتنفيذ كود عن بعد غير مصدق، وأشار إلى أنها قد تُستغل في البرية.
• أضافت CISA CVE-2024-21762 إلى كتالوج الثغرات المستغلة المعروفة لديها، مما جعلها أولوية عامة مستغلة على الحافة للمؤسسات التي تستخدم منتجات Fortinet المتأثرة.
• تصنيف الحادثة ليس مجرد "تصحيح FortiOS". يمكن أن تظل أجهزة الوصول عن بُعد غير موثوقة إذا استغلها المهاجمون قبل التصحيح، أو جمعوا بيانات اعتماد، أو غيروا التكوين، أو أسسوا وجودًا دائمًا.
• تحكم Fortinet في أمان المنتج، وإفصاح PSIRT، والإصدارات المُصلحة، والحلول البديلة، وإرشادات التعزيز. تحكم العملاء في جرد الأجهزة، وتعرض SSL-VPN، والتصحيح الطارئ، والاحتفاظ بالسجلات، وتقييم الاختراق، وتدوير بيانات الاعتماد، وقرارات إعادة البناء.
• يدعم السجل العام نتيجة عالية الثقة بأن تصحيح أجهزة الحافة يجب أن يقترن بمراجعة ما بعد الاستغلال. لا يثبت أن كل FortiGate ضعيف قد تم استغلاله أو أن CVE-2024-21762 يفسر كل اختراق لاحق متعلق بـ Fortinet.

الإعلان نفسه وضع الاستغلال على الطاولة

الإعلان الصادر عن Fortinet، FG-IR-24-015، هو المصدر الأساسي. وصف CVE-2024-21762 بأنها ثغرة كتابة خارج الحدود في FortiOS وFortiProxy قد تسمح بتنفيذ كود عن بعد غير مصدق من خلال طلبات HTTP مصممة. قال الإعلان إن الثغرة قد تُستغل في البرية وسرد الإصدارات المتأثرة والمصلحة. تضمن أيضًا حلًا بديلًا: تعطيل SSL-VPN.

يسجل إدخال NVD لـ CVE-2024-21762 الثغرة الحرجة، بينما أضاف كتالوج الثغرات المستغلة المعروفة التابع لـ CISA CVE كأحد الثغرات المستغلة التي تتطلب المعالجة من قبل الوكالات الفيدرالية الخاضعة للتوجيه. حث تنبيه CISA، Fortinet يصدر تحديثات أمنية لـ FortiOS، المسؤولين على مراجعة الإعلان وتطبيق التحديثات.

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

منتجات Fortinet ليست بنية تحتية هامشية. تُستخدم جدران الحماية FortiGate وأجهزة FortiOS على نطاق واسع لأمان المحيط، والوصول عبر VPN، والتجزئة، والإدارة عن بُعد. وهذا يجعل نطاق الانفجار تنظيميًا. يمكن أن يصبح SSL-VPN الضعيف نقطة دخول إلى نفس البيئات التي كان من المفترض أن يحميها جدار الحماية.

تعطيل SSL-VPN هو حل بديل حقيقي بتكلفة تشغيلية حقيقية

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

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

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

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

أجهزة الحافة لها ذيل طويل من الاختراقات

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

أظهر تحليل Mandiant لاستغلال Fortinet والثبات على نشاط سابق ليوم الصفر في FortiOS كيف استخدم المهاجمون برمجيات خبيثة مخصصة وثباتًا على أجهزة Fortinet. هذا التقرير لا يتعلق بـ CVE-2024-21762 تحديدًا. إنه ذو صلة لأنه يوضح فئة المخاطر الأوسع: يمكن لجهاز Fortinet مستغل أن يصبح موطئ قدم دائم، وليس مجرد حدث دخول.

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

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

الجرد يقرر ما إذا كان التحذير يتحول إلى إجراء

عندما نشرت Fortinet الإصدارات المُصلحة، احتاج كل عميل إلى معرفة الأجهزة الموجودة، والإصدارات التي تعمل عليها، وما إذا كان SSL-VPN ممكّنًا، وما إذا كان الجهاز مواجهًا للإنترنت، ومن يملكه، وما الخدمة التي تعتمد عليه. هذا هو جرد الأصول. بدونه، الإعلان مجرد وثيقة عامة.

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

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

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

السجلات تحدد ما إذا كان التصحيح كافيًا

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

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

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

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

بيانات الاعتماد والجلسات جزء من نطاق الانفجار

يتعامل جهاز SSL-VPN مع بيانات الاعتماد والجلسات والشهادات ووضع الجهاز وعضويات المجموعات وسياسات الوصول. إذا تمكن مهاجم من اختراقه، فإن نطاق الانفجار المحتمل يتضمن حسابات المسؤول المحلي، وبيانات اعتماد مستخدمي VPN، وملفات تعريف الارتباط للجلسات، ونسخ احتياطية للتكوين، وحسابات ربط LDAP، وأسرار RADIUS، والشهادات، وسياسات جدار الحماية. ليس كل استغلال يسفر عن كل أصل. يجب أن يحدد الرد ما الذي كان يمكن أن يتعرض.

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

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

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

الحلول البديلة يمكن أن تخلق مسارات وصول ظليلة

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

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

الحل البديل لـ SSL-VPN في إعلان Fortinet كان واضحًا تقنيًا. التحدي التشغيلي كان يخص العملاء. إذا أدى تعطيل SSL-VPN إلى إنشاء حلول بديلة غير خاضعة للرقابة، كانت تلك مشكلة في تصميم الاستمرارية. إذا ترك SSL-VPN ممكّنًا مخلفًا التعرض، كان ذلك قرار مخاطرة أمنية. الخطة الجيدة تتجنب فرض هذه المقايضة تحت الضغط.

استمرارية القطاع العام ترفع الرهانات

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

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

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

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

مسؤولية البائع تتضمن التعرف على الأنماط

كانت لدى Fortinet ثغرات عديدة رفيعة المستوى عبر FortiOS وFortiGate وSSL-VPN والمنتجات ذات الصلة على مر السنين. هذا لا يعني أن كل مشكلة تشترك في سبب جذري. لكنه يعني أن البائع والعملاء يجب أن يعاملوا مخاطر التعرض للحافة كنمط متكرر للمنتج والنشر.

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

يجب أن يشمل إصلاح العميل مراجعة كل فئة أجهزة Fortinet، وليس فقط CVE محددة. هل لا تزال الإصدارات القديمة قيد التشغيل؟ هل لا يزال SSL-VPN مطلوبًا؟ هل واجهات الإدارة مقيدة؟ هل الحسابات المحلية مراجعة؟ هل السجلات مركزية؟ هل المناطق عالية المخاطر محظورة؟ هل حسابات الطوارئ مراقبة؟ هل النسخ الاحتياطية للتكوين مخزنة بشكل آمن؟

درس التعرف على الأنماط ليس معاديًا لـ Fortinet. إنه ينطبق على كل بائع للحافة. المنتجات التي توفر الوصول عن بُعد وأمان المحيط ستظل أهدافًا عالية القيمة. يجب على البائعين والعملاء التعامل مع ذلك كحقيقة تصميمية.

ما الأدلة التي من شأنها تغيير التقييم

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

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

الأدلة العامة الحالية تدعم الاستنتاج المركزي: جعلت CVE-2024-21762 من تعرض SSL-VPN اختبارًا حيًا للمساءلة. أغلق التصحيح عيبًا في المنتج. لم يثبت تلقائيًا أن كل جهاز مكشوف ظل جديرًا بالثقة.

أطر الهجوم تظهر لماذا الحافة هي خطوة أولى جذابة

تشرح تقنيتا استغلال التطبيق المواجه للجمهور و الخدمات الخارجية عن بُعد من MITRE ATT&CK منطق الخصم. يحب المهاجمون الأنظمة المواجهة للجمهور لأنها قابلة للوصول. يحبون خدمات الوصول عن بُعد لأن تلك الخدمات مصممة لربط العالم الخارجي بالموارد الداخلية. يجمع SSL-VPN الضعيف بين الميزتين.

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

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

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

الإدارة الآمنة هي التزام تصميمي

تعزز إرشادات NCSC في المملكة المتحدة حول إدارة النظام الآمنة مبدأ أساسيًا: يجب التحكم في الوصول الإداري ومراقبته وفصله عن التعرض العادي. أجهزة Fortinet هي أجهزة أمان، لكنها أيضًا أنظمة مُدارة. نفس مبادئ الإدارة الآمنة تنطبق.

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

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

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

ضوابط CIS ترسم الرد الكامل، وليس فقط التصحيح

تساعد ضوابط CIS في إظهار اتساع الرد. يحدد جرد أصول المؤسسة والتحكم فيها أجهزة FortiGate. التكوين الآمن يحد من تعرض SSL-VPN والإدارة. إدارة الحسابات تحكم المستخدمين المحليين والبعيدين. إدارة التحكم في الوصول تحد من مدى وصول VPN. إدارة الثغرات المستمرة تدفع التصحيح. إدارة سجلات التدقيق تحافظ على الأدلة. إدارة الاستجابة للحوادث توجه مراجعة الاختراق.

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

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

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

توقعات الأمان حسب التصميم تنطبق على البائع والنشر

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

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

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

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

الثغرات القديمة تؤثر على قرارات الثقة الجديدة

كانت أجهزة Fortinet موضوع ثغرات مستغلة سابقة قبل CVE-2024-21762. هذا التاريخ مهم لأن الجهاز المصحح لـ CVE الجديدة قد يظل مخترقًا من خلال مسار أقدم إذا لم يتم التحقيق في الاستغلال السابق. تؤكد تحذيرات CISA وMandiant حول ثبات Fortinet على هذه النقطة. الحالة الموثوقة للجهاز تراكمية.

يجب على المؤسسة التي صححت CVE-2024-21762 أن تسأل أيضًا ما إذا كان نفس الجهاز قد تعرض خلال ثغرات سابقة في FortiOS SSL-VPN. هل تم معالجة الإعلانات السابقة؟ هل تمت مراجعة السجلات آنذاك؟ هل تم تدوير بيانات الاعتماد؟ هل أعيد بناء الجهاز بعد تأكيد الاختراق؟ إذا لم يكن كذلك، فقد يجلس التصحيح الحالي على عدم يقين قديم.

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

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

تخطيط الاستمرارية يجب أن يشمل فقدان الوصول عن بُعد

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

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

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

هنا تواجه بعض المؤسسات مقايضات غير مريحة. يريدون ضوابط محيط قوية لكنهم لم يمولوا مسارات وصول احتياطية. يريدون تصحيحًا سريعًا لكن لديهم عمليات تغيير هشة. يريدون تعطيل SSL-VPN لكن ليس لديهم بديل مختبر. حادثة Fortinet تفرض تلك التناقضات إلى العلن.

حزمة أدلة العميل يجب أن تكون معيارية

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

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

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

السرد العام لا ينبغي أن يجعل التصحيح يؤدي عملاً أخلاقيًا

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

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

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

كيف يبدو أقوى إصلاح

أقوى إصلاح بعد CVE-2024-21762 سيشمل إجراءات من البائع والعميل. ستواصل Fortinet تحسين الإعدادات الافتراضية الآمنة وإرشادات الترقية والقياس عن بُعد ووثائق ما بعد الاستغلال. سيقوم العملاء بجرد جميع أجهزة Fortinet، وتعطيل SSL-VPN غير الضروري، وتقييد الوصول الإداري، ومركزية السجلات، وفرض مصادقة قوية، وتدوير بيانات الاعتماد الحساسة عند الحاجة، واختبار مسارات الوصول البديلة.

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

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

قرارات إعادة البناء تحتاج إلى عتبة عامة

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

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

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

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

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

أدلة الجهاز يجب أن تنجو من اختراق الجهاز

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

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

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

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

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

يجب أن تحدد العقود العمل المحرج

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

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

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

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

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

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

يجب الحكم على حادثة Fortinet من خلال ستة ضوابط.

أولاً، التعرض: هل كان SSL-VPN ممكّنًا ويمكن الوصول إليه من الإنترنت على الإصدارات المتأثرة؟

ثانيًا، سرعة المعالجة: ما مدى سرعة تطبيق المشغل للإصدارات المُصلحة أو تعطيل SSL-VPN بعد إعلان Fortinet وإدراج CISA للثغرة المستغلة؟

ثالثًا، التسجيل: هل تم الاحتفاظ بسجلات SSL-VPN والإدارة والنظام والتكوين مركزيًا ومراجعتها للكشف عن استغلال ما قبل التصحيح؟

رابعًا، استجابة بيانات الاعتماد: هل تم تدوير بيانات اعتماد المسؤول وبيانات اعتماد VPN والشهادات وأسرار التكامل حيث لا يمكن استبعاد الاختراق؟

خامسًا، قرار الثقة: هل حدد المشغل متى يتطلب FortiGate أو جهاز FortiOS إعادة بناء أو استبدال بدلاً من مجرد تصحيح؟

سادسًا، الاستمرارية: هل كان لدى المؤسسة بديل آمن لـ SSL-VPN تجنب حلول الطوارئ غير الآمنة؟

النتيجة النهائية محدودة. نشرت Fortinet إعلانًا حرجًا لـ CVE-2024-21762 وقالت إن الاستغلال ممكن في البرية. تعاملت معه CSA على أنه مستغل. كان على العملاء الذين لديهم خدمات SSL-VPN مكشوفة التحرك بسرعة. لكن درس المساءلة الأعمق هو بعد يوم التصحيح: جهاز الحافة الذي ربما تم استغلاله ليس تلقائيًا جديرًا بالثقة. الرد المسؤول يقترن التصحيح بالجرد والسجلات وتدوير بيانات الاعتماد ومراجعة الثبات وتخطيط الاستمرارية.