مجالات الأمن السيبراني – Cybersecurity Domains
فهرس المقال
- مقدمة
- 1) أين تقع “المخاطر” داخل منظومة الأمن؟
- 2) (أ) ما هو “الخطر” بصياغة تشغيلية؟
- 3) (ب) دورة العمل القياسية Identify → Analyze → Evaluate → Treat → Monitor
- 4) (ج) لماذا يفشل تقييم المخاطر غالبًا؟
- 5) (د) المخرجات التي تهم القارئ التنفيذي
- 6) قياس موجز (KRIs/KPIs) — بدون تفصيل
- 7) خاتمة الحلقة وربطها بالحلقات القادمة
- المصادر والمراجع
مقدمة
كثير من المؤسسات تتعامل مع الأمن السيبراني كحزمة تقنيات: جدار ناري، مضاد فيروسات، منصة مراقبة… بينما الواقع الإداري مختلف: الأمن قرار. وتقييم المخاطر هو “اللغة” التي تُحوّل ضجيج التقنية إلى: أولوية + ميزانية + زمن + مسؤولية.
1) أين تقع “المخاطر” داخل منظومة الأمن؟
الفكرة الأساسية: الأدوات ليست الهدف
أدوات الفحص والرصد والاختبار لا تساوي “إدارة مخاطر” تلقائيًا. هي فقط وسائل لتغذية قرار واحد: ماذا سنفعل، وبأي أولوية، ولماذا الآن؟
- التقنية تُنتج بيانات: ثغرات، تنبيهات، سوء ضبط.
- المخاطر تُترجم البيانات إلى “سيناريو أثر” على أصل محدد.
- الإدارة تتخذ قرارًا وتخصص موارد وتضع استحقاقات.
2) (أ) ما هو “الخطر” بصياغة تشغيلية؟
تعريف تشغيلي مختصر
الخطر ليس “ثغرة”، وليس “تهديدًا” منفصلًا، وليس “حادثة” وقعت. الخطر هو سيناريو قابل للتحقق: احتمال أن يؤدي مسار تهديد عبر تعرض/ضعف إلى أثر على أصل ذي قيمة، مع وجود ضوابط تؤثر على الاحتمال والأثر.
تحويل الخطر إلى “قصة تدقيق” (Risk Scenario)
أفضل طريقة لمنع الغموض هي كتابة الخطر كجملة تشغيلية: “تهديد X يستغل ضعف Y عبر مسار Z ليؤثر على أصل A بنتيجة B.”
- X التهديد: مهاجم خارجي، موظف داخلي، مورد طرف ثالث، خطأ تشغيلي، فشل بنية…
- Y الضعف: إعداد خاطئ، صلاحيات زائدة، غياب تصنيف بيانات، ضعف مراقبة، ثغرة تقنية…
- Z المسار: بريد تصيّد، حسابات مميزة، بوابة مكشوفة، وصول فيزيائي، واجهة طرف ثالث…
- A الأصل: خدمة حرجة، قاعدة بيانات، نظام مالي، منصة موارد بشرية، بوابة مواطن…
- B النتيجة: توقف، تسريب، تحريف بيانات، فدية، تعطيل سلسلة إمداد…
3) (ب) دورة العمل القياسية: Identify → Analyze → Evaluate → Treat → Monitor
3.1 Identify — التعرّف
الهدف: معرفة ما الذي يجب تقييمه بدقة: الأصول وحدودها، وتدفقات البيانات، ونقاط التعرض.
- جرد الأصول: أنظمة/خدمات/بيانات/واجهات/طرف ثالث.
- حدود النظام: أين يبدأ وينتهي؟ وما الاتصالات/التكاملات؟
- سياق البيانات: نوع الحساسية، الالتزام القانوني، الأثر على الأفراد.
- سيناريوهات أولية: ما المسارات الأكثر واقعية، لا الأكثر تخويفًا.
3.2 Analyze — التحليل
الهدف: تقدير الأثر والاحتمال بصورة قابلة للتفسير، مع تمييز الخطر قبل الضوابط وبعدها.
- الخطر الكامن (Inherent): قبل احتساب الضوابط.
- الخطر المتبقي (Residual): بعد احتساب فعالية الضوابط.
- فعالية الضوابط: موجودة؟ مطبقة؟ مراقبة؟ قابلة للتدقيق؟
- ارتباط التحليل بالواقع: أي تقدير لا يرتبط بأدلة يصبح رأيًا.
3.3 Evaluate — التقييم/الترتيب
الهدف: ترتيب المخاطر ضمن “قابلية اتخاذ قرار” وفق شهية المخاطر وحدود التحمل.
- الترتيب: ما الذي يجب أن يسبق؟ وما الذي يمكن أن ينتظر؟
- شهية المخاطر (Risk Appetite): ما المستوى المقبول إداريًا؟
- حدود التحمل (Tolerance): ما الحد الذي لا يسمح بتجاوزه؟
- منطق المقارنة: أثر “قانوني/خصوصية” قد يُرفع حتى لو كانت احتماليته أقل.
3.4 Treat — المعالجة (قرارات أربعة)
الهدف: تحويل كل خطر إلى قرار واضح ومبرر، ثم ربطه بخطة تنفيذ.
- معالجة (Mitigate): تقليل الاحتمال أو الأثر بضوابط.
- نقل/مشاركة (Transfer/Share): تأمين/تعاقد/طرف ثالث — مع بقاء الحوكمة.
- قبول (Accept): قبول مُوقع ومبرر وبشروط متابعة.
- تجنب (Avoid): إيقاف نشاط/واجهة/خدمة أو إعادة تصميم جوهري.
3.5 Monitor — المتابعة
الهدف: إبقاء المخاطر “حية” ومواكبة لتغير الواقع: تهديدات جديدة، أصول جديدة، توسع رقمي.
- مؤشرات: KRIs للإنذار المبكر وKPIs لأداء المعالجة.
- اختبارات فعالية الضوابط: تدقيق/اختبار/مراجعة.
- تحديث السياق: تغيّر الأعمال أو الموردين أو التكاملات أو البيانات.
4) (ج) لماذا يفشل تقييم المخاطر غالبًا؟
أسباب الفشل الأكثر شيوعًا (عمليًا)
- لا يوجد Asset Inventory: التقييم يصبح “تخمينًا” لأنك لا تعرف ما تملك ولا أين تقع قيمته.
- خلط بين “الثغرة” و“الخطر”: الثغرة رقم/وصف؛ الخطر سيناريو أثر على أصل ضمن سياق.
- لا يوجد سياق بيانات (Data Context): نفس المشكلة على نظامين قد تكون كارثة على واحد وتفصيلًا ثانويًا على آخر.
- لا يوجد Owners ومسؤوليات: بدون مالك، لا تنفيذ ولا ميزانية ولا استحقاق.
- تُكتب النتائج ولا تُترجم إلى خطة: غياب Roadmap وميزانية ومواعيد يجعل الملف “معلّقًا”.
5) (د) المخرجات التي تهم القارئ التنفيذي
5.1 Risk Register — سجل المخاطر
ما المقصود؟ سجل واحد “مركزي” يربط السيناريو بالقرار وبالملكية وبالمتابعة. وجوده يمنع التشتت بين تقارير الأدوات ويجعل الإدارة ترى الصورة.
- حقول ضرورية (حد أدنى): أصل، سيناريو، مالك، مستوى خطر، قرار، استحقاق، حالة تنفيذ.
- تمييز مهم: خطر كامن/متبقٍ + الضوابط الحالية + فجوات المعالجة.
5.2 Top Risks Heatmap — خريطة أعلى المخاطر
ما المقصود؟ عرض بصري سريع يوضح أين تتجمع المخاطر العالية (أثر مرتفع/احتمال مرتفع) مع إبراز مخاطر قانونية/سيادية حتى لو كانت احتمالية أقل.
5.3 خطة معالجة (Roadmap) مرتبطة بمالك وزمن وكلفة
ما المقصود؟ تحويل القرار إلى تنفيذ: مبادرات ومشاريع مرتبطة بمواعيد وتبعيات وكلفة تقريبية.
- المالك: من يتحمل التنفيذ والمتابعة؟
- الزمن: تاريخ بدء/انتهاء + نقاط مراجعة.
- الكلفة: حتى لو نطاق (Range) أو رتبة تقريبية.
- التبعيات: ما الذي يجب إنجازه أولًا ليعمل الحل؟
5.4 مؤشرات متابعة (KRIs/KPIs)
ما المقصود؟ أدوات متابعة تجعل المخاطر “تُدار” لا “تُوصف”.
- KRIs: إنذار مبكر (تغير التعرض، ارتفاع محاولات، توسع سطح هجوم…).
- KPIs: أداء المعالجة (نسبة إغلاق، التزام بالاستحقاقات، فعالية ضوابط…).
6) قياس موجز (KRIs/KPIs) — بدون تفصيل
ما المقصود؟ وضع حد أدنى من القياس يثبت أن التقييم يتحرك ويُغلق، وأن تغير البيئة يُلتقط مبكرًا.
- KRI — نمو السطح: زيادة خدمات مكشوفة/واجهات/موردين/تكاملات.
- KRI — حساسية البيانات: توسع بيانات شخصية/حساسة بلا تصنيف أو ضوابط.
- KPI — التزام الاستحقاقات: نسبة عناصر خارطة المعالجة المنجزة ضمن الوقت.
- KPI — خفض الخطر المتبقي: قياس تغيّر مستوى الخطر بعد تطبيق الضوابط.
7) خاتمة الحلقة وربطها بالحلقات القادمة
تقييم المخاطر هو القاعدة التي تجعل بقية مجالات الأمن السيبراني قابلة للإدارة: بدل أن تُدار المؤسسة عبر “قائمة ثغرات”، تُدار عبر “سجل قرارات” مرتبط بمالكين ومواعيد وكلفة وأدلة متابعة.
المصادر والمراجع
- [1] NIST — SP 800-30: Guide for Conducting Risk Assessments. https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
- [2] NIST — SP 800-37: Risk Management Framework (RMF). https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final
- [3] ISO — ISO/IEC 27005: Information security risk management. https://www.iso.org/standard/80585.html
- [4] ISO — ISO 31000: Risk management — Guidelines. https://www.iso.org/iso-31000-risk-management.html
- [5] ISO — ISO/IEC 27001 (ISMS Requirements — risk-based approach). https://www.iso.org/standard/82875.html
