أليكس ماكولوك لـ«البوابة التقنية»: الخدمات الحيوية قد تتعطل دون هجوم سيبراني

قد تتوقف خدمة حيوية دون تعرض المؤسسة لهجوم سيبراني ناجح. فتعثر مورّد البرمجيات أو توقفه عن تقديم الدعم قد يضع المؤسسات أمام اختبار لا تجيب عنه الحماية من الهجمات وحدها: هل تستطيع مواصلة العمل عندما يصبح المورّد غير قادر على دعم التطبيق الذي تعتمد عليه؟

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

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

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

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

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

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

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