المرونة السيبرانية بعد الأمن: لماذا أصبحت قدرة مؤسسية وليست وظيفة تقنية فقط؟

من الدفاع إلى القدرة المؤسسية

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

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

خمسة مكونات يجب أن تعمل معًا

الأمن

منع الهجمات واكتشافها والاستجابة لها.

الهوية والصلاحيات

التأكد من أن الوصول مرتبط بهوية موثوقة، وبأقل صلاحية لازمة، مع إمكانية السحب والتغيير.

الاستمرارية والتعافي

القدرة على إبقاء الوظائف الحرجة ضمن حدود مقبولة، ثم استعادة الخدمة بعد الاضطراب.

الامتثال والأدلة

ربط المتطلبات بالضوابط والأدلة والإجراءات التصحيحية بدل الاعتماد على ملفات تدقيق منفصلة.

الحوكمة والمساءلة

وضوح من يملك القرار، ومن يستطيع قبول الخطر، ومن يفعّل الاستجابة، ومن يثبت أن الإجراء أُغلق.

لماذا يزيد AI التعقيد؟

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

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

المرونة تحتاج إثباتًا

وجود Policy لا يثبت أن المؤسسة مرنة. الدليل الأقوى يأتي من التشغيل:

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

اختبار سيادة للمرونة السيبرانية

اسأل خمسة أسئلة:

1. ما الخدمات والأنظمة التي لا يمكن أن تتوقف دون أثر مادي؟
2. ما الاعتماديات الخارجية التي قد تمنعنا من الاستمرار أو الاستعادة؟
3. هل يمكننا معرفة من يملك صلاحية التدخل عند الحادث؟
4. هل نستطيع إثبات حالة الضوابط دون حملة يدوية لجمع الأدلة؟
5. هل اختبرنا الاستعادة والخروج، أم اكتفينا بتوثيق الخطة؟

الحد الفاصل

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

كيف نقيس المرونة فعلًا؟

المؤسسة المرنة لا تُقاس بعدد أدوات الحماية، بل بقدرتها على الحفاظ على وظائف حرجة ضمن حدود مقبولة ثم استعادة الوضع والسيطرة والأدلة بعد الاضطراب.

يمكن التفكير في المرونة عبر أربع مراحل:

Absorb → Contain → Recover → Learn

إذا كانت المؤسسة جيدة في المنع لكنها بطيئة في الاستعادة، فهي ليست مرنة بما يكفي.

Critical Service Mapping

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

هذا يكشف اعتماديات لا تظهر عندما ننظر إلى كل نظام منفردًا.

Recovery يجب أن يشمل السلطة

خطة الاستعادة التقنية لا تكفي. أثناء الحادث نحتاج معرفة من يملك صلاحية:

• عزل نظام.
• إيقاف Agent أو Model endpoint.
• سحب Credentials.
• تشغيل fallback.
• قبول وضع degraded mode.
• إعلان العودة إلى التشغيل الطبيعي.

Evidence of Resilience

يمكن إثبات المرونة من خلال:

• نتائج اختبارات الاستعادة.
• زمن التحول إلى البديل.
• سجلات التدخلات الحرجة.
• نتائج tabletop exercises.
• زمن إغلاق findings.
• اختبارات الخروج من مزود أو خدمة.
• قياس الاعتماديات المشتركة.

AI يغير شكل الحوادث

قد لا يكون الحادث اختراقًا. قد يكون تغيرًا مفاجئًا في النموذج، Output غير موثوق، فشل API، Drift، فقدان visibility أو Agent يتجاوز نطاقه.

لذلك يجب أن تتسع Incident Taxonomy لتشمل فشل AI operationally وليس فقط cyber compromise.

سؤال الإدارة العليا

بدل السؤال «هل نحن آمنون؟» الأفضل أن يكون:

ما الوظائف التي قد نفقد السيطرة عليها إذا تعطل مورد أو هوية أو نموذج اليوم، وكم نحتاج لاستعادتها؟

هذا السؤال يجبر المؤسسة على ربط الأمن بالاستمرارية والسيادة والأدلة.