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

قد تتوقف خدمة حيوية من دون أن تتعرض المؤسسة لهجوم سيبراني ناجح. فتعثّر مورّد البرمجيات أو توقفه عن تقديم الدعم قد يضعها أمام اختبار لا تجيب عنه الحماية من الهجمات وحدها: هل تستطيع مواصلة العمل عندما يصبح المورّد غير قادر على دعم التطبيق الذي تعتمد عليه؟ هذا السؤال هو نقطة انطلاق حوار «البوابة التقنية» مع أليكس ماكولوك، مدير تطوير الأسواق – الشرق الأوسط، في شركة ‎Escode‎. ويرى ماكولوك أن وجود خطط مكتوبة وضمانات تعاقدية لا يكفي لإثبات المرونة التشغيلية ‎(Operational Resilience)‎؛ إذ تحتاج المؤسسات إلى أدلة على أن ترتيبات الاستمرارية قابلة للتفعيل، وأن المواد التقنية اللازمة للتعافي محدّثة وقد خضعت للاختبار. ويشرح ماكولوك دور الحساب الضامن للبرمجيات ‎(Software Escrow)‎ وأهمية التحقق التقني ‎(Technical Verification)‎ ضمن نطاق الخدمة المتفق عليه، مع التمييز بين حق الوصول إلى البرمجيات وقدرتها الفعلية على دعم التعافي. كما يناقش كيفية تحديد أوجه الاعتماد الأكثر تأثيرًا في أعمال المؤسسة، والأسئلة التي ينبغي أن تطرحها مجالس الإدارة قبل وقوع الاضطرابات. لا شك في أن الأمن السيبراني ركيزة أساسية للمرونة، لكنه ليس المسألة الوحيدة التي ينبغي للمؤسسات الاستعداد لها. فقد تتعطل خدمة حيوية حتى من دون وقوع هجوم سيبراني ناجح. إذ قد يواجه مورّد التكنولوجيا ضائقة مالية، أو يوقف تقديم الدعم، أو يتعرض لإخفاق تشغيلي، أو يتأثر هو نفسه بحادث سيبراني أو باضطرابات جيوسياسية أوسع نطاقًا. وما تغفل عنه المؤسسات أحيانًا هو مدى اعتمادها على المورّد الذي يقف وراء تطبيق حيوي. فإذا لم يعد هذا المورّد قادرًا على دعم البرمجيات، يصبح السؤال الأساسي: ما الخيارات العملية المتاحة للمؤسسة للحفاظ على الاستمرارية التشغيلية ‎(Operational Continuity)‎ لتلك الخدمة الحيوية؟ لهذا، ينبغي بناء المرونة التشغيلية منذ مرحلة التصميم، وقبل وقوع الاضطرابات. وعلى المؤسسات أن تحدد أوجه اعتمادها على البرمجيات الحيوية، وأن تضع ترتيبات الاستمرارية مسبقًا، وأن تتبيّن ما إذا كانت هذه الترتيبات قادرة فعليًا على دعم التعافي إذا تعذّر استمرار المورّد في تقديم الدعم. نقطة البداية ليست البرمجيات نفسها، بل العملية الحيوية التي تعتمد عليها. ينبغي لكبار مسؤولي المعلومات وقادة إدارة المخاطر تحديد التطبيقات التي تدعم الخدمات الحيوية، ثم فهم أوجه الاعتماد التي تستند إليها هذه التطبيقات. ويعني ذلك، عند الضرورة، تجاوز النظر إلى المورّد المباشر، وفهم المنظومة الأوسع من الأطراف الثالثة والرابعة التي تدعم الخدمة. وعليهم بعد ذلك تقييم ما قد يحدث إذا لم يعد أحد العناصر التي تعتمد عليها تلك التطبيقات متاحًا. هل يمكن استبدال البرمجيات بسرعة وأمان؟ وهل تستطيع المؤسسة الانتقال إلى مزوّد آخر ضمن إطار زمني مقبول؟ أم أن فقدان دعم المورّد سيسبب مشكلة جوهرية في الاستمرارية؟ عندما يكون الاستبدال صعبًا أو مكلفًا أو محفوفًا بمخاطر تشغيلية، تحتاج المؤسسات إلى وضع ترتيبات بديلة للاستمرارية قبل وقوع الاضطرابات. ولهذا، لا ينبغي التعامل مع مخاطر البرمجيات التي توفرها أطراف ثالثة بوصفها مجرد مسألة تتعلق بالمشتريات. فعندما تدعم البرمجيات عملية حيوية، يصبح الاعتماد على المورّد مسألة مرتبطة بالمرونة التشغيلية. تظهر الفجوة عندما تفترض المؤسسات أن وجود ترتيب تعاقدي أو خطة موثّقة للاستمرارية يعني تلقائيًا قدرتها على التعافي. لا تكون للخطة قيمة إلا إذا أمكن تفعيلها فعليًا. وفيما يتعلق بالبرمجيات الحيوية، تحتاج المؤسسات إلى حقوق وصول واضحة، ومواد تقنية محدّثة، ووثائق مناسبة، ومعرفة تشغيلية، وإجراءات تعافٍ خضعت للاختبار، مع تحديد شروط الإنهاء والتسليم ‎(Release Conditions)‎. كما ينبغي الحفاظ على هذه الترتيبات وتحديثها مع تغيّر البرمجيات بمرور الوقت. وتكتسب هذه المسألة أهمية خاصة في الحساب الضامن للبرمجيات. إذ تحدد اتفاقية الحساب الضامن للبرمجيات حقوق الوصول إلى المواد المودعة ‎(Deposited Materials)‎ وشروط الإنهاء والتسليم. لكن وجود هذه الحقوق وحده لا يثبت قدرة المواد على دعم التعافي؛ بل ينبغي إجراء التحقق التقني من قابليتها للاستخدام وفق نطاق الاختبارات المتفق عليه. ولهذا، فإن المبدأ واضح: ينبغي التحقق من المرونة، لا افتراضها. وينبغي لترتيبات الاستمرارية المتينة أن توفر أدلة على أن المواد المودعة مكتملة ومحدّثة وقادرة على دعم التعافي عند الحاجة. ينبغي أولًا التمييز بين الوصول إلى المواد وقابليتها للاستخدام. في الحساب الضامن للبرمجيات، يودع مطور البرمجيات ‎(Software Developer)‎ الأصول البرمجية، بما يشمل كود المصدر ‎(Source Code)‎ والوثائق الداعمة، لدى وكيل الحساب الضامن للبرمجيات، وهو طرف ثالث مستقل. وتحدد الاتفاقية شروط تسليم هذه المواد إلى المستفيد ‎(Beneficiary)‎. ويشمل دور الوكيل التحقق التقني من المواد واختبارها وفق النطاق المتفق عليه، للإجابة عن سؤال عملي: هل يمكن استخدام هذه المواد لاستعادة تشغيل البرمجيات عند الحاجة؟ على المستوى الأساسي، تحتاج المؤسسات إلى التأكد من أن المواد المودعة مكتملة ومحدّثة، وتشمل الملفات المنصوص عليها في الاتفاقية، وأن الوثائق التقنية شاملة وكافية. وبحسب نطاق التحقق التقني المتفق عليه، يمكن أن يشمل التقييم اختبار إمكانية إعادة بناء البرمجيات أو نشرها أو تشغيلها فعليًا باستخدام المواد المودعة. كذلك، يمكن أن تكون اختبارات السيناريوهات ‎(Scenario Testing)‎ بالغة الفائدة، لأنها تنقل النقاش من التوثيق إلى التعافي العملي. فعلى سبيل المثال، أنجز «فيجن بنك» عملية تحقق تقني من مرحلتين، جمعت بين تقييم نقل المعرفة واختبار السيناريوهات عمليًا لتطبيق سحابي حيوي. وأكدت العملية قابلية استخدام المواد المودعة وتعليمات النشر ومعلومات التهيئة وآليات الوصول. لذلك، لا يقتصر السؤال الجوهري على ما إذا كان كود المصدر قد أُودع، بل يتعلق بما إذا كانت المواد المودعة مكتملة ومحدّثة وقادرة فعليًا على دعم التعافي.