هندسة الكشف في Azure Sentinel

هندسة كشف على بيئة Microsoft Sentinel وDefender XDR حية أديرها بنفسي. تسع قواعد تحليلات مخصصة تمتد عبر ثلاث مستويات، كل منها مرتبطة بـ MITRE ATT&CK ومُثبتة من البداية إلى النهاية: إجراء مُتحكم فيه يُفعّل القاعدة، والقاعدة تُنشئ حادثة، والحادثة تُحقَّق وتُوثَّق. سبع قواعد تراقب مستوى التحكم (control plane) في Azure (AzureActivity)، بما في ذلك ارتباط متعدد المراحل وقاعدة محتوى مدعومة بـ ARG؛ وقاعدة واحدة تراقب نقطة النهاية (Defender for Endpoint)، حيث تغذي Defender Vulnerability Management مكتبة صيد تهديدات؛ وقاعدة واحدة تراقب الهوية (SigninLogs في Entra ID). جميعها تُنشر عبر خط الأنابيب نفسه المحكوم بطلبات السحب (PR).

بيئة أحادية المستأجر حية أديرها من البداية إلى النهاية. معرّفات المستأجر والاشتراك وأي معلومات شخصية قابلة للتحديد (PII) محجوبة في جميع لقطات الشاشة.

الأرقام قابلة للتتبع: التغطية إلى طبقة ATT&CK، والتحقق إلى RESULTS.md. لا توجد عمدًا شارة لمعدل الإيجابيات الكاذبة: بيئة أحادية المستأجر لا يمكنها إنتاج معدل FP ذي معنى، لذا يبلّغ المستودع عن الإنذارات الكاذبة المُقاسة عبر دفعة حميدة حقيقية بدلًا من نسبة مئوية مفتعلة (metrics.yaml يوضح ذلك بالكامل).

بدء سريع

شغّل اختبارات الوحدة للكشف على نسخة fork، دون الحاجة إلى Azure. يعمل KQL الفعلي لكل قاعدة مقابل بيانات تجريبية اصطناعية في محاكي Kusto محلي، لذا يمكن التحقق من منطق الكشف دون الحاجة إلى المستأجر الخاص بي:

git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py

هذا هو الفحص نفسه الذي يشغّله CI عند كل طلب سحب (detection-tests): يتحقق من أن كل قاعدة تُفعَّل على البيانات التجريبية الخبيثة وتظل صامتة أمام البيانات الحميدة. أما بيئة الاختبار الحية في validation/ فتذهب أبعد من ذلك، إذ تقود دفعة حقيقية من الأنشطة الحميدة والهجومية في مستأجر وتقيس الإيجابيات الحقيقية والإنذارات الكاذبة، لكنها تتطلب اشتراك Azure خاصًا بك وaz login (انظر validation/README)، لذا فهي ليست "محلية". خط أنابيب النشر: docs/03. المساهمة بقاعدة: CONTRIBUTING.

لماذا هذا المستودع؟

أي كشف لا يكون موثوقًا إلا عندما يمكنك إثبات أنه يُفعَّل فعلًا. يُغلق هذا المستودع تلك الحلقة عبر ثلاث مستويات: مستوى التحكم في Azure، ونقطة النهاية، والهوية: منطق القاعدة، والإجراء المُحفِّز المُتحكم فيه، والحادثة المُنشأة، والتحقيق، وربط MITRE. يتجاوز القواعد ذات الحدث الواحد عبر ارتباط متعدد المراحل (منح ثم نشر) وقاعدة واعية بالسياق تربط وضع Azure Resource Graph بحدث التغيير. إنها قواعد تحليلات Sentinel وKQL واستجابة للحوادث مقابل تيليمتري حقيقي وليس عينات اصطناعية.

Detection-as-Code

القواعد لا تُنقر يدويًا في البوابة. إنها YAML مُدارة بالإصدارات وتُنشر عبر خط أنابيب محكوم بطلبات السحب. تعديل أي كشف يعني فتح طلب سحب؛ يتحقق CI منه، ويوافق عليه مراجع، ودمجه في main ينشره إلى Sentinel عبر OIDC (بدون أسرار مخزنة)، بشكل تكاملي (idempotent) حسب GUID القاعدة (API 2025-09-01).

flowchart LR
  D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]

• مصدر الحقيقة: detections/rules/*.yaml · خط الأنابيب: .github/workflows/deploy-detections.yml · أداة النشر/التحقق: cicd/ · التفاصيل: docs/03-cicd.md

مرّ عبره تغيير حقيقي: PR #1 شدّد عتبة DET-001 (من 10 إلى 8)؛ تحقق CI منه، ونشره الدمج في القاعدة الحية sc200-ws. هذه الخطوة، أي نشر القواعد تلقائيًا من git عبر طلب سحب مُراجع، هي ما يميز مهندس الكشف عن محلل أنهى دورة تدريبية.

البنية المعمارية

flowchart LR
  subgraph Sources
    A[Microsoft Defender XDR<br/>Email · Endpoint]
    B[Azure subscription<br/>Activity Log]
    C[Entra ID<br/>sign-ins]
  end
  A --> W[Log Analytics workspace<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 scheduled<br/>analytics rules]
  R --> I[Incidents]
  I --> V[Investigation<br/>+ MITRE mapping]

كتالوج الكشوفات

النتائج

تم تفعيل كل كشف بإجراء إداري مُتحكم فيه ويتراجع ذاتيًا، وأدى إلى حادثة حقيقية:

الحالة التشغيلية الحالية لمساحة العمل: 10 قواعد تحليلات مفعّلة، و4 موصلات بيانات نشطة، وقاعدة أتمتة، وبيانات حية تتدفق. القواعد العشر المفعّلة هي القواعد المجدولة المخصصة التسع [DET] في هذا الكتالوج بالإضافة إلى قاعدة Fusion المدمجة من Microsoft (اكتشاف الهجمات متعددة المراحل المتقدمة) التي تعمل افتراضيًا ولم تُكتب هنا؛ أما الرقم تسعة الوارد في مكان آخر من هذا README فيحسب القواعد المخصصة فقط.

خمس حوادث موثقة كتحقيقات كاملة:

• INV-01، الحذف الجماعي للموارد (مرتفع)
• INV-02، تصعيد صلاحيات RBAC
• INV-03، الوصول إلى بيانات الاعتماد عبر LSASS (مرتفع)، نقطة النهاية، الحادثة #65
• INV-04، فتح NSG للدخول الوارد من Any (مرتفع)، ارتباط محتوى ARG (DET-009)
• INV-05، منح صلاحيات ثم نشر (مرتفع)، ارتباط متعدد المراحل (DET-007)

إلى جانب التفعيلات الفردية، تقود بيئة تحقق دفعة حقيقية من الأنشطة الحميدة + الهجومية في المستأجر وتشغّل KQL الخاصة بكل قاعدة ضدها، بحيث تكون الإيجابيات الكاذبة مُقاسة وليست مفترضة. أحدث تشغيل (النتائج): 5/5 سيناريوهات هجومية أُطلقت (DET-002/003/004/007/009) و0 إنذارات كاذبة على تدفق الأنشطة الحميدة (نشر المالك المدرج في القائمة البيضاء، وعمليات حذف دون العتبة، والنشر دون منح صلاحيات). إنها لا تزيّف حجم الإنتاج؛ بل تحوّل "0% إيجابيات كاذبة عند N=1" إلى قياس فعلي "0 إنذارات كاذبة عبر دفعة حميدة حقيقية".

تغطية ATT&CK

خريطة تغطية بفجوات صريحة أكثر صدقًا من مجرد قائمة بالقواعد. تُظهر طبقة ATT&CK Navigator (كيفية التحميل) كليهما:

الفجوات ليست نصًا ثابتًا. كل واحدة منها هي قضية detection-gap حية، لذا فإن خارطة الطريق عبارة عن تراكم عمل قابل للنقر.

لماذا هذه القواعد دون غيرها: docs/08، استراتيجية الكشف ونموذج التهديد يربط الكتالوج بسلسلة قتل سحابية ويُرتب الفجوات حسب المخاطر. كيف تُضبط قاعدة: docs/09، حلقة ضبط مُقاسة لـ DET-005 ينقل قاعدة من "تُفعَّل عند كل كتابة" إلى صفر إيجابيات كاذبة مُقاس على بيئة التحقق.

الاستجابة الآلية (SOAR)

أخطر كشف يُغلق الحلقة من الكشف إلى الاستجابة. تشغّل قاعدة أتمتة في Sentinel كتاب تشغيل Logic App عند كل حادثة DET-004 (حذف جماعي): ينشر تعليق إثراء يتضمن الاحتواء الموصى به (تعطيل المستدعي، وقفل مجموعات الموارد، والاستعادة، والصيد). يوثّق كتاب التشغيل بهويته المُدارة (managed identity) الخاصة مباشرة إلى ARM API، دون أسرار ودون موصل خارجي.

كتاب تشغيل ثانٍ يوسّع الحلقة إلى كشف ← استجابة ← تحقيق بالذكاء الاصطناعي عبر Microsoft Security Copilot: promptbook + Logic App يستدعي promptbook من Copilot على حادثة DET-004 نفسها وينشر ملخص تحقيق بالذكاء الاصطناعي كتعليق. يُبنى ويُنتشر دون أي وحدات حوسبة؛ التقاط ملخص الذكاء الاصطناعي الحي يعمل في نافذة مدفوعة واحدة محدودة التكلفة (~4$)، ولا يُدَّعى حتى يتم الالتقاط. كتاب تشغيل التكلفة والتفكيك: docs/06.

إدارة نقطة النهاية والثغرات الأمنية

تبدأ عمليات الكشف على مستوى التحكم في Azure؛ وتضيف هذه المرحلة مستوى نقطة النهاية. يعمل مستشعر Defender for Endpoint على مضيف Windows ويُغذي مساحة العمل نفسها، لذا ينشر خط أنابيب Detection-as-Code قاعدة نقطة نهاية، وهي DET-006 الوصول إلى بيانات الاعتماد عبر LSASS، بجانب قواعد مستوى التحكم. DET-006 متعددة المصادر ومُشاهَدة عمليًا: نُفذت ثلاث تقنيات لتفريغ بيانات الاعتماد ضد المستشعر، ومنعها المضيف المحصّن (LSASS RunAsPPL, AMSI, الحماية السلوكية) جميعها، وأُطلقت القاعدة على تنبيهات Defender الناتجة لرفع حادثة (INV-03). يضيف Defender Vulnerability Management مدخلًا ثانيًا: مكتبة صيد تُبرز ثغرات CVE حرجة حسب البرامج المكشوفة، وخطوط الأساس الفاشلة للإعداد الآمن، والأصول المعرضة للخطر تحت تنبيه نشط. جداول DeviceTvm* موجودة فقط في الصيد المتقدم في Defender، لذا فإن تلك الارتباطات هي عمليات صيد وليست قواعد منشورة، ويوضح المستودع أين يعمل كل استعلام فعلًا. البنية وتدفق البيانات: docs/07.

معالجة الوضع الأمني

تراقب عمليات الكشف الهجمات؛ وتقرأ هذه المرحلة درجة الوضع الأمني للمستأجر نفسه وتصلح ما تشير إليه، ثم تُثبت أن الرقم تغيّر. يُسحب خط الأساس الخاص بـ Defender for Cloud Secure Score كـلقطة قابلة للقراءة آليًا عبر collect-posture.ps1، لذا فإن المقارنة قبل/بعد هي فرق ملفات وليست مقارنة لقطات شاشة. عند خط الأساس تكون الدرجة 68.81% (21.33 / 31)، ويضع تفصيل الرقابات الفجوة كاملة البالغة 9.67 نقطة في أربع رقابات (التشفير عند التخزين، والوصول والصلاحيات، والوصول إلى الشبكة، والتدقيق). المعالجة مُرتّبة حسب نصف قطر الانفجار، بالإصلاحات الإضافية أولًا، وكل عنصر مرتبط بقاعدة الكتالوج التي تلتقط تراجعه (كشف التخزين إلى DET-002 / DET-009، وانتشار RBAC إلى DET-003 / DET-007، وفقدان التسجيل إلى الكتالوج بأكمله). طُبقت ثلاثة إصلاحات في هذه الجولة وتحققت على مستوى الموارد: جهة الاتصال الأمنية وإشعارات التنبيهات، والتسجيل التشخيصي على كتابَي تشغيل SOAR (+1 تدقيق)، والتشفير على المضيف في الجهاز الافتراضي للمستشعر (+4 تشفير عند التخزين). يعيد Defender for Cloud تقييم الدرجة وإعادة حسابها خلال الـ24 إلى 72 ساعة التالية، لذا تُوثَّق الدرجة البعدية كمتابعة وليس كتأكيد الآن. المنهج الكامل والخطة المرتبة وجدول ربط الكشوفات: docs/10، معالجة الوضع الأمني.

ربط رقابات SOC 2

يدعم هذا العمل إطار رقابات معترفًا به، لذا يوضح المستودع أين. كل جزء من الكتالوج مرتبط بمعيار من معايير خدمات الثقة في SOC 2: كتالوج القواعد التسع والحوادث إلى سلسلة المراقبة والاستجابة (CC7.2 إلى CC7.4)، وكتُب تشغيل SOAR إلى الاستجابة للحوادث (CC7.4)، وخط أنابيب Detection-as-Code المحكوم بطلبات السحب إلى إدارة التغيير (CC8.1)، وبيئة التحقق والوضع الأمني قبل/بعد إلى فعالية الرقابة التشغيلية (CC4.1). يُقدَّم هذا كربط وليس كادعاء امتثال: هذا مستأجر واحد أديره وليس مؤسسة مُدقَّقة، لذا يربط المستند أنشطة الرقابة التقنية ويوضح صراحةً الغلاف الحوكمي الذي يتطلبه تقرير SOC 2 حقيقي ولا يحمله مستودع كشف. الجدول الكامل معيارًا بمعيار وملاحظة كيفية قراءته في التدقيق: docs/11، ربط رقابات SOC 2.

هيكل المستودع

detections/rules  rule source-of-truth (Sentinel YAML, deployed by CI)
detections/*.md   one card per rule: logic, MITRE, trigger, evidence
detections/metrics.yaml  per-detection metrics (volume, FP rate, TP, MTTD)
tests/            synthetic-log unit tests (Kusto emulator, fork-runnable)
validation/       live mixed-activity harness: benign + attack streams, measured TP/FP
cicd/ + .github   Detection-as-Code pipeline (deploy, validate, regression)
sigma/            vendor-neutral Sigma conversions (portable to any SIEM)
kql/              analytics-rule queries + hunting library
investigations/   end-to-end incident write-ups
simulations/      exact atomic-aligned trigger steps
navigator/        ATT&CK coverage layer (covered + gaps)
posture/          Secure Score baseline collector + JSON snapshots + remediation script
playbooks/        SOAR response (Logic App + automation rule)
docs/             architecture, methodology, cicd, validation, data-dictionary, endpoint+TVM, detection-strategy, tuning case study, posture remediation, SOC 2 control mapping
screenshots/      visual evidence

المهارات المعروضة

KQL · قواعد تحليلات Sentinel المجدولة · قواعد الارتباط متعدد المراحل · كشف هوية Entra ID (SigninLogs) · قوائم مراقبة القائمة البيضاء (_GetWatchlist) · Azure Resource Graph كوضع أمني كمحتوى (إجراء مجدول) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · الصيد المتقدم (جداول Device / DeviceTvm) · Microsoft Secure Score · معالجة الوضع الأمني في Defender for Cloud (CSPM, MCSB) · ربط رقابات SOC 2 بمعايير Common Criteria · Detection-as-Code (GitHub Actions, OIDC) · SOAR (قواعد أتمتة Logic Apps) · Sigma (مستقل عن البائع) · التحقق بـ Atomic Red Team · فرز الحوادث والتحقيق · ربط MITRE ATT&CK · مراقبة مستوى التحكم في Azure (سجل النشاط).

المساهمة

هذه محفظة شخصية، لكنها منظمة بحيث يكون أي تغيير في الكشف طلب سحب قابلًا للمراجعة وليس نقرة في البوابة. إذا نسخت المستودع (fork) أو أردت اقتراح قاعدة، يغطي CONTRIBUTING.md سير العمل: عدّل YAML القاعدة، وأعد توليد مرآة KQL، ووسّع بيانات الاختبار التجريبية، وشغّل اختبارات الوحدة محليًا، وافتح طلب سحب تفحصه نفس بوابات CI.

الشهادات

معتمد من Microsoft: محلل عمليات أمنية مشارك (Security Operations Analyst Associate, SC-200).

إخلاء المسؤولية

بيئة أديرها بنفسي، وليست مستأجر إنتاج لأي جهة عمل أو طرف ثالث. تُتحقق عمليات الكشف بإجراءات إدارية مُتحكم فيها وتتراجع ذاتيًا ضد مواردي الخاصة؛ ولا توجد أنظمة إنتاج أو أطراف ثالثة مشاركة. معرّفات المستأجر والاشتراك والمعلومات الشخصية (PII) محجوبة في جميع لقطات الشاشة.

الترخيص

MIT