القائمة الرئيسية

الصفحات

تعديل المشاركة

الفيديو #8: كيف تقيس نجاح وقوة فريق الـ SOC؟ | شرح SOC Metrics and Objectives #8

Task 1 (Introduction)

📌 الفكرة: كيف نقيس النجاح؟ (Measuring Success)

  • السؤال: كيف نعرف إن فريق الـ SOC شاطر وفعّال؟
  • الجواب: باستخدام مؤشرات ومقاييس رقمية. مثلما نقيس سرعة السيارة بالكيلومتر/ساعة، نقيس سرعة الـ SOC بمصطلحات مثل MTTD و MTTR.
  • الهدف: تحسين هذه الأرقام يعني اكتشاف الهكر أسرع وإيقافه قبل أن يدمر الشركة. تجاهلها يعني كوارث!

🎯 أهداف التعلم (Learning Objectives)

في هذه الغرفة، سنتعلم لغة الأرقام في الـ SOC:

  1. المصطلحات الأربعة الكبار: فهم معاني SLA, MTTD, MTTA, MTTR. (هذه أهم شيء في الغرفة).
  2. معدل الخطأ (False Positive Rate): فهم أهمية تقليل الإنذارات الكاذبة.
  3. التحسين (Improvement): كيف تساهم أنت (كمحلل L1) في تحسين هذه الأرقام.
  4. تطبيق عملي: إدارة مقاييس فريق SOC في سيناريو تدريبي.

📚 المتطلبات (Prerequisites)

يفضل أن تكون قد أنهيت غرفة SOC Workbooks and Lookups وتعرف الفرق بين الـ SOC الداخلي والـ Managed SOC.

Task 2: Core Metrics (المقاييس الأساسية)

🔢 1. عدد التنبيهات (Alerts Count - AC)

  • المعنى: كم تنبيه وصل للفريق اليوم؟
  • المشكلة:
    • عدد كبير جداً (80): ضغط هائل، واحتمال كبير نضيع التهديد الحقيقي وسط الزحمة.
    • عدد قليل جداً (0): مريب! قد يعني أن النظام عطلان أو لا يرى شيئاً.
  • الرقم المثالي: 5 إلى 30 تنبيه يومياً لكل محلل L1.

🚫 2. معدل الإيجابية الكاذبة (False Positive Rate - FPR)

  • المعنى: كم نسبة التنبيهات التي طلعت "كذب" (ضجيج) من المجموع الكلي؟
  • المشكلة:
    • إذا كانت 94% من التنبيهات كاذبة، المحلل سيصاب بالملل ويصير يغلق التنبيهات بدون تركيز (وهذا خطير جداً).
  • الهدف: تقليل هذا الرقم قدر الإمكان (عن طريق تحسين قواعد الكشف - Tuning). نسبة 80% وأكثر تعتبر مشكلة خطيرة.

📈 3. معدل التصعيد (Alert Escalation Rate - AER)

  • المعنى: كم نسبة التنبيهات التي يرفعها الـ L1 إلى الـ L2؟
  • ماذا يقيس؟ خبرة واستقلالية المحلل المبتدئ (L1).
    • إذا كان يرفع كل شيء ← قليل الخبرة أو خائف.
    • إذا كان لا يرفع شيئاً ← متهور أو واثق زيادة.
  • الرقم المثالي: يجب أن يكون أقل من 50%، والأفضل أقل من 20%. (يعني تحل معظم المشاكل بنفسك).

🛡️ 4. معدل كشف التهديدات (Threat Detection Rate - TDR)

  • المعنى: من أصل كل الهجمات التي حدثت، كم هجوم اكتشفنا؟
  • المثال: 6 هجمات حدثت، اكتشفنا 4 وفوتنا 2. النسبة = 67%.
  • المشكلة: هذه النسبة سيئة جداً!
  • الهدف: يجب أن يكون دائماً 100%. لأن هجوماً واحداً تفوته قد يدمر الشركة (Ransomware).

Task 3: Triage Metrics (مقاييس الفرز والاستجابة)

📜 ما هو الـ SLA؟

هو Service Level Agreement (اتفاقية مستوى الخدمة).

  • ببساطة، هو "عقد" أو "وعد" بين فريق الـ SOC والشركة.
  • الوعد: "نحن نعدكم أننا سنكتشف الهجوم ونبدأ العمل عليه ونحله خلال وقت محدد (مثلاً ساعة واحدة)".

⏱️ مقاييس الوقت الثلاثة (The Big 3 Metrics)

انظر للصورة التالية، فهي تلخص دورة حياة الهجوم وعلاقتها بالوقت:

☝️ شرح المخطط الزمني (من اليسار لليمين):

  1. MTTD (Mean Time to Detect) - متوسط وقت الكشف:
    • المعنى: الوقت بين "لحظة وقوع الهجوم" ولحظة "ظهور التنبيه" في النظام.
    • المثال: الهكر دخل الساعة 10:00، النظام أرسل تنبيهاً الساعة 10:05. الـ MTTD هو 5 دقائق.
  2. MTTA (Mean Time to Acknowledge) - متوسط وقت الاستلام:
    • المعنى: الوقت بين "ظهور التنبيه" ولحظة "بدء المحلل (أنت) بالعمل عليه".
    • المثال: التنبيه ظهر 10:05، أنت فتحته وغيرت حالته لـ "In Progress" الساعة 10:10. الـ MTTA هو 5 دقائق. (هذا يقيس سرعتك أنت!).
  3. MTTR (Mean Time to Respond) - متوسط وقت الاستجابة/الإصلاح:
    • المعنى: الوقت الكلي حتى يتم "إيقاف الهجوم" تماماً (عزل الجهاز، طرد الهكر).
    • المثال: بدأنا 10:10، وتم طرد الهكر 10:30. العملية أخذت 20 دقيقة. الـ MTTR الكلي (من لحظة التنبيه للحماية) هو 25 دقيقة.

📊 الجدول المرجعي (Common SLA Targets)

في الشركات المحترفة، هذه هي الأرقام التي يطمحون لها:

المقياس الهدف المثالي (SLA) الوصف
MTTD < 5 دقائق أدوات الحماية لازم تكون سريعة جداً في كشف الهكر.
MTTA < 10 دقائق لازم المحلل ينتبه للتنبيه ويبدأ الشغل خلال 10 دقايق.
MTTR < 60 دقيقة لازم المصيبة تنحل بالكامل خلال ساعة واحدة.

Task 4: Improving Metrics (تحسين المقاييس)

🛠️ كيف تصلح الأرقام السيئة؟

إليك أبرز 4 مشاكل قد تواجه فريقك وكيف تقترح حلولاً لها:

1️⃣ مشكلة: الضجيج العالي (False Positive Rate > 80%)

  • السبب: الفريق يغرق في تنبيهات تافهة وكاذبة.
  • الحل:
    1. استثناء النشاطات الموثوقة: اطلب تعديل قواعد الكشف لتتجاهل أشياء مثل "تحديثات النظام" الموثوقة.
    2. الأتمتة (SOAR): استخدم أدوات للرد الآلي على التنبيهات المتكررة والسهلة.
      (SOAR: اختصار لـ "Security Orchestration, Automation, and Response". وهو حلٌّ يُساعد المؤسسات على تبسيط عملياتها الأمنية وأتمتتها).

2️⃣ مشكلة: بطء الكشف (MTTD > 30 min)

  • السبب: الهجوم يحدث، والنظام يكتشفه متأخراً جداً.
  • الحل:
    1. تسريع القواعد: اطلب من مهندسي الـ SOC جعل قواعد الكشف تعمل بشكل متكرر أكثر (كل دقيقة بدل كل 30 دقيقة).
    2. الـ Real-time Logs: تأكد أن السجلات تصل للـ SIEM فوراً بدون تأخير في الشبكة.

3️⃣ مشكلة: بطء الاستجابة (MTTA > 30 min)

  • السبب: التنبيه يظهر، لكن المحللين (أنت وزملاؤك) يتأخرون في فتحه.
  • الحل:
    1. تنبيهات فورية: تأكد أن التنبيه يصلك كإشعار (Notification) فوراً.
    2. توزيع العمل: وزع التنبيهات بالتساوي بين المحللين في الشفت لكي لا ينضغط أحد ويتأخر.

4️⃣ مشكلة: بطء الحل (MTTR > 4 hours)

  • السبب: الفريق يأخذ وقتاً طويلاً جداً لإيقاف الهجوم.
  • الحل:
    1. سرعة التصعيد: كـ L1، لا تضيع وقتاً، صعد التهديدات الحقيقية للـ L2 بأقصى سرعة.
    2. التوثيق (Playbooks): تأكد أن لديكم خططاً مكتوبة (Workbooks) جاهزة لكل سيناريو لعدم التفكير طويلاً وقت الأزمة.

Task 5: Practice Scenarios (سيناريوهات عملية)

🎮 طريقة اللعب

اضغط على زر View Site لفتح اللوحة. سترى سيناريو (رسالة شكوى أو تقرير). عليك ملء 3 خانات:

  1. Problematic Metric: ما هو المقياس السيئ هنا؟ (MTTD, MTTR, FPR...؟).
  2. Improvement Task: ما هو الحل؟ (أتمتة، تدريب، تحسين قواعد...).
  3. Assign Task To: من ينفذ الحل؟ (Engineer, L2, Manager...).

🛠️ دليل الحلول (Cheat Sheet)

استخدم هذا الدليل لتجاوز السيناريوهات الثلاثة:

1️⃣ السيناريو الأول: "تأخرنا في طرد الهكر 6 ساعات!"

  • المشكلة: الرسالة تقول "استغرق الأمر 6 ساعات لطرد الهكر".
  • المقياس السيئ: MTTR (Mean Time to Respond). (لأن الاستجابة كانت بطيئة جداً).
  • الحل: Create a workbook explaining credential rotation. (عمل دليل إرشادي لتسريع عملية تغيير الباسوردات).
  • المسؤول: Assign to the L2 that handled the incident. (الـ L2 هو من يكتب الأدلة).

2️⃣ السيناريو الثاني: "الفريق غارق في تنبيهات تافهة"

  • المشكلة: الرسالة تقول "المحللون يشتكون من كثرة التنبيهات الكاذبة والضجيج".
  • المقياس السيئ: False Positive Rate.
  • الحل: Tune detection rules to exclude safe activities. (تعديل القواعد لاستثناء الأنشطة الآمنة).
  • المسؤول: Assign to SOC Engineer. (المهندس هو المسؤول عن ضبط الأدوات).

3️⃣ السيناريو الثالث: "اكتشفنا الهجوم بعد أسبوع!"

  • المشكلة: الرسالة تقول "الهجوم حدث يوم الاثنين واكتشفناه يوم الجمعة!".
  • المقياس السيئ: MTTD (Mean Time to Detect). (وقت الكشف طويل جداً).
  • الحل: Check log collection latency and detection frequency. (التأكد من سرعة وصول السجلات).
  • المسؤول: Assign to SOC Engineer.

أخر المواضيع من قسم : SOC L1