Azure Sentinel Detection Engineering

Detection engineering एक लाइव Microsoft Sentinel और Defender XDR वातावरण पर जिसे मैं संचालित करता हूँ। नौ कस्टम एनालिटिक्स नियम तीन प्लेनों में फैले हुए हैं, प्रत्येक MITRE ATT&CK से मैप किया गया है और एंड-टू-एंड सिद्ध है: एक नियंत्रित कार्रवाई नियम को ट्रिगर करती है, नियम एक घटना उठाता है, और घटना की जांच और दस्तावेज़ीकरण किया जाता है। सात Azure कंट्रोल प्लेन (AzureActivity) पर नज़र रखते हैं, जिसमें एक बहु-चरण सहसंबंध और एक ARG-समर्थित सामग्री नियम शामिल है; एक एंडपॉइंट (Defender for Endpoint) पर नज़र रखता है, जिसमें Defender Vulnerability Management एक हंटिंग लाइब्रेरी को फीड करता है; एक पहचान (Entra ID SigninLogs) पर नज़र रखता है। सभी एक ही PR-गेटेड पाइपलाइन द्वारा तैनात किए गए हैं।

एक लाइव सिंगल-टेनेंट वातावरण जिसे मैं एंड-टू-एंड संचालित करता हूँ। सभी स्क्रीनशॉट में टेनेंट और सब्सक्रिप्शन पहचानकर्ता और कोई भी PII को हटा दिया गया है।

आंकड़े ट्रेसेबल हैं: कवरेज ATT&CK लेयर तक, सत्यापन RESULTS.md तक। जानबूझकर कोई फाल्स-पॉज़िटिव-रेट बैज नहीं है: एक सिंगल-टेनेंट वातावरण सार्थक FP दर नहीं दे सकता है, इसलिए रिपॉजिटरी एक वास्तविक बेनाइन बैच पर मापे गए फाल्स फायर की रिपोर्ट करता है, न कि एक मनगढ़ंत प्रतिशत (metrics.yaml इसे पूरा बताता है)।

---

त्वरित प्रारंभ

एक फोर्क पर डिटेक्शन यूनिट टेस्ट चलाएँ, 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

नियम पोर्टल में क्लिक नहीं किए गए हैं। वे PR-गेटेड पाइपलाइन द्वारा तैनात संस्करणित YAML हैं। डिटेक्शन को संपादित करने का मतलब है एक पुल रिक्वेस्ट खोलना; CI मान्य करता है, एक समीक्षक अनुमोदित करता है, और main में मर्ज करने पर इसे OIDC (कोई संग्रहीत रहस्य नहीं) के माध्यम से Sentinel में तैनात किया जाता है, नियम GUID (API 2025-09-01) द्वारा इडेम्पोटेंटली।

flowchart LR
  D[नियम YAML संपादित करें] --> PR[पुल रिक्वेस्ट] --> V[CI मान्य करें] -->|समीक्षा| M[Merge main] --> CD[OIDC तैनाती] --> 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 से समीक्षित PR द्वारा स्वचालित रूप से तैनात होना, एक डिटेक्शन इंजीनियर को एक विश्लेषक से अलग करता है जिसने एक कोर्स पूरा कर लिया है।

आर्किटेक्चर

flowchart LR
  subgraph Sources
    A[Microsoft Defender XDR<br/>ईमेल · एंडपॉइंट]
    B[Azure सब्सक्रिप्शन<br/>एक्टिविटी लॉग]
    C[Entra ID<br/>साइन-इन]
  end
  A --> W[Log Analytics वर्कस्पेस<br/>sc200-ws]
  B --> W
  C --> W
  W --> R[9 अनुसूचित<br/>एनालिटिक्स नियम]
  R --> I[घटनाएँ]
  I --> V[जांच<br/>+ MITRE मैपिंग]

डिटेक्शन सूची