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

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

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

ويشرح ماكولوك دور الحساب الضامن للبرمجيات ‎(Software Escrow)‎ وأهمية التحقق التقني ‎(Technical Verification)‎ ضمن نطاق الخدمة المتفق عليه، مع التمييز بين حق الوصول إلى البرمجيات وقدرتها الفعلية على دعم التعافي. كما يناقش كيفية تحديد أوجه الاعتماد الأكثر تأثيرًا في أعمال المؤسسة، والأسئلة التي ينبغي أن تطرحها مجالس الإدارة قبل وقوع الاضطرابات.

وفيما يلي نص الحوار:

١. يهيمن الأمن السيبراني ‎(Cybersecurity)‎ على جانب كبير من النقاش حول المرونة التقنية، لكن الشركة ترى أن المخاطر السيبرانية ليست سوى جزء من الصورة. ما الذي لا تزال المؤسسات تغفل عنه فيما يتعلق باعتمادها على البرمجيات الحيوية التي توفرها أطراف ثالثة؟

لا شك في أن الأمن السيبراني ركيزة أساسية للمرونة، لكنه ليس المسألة الوحيدة التي ينبغي للمؤسسات الاستعداد لها.

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

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

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

٢. مع تزايد اعتماد الشركات على شبكات معقدة من مزوّدي التكنولوجيا من الأطراف الثالثة، بل والرابعة أيضًا، كيف ينبغي لكبار مسؤولي المعلومات ‎(Chief Information Officers – CIOs)‎ وقادة إدارة المخاطر تحديد أوجه الاعتماد على البرمجيات التي قد تهدد العمليات الحيوية ‎(Critical Operations)‎ فعليًا إذا تعذّر الحصول على خدمات أحد المورّدين؟

نقطة البداية ليست البرمجيات نفسها، بل العملية الحيوية التي تعتمد عليها.

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

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

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

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

٣. لدى كثير من المؤسسات بالفعل خطط لاستمرارية الأعمال ‎(Business Continuity)‎ وضمانات تعاقدية. فأين تظهر الفجوة الحقيقية بين امتلاك خطة للاستمرارية على الورق وامتلاك قدرة على التعافي ‎(Recovery Capability)‎ يمكن تفعيلها فعليًا عند وقوع الاضطرابات؟

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

لا تكون للخطة قيمة إلا إذا أمكن تفعيلها فعليًا.

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

وتكتسب هذه المسألة أهمية خاصة في الحساب الضامن للبرمجيات. إذ تحدد اتفاقية الحساب الضامن للبرمجيات حقوق الوصول إلى المواد المودعة ‎(Deposited Materials)‎ وشروط الإنهاء والتسليم. لكن وجود هذه الحقوق وحده لا يثبت قدرة المواد على دعم التعافي؛ بل ينبغي إجراء التحقق التقني من قابليتها للاستخدام وفق نطاق الاختبارات المتفق عليه.

ولهذا، فإن المبدأ واضح: ينبغي التحقق من المرونة، لا افتراضها.

وينبغي لترتيبات الاستمرارية المتينة أن توفر أدلة على أن المواد المودعة مكتملة ومحدّثة وقادرة على دعم التعافي عند الحاجة.

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

ينبغي أولًا التمييز بين الوصول إلى المواد وقابليتها للاستخدام.

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

على المستوى الأساسي، تحتاج المؤسسات إلى التأكد من أن المواد المودعة مكتملة ومحدّثة، وتشمل الملفات المنصوص عليها في الاتفاقية، وأن الوثائق التقنية شاملة وكافية.

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

كذلك، يمكن أن تكون اختبارات السيناريوهات ‎(Scenario Testing)‎ بالغة الفائدة، لأنها تنقل النقاش من التوثيق إلى التعافي العملي.

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

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

٥. يعزز النظام الجديد لإدارة المخاطر التشغيلية ‎(Operational Risk Management Regulation)‎ الصادر عن مصرف الإمارات العربية المتحدة المركزي ‎(CBUAE)‎ التركيز على المرونة التشغيلية والعمليات الحيوية والاعتماد على الأطراف الثالثة. ومن دون الإيحاء بأن النظام يفرض الحساب الضامن للبرمجيات، كيف يغيّر هذا التوجه التنظيمي الأسئلة التي ينبغي للمؤسسات المالية طرحها بشأن مورّدي البرمجيات الحيوية؟

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

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

وبالنسبة إلى المؤسسات المالية، يغيّر ذلك طبيعة النقاش بشأن مورّدي البرمجيات الحيوية.

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

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

يمكن لهذه التدابير أن تدعم الأهداف الأوسع للمرونة التشغيلية والجاهزية، لكن لا ينبغي تقديمها بوصفها ضمانًا للامتثال التنظيمي ‎(Regulatory Compliance)‎.

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

المسألة الأساسية هي أن القدرة على الوصول إلى المواد المودعة لا تعني التأكد من قابليتها للاستخدام.

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

ولهذا، يكتسب التحقق التقني أهمية كبيرة.

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

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

لذلك، ينبغي أن يكون الهدف هو الانتقال من امتلاك حماية تعاقدية إلى امتلاك قدرة على التعافي قابلة للتفعيل.

٧. تحظى السيادة الرقمية ‎(Digital Sovereignty)‎ والمرونة التنظيمية ‎(Regulatory Resilience)‎ والاعتماد على مزوّدي التكنولوجيا الخارجيين باهتمام متزايد في أنحاء الشرق الأوسط. هل أصبحت المؤسسات في المنطقة أكثر نضجًا في تقييم استمرارية البرمجيات ‎(Software Continuity)‎، أم لا تزال هناك فجوات كبيرة؟

من الواضح أن الاهتمام يتزايد في أنحاء المنطقة بالمرونة التشغيلية، والاعتماد على الأطراف الثالثة، والقدرة على إثبات أن ترتيبات الاستمرارية عملية ومحدّثة.

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

ويتمثل التحوّل المهم في الانتقال من السؤال عمّا إذا كانت ترتيبات الاستمرارية موجودة إلى السؤال عمّا إذا كانت قد خضعت للاختبار فعليًا.

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

وهنا تبرز أهمية التحقق التقني المستقل.

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

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

سأطرح ثلاثة أسئلة.

أولًا: هل وضعنا ترتيبات للاستمرارية قبل وقوع الاضطرابات؟

تحتاج المؤسسة إلى فهم أوجه الاعتماد على البرمجيات التي تدعم العمليات الحيوية، والتأكد من أن الترتيبات المناسبة قائمة بالفعل.

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

لا يكفي أن نعرف أن كود المصدر أو المواد التقنية قد أُودعت في مكان ما. فالمؤسسة تحتاج إلى أدلة على أن هذه المواد مكتملة ومحدّثة وقادرة على دعم التعافي.

ثالثًا: هل يمكن تفعيل هذه الترتيبات فعليًا إذا تعذّر استمرار المورّد في تقديم الدعم؟

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

تعكس هذه الأسئلة الثلاثة ما نراه جوهر مرونة البرمجيات ‎(Software Resilience)‎:

مرونة تُبنى منذ التصميم.
مرونة يُتحقَّق منها، لا تُفترض.
جاهزية لمواجهة الاضطرابات.

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

نسخ الرابط تم نسخ الرابط