مصطلحات GRC للمبتدئين بمثال من شركة صغيرة

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

وهذه الكلمات هي لغة مجال اسمه الحوكمة والمخاطر والامتثال Governance, Risk and Compliance، واختصاراً GRC، وهو المجال الذي يحول العمل التقني الجيد إلى شيء يمكن أن يقرره شخص مسؤول، ويرتب حسب الأهم، ويثبت لطرف آخر. وهذا المقال هو أول مقال في مرحلة الحوكمة والمخاطر والامتثال GRC في خريطة التعلم، وهدفه أن تفهم المصطلحات قبل أن تقرأ أي إطار، لأن كل الأطر، من الضوابط الأساسية للأمن السيبراني NCA ECC إلى ISO 27001، تستخدم هذه الكلمات نفسها، وسوف نناقش في هذا المقال ما يلي:

• ما معنى GRC، وكيف تعمل الكلمات الثلاث معاً في دورة واحدة.
• الحوكمة Governance: من يقرر، ومن يحاسب، ولماذا لا يكفي أن يكون الفريق التقني ممتازاً.
• المخاطر Risk: الاحتمال Likelihood والأثر Impact، والمخاطرة الأصلية Inherent والمتبقية Residual، وشهية المخاطر Risk Appetite، وسجل المخاطر Risk Register.
• الامتثال Compliance: الفرق بين النظام Law والإطار Framework والعقد Contract.
• الضوابط Controls وأنواعها: وقائي وكشفي وتصحيحي، وإداري وتقني ومادي، والضابط البديل Compensating Control.
• الفرق بين السياسة Policy والمعيار Standard والإجراء Procedure والإرشاد Guideline.
• الأدلة Evidence: ما الذي يقبله المدقق وما الذي لا يقبله، والتدقيق Audit الداخلي والخارجي.
• الأطر Frameworks الأشهر: NCA ECC وISO/IEC 27001 وNIST CSF 2.0 وSOC 2، باختصار.
• مثال كامل من مخاطرة واحدة إلى دليل في ملف المدقق، ثم أخطاء شائعة وجدول مختصر بالمصطلحات.

ما معنى GRC؟ ثلاث كلمات تعمل في دورة واحدة

الحوكمة Governance تجيب عن سؤال «من يقرر، ومن يحاسب؟»، وإدارة المخاطر Risk Management تجيب عن سؤال «ما الذي قد يضرنا، وبأي ترتيب نعالجه؟»، والامتثال Compliance يجيب عن سؤال «هل نلتزم بما يطلبه منا غيرنا، وكيف نثبت ذلك؟». والخطأ الشائع أن يتعامل الفريق مع الثلاث كأنها ثلاثة ملفات منفصلة، فيكتب سياسة لأن العميل طلبها، ويملأ جدول مخاطر مرة في السنة لأن المدقق سوف يسأل عنه، ثم لا يربط أحد بين الاثنين وبين ما يحدث فعلاً على السيرفرات، والصحيح أنها دورة واحدة: الإدارة تعين المسؤول وتحدد ما تقبله من المخاطر، ثم تقيم المخاطر لتعرف أين تبدأ، ثم تختار ضوابط Controls تقلل هذه المخاطر وتغطي المتطلبات الخارجية، ثم تجمع أدلة Evidence على أن الضوابط تعمل، ثم يراجعها شخص مستقل في التدقيق Audit، وتعود النتائج إلى الإدارة لتقرر من جديد.

والصورة التالية تبين هذه الدورة بالخطوات الخمس، مع مثال الشركة الصغيرة في كل خطوة:

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

الحوكمة Governance: من يقرر، ومن يحاسب؟

الحوكمة هي الطريقة التي تحدد بها المؤسسة من يملك القرار في الأمن السيبراني، وما هي أهدافه، وما الذي تقبله وما الذي ترفضه، وكيف تتابع التنفيذ. ويصفها إطار NIST للأمن السيبراني CSF 2.0 في وظيفة Govern بأنها وضع استراتيجية إدارة المخاطر السيبرانية وتوقعاتها وسياستها، ونشرها ومراقبتها، وتشمل فهم سياق المؤسسة، والأدوار والمسؤوليات والصلاحيات، والسياسة، والإشراف على تنفيذ الاستراتيجية.

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

وتجد عناصر الحوكمة بوضوح في الضوابط الأساسية للأمن السيبراني ECC-2:2024، فالمكون الفرعي 1-2 يطلب إنشاء إدارة للأمن السيبراني مستقلة عن إدارة تقنية المعلومات (الضابط 1-2-1)، ولجنة إشرافية يكون رئيس إدارة الأمن السيبراني عضواً فيها (1-2-3)، والمكون 1-4 يطلب أن يحدد صاحب الصلاحية Authorized Official الهيكل التنظيمي والأدوار والمسؤوليات ويعتمدها مع مراعاة عدم تعارض المصالح Conflict of Interest. والسبب في فصل الأمن عن تقنية المعلومات أن الفريق الذي يشغل الأنظمة ويحاسب على سرعة التسليم لا يصلح أن يكون الحكم الوحيد على أمنها، وهذا هو مبدأ فصل المهام Segregation of Duties نفسه الذي سوف تراه في الصلاحيات أيضاً.

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

المخاطر Risk: الاحتمال والأثر، والأصلية والمتبقية

المخاطرة Risk في تعريف مسرد NIST هي مقياس لمدى تهديد حدث أو ظرف محتمل للمؤسسة، وهي في العادة دالة في أمرين: الأثر السلبي Impact إذا وقع الحدث، واحتمال Likelihood وقوعه. فالمخاطرة ليست الثغرة Vulnerability وحدها ولا التهديد Threat وحده، وإنما ما يحدث عندما يستغل تهديد ثغرة في أصل Asset له قيمة، ولذلك تبدأ كل منهجية مخاطر بقائمة الأصول: ما الذي نحميه، ومن يملكه، وما قيمته.

والمصطلحات التي سوف تقابلها في كل سجل مخاطر هي:

• الاحتمال Likelihood والأثر Impact: تقدير لكل منهما بمقياس تحدده المؤسسة، مثل منخفض ومتوسط ومرتفع، أو من 1 إلى 5، وحاصل ضربهما هو درجة المخاطرة التي ترتب بها القائمة. وقد شرحنا في نمذجة التهديدات Threat Modeling كيف ترتب تهديدات تطبيق واحد بهذه الطريقة، أما هنا فالفكرة نفسها على مستوى المؤسسة كلها.
• المخاطرة الأصلية Inherent Risk: بحسب NIST هي المخاطرة في غياب أي إجراء مباشر من الإدارة لتغيير شدتها، أي قبل الضوابط.
• المخاطرة المتبقية Residual Risk: بحسب NIST هي الجزء الذي يبقى من المخاطرة بعد تطبيق الضوابط، ولاحظ أنها لا تصل إلى الصفر أبداً، فالهدف أن تنزل تحت المستوى الذي تقبله الإدارة، وليس أن تختفي.
• شهية المخاطر Risk Appetite: بحسب NIST هي أنواع المخاطر ومقدارها التي تقبلها المؤسسة بشكل عام في سعيها لتحقيق أهدافها، وهي قرار حوكمة تكتبه الإدارة، وليست رقماً يختاره الفريق التقني.
• سجل المخاطر Risk Register: بحسب NIST هو سجل مركزي للمخاطر الحالية ومعلوماتها لنطاق معين، ويشمل المخاطر المقبولة والمخاطر التي لها خطة معالجة.
• معالجة المخاطرة Risk Treatment: القرار الذي تتخذه لكل مخاطرة، وهو واحد من أربعة: التخفيف Mitigate، أو الإزالة Avoid، أو النقل Transfer، أو القبول Accept، وقد شرحناها بالتفصيل مع أمثلة في مقال نمذجة التهديدات، والمهم هنا أن القبول قرار مكتوب له مالك وتاريخ مراجعة، وليس سكوتاً.

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

في المثال أعلاه لاحظ التالي:

• الأثر لم يتغير بعد MFA، لأن من يسرق حساب مدير سوف يصل إلى البيانات نفسها، والذي تغير هو احتمال أن ينجح بكلمة مرور مسربة فقط، ولو أردت أن تقلل الأثر أيضاً فأنت تحتاج إلى ضوابط أخرى مثل تقليل صلاحيات حسابات الإدارة، كما شرحنا في إدارة الهوية والوصول IAM والوصول المميز PAM.
• لكل مخاطرة مالك Risk Owner بالاسم أو بالمنصب، وهو الشخص الذي يحاسب إذا وقعت، وغالباً ليس هو من ينفذ الضابط.
• المقياس من 1 إلى 3 مقياس توضيحي، والمهم أن تكتب المؤسسة مقياسها ومعنى كل درجة في منهجية المخاطر Risk Methodology، حتى يصل شخصان مختلفان إلى الدرجة نفسها تقريباً.

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

الامتثال Compliance: الالتزام بما يطلبه غيرك

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

• الأنظمة واللوائح Laws and Regulations: ملزمة بقوة القانون لمن يقع في نطاقها، مثل نظام حماية البيانات الشخصية PDPL في المملكة الذي تشرف عليه سدايا، وقرارات الجهات المنظمة لكل قطاع.
• الأطر والمعايير Frameworks and Standards: قوائم منظمة من الضوابط والممارسات، بعضها ملزم لجهات محددة مثل الضوابط الأساسية للأمن السيبراني ECC التي تنطبق على الجهات الحكومية وجهات البنى التحتية الوطنية الحساسة، وبعضها اختياري تتبناه المؤسسة أو تطلب الشهادة فيه مثل ISO/IEC 27001.
• العقود Contracts: عندما يطلب منك عميل الالتزام بإطار معين أو بسياساته في العقد، فإن هذا يصبح التزاماً عليك حتى لو لم يكن الإطار ملزماً لك بالنظام، وهذا ما حدث مع شركتنا الصغيرة، فهي ليست جهة حكومية، ولكن المستشفى الحكومي ملزم بضوابط ECC، والضوابط نفسها في الضابط 4-1-2 تطلب أن تلزم الجهة الطرف الخارجي في العقد بتطبيق متطلباتها وسياساتها في الأمن السيبراني.

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

الضوابط Controls: ما تفعله فعلاً لتقلل المخاطرة

الضابط Security Control في تعريف NIST هو إجراء حماية Safeguard أو إجراء مضاد Countermeasure يوضع لنظام أو لمؤسسة لحماية سرية المعلومات Confidentiality وسلامتها Integrity وتوافرها Availability ولتحقيق متطلبات أمنية محددة. وبكلام أبسط، الضابط هو أي شيء تفعله أو تضعه ليقلل احتمال المخاطرة أو أثرها، وقد يكون إعداداً في نظام، أو قراراً مكتوباً، أو باباً مقفلاً.

وتصنف الضوابط عادة بطريقتين في الوقت نفسه. الطريقة الأولى بحسب وقت عمل الضابط، وهي التي تقابل وظائف إطار NIST CSF 2.0، فالوظيفة Protect غرضها أن تمنع الحوادث أو تقلل احتمالها وأثرها، والوظيفة Detect غرضها أن تكتشفها وتحللها، والوظيفتان Respond وRecover غرضهما احتواء الحادثة وإعادة العمل:

• الضابط الوقائي Preventive: يمنع الحادثة قبل أن تقع، مثل MFA وجدار الحماية Firewall وسياسة كلمات المرور.
• الضابط الكشفي Detective: يكشف الحادثة أثناء وقوعها أو بعده، مثل التنبيه من سجلات الدخول ومراجعة الصلاحيات الدورية وكاميرات المراقبة.
• الضابط التصحيحي Corrective: يقلل أثر الحادثة ويعيدك إلى الوضع الطبيعي، مثل استعادة النسخة الاحتياطية وإجراء الاستجابة للحوادث.

والطريقة الثانية بحسب نوع الضابط، وهي الطريقة التي يذكرها مدخل NIST إلى أمن المعلومات SP 800-12 Rev. 1 عند شرح الدفاع في العمق Defense in Depth، حيث يجمع بين الدفاعات الإدارية مثل السياسات والإجراءات، والتقنيات الأمنية مثل أنظمة كشف التسلل وجدران الحماية والإعدادات، والحماية المادية مثل البوابات والحراس:

• الضابط الإداري Administrative: قرارات ووثائق وأشخاص، مثل السياسة والتدريب والتحقق من خلفية الموظفين.
• الضابط التقني Technical: إعدادات وأنظمة وكود، مثل التشفير والصلاحيات والسجلات.
• الضابط المادي Physical: أبواب وكاميرات ومعدات، مثل قارئ البطاقات على غرفة السيرفرات.

والصورة التالية تجمع التصنيفين في جدول واحد، بمثال في كل خلية:

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

وهناك مصطلح ثالث سوف تقابله في التدقيق هو الضابط البديل Compensating Control، وهو بحسب NIST ضابط يطبق بدلاً من الضابط المطلوب ويقدم حماية مكافئة أو مقاربة. فإذا كان لديك نظام قديم لا يدعم MFA مثلاً، فقد تضعه خلف شبكة خاصة VPN لا يدخلها إلا من سجل ب MFA، مع مراقبة دخوله، وتوثق السبب وتاريخ استبدال النظام، وهذا مقبول غالباً إذا كان موثقاً ومعتمداً من مالك المخاطرة، ومرفوض إذا كان مجرد عذر شفهي.

السياسة والمعيار والإجراء والإرشاد Policy, Standard, Procedure, Guideline

هذه الكلمات الأربع تستخدم في الكلام اليومي كأنها مترادفة، ولكنها في GRC أربعة مستويات مختلفة من الوثائق، ويشرح الفرق بينها NIST SP 800-12 Rev. 1 في القسم 5.1، والخلاصة كما يلي:

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

والصورة التالية تبين المستويات الأربعة لموضوع واحد هو MFA في شركتنا:

وقد يتساءل البعض: لماذا لا نكتب كل شيء في السياسة ونرتاح؟ والإجابة أن السياسة تحتاج إلى اعتماد الإدارة العليا، فإذا كتبت فيها «تطبيق TOTP» فسوف تحتاج إلى اعتماد جديد من المدير التنفيذي كلما غيرت مزود الهوية، وإذا كتبت فيها خطوات الإجراء فلن يقرأها أحد. لذلك تبقى السياسة قصيرة وثابتة، والتفاصيل في المعيار والإجراء. وهذا الترتيب نفسه تجده في ECC، فالضابط 1-3-1 يطلب تحديد سياسات وإجراءات الأمن السيبراني وتوثيقها واعتمادها من صاحب الصلاحية ونشرها، والضابط 1-3-3 يطلب أن تدعمها معايير تقنية أمنية مثل معايير جدار الحماية وقواعد البيانات وأنظمة التشغيل. وتنشر الهيئة الوطنية للأمن السيبراني في حزمة أدوات الأمن السيبراني Cybersecurity Toolkits قوالب جاهزة من النوعين، فترى في أسماء ملفاتها كلمة POLICY لقوالب السياسات وكلمة STANDARD لقوالب المعايير وكلمة CHECKLIST لقوائم التحقق، وهي نقطة بداية جيدة بشرط أن تعدلها لتطابق ما تفعله فعلاً.

الأدلة Evidence: ما لم يوثق فهو لم يحدث في نظر المدقق

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

والصورة التالية تبين ضابطاً واحداً في شركتنا والأدلة الأربعة التي تثبته:

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

ومن أين تأتي الأدلة؟ أغلبها يأتي من أنظمتك نفسها إذا صممتها جيداً، فالسجلات Logs التي شرحناها في السجلات Logging للمطورين ومديري السيرفرات دليل على الضوابط الكشفية، وسجل التدقيق Audit Trail الذي شرحناه في سجل التدقيق: من فعل ماذا ومتى هو الدليل الذي يجيب عن «من غير صلاحية هذا الحساب ومتى»، وتذاكر طلبات التغيير Change Requests دليل على أن التغييرات على الإنتاج Production معتمدة. والدليل الجيد له مصدر واضح وتاريخ ونطاق، ويمكن أن يجمعه شخص آخر ويصل إلى النتيجة نفسها، أما الدليل الضعيف فهو لقطة شاشة بلا تاريخ، أو سياسة لم يعتمدها أحد، أو سجل لا يغطي الفترة المطلوبة، أو جملة «نحن نفعل ذلك» في اجتماع.

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

التدقيق Audit: الداخلي والخارجي، والملاحظة وخطة التصحيح

التدقيق Audit في مسرد NIST عملية منهجية ومستقلة وموثقة للحصول على أدلة التدقيق وتقييمها بموضوعية لتحديد مدى استيفاء معايير التدقيق Audit Criteria، ويضيف التعريف أن التدقيق قد يكون داخلياً Internal Audit (الطرف الأول First Party) أو خارجياً External Audit (الطرف الثاني أو الثالث)، وأن التدقيق الداخلي تقوم به المؤسسة نفسها أو طرف خارجي يعمل لصالحها. والطرف الثاني في العادة هو عميلك أو الجهة التي تتعامل معها، مثل المستشفى الذي يدقق على شركتنا، والطرف الثالث جهة مستقلة عن الاثنين، مثل جهة منح الشهادات Certification Body في ISO 27001.

والصورة التالية تبين خطوات التدقيق، ومن الذي يمكن أن يقوم به:

وفي هذه الخطوات مصطلحات سوف تقابلها في كل تقرير تدقيق:

• النطاق Scope ومعايير التدقيق Audit Criteria: ما الأنظمة والإدارات والفترة الزمنية التي سوف تفحص، وعلى أي متطلبات تقاس، مثل ضوابط ECC أو سياساتك الداخلية.
• الملاحظة Finding: نتيجة يكتبها المدقق عندما لا يطابق الواقع المتطلب، وغالباً معها تصنيف لخطورتها.
• خطة التصحيح Corrective Action Plan: لكل ملاحظة إجراء يعالج سببها، ومالك، وتاريخ إغلاق، ثم متابعة Follow-up يتأكد فيها المدقق بدليل جديد أنها أغلقت فعلاً.

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

ولاحظ أن كلمة Audit تستخدم بمعنى آخر في الأنظمة، وهو سجل التدقيق Audit Log الذي يسجل من فعل ماذا ومتى، والمعنيان مرتبطان، فالثاني من أهم أدلة الأول.

الأطر Frameworks الأشهر باختصار

الإطار Framework مجموعة منظمة من المتطلبات أو النتائج المطلوبة تستخدمها المؤسسة لبناء برنامجها وقياسه، والجدول التالي يلخص أشهر أربعة أطر سوف تقابلها، وكلها تستخدم المصطلحات التي شرحناها:

ولاحظ أن ISO/IEC 27001 لا يبدأ بقائمة ضوابط، وإنما بنظام إدارة تنشئه وتطبقه وتحافظ عليه وتحسنه باستمرار، أي بدورة تشبه دورة GRC التي رسمناها في أول المقال، أما NIST CSF فهو لغة لوصف النتائج أكثر منه قائمة ضوابط، وأما SOC 2 فهو تقرير عن ضوابط مقدم خدمة يطلبه عملاؤه ليطمئنوا إلى المخاطر التي تنتقل إليهم مع الخدمة. والمقارنة الكاملة بين هذه الأطر، ومن يحتاج أياً منها، مقال مخطط في مرحلة GRC، وقد ذكرنا في مقال ASVS كيف تملأ معايير OWASP التفاصيل التقنية التي تطلبها هذه الأطر من التطبيقات.

مثال كامل: من مخاطرة واحدة إلى ملف المدقق

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

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

أخطاء شائعة

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

المصطلحات في جدول واحد

الخلاصة

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

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

دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلإدارة الهوية والوصول IAM والوصول المميز PAMمن يملك صلاحية root على سيرفراتك ومنذ متى، وكيف تضبط حسابات المديرين بصلاحيات مؤقتة وجلسات مسجلة.دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.دليلالسجلات Logging للمطورين: ماذا تسجل وماذا لا تسجلكيف تكتب سجلات Logs تساعدك على فهم ما حدث في الإنتاج، وما الذي لا يدخل السجل أبداً، وكيف تجمعها في مكان واحد.

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

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

• أكتوبر 2026: كتابة المقال، بالرجوع إلى مسرد NIST وNIST SP 800-12 Rev. 1 وNIST CSF 2.0 ونص ECC-2:2024 والدليل الإرشادي لتطبيقه من الهيئة الوطنية للأمن السيبراني.