التحقيق في حادثة أمنية في Azure: Sentinel، Entra و Defender

تحديد نطاق Tenant/Subscription

تُبنى عملية التحقيق في حادثة أمنية في Azure من مراحل مع نقاط توقف. نحدد هدفًا، نطاقًا، مصادر، إجراءات مسموح بها، أدلة مطلوبة، أصحاب أدوار، ومعيار إنهاء. في البيئات الهجومية، نضيف شروط إيقاف وقناة طوارئ.

في كل مرحلة، يجب أن يكون هناك مخرجات واضحة: خريطة أصول، جدول زمني، نتيجة، قاعدة، Playbook أو تقرير. لا يتم الانتقال إلى المرحلة التالية إلا عندما تكون المخرجات كافية وموثوقة؛ وهذا يمنع العمل العشوائي أو توسيع النطاق دون موافقة.

Entra و Identity

موضوع 'Entra و Identity' هو جزء أساسي من العمل على التحقيق في حادثة أمنية في Azure. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار المراد اتخاذه، وما هي الأدلة الكافية لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود وخطوات المتابعة.

Activity logs والموارد

موضوع 'Activity logs والموارد' هو جزء أساسي من العمل على التحقيق في حادثة أمنية في Azure. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار المراد اتخاذه، وما هي الأدلة الكافية لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود وخطوات المتابعة.

Defender و Sentinel

موضوع 'Defender و Sentinel' هو جزء أساسي من العمل على التحقيق في حادثة أمنية في Azure. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار المراد اتخاذه، وما هي الأدلة الكافية لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود وخطوات المتابعة.

Containment, Recovery و Review

يجب أن تقلل الاستجابة لـ التحقيق في حادثة أمنية في Azure من المخاطر دون محو الأدلة التي لا تزال مطلوبة. نبدأ بإجراء قابل للعكس ومحدد الهدف، ونؤكد الملكية والسلطة، ونوثق الوقت، العملية، والنتيجة.

يعالج الإصلاح طويل الأمد الجذر: الصلاحيات، التكوين، Validation، Telemetry، العملية أو التدريب. بعد التطبيق، نقوم بإجراء Retest ونراقب علامات العودة، بدلاً من الاكتفاء بإغلاق التذكرة.

نقاط فحص فريدة

في هذا الموضوع، يوصى ببناء خريطة أدلة مركزة مسبقًا. نقاط الفحص الرئيسية هي: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud, resource changes, managed identity. القائمة ليست قائمة مراجعة تلقائية؛ يتم اختيار كل عنصر لأنه يمكن أن يربط بين كيان، إجراء ووقت أو يشرح سلوكًا مشروعًا.

• Microsoft Sentinel: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
• Entra sign-ins: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
• Activity Log: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
• Defender for Cloud: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
• resource changes: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
• managed identity: حدد القيمة المتوقعة، وما سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.

عندما يكون أحد التركيزات غير متاح، يجب توثيق الفجوة واختيار بديل. على سبيل المثال، إذا كان Process identifier غير مستقر، يمكن استخدام الوقت، Host، User و Parent؛ إذا كانت Payload مشفرة، يتم استخدام Metadata، الحجم، التردد وسياق TLS/DNS.

عملية عمل موصى بها

1. حدد النطاق وسؤال عمل واحد حول التحقيق في حادثة أمنية في Azure.
2. سجل مصادر البيانات والأدلة المطلوبة: Microsoft Sentinel, Entra sign-ins, Activity Log, Defender for Cloud.
3. أنشئ خطًا أساسيًا قصيرًا للسلوك الطبيعي أو النتيجة المتوقعة.
4. أجرِ الاختبار الأدنى في بيئة معملية واحفظ الوقت والمدخلات والمخرجات.
5. أنشئ جدولًا زمنيًا أو جدول مقارنة وافصل بين الحقيقة والتفسير.
6. قم بتدوير Pivot إلى مصدر إضافي للتحقق من التفسير الأولي أو دحضه.
7. لخص القرار، القيود، الإجراء الموصى به، ومعيار Retest.

سيناريو عملي

السيناريو المختار هو سيناريو تغيير الأذونات ومورد غير عادي. الهدف من التمرين ليس إثبات القدرة على الهجوم، بل التدرب على جمع البيانات والمقارنة والتوثيق بطريقة آمنة. قبل بدء العمل، نحدد بيانات وهمية، نافذة زمنية ونتائج متوقعة.

في نهاية التمرين، يجب تقديم منتج يمكن لمحلل أو مدقق آخر مراجعته: لقطة شاشة أو تصدير للدليل، جدول زمني قصير، افتراض أولي، دليل مؤكد، قيود وتوصية. عندما لا يكون هناك دليل كافٍ، فإن الاستنتاج الصحيح هو أن السيناريو لم يثبت.

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

• ✓تحقق ووثق: Principal والجلسة.
• ✓تحقق ووثق: إجراء API.
• ✓تحقق ووثق: المورد والمنطقة.
• ✓تحقق ووثق: Source IP و user agent.
• ✓تحقق ووثق: Audit event ID.
• ✓تحقق ووثق: GuardDuty/Defender/SCC finding.
• ✓اذكر المنطقة الزمنية، إصدار الأداة ووقت التجميع.
• ✓احفظ البيانات الخام قبل التصفية أو التعديل.
• ✓اكتب ما تثبته النتيجة وما هو غير معروف بعد.
• ✓حدد المالك وإجراء المتابعة مع الموعد النهائي.

أخطاء شائعة

• التركيز على منطقة واحدة فقط.
• تدوير المفتاح قبل الحفاظ على الجدول الزمني.
• عدم فحص AssumeRole أو Token.
• تجاهل Control Plane.
• عدم تحديد الصلاحيات الفعالة.
• استنتاج أن الموقع الجغرافي يثبت الهجوم.

الخلاصة و CTA

التحقيق في حادثة أمنية في Azure: Sentinel, Entra و Defender هو موضوع يربط المعرفة التقنية بالانضباط في العمل. ابدأ بسؤال، اجمع الأدلة ذات الصلة فقط، حافظ على السياق والوقت، واختر إجراءً يمكن تبريره وإعادة اختباره.

في مسار Cybersecurity & AI لـ HPI، يتم التدرب على هذه المبادئ باستخدام الأنظمة، السجلات والمختبرات. من الطبيعي الانتقال إلى المقالات المرتبطة، وإجراء تمرين المختبر، وحفظ المنتج كجزء من محفظة عمل احترافية.

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