LLMs in Detection Engineering

السلام عليكم ورحمة الله وبركاته

في هذا المقالة أقدّم خلاصة من الفصل الرابع من كتاب Automating Security Detection Engineering، وهو فصل يتمحور حول كيفية توظيف نماذج اللغة الضخمة (LLMs) في تطوير الـ Use Case Development، وتحسين عمل مهندسي الكشف (Detection Engineers) في مراحل التحليل، والبحث، وصياغة الـ detection rules.

يوضّح الفصل أن الذكاء الاصطناعي —وبالتحديد LLMs— ما هو إلا نظام إحصائي متطور قادر على فهم اللغة الطبيعية وتوليد محتوى جديد بناءً على المدخلات.

هذه النماذج ليست بديلاً كاملاً للـ Detection Engineers، لكنها أداة قوية تساعدهم على تنظيم الأفكار، تحليل البيانات، التلخيص، واقتراح منطق كشف لم يكن ظاهرًا بشكل مباشر.

وبما أن هذه النماذج تعتمد بشكل كبير على وضوح التعليمات والمعلومات المقدمة لها، فإن طريقة استخدامها هي ما يصنع الفارق الحقيقي بين نموذج “يتخبط” ونموذج يتحول إلى مساعد فعّال.

وانطلاقًا من هذا المفهوم، يعرض الفصل منهجية عملية تساعد الـ Detection Engineers على توظيف الـ LLMs بشكل صحيح، وذلك عبر مجموعة من الأسس التالية:

1. وضوح الهدف من الـ Prompt

الكتاب يؤكد أن النموذج لا يمكنه “استنتاج” ما تريده، بل يعتمد بالكامل على وضوح الطلب.

لماذا مهم؟

لأن أي غموض في المهمة سينعكس مباشرة على جودة المخرجات.

مثال:

بدل: اكتب لي قاعدة كشف،
استخدم:
اكتب قاعدة Sysmon تعتمد على Event ID 1 لكشف إساءة استخدام certutil.exe لتنزيل ملفات عبر URL.

كل معلومة إضافية تقلل هامش الخطأ وتزيد دقة النتائج.

2. معاملة الـ Prompt كدالة ( Function Inputs )

الكتاب يوضح أن الـ prompt يجب أن يُكتب كما لو أنك تمرّر معطيات إلى دالة برمجية.

المقصود بذلك:

تحديد ما تريده بدقة وكأنك تحدد parameters.

مثال:

تحديد الأسلوب، التنسيق، مستوى التفصيل، وحدود الإجابة مثل:
استخدم Markdown ، اجعل الرد فقرتين، لا تذكر أمثلة تنفيذ

3. تنظيم الطلب باستخدام Markdown

التنظيم الواضح يجعل النموذج يفهم هيكل المهمة بشكل أفضل.

لماذا Markdown؟

لأنه يساعد النموذج على تقسيم السياق وترتيب الأفكار بما يشبه طريقة تفكير الإنسان.

مثال:

    ## الهدف
    تحليل سلوك `mshta.exe`

    ## المطلوب
    - أمثلة على إساءة الاستخدام
    - قاعدة كشف `SIEM`
    - ربط السلوك بـ `MITRE ATT&CK`

هذا الهيكل يجعل الإجابات أوضح، وأسهل في القراءة والاستخدام.

4. استخدام صيغة الأمر المباشر

الكتاب يوصي بأن تتعامل مع النموذج باعتباره منفّذ تعليمات.

لماذا؟

لأن لهجة الاستفهام تعطي النموذج مساحة للتفسير، بينما صيغة الأمر تضبط المخرجات وتجعلها أدق.

مثال:

بدل: هل يمكنك شرح…؟

استخدم: اشرح كيفية إساءة استخدام regsvr32.exe مع مثال واحد.

بهذا تقل احتمالية الردود الفضفاضة أو غير المفيدة.

5. تعريف “الحقيقة” Truth Source

هذه النقطة من أهم ما يركّز عليه الفصل.

ما المقصود؟

أن النموذج يجب أن يعرف ما هي المصادر المعتمدة التي يجب أن يستند إليها لكي لا ينسج معلومات غير دقيقة.

كيف يتم ذلك؟

عبر تزويده بمراجع صحيحة مثل:

• مراجع من Splunk أو Sigma أو LOLBAS ( بحسب طبيعة المشروع الذي يخدمه النموذج )
• وثائق Microsoft الرسمية
• بيانات MITRE ATT&CK

النتيجة:

مخرجات ثابتة ودقيقة ومتوافقة مع “الحقيقة” التي حدّدتها أنت.

6. تحديد شكل المخرجات المتوقعة

يشير الكتاب إلى أن النماذج تقدم أفضل النتائج عندما يتم تحديد شكل المخرجات مسبقًا، مثل:

• طول النص
• عدد النقاط
• هل يتضمن أمثلة؟
• هل يتضمن جدول؟
• هل يتضمن Code Snippet؟

مثال:
قدّم ملخّصًا من 4 نقاط، كل نقطة جملة واحدة، بدون أي أمثلة.

7. تكرار التعديل Iterative Prompting

الكتاب يشدد على أن أفضل النتائج تأتي من البناء التدريجي للـ prompt.

• تبدأ بـ prompt أساسي
• تلاحظ النتائج
• تعدّل
• تضيف سياق
• تضبط الأسلوب
• تقدّم النموذج حتى يصل للنسخة الدقيقة

تمامًا مثل كتابة كود وتعديله.

8. استخدام أسلوب الـ Pair Programming مع الـ LLMs

يقترح الفصل استخدام النموذج كزميل عمل تقني بدلاً من اعتباره مجرد أداة توليد.

أي الدخول معه في أسلوب يشبه الـ Pair Programming حيث يشاركك التفكير، يطرح أسئلة، يراجع المنطق، ويقترح تحسينات قبل كتابة النتيجة النهائية.

فيما يلي نماذج إضافية مختصرة يمكن استخدامها ضمن نفس الفكرة:

• جعل النموذج يعمل كمراجع تقني عبر طلب مراجعة القاعدة واقتراح تعديلات قبل اعتمادها.
• استخدامه لإنتاج عدة نسخ من نفس القاعدة لمقارنتها واختيار الأفضل.
• تكليفه بشرح تفكيره خلف كل تعديل.
• استخدامه لتوليد سيناريوهات إضافية أو فرضيات هجوم مرتبطة بالقاعدة لتحسين تغطيتها.
• الطلب منه اكتشاف نقاط الضعف أو blind spots الموجودة في منطق الـ Detection Rule المقترح.

وبذلك تتضح الفلسفة الأساسية لعمل الـ LLMs في مجال الـ Detection Engineering:

أنها أدوات فعّالة فقط عندما تُستخدم بشكل منهجي ، أي عبر كتابة prompt واضح، وتحديد “الحقيقة” التي يعتمد عليها النموذج، وضبط الإخراج بحيث يخدم المهمة بدقة.

وبما أن الـ Detection Engineer يتعامل يوميًا مع كميات كبيرة من البيانات وأساليب هجوم متنوعة، فإن نموذجاً لغويًا جيدًا لا يحل محله، لكنه يتحول إلى مُسرّع للعمل، يقلل الوقت المستغرق في التحليل وبناء قواعد الكشف.