Microsoft Defender XDR Unified Incident View Explained: Correlating Endpoint, Identity, and Email Signals | لما الـ Endpoint والـ Identity والـ Email يحكوا نفس القصة: Unified Incident View في Defender XDR

لما الـ Endpoint والـ Identity والـ Email يحكوا نفس القصة: Unified Incident View في Defender XDR

حكاية إزاي بقيت أشوف الهجوم كقصة واحدة متكاملة، مش عشرين تنبيه متفرق كل واحد فيهم يحكي نص الحقيقة.

---

المقدمة

أول مرة شغلت SOC صغير، كنت بفتح ثلاث بلاتفورمز مختلفة كل يوم الصبح: Defender for Endpoint عشان أشوف الأجهزة، Defender for Identity عشان أتابع الـ Domain Controllers، وDefender for Office 365 عشان أشوف الإيميلات المشبوهة. المشكلة إني كنت بشوف تنبيه هنا وتنبيه هناك، وبقعد أحاول أربطهم ببعض يدوي بالوقت والـ user name، وده وقت ضايع وممكن يفوتني lateral movement حصل بين الإيميل والجهاز والحساب في دقايق.

لما بدأت أستخدم Unified Incident View في Defender XDR بجد، الفرق كان واضح: النظام نفسه بيجمع التنبيهات المرتبطة ببعضها في incident واحد، وبيبني لك Attack Story توضح إزاي الهجوم بدأ من إيميل phishing، وصل لجهاز، وبعدين استخدم identity مسروقة للتحرك جانبيا. ده مش بس توفير وقت، ده فرق بين إنك تمسك الهجوم بدري أو تكتشفه بعد ما يخلص.

💡 المتطلبات: لازم يكون عندك Microsoft Defender XDR مفعل مع على الأقل ورك لود واحد من Defender for Endpoint وDefender for Identity وDefender for Office 365، ورخصة Microsoft 365 E5 أو E5 Security أو ما يعادلها. كمان محتاج صلاحيات Security Reader أو Security Administrator في Defender XDR unified RBAC، وممكن تحتاج Microsoft Graph PowerShell SDK لو هتشتغل بالـ API.

إزاي الـ Correlation Engine بيدمج الإشارات؟

Defender XDR مش بس بيجمع التنبيهات في مكان واحد، هو بيستخدم correlation logic بيقارن بين entities مشتركة زي الـ User Principal Name، Device Name، File Hash، وIP Address عبر كل الورك لودز المتصلة. لما يلاقي تنبيهين أو أكتر بيتشاركوا في entity واحدة على الأقل ضمن نفس النافذة الزمنية، بيجمعهم في incident واحد ويبني منهم Attack Story.

الفكرة إن كل ورك لود بيبعت الأدلة بتاعته:

• Defender for Endpoint: process events, file activity, network connections.
• Defender for Identity: authentication anomalies, lateral movement عبر LDAP وKerberos.
• Defender for Office 365: phishing emails, malicious attachments, URL clicks.
• Microsoft Entra ID Protection: risky sign-ins، impossible travel، leaked credentials.

وكل ده بيتجمع في incident واحد له Severity واحد وClassification واحد، مش كل تنبيه لوحده.

جولة عملية في صفحة الـ Incident الموحدة

1. افتح الـ Incident واقرأ الـ Attack Story الأول

قبل ما تدخل في التفاصيل، بص على الـ Attack Story graph فوق الصفحة. هي بترسملك الأحداث بترتيب زمني وبتوضح إزاي كل entity اتصلت بالتالية.

2. راجع تبويب Assets

هنا هتلاقي كل الـ Devices والـ Users والـ Mailboxes المتأثرة في نفس الحادثة، مع Risk Level لكل واحدة، وده بيساعدك تحدد أولوية الـ containment.

3. اتأكد من Evidence and Response

التبويب ده بيوريك الإجراءات المتاحة زي isolate device، disable user، أو block sender، وكلها ممكن تنفذها من نفس الصفحة بدون ما تروح لكل بورتال لوحده.

4. راجع الـ Alerts المكونة للـ Incident

مهم تفتح كل alert لوحده كمان، عشان تتأكد إن الربط منطقي وإنه مش false correlation، خصوصا لما يكون عدد الـ entities المشتركة قليل.

✅ لو الـ Attack Story طلعت متسلسلة منطقيا (email click، بعدين process execution، بعدين lateral movement)، ده معناه الـ correlation شغال صحيح ومفيش data source ناقصة.

استخدام KQL في Advanced Hunting عشان تتعمق في الربط

لما الـ Incident View مش كافي وعايز تتحقق من كل الأدلة المرتبطة بـ Incident معين، تقدر تستخدم Advanced Hunting بجدولين مهمين: AlertInfo وAlertEvidence، وهما بيحتوا على IncidentId ثابت لكل التنبيهات المجمعة.

AlertInfo
| where Timestamp > ago(30d)
| where Title has "Suspicious"
| join kind=inner AlertEvidence on AlertId
| project Timestamp, IncidentId, AlertId, Title, EntityType, EvidenceRole, FileName, AccountName, DeviceName
| order by IncidentId, Timestamp asc

الكويري ده بيوريك كل الأدلة (Files، Devices، Accounts) المرتبطة بتنبيهات معينة، مجمعة تحت الـ IncidentId بتاعها، وده مفيد جدا لو عايز تصدر تقرير كامل عن كل الـ entities اللي اشتركت في هجوم واحد.

⚠️ خد بالك إن IncidentId بيظهر بس لو الـ workload فعلا متصل ومحدد بـ Defender XDR unified SOC، لو workload زي Defender for Identity مش مفعل كويس، هتلاقي الجدول IdentityLogonEvents موجود بيانات لكن مش مربوط بأي IncidentId.

سحب وتحديث الحوادث برمجيا عبر Microsoft Graph Security API

لو عندك SOAR أو أوتوميشن خارجي، تقدر تستخدم Microsoft Graph Security API عشان تسحب الحوادث أو تحدث حالتها من PowerShell.

Connect-MgGraph -Scopes "SecurityIncident.Read.All","SecurityIncident.ReadWrite.All"

# سحب كل الحوادث النشطة
Get-MgSecurityIncident -Filter "status eq 'active'" |
    Select-Object Id, DisplayName, Severity, Classification, CreatedDateTime

# تحديث حالة incident معين بعد التحقيق
$body = @{
    status = "resolved"
    classification = "truePositive"
    determination = "multiStagedAttack"
}
Update-MgSecurityIncident -SecurityIncidentId "IncidentId-here" -BodyParameter $body

ده بيساعدك تربط الـ Incident lifecycle بأدوات الـ ticketing الداخلية بتاعتك بدون ما تفتح البورتال كل مرة.

مقارنة: Alert فردي مقابل Incident موحد

الخاصية	Alert فردي	Incident موحد
المصدر	Sensor واحد أو workload واحد	عدة workloads مربوطة ببعضها
السرد	حدث معزول بلا سياق	Attack Story كاملة بترتيب زمني
الأتوميشن	إجراء محدود على entity واحدة	إجراءات على مستوى كل الحادثة مرة واحدة
التحقيق	لازم تربط الأدلة يدوي	الربط جاهز، بس محتاج تأكيد منك

مشاكل شائعة وحلولها

المشكلة	الحل
التنبيهات مش بتتجمع في incident واحد رغم إنها مرتبطة منطقيا	اتأكد إن كل الورك لودز (MDE، MDI، MDO، Entra ID Protection) متفعلة ومتصلة بنفس tenant في Defender XDR unified settings
بيانات الـ Identity مش ظاهرة في الـ Attack Story	راجع إن Defender for Identity sensor منصب وشغال على كل الـ Domain Controllers، مش على بعضهم فقط
عدد الـ False Positives كبير وبيبوظ التصنيف	استخدم Custom Detection Rules وضبط الـ exclusions بدل ما تتجاهل التنبيهات كلها
فريق معين مش قادر يشوف كل الإشارات في الـ Incident	راجع Unified RBAC roles وتأكد إن الصلاحيات شاملة الـ workloads المطلوبة، مش Endpoint بس

نصائح الأمان 🔐

• فعّل Unified RBAC في Defender XDR بدل الاعتماد على أدوار كل بورتال لوحده، ده بيمنع confusion في مين يشوف إشارات الـ Identity والـ Email.
• راجع إجراءات Automated Investigation and Response قبل ما تفعل auto-remediation على حوادث فيها identity signals، لأن disable حساب غلط ممكن يوقف عمل فعلي.
• اربط Entra ID Protection risk detections بـ Conditional Access policies عشان الاستجابة تبقى لحظية بدل ما تنتظر التحقيق يخلص.
• راجع Attack Story على مستوى الـ Incident بشكل دوري، مش التنبيهات المنفردة بس، عشان تلاحظ lateral movement بدري.
• خزن بيانات Advanced Hunting لفترة retention كافية، لأن كتير من التحقيقات محتاجة ترجع لأسابيع سابقة تفهم بداية الهجوم.

الخلاصة

Unified Incident View في Defender XDR مش feature زخرفة، هو فعلا بيغير طريقة تفكيرك في التحقيق: بدل ما تلاحق تنبيهات متفرقة، بقيت