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

Microsoft Sentinel: دليل التحقيق في الحوادث لمحلل مبتدئ

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

توضيح بصري احترافي حول التحقيق في الحوادث في Microsoft Sentinel في مجال SIEM والكشف

إجابة سريعة

يبدأ التحقيق في الحوادث في Microsoft Sentinel بفهم سياق الحالة: أي التنبيهات تم تجميعها، من هي الكيانات، ما هي درجة الخطورة، وما هو مصدر الكشف. بعد ذلك، يقوم المحلل بالتحقق من المستخدمين والأصول، وفحص الأدلة والجدول الزمني، وتشغيل KQL تكميلي، وتوثيق القرارات، والتصعيد أو الاستجابة. الحادث هو ملف عمل – وليس دليلاً على نجاح الهجوم – وبالتالي يجب أن يعتمد التصنيف على الأدلة والسياق.

يركز Microsoft Sentinel على الكشف والتحقيق والاستجابة للحوادث. يمكن أن ينشأ الحادث من قاعدة تحليلات، أو من تنبيه مستورد من منتج آخر، أو من تجميع عدة تنبيهات مرتبطة بنفس النشاط. ويرث خصائص مثل الخطورة، الحالة، تكتيكات MITRE ATT&CK، والكيانات المحددة في التنبيهات.

توفر الشاشة الكثير من المعلومات، لكن التحقيق الجيد ليس انتقالاً تلقائياً بين علامات التبويب. يجب على المحلل تحديد سؤال تحقيق، وتحديد ما هو معروف وما هو مفقود، واستخدام أدوات الواجهة لجمع الأدلة. هذا الدليل مناسب لبيانات المختبر أو بيئة تنظيمية حيث يوجد إذن.

تقوم Microsoft بدمج تجربة SOC داخل بوابة Microsoft Defender. وفقًا للوثائق الحالية، من المتوقع أن ينتهي دعم Sentinel عبر بوابة Azure بعد 31 مارس 2027، لذلك من الأفضل تعلم سير العمل الأساسي والتعرف على بوابة Defender بدلاً من الاعتماد على موقع زر ثابت.

قبل التحقيق: تحضيرات أساسية

يحتاج المحلل إلى صلاحيات مناسبة للعرض، التعيين، وتعديل Incident. تشير Microsoft إلى Sentinel Responder كأحد الأدوار المطلوبة للتحقيق. يجب أن تعمل الصلاحيات وفقًا لمبدأ Least privilege، وفي منظمة حقيقية من المهم الفصل بين عرض البيانات الحساسة وإجراءات الاستجابة مثل عزل الأصول أو تعطيل المستخدم.

تأكد من أن Incident يتضمن Entities مفيدة. Entity mapping في Analytics rule يسمح للنظام بتحديد Account, Host, IP, URL, File أو Process. بدون Mapping، سيكون التحقيق الرسومي والروابط إلى السياق محدودة. بالإضافة إلى ذلك، تحقق من أن Data connectors سليمة وأنه لا يوجد Ingestion delay كبير.

قبل فتح Incident، حدد SLA أو Triage target, Owner ومعايير التصعيد. Incident بدون Owner قد ينتظر حتى عندما تكون Severity عالية.

الخطوة 1: قراءة قائمة انتظار الحوادث

في قائمة انتظار الحوادث، يتم تحديد الأولويات الأولية. لا تكتفِ بـ Severity. تحقق من Created time, Last activity, Product, Tactics, عدد Alerts, Entities, Owner و Status. اربط هذا بأهمية الأصل وهوية المستخدم. قد يحصل حدث متوسط (Medium) في حساب Privileged على أولوية أعلى من حدث عالي (High) في أصل معزول في المختبر.

السؤال الأولي	ماذا أتحقق	لماذا يهم
ماذا حدث؟	العنوان، موفرو التنبيهات، التكتيكات، الوصف	يحدد فرضية أولية
لمن حدث ذلك؟	الحساب، المضيف، عنوان IP، مورد سحابي	يحدد النطاق والأهمية
متى؟	النشاط الأول/الأخير، وقت الإنشاء	يحدد نافذة التحقيق
هل لا يزال نشطاً؟	تنبيهات جديدة، جلسات، نشاط الشبكة	يؤثر على الإلحاح والاحتواء
من يعالج؟	المالك، الحالة، المهام	يمنع الازدواجية والانتظار

الخطوة 2: فتح الحادث وفهم القصة

اقرأ الملخص وقائمة التنبيهات. قد تكون عدة تنبيهات ناتجة عن نفس القاعدة أو منتجات مختلفة. تحقق مما إذا كان تجميع التنبيهات قد جمع نشاطًا منطقيًا أو أنشأ حادثًا واسعًا جدًا. انتبه إلى Time range: قد يوسع التنبيه المتأخر Incident ويخفي بداية النشاط.

افتح كل تنبيه رئيسي واقرأ Detection source, Description, Query أو Evidence, Threshold و Entities. اسأل: ما هو الشرط الذي تم تشغيله بالفعل؟ هل يعتمد على مؤشر، شذوذ، سلوك، أو Correlation؟ ما هو مستوى اليقين؟ ما هي البيانات التي لم يتم فحصها؟

تجنب تحيز العنوان. التنبيه المسمى “Compromised account” لا يزال يتطلب التحقق. الاسم الدرامي ليس دليلاً.

الخطوة 3: الكيانات والعلاقات

الكيانات هي مرتكزات التحقيق. ابدأ بالحساب المركزي، المضيف أو IP وتحقق من Insights: النشاط السابق، التنبيهات الإضافية، العضوية في المجموعات، Sign-ins، Related hosts، و Threat intelligence. لا تعتمد على الرسم البياني فقط؛ فهو يعرض العلاقات التي تمكن النظام من رسمها، وليس كل الواقع.

لكل Entity، قم بإنشاء بطاقة تحقيق قصيرة: معرف، نوع، مالك، أهمية، Last known good، نشاط غير طبيعي، ومصادر بيانات. عندما توجد أسماء متشابهة، تأكد من أنك تتبع Object ID أو SID وليس فقط Display name.

أسئلة لحساب المستخدم

هل الحساب Privileged أم Service account؟
هل تم تفعيل MFA وماذا كانت نتيجة التحقق؟
هل الـ IP والجهاز والبلد معروفة؟
هل توجد إخفاقات، إعادة تعيين، موافقات، أو تغييرات في الصلاحيات؟
هل يؤكد المستخدم النشاط عبر قناة اتصال موثوقة؟

أسئلة للمضيف (Host)

هل المحطة مُدارة ومحدثة؟
ما هي شجرة العمليات وهل سطر الأوامر (Command line) غير طبيعي؟
هل توجد اتصالات، ملفات، أو مؤشرات استمرارية؟
هل يدعم تنبيه إضافي من EDR أو مستشعر الشبكة القصة؟
هل سيؤثر عزل المحطة على خدمة حاسمة؟

الخطوة 4: الأدلة والجدول الزمني

تجمع Evidence النتائج التي ربطها النظام بـ Incident. تحقق من المصدر، الوقت، والقيمة. ميز بين Raw event, Alert evidence و Enrichment. المؤشر الذي يظهر في Threat Intelligence لا يكفي إذا لم يتم العثور على صلة بنشاط الأصل.

ينظم Timeline التنبيهات، الإشارات المرجعية، والإجراءات. استخدمه لتحديد البداية، التوسع، والاستجابة، ولكن قم أيضًا بإنشاء Timeline الخاص بك عندما تكون هناك مصادر خارج Sentinel. قم بتطبيع UTC، ووثق Event time مقابل Ingestion time، وحدد الفجوات.

يمكن أن تضمن Tasks أن المحلل يتحقق من الخطوات المطلوبة: التحقق من المستخدم، البحث عن Sign-ins، فحص Host، التواصل مع IT، وإضافة Classification. Task completed لا يعني أن النتيجة صحيحة؛ يجب أن تتضمن التذكرة ما تم فحصه وما تم العثور عليه.

الخطوة 5: بحث تكميلي في السجلات

توفر واجهة Incident السياق، ولكن Query التكميلية في Logs هي عادةً جوهر التحقيق. ابدأ بـ Entity ونافذة زمنية، ووسع قليلاً قبل وبعد النشاط، وابحث عن الأحداث الداعمة أو المتناقضة.

let TargetUser = "student@contoso.example";
let StartTime = datetime(2026-08-01 08:30:00);
let EndTime = datetime(2026-08-01 10:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated asc

بعد Authentication، تحقق من Audit, Endpoint, DNS أو Cloud activity وفقًا للقصة. لا تتوسع إلى جميع الجداول بدون هدف. يجب أن تجيب كل Query على سؤال: هل كان هناك نجاح؟ هل تم إنشاء Session؟ هل تم إجراء تغيير في الصلاحيات؟ هل أنشأت المحطة Process أو Connection غير طبيعي؟

سيناريو: مستخدم وعنوان IP مشبوهان

يتضمن Incident تنبيهاً حول Sign-in من بلد جديد وتنبيهًا آخر حول قاعدة صندوق وارد تم إنشاؤها.
تحدد Triage أن المستخدم يعمل في الشؤون المالية وأن النشاط بدأ خارج ساعات العمل العادية.
في Entities يتم فحص IP, Account والتطبيق. IP ليس VPN معروف، والحساب لا يفترض أن يعمل من البلد المحدد.
تعرض KQL عدة إخفاقات، نجاحًا مع MFA method غير عادي وتغيير Mailbox بعد ذلك.
يقوم المحلل بفحص Audit logs, Sessions, OAuth consents ونشاط مستخدم إضافي. يتصل بالمستخدم عبر قناة موثقة.
بعد التأكد من أن النشاط ليس له، يتم تصنيف الحدث على أنه True Positive ويتم تصعيده إلى IR. يتم تنفيذ إجراءات Containment وفقًا لـ Playbook والترخيص.
توثق التذكرة Timeline, Queries, Evidence, الإجراءات، المالك والتوصيات لتحسين Detection.

التصنيف، الاستجابة، والإغلاق

يجب أن يميز Classification بين True Positive, False Positive و Benign Positive، وفقًا للنموذج التنظيمي. أضف Reason و Comment يشرحان الأدلة. الإغلاق بدون تبرير يضر بـ Tuning والمقاييس.

إذا كانت هناك حاجة إلى استجابة، قم بتنفيذها وفقًا لـ Playbook: إلغاء Sessions, إعادة تعيين credentials, عزل Endpoint, حظر Indicator, حفظ الأدلة أو التواصل مع الفرق. تتطلب الإجراءات غير القابلة للإلغاء أو ذات التأثير التجاري موافقة مناسبة.

قبل الإغلاق، تأكد من فحص Scope، وأن النشاط لا يزال مستمرًا، وأن جميع Tasks قد اكتملت، وأن الدروس المستفادة قد تم نقلها إلى Detection owner، وأن الإجراءات قد تم فتحها لإصلاح Root cause.

قائمة مراجعة التحقيق

تم تحديد Owner و Priority.
تم قراءة منطق كل Alert وليس فقط العنوان.
تم التحقق من Accounts, Hosts و IPs باستخدام معرفات مستقرة.
تم فحص Evidence و Timeline مع مناطق زمنية صحيحة.
تم إجراء Queries تكميلية مقابل المصادر ذات الصلة.
تم الفصل بين الحقائق والافتراضات والتفسير.
تم تحديث Classification و Severity مع تبرير.
تم توثيق إجراءات الاستجابة بالوقت والمنفذ.
تم إنشاء مهام متابعة لـ Tuning أو Hardening.

أخطاء شائعة

الافتراض بأن جميع التنبيهات في Incident تنتمي إلى نفس الهجوم.
الاعتماد على Investigation graph دون فحص Raw logs.
تجاهل Ingestion delay أو مصدر بيانات مفقود.
إغلاق False Positive فقط لأن المستخدم معروف.
إجراء عمليات بحث واسعة النطاق بدون سؤال تحقيق.
تنفيذ Containment كبير دون فهم التأثير التجاري.
إغلاق Incident دون تقديم ملاحظات إلى Rule owner.

ملخص و CTA

أنشئ في المختبر Incident وهميًا يتضمن Account, IP وتنبيهين. اكتب خمسة أسئلة تحقيق، Query واحدة لكل سؤال و Timeline قصير. الهدف ليس الضغط على جميع الخيارات في الواجهة، بل إظهار كيف يغير كل إجراء القرار. بعد ذلك، انتقل إلى مقال Analytics Rule لفهم كيف يبدأ Incident عالي الجودة بـ Detection يمكن التحقيق فيه.