EQL مقابل ES|QL: متى تستخدم كل لغة في تحقيقات الأمن

ما الذي تحله EQL

تعتبر EQL مناسبة بشكل خاص للتسلسلات المرتبة زمنيًا. يمكن للقاعدة البحث عن Process start متبوعًا بـ Network event من نفس process.entity_id. يمكن ربط الأحداث حسب حقل مشترك باستخدام by، وتحديد Timestamp وEvent category وTiebreaker، وحتى البحث عن Missing events في سيناريوهات معينة.

الميزة هي أن المنطق يعكس قصة: حدثت المرحلة أ قبل المرحلة ب. بدلاً من تلخيص نوعين من الأحداث في نفس النافذة وافتراض أنها مرتبطة، تتحقق EQL من الترتيب ومفتاح الربط. لذلك فهي مفيدة لـ Process chains، وAuthentication sequences، وFile ثم Process، أو حدث متوقع لم يصل.

sequence by process.entity_id
  [process where event.type == "start" and process.name == "lab-tool.exe"]
  [network where event.type == "connection" and network.direction == "egress"]

يستخدم المثال اسمًا وهميًا وبيانات معملية. يبحث عن Process يتبعه Network connection من نفس الكيان Process. لا يثبت الخبث؛ يجب التحقق من Destination وSigner وParent وUser وHost context.

ما الذي تحله ES|QL

تعمل ES|QL على الجداول وتدعم معالجة Pipeline. تبدأ بـ FROM، وتصفّي بـ WHERE، وتنشئ حقولًا بـ EVAL، وتلخص باستخدام STATS ... BY، وتفرز وتعرض Columns. يحول الكشف من نوع ES|QL كل صف نتيجة إلى Alert.

إنه مناسب عندما يكون السؤال كميًا أو يتطلب Transformation: كم عدد المضيفين الذين قاموا بتشغيل أداة معينة، ما هي المستخدمين الذين أنشأوا حجمًا غير عادي، ما هي النسبة بين النجاح والفشل، أو ما هو الحقل المحسوب الذي يتجاوز Threshold. ليس الخيار الطبيعي عندما يكون ترتيب الحدث أ ثم ب هو الأهم؛ توصي Elastic باستخدام EQL للتسلسلات المرتبة.

FROM logs-endpoint.events.*
| WHERE event.category == "process" AND event.type == "start"
| WHERE process.name == "lab-tool.exe"
| STATS executions = COUNT(*), hosts = COUNT_DISTINCT(host.id) BY user.name
| WHERE executions >= 5

يلخص هذا الاستعلام عمليات التشغيل حسب المستخدم ويصفّي المستخدمين بخمس عمليات تشغيل أو أكثر. يجيب على سؤال مختلف عن EQL: "من قام بتشغيل الأداة عدة مرات وعلى كم عدد المضيفين؟"، وليس "هل أنشأ Process معين اتصالًا بعده؟"

Sequence مقابل Pipeline

السيناريو نفسه بطريقتين

لنفترض أن السيناريو العام هو أداة معملية تسمى lab-tool.exe والتي قد تعمل في سياق غير عادي. أولاً، نحدد السؤال الدقيق:

• سؤال EQL: هل بدأ مثيل معين للأداة ثم أنشأ Network connection؟
• سؤال ES|QL: ما هي المستخدمين أو المضيفين الذين قاموا بتشغيل الأداة بتردد غير عادي؟
• سؤال Custom query: هل تم تشغيل الأداة على الإطلاق مع Parent غير متوقع؟

يمكن أن تدعم الأسئلة الثلاثة نفس Use Case، لكنها ليست متساوية. توفر EQL ارتباطًا زمنيًا. توفر ES|QL Baseline أو Aggregation. توفر Custom query مطابقة مباشرة. يمكن أن تستخدم Detection architecture الجيدة عدة Rules، ولكن يجب تجنب التكرار وتحديد ما تضيفه كل Rule.

متطلبات البيانات

تتطلب EQL Timestamp موثوقًا وEvent category. تستفيد التسلسلات من Tiebreaker عندما تتشارك الأحداث نفس الوقت. يجب أن يكون حقل الربط ثابتًا: process.entity_id أفضل عادةً من process.name، لأنه يمكن لعدة Processes مشاركة الاسم. إذا كان entity_id مفقودًا أو يتغير بين المصادر، فلن يعمل Sequence كما هو متوقع.

تتطلب ES|QL أن تكون Indices قابلة للوصول وأن تتطابق الحقول مع الأوامر. قد يؤدي Aggregation على Field من نوع text بدلاً من keyword، أو قيم Null، أو Schema غير متناسقة إلى تغيير النتائج. في Detection Rule، يجب مراعاة Deduplication للـ Alerts، وSchedule وLookback. تتغير بعض القدرات ومتطلبات Metadata بين إصدارات Elastic، ولذلك يجب التحقق من وثائق الإصدار.

المزايا والقيود

مزايا EQL

• تعبر عن ترتيب الأحداث بشكل قابل للقراءة.
• تربط المراحل حسب كيان مشترك.
• مناسبة لـ Process lineage والتسلسلات السلوكية.
• يمكنها التعبير عن عدم وجود حدث متوقع في السيناريوهات المدعومة.

قيود EQL

• ليست الأداة الطبيعية لـ Aggregation المعقدة والإحصائيات.
• تعتمد بشكل كبير على Timestamp، event.category وKey ثابت.
• قد يكون Sequence الواسع جدًا مكلفًا أو مزعجًا.

مزايا ES|QL

• Pipeline واضح للتصفية، الحساب والـ Aggregation.
• إنشاء حقول مشتقة باستخدام EVAL.
• STATS ... BY يسمح بالكشف عن القيم المجمعة.
• مناسبة لـ Hunting والتقارير الجدولية.

قيود ES|QL

• لا تحل محل EQL عندما يكون ترتيب الأحداث هو المتطلب المركزي.
• كل Row تتحول إلى Alert، لذلك يجب تخطيط Grain للنتيجة.
• يمكن لـ Aggregation أن تفقد سياق Raw event إذا كان Investigation Guide لا يوفر Drill-down.

مصفوفة الاختيار

تمرين معملي

1. أنشئ خمسة أحداث Process وهمية وحدثين Network مع process.entity_id.
2. اكتب EQL تعيد Sequence فقط عندما يأتي Network بعد Process على نفس الكيان.
3. اكتب ES|QL تلخص عدد العمليات حسب user.name وhost.id.
4. غيّر Timestamp لحدث واحد وافحص ماذا يحدث للتسلسل.
5. أزل process.entity_id من حدث وافحص كيف تؤثر جودة البيانات.
6. اكتب لكل استعلام جملة: ماذا يثبت، ماذا لا يثبت، وما هو Drill-down المطلوب.

أخطاء شائعة

• استخدام ES|QL لمحاكاة Sequence معقدة عندما تكون EQL مناسبة.
• استخدام EQL لسؤال هو Count بسيط.
• الربط حسب process.name بدلاً من كيان ثابت.
• تجاهل Time zone، وIngestion delay وTiebreaker.
• تحويل Aggregation إلى صف Alert بدون حقول تسمح بالتحقيق.
• نسخ Query من إصدار آخر بدون التحقق من Syntax ومتطلبات Metadata.

الخلاصة و CTA

قبل كتابة Query، اكتب السؤال على ورقة: هل أبحث عن Event، Sequence، Count، Transformation، IOC أو Anomaly؟ يأتي اختيار اللغة تلقائيًا تقريبًا من الإجابة. في تدريب HPI، يوصى بالاحتفاظ بنفس Telemetry وتشغيل EQL وES|QL عليها، لمعرفة كيف يغير نموذج السؤال نتيجة التحقيق.

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