الأمن السيبراني للمنصات السعودية: متطلبات NCA ECC وإطار SAMA
ملخص سريع
الضوابط الأساسية للأمن السيبراني (NCA ECC) الصادرة عن الهيئة الوطنية للأمن السيبراني تضع الحد الأدنى من المتطلبات لكل جهة حكومية وجهة ذات علاقة بالبنية التحتية الوطنية الحرجة.
إطار الأمن السيبراني من SAMA (CSF) إلزامي لكل البنوك ومؤسسات التأمين ومقدمي خدمات الدفع في المملكة — يتضمن مراجعات سنوية واختبارات اختراق دورية.
Secure SDLC قابل للدفاع عنه يتطلب النمذجة التهديدية عند البدء، SAST وSCA في خط الأنابيب، إرشادات برمجة آمنة موثقة، واختبار اختراق خارجي قبل الإطلاق. هذه العناصر تنتمي إلى العقد، لا إلى إعلان نوايا.
الأمن السيبراني كان موضوعاً مستمراً في الشركات السعودية لسنوات. إنشاء الهيئة الوطنية للأمن السيبراني (NCA) في 2017 وإصدار الضوابط الأساسية في 2018، ومراجعتها في 2023، شدَّد التوقعات بشكل جوهري. لشراء مزودي البرمجيات الخارجيين، هذا يعني أن ما كان كافياً قبل خمس سنوات — «نحن نهتم بالأمن» — لم يعد إجابة تعاقدية.
هذا المقال يرتب المعايير ذات الصلة ويسمي المخرجات الملموسة التي يستحق تحديدها.
إطار NCA ECC
ضوابط NCA ECC تنظم خمسة محاور رئيسية:
الحوكمة: سياسة أمن سيبراني، مسؤول أمن معتمد، ميزانية مخصصة.
الدفاع السيبراني: حماية الشبكة، حماية الأجهزة، إدارة الوصول، التشفير، التشغيل الآمن.
المرونة السيبرانية: إدارة الحوادث، استمرارية العمل، التعافي من الكوارث.
الأمن السيبراني للأطراف الثالثة والحوسبة السحابية: تقييم المزودين، إدارة المخاطر، مراقبة الأداء.
الصناعة والتحكم (ICS): للمنشآت الصناعية الحرجة.
الأجهزة الحكومية والجهات ذات العلاقة بالبنية التحتية الوطنية الحرجة (الطاقة، المياه، الاتصالات، النقل) ملزمة بالتوافق الكامل. للمزودين الخاصين، الامتثال طوعي لكنه يصبح ملزماً حين يُورَّد إلى تلك الجهات.
إطار SAMA للأمن السيبراني
إطار SAMA CSF (Cyber Security Framework) إلزامي لكل البنوك السعودية، شركات التأمين، مقدمي خدمات الدفع، وشركات الوساطة المالية. الإطار يشمل:
التقييم الذاتي السنوي مع تقرير إلى البنك المركزي.
اختبار اختراق خارجي كل سنة على الأقل من طرف معتمد.
مراجعة مستقلة كل ثلاث سنوات.
إبلاغ عن الحوادث خلال أربع وعشرين ساعة.
تخطيط استمرارية الأعمال مع اختبار سنوي.
لمزودي البرمجيات العاملين مع البنوك، هذه المتطلبات تُمرَّر في العقود. الجهة المانحة للتعاقد مسؤولة عن إثبات أن المزود يلبي الاشتراطات — وهذا يعني توثيقاً صارماً وحقوق تدقيق مفصلة.
عملية تطوير قابلة للدفاع عنها تحتوي على الأقل على العناصر التالية:
النمذجة التهديدية عند بدء المشروع. تحليل منظم لمسارات الهجوم المحتملة على التطبيق المراد تطويره. STRIDE أو PASTA طرق شائعة. المخرجات قائمة متطلبات أمنية مرتبة الأولوية تدخل إلى backlog.
إرشادات الترميز الآمن. قواعد ملزمة للتطوير — خاصة باللغة والإطار. لتطبيقات الويب: التحقق من المدخلات، إدارة الجلسات الآمنة، الاستخدام الصحيح للتشفير، الحماية من OWASP Top Ten.
اختبار تحليل الشيفرة الثابتة (SAST) في خط الأنابيب. تحليل تلقائي للشيفرة المصدرية في كل commit. أدوات مثل Semgrep، SonarQube، أو linters متخصصة تتعرف على أنماط معروفة للبرمجة غير الآمنة.
اختبار تحليل التطبيق الديناميكي (DAST). اختبارات وقت التشغيل ضد بيئة اختبار. أدوات مثل OWASP ZAP أو Burp Suite تفحص التطبيق المشغل بحثاً عن ثغرات.
تحليل مكونات البرمجيات (SCA). تحليل مكتبات مفتوحة المصدر المضمنة بحثاً عن ثغرات معروفة. Dependabot، Snyk، أو Trivy تغطي الطلب القياسي.
اختبار اختراق قبل الإطلاق. مفحص مستقل (خارجي، ليس المطور) يختبر التطبيق ضد أنماط الهجوم الحالية. للتطبيقات الحرجة، يتكرر سنوياً.
لا يوجد عنصر من هذه مكلف في الإعداد الفردي. جميعها معاً هي الفرق بين «نهتم بالأمن» وهيكل أمني قابل للدفاع عنه.
بنود تعاقدية تعمل
البنود الأمنية العامة بلا قيمة. البنود المحددة تكلف قليلاً في التفاوض وكثيراً في حالة الضرر — في النسبة العكسية.
أمثلة على صيغ مؤثرة:
«ينفذ المتعاقد اختبارات SAST وSCA في خط CI/CD ويوثق الثغرات الحرجة قبل الانطلاق الإنتاجي.»
«يضمن المتعاقد تنفيذ اختبار اختراق خارجي من قبل مفحص مستقل قبل الإطلاق. تقرير الاختبار يُسلَّم للعميل.»
«عند معرفة ثغرة أمنية في مكون مستخدم، يُعلَم العميل خلال أربع وعشرين ساعة.»
هذه البنود قابلة للفرض. «المتعاقد يضمن أمناً مناسباً» العامة ليست كذلك في حالة النزاع.
اختبار الاختراق: النطاق والحدود
اختبار الاختراق ليس دليلاً شاملاً على الأمان. يختبر خصوصاً ضد مسار هجوم محدد في نافذة زمنية محددة. نطاق نموذجي لتطبيق ويب:
اختبار صندوق أسود (المفحص يعرف فقط الـURL): يحدد سطح الهجوم المرئي من الخارج.
اختبار صندوق رمادي (المفحص لديه حساب مستخدم): سيناريو أكثر واقعية لتطبيقات B2B.
اختبار صندوق أبيض (المفحص لديه وصول للشيفرة): أعمق، يكشف أكثر، أغلى.
لمعظم تطبيقات ويب B2B، اختبار صندوق رمادي على خمسة إلى عشرة أيام عمل هو المدخل الأكثر اقتصاداً. التقرير يحتوي على الثغرات المكتشفة مع تصنيف الحرجية (غالباً بـ CVSS) وتوصيات العلاج.
مهم: اختبار الاختراق يجد الثغرات، لا يصلحها. الإصلاح جزء من ميزانية التطوير — احسبوا عشرة إلى عشرين بالمئة جهد إضافي للعلاج بعد أول اختبار اختراق إنتاجي.
كيف توظف D'Cloud الأمن عملياً
إجراءاتنا القياسية: SAST وSCA في كل خط أنابيب. نمذجة تهديدات عند بدء المشروع كإلزام. إرشادات ترميز آمن مبنية على OWASP ASVS Level 2 للتطبيقات العادية، Level 3 للتطبيقات الحرجة أمنياً. اختبار اختراق خارجي قبل كل إصدار رئيسي — عبر شريك معتمد من CREST أو OSCP.
تعاقدياً: بنود أمنية محددة كملحق لعقد العمل، نافذة استجابة للحوادث أربع وعشرون ساعة، إلزام توثيق للهندسة المعمارية والقرارات التصميمية الحرجة. الاستخدامات الأمنية جزء من خدمات الأمن السيبراني وتعمل بتكامل وثيق مع DevOps والبنية التحتية السحابية.
الخطوة التالية
إذا كانت مؤسستكم خاضعة لـ NCA ECC أو إطار SAMA، أو تستعد لشهادة، المراجعة المنظمة لعقودكم الحالية تختصر الوقت. أي مزودين يمتلكون أي بنود أمنية موثقة؟ احجزوا جلسة نطاق مجانية — نفحص الحالة الراهنة قبل أن يسأل المنظم. الاطلاع المتوازي على دليل PDPL لمطوري البرمجيات يغطي طبقة حماية البيانات.
الأسئلة الشائعة
هل يجب أن يكون مطورونا معتمدين فردياً بـ ISO 27001؟
ليس إلزامياً. المنظمات المقاولة المعتمدة تقلل بشكل جوهري جهد الامتثال لديكم. إذا كنتم تحملون ISO 27001 أو TISAX، المزودون الحرجون يجب أن يحملوا شهادة مكافئة أو يثبتوا ISMS مكافئاً.
هل NCA ECC إلزامي للشركات الصغيرة؟
مباشرة في حالات خاصة (مشغلو البنية التحتية الحرجة في النطاق بغض النظر عن الحجم). غير مباشرة غالباً نعم — كمورد لعميل ملزم بـ NCA ECC، قد يُطلب منكم إثبات الامتثال عبر سلسلة التوريد.
كم مرة يجب تكرار اختبار الاختراق؟
للتطبيقات الحرجة، سنوياً أو بعد تغييرات جوهرية. للتطبيقات الأقل حرجية، كل سنتين. بعد تغيير هندسي كبير، دائماً — حتى لو كان الاختبار السابق قريباً.
ما تكلفة اختبار اختراق خارجي لتطبيق ويب متوسط؟
التسعير السوقي يتباين حسب النطاق ومؤهلات المفحص. عروض ملموسة تأتي بعد تنسيق النطاق (المكونات المتأثرة، عمق الاختبار، أيام الاختبار). دون خمسة أيام عمل اختبار، العمق غير كافٍ للتطبيقات الحرجة عادة.
هل يمكننا تشغيل SAST وSCA داخلياً؟
نعم، ويجب. أدوات مثل Dependabot (مجاناً في GitHub)، Trivy، أو SonarCloud تغطي الحد الأدنى. الاستثمار الأهم أقل في الأداة وأكثر في عملية فرز الاكتشافات وعلاجها بسرعة.