MDR اختصار لـ Managed Detection and Response، وهي خدمة أمن سيبراني تتولى مراقبة التهديدات وكشفها والتحقيق فيها والاستجابة لها بالنيابة عن المؤسسة، عادةً من خلال مزيج من التقنيات الأمنية والأتمتة ومحللين بشريين يعملون على مدار الساعة.
الفكرة الأساسية ليست شراء أداة أخرى تولّد المزيد من التنبيهات، بل إضافة طبقة تشغيلية تتولى فرز تلك التنبيهات وربطها بالسياق والتحقق مما إذا كان النشاط يمثل تهديدًا حقيقيًا، ثم تنفيذ إجراءات الاستجابة المسموح بها أو توجيه فريق المؤسسة لما يجب فعله.
وهذا يفسر سبب لجوء المؤسسات إلى MDR عندما تكون لديها أدوات مثل EDR أو SIEM لكنها لا تملك عددًا كافيًا من المحللين لمراقبتها طوال الوقت، أو عندما تريد تعزيز قدرات مركز عمليات الأمن السيبراني SOC دون بناء جميع القدرات داخليًا.
ما هي MDR Services بالضبط؟
تصف Microsoft خدمة MDR بأنها خدمة تجمع بين تقنيات الكشف المتقدمة والخبرة البشرية لتنفيذ مراقبة التهديدات وصيدها والاستجابة للحوادث.
لكن لا توجد حزمة واحدة موحدة تسمى MDR يقدمها جميع المزودين بالطريقة نفسها. قد تركز خدمة على نقاط النهاية، بينما تجمع أخرى Telemetry من الأجهزة والهوية والبريد الإلكتروني والشبكات والخدمات السحابية وSIEM. وقد يستطيع مزود تنفيذ إجراءات احتواء مباشرة، بينما يكتفي آخر بإرسال توصيات لفريق العميل.
لذلك من الأدق التفكير في MDR باعتبارها نموذج تشغيل أمني مُدار وليس تقنية منفردة.
كيف تعمل MDR؟
يختلف التنفيذ بين مزود وآخر، لكن سير العمل النموذجي يمر بعدة مراحل مترابطة.
1. جمع Telemetry الأمنية
تحتاج خدمة MDR إلى رؤية كافية داخل البيئة حتى تتمكن من اكتشاف السلوك المشبوه. وقد تشمل مصادر البيانات:
- أجهزة Windows وLinux وmacOS.
- EDR وEndpoint Security.
- أنظمة الهوية وإدارة الحسابات.
- البريد الإلكتروني.
- الشبكات وأجهزة Firewall.
- الخدمات والتطبيقات السحابية.
- أنظمة SIEM.
- سجلات التطبيقات والخوادم، وفق نطاق الخدمة والتكاملات المدعومة.
لا يعني استخدام MDR بالضرورة أن المزود يرى جميع هذه المصادر. نطاق Telemetry يجب أن يكون من أول الأشياء التي تتحقق منها قبل توقيع العقد.
2. الكشف وربط الإشارات
تُحلل الأحداث باستخدام قواعد كشف وتحليل سلوكي وThreat Intelligence وتقنيات آلية أخرى، وقد تُربط أحداث منفصلة ببعضها لتكوين Incident واحد ذي سياق أوضح.
على سبيل المثال، قد لا يكون تسجيل دخول غير معتاد كافيًا وحده لإعلان حادث، لكن ظهوره مع إنشاء صلاحيات جديدة ثم نشاط غير مألوف على جهاز المستخدم قد يجعل الصورة أكثر أهمية.
وهنا تبرز قيمة MDR فوق مجرد استقبال آلاف Alerts منفصلة.
3. Triage والتحقيق
بعد ظهور Detection أو Incident، يقوم النظام والمحللون بفرز الحالة لمعرفة ما إذا كانت:
- True Positive وتمثل نشاطًا ضارًا حقيقيًا.
- False Positive.
- نشاطًا مشروعًا أو متوقعًا يحتاج إلى توثيق أو Tuning.
- حالة غير محسومة تحتاج إلى معلومات أو تحليل إضافي.
هذه المرحلة مهمة لأن الهدف ليس جعل كل Alert حادثًا أمنيًا، وإنما تقليل الضوضاء ورفع الحالات التي تستحق فعلًا تدخل الفريق.
4. Threat Hunting
تقدم كثير من خدمات MDR شكلًا من أشكال Threat Hunting للبحث عن نشاط لا يكون قد أدى إلى تنبيه واضح بعد.
وقد يعتمد الصيد على TTPs معروفة، وThreat Intelligence، وأنماط سلوكية، ومؤشرات جديدة ظهرت في حملات هجومية أخرى.
ولا يعني ذلك أن MDR قادرة على اكتشاف كل هجوم أو كل ثغرة Zero-Day. فحتى عند غياب Signature للثغرة نفسها، يمكن أحيانًا كشف مراحل لاحقة من الهجوم مثل تنفيذ عمليات غير معتادة أو سرقة بيانات الاعتماد أو Persistence أو Lateral Movement، بشرط توفر Telemetry مناسبة.
5. الاستجابة والاحتواء
عندما يصبح التهديد مؤكدًا، تبدأ أهم مرحلة: ماذا يستطيع مزود MDR أن يفعل فعليًا؟
قد تشمل إجراءات الاستجابة، بحسب المنتج والصلاحيات والعقد:
- عزل جهاز مصاب عن الشبكة.
- إيقاف أو عزل ملف ضار.
- تعطيل حساب مستخدم.
- حظر Indicators معينة.
- إيقاف Process خبيثة.
- إرسال خطوات Remediation إلى فريق العميل.
- تصعيد الحادث إلى Incident Response أو DFIR عند الحاجة.
وتوضح وثائق Microsoft Defender Experts MDR هذا الفرق عمليًا: يمكن للمحللين، عند منحهم الصلاحيات المناسبة، تنفيذ مجموعة من إجراءات الاستجابة نيابة عن العميل، بينما تتحول بعض الحالات الأخرى إلى توصيات أو إجراءات يجب أن ينفذها فريق المؤسسة.
6. المراجعة والتحسين
بعد معالجة الحادث، يفترض ألا ينتهي العمل عند إغلاق Alert. الخدمة الجيدة تساعد أيضًا على فهم سبب الحادث، وتحسين قواعد الكشف، وتحديد نقاط الضعف التشغيلية التي سمحت بحدوثه.
وهذا يتماشى مع نهج إدارة الحوادث الحديث؛ إذ يربط NIST SP 800-61 Rev. 3 الاستجابة للحوادث بإدارة مخاطر الأمن السيبراني الأوسع، بما يشمل الاستعداد والكشف والاستجابة والتعافي والتحسين المستمر.
ما الفرق بين MDR وEDR وXDR وSIEM وSOC وMSSP؟
أكثر الأخطاء شيوعًا هو التعامل مع هذه المصطلحات وكأنها منتجات متنافسة تؤدي الوظيفة نفسها، بينما يمكن أن تعمل عدة طبقات منها معًا.
| المصطلح | ما هو؟ | الدور الأساسي |
|---|---|---|
| EDR | تقنية Endpoint Detection and Response | جمع وتحليل نشاط نقاط النهاية والمساعدة في الكشف والتحقيق والاستجابة عليها |
| XDR | منصة Detection and Response أوسع | ربط إشارات من أكثر من طبقة مثل Endpoint والهوية والبريد والسحابة |
| SIEM | منصة لجمع وتحليل وربط السجلات والأحداث | الرؤية المركزية والتحليل والتنبيه ودعم التحقيقات |
| SOC | وظيفة أو فريق عمليات أمنية | المراقبة والتحليل والتحقيق والاستجابة وإدارة العمليات الأمنية |
| MDR | خدمة Detection and Response مُدارة | إضافة محللين وعمليات وتقنيات لمراقبة التهديدات والتحقيق والاستجابة نيابة عن المؤسسة |
| MSSP | Managed Security Service Provider | مصطلح أوسع لمقدمي خدمات أمنية مُدارة قد تشمل إدارة Firewall وSIEM والمراقبة وغيرها |
MDR ليست بديلًا تلقائيًا عن EDR
EDR قد يكون أحد أهم مصادر البيانات والأدوات التي تعتمد عليها خدمة MDR. لذلك عبارة "MDR أم EDR؟" ليست دائمًا المقارنة الصحيحة؛ فقد تشتري EDR ثم تديره داخليًا، أو تحصل عليه ضمن خدمة MDR، أو تربط EDR موجودًا لديك بمزود خارجي.
يمكنك الاطلاع على دور EDR إلى جانب أدوات الحماية الأخرى في دليل نظم الحماية الأساسية في الأمن السيبراني.
MDR وXDR
XDR غالبًا منصة تقنية، بينما MDR طبقة خدمة وتشغيل بشري مُدار. وقد يستخدم مزود MDR منصة XDR لتنفيذ الخدمة، لكن وجود XDR لا يعني تلقائيًا أن هناك محللين يراقبونها ويتعاملون مع الحوادث نيابة عنك على مدار الساعة.
MDR وSOC
لا تعني الاستعانة بـMDR بالضرورة التخلص من SOC الداخلي.
قد تستخدم مؤسسة صغيرة MDR باعتبارها الجزء الأكبر من قدرتها التشغيلية، بينما تستخدمها مؤسسة أكبر لتقوية SOC موجود بالفعل أو لتغطية أوقات الليل والعطل أو مهارات متخصصة.
وتصف Microsoft خدمتها الحالية بأنها تعزز SOC لدى العميل بدل أن تكون بالضرورة بديلًا كاملًا له.
MDR وMSSP
كان التفريق التقليدي يقول إن MSSP يدير الأدوات ويرسل التنبيهات بينما MDR يحقق ويستجيب. هذا التبسيط لم يعد دقيقًا دائمًا، لأن بعض MSSP الحديثة تقدم Threat Hunting وIncident Response وقد تعرض MDR ضمن خدماتها.
لذلك لا تعتمد على الاسم التجاري وحده. اقرأ بوضوح ما الذي تتم مراقبته، ومن يحقق، ومن ينفذ الاستجابة، وما الذي يبقى مسؤولية مؤسستك.
MDR ليست Incident Response كاملة بالضرورة
هذه نقطة مهمة جدًا عند شراء الخدمة.
قد تكون MDR ممتازة في اكتشاف نشاط مهاجم واحتواء جهاز أو حساب، لكنها ليست بالضرورة عقدًا لخدمات Digital Forensics أو إدارة أزمة Ransomware أو استعادة مئات الخوادم بعد تشفيرها.
على سبيل المثال، توضح حدود Microsoft Defender Experts MDR الحالية أن الخدمة ليست Incident Response engagement لحادث اختراق كبير قائم بالفعل، وتفصل Microsoft خدمة الاستجابة للحوادث عن MDR.
لذلك اسأل مقدم الخدمة مسبقًا عما يحدث عند تجاوز الحادث نطاق العمليات اليومية: هل توجد DFIR؟ هل الخدمة مشمولة أم برسوم إضافية؟ ومن يتولى Recovery وCrisis Management؟
هل MDR مناسبة لكل مؤسسة؟
ليست كل مؤسسة بحاجة إلى النموذج نفسه. القيمة تكون أوضح عندما توجد فجوة فعلية بين الأدوات الموجودة والقدرة على تشغيلها.
قد تكون MDR مناسبة خصوصًا عندما:
- لا يتوفر فريق أمني يعمل 24/7.
- يمتلك الفريق EDR أو SIEM لكنه يعاني من Alert Fatigue.
- لا تتوفر خبرة كافية في Threat Hunting والتحقيقات.
- تحتاج المؤسسة مراقبة خارج ساعات العمل.
- تتوزع البيئة بين Endpoint والهوية والسحابة وأنظمة متعددة.
- تحتاج المؤسسة إلى خفض MTTD وMTTR وتحسين عملية التصعيد.
- يصعب توظيف محللين أمنيين والاحتفاظ بهم داخليًا.
في المقابل، MDR ليست سببًا لإهمال الأساسيات. يجب أن تظل المؤسسة مسؤولة عن Asset Management والتحديثات والنسخ الاحتياطية وMFA وإدارة الصلاحيات وتقسيم الشبكات والسياسات الأمنية وغيرها من أفضل ممارسات الأمن السيبراني.
ما الذي يجب فحصه عند اختيار مزود MDR؟
لا يكفي أن يكتب المزود "24/7 MDR" على صفحة المنتج. الأهم هو معرفة ما الذي يحدث عندما يصل Threat حقيقي الساعة الثالثة صباحًا.
1. نطاق Telemetry
حدد بدقة المصادر التي يستطيع المزود رؤيتها:
- Endpoints.
- Identity.
- Email.
- Cloud.
- Network.
- SaaS.
- SIEM.
- OT أو IoT إذا كانت جزءًا من بيئتك.
وتحقق من الفرق بين "يمكننا استيراد Log" وبين "لدينا Detection وAnalyst Coverage فعلية لهذا المصدر".
2. نطاق الاستجابة
اطلب قائمة مكتوبة بالإجراءات التي يستطيع المزود تنفيذها دون انتظار موافقة يدوية، وتلك التي تحتاج إلى Authorization.
الفرق بين "سنرسل لك تنبيهًا بأن الجهاز مصاب" و"سنحقق ثم نعزل الجهاز وفق الصلاحيات المتفق عليها" كبير جدًا.
3. ساعات العمل الحقيقية
تحقق مما إذا كانت عبارة 24/7 تشمل:
- Triage.
- Analyst investigation.
- Threat Hunting.
- Response.
- الاتصال بالعميل في الحالات الحرجة.
قد تختلف حدود كل وظيفة حتى عندما تكون منصة المراقبة نفسها متاحة دائمًا.
4. التكامل مع الأدوات الحالية
إذا كانت لديك استثمارات كبيرة في Microsoft Defender أو CrowdStrike أو SentinelOne أو SIEM معين، فاعرف هل يمكن للمزود العمل معها أم يفرض استبدالها.
الخدمة Vendor-agnostic قد تكون مفيدة في البيئات المختلطة، بينما قد يوفر MDR المبني مباشرة على منصة أمنية واحدة تكاملًا أعمق مع منتجات ذلك المزود.
5. SLA ومقاييس الأداء
اطلب تعريفًا واضحًا للمقاييس، ولا تكتفِ بعبارات مثل "استجابة سريعة". من المقاييس المفيدة:
- زمن بدء Triage.
- زمن التحقيق.
- زمن إخطار العميل.
- زمن الاحتواء للحوادث المؤكدة.
- عدد الحالات التي تحتاج إلى تدخل العميل.
وانتبه إلى أن MTTD وMTTR يمكن تعريفهما بطرق مختلفة بين المزودين، لذلك لا تقارن رقمين قبل معرفة نقطة البداية والنهاية التي يقيسها كل منهما.
6. صلاحيات المزود
كلما زادت قدرة MDR على تنفيذ استجابة مباشرة، زادت أهمية تصميم Access Control جيد.
اسأل عن:
- نوع الحسابات والصلاحيات المستخدمة.
- كيفية تسجيل Actions المنفذة.
- فصل المهام والموافقات.
- استثناء الأنظمة الحساسة من Automated Response عند الحاجة.
- كيفية إلغاء الوصول عند انتهاء العقد.
7. الاحتفاظ بالبيانات وموقعها
اعرف ما Telemetry التي ستغادر بيئتك، وأين تُخزن، ومدة الاحتفاظ بها، ومن يستطيع الوصول إليها، وكيف تُحذف عند انتهاء الخدمة.
هذه النقاط قد تكون مهمة بسبب متطلبات الخصوصية أو العقود أو القوانين المحلية، ولا يكفي افتراض أن شراء MDR يحقق Compliance تلقائيًا.
8. Incident Response وDFIR
حدد ما إذا كانت الخدمات التالية مشمولة أم منفصلة:
- Forensic analysis.
- Malware analysis.
- Compromise assessment.
- Incident containment.
- Eradication.
- Recovery.
- Ransomware response.
- إدارة الحوادث واسعة النطاق.
9. الخروج من الخدمة
من السهل التركيز على Onboarding ونسيان Offboarding. اسأل كيف تستعيد Logs والبيانات والتقارير، وكيف تزال Agents والتكاملات والصلاحيات إذا قررت تغيير المزود.
كم تكلف MDR؟
لا توجد تكلفة معيارية يمكن تطبيقها على جميع خدمات MDR.
قد يكون التسعير مبنيًا على عدد Endpoints أو المستخدمين أو مصادر البيانات أو حجم البيئة أو حزمة المنتجات، وقد يدخل في السعر EDR نفسه أو يكون ترخيصه منفصلًا.
كما قد تختلف الأسعار بسبب مدة الاحتفاظ بالسجلات، وCloud Telemetry، ومستوى Threat Hunting، وخدمات Incident Response، وعدد البيئات أو المواقع.
ولهذا فإن القول إن MDR تكلف دائمًا مبلغًا ثابتًا لكل Endpoint سيكون مضللًا.
بعض الشركات تنشر أسعارًا مباشرة لمنتجات محددة، بينما تعتمد الخدمات المؤسسية غالبًا على عرض سعر. لذلك الأفضل مقارنة Total Cost of Ownership لنفس النطاق بدل مقارنة رقم شهري منفرد.
أمثلة على خدمات MDR المتاحة في 2026
السوق يتغير باستمرار، ولا توجد خدمة واحدة هي الأفضل لكل المؤسسات. الأمثلة التالية توضح اختلاف نماذج MDR الحالية وليست ترتيبًا أو توصية مطلقة.
| الخدمة | مثال على نموذج التغطية |
|---|---|
| Microsoft Defender Experts MDR | خدمة Expert-led مرتبطة ببيئة Microsoft Defender، مع خطة توسع التغطية إلى Telemetry مختارة من مصادر غير Microsoft عبر Microsoft Sentinel |
| CrowdStrike Falcon Complete MDR | خدمة MDR مرتبطة بمنصة Falcon وتجمع الأتمتة والتحقيق والاستجابة مع إشراف خبراء |
| Sophos MDR | مراقبة وتحقيق واستجابة 24/7 مع دعم مجموعة واسعة من التكاملات الأمنية |
| Arctic Wolf MDR | مراقبة 24/7 تجمع Telemetry من Endpoint والشبكات والبيئات السحابية مع فريق أمني مُدار |
| SentinelOne Wayfinder MDR | خدمة مراقبة وتحقيق واستجابة وخدمات Threat Hunting مرتبطة بمنظومة SentinelOne |
| Huntress Managed EDR | نموذج Managed EDR مدعوم بـSOC يعمل 24/7 ويركز بقوة على تشغيل حماية Endpoint نيابة عن العميل |
هذه الأمثلة تكشف نقطة مهمة: حتى داخل السوق نفسه، لا يستخدم كل مزود تعريفًا مطابقًا للآخر. لذلك يجب مقارنة Scope وTelemetry وResponse Rights وService Boundaries بدل مقارنة الأسماء التجارية فقط.
ما دور الذكاء الاصطناعي في MDR في 2026؟
أصبح AI والأتمتة أكثر حضورًا في خدمات MDR، خصوصًا في تلخيص الحوادث وربط الأحداث وإثراء التنبيهات وتحديد الأولويات وتشغيل Workflows للاستجابة.
لكن لا توجد نسبة عامة موثوقة يمكن القول إنها تنطبق على جميع خدمات MDR في مقدار تقليل False Positives أو نسبة الحوادث التي يعالجها AI.
الأرقام التي ينشرها مزود معين يجب فهمها باعتبارها بيانات تخص منصته وعملاءه ومنهجية القياس لديه، وليس معيارًا عالميًا للسوق.
والأهم أن استخدام AI لا يلغي الحاجة إلى Human Judgment. فإيقاف حساب أو عزل Server إنتاجي قد يكون قرارًا ذا أثر تشغيلي كبير، ولذلك تعتمد الخدمات الحديثة عادةً درجات مختلفة من الأتمتة وإشراف المحللين وفق حساسية الإجراء.
ما الذي يجب الاتفاق عليه قبل تشغيل MDR؟
أفضل خدمة في العالم يمكن أن تفشل عمليًا إذا لم يعرف الطرفان من المسؤول عن ماذا. قبل بدء الخدمة، يجب تحديد:
- الأصول والمستخدمين والبيئات المشمولة في Scope.
- مصادر Telemetry المطلوبة.
- جهات الاتصال للحوادث الحرجة.
- إجراءات الاستجابة المسموح تنفيذها تلقائيًا.
- الأنظمة التي تحتاج موافقة قبل عزلها أو تعطيلها.
- قواعد التصعيد حسب Severity.
- مسؤولية المؤسسة بعد إرسال Managed Response.
- آلية التعامل مع الحوادث الكبرى التي تتجاوز MDR.
- متطلبات الاحتفاظ بالسجلات والتقارير.
- طريقة اختبار الخدمة والتأكد من أن التكاملات تعمل بالفعل.
وتوضح وثائق إعداد Microsoft Defender Experts MDR مثالًا عمليًا على أهمية الصلاحيات وجهات الاتصال والاستثناءات؛ فإذا لم يحصل المحللون على صلاحيات الاستجابة المناسبة، فقد يتمكنون من التحقيق وتقديم التوصيات لكن لا يستطيعون تنفيذ بعض إجراءات الاحتواء مباشرة.
كيف تعرف أن MDR تحقق قيمة فعلية؟
لا تقيس الخدمة بعدد Alerts التي أرسلتها. كثرة التنبيهات ليست نتيجة أمنية.
ابحث بدلًا من ذلك عن مؤشرات مثل:
- هل يتم التحقيق في الحالات المهمة فعلًا؟
- كم Incident حقيقيًا تم اكتشافه واحتواؤه؟
- هل انخفض العبء على فريق IT أو SOC؟
- هل أصبحت الحوادث تُكتشف وتُصعد بسرعة أكبر؟
- هل توفر التقارير Root Cause وسياقًا قابلًا للتنفيذ؟
- هل تتحسن Detections بعد الحوادث السابقة؟
- هل ما زالت هناك أجزاء من البيئة خارج نطاق الرؤية؟
- هل يعرف فريقك ماذا يفعل عندما يطلب المزود إجراءً يدويًا؟
الخلاصة: متى تكون MDR استثمارًا منطقيًا؟
MDR ليست مجرد برنامج أمني جديد، وليست ضمانًا بأن الاختراق لن يحدث. قيمتها الحقيقية تظهر عندما تحول Telemetry والتنبيهات إلى عملية مستمرة من الكشف والتحقيق والاستجابة يقودها مختصون بدل ترك الأدوات تعمل دون متابعة كافية.
إذا كانت مؤسستك تمتلك EDR أو SIEM لكن لا تستطيع مراقبتهما وتحليل الحوادث على مدار الساعة، أو إذا كان فريقك يحتاج إلى Threat Hunting وخبرة استجابة إضافية، فقد تكون MDR طريقة عملية لسد هذه الفجوة.
لكن الاختيار الصحيح لا يبدأ بسؤال "من أفضل مزود MDR؟"، بل بأسئلة أكثر دقة: ما الأصول التي سيراقبها؟ ما Telemetry التي يراها؟ ماذا يفعل عند تأكيد الاختراق؟ ما الصلاحيات التي يحتاجها؟ وما الذي يبقى مسؤولية فريقك؟
عندما تكون الإجابات واضحة ومكتوبة، تصبح MDR جزءًا قابلًا للقياس من استراتيجية الدفاع، بدل أن تكون مجرد اشتراك أمني آخر يضيف أدوات وتنبيهات جديدة.