الضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطة

إذا كنت تعمل في جهة حكومية أو في شركة تقدم خدمات تقنية لجهة حكومية في المملكة، فغالباً سمعت هذه الجملة في اجتماع أو قرأتها في عقد: «يجب الالتزام بالضوابط الأساسية للأمن السيبراني الصادرة عن الهيئة الوطنية للأمن السيبراني». ثم تفتح الوثيقة فتجد عشرات الصفحات من الأرقام مثل 2-12-3-5 والعبارات المتكررة مثل «يجب تحديد متطلبات الأمن السيبراني وتوثيقها واعتمادها»، ولا تعرف من أين تبدأ، ولا ما الذي يخصك أنت كمطور أو مدير سيرفرات، ولا ما الذي يخص الإدارة.

وقد شرحنا في مصطلحات GRC للمبتدئين معنى الحوكمة والمخاطر والامتثال والضابط والدليل والتدقيق، وهذا المقال يطبق هذه المصطلحات على وثيقة محددة هي الضوابط الأساسية للأمن السيبراني Essential Cybersecurity Controls، واختصاراً ECC، في إصدارها الحالي ECC-2:2024، والهدف أن تخرج منه وأنت تعرف كيف تقرأ الوثيقة، وما الذي يغطيه كل جزء منها بلغة بسيطة، وأين تجد التفاصيل الرسمية. ولن ننسخ نص الضوابط هنا، فالنص الرسمي متاح مجاناً على موقع الهيئة، وما نقدمه هو خريطة لقراءته، وسوف نناقش في هذا المقال ما يلي:

• ما هي ECC ومن أصدرها، وعلى من تنطبق، ولماذا يهم ذلك حتى لو كانت شركتك خاصة.
• كيف تقرأ رقم الضابط، والنمط الذي يتكرر في أغلب الوثيقة.
• المكونات الأساسية الأربعة والمكونات الفرعية الثمانية والعشرون، بلغة بسيطة ومع ما يخص الفريق التقني في كل منها.
• أين يقع أمن التطبيقات Application Security في الضوابط، وما الذي تغير في الإصدار الثاني.
• الضوابط المتخصصة التي تبنى فوق ECC: CSCC وCCC وDCC وOTCC وTCC، وما تنشره الهيئة لمساعدتك على التطبيق.
• من أين تبدأ إذا طلب منك الالتزام، وأخطاء شائعة في فهم الضوابط.

ما هي الضوابط الأساسية ECC، ومن أصدرها؟

أصدرت الهيئة الوطنية للأمن السيبراني NCA، وهي المرجع الوطني المختص بالأمن السيبراني في المملكة منذ إنشائها بالأمر الملكي رقم 6801 بتاريخ 11/02/1439هـ، الإصدار الأول من الضوابط الأساسية ECC-1:2018، ثم حدثته إلى الإصدار الثاني ECC-2:2024. والضوابط بحسب نصها تضع الحد الأدنى من متطلبات الأمن السيبراني المبنية على أفضل الممارسات والمعايير، لتقليل المخاطر على الأصول المعلوماتية والتقنية للجهات من التهديدات الداخلية والخارجية، وتركز على أهداف الحماية الثلاثة: السرية Confidentiality والسلامة Integrity والتوافر Availability، وتأخذ في الاعتبار أربعة محاور: الاستراتيجية Strategy والأشخاص People والإجراء Process والتقنية Technology.

ولاحظ كلمة «الحد الأدنى»، فهي مفتاح فهم الوثيقة كلها. الضوابط لا تقول لك أي منتج تشتري ولا أي إعداد تكتب، وإنما تقول ما يجب أن يكون موجوداً في كل جهة مهما كان حجمها ونشاطها، ثم تترك لك أن تحدد التفاصيل في سياساتك ومعاييرك بحسب المخاطر. ولهذا السبب سوف تجد أن ضابطاً مثل «استخدام بروتوكولات آمنة مثل HTTPS» لا يذكر إصدار TLS ولا الخوارزميات، فهذه التفاصيل مكانها معيارك الداخلي والمعايير الوطنية للتشفير التي يحيل إليها الضابط 2-8-3.

والنص الرسمي متاح في النسخة العربية والنسخة الإنجليزية، الأولى في 40 صفحة والثانية في 56 صفحة، والضوابط نفسها تبدأ بعد صفحات التعريف والنطاق والهيكلية وتنتهي قبل الملاحق، وفي الملحق (ج) قائمة بالتغييرات عن الإصدار الأول.

على من تنطبق الضوابط؟ نطاق العمل Scope وقابلية التطبيق Applicability

بحسب قسم نطاق العمل في الوثيقة، تنطبق الضوابط على:

• الجهات الحكومية في المملكة، وتشمل الوزارات والهيئات والمؤسسات وغيرها.
• الجهات والشركات التابعة للجهات الحكومية، داخل المملكة وخارجها.
• جهات القطاع الخاص التي تملك بنى تحتية وطنية حساسة Critical National Infrastructures أو تشغلها أو تستضيفها.

وتشجع الهيئة بقية الجهات في المملكة بشدة على الاستفادة من الضوابط. وفي قسم قابلية التطبيق تقول الوثيقة إن على كل جهة الالتزام بجميع الضوابط القابلة للتطبيق عليها، وتضرب مثالاً بضوابط المكون الفرعي 4-2 الخاص بالحوسبة السحابية والاستضافة، فهي ملزمة للجهة التي تستخدم هذه الخدمات أو تخطط لاستخدامها، أي أن «لا ينطبق Not Applicable» إجابة مقبولة لبعض الضوابط بشرط أن يكون لها سبب حقيقي موثق.

وقد يتساءل البعض: شركتي خاصة ولا تملك بنية تحتية حساسة، فهل تعنيني هذه الضوابط؟ والإجابة أنها تعنيك غالباً إذا كان عملاؤك جهات في النطاق، والسبب في المكون الفرعي 4-1 الخاص بالأطراف الخارجية Third-Party Cybersecurity، فالضابط 4-1-2 يطلب أن تشمل عقود الجهة مع الأطراف الخارجية بنوداً للمحافظة على سرية المعلومات وحذف بيانات الجهة بشكل آمن عند انتهاء الخدمة، وإجراءات التواصل عند وقوع حادثة، وإلزام الطرف الخارجي بتطبيق متطلبات الجهة وسياساتها في الأمن السيبراني. ويضيف الضابط 4-1-3 لمقدمي خدمات التعهيد Outsourcing والخدمات المدارة Managed Services تقييم المخاطر قبل توقيع العقد، وأن تكون مراكز العمليات المدارة للمراقبة والتشغيل التي تستخدم الوصول عن بعد موجودة بالكامل داخل المملكة. وبالتالي فإن الضوابط تصل إليك عبر العقد حتى لو لم تكن في نطاقها المباشر.

وكيف تقيس الهيئة الالتزام؟ بحسب قسم التنفيذ والالتزام، تقيم الهيئة التزام الجهات بطرق منها التقييم الذاتي Self-assessment من الجهات، والتقارير الدورية لأداة الالتزام، والزيارات الميدانية للتدقيق، بحسب الآلية التي تراها الهيئة مناسبة.

كيف تقرأ رقم الضابط؟ المكونات Domains والضوابط Controls

تقول مقدمة ECC-2:2024 إنها تتكون من 4 مكونات أساسية Main Domains، و28 مكوناً فرعياً Subdomains، و108 ضوابط أساسية Main Controls، و92 ضابطاً فرعياً Subcontrols. ولكل مكون فرعي هدف Objective في جملة واحدة يشرح لماذا يوجد، ثم قائمة ضوابطه، وبعض الضوابط فيها قائمة ضوابط فرعية تبدأ عادة بعبارة «بحد أدنى». ورقم أي ضابط يقرأ بالترتيب نفسه، كما تبين الصورة التالية:

ولاحظ أن الرقم داخل سطر عربي يظهر من اليمين إلى اليسار، فالضابط 2-12-3-5 في هذا المقال وفي النسخة العربية من الضوابط يقرأ من اليمين: المكون 2 ثم 12 ثم 3 ثم 5، وفي النسخة الإنجليزية قد تجده مكتوباً بالنقاط مثل 2.12.3.5، والمقصود هو الضابط نفسه. وإذا قرأت مرجعاً يتحدث عن خمسة مكونات أساسية فهو يتحدث عن الإصدار الأول، والسبب أن المكون الخامس الخاص بأنظمة التحكم الصناعي حذف من الإصدار الثاني ونقل إلى ضوابط مستقلة كما سيأتي.

النمط الذي يتكرر: اكتب، ثم طبق، ثم غط الحد الأدنى، ثم راجع

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

وهذا النمط يخبرك مباشرة بنوع الأدلة Evidence التي سوف تطلب منك لكل مكون، كما شرحنا في قسم الأدلة في مقال مصطلحات GRC: وثيقة معتمدة للضابط الأول، وإعدادات أو لقطات من الأنظمة للضابط الثاني، وما يثبت كل بند من بنود الحد الأدنى للضابط الثالث، ومحضر أو تقرير مراجعة للضابط الأخير. ولاحظ أن بعض المكونات تخرج عن هذا النمط، مثل 1-2 إدارة الأمن السيبراني و1-7 الالتزام بالتشريعات، فاقرأ كل مكون بنصه ولا تفترض.

وفي مثال البريد، يطلب الحد الأدنى في 2-4-3 تحليل الرسائل وتصفيتها خاصة رسائل التصيد Phishing والرسائل غير المرغوبة Spam، والتحقق متعدد العوامل للدخول عن بعد وعبر الويب بحسب تقييم أثر فشل التحقق، وأرشفة البريد ونسخه احتياطياً، والحماية من التهديدات المتقدمة المستمرة APT، والتحقق من نطاقات البريد بسجلات SPF وDKIM وDMARC، وقد شرحنا الأخيرة بالتفصيل في شرح SPF وDKIM وDMARC للمبتدئين.

المكونات الأربعة بلغة بسيطة

الصورة التالية تبين المكونات الأساسية الأربعة والمكونات الفرعية الثمانية والعشرين، مع عدد الضوابط الأساسية والفرعية في كل مكون أساسي كما عددناها من نص الوثيقة:

المكون الأول: حوكمة الأمن السيبراني Cybersecurity Governance

هذا المكون يجيب عن سؤال «من يقرر، وبأي وثائق، وكيف نتابع؟»، وفيه عشرة مكونات فرعية، وأغلب ما فيه عمل الإدارة وإدارة الأمن السيبراني، ولكن الفريق التقني يلمسه في مواضع واضحة:

• الاستراتيجية والإدارة (1-1 و1-2): استراتيجية للأمن السيبراني يعتمدها ويدعمها رئيس الجهة أو من ينيبه، ويسمى في الوثيقة صاحب الصلاحية Authorized Official، وإدارة للأمن السيبراني مستقلة عن إدارة تقنية المعلومات والاتصالات، ويوصى بأن ترتبط برئيس الجهة مباشرة، وتشغل وظائفها بكوادر سعودية متفرغة ومؤهلة، ولجنة إشرافية للأمن السيبراني.
• السياسات والإجراءات والأدوار (1-3 و1-4): سياسات وإجراءات معتمدة ومنشورة، تدعمها معايير تقنية أمنية مثل معايير جدار الحماية وقواعد البيانات وأنظمة التشغيل، وأدوار ومسؤوليات محددة، وكلها تراجع دورياً. وإذا كان الفرق بين السياسة والمعيار غير واضح لك فقد شرحناه في مقال مصطلحات GRC.
• إدارة المخاطر (1-5): منهجية معتمدة لإدارة المخاطر، وتقييم للمخاطر بحد أدنى في بداية المشاريع التقنية، وقبل التغييرات الجوهرية في البنية التقنية، وعند التخطيط لخدمات طرف خارجي، وقبل إطلاق خدمات ومنتجات جديدة. وبالنسبة للمطور فإن نمذجة التهديدات Threat Modeling في بداية المشروع هي الطريقة العملية لتقييم مخاطر تصميم تطبيق واحد.
• الأمن في المشاريع التقنية (1-6): متطلبات الأمن جزء من منهجية إدارة المشاريع وإدارة التغيير، ومنها تقييم الثغرات ومعالجتها، ومراجعة الإعدادات والتحصين Hardening وحزم التحديثات قبل إطلاق المشاريع والتغييرات، وضابط خاص بتطوير البرمجيات سوف نعود إليه بعد قليل.
• الالتزام والمراجعة والتدقيق (1-7 و1-8): الالتزام بالاتفاقيات الدولية المعتمدة وطنياً التي فيها متطلبات أمن سيبراني، ومراجعة دورية من إدارة الأمن السيبراني، وتدقيق مستقل من طرف آخر غير إدارة الأمن السيبراني وفق معايير التدقيق المتعارف عليها، ورفع النتائج إلى اللجنة الإشرافية وصاحب الصلاحية مع الإجراءات التصحيحية.
• الموارد البشرية والتوعية (1-9 و1-10): بنود السرية في عقود العاملين، والتحقق من خلفية من يشغل وظائف الأمن والوظائف ذات الصلاحيات الحساسة، وإلغاء الصلاحيات فور انتهاء العلاقة الوظيفية، وبرنامج توعية يشمل التعامل مع رسائل التصيد والأجهزة المحمولة ووسائط التخزين والتصفح ووسائل التواصل، وتدريب متخصص لفريق الأمن ولمن يعمل على تطوير البرمجيات والأصول التقنية وللقيادات.

المكون الثاني: تعزيز الأمن السيبراني Cybersecurity Defense

هذا أكبر المكونات وأقربها إلى عملك اليومي، ففيه خمسة عشر مكوناً فرعياً و61 ضابطاً، وكل مكون فيه تقريباً يقابل مجالاً تقنياً تعرفه:

• إدارة الأصول Asset Management (2-1): قائمة محدثة بالأصول المعلوماتية والتقنية، وسياسة للاستخدام المقبول Acceptable Use، وتصنيف الأصول وترميزها والتعامل معها بحسب التصنيف. ولاحظ أنك لا تستطيع أن تحمي ما لا تعرف أنه موجود، ولذلك يبدأ المكون بالجرد.
• إدارة هويات الدخول والصلاحيات IAM (2-2): تحقق بكلمة مرور كحد أدنى، وتحقق متعدد العوامل MFA للدخول عن بعد وللحسابات ذات الصلاحيات الهامة يحدد عدده ونوعه بناء على تقييم أثر فشل التحقق أو تجاوزه، وصلاحيات مبنية على مبادئ الحاجة إلى المعرفة والاستخدام Need-to-Know and Need-to-Use وأقل الصلاحيات Least Privilege وفصل المهام Segregation of Duties، وإدارة الصلاحيات الهامة والحساسة PAM، ومراجعة دورية للهويات والصلاحيات. وقد شرحنا هذا كله عملياً في إدارة الهوية والوصول IAM والوصول المميز PAM.
• حماية الأنظمة وأجهزة المعالجة (2-3): الحماية من الفيروسات والبرمجيات الضارة على الأجهزة والسيرفرات، والتقييد الصارم لوسائط التخزين الخارجية، وإدارة التحديثات Patch Management، ومزامنة التوقيت مركزياً مع مصدر دقيق وموثوق مثل مصادر الهيئة السعودية للمواصفات والمقاييس والجودة. والتوقيت ليس تفصيلاً صغيراً، فسجلات الأحداث بتوقيت خاطئ دليل ضعيف في أي تحقيق.
• حماية البريد الإلكتروني (2-4): شرحناها في القسم السابق.
• إدارة أمن الشبكات (2-5): عزل الشبكات وتقسيمها Segmentation بجدار الحماية ومبدأ الدفاع في العمق، وعزل شبكة الإنتاج Production عن شبكات التطوير والاختبار، وتقييد التصفح، وتأمين الشبكات اللاسلكية، وتقييد المنافذ والبروتوكولات والخدمات، وأنظمة منع الاختراق IPS، وأمن خدمة أسماء النطاقات DNS، والحماية من هجمات حجب الخدمة الموزعة DDoS، وهذه الأخيرة أضيفت في الإصدار الثاني.
• أمن الأجهزة المحمولة (2-6): فصل بيانات الجهة على الأجهزة المحمولة والأجهزة الشخصية BYOD وتشفيرها، وحذفها عند فقد الجهاز أو انتهاء العلاقة الوظيفية، كما شرحنا في الأجهزة الشخصية في العمل BYOD.
• حماية البيانات والتشفير (2-7 و2-8): حماية البيانات بحسب مستوى تصنيفها، والتشفير بحد أدنى وفق المعايير الوطنية للتشفير التي تنشرها الهيئة، وإدارة المفاتيح خلال دورة حياتها، وتشفير البيانات أثناء النقل والتخزين بحسب تصنيفها. وللأساسيات التقنية راجع التشفير للمطورين.
• النسخ الاحتياطية والاستعادة (2-9): نطاق يغطي الأصول الحساسة، والقدرة على الاستعادة السريعة بعد الحوادث، والفحص الدوري لفعالية الاستعادة. ولاحظ أن الضابط يطلب فحص الاستعادة وليس وجود النسخة فقط، والسبب أن النسخة التي لم تجرب استعادتها لا تعرف هل تعمل.
• إدارة الثغرات واختبار الاختراق (2-10 و2-11): فحص دوري للثغرات وتصنيفها بحسب خطورتها ومعالجتها بحسب المخاطر، واختبار التحديثات في بيئة غير بيئة الإنتاج قبل تطبيقها، والاشتراك في مصادر موثوقة للتنبيهات، واختبار اختراق دوري يشمل كل الخدمات المقدمة عبر الإنترنت ومكوناتها: البنية التحتية والمواقع وتطبيقات الويب وتطبيقات الهواتف والبريد والدخول عن بعد.
• سجلات الأحداث والمراقبة (2-12): تفعيل السجلات للأصول الحساسة وللحسابات ذات الصلاحيات الهامة ولأحداث الدخول عن بعد، وتحديد تقنيات إدارة السجلات والأحداث الأمنية SIEM، والمراقبة المستمرة، والاحتفاظ بالسجلات مدة لا تقل عن 12 شهراً. وقد شرحنا كيف تبني السجلات في السجلات Logging للمطورين ومديري السيرفرات، وكيف تصمم سجلاً للأحداث الحساسة لا يقبل العبث في سجل التدقيق Audit Trail، وفيه قسم عن 2-12-3 تحديداً.
• الحوادث والتهديدات (2-13): خطط للاستجابة للحوادث وإجراءات للتصعيد، وتصنيف الحوادث، والتبليغ عنها للهيئة، ومشاركة التنبيهات ومعلومات التهديدات معها، وجمع معلومات التهديدات Threat Intelligence.
• الأمن المادي (2-14): الدخول المصرح به إلى المواقع الحساسة مثل مراكز البيانات، وسجلات الدخول والمراقبة بالكاميرات CCTV وحمايتها، والإتلاف الآمن للأصول التي تحمل معلومات مصنفة وإعادة استخدامها.
• حماية تطبيقات الويب (2-15): سوف نعود إليها في قسم أمن التطبيقات.

المكون الثالث: صمود الأمن السيبراني Cybersecurity Resilience

مكون فرعي واحد هو 3-1، ويطلب أن تكون متطلبات الأمن السيبراني جزءاً من إدارة استمرارية الأعمال Business Continuity Management، وبحد أدنى ضمان استمرار أنظمة الأمن السيبراني وإجراءاته، وخطط للاستجابة للحوادث التي قد تؤثر على استمرارية الأعمال، وخطط للتعافي من الكوارث Disaster Recovery. والفكرة هنا أن جدار الحماية ونظام المراقبة نفسيهما يجب أن يعملا في موقع التعافي، وإلا فإنك تعود إلى العمل بعد الكارثة بلا حماية.

المكون الرابع: الأطراف الخارجية والحوسبة السحابية Third-Party and Cloud Computing

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

أين يقع أمن التطبيقات Application Security في الضوابط؟

هذا السؤال يسأله كل مطور يقرأ الضوابط لأول مرة، والإجابة المختصرة أن هناك موضعين مخصصين للتطبيقات، ومواضع أخرى تلمسها:

• الضابط 1-6-3: يطلب أن تشمل متطلبات الأمن السيبراني لمشاريع تطوير التطبيقات والبرمجيات بحد أدنى استخدام معايير التطوير الآمن Secure Coding Standards، واستخدام مصادر مرخصة وموثوقة لأدوات التطوير والمكتبات، واختبار التزام التطبيقات بمتطلبات الأمن السيبراني للجهة، والتكامل الآمن بين التطبيقات، ومراجعة الإعدادات والتحصين وحزم التحديثات قبل إطلاق التطبيقات.
• المكون الفرعي 2-15: يخص تطبيقات الويب الخارجية للجهة، ويطلب بحد أدنى جدار حماية لتطبيقات الويب Web Application Firewall، ومبدأ المعمارية متعددة المستويات Multi-tier Architecture، وبروتوكولات آمنة مثل HTTPS، وتوضيح سياسة الاستخدام الآمن للمستخدمين، وتحديد عناصر التحقق من هوية المستخدمين وعددها وتقنياتها بناء على تقييم أثر فشل التحقق وتجاوزه.
• مواضع أخرى: الصلاحيات في 2-2، والتشفير في 2-8، والثغرات في 2-10، واختبار الاختراق في 2-11 الذي يشمل تطبيقات الويب والهواتف، والسجلات في 2-12، وتدريب العاملين على تطوير البرمجيات في 1-10-4.

ولاحظ أن هذه البنود تقول ماذا تريد ولا تقول كيف، فعبارة «استخدام معايير التطوير الآمن» لا تحدد أي معيار، وعبارة «اختبار الالتزام بالمتطلبات» لا تحدد ما هي المتطلبات. ولهذا كتب صاحب الموقع دليلاً مقترحاً لضوابط أمن التطبيقات، وهو مقترح مستقل من المجتمع وليس وثيقة رسمية، يقرأ في قسمه عن ECC نص البندين 1-6-3 و2-15 بالتفصيل، ويذكر في قسم CSCC ما تضيفه ضوابط الأنظمة الحساسة مثل مراجعة الكود المصدري قبل الإطلاق وحماية واجهات API، ويعدد في قسم حزمة الأدوات القوالب الرسمية التي تخص التطوير، مثل قالب سياسة دورة حياة التطوير الآمن SSDLC وقالب معيار البرمجة الآمنة وقالب معيار حماية تطبيقات الويب.

وأما التفاصيل التقنية التي تملأ هذه البنود فقد شرحناها في مقالات منفصلة: ما هي OWASP لمعرفة المراجع المتاحة، ومتطلبات الأمان ومراجعة الكود مع OWASP ASVS لكتابة متطلبات يمكن اختبارها، وفيه قسم عن علاقة ASVS بضوابط ECC، ونمذجة التهديدات لتقييم المخاطر في بداية المشروع.

ما الذي تغير في ECC-2:2024 عن الإصدار الأول؟

في الملحق (ج) من الوثيقة جدول بكل التغييرات عن ECC-1:2018، مع سبب كل تغيير، ومن أهمها لمن يعمل في التقنية:

• حذف المكون الأساسي الخامس الخاص بالأمن السيبراني لأنظمة التحكم الصناعي، ونقل ضوابطه إلى ضوابط الأمن السيبراني للأنظمة التشغيلية OTCC.
• التحقق متعدد العوامل في 2-2-3-2 أصبح للدخول عن بعد وللحسابات ذات الصلاحيات الهامة، مع تحديد عدد العناصر ونوعها بناء على تقييم أثر فشل التحقق وتجاوزه، وبالطريقة نفسها تغير 2-4-3-2 للبريد و2-15-3-5 لتطبيقات الويب الذي كان ينص على التحقق متعدد العناصر لدخول المستخدمين.
• التحقق من نطاقات البريد في 2-4-3-5 أصبح يذكر SPF وDKIM وDMARC معاً، بعد أن كان يذكر SPF مثالاً.
• إضافة الضابط الفرعي 2-5-3-9 للحماية من هجمات حجب الخدمة الموزعة DDoS.
• حذف بنود خصوصية البيانات من 2-7 والبند الخاص باستضافة معلومات الجهة وتخزينها داخل المملكة من 4-2، وتقول الوثيقة إنها نقلت إلى اختصاص مكتب إدارة البيانات الوطنية NDMO في الهيئة السعودية للبيانات والذكاء الاصطناعي سدايا، وإن على الجهات الرجوع إليه في هذه المسائل.
• الضابط 1-2-2 أصبح يطلب أن تشغل كل وظائف الأمن السيبراني بكوادر سعودية متفرغة ومؤهلة، بعد أن كان النص عن رئيس الإدارة والوظائف الإشرافية والحساسة فيها.

الضوابط المتخصصة التي تبنى فوق ECC

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

ولاحظ أن ضوابط الأنظمة الحساسة CSCC صدرت قبل الإصدار الثاني من ECC وتشير إلى أرقام الإصدار الأول، فإذا قرأتها بجانب ECC-2:2024 فتأكد من أن رقم الضابط المشار إليه لم يتغير، وقد ذكر الدليل المقترح لضوابط أمن التطبيقات أن الأرقام التي تخص التطبيقات مثل 1-6-3 و2-15 لم يتغير ترقيمها.

وقد شرحنا كل مجموعة من هذه المجموعات بنطاقها وأمثلة من ضوابطها، ومعها ضوابط القطاع الخاص الجديدة NCNICC-1:2025، في مقال ضوابط الهيئة الوطنية للأمن السيبراني: أيها ينطبق عليك؟.

ما الذي تنشره الهيئة لمساعدتك على التطبيق؟

قد يتساءل البعض: إذا كانت الضوابط تقول ماذا ولا تقول كيف، فمن أين أعرف كيف؟ والإجابة أن الهيئة تنشر بجانب الضوابط وثائق مساعدة، وأهمها ثلاثة:

• الدليل الإرشادي لتطبيق الضوابط الأساسية GECC: النسخة الإنجليزية المنشورة الآن على صفحة الضوابط في موقع الهيئة هي GECC-2:2026 المبنية على ECC-2:2024، وفيها لكل بند إرشادات تطبيق Control Implementation Guidelines ومخرجات متوقعة Expected Deliverables، مثل وثيقة معتمدة ولقطة من لوحة تحكم النظام تبين أن السجلات مفعلة. ويقول الدليل في أوله إنه نموذج توضيحي وليس الطريقة الوحيدة للتطبيق، وإن المقيم أو المدقق له الحق في طلب أدلة أخرى.
• حزمة أدوات الأمن السيبراني Cybersecurity Toolkits: قوالب جاهزة لسياسات ومعايير وقوائم تحقق تملؤها الجهة، وقد عدد الدليل المقترح في قسم حزمة الأدوات ما يخص التطوير منها. والقالب نقطة بداية جيدة، بشرط أن تعدله ليطابق ما تفعله جهتك فعلاً، لأن المدقق يقارن النص بالواقع.
• أدوات التقييم وقياس الالتزام Assessment and Compliance Tools: تنص ECC-2:2024 على أن الهيئة سوف تصدر أداة لتنظيم تقييم التزام الجهات بها وقياسه، وصفحات الضوابط المتخصصة مثل DCC وOTCC وTCC تنشر أدوات تقييم خاصة بها.

من أين تبدأ إذا طلب منك الالتزام؟

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

وأهم خطوة فيها هي تقييم الفجوات Gap Assessment، وهو جدول بسيط فيه صف لكل ضابط وضابط فرعي، وأعمدة للحالة والدليل والمالك والإجراء المطلوب. والجدول التالي مثال توضيحي لخمسة صفوف من جهة متخيلة:

في الجدول أعلاه لاحظ التالي:

• عمود الدليل هو أهم عمود، فالحالة «مطبق» بدون دليل تساوي «غير مطبق» في نظر المدقق، كما شرحنا في مقال مصطلحات GRC.
• الصف الأخير يخص مكوناً كاملاً، والأفضل أن تقيم كل ضابط فيه على حدة، وجمعناه هنا لاختصار المثال.
• الإجراء يحتاج إلى مالك وتاريخ، ثم ترتب الصفوف بحسب المخاطر وليس بحسب ترتيب الأرقام في الوثيقة.

وكيف تحقق هذه الضوابط بأدوات مفتوحة المصدر تستضيفها بنفسك؟ هذا موضوع مقال مخطط بعنوان «تحقيق ضوابط ECC بأدوات مفتوحة المصدر: خريطة الضابط والأداة» في مرحلة الحوكمة والمخاطر والامتثال GRC.

أخطاء شائعة في فهم الضوابط

• الاعتماد على أرقام الإصدار الأول: كثير من العروض والمقالات القديمة تتحدث عن خمسة مكونات أساسية وعن متطلبات تغيرت، فتأكد دائماً أنك تقرأ ECC-2:2024 من موقع الهيئة.
• اعتبارها مهمة قسم تقنية المعلومات وحده: المكون الأول كله حوكمة، والضوابط نفسها تطلب أن تكون إدارة الأمن السيبراني مستقلة عن تقنية المعلومات، والموارد البشرية والمشتريات والإدارة العليا لها ضوابط واضحة.
• شراء أداة وانتظار الالتزام: الأداة تساعدك على تطبيق ضابط أو جمع دليل، ولكن الضابط الأول في أغلب المكونات وثيقة معتمدة، والأخير مراجعة دورية، ولا تقوم بهما أداة بدلاً منك.
• القول إن شركتنا خاصة فلا تعنينا: إذا كان عملاؤك جهات حكومية أو جهات بنى تحتية حساسة فالضوابط تصل إليك عبر العقود في المكون 4-1.
• نسخ القوالب دون تعديل: قالب سياسة يقول إنكم تفعلون شيئاً لا تفعلونه يتحول إلى ملاحظة في أول تدقيق.
• تفسير «الحد الأدنى» كأنه سقف: الضوابط هي الحد الأدنى، وتقييم المخاطر قد يطلب منك أكثر منها في نظام حساس.
• نسخ نص الضابط إلى السياسة كما هو: عبارة «استخدام بروتوكولات آمنة» في سياستك لا تفيد أحداً، والمعيار الداخلي يجب أن يحدد القيم، مثل إصدار TLS المسموح، ويحيل إلى المعايير الوطنية للتشفير.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• ECC-2:2024 هي الحد الأدنى من ضوابط الأمن السيبراني للجهات الحكومية والجهات التابعة لها وجهات البنى التحتية الوطنية الحساسة، وتصل إلى الموردين عبر العقود في المكون 4-1.
• تتكون من 4 مكونات أساسية و28 مكوناً فرعياً و108 ضوابط أساسية و92 ضابطاً فرعياً، والرقم يقرأ: المكون ثم المكون الفرعي ثم الضابط ثم الضابط الفرعي.
• أغلب المكونات تتبع نمطاً واحداً: حدد المتطلبات ووثقها واعتمدها، ثم طبقها، ثم غط الحد الأدنى، ثم راجعها دورياً، وكل خطوة لها نوع من الأدلة.
• أمن التطبيقات في الضابط 1-6-3 والمكون 2-15 أساساً، والتفاصيل تأتي من معاييرك ومن OWASP، ومن الدليل المقترح لضوابط أمن التطبيقات.
• الإصدار الثاني نقل أنظمة التحكم الصناعي إلى OTCC، وربط MFA بتقييم الأثر، وأضاف DDoS، ونقل الخصوصية وتوطين البيانات إلى مكتب إدارة البيانات الوطنية.
• CSCC وCCC وDCC وOTCC وTCC امتداد للضوابط الأساسية، والدليل الإرشادي وحزمة الأدوات يساعدانك على التطبيق.
• ابدأ بتقييم الفجوات بعمود للأدلة، ورتب العمل بالمخاطر، واكتب الوثائق لما تطبقه فعلاً.

دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.دليلضوابط أمن التطبيقات: دليل مقترح بنطاقات وضوابط مرقمة، مربوط بضوابط NCA وOWASP ASVSمقترح مستقل من عرب رووت بتسعين ضابطاً مرقماً لأمن تطبيقات الويب وواجهات API وخط CI/CD، لكل ضابط متطلب ودليل للمدقق، مربوط بالبنود التي يدعمها في ECC-2:2024 وCSCC وبأرقام OWASP ASVS 5.0، مع ملف Excel للتقييم الذاتي.دليلإدارة الهوية والوصول IAM والوصول المميز PAMمن يملك صلاحية root على سيرفراتك ومنذ متى، وكيف تضبط حسابات المديرين بصلاحيات مؤقتة وجلسات مسجلة.دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.دليلOWASP ASVS ومراجعة الكود الأمنية لكل Pull Requestكيف تكتب متطلبات أمان يمكن اختبارها مع OWASP ASVS، وتراجع كل طلب دمج أمنياً في عشرين دقيقة بقائمة جاهزة.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.

وفي مقالات قادمة بإذن الله ضمن مرحلة الحوكمة والمخاطر والامتثال GRC سوف نتحدث عن المقارنة بين NCA ECC وISO 27001 وNIST CSF وSOC 2، وعن تحقيق ضوابط ECC بأدوات مفتوحة المصدر، وعن إدارة الامتثال والمخاطر بأدوات تستضيفها بنفسك، وعن الاستعداد للتدقيق.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من النسختين العربية والإنجليزية من ECC-2:2024 والدليل الإرشادي GECC-2:2026 وصفحات الضوابط المتخصصة على موقع الهيئة الوطنية للأمن السيبراني، مع عد الضوابط في كل مكون من النص الإنجليزي.
• أكتوبر 2026: إضافة رابط في قسم الضوابط المتخصصة إلى مقال يشرح كل مجموعة وضوابط القطاع الخاص NCNICC-1:2025.