Elastic Security: إنشاء قاعدة اكتشاف ودليل التحقيق

الخطوة 1: تحديد حالة الاستخدام واختيار نوع القاعدة

ابدأ بعبارة سلوكية: “تحديد عملية من نوع معين يتم تشغيلها في سياق غير متوقع على محطات المستخدمين”. ثم حدد ما يعتبر تطابقًا، وما هو السياق المطلوب، وما هو التفسير المشروع. عندها فقط اختر نوع القاعدة.

الاختيار الخاطئ يؤدي إلى استعلام معقد أو تنبيهات غير مستقرة. إذا كان ترتيب الأحداث جوهريًا، فإن EQL أكثر طبيعية من ES|QL. إذا كان التجميع مطلوبًا، فإن ES|QL أو Threshold أكثر ملاءمة. Custom query جيدة للمطابقة المباشرة للحقول.

الخطوة 2: التحقق من ECS وجاهزية البيانات

يحدد Elastic Common Schema — ECS — أسماء وهياكل مشتركة، مثل event.category, event.type, host.name, user.name, process.name, process.command_line و-process.parent.name. القاعدة التي تعتمد على حقول غير معينة بشكل ثابت ستعمل على Integration واحد وتفشل على آخر.

افتح Sample events وتحقق: هل event.category هو process؟ هل يتضمن event.type كلمة start؟ هل يتم جمع process.command_line أو إخفاؤه؟ هل process.entity_id موجود؟ هل @timestamp هو وقت الحدث أم وقت الاستيعاب؟ وثق Index patterns, Integrations, Version و-Required fields. قائمة Required fields في الواجهة هي معلومات للمستخدم ولا تصحح التعيين الفعلي.

الخطوة 3: اكتب استعلامًا مركزًا

في مثال المختبر، نرغب في تحديد إنشاء عملية باسم lab-admin-tool.exe عندما لا يكون الوالد هو برنامج الإدارة المتوقع. الاسم وهمي. في Custom query، يمكن كتابة KQL بسيط:

event.category:process and event.type:start and process.name:"lab-admin-tool.exe" and not process.parent.name:"approved-manager.exe"

الاستعلام يشير إلى انحراف، ولكنه لا يثبت الخبث. يجب فحص Signer, Hash, Path, User, Host, Parent command line والتكرار. قبل إنشاء قاعدة، قم بتشغيلها في Discover أو Timeline على نطاقات مختلفة. تحقق مما إذا كانت هناك حقول Null، أو Variants في الاسم، أو Sources غير موثوق بها.

إذا كان السلوك يتطلب تسلسلًا — على سبيل المثال Process متبوعًا بـ Network connection من نفس process.entity_id — انتقل إلى EQL. إذا كنت ترغب في تلخيص عدد Hosts الذين قاموا بتشغيل الأداة أو حساب Count حسب Parent، يمكن أن يكون ES|QL مناسبًا.

الخطوة 4: الجدول الزمني والبحث التاريخي (Lookback)

تتضمن القاعدة Query, Schedule و-Actions. تحدد Interval عدد مرات تشغيلها. يوسع Lookback نافذة البحث لتغطية Events التي تصل متأخرة. قد تؤدي النوافذ المتداخلة إلى إنشاء Alerts مكررة إذا لم يكن هناك Deduplication أو Suppression مناسبة. نافذة قصيرة جدًا تفوت البيانات المتأخرة.

تحقق من Ingestion delay حسب المصدر. قد تصل Endpoint events في الوقت الفعلي تقريبًا، بينما قد يتأخر مصدر Cloud أو Batch. حدد Run every و-Additional look-back من القياس. بعد تغيير Pipeline أو Integration، قم بالقياس مرة أخرى.

الخطوة 5: الخطورة والمخاطر و-MITRE

تصف Severity خطورة المطابقة حسب حالة الاستخدام؛ يسمح Risk score بتصنيف رقمي. لا تستخدم High لكل قاعدة. تختلف العملية الشاذة على Lab host عن نفس العملية على Domain Controller. يمكن استخدام Risk score override عندما يوفر حقل موثوق سياقًا، ولكن يجب التحقق من Missing values و-Range.

يجب أن يتطابق تعيين MITRE ATT&CK مع السلوك الذي تحدده القاعدة، وليس مع سيناريو الهجوم الكامل الذي تتخيله. لا تثبت القاعدة التي تحدد Process execution بالضرورة Persistence أو Exfiltration.

الخطوة 6: الكبت والاستثناءات

يقوم Alert suppression بتجميع التطابقات المتكررة حسب الحقول لتقليل الحجم. إنه ليس بديلاً عن Query صحيحة. يمكن أن يخفي Suppression حسب host.name تطورًا إذا كان نفس Host ينتج عدة Behaviors مختلفة. اختر الحقول التي تمثل وحدة التحقيق، على سبيل المثال host.id و-process.hash، وحدد Window من Baseline.

تستثني Exceptions التطابقات المعروفة. أنشئ Exception محدودة: Hash موقّع، Path، Parent معين ومجموعة Host محددة، بدلاً من استثناء process.name في جميع أنحاء المنظمة. أضف Comment, Owner وتاريخ Review. عندما يكون ذلك ممكنًا، فضل قائمة Exception مدارة على Query مع عشرات NOT clauses.

الخطوة 7: اكتب دليل تحقيق

دليل التحقيق هو مستند Markdown مرفق بالقاعدة ويظهر بجانب التنبيه. وفقًا لـ Elastic، يتم بناء دليل جيد حول Triage, Analysis و-Response، ويبدأ بالسياق وليس بقائمة Commands، ويشير إلى حقول Alert, Timeline queries و-Osquery عندما يكون ذلك مناسبًا.

يمكن الإشارة إلى الحقول الديناميكية مثل host.name أو user.name وإضافة أزرار Timeline عندما تدعم الإصدار والترخيص ذلك. اجعل الدليل قصيرًا وسهل المسح. يعمل المحلل تحت الضغط؛ الفقرات الطويلة بدون ترتيب ستبقى غير مقروءة.

الخطوة 8: التحقق والضبط

1. قم بتشغيل Preview أو Query تاريخية وقم بتمييز أمثلة True, False و-Benign Positive.
2. اختبر القاعدة على Positive sample محاكي وعلى Negative sample. تأكد من أنها تفشل عندما يكون الحقل مفقودًا ولا تنشئ تطابقًا خاطئًا.
3. قم بالتشغيل في البداية بدون Response خطيرة. قم بقياس Alert volume, أوقات التحقيق وجودة Context.
4. تحقق من Rule execution status, gaps, permissions و-API key. يتم تشغيل القواعد بصلاحيات المستخدم الأخير الذي قام بتحريرها.
5. قم بضبط Query, Schedule, Suppression و-Exceptions بشكل منفصل لمعرفة ما الذي حل المشكلة.
6. قم بإجراء Regression test بعد تحديث Integration, ECS mapping أو Elastic version.

قائمة التحقق

• ✓نوع القاعدة مناسب للسؤال.
• ✓Indices, Data view, ECS و-Required fields تم فحصها.
• ✓الاستعلام يعيد وحدة تحقيق واضحة.
• ✓Schedule و-Lookback يغطيان Delay بدون تكرار مفرط.
• ✓Severity, Risk و-MITRE تتوافق مع السلوك.
• ✓Suppression و-Exceptions محدودة وموثقة.
• ✓Investigation Guide يتضمن Triage, Analysis و-Response.
• ✓يوجد Owner, Review date, Metrics و-Regression test.

أخطاء شائعة

• اختيار EQL, KQL أو ES|QL حسب التفضيل وليس حسب السؤال.
• نسخ Prebuilt Rule دون التحقق من Data requirements.
• الافتراض أن ECS معينة لأن الحقل يظهر في بعض الأحداث.
• زيادة Lookback دون فهم التكرارات.
• إنشاء Exception واسعة على Process name.
• تشغيل Response التلقائي قبل Validation.
• كتابة Investigation Guide يحتوي فقط على “تحقق مما إذا كان خبيثًا”.

ملخص ودعوة للعمل

اختر عملية وهمية في المختبر وقم ببناء قاعدة كاملة: Data contract, Query, Schedule, Risk, Exception واحدة، Investigation Guide و-Test cases. ثم اطلب من محلل آخر التحقيق في Alert بدون شرح شفهي. إذا لم يكن الدليل والحقول كافيين، قم بتحسين القاعدة قبل إضافة المزيد من المنطق.

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