Detection Engineering: كيف نحول السلوك الخبيث إلى قاعدة اكتشاف

تعريف حالة الاستخدام (Use Case)

موضوع 'تعريف حالة الاستخدام' هو جزء أساسي من العمل على Detection Engineering. يُنصح بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. هذه الأسئلة تمنع الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل use case, data contract, logic, unit tests, tuning، قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للاختبار من قبل محلل آخر، بما في ذلك القيود والخطوات التالية.

تخطيط القياس عن بعد و ATT&CK

موضوع 'تخطيط القياس عن بعد و ATT&CK' هو جزء أساسي من العمل على Detection Engineering. يُنصح بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. هذه الأسئلة تمنع الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل use case, data contract, logic, unit tests, tuning، قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للاختبار من قبل محلل آخر، بما في ذلك القيود والخطوات التالية.

كتابة المنطق (Logic)

موضوع 'كتابة المنطق' هو جزء أساسي من العمل على Detection Engineering. يُنصح بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. هذه الأسئلة تمنع الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل use case, data contract, logic, unit tests, tuning، قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للاختبار من قبل محلل آخر، بما في ذلك القيود والخطوات التالية.

الاختبار، الضبط، والتحقق (Testing, Tuning, Validation)

يبدأ الاختبار الاحترافي لـ Detection Engineering بشروط النجاح وشروط الفشل. يتم تعريف حالة إيجابية، حالة سلبية، حالة حدودية، ونشاط مشروع مماثل. بهذه الطريقة يمكن تحديد كل من False Negative و False Positive.

في البيئة المصرح بها، يتم استخدام إجراء بسيط يثبت الادعاء دون التسبب في ضرر. يتم الاحتفاظ بالمدخلات، والمخرجات، والوقت، والإصدار، وبعد التصحيح يتم إجراء Retest في نفس السيناريو ويتم أيضًا فحص Regression على الوظائف القريبة.

النشر، المراقبة، والإيقاف (Deployment, Monitoring, Retirement)

موضوع 'النشر، المراقبة، والإيقاف' هو جزء أساسي من العمل على Detection Engineering. يُنصح بتقسيمه إلى ثلاثة أسئلة: ما هو المدخل، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. هذه الأسئلة تمنع الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، قم بتسجيل use case, data contract, logic, unit tests, tuning، قارنها بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للاختبار من قبل محلل آخر، بما في ذلك القيود والخطوات التالية.

نقاط اختبار فريدة

في هذا الموضوع، يُنصح ببناء خريطة أدلة مركزة مسبقًا. نقاط الاختبار الرئيسية هي: use case, data contract, logic, unit tests, tuning, deployment, coverage. القائمة ليست قائمة تحقق تلقائية؛ تم اختيار كل عنصر لأنه يمكن أن يربط بين كيان، وإجراء، ووقت أو يشرح سلوكًا مشروعًا.

• use case: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.
• data contract: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.
• logic: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.
• unit tests: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.
• tuning: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.
• deployment: حدد القيمة المتوقعة، وما سيعتبر شاذًا، وأي مصدر إضافي سيؤكد النتيجة.

عندما يكون أحد النقاط غير متاح، يجب توثيق الفجوة واختيار بديل. على سبيل المثال، إذا كان Process identifier غير مستقر، يمكن الاستعانة بالوقت، والمضيف (Host)، والمستخدم (User)، والعملية الأم (Parent)؛ إذا كان Payload مشفرًا، يتم استخدام Metadata، والحجم، والتردد، وسياق TLS/DNS.

سير العمل الموصى به

1. حدد النطاق (Scope) وسؤال عمل واحد حول Detection Engineering.
2. سجل مصادر البيانات والأدلة المطلوبة: use case, data contract, logic, unit tests.
3. أنشئ خط أساس قصير للسلوك السليم أو النتيجة المتوقعة.
4. قم بإجراء الاختبار الأدنى في بيئة معملية واحفظ الوقت، المدخلات، والمخرجات.
5. قم بإنشاء جدول زمني (Timeline) أو جدول مقارنة وافصل بين الحقيقة والتفسير.
6. قم بإجراء Pivot لمصدر إضافي لتأكيد أو دحض التفسير الأولي.
7. لخص القرار، القيود، الإجراء الموصى به، ومعيار Retest.

سيناريو عملي

السيناريو المختار هو Design document لقاعدة اكتشاف واحدة. الهدف من التمرين ليس إثبات القدرة على الهجوم، بل ممارسة جمع، مقارنة، وتوثيق بطريقة آمنة. قبل بدء العمل، يتم تعريف بيانات وهمية، نافذة زمنية، ونتيجة متوقعة.

في نهاية التمرين، يجب تقديم ناتج يمكن لمحلل أو مختبر آخر مراجعته: صورة أو Export للدليل، جدول زمني قصير، افتراض أولي، دليل مؤكد، قيد، وتوصية. عندما لا يكون هناك دليل كافٍ، فإن الاستنتاج الصحيح هو أن السيناريو لم يثبت.

قائمة التحقق العملية (Checklist)

• ✓تحقق ووثق: الفرضية (Hypothesis).
• ✓تحقق ووثق: تقنية ATT&CK.
• ✓تحقق ووثق: مصادر البيانات (Data sources).
• ✓تحقق ووثق: منطق الاكتشاف (Detection logic).
• ✓تحقق ووثق: السلوك الحميد المتوقع (Expected benign behavior).
• ✓تحقق ووثق: حالات الاختبار والتغطية (Test cases و coverage).
• ✓اذكر المنطقة الزمنية (Time zone)، إصدار الأداة، ووقت التجميع.
• ✓احفظ البيانات الخام قبل التصفية أو التغيير.
• ✓اكتب ما تثبته النتيجة وما لا يزال مجهولاً.
• ✓حدد المالك والإجراء التالي مع تاريخ محدد.

أخطاء شائعة

• البدء من IOC عشوائي بدون فرضية (Hypothesis).
• تخطيط ATT&CK بالاسم فقط.
• كتابة قاعدة (Rule) بدون حالات اختبار (Test cases).
• تجاهل السلوك المشروع.
• قياس القواعد (Rules) بدلاً من التغطية (Coverage).
• عدم إدارة الإصدارات.

الخلاصة والدعوة إلى اتخاذ إجراء

Detection Engineering: كيف نحول السلوك الخبيث إلى قاعدة اكتشاف هو موضوع يربط المعرفة التقنية بانضباط العمل. ابدأ بسؤال، اجمع فقط الأدلة ذات الصلة، احتفظ بالسياق والوقت، واختر إجراءً يمكن تبريره واختباره مرة أخرى.

في مسار Cybersecurity & AI في HPI، يتم ممارسة هذه المبادئ باستخدام الأنظمة، والسجلات، والمختبرات. الانتقال الطبيعي هو الانتقال إلى المقالات المرتبطة، وإجراء تمرين المختبر، وحفظ الناتج كجزء من ملف الأعمال المهني.

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