الأمن السيبراني وأمن المعلومات

Splunk Enterprise Security: من عملية الكشف حتى التحقيق

7 دقيقة قراءةتاريخ النشر: 5 أغسطس 2026

توضيح بصري احترافي حول تحقيق في حادثة بـ Splunk Enterprise Security في مجال SIEM والكشف

إجابة سريعة

يبدأ التحقيق في حادثة بـ Splunk Enterprise Security بفهم الـ Detection والكيان الذي يشير إليه، ثم يستمر في التحقق من الأحداث المساهمة، وإثراء Asset و-Identity، وبناء Timeline والبحث عن نشاط ذي صلة، وينتهي بـ Disposition، التوثيق والتغذية الراجعة للـ Detection. في إصدارات Splunk ES 8، المصطلحات Finding و-Analyst Queue أكثر شيوعًا؛ في الإصدارات السابقة قد تجد أحيانًا Notable و-Incident Review.

Splunk Enterprise Security — أو Splunk ES — تضيف فوق محرك بحث Splunk طبقة عمليات الأمن: Detections، إثراء الأصول والهويات، إدارة Findings، التحقيقات، المخاطر والاستجابات. تحدي المحلل ليس فقط “فتح تنبيه”، بل فهم المنطق الذي أنشأه، والبيانات التي ساهمت فيه، وما هو النطاق الحقيقي وما الذي ينقص لاتخاذ قرار.

تتغير الواجهة والمصطلحات بين الإصدارات. في Splunk ES 7، يكثر استخدام Notable Event و-Incident Review. في Splunk ES 8، تستخدم Splunk بشكل أكبر Findings، Finding Groups، Analyst Queue و-Mission Control. المبدأ المهني يبقى كما هو: Detection ينتج نتيجة؛ المحلل يتحقق من السياق والأدلة؛ وإذا كان هناك شك حقيقي، تتحول النتيجة إلى تحقيق منظم أو تنضم إليه.

يركز المقال على Risk-Based Alerting — RBA — لأنه يوضح جيدًا الانتقال من تنبيه فردي إلى قصة سلوكية. تستخدم الأمثلة بيانات مختبر ونقاط مخاطر توضيحية فقط. لا ينبغي تفسير Risk score كاستنتاج تلقائي بشأن اختراق.

من Detection إلى Finding أو Notable

تعتمد Detection في Splunk ES عادةً على Correlation Search أو على آلية Detection أحدث وفقًا للإصدار. يقوم البحث بفحص البيانات، ويعيد النتائج ويطلق Response. في سيناريو تقليدي، ينشئ الـ Response Notable أو Finding. في سيناريو RBA، يمكن لـ Detection كتابة Risk event إلى مؤشر المخاطر بدلاً من فتح Case فوري.

يغير هذا الاختيار وحدة العمل. التنبيه التقليدي يقول: “حدث نمط معين الآن”. RBA يقول: “كيان معين أُضيفت إليه عدة مؤشرات بمرور الوقت، وتجاوز تراكمها شرطًا يبرر التحقيق”. وبهذه الطريقة يمكن ربط إشارات ضعيفة — على سبيل المثال، Login غير عادي، تشغيل أداة إدارة، واتصال بهدف جديد — في حالة واحدة ذات سياق أكثر ثراءً.

المكون	سؤال للمحلل	الأدلة المطلوبة
Detection	أي سلوك حاول القانون الكشف عنه؟	اسم القانون، SPL، شروط الوقت، الحقول، MITRE
Finding/Notable	ما الذي عُرض بالضبط على قائمة انتظار المحللين؟	العنوان، الإلحاح، الكيان، الأحداث المساهمة
Risk event	ما هي المخاطر التي أُضيفت وإلى أي كيان؟	risk_object, risk_object_type, risk_score, risk_message
Investigation	ما هو النطاق الذي جُمع بالفعل؟	النتائج ذات الصلة، القطع الأثرية، الملاحظات، خطة الاستجابة

Risk objects و-Risk score

Risk object هو كيان يمكن تجميع المخاطر عليه: مستخدم، نظام، جهاز أو نوع مخصص. الحقلان الأساسيان هما risk_object ونوعه. إذا ظهر نفس المستخدم مرة كـ tair، ومرة كـ tair@company.example، ومرة بصيغة أخرى، فإن عدم التوحيد في التسمية قد يقسم القصة إلى ثلاثة كيانات أو يدمج كيانات غير متطابقة. لذلك، جودة بيانات Asset and Identity هي جزء من Detection، وليست مسألة إدارية جانبية.

Risk score هو وسيلة لتحديد الأولويات. إنه ليس احتمالاً رياضيًا للاختراق وليس بديلاً عن الأدلة. يجب التحقق من الذي أعطى النتيجة، وما هي Risk modifiers، وما إذا كان الحدث متوقعًا في البيئة، وما هي حساسية الأصل، وما هي النافذة الزمنية. القاعدة التي تضيف 80 نقطة لكل إجراء شائع ستخلق “تضخمًا في المخاطر” وتضر بثقة المحللين.

Risk incident rule أو Finding-based detection يمكنها تجميع Risk events بناءً على الكيان، Threat object أو شرط تراكمي. يجب على المحلل فتح الأحداث المساهمة وعدم الاكتفاء بالمجموع. يمكن أن تمثل درجتان متطابقتان قصصًا مختلفة تمامًا: خمس إشارات متوسطة من مصادر مستقلة، أو عشرين تكرارًا لنفس الحدث الصاخب.

فحص Assets و-Identities

يمكن لـ Splunk ES إثراء Findings باستخدام قوائم Asset و-Identity. الإثراء الجيد يضيف الأهمية، المالك، القسم، فئة النظام، التوقعات التشغيلية وبيانات إضافية. قبل التحقيق المتعمق، تحقق مما إذا كان الكيان محددًا بشكل صحيح: هل ينتمي IP إلى VPN، هل الـ Host هو خادم Production، هل المستخدم هو Service account، وهل يوجد تسمية Privileged.

يجب التمييز بين الحقيقة والإثراء. src=203.0.113.10 هي قيمة من الحدث. “VPN Gateway” هو Context يأتي من Lookup. إذا كان الـ Lookup قديمًا، فسيكون القرار خاطئًا أيضًا. وثق مصدر الإثراء وتاريخ التحديث عندما يؤثر على الإغلاق أو التصعيد.

Workflow تحقيق عملي

اقرأ اسم الـ Detection، الوصف، الـ Owner، الـ MITRE mapping والـ Drill-down. صغ في جملة واحدة ما الذي يدعيه القانون.
حدد الـ Entity المركزي والنطاق الزمني. تحقق مما إذا كان User، System أو كيانًا مخصصًا، وما إذا كانت هناك أهمية تجارية.
افتح الأحداث المساهمة. تأكد من وجودها، وأن الحقول صحيحة، وأنه لا يوجد تكرار بسبب Lookback أو Ingestion delay.
أنشئ Timeline زمنيًا. أضف Authentication، Endpoint، Network، DNS، Cloud و-Email وفقًا للسيناريو.
ابحث عن Related findings حول نفس الكيان، نفس الـ IP، Hash، Process أو Threat object. لا تقصر البحث على العنوان الأصلي فقط.
تحقق من التفسيرات المشروعة: نشاط IT مصرح به، Scanner، Automation، تغيير نظام، VPN أو أداة إدارة معروفة.
صنف النتيجة بناءً على الأدلة: True Positive، Benign Positive، False Positive، Duplicate أو حالة وسيطة تتطلب تصعيدًا.
حدث Owner، Status، Urgency/Disposition و-Notes. إذا بدأ تحقيق (Investigation)، أرفق Artifacts، المهام وإجراءات الاستجابة.

سيناريو المختبر: مخاطر تراكمية للمستخدم

لنفترض أنه خلال 40 دقيقة، يتم استقبال أربعة Risk events حول المستخدم lab.user. النقاط أدناه هي مثال فقط. الهدف ليس جمع الأرقام بالعين، بل فهم ما إذا كانت الأحداث مرتبطة بنفس النشاط.

الزمن	الإشارة	مخاطر توضيحية	فحص مركزي
09:02	Login من دولة جديدة	20	VPN, Device, MFA, التاريخ
09:14	PowerShell مع Command line غير عادي	35	Host, Parent process, Script origin
09:21	وصول إلى Share حساس	25	الترخيص، الحجم، الملفات، دور المستخدم
09:37	DNS لنطاق جديد	30	Process البادئ، Reputation، مستخدمون إضافيون

يبدأ التحقيق بـ Drill-down لكل إشارة. إذا جاء الـ Login من VPN مؤسسي وكان الجهاز مُدارًا، فلا يجب الإغلاق فورًا: لا يزال يجب التحقق من PowerShell والـ DNS. إذا تم تشغيل PowerShell بواسطة نظام إدارة معروف، وكان الـ Share متوافقًا مع الدور، وكان النطاق ينتمي إلى تحديث برنامج، فقد يكون Benign Positive. إذا كانت عدة إشارات تتصل بنفس الـ Host وعملية غير معروفة، يجب التصعيد والنظر في Containment وفقًا لـ Playbook معتمد.

الإغلاق والتغذية الراجعة للكشف

يتضمن الإغلاق الجيد ما تم فحصه، وأي الأحداث دعمت القرار، وأي المصادر لم تكن متاحة، وما هو التفسير. في RBA، من المهم الإشارة إلى أي Risk events كانت مفيدة وأي منها أحدث ضوضاء. بهذه الطريقة، يمكن لمهندس الـ Detection تغيير Risk modifiers، إضافة Entity zones، تحسين Normalization أو تحديث شروط Aggregation.

لا تقم بتطبيق Exclusion واسع على مستخدم، Host أو IP فقط لتقليل الـ Volume. فضل Exception محدودة في الوقت والشروط، مع Owner وتاريخ انتهاء الصلاحية. بعد التغيير، قم بتشغيل Regression test على True Positives التاريخية وسيناريوهات المختبر.

قائمة تحقق للمحلل

فهمت ما تدعيه الـ Detection وما لا تثبته.
تحققت من جميع الأحداث المساهمة وليس فقط Score النهائي.
تحققت من Risk object، نوع الكيان وتوحيد الاسم.
تحققت من Asset/Identity enrichment ومصدره.
أنشأت Timeline وبحثت عن Findings ذات صلة.
فصلت الحقائق، الافتراضات والتفسير المشروع.
وثقت Disposition والأدلة بطريقة تمكن محلل آخر من المتابعة.
قدمت تغذية راجعة محددة للـ Detection ولم أنشئ Exclusion شاملًا.

أخطاء شائعة

التعامل مع Risk score كدليل على اختراق.
التحقيق في الحدث صاحب أعلى درجة فقط.
دمج هويات مختلفة أو تقسيم نفس الهوية بسبب Normalization خاطئ.
افتراض أن إثراء Asset صحيح دون التحقق من التحديث.
إغلاق Finding بدون Drill-down للأحداث الخام.
كتابة Notes عامة مثل “تم الفحص وسليم” بدون أدلة.
إجراء Tuning يخفي العرض ولكنه لا يعالج جذر الضوضاء.

الخلاصة و-CTA

خذ Detection واحدًا في مختبر Splunk ES وقم ببناء صفحة تحقيق له: فرضية، Risk object، أحداث مساهمة، Drill-down، مصادر إثراء، شروط إغلاق وتغذية راجعة لـ Tuning. هذا التمرين يربط SPL بطريقة عمل المحلل. في مسار Cybersecurity & AI لـ HPI، يمكن ممارسة نفس الانتقال من السجل الخام إلى تحقيق موثق، باستخدام بيئات مرخصة وبيانات محاكاة فقط.

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

ما الفرق بين Finding و-Notable؟

تعتمد المصطلحات على إصدار Splunk ES ونموذج العمل. في الإصدارات 8.x، تستخدم Splunk بشكل أكبر Finding و-Analyst Queue؛ في الإصدارات 7.x، يكثر استخدام Notable و-Incident Review. من وجهة نظر المحلل، كلاهما نتائج تتطلب Triage.

هل RBA تحل محل Correlation Searches؟

لا. تستخدم RBA منطق Detection وإطار عمل المخاطر لتجميع الإشارات حسب الكيان. يمكن لـ Correlation search أن تنتج Risk event، Finding/Notable أو Responses أخرى وفقًا للتصميم.

كم يعتبر Risk score مرتفعًا؟

لا يوجد رقم عالمي. يجب بناء الـ Threshold بناءً على Baseline، Criticality، جودة المصادر ونوع السلوك. الـ Score هو أداة تحديد أولويات محلية.

متى يتم فتح Investigation؟

عندما يتطلب الأمر نطاقًا واسعًا، تعاونًا بين المحللين، إجراءات استجابة، جمع Artifacts أو متابعة تتجاوز الـ Triage القصير. تحدد سياسة المنظمة العتبة.

ماذا نفعل عندما يظهر نفس الكيان بأسماء متعددة؟

يتم فحص Asset and Identity lookups، normalized risk object، Entity zones وقواعد الدمج. يجب فحص تغيير الـ Normalization للتأكد من عدم دمج أشخاص أو أنظمة مختلفة.