كيفية كتابة Analytics Rule في Microsoft Sentinel

الخطوة 1: اكتب Detection specification قبل KQL

يجب أن يجيب Use Case على أسئلة واضحة: ما هو السلوك الذي سنحدده؟ لماذا هو خطير؟ ما هي Data sources المطلوبة؟ ما هو Expected benign activity؟ من هو Owner؟ ماذا سيفعل المحلل عند تشغيل القاعدة؟ بأي MITRE technique يرتبط؟

حدد الحدود أيضًا. القاعدة لا تثبت Account compromise. إنها تحدد Pattern يتطلب تحقيقًا. إذا كان هناك نجاح، يمكنها رفع الأولوية، ولكن لا يزال يجب التأكد من التسلسل والسياق.

الخطوة 2: تحقق من Data readiness

افتح الجدول وتحقق من Sample events. هل ResultType رقم أم سلسلة؟ هل IPAddress فارغ في بعض الأحداث؟ هل تظهر Service principals بجانب المستخدمين؟ ما هو Ingestion delay؟ هل توجد Tenant أو Application تتطلب الاستثناء؟

القاعدة التي تعتمد على حقل غير مستقر ستنهار. قم بتوثيق Schema, Connector, Normalization و Data health query. إذا توقف المصدر عن الإرسال، يجب على Dashboard أن ينبه؛ "لا توجد تنبيهات" ليس بالضرورة وضعًا آمنًا.

الخطوة 3: اكتب Query تعيد Evidence مفيدة

يمكن لـ Query أساسية لـ Password Spray في المختبر تجميع الإخفاقات حسب IP والنافذة الزمنية وتتطلب عددًا فريدًا من المستخدمين:

let Lookback = 15m;
let MinimumAttempts = 20;
let MinimumUsers = 5;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where tostring(ResultType) != "0"
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            UserList=make_set(UserPrincipalName, 20),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by IPAddress, bin(TimeGenerated, 5m)
| where Attempts >= MinimumAttempts and Users >= MinimumUsers
| project TimeGenerated, IPAddress, Attempts, Users, UserList, FirstSeen, LastSeen

يجب أن تحتوي النتيجة على الحقول التي يحتاجها المحلل والحقول التي سيتم ربطها بـ Entities. في هذه الحالة، IPAddress هو Entity مركزية، و UserList هو Context. قائمة ديناميكية من المستخدمين ليست بالضرورة مناسبة لربط Account واحد، لذلك يمكن إنشاء Alert بناءً على IP وإضافة Custom details، أو تغيير بنية النتيجة وفقًا لـ Workflow.

اختبر Query على عدة نطاقات: ساعة، يوم، وأسبوع. قم بوضع علامة يدوية على True, False و Benign Positives. انظر ما إذا كانت تحدد نشاط VPN أو Health checks. لا تقم بضبط Threshold فقط للوصول إلى صفر تنبيهات.

الخطوة 4: Frequency و Lookback

Query frequency يحدد عدد مرات تشغيل القاعدة. Query period أو Lookback يحدد المدة الزمنية التي يتم فحصها. إذا كانت القاعدة تعمل كل خمس دقائق وتفحص 15 دقيقة، فقد يظهر نفس Pattern في عدة عمليات تشغيل. يمكن لآليات Event grouping, Alert grouping أو Suppression تقليل التكرارات، ولكن يجب فهم التأثير.

يجب أن يكون Lookback طويلاً بما يكفي لتغطية Ingestion delay وتحديد السلوك، ولكن ليس واسعًا جدًا. قد يتطلب Password Spray البطيء نافذة أكبر أو Baseline مختلفًا. قد تولد القاعدة السريعة جدًا ضوضاء؛ القاعدة البطيئة جدًا تزيد من وقت الكشف.

الخطوة 5: Severity, MITRE وتفاصيل Alert

يجب أن تعكس Severity المخاطر عندما يتم استيفاء الشرط، وليس النتيجة النهائية للتحقيق. قد يكون Password Spray بدون نجاح متوسطًا، ولكن محاولة ضد حسابات Privileged أو النجاح بعد الإخفاقات قد يبرر تصنيفًا مختلفًا. يمكن استخدام Alert details override لعرض IP، المستخدم أو Count في العنوان ديناميكيًا، مع الحفاظ على عنوان قابل للقراءة.

يساعد ربط MITRE ATT&CK في شرح سلوك الخصم وبناء Coverage map. اختر Tactics و Techniques التي تتناسب مع المنطق الفعلي. لا تقم بربط قائمة طويلة فقط لتبدو شاملة.

يجب أن تعرض Custom details السياق الذي يختصر Triage: Attempts, Users, FirstSeen, LastSeen, Application أو Tenant. تجنب نقل معلومات حساسة غير ضرورية.

الخطوة 6: Entity mapping

يتيح Entity mapping لـ Sentinel تحديد IP, Account, Host, URL والمزيد. Entity ذات جودة عالية تتيح Investigation, Enrichment, UEBA والربط بـ Incidents أخرى. تأكد من أن الحقل في الإخراج هو Scalar وبالتنسيق المناسب.

في المثال، يتم ربط IP.Address بـ IPAddress. إذا أعادت القاعدة UserPrincipalName واحدًا لكل صف، يمكن ربط Account.FullName أو AadUserId وفقًا لـ Schema. عندما تلخص Query العديد من المستخدمين في قائمة، لا تجبر Mapping لا يمثل Entity واحدًا.

الخطوة 7: Event grouping و Alert grouping

يحدد Event grouping ما إذا كان كل صف من Query سيصبح Alert منفصلاً أو سيتم تجميع جميع النتائج. إذا كان كل IP هو حالة منفصلة، فقد يكون صف لكل IP و Alert لكل Result منطقيًا. إذا تم تجميع كل شيء في Alert واحد، فقد يتلقى المحلل Incident ضخمًا مع IPs غير ذات صلة.

يمكن لـ Alert grouping ضم Alerts إلى Incident بناءً على Entities أو التفاصيل. حدد نافذة وتحديد علاقة حقيقية. Grouping العدواني جدًا يخفي التطورات ويمزج Scopes؛ Grouping الضعيف جدًا ينشئ Incident لكل عملية تشغيل.

الخطوة 8: Automation و Tasks

في المرحلة الأولى، يمكن لـ Automation تعيين Owner، إضافة Tags، إنشاء Tasks، إثراء IP أو إرسال Notification. تتطلب إجراءات Containment التلقائية ثقة عالية، Exceptions، موافقة وقدرة على Rollback. يتطلب Detection الجديد عادةً فترة Monitor قبل الاستجابة التلقائية الهامة.

أرفق Tasks التي توجه المحلل: تحقق من النجاحات من نفس IP، تحقق من MFA، تحقق من Reputation، ابحث عن نشاط متابعة واتصل بمالك الحساب. وبهذه الطريقة، تنشئ القاعدة عملية وليس مجرد Alert.

Testing و Tuning

1. قم بتشغيل Query يدويًا على البيانات التاريخية وقم بتمييز النتائج.
2. اختبر Unit test بأحداث محاكاة تمثل حالات Positive و Negative.
3. قم بتشغيل القاعدة في وضع المراقبة بدون Automation خطير.
4. قم بقياس Volume, True/False/Benign Positive, وقت Triage وجودة Context.
5. غير Threshold, exclusions أو grouping مع توثيق السبب.
6. قم بإجراء Regression test بعد تغيير Parser, Connector أو Query.
7. حدد Review date و Owner؛ القاعدة بدون صيانة تصبح عبئًا على الكشف.

Checklist قبل التشغيل

• ✓Use Case والفرضية موثقة.
• ✓تم فحص Data source, Schema و Delay.
• ✓تعيد Query وحدة تحقيق واضحة.
• ✓تغطي Frequency و Lookback السلوك بدون تكرار مفرط.
• ✓Severity و MITRE يتطابقان مع المنطق.
• ✓Entities و Custom details سليمة.
• ✓تم اختبار Grouping على عدة نتائج.
• ✓توجد Playbook, Owner و Review date.
• ✓تم فحص Privacy, التكلفة والأذونات.
• ✓يوجد Rollback للتغييرات ولـ Automation.

أخطاء شائعة

• البدء من Query وجدتها على الإنترنت بدون Use Case محلي.
• ربط Entity من قائمة أو من حقل غير مستقر.
• استخدام Lookback متداخل بدون فهم التكرارات.
• تحديد High severity لكل Rule.
• استثناء IP أو مستخدم بشكل دائم بدون Expiration.
• إضافة Suppression يخفي تصعيد النشاط.
• تفعيل حظر تلقائي قبل فترة Tuning.
• عدم فحص Data health و Schema changes.

الخلاصة و CTA

اختر Use Case واحدًا في المختبر واكتب Detection specification من صفحة واحدة قبل KQL. ثم قم بإنشاء القاعدة، قم بتشغيلها على بيانات محاكاة ووثق ثلاث نتائج: True, False و Benign Positive. التحسين الأكثر أهمية ليس شرطًا آخر في Query، بل Incident يمكن للمحلل التالي التحقيق فيه بسرعة وبشكل متسق.

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