ما هو CTEM؟ كيف تنتقل من فحص الثغرات إلى إدارة التعرض المستمر؟

إدارة التعرض المستمر للتهديدات Continuous Threat Exposure Management (CTEM) هي برنامج تشغيلي مستمر يساعد المؤسسة على معرفة أي نقاط التعرض يمكن أن تقود فعلًا إلى ضرر مهم للأعمال، ثم ترتيبها والتحقق منها ومعالجتها بدل التعامل مع كل نتيجة أمنية بالدرجة نفسها.

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

CTEM ليست منتجًا واحدًا ولا بديلًا عن Vulnerability Management أو اختبار الاختراق. هي دورة تجمع بيانات الأصول والثغرات والهويات والتهيئات ومسارات الهجوم والسياق التجاري، ثم تحولها إلى قرارات قابلة للتنفيذ.

ما هي CTEM بالضبط؟

ظهر مصطلح CTEM من Gartner لوصف نهج مستمر لإدارة التعرضات الأمنية بدل الاعتماد على تقييمات منفصلة ودورية. وتستمر Gartner في التعامل مع Exposure Management باعتباره ممارسة أوسع من إدارة الثغرات التقليدية؛ إذ تشمل البنية المرجعية لإدارة التعرض تقييم سطح الهجوم، وتقييم الثغرات، وترتيب التعرضات، والتحقق الهجومي منها، ثم المعالجة أو التخفيف.

كلمة Exposure هنا مهمة لأنها أوسع من Vulnerability. فقد يكون التعرض:

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

لذلك لا ينبغي اختزال CTEM في ماسح Vulnerability Scanner جديد. ويمكن الرجوع إلى دليل مصطلحات الأمن السيبراني إذا كنت تحتاج إلى التمييز بين Vulnerability وExploit والمفاهيم الأساسية المرتبطة بها.

لماذا لم يعد ترتيب آلاف CVEs حسب CVSS كافيًا؟

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

وتزداد مشكلة الحجم نفسها. ففي أبريل 2026 أعلنت NIST تغيير طريقة إثراء بيانات National Vulnerability Database بعد ارتفاع عدد CVEs المقدمة بنسبة 263% بين 2020 و2025. وأصبح نموذج NVD الجديد يعطي الأولوية، من بين فئات أخرى، للثغرات الموجودة في كتالوج CISA للثغرات المستغلة فعليًا. هذا التغيير لا يساوي CTEM، لكنه يوضح سبب عدم قابلية استراتيجية «تعامل مع كل شيء بالطريقة نفسها» للاستمرار مع تزايد الحجم.

يمكن مراجعة إعلان NIST عن نموذج NVD القائم على الأولوية للاطلاع على تفاصيل التغيير.

ولهذا تجمع CTEM عدة إشارات بدل الاعتماد على رقم واحد:

الإشارة	ماذا تخبرك؟	ما الذي لا تخبرك به وحدها؟
CVSS	الشدة والخصائص التقنية للثغرة	هل ستُستغل ضد بيئتك فعلًا؟
EPSS	تقدير احتمال ملاحظة استغلال CVE في البرية خلال 30 يومًا	تأثيرها التجاري أو وجودها في بيئتك
CISA KEV	وجود دليل على استغلال الثغرة في البرية	مدى أهمية الأصل لديك أو إمكانية وصول المهاجم إليه
Business Criticality	أهمية الأصل أو الخدمة للأعمال	قابلية الاستغلال التقنية
Attack Path	إمكانية انتقال المهاجم من نقطة دخول إلى هدف مهم	احتمال حدوث الهجوم خارج سياق بقية الإشارات
Compensating Controls	هل توجد ضوابط تقلل إمكانية الوصول أو التأثير؟	أن الخطر اختفى بالضرورة

وتوضح FIRST صراحة أن EPSS ليس Risk Score كاملًا؛ فهو يقدّر احتمال الاستغلال ولا يعرف تأثير الثغرة على مؤسستك أو الضوابط الموجودة لديها. كما توصي CISA باستخدام كتالوج KEV كأحد مدخلات ترتيب أولويات إدارة الثغرات، لا باعتباره المصدر الوحيد للقرار.

المراحل الخمس لبرنامج CTEM

1. Scoping: حدد ما الذي تحاول حمايته

الخطأ الأول هو البدء بنطاق مثل «افحص جميع عناوين IP في الشركة». CTEM تبدأ من نطاق له معنى للأعمال.

قد يكون السؤال مثلًا:

• كيف يستطيع مهاجم الوصول من الإنترنت إلى منصة الدفع؟
• ما التعرضات التي قد تؤدي إلى بيانات العملاء؟
• ما الطرق الممكنة للوصول إلى بيئة Production؟
• ما المخاطر المحيطة بحسابات مسؤولي Microsoft 365؟

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

وهذا يتوافق أيضًا مع فلسفة NIST Cybersecurity Framework 2.0 التي تربط ترتيب الأنشطة الأمنية باحتياجات المؤسسة والمخاطر والموارد المتاحة بدل التعامل مع الأمن باعتباره قائمة تقنية منفصلة عن الأعمال.

2. Discovery: اكتشف الأصول والتعرضات

بعد تحديد النطاق، يجب معرفة ما الذي يوجد فعليًا داخله وكيف يمكن الوصول إليه.

قد تأتي البيانات من:

• Asset Inventory وCMDB.
• Vulnerability Scanners.
• Cloud Security Posture Management.
• Attack Surface Management.
• Identity Security.
• EDR وXDR.
• SaaS Security.
• مستودعات الكود وCI/CD.
• Threat Intelligence.

Attack Surface Management مفيدة هنا خصوصًا لاكتشاف الأصول والخدمات المكشوفة. لكن ASM ليست CTEM كاملة؛ Discovery مرحلة واحدة فقط ضمن الدورة. ومن الأمثلة المبسطة على اتساع سطح الهجوم تأثير التهيئات الخاطئة على سطح الهجوم.

3. Prioritization: رتب التعرضات حسب الخطر الحقيقي

بعد Discovery قد تحصل على آلاف أو ملايين Findings. وظيفة Prioritization ليست إضافة لون أحمر جديد إليها، وإنما تقليصها إلى مجموعة يمكن للفريق التصرف بشأنها.

من الإشارات المهمة:

• هل يوجد استغلال معروف في البرية؟
• ما احتمال الاستغلال وفق بيانات مثل EPSS؟
• هل الأصل مكشوف للإنترنت؟
• هل توجد بيانات أو عمليات حساسة خلفه؟
• ما الصلاحيات التي يمكن الحصول عليها بعد الاختراق؟
• هل توجد ثغرات أو أخطاء أخرى تسمح بتكوين Attack Path؟
• هل توجد ضوابط تعويضية تقلل إمكانية الاستغلال؟
• كم مضى على وجود التعرض دون معالجة؟

والنتيجة ليست «تجاهل كل شيء غير حرج»، وإنما منح الأولوية لما يجمع بين قابلية الاستغلال والوصول والتأثير والسياق التجاري.

4. Validation: هل يعمل مسار الهجوم فعلًا؟

Prioritization ما تزال مبنية جزئيًا على بيانات ونماذج. تأتي Validation لاختبار الافتراضات المهمة.

يمكن تنفيذ التحقق بوسائل مختلفة حسب المخاطر والبيئة، مثل:

• Breach and Attack Simulation.
• Attack Path Analysis.
• Adversarial Exposure Validation.
• Penetration Testing.
• Red Team exercises عند الحاجة.
• تحقق يدوي محدود من إعداد أو صلاحية.

يمكن ربط السيناريوهات ذات الصلة بتكتيكات وتقنيات MITRE ATT&CK حتى يكون الاختبار قائمًا على سلوكيات هجومية معروفة وليس على سيناريوهات عشوائية.

ولا تعني Validation محاولة Exploit لكل CVE. قد يكفي أحيانًا إثبات أن خدمة غير قابلة للوصول من المسار المفترض، أو أن صلاحية معينة لا تسمح بالحركة إلى الهدف الحساس، أو أن أحد الضوابط يوقف التقنية المختبرة.

وعندما تكون الحاجة إلى اختبار أعمق للشبكة أو التطبيقات، يظل اختبار الاختراق Capability مهمة، لكنه لا يمثل بمفرده برنامج CTEM المستمر.

5. Mobilization: حوّل النتيجة إلى تغيير فعلي

هذه المرحلة هي التي تمنع CTEM من التحول إلى Dashboard أخرى.

العثور على Attack Path حقيقي لا يقلل الخطر ما لم تتحول النتيجة إلى عمل واضح، مثل:

• تحديث برنامج أو نظام.
• إغلاق خدمة غير ضرورية.
• تغيير Firewall Rule.
• تقليل صلاحيات حساب.
• تدوير Credential مسرّبة.
• إصلاح Misconfiguration.
• إضافة Segmentation.
• تطبيق Compensating Control عندما يتعذر الإصلاح المباشر.

ويجب أن يملك الإجراء مسؤولًا وموعدًا وسياقًا يوضح سبب الأولوية، ثم تتم إعادة التحقق بعد الإصلاح.

هنا يتقاطع CTEM مع عمليات مركز عمليات الأمن السيبراني SOC وفرق IT وCloud وIdentity وApplication Security؛ فإدارة التعرض ليست مسؤولية أداة أو فريق منفرد.

CTEM مقابل Vulnerability Management وASM وAEV

المفهوم	الدور الأساسي	مكانه بالنسبة إلى CTEM
Vulnerability Management	اكتشاف الثغرات وتقييمها ومعالجتها	Capability مهمة داخل البرنامج، لكن CTEM أوسع من CVEs
Attack Surface Management	اكتشاف الأصول والتعرض الخارجي والتغيرات في السطح	تغذي Discovery وScoping
AEV / BAS	التحقق من إمكانية نجاح تقنيات أو مسارات هجومية	تدعم Validation
Penetration Testing	اختبار أعمق لنطاق محدد من منظور هجومي	إحدى وسائل Validation، وليست الدورة الكاملة
CTEM	Scoping وDiscovery وPrioritization وValidation وMobilization بصورة مستمرة	البرنامج التشغيلي الذي يربط هذه القدرات حول تقليل التعرض

لهذا السبب فإن شراء منصة تحمل عبارة Exposure Management لا يعني تلقائيًا وجود برنامج CTEM ناضج. التكنولوجيا تجمع وتحلل البيانات، لكن المؤسسة ما تزال تحتاج إلى نطاق واضح ومنطق للأولوية ومالكي معالجة وآلية لقياس النتيجة.

مثال: لماذا قد تكون Misconfiguration أهم من CVE حرجة؟

افترض وجود نتيجتين:

• خادم داخلي يحتوي على CVE بدرجة CVSS مرتفعة، لكنه غير مكشوف للإنترنت ولا يوجد حاليًا مسار قابل للتحقق من نقطة دخول خارجية إليه.
• حساب SaaS يمتلك صلاحيات واسعة، ويمكن لبيانات اعتماد مسرّبة مرتبطة به فتح طريق مباشر إلى بيانات حساسة.

فحص الثغرات التقليدي سيركز بسهولة على CVE لأن لديه رقمًا واضحًا. أما CTEM فتدرس السيناريو الكامل، وقد تضع مشكلة الهوية أولًا إذا كان مسارها إلى الأصل الحساس أقصر وأكثر واقعية.

هذا لا يعني أن الثغرة الأولى أصبحت آمنة أو أنه يجب تجاهلها. الفرق هو ترتيب وقت وموارد المعالجة بناءً على السياق.

كيف تبدأ CTEM دون شراء منصة جديدة؟

يمكن البدء بما تملكه المؤسسة بالفعل، ثم تحديد الفجوات التقنية بعد فهم العملية.

1. اختر خدمة تجارية واحدة مهمة. لا تحاول إدخال المؤسسة كاملة في الدورة الأولى.
2. حدد الأصول والهويات والبيانات المرتبطة بها.
3. اجمع Findings الموجودة أصلًا من Vulnerability Management وCloud وIdentity وEDR وأدوات اكتشاف السطح.
4. أضف سياق التهديد. استخدم مثلًا KEV وEPSS والمعلومات المتعلقة بالتعرض الخارجي.
5. ابحث عن Attack Paths بدل تقييم كل Finding بشكل معزول.
6. تحقق من أخطر الافتراضات باستخدام التقنية الأقل خطورة التي تقدم الدليل المطلوب.
7. عالج السبب ثم أعد الاختبار.

بعد نجاح الدورة في نطاق محدود، يمكن توسيعها إلى خدمة أو بيئة أخرى.

ما المقاييس المناسبة لبرنامج CTEM؟

عدد CVEs المغلقة وحده Metric ضعيفة؛ إذ يمكن لفريق إغلاق آلاف المشكلات السهلة مع ترك عدد قليل من مسارات الهجوم ذات التأثير الكبير.

مقاييس أكثر ارتباطًا بالنتيجة قد تشمل:

• الوقت من اكتشاف Exposure عالية الأولوية إلى التحقق منها.
• الوقت من Validation إلى Remediation.
• عدد Attack Paths المهمة التي أزيلت.
• عمر التعرضات الحرجة المكشوفة للإنترنت.
• نسبة التعرضات عالية الأولوية التي لها Owner وموعد معالجة.
• نسبة الإصلاحات التي تم التحقق منها بعد التنفيذ.
• Repeat Exposure Rate للمشكلات التي تعود بعد إصلاحها.

ويجب تفسير هذه المقاييس في سياق الخدمة والمخاطر؛ فلا يوجد رقم عالمي يجعل برنامج CTEM «ناجحًا» في جميع المؤسسات.

ما الذي تغيّر في 2026؟

لم يعد من الدقيق التعامل مع CTEM باعتبارها مجرد «اتجاه مستقبلي». بحلول 2025 و2026 استمرت Gartner في نشر أبحاث وبنى مرجعية حول Exposure Management ودمج بيانات التعرض في عمليات SecOps، وأصبحت فكرة جمع سياق الأصول والثغرات والهويات ومسارات الهجوم جزءًا أوضح من سوق منصات إدارة التعرض.

لكن توجد نقطة مهمة عند قراءة المواد الأقدم: في 2024 نشرت Gartner توقعًا بأن المؤسسات التي ترتب استثماراتها الأمنية وفق برنامج CTEM قد تحقق بحلول 2026 انخفاضًا بمقدار الثلثين في الاختراقات. كان ذلك توقعًا استشرافيًا، وليس نتيجة قياس تثبت أن جميع المؤسسات التي تستخدم CTEM حققت هذا الانخفاض بالفعل.

وفي الوقت نفسه، يوضح تغيير NVD في أبريل 2026 أن مشكلة الحجم أصبحت أكثر وضوحًا: حتى قواعد البيانات المركزية نفسها تحتاج إلى Prioritization عندما يتجاوز تدفق CVEs القدرة على إثراء كل نتيجة بالطريقة نفسها.

كما نشرت Gartner في مايو 2026 بحثًا حول استخدام CTEM لتوحيد بيانات التعرض عبر SecOps، وهو اتجاه مهم لأن جودة Prioritization تعتمد على دمج السياق بدل إبقاء بيانات Vulnerabilities وIdentity وAssets وThreats في جزر منفصلة.

أخطاء شائعة عند تطبيق CTEM

شراء Tool ثم إعلان أن CTEM اكتملت

المنصة قد تساعد في Discovery أو Prioritization أو Validation، لكنها لا تحدد وحدها ما هو مهم للأعمال ولا تضمن أن الفرق ستعالج النتائج.

توسيع النطاق منذ اليوم الأول

إدخال جميع Cloud Accounts وEndpoints وSaaS Applications والشبكات والهويات دفعة واحدة يعيد إنشاء المشكلة نفسها: كمية ضخمة من النتائج دون قدرة على التنفيذ.

استبدال CVSS بدرجة واحدة أخرى

EPSS أو KEV أو درجة Risk من أحد المنتجات يمكن أن تحسن القرار، لكن لا توجد إشارة واحدة تمثل المخاطر الكاملة للمؤسسة.

اعتبار Validation مرادفًا لاستغلال كل شيء

الهدف هو الحصول على دليل كافٍ لاتخاذ القرار بأمان. ليس مطلوبًا تحويل كل Exposure إلى عملية استغلال كاملة.

إهمال Mobilization

إذا لم تصل النتيجة إلى الفريق الذي يستطيع إزالة التعرض، ولم يكن لها Owner وأولوية وموعد وإعادة تحقق، فقد أنشأت المؤسسة نظامًا أفضل لاكتشاف المشكلات دون تحسين النتيجة الأمنية.

الخلاصة

CTEM تنقل إدارة الأمن من سؤال «كم Finding لدينا؟» إلى «أي مسارات التعرض تمثل خطرًا واقعيًا على الأعمال وكيف نقللها؟».

وتقوم الدورة على خمس مراحل مترابطة: Scoping، Discovery، Prioritization، Validation، ثم Mobilization. نجاحها لا يعتمد على ماسح أكثر قوة بقدر ما يعتمد على جمع السياق الصحيح، واختيار الأولويات القابلة للدفاع عنها، والتحقق من الفرضيات المهمة، ثم تحويل الدليل إلى معالجة قابلة للقياس.

لهذا لا تستبدل CTEM إدارة الثغرات أو ASM أو Penetration Testing أو SOC، وإنما تربط هذه القدرات حول هدف واحد: تقليل التعرض الذي يستطيع المهاجم استخدامه للوصول إلى ما يهم المؤسسة فعلًا.