SamirOnCloud | Entra ID & Security

Custom Detection Rules في Defender XDR: اصطاد التهديدات قبل ما تضربك دليل عملي لتحويل أي كويري KQL في Advanced Hunting لقاعدة detection شغالة لوحدها وبتعمل alert وresponse تلقائي. المقدمة حصلت معايا قبل كده إني لقيت في Advanced Hunting كويري بيكشف سلوك غريب، encoded PowerShell command جوه process عادي، بس المشكلة إني كنت بشغّل الكويري يدوي كل يوم عشان أتأكد مفيش تكرار للموضوع. ده تعب ومش قابل للتوسع، ولو نسيت يوم ممكن يفوتني حدث مهم. هنا بالظبط بييجي دور الـ Custom Detection Rules: بتاخد نفس الكويري اللي اتأكدت إنه دقيق، وتحوّله لقاعدة بتشتغل أوتوماتيك كل فترة زمنية محددة، وتولّد alert أو حتى تاخد action (زي عزل جهاز أو تعطيل مستخدم) من غير ما تلمس لوحة المفاتيح. الفايدة الحقيقية هنا إنك بتعمل detection logic خاص بالبيئة بتاعتك، مش مقتصر على القواعد الجاهزة من Microsoft، وده بيسد فجوات حقيقية خصوصاً لو عندك سيناريوهات معينة في شغلك أو صناعتك مش مغطاة بالـ built-in detections. 💡 المتطلبات: - اشتراك Microsoft Defender XDR فعّال (ضمن Microsoft 365 E5 أو Defender plan مناسب ي...

إزاي تكشف الـ Shadow IT في شركتك قبل ما تبقى مشكلة أمنية دليل عملي لاستخدام Defender for Cloud Apps في اكتشاف الـ cloud apps اللي بيستخدمها الموظفين من غير علم IT، وإزاي تدير الموضوع بشكل منظم. المقدمة لو سألت أي مسؤول أمان في شركة متوسطة أو كبيرة "كام cloud app بيستخدمها الموظفين دلوقتي؟"، هتلاقي الإجابة الحقيقية أكبر بكتير من اللي هو متخيله. أنا شخصياً قابلت عميل كان عنده تقدير إنه بيستخدم حوالي 60 تطبيق سحابي، وبعد ما شغّلنا الـ Cloud Discovery في Defender for Cloud Apps ظهر إن العدد الحقيقي أكبر بمراحل، وده كان فيه تطبيقات فيها risk score منخفض جداً وبيتم رفع بيانات حساسة عليها. المشكلة إن الموظف مش بيقصد يعمل خطأ، هو بس بيحاول يخلص شغله بسرعة، وده اللي بيخلق ما يسمى Shadow IT: أي تطبيق أو خدمة بيستخدمها حد في الشركة من غير موافقة أو رؤية من فريق IT أو الأمان. المقال ده هيوضح إزاي تبدأ تكتشف الموضوع بشكل عملي وتوصل لحوكمة (Governance) حقيقية للتطبيقات. 💡 المتطلبات: ترخيص Microsoft Defender for Cloud Apps (متوفر ضمن Microsoft 365 E5 أو كـ add-on منفصل) ص...

قواعد ASR في Defender for Endpoint اللي بتوقف الـ Ransomware قبل ما يبدأ تجربة عملية مع Attack Surface Reduction rules، من التفعيل في Audit mode لحد الـ Enforcement، وإزاي تتابع النتيجة بـ KQL في Defender XDR. المقدمة حصلت معايا حادثة عند عميل، جهاز واحد فيه Excel macro مصاب حاول ينزل payload ويشغله عن طريق PowerShell، والقصة خلصت في ثواني لأن قاعدة ASR واحدة اسمها "Block all Office applications from creating child processes" كانت شغالة في Block mode. لو القاعدة دي متكانتش موجودة، كان الـ payload اتنفذ عادي وبدأ الانتشار الجانبي قبل ما أي حد يلاحظ حاجة. المشكلة إن كتير من الشركات بتدفع فلوس في Defender for Endpoint بس بتسيب الـ ASR rules في وضعها الافتراضي "Not configured"، يعني بيشتروا سيارة بأحدث نظام فرامل بس مش ضاغطين عليه. الـ ASR rules هي أرخص وأسرع طبقة حماية ممكن تقفلها النهارده، وبتوقف سلوكيات الـ Ransomware المعروفة قبل ما توصل لمرحلة الـ Encryption أصلا. 💡 المتطلبات: Microsoft Defender for Endpoint Plan 1 على الأقل (الـ ASR rules متاحة من ...

Defender for Identity وصيد Kerberoasting والحركة الجانبية في شبكتك الهجينة إزاي تمسك attacker بيتحرك من مكينة لمكينة في Active Directory قبل ما يوصل لـ Domain Admin. المقدمة لو عندك بيئة hybrid فيها on-prem AD متوصل بـ Entra ID، فاكر إن الحماية بتاعة الـ cloud كفاية؟ للأسف لا. أغلب الـ incidents الكبيرة اللي شوفتها في بيئات العملاء بتبدأ من مكينة عادية جوه الشبكة، الـ attacker بياخد foothold صغير، وبعدين يبدأ يعمل lateral movement بهدوء لغاية ما يوصل لـ Domain Controller. في الوقت ده، Conditional Access و MFA على الـ cloud ملهم مفعول لأن الهجوم كله شغال على الـ on-prem identity. هنا بالضبط بييجي دور Defender for Identity (كان اسمه Azure ATP قبل كده). هو الـ sensor اللي شغال على الـ Domain Controllers نفسها، وبيراقب الـ traffic والـ authentication requests علشان يمسك حاجات مثل Kerberoasting و Pass-the-Hash و DCSync قبل ما توصل لـ Defender XDR كـ incident كامل. المقال ده هيمشيك خطوة خطوة إزاي تفهم الـ detections بتاعته، وإزاي تكتب KQL queries تساعدك تصيد نفس السلوكيات بنفسك. ...

لما الـ 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 X...

لوجات الـ Audit والـ Sign-in في Entra ID: إيه اللي يستحق المتابعة فعلاً؟ دليل عملي لتحديد الـ signals المهمة في الزحمة، بعيد عن فكرة "شوف كل اللوجات" اللي مستحيل تنفذها. المقدمة أول مرة فتحت Sign-in Logs في tenant فيه عدد users كبير، حسيت إني بحاول أشرب من خرطوم حريق. آلاف الـ entries في اليوم، وكل entry فيها تفاصيل كتير: IP, device, location, conditional access result... والمشكلة إنك لو حاولت تراجع كل ده يدوي، مش هتلاقي وقت تعمل حاجة تانية في الشغل. الحقيقة إن مش كل سطر في اللوجات ده له قيمة أمنية واحدة. فيه فرق كبير بين "حاجة حصلت" و"حاجة لازم تتراجع دلوقتي". في البوست ده هقولك بالتحديد إيه اللي أنا فعلاً براجعه بشكل دوري من الـ Audit Logs والـ Sign-in Logs، وإزاي تبني عليه queries بـ KQL تقدر تشغلها في Log Analytics أو Sentinel بدون ما تضيع وقتك. 💡 المتطلبات: Microsoft Entra ID P1 أو P2 للحصول على أفضل مدة retention وتصدير مستمر للوجات Global Reader أو Security Reader على الأقل لقراءة اللوجات من الـ portal Log Analytics workspace (لو...

الفجوة بين Intune و Entra: ليه الجهاز Compliant وبرضو بيتمنع من الدخول؟ حكاية Ticket فضل قاعد يومين، وبعد التحقيق طلع السبب حاجة بسيطة كل واحد فينا ممكن يقع فيها. المقدمة لو شغال Identity أو Endpoint Engineer، أكيد قابلت الموقف ده: يوزر بيقولك "الجهاز بتاعي Compliant في Intune، طب ليه Conditional Access رافضه؟". الموضوع مش باج، الموضوع إن Intune و Entra ID عندهم مصدرين مختلفين للحقيقة (source of truth)، والـ sync بينهم مش instant، وفيه شروط تانية غير الـ Compliance نفسها بتتحكم في القرار. في البوست ده هنفكك المشكلة دي من جذورها: إزاي الـ Compliance State بيتحسب، إزاي الـ Conditional Access بيقرأه، وإزاي تقفل الفجوة دي عمليًا بدل ما تفضل بتعمل Troubleshoot كل مرة من الصفر. 💡 المتطلبات: صلاحية Global Administrator أو Intune Administrator + Conditional Access Administrator Microsoft Entra ID P1 على الأقل (للـ Conditional Access) Microsoft Intune Plan 1 (Device Compliance Policies) وصول لـ Microsoft Graph Explorer أو PowerShell مع Microsoft.Graph module وصول لـ...

تمبلت Conditional Access الجاهزة ولا تبنيها بإيدك؟ القصة كاملة تجربة عملية مع Microsoft's baseline templates في Entra admin center، وإمتى تسيبها وتعمل policy مخصصة من الصفر. المقدمة لما بتفتح Conditional Access في Entra admin center دلوقتي، هتلاقي Microsoft ضايفة قسم "Templates" فيه policies جاهزة زي Require MFA for admins و Block legacy authentication. الفكرة إن أي حد داخل جديد على identity security يقدر يفعّل baseline policies في دقايق من غير ما يفهم كل تفصيلة. المشكلة إني شخصياً اتعاملت مع عميل استخدم الـ templates زي ما هي من غير تعديل، وبعد شهر لقى نفسه محتاج exclusions لحسابات service accounts ومحتاج session controls مش موجودة في التمبلت الأساسي. يعني السؤال مش "التمبلت كويس ولا لأ"، السؤال هو "امتى تستخدمه كما هو وامتى تاخده كنقطة بداية بس". 💡 المتطلبات: Microsoft Entra ID P1 على الأقل (P2 لو هتستخدم Sign-in risk أو User risk conditions) رول Conditional Access Administrator أو Security Administrator Microsoft Graph PowerShell SD...

وداعًا لسياسات الـ MFA و SSPR القديمة: دليل Migration لـ Authentication Methods Policy في Entra ID حكاية عملية لتينانت لسه شغال بالـ Legacy MFA Service Settings و SSPR Policy القديمة، وإزاي تنقله بأمان لـ Authentication Methods Policy الموحدة من غير ما توقف أي user عن تسجيل الدخول. المقدمة لو فتحت تينانت قديم شويه في Entra ID، هتلاقي حاجة غريبة: فيه صفحة "Multi-factor authentication" جوه Active Directory admin center لوحدها، وفيه صفحة "Password reset" لوحدها بتتحكم في SSPR، وفيه Authentication methods policy تالتة جوه Protection بتتحكم في نفس الطرق دي. ده مش تكرار غلط، ده بقايا نظام قديم كانت Microsoft بتديره من قبل ما توحّد كل حاجة في مكان واحد. المشكلة إن الوضع ده بيسبب تعارض فعلي: ممكن تفعّل Microsoft Authenticator من Authentication methods policy وتلاقيه شغال، لكن الـ per-user MFA القديم لسه مفعّل على مستخدمين معينين ومعطلهم من الـ Conditional Access الطبيعي. أنا اتعاملت مع الموضوع ده في تينانت فيه أكتر من ٢٠٠٠ يوزر، وده اللي عملته خطوة بخطوة. 💡 ال...