ibondarenko1/azure-sentinel-detection-engineering9 كشوفات KQL مرتبطة بإطار MITRE ATT&CK على بيئة حيّة من Microsoft Sentinel + Defender XDR (مستوى التحكّم، نقطة النهاية، الهوية)، مع خط أنابيب Detection-as-Code خاضع لبوابة طلبات السحب (GitHub Actions، OIDC)، ودفاتر تشغيل SOAR، وتعيين ضوابط SOC 2.
هندسة كشف على بيئة 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 واستجابة للحوادث مقابل تيليمتري حقيقي وليس عينات اصطناعية.
القواعد لا تُنقر يدويًا في البوابة. إنها 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]
