مشكلة Alert Fatigue في مركز العمليات الأمنية لا تُحل بتوظيف محللين أكثر لفتح عدد أكبر من التنبيهات. إذا كانت منظومة الكشف تنتج ضوضاء باستمرار، فسوف تستهلك وقت أي فريق مهما زاد حجمه.
الحل يبدأ من جودة الإشارة: هل التنبيه يمثل سلوكًا يستحق التحقيق؟ هل يحمل السياق الذي يسمح بتحديد أولويته؟ وهل عدة تنبيهات تصف حادثًا واحدًا أم أنها تُعرض للمحلل كقضايا منفصلة؟
لهذا تختلف هذه الصفحة عن دليل مركز عمليات الأمن السيبراني SOC العام. التركيز هنا ليس على تعريف SOC أو مكوناته، بل على مشكلة تشغيلية محددة: كيف تقلل حجم العمل غير المفيد دون إضعاف قدرة الفريق على اكتشاف الحوادث الحقيقية.
ما هي Alert Fatigue؟
تحدث Alert Fatigue عندما يتعرض المحللون لحجم كبير من التنبيهات منخفضة القيمة أو المتكررة أو التي تفتقر إلى السياق، فيصبح فرزها جزءًا كبيرًا من يوم العمل. المشكلة ليست أن كل Alert خاطئة؛ فقد يكون بينها True Positives مهمة، لكن الإشارات المفيدة تختلط بضوضاء يصعب التعامل معها بالسرعة المطلوبة.
وقد تكون المشكلة ناتجة عن قاعدة كشف واحدة سيئة، أو عن طريقة تصميم Detection Pipeline كاملة. من الأسباب الشائعة:
- قواعد Detection عامة أكثر من اللازم.
- Thresholds لا تناسب السلوك الطبيعي للبيئة.
- نفس النشاط يولد Alerts من EDR وIdentity وFirewall وSIEM بصورة منفصلة.
- عدم توفر معلومات عن الأصل أو المستخدم داخل التنبيه.
- قواعد قديمة لم تُراجع بعد تغير الأنظمة أو التطبيقات.
- إرسال Telemetry ضخمة إلى SIEM دون تحديد Use Cases واضحة.
- اعتبار كل إشارة مستقلة بدل ربط سلسلة الأحداث ببعضها.
لهذا فإن بناء بنية مراقبة وكشف أمنية متكاملة أهم من مجرد زيادة عدد الأدوات التي تولد Alerts.
لا تعامل Alert وIncident على أنهما الشيء نفسه
من أكثر التغييرات تأثيرًا فصل مفهوم Alert عن Incident. التنبيه إشارة أنتجها Detector أوAnalytics Rule، أما الحادث فهو قضية تحقيق قد تضم تنبيهًا واحدًا أو مجموعة من الإشارات المرتبطة ببعضها.
لنفترض أن الحساب نفسه أنتج خلال فترة قصيرة:
- تسجيل دخول من سياق غير معتاد.
- إضافة وسيلة MFA جديدة.
- إنشاء Mailbox Forwarding Rule.
قد يكون كل حدث منفردًا منخفض الثقة، لكن جمعها في Timeline واحد يجعل الصورة مختلفة تمامًا. وعلى العكس، عرضها كثلاث قضايا منفصلة يجبر المحلل على إعادة جمع معلومات المستخدم والجهاز والجلسة في كل مرة.
منصات حديثة تطبق هذا المفهوم فعليًا. تسمح Microsoft Sentinel مثلًا بتجميع Alerts داخل Incidents، كما تسمح قواعد الأتمتة بتنفيذ إجراءات على مستوى الحادث بدل التعامل مع كل إشارة يدويًا. الفكرة المهمة ليست المنتج المستخدم، بل تصميم Queue حول القضايا التي تحتاج قرارًا بدل عدد الأحداث التي ولّدتها الأدوات.
Severity وحدها لا تحدد الأولوية
الاعتماد على مستوى High أوMedium الذي يضعه المنتج دون سياق قد يعطي ترتيبًا خاطئًا للعمل. تنبيه High على جهاز مختبر معزول ليس بالضرورة أهم من تنبيه Medium يتعلق بحساب إداري قادر على الوصول إلى أنظمة حساسة.
يجب أن تضيف عملية Triage معلومات مثل:
- Asset criticality: ما أهمية الجهاز أوالخدمة للأعمال؟
- Identity privilege: هل الحساب مستخدم عادي أم Administrator أم Service Account حساس؟
- Exposure: هل الأصل مكشوف للإنترنت أويمكن الوصول إليه من مناطق عالية المخاطر؟
- Related activity: هل توجد Events أخرى مرتبطة بالمستخدم أوالجهاز؟
- Threat context: هل السلوك يطابق سيناريو تهديد يهم المؤسسة فعلًا؟
- Potential impact: ماذا يمكن أن يحدث إذا كان النشاط خبيثًا؟
بهذا يصبح ترتيب العمل مبنيًا على Risk Context وليس اسم التنبيه وحده.
استخدم Correlation وDeduplication قبل زيادة عدد المحللين
إذا اكتشف EDR اتصالًا مشبوهًا ثم أنشأ SIEM تنبيهًا آخر من السجل نفسه وأطلقت أداة الشبكة تنبيهًا ثالثًا، فليس من المنطقي دائمًا إرسال ثلاث مهام مستقلة إلى المحلل.
Deduplication يقلل التكرار الواضح، بينما Correlation يحاول جمع إشارات مختلفة تشترك في مستخدم أوجهاز أوزمن أوAttack Chain واحدة.
لكن الارتباط نفسه يحتاج إلى ضبط. دمج كل التنبيهات التي تخص مستخدمًا واحدًا خلال يوم كامل قد يخفي قضايا مستقلة، بينما إنشاء Incident جديدة لكل Event يعيد مشكلة الضوضاء. يجب تحديد نوافذ زمنية وEntities وشروط ارتباط تناسب كل Detection Scenario.
Tuning الجيد يبدأ من نتائج التحقيقات
كل False Positive متكرر هو Feedback على Detection وليس مجرد تذكرة يجب إغلاقها.
بعد التحقيق، حاول معرفة السبب الحقيقي:
- هل شرط Detection واسع؟
- هل هناك تطبيق داخلي شرعي يشبه السلوك الخبيث؟
- هل Threshold منخفض أكثر من اللازم؟
- هل قاعدة الكشف تحتاج إلى Context إضافي؟
- هل المصدر يرسل Telemetry غير متوقعة بسبب تغيير في Configuration؟
- هل Detection نفسها لم تعد تخدم سيناريو تهديد مهمًا؟
يمكن بعد ذلك تعديل المنطق بدل تدريب المحللين على تجاهل التنبيه.
هذا الأسلوب موجود أيضًا في المنتجات التجارية. توضح وثائق Microsoft Defender XDR حول Alert Tuning أن قواعد الضبط يمكنها التعامل مع النشاط المتوقع وتقليل الضوضاء، لكنها تحذر من استخدام التوليف دون فهم الحالات التي ستتأثر به.
لا تعالج الضوضاء بـAllowlist واسعة
الاستثناء السريع قد يزيل آلاف Alerts فورًا، لكنه قد يزيل معها جزءًا من الرؤية الأمنية.
مثلًا، إذا كان برنامج إداري شرعي يشغّل PowerShell باستمرار، فإن استثناء powershell.exe بالكامل سيكون أوسع بكثير من المطلوب. الأفضل البحث عن Context يمكن استخدامه لتحديد النشاط المشروع بدقة أكبر، مثل Host أوParent Process أوCommand pattern أوحساب خدمة محدد، بحسب البيانات التي توفرها منصة الكشف.
المبدأ هو:
اجعل Exception أضيق ما يسمح به السلوك الشرعي، ثم راقب تأثيرها.
كما يجب أن تكون الاستثناءات قابلة للمراجعة؛ فالاستثناء الذي كان منطقيًا لتطبيق داخلي قبل عام قد يصبح Blind Spot بعد تغير التطبيق أوالبنية.
اجعل Detection Rule منتجًا له دورة حياة
قاعدة الكشف ليست شيئًا يُنشأ مرة ثم يبقى إلى الأبد. البيئة التي تعتمد عليها تتغير: أسماء الحقول، مصادر Logs، التطبيقات، بنية الشبكة وسلوك المستخدمين كلها قد تتبدل.
لكل Detection مهمة ينبغي أن توجد، حيثما تسمح المنصة، معلومات مثل:
- السيناريو الذي تحاول اكتشافه.
- مصادر البيانات المطلوبة.
- Owner مسؤول عنها.
- منطق Detection وإصداره.
- خطوات Triage.
- اختبارات معروفة يجب أن تنجح.
- التغييرات التي أُجريت وسببها.
- طريقة Rollback عند ظهور مشكلة.
وعندما تسمح التقنية، يفيد التعامل مع القواعد بأسلوب Detection as Code ووضعها في Version Control بحيث يمكن Review التغييرات واختبارها وتتبعها بدل تعديل قواعد Production دون سجل واضح.
لا تخف من حذف Detection سيئة
وجود 500 قاعدة لا يعني امتلاك تغطية أفضل من بيئة تستخدم 150 قاعدة مصممة ومختبرة جيدًا.
إذا كانت Detection لم تنتج إشارات مفيدة منذ فترة طويلة، اسأل لماذا:
- هل التهديد الذي تستهدفه ما زال مهمًا؟
- هل البيانات المطلوبة تصل أصلًا؟
- هل Detection أخرى أصبحت تغطي السيناريو بصورة أفضل؟
- هل القاعدة معطلة منطقيًا بسبب تغير Schema أوConfiguration؟
قد تكون النتيجة تعديل القاعدة أو دمجها أوإيقافها. الاحتفاظ بكل Rule تاريخية لمجرد أنها موجودة يزيد تكلفة التشغيل ويجعل تقييم التغطية أكثر صعوبة.
استخدم MITRE ATT&CK لتوجيه Detection لا لملء Matrix
يساعد MITRE ATT&CK على وصف سلوكيات الخصوم وربطها بالبيانات التي قد تسمح بكشفها. وفي بنيته الحالية يوفر المشروع Detection Strategies وAnalytics وData Components يمكن استخدامها لفهم ما الذي يحتاج المدافع إلى مراقبته.
لكن تحويل ATT&CK إلى هدف عددي مثل «نريد تغطية 90% من Techniques» قد يكون مضللًا. ليست جميع التقنيات متساوية في الأهمية لكل مؤسسة، ولا يعني وضع لون أخضر على Technique أن Detection تعمل فعلًا في بيئتك.
الأفضل البدء من سيناريوهات الخطر:
- ما أنواع Initial Access التي تهمنا؟
- كيف يمكن إساءة استخدام حساب إداري؟
- كيف يبدو تعطيل EDR لدينا؟
- ما Telemetry المتاحة لرصد حركة جانبية؟
- كيف سنلاحظ محاولة Exfiltration من الخدمات التي نستخدمها؟
ثم استخدم ATT&CK لتنظيم هذه التغطية واكتشاف الفجوات، لا باعتباره قائمة إلزامية يجب تحويل كل عنصر فيها إلى Alert.
أتمت المهام المتكررة قبل أتمتة القرارات الخطرة
الأتمتة مفيدة جدًا عندما تمنع المحلل من تكرار عمليات Copy/Paste وجمع البيانات الأساسية في كل قضية.
يمكن مثلًا أتمتة:
- Asset lookup.
- جلب معلومات المستخدم وصلاحياته.
- جمع معلومات IP أوDomain.
- إضافة Threat Intelligence context.
- إنشاء Case وتعيين Tags.
- جمع آخر عمليات تسجيل الدخول المرتبطة.
- إرفاق Timeline أوQueries جاهزة للمحلل.
توفر Automation Rules في Microsoft Sentinel مثالًا على هذا النموذج، إذ يمكن استخدامها لتعيين الحوادث وتصنيفها وإضافة مهام للمحللين وتشغيل Playbooks وفق شروط محددة.
لكن هناك فرقًا كبيرًا بين Enrichment وبين Containment.
إضافة معلومات إلى Incident عملية منخفضة الأثر عادةً، بينما تعطيل حساب إداري أوعزل Server حرج أوحظر نطاق تعتمد عليه المؤسسة قد يسبب توقفًا حقيقيًا إذا كان القرار خاطئًا.
صنف إجراءات الأتمتة حسب أثرها
يمكن للمؤسسة إنشاء مستويات مثل:
- منخفض الأثر: enrichment، tags، إنشاء Case، جمع سجلات.
- متوسط الأثر: إجراءات قابلة للعكس على أصول محدودة وفق شروط قوية.
- مرتفع الأثر: تعطيل حسابات حساسة، عزل خوادم حرجة، تغييرات واسعة في الشبكة أوالوصول.
كلما ارتفع أثر الإجراء، ازدادت الحاجة إلى شروط أقوى أوHuman Approval أوآلية Rollback واضحة.
ما دور الذكاء الاصطناعي في تقليل Alert Fatigue؟
يمكن للذكاء الاصطناعي التوليدي مساعدة المحلل في أجزاء من Workflow، مثل تلخيص Incident طويلة، جمع سياق Entities، تفسير Query، اقتراح خطوات تحقيق أوصياغة استعلامات أولية.
لكنه لا يحل مشكلة Detection Pipeline سيئة. إذا كانت البيانات ناقصة أوالتنبيهات غير دقيقة، فإن تلخيصها بسرعة لا يجعلها صحيحة.
كما أن مخرجات النماذج نفسها تحتاج إلى تحقق. توضح وثائق الشفافية الخاصة بـMicrosoft Security Copilot أن المخرجات قد تكون غير دقيقة أوغير مكتملة أوقديمة، وأن جودة النتائج تعتمد على البيانات والتكاملات والسياق المتاح، مع ضرورة استخدام الحكم البشري والتحقق من النتائج المهمة.
لذلك يكون الاستخدام الأفضل للـAI هو تسريع الوصول إلى الأدلة وليس استبدال الأدلة نفسها.
قس جودة Detection بدل عدّ Alerts المغلقة
إذا كان KPI الرئيسي لفريق SOC هو «عدد التنبيهات التي أغلقناها»، فقد يكافئ النظام إنتاج الضوضاء ثم التخلص منها بسرعة.
مقاييس أكثر فائدة قد تشمل:
- عدد Alerts المرتبطة بكل Incident.
- نسبة False Positives المتكررة التي كان يمكن ضبطها.
- الزمن من Detection إلى بدء Triage.
- الوقت البشري الفعلي المستهلك لكل Case.
- عدد القواعد التي لا تملك Owner أواختبارات واضحة.
- نسبة Detections الحرجة التي جرى اختبارها بعد آخر تعديل.
- قدرة الفريق على اكتشاف سيناريوهات الخطر ذات الأولوية.
- الزمن اللازم للوصول إلى قرار يمكن اتخاذ إجراء بناءً عليه.
والهدف ليس جعل عدد Alerts منخفضًا بأي ثمن. منصة تنتج عشرة تنبيهات يوميًا لكنها لا ترى الهجمات المهمة أسوأ من منصة تنتج مئة تنبيه عالي الجودة.
حوّل كل Incident إلى Feedback على منظومة الكشف
بعد إغلاق قضية مهمة، لا ينتهي العمل عند كتابة التقرير. يجب سؤال فريق Detection Engineering:
- ما أول Evidence كان يمكننا رؤيتها؟
- هل ظهر التنبيه في الوقت المناسب؟
- ما البيانات التي افتقدناها؟
- هل ظهرت Alerts لا علاقة لها بالقضية وأبطأت التحقيق؟
- هل كان يمكن ربط الأحداث تلقائيًا؟
- هل Playbook الحالية قابلة للتنفيذ؟
- هل نحتاج Detection جديدة أم تحسين الموجودة؟
هذا يتماشى مع الاتجاه الحديث للاستجابة للحوادث باعتبارها جزءًا مستمرًا من إدارة المخاطر. فقد جعل NIST SP 800-61 Rev. 3 الصادر نهائيًا في أبريل 2025 الاستجابة للحوادث جزءًا متكاملًا مع وظائف NIST Cybersecurity Framework 2.0 بدل التعامل معها كعملية تبدأ فقط بعد وقوع الحادث.
ما الذي يجب أن يطلبه CISO من SOC؟
السؤال غير المفيد هو: كم Alert أغلق الفريق هذا الشهر؟
الأسئلة الأكثر أهمية هي:
- هل نكشف السيناريوهات التي يمكن أن تؤثر فعليًا في المؤسسة؟
- هل تصل Telemetry المطلوبة من أصولنا الحرجة؟
- ما أكثر Detections استهلاكًا لوقت المحللين؟
- ما القواعد التي تنتج False Positives متكررة؟
- كم من وقت الفريق يذهب إلى Enrichment يمكن أتمتته؟
- هل الاستثناءات الحالية تخلق Blind Spots؟
- هل نستطيع تنفيذ إجراءات الاحتواء التي تنص عليها Playbooks؟
- متى اختُبرت أهم قواعد Detection آخر مرة؟
هذه الأسئلة تحول النقاش من حجم النشاط إلى فعالية القدرة الأمنية.
خطة عملية لتقليل Alert Fatigue
- ابدأ بأكثر مصادر الضوضاء: رتب Detection Rules حسب عدد التنبيهات والوقت الذي تستهلكه، لا حسب Severity فقط.
- راجع التحقيقات السابقة: حدد الأنماط المتكررة من False Positives والنشاط المشروع المتوقع.
- أضف السياق: اربط Asset criticality والهوية وExposure بالتنبيه قبل تغيير الأولوية.
- طبّق Correlation: اجمع التنبيهات التي تمثل Incident واحدة عندما يكون الارتباط قابلًا للدفاع عنه.
- اضبط القواعد بدقة: عدّل شروط Detection أوThresholds بدل استخدام Allowlist واسعة.
- اختبر بعد كل تعديل: تأكد أن السيناريو الخبيث الذي تريد اكتشافه ما زال يولد الإشارة المطلوبة.
- أتمت Enrichment: أزل الأعمال اليدوية المتكررة قبل التفكير في Response ذات أثر مرتفع.
- راجع القواعد القديمة: عدّل أوادمج أوأوقف Detections التي لم تعد تحقق هدفًا واضحًا.
- قس النتائج: تابع وقت التحقيق وجودة الإشارة والتغطية، لا عدد Alerts المغلقة فقط.
وماذا إذا لم تستطع المؤسسة تشغيل هذه العملية داخليًا؟
بعض المؤسسات تملك الأدوات لكنها لا تملك عدد الموظفين أوالتخصصات اللازمة لمراقبة البيئة والتحقيق على مدار الساعة. في هذه الحالة قد تكون خدمة Managed Detection and Response — MDR خيارًا تشغيليًا، لكن شراء MDR لا يلغي الحاجة إلى تحديد الأصول المهمة والصلاحيات وآليات التصعيد وما الذي يستطيع المزود فعله عند اكتشاف Incident.
سواء كان SOC داخليًا أوMDR أوفريقًا هجينًا، تبقى المشكلة نفسها: لا قيمة لمراقبة آلاف الإشارات إذا لم تستطع تحويل الإشارة المهمة إلى تحقيق وقرار في الوقت المناسب.
الخلاصة
Alert Fatigue ليست مجرد إرهاق يصيب محللي SOC؛ غالبًا هي علامة على مشكلة في تصميم Detection Pipeline وتشغيلها.
تقليل الضوضاء بصورة آمنة يبدأ من ربط التنبيهات بالسياق، وتجميع الأحداث المرتبطة داخل Incidents، وتحسين القواعد بناءً على نتائج التحقيق، واستخدام استثناءات دقيقة، ومراجعة دورة حياة Detection، ثم أتمتة الأعمال المتكررة منخفضة المخاطر.
الهدف النهائي ليس الوصول إلى أقل عدد ممكن من Alerts، بل إلى أقل قدر ممكن من العمل غير المفيد مع الاحتفاظ بأعلى قدرة ممكنة على اكتشاف السيناريوهات التي تهم المؤسسة فعلًا.