تحقيق في Offense بـ QRadar: كيفية قراءة والتحقيق في Offense

ما الذي ينشئ Offense

القاعدة (Rule) في QRadar هي مجموعة من الاختبارات (Tests) التي يتم تطبيقها على حدث (Event) أو تدفق (Flow) أو سلسلة من الأحداث أو Offense أو أي مزيج آخر وفقًا لنوع القاعدة. عندما تتحقق الشروط، يمكن للاستجابة (Response) إنشاء Offense، أو إضافة بيانات إلى مجموعة مرجعية (Reference set)، أو إرسال إشعار، أو تنفيذ إجراء آخر. اسم القاعدة هو نقطة البداية فقط؛ يجب على المحلل فهم مكدس الاختبار (Test stack) ونطاق البيانات (Scope).

قبل فتح الأحداث الأولية (Raw events)، اسأل: هل هي قاعدة حدث (Event rule) أم قاعدة تدفق (Flow rule)؟ هل يتعلق الأمر بعتبة (Threshold) في نافذة زمنية؟ هل الشرط مرتبط بحالة (Stateful)؟ هل تعتمد القاعدة على كتلة بناء (Building Block) تحدد مجموعة، على سبيل المثال “خوادم البريد” أو “ماسحات الثغرات الأمنية”؟ هل Offense مرتبط بعنوان IP مصدر (Source IP)، أو عنوان IP وجهة (Destination IP)، أو اسم مستخدم (Username)، أو سمة أخرى؟

Magnitude, Relevance, Credibility و Severity

يقيس الـ Magnitude أهمية Offense في البيئة ويستخدم للفرز. تشير الـ Relevance إلى التأثير المحتمل على الشبكة والأصول. تمثل الـ Credibility موثوقية الإشارة وتتأثر، من بين أمور أخرى، بموثوقية مصدر السجل (Log source) والتعزيز من مصادر إضافية. تشير الـ Severity إلى مستوى التهديد بالنسبة لجهوزية الهدف. تعيد QRadar تقييم الـ Magnitude عند إضافة البيانات وفي أوقات محددة.

لا ينبغي تفسير كل درجة على حدة دون فهم البيانات. الـ Credibility العالية من مصدر واحد لا تضمن أن الحدث ضار؛ قد يصنف برنامج تحليل (Parser) معين نشاطًا مشروعًا على أنه فئة خطيرة. الـ Relevance العالية يمكن أن تنبع من أصل حرج، ولكن إذا كان الهدف هو مصيدة عسل (Honeypot) أو مختبر (Lab)، فإن السياق يختلف. الـ Severity العالية يمكن أن تكون مبررة من حيث نوع الحدث، حتى لو تم حظر الإجراء.

الأحداث (Events) والتدفقات (Flows): عدستان

يصف الحدث (Event) عادةً سجلًا: مصادقة (Authentication)، رفض جدار حماية (Firewall deny)، عملية (Process)، تدقيق (Audit)، أو حدث تطبيقي. يصف التدفق (Flow) محادثة أو اتصال شبكة: مصدر، وجهة، منافذ (Ports)، بروتوكول (Protocol)، بايتات (Bytes)، حزم (Packets)، وأوقات. يمكن أن يتضمن Offense أحدهما أو كليهما. يتيح ربط الحدث بالتدفق التحقق ليس فقط من “ما أبلغ عنه المنتج”، ولكن أيضًا “هل حدثت حركة المرور وما هو حجمها”.

في التحقيق، افتح قائمة الأحداث، وقم بالفرز حسب الوقت والفئة، وتحقق من QID، ومصدر السجل (Log Source)، واسم المستخدم (Username)، والحمولة (Payload)، والحقول المخصصة. ثم انتقل إلى التدفقات (Flows): هل اتصل المصدر بالوجهة؟ هل كان هناك اتصال ثنائي الاتجاه؟ ما هو حجم البيانات؟ هل يتوافق المنفذ مع الخدمة المتوقعة؟ عدم وجود تدفق لا يثبت عدم وجود اتصال؛ قد لا يكون هناك تغطية NetFlow في ذلك القطاع (Segment).

المصدر (Source)، الوجهة (Destination)، والأصول (Assets)

تربط QRadar الـ Offense بـ “مصدر الـ Offense” الذي تحدده القاعدة والأحداث. أحيانًا يكون المصدر عنوانًا خارجيًا، وأحيانًا مستخدمًا، أو مضيفًا داخليًا، أو وجهة. لا تفترض أن حقل المصدر هو دائمًا المهاجم. في مثال استدعاء البرمجيات الخبيثة (Malware callback)، قد يكون المصدر الداخلي محطة عمل مخترقة؛ في مثال المسح (Scan)، قد يكون المصدر ماسحًا ضوئيًا تنظيميًا مصرحًا به.

يغير سياق الأصل (Asset context) تحديد الأولويات: خادم Domain Controller، ومحطة عمل إدارية، وخادم اختبار ليست متطابقة. تحقق من وزن الأصل (Asset weight)، والمالك (Owner)، وتسلسل الشبكة الهرمي (Network hierarchy)، والثغرات الأمنية (Vulnerabilities)، والعلاقات التجارية. إذا لم تتعرف QRadar على الأصل أو تعرفت عليه باسم قديم، فاذكر ذلك كنقص في الأدلة.

سير عمل التحقيق في Offense

1. اقرأ الوصف (Description)، والقواعد (Rule(s))، ونوع الـ Offense (Offense type)، والمصدر (Source)، والوجهة (Destination)، والـ Magnitude، ووقت البدء (Start time)، وآخر حدث (Last event).
2. افتح القاعدة (Rule) أو تفاصيل القاعدة وافهم الاختبارات (Tests)، والعتبة (Threshold)، والنافذة الزمنية، وكتل البناء (Building Blocks).
3. راجع الأحداث المساهمة. قم بتجميعها حسب QID، ومصدر السجل (Log Source)، واسم المستخدم (Username)، والمصدر (Source)، والوجهة (Destination) لتحديد التكرار والازدواجية.
4. تحقق من التدفقات ذات الصلة، إن وجدت، وابحث عن الاتصالات قبل وبعد الحدث الرئيسي.
5. تحقق من التسلسل الهرمي للشبكة (Network hierarchy) وملف تعريف الأصل (Asset profile). اسأل ما إذا كانت العناوين داخلية، أو VPN، أو NAT، أو Proxy، أو بنية تحتية مشتركة (Shared infrastructure).
6. قم بإنشاء جدول زمني (Timeline) وبحث إضافي في نشاط السجل (Log Activity) ونشاط الشبكة (Network Activity) لنطاق أوسع.
7. تحقق من الـ Offenses الإضافية على نفس الأصول، والمستخدمين، والنطاقات (Domains)، أو القواعد (Rules). يمكن أن يوسع الارتباط بين الحالات النطاق (Scope).
8. صنف (Classify)، وثق الملاحظات (Notes)، وخصص مالكًا (Owner)، وقرر ما إذا كنت سترفع الأمر (Escalate)، أو تغلق (Close)، أو تتركه قيد المراقبة (Monitor).

سيناريو: عدة مصادر مقابل هدف حرج

في المختبر، تم إنشاء Offense باسم “فشل مصادقة متعددة تبعها نجاح” (Multiple authentication failures followed by success) على خادم ملفات حرج. الـ Magnitude هو 8، وهناك 180 حدثًا من ثلاثة مصادر سجلات (Log Sources)، ومصدر الـ Offense هو IP داخلي. يمكن أن تبدو طاولة العمل كالتالي:

إذا كان المصدر خادم إدارة وتتطابق الإخفاقات مع مهمة (Job) فشلت بعد تغيير كلمة المرور، فقد يكون إيجابيًا حميدًا (Benign Positive). لكن النجاح الذي يتبعه SMB إلى مشاركة حساسة لا يزال يتطلب التحقق من الحساب والعملية. إذا لم يكن هناك تغيير معتمد، يجب تصعيد الأمر إلى فريق الاستجابة للحوادث (IR) أو فريق الهوية وفقًا لخطة العمل (Playbook).

الإغلاق (Closing)، الملاحظات (Notes)، والضبط (Tuning)

يجب أن تتضمن الملاحظات فرضية، وأدلة، وعمليات البحث التي أجريت، والنواقص، والتصنيف (Classification)، والإجراءات. يجب أن يكون سبب الإغلاق (Closing Reason) متسقًا للسماح بالمقاييس (Metrics) والضبط (Tuning). “إيجابي كاذب” (False Positive) بدون تفسير غير كافٍ؛ اذكر ما إذا كان السبب هو ماسح ضوئي مصرح به، أو محلل (Parser) خاطئ، أو عتبة (Threshold)، أو تكرار (Duplicate)، أو سياق أصل (Asset context)، أو نشاط مستخدم مشروع.

يمكن أن يتضمن الضبط (Tuning) تغيير القاعدة (Rule)، أو كتلة البناء (Building Block)، أو مجموعة المراجع (Reference set)، أو التسلسل الهرمي للشبكة (Network hierarchy)، أو مصداقية مصدر السجل (Log source credibility)، أو وزن الأصل (Asset weight). يجب أن يكون لكل تغيير مالك (Owner)، وتوثيق (Documentation)، واختبار تراجع (Regression test)، وتاريخ مراجعة (Review Date). لا تستبعد عنوان IP مصدرًا كاملاً إذا كان يمكن استبعاد اسم الحدث (Event name)، أو الوجهة (Destination)، أو نافذة الصيانة (Maintenance window)، أو حساب الخدمة (Service account) فقط.

قائمة التحقق (Checklist)

• ✓فهمت ما الذي أنشأ الـ Offense وما هي القواعد التي ساهمت.
• ✓فككت الـ Magnitude إلى مكوناته السياقية ولم أستخدمه كدليل.
• ✓تحققت من الأحداث (Events) والتدفقات (Flows) عند وجودها.
• ✓تحققت من المصدر (Source)، والوجهة (Destination)، و NAT، و Proxy، والتسلسل الهرمي للشبكة (Network hierarchy).
• ✓تحققت من حرجية الأصل (Asset criticality) والثغرات الأمنية (Vulnerabilities).
• ✓قمت بإنشاء جدول زمني (Timeline) وبحثت عن النشاط قبل وبعد.
• ✓كتبت ملاحظات (Notes) مفصلة وسبب إغلاق (Closing Reason).
• ✓نفذت ضبطًا (Tuning) مركزًا مع مالك (Owner) وتاريخ مراجعة (Review date).

أخطاء شائعة

• الإغلاق بناءً على Magnitude منخفض دون فتح الأحداث.
• افتراض أن مصدر Offense هو المهاجم.
• عدّ الأحداث دون التحقق من التكرارات أو التجميع (Aggregation).
• تجاهل التدفقات (Flows) أو عدم وجود تغطية لحركة المرور.
• الاعتماد على ملف تعريف أصل (Asset profile) غير محدث.
• تغيير القاعدة (Rule) في الإنتاج بدون خط أساس (Baseline) واختبار تراجع (Regression test).

الخلاصة و CTA

اختر Offense مختبريًا واكتب صفحة تحقيق من صفحة واحدة: ما الذي أنشأه، وماذا يعني الـ Magnitude، وما هي الأحداث والتدفقات المساهمة، ومن هو المصدر والوجهة، وما هو سياق الأصل (Asset context)، وما هو قرار الإغلاق. ثم قارن الصفحة بتذكرة محلل آخر. يعلم هذا التمرين كيفية العمل مع QRadar كساحة تحقيق وليس مجرد قائمة تنبيهات.

الأسئلة الشائعة