مجالات الأمن السيبراني – Cybersecurity Domains
فهرس المقال
- مقدمة الحلقة: لماذا هذا هو “الأساس” وليس تفصيلًا؟
- 1) لماذا تفشل تقييمات المخاطر غالبًا؟ (المشكلة قبل الأدوات)
- 2) تعريفات توحيد اللغة: Asset / Data Context / Boundary
- 3) درجات النضج: من Excel إلى CMDB إلى Attack Surface Map
- 4) الحد الأدنى لحقول الجرد: ما الذي يجب تسجيله لكل أصل؟
- 5) إضافة Data Context: لماذا الأصل ليس “جهازًا” فقط؟
- 6) حدود الأنظمة (System Boundaries): أين نرسم “السياج”؟
- 7) التحويل العملي: من الجرد إلى Attack Surface Map
- 8) مصادر الحقيقة: كيف نبني جردًا لا يكذب ولا يتقادم؟
- 9) مؤشرات النجاح: KPIs وقياسات تُثبت أن القرار يتقدم
- 10) أخطاء قاتلة وفخاخ شائعة
- 11) خاتمة الحلقة وربطها بالحلقات القادمة
- المصادر والمراجع
مقدمة الحلقة: لماذا هذا هو “الأساس” وليس تفصيلًا؟
هناك أسئلة إذا لم تُجب عنها المؤسسة بدقة، فإن كل ما يُكتب بعدها في الأمن السيبراني يتحول إلى نشاطات متفرقة لا تنتج قرارًا: ماذا نملك؟ أين يوجد؟ من يملكه؟ ما الذي يشغّله؟ ما البيانات التي يلمسها؟ وما حدود النظام؟
كثير من المؤسسات تنظر للأمن كحزمة تقنيات: جدار ناري، مضاد فيروسات، منصات مراقبة، تقارير ثغرات… بينما الواقع الإداري مختلف: الأمن السيبراني قرار. والقرار لا يُبنى على “عدد التنبيهات”، بل يُبنى على معرفة ما يستحق الحماية أولًا، ولماذا، وبأي ترتيب.
1) لماذا تفشل تقييمات المخاطر غالبًا؟ (المشكلة قبل الأدوات)
الفشل لا يبدأ من المنهج… بل من الأرضية
كثير من برامج الأمن تفشل لأن المؤسسة تبدأ من النهاية: تبدأ بالأدوات ثم تحاول لاحقًا تفسير النتائج. لكن الأصح أن تبدأ بالأساس: معرفة الأصول وسياقها وحدودها.
- غياب الجرد: لا يمكن تقييم ما لا تعرف أنه موجود.
- غياب سياق البيانات: نفس المشكلة التقنية قد تكون كارثة على نظام يمس بيانات حساسة، وتفصيلًا ثانويًا على نظام آخر.
- غياب الحدود: بدون تعريف Boundary لا تعرف أين نقاط الدخول والخروج ولا أين تقع المسؤولية.
- غياب المالك: أصل بلا Owner يعني قرارًا بلا تنفيذ.
2) تعريفات توحيد اللغة: Asset / Data Context / Boundary
2.1 ما هو الأصل (Asset)؟
الأصل هو أي شيء له قيمة ويحتاج حماية، ولا يقتصر على الأجهزة فقط. في الواقع، بعض أخطر الأصول هي “هوية وصلاحيات ومفاتيح” أكثر من كونها خوادم.
- أصول تقنية: أجهزة، خوادم، قواعد بيانات، تطبيقات، حاويات، موارد سحابة.
- أصول هوية: حسابات، أدوار سحابية (IAM)، حسابات مميزة.
- أصول وصول: مفاتيح API، أسرار (Secrets)، شهادات TLS.
- أصول تعاقدية: خدمات SaaS وموردون وتكاملات طرف ثالث.
2.2 ما هو Data Context؟
هو معرفة ما البيانات التي يلمسها هذا الأصل، ومن يملك قرارها، وكيف تتحرك، وما متطلبات حمايتها واحتفاظها. الأصل ليس “مهمًا” بذاته… بل بما يلمسه من بيانات وبما يملكه من صلاحيات.
- نوع البيانات: شخصية (PII)، مالية، صحية، أسرار تجارية، مفاتيح تشفير…
- تصنيف البيانات: عام/داخلي/سري/مقيّد.
- مالك البيانات: Data Owner (قد يختلف عن مالك النظام).
- مسار البيانات: مصدر ← معالجة ← تخزين ← إرسال/تكامل ← أرشفة/حذف.
2.3 ما معنى حدود النظام (System Boundary)؟
حدّ منطقي/تشغيلي يحدد ما الداخل الذي تتحكم به المؤسسة، وما الخارج الذي تعتمد عليه، وأين نقاط الدخول والخروج، وأين تنتهي المسؤولية وتبدأ مسؤولية طرف آخر.
3) درجات النضج: من Excel إلى CMDB إلى Attack Surface Map
3.1 أربع درجات عملية — بدون تنظير
- المستوى (0): جرد اسمي — قائمة أسماء بلا مالك، بلا تحديث، بلا سياق بيانات، بلا علاقات.
- المستوى (1): MVI — جرد حد أدنى للأصول الحرجة خلال أسابيع قليلة.
- المستوى (2): جرد تشغيلي حي — الجرد جزء من التشغيل والتغيير، لا وثيقة جامدة.
- المستوى (3): CMDB — علاقات اعتماد بين خدمة/تطبيق/قاعدة بيانات/خادم/شبكة/هوية.
- المستوى (4): Attack Surface Map — تحويل الجرد إلى خريطة انكشاف وأولوية قرار.
4) الحد الأدنى لحقول الجرد: ما الذي يجب تسجيله لكل أصل؟
4.1 “حقول لا يمكن التنازل عنها” (Minimum Fields)
إذا لم تستطع المؤسسة تسجيل هذه الحقول، فإن الجرد لن ينتج قرارًا ولن يصمد أمام التدقيق أو التشغيل.
- هوية الأصل: Asset ID / الاسم / النوع / البيئة (Prod/Test/Dev).
- الملكية: Business Owner + Technical Owner.
- المكان: On-prem / Cloud / SaaS + منطقة/شبكة.
- الانكشاف: Internet-facing? + منافذ/واجهات/نقاط دخول.
- الحالة التقنية: إصدار/نظام/حالة تحديث (Patch Level) + نهاية دعم (EOL/EOS).
- الأهمية: Criticality وفق منظور الأعمال، لا وفق رأي تقني فقط.
- الاعتماديات: يعتمد على ماذا؟ ومن يعتمد عليه؟
5) إضافة Data Context: لماذا الأصل ليس “جهازًا” فقط؟
5.1 تصنيف البيانات: طبقات واضحة يفهمها التقني والإدارة
تصنيف البيانات ليس تمرينًا شكليًا؛ هو مفتاح ترتيب الأولويات. نفس الأصل يتغير تقييمه جذريًا عندما نعرف نوع البيانات التي يلمسها.
- Public: بيانات للنشر العام.
- Internal: بيانات داخل المؤسسة.
- Confidential: بيانات حساسة تتطلب قيود وصول وتشفير ومراقبة.
- Restricted: بيانات عالية الحساسية (هويات، صحة، مفاتيح، أسرار تجارية…)
5.2 ربط الأصل بالبيانات: Tagging ينتج قرارًا
بدل “هذا سيرفر”، تصبح الجملة تشغيلية: “هذا الأصل يلمس بيانات PII ويحتفظ بها 5 سنوات، ومالك البيانات هو قسم كذا.”
- Data Types: PII / مالية / صحية / أسرار / مفاتيح وصول.
- Data Owner: من يملك قرار الوصول والمشاركة والاستثناءات؟
- Retention: ما مدة الاحتفاظ ولماذا؟
- Data Flow: أين تدخل البيانات وأين تُخزَّن وأين تُرسل؟
5.3 خريطة حركة البيانات (Data Flow) كاختصار للوقت والجدل
حتى لو بخطوط بسيطة، فإن رسم: إرسال/تكامل ← تخزين ← معالجة ← مصدر يحوّل النقاش من “آراء” إلى “نقاط” واضحة تُدار.
6) حدود الأنظمة (System Boundaries): أين نرسم “السياج”؟
6.1 بطاقة حدود نظام (صفحة واحدة) تغيّر طريقة العمل
كثير من المؤسسات تُسمّي “النظام” كعنوان، لكنها لا تعرف حدوده عمليًا. بطاقة واحدة لكل خدمة رئيسية تمنع الفوضى.
- اسم الخدمة/النظام + هدفه التجاري.
- مالك الخدمة + مالك التشغيل.
- داخل النطاق (In Scope) وما خارج النطاق.
- نقاط الدخول (Ingress) ونقاط الخروج (Egress).
- تكاملات الطرف الثالث والعقود المؤثرة.
- البيانات المصنفة التي يلمسها النظام ومساراتها.
7) التحويل العملي: من الجرد إلى Attack Surface Map
7.1 تعريف بسيط لسطح الهجوم
سطح الهجوم هو كل نقطة يمكن استغلالها أو إساءة استخدامها: واجهة مكشوفة، حساب مميز، مفتاح وصول، تكامل طرف ثالث، إعداد سحابي خاطئ، منفذ إدارة… وما لا تراه في الجرد لن تراه في الدفاع.
7.2 “وسوم القرار” التي تحوّل الجدول إلى خريطة
لكي يتحول الجرد إلى خريطة، ضع لكل أصل مجموعة وسوم بسيطة لكنها حاسمة:
- وسم الانكشاف (Exposure): خارجي/شركاء/داخلي فقط.
- وسم البيانات (Data): تصنيف + نوع بيانات (PII/مالية/صحية/أسرار).
- وسم الصلاحيات (Privilege): هل يمتلك صلاحيات واسعة؟ هل يحمل أسرار وصول؟
- وسم التحديث (Freshness): محدث/متأخر/نهاية دعم.
- وسم الاعتماديات (Dependencies): نقطة فشل واحدة؟ يعتمد عليه نظام حرج؟
7.3 كيف تخرج “الأولوية” تلقائيًا؟ (منطق بسيط)
عندما تتجمع هذه الوسوم، يصبح ترتيب الأولويات منطقيًا بدل انطباعي:
8) مصادر الحقيقة: كيف نبني جردًا لا يكذب ولا يتقادم؟
8.1 لماذا الجرد اليدوي وحده يفشل؟
لأن الواقع يتغير أسرع من أي ملف: أجهزة تُضاف، موارد سحابية تُنشأ، خدمات SaaS تُشترى بلا علم الأمن، مفاتيح تُنشأ داخل مشاريع… الجرد إن لم يكن “عملية” سيتحول إلى “متحف”.
8.2 مصادر عملية لبناء Single Source of Truth
- هوية وصلاحيات: AD / Azure AD / IAM (الحسابات والأدوار والمميز).
- الشبكة والنطاق: اكتشاف DNS، المسح الداخلي، مناطق الشبكة.
- السحابة: مخزون الموارد AWS/Azure/GCP (حسابات، تخزين، شبكات، أدوار).
- الأجهزة: MDM/EDR (حالة الأجهزة، الامتثال، التحديث).
- التشغيل والتغيير: ITSM/Change (أي تغيير يجب أن يحدّث الجرد).
- DevOps: مستودعات، أسرار، CI/CD (مصادر “أصول غير مرئية” غالبًا).
9) مؤشرات النجاح: KPIs وقياسات تُثبت أن القرار يتقدم
9.1 مؤشرات قابلة للتطبيق فورًا
- Inventory Coverage %: نسبة الأصول المكتشفة والمقيدة ضمن الجرد.
- Owner Assigned %: نسبة الأصول التي لها Business Owner وTechnical Owner.
- External Attack Surface Count: عدد الأصول المكشوفة للإنترنت + اتجاهه.
- Patch Compliance (Critical): التزام التحديث للأصول الحرجة.
- Data-tag Coverage %: نسبة الأصول الموسومة بسياق بيانات وتصنيف واضح.
- Stale Records %: سجلات لم تُحدّث خلال 30/60/90 يوم.
10) أخطاء قاتلة وفخاخ شائعة
10.1 أخطاء تتكرر في أغلب المؤسسات
- حصر الجرد بالأجهزة فقط: وتجاهل الحسابات المميزة، المفاتيح، الشهادات، SaaS، وShadow IT.
- CMDB بلا تغيير: تصبح قاعدة بيانات “غير صحيحة” أكثر من كونها مفيدة.
- أهمية الأصل تُحدَّد من IT فقط: بينما القيمة تُعرَّف غالبًا من الأعمال.
- السعي للكمال مبكرًا: يقتل المشروع. ابدأ بـ MVI ثم توسع.
- غياب مالك البيانات: يجعل الوصول والمشاركة والاستثناءات فوضى لا تُدار.
11) خاتمة الحلقة وربطها بالحلقات القادمة
عندما يتأسس Asset Inventory مع Data Context وحدود أنظمة واضحة، تتحول المؤسسة من “تقارير” إلى “قرار”. وحينها فقط تصبح الحلقات التالية (الفحص/الاختبار/المراقبة/إدارة الثغرات) أدوات داخل إطار واحد: نختبر ماذا أولًا؟ نراقب ماذا أولًا؟ نعالج ماذا أولًا؟ ولماذا؟
الأدوات لا تبني أمنًا… الجرد + السياق + الحدود تبني قرارًا، وما بعد القرار يصبح تنفيذًا.
المصادر والمراجع
- [1] NIST — Cybersecurity Framework (CSF) 2.0. https://www.nist.gov/cyberframework
- [2] NIST — SP 800-53 Rev. 5 (خصوصًا CM-8: System Component Inventory). https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- [3] CIS — Critical Security Controls v8 (Control 1 & 2: Asset/Software Inventory). https://www.cisecurity.org/controls/v8
- [4] ISO — ISO/IEC 27001:2022 (ISMS Requirements) وISO/IEC 27002:2022 (Controls guidance). https://www.iso.org/standard/82875.html
