سير عمل منظم لتحويل استخبارات التهديدات السيبرانية إلى أنماط كشف قابلة للحوسبة

ملخص

هنا، نقدم بروتوكولا لتحويل مؤشرات الاختراق من تقارير استخبارات التهديدات السيبرانية، ومسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر إلى تعبيرات منتظمة معتمدة لقواعد كشف معلومات الأمن وإدارة الأحداث (SIEM)، باستخدام الاستخراج الجماعي مع نماذج اللغة الكبيرة (LLMs) وتصنيف المكونات بمساعدة الرسوم البيانية.

الملخص

تقوم مراكز عمليات الأمن (SOCs) بتحويل تقارير استخبارات التهديدات السيبرانية (CTI) بشكل روتيني إلى محتوى كشف تشغيلي. عنق زجاجة مستمر في هذا سير العمل هو ترجمة مؤشرات الاختراق المستخرجة (IOCs)، وخاصة مسارات الملفات، ومفاتيح السجل، وسلاسل أسطر الأوامر إلى تعبيرات منتظمة قابلة للنشر (regexes) مناسبة لتضمين قواعد الارتباط في معلومات الأمان وإدارة الأحداث (SIEM). على الرغم من أن الأعمال السابقة حسنت استخراج مؤشر الاختراق الآلي (IOC)، إلا أن تحويل السلاسل المستخرجة إلى أنماط regex معتمدة لا يزال يدويا إلى حد كبير، ويتطلب خبرة متخصصة، وعرضة للأخطاء. هدف هذا البروتوكول هو توفير إجراء موحد وقابل للتكرار للترجمة من IOC إلى REGEX. يتكون سير العمل من خمس مراحل: (1) تحليل تقارير CTI غير المتجانسة في تمثيل موحد لماركداون؛ (2) استخراج IOC باستخدام نماذج لغوية كبيرة متعددة (LLMs) مع تصويت توافقي؛ (3) التطبيع والتصنيف وإزالة التكرار القائم على القواعد من مراكز IOC المستخرجة؛ (4) التصنيف المدعوم بالرسم البياني لمكونات IOC كالاحتفاظ (مجموعة الالتقاط) أو التخلص (مجموعة غير الالتقاط); و(5) توليد الريجيكس التكراري مع التحقق التشخيصي ضد سلاسل IOC الأصلية. لتقييم المنفعة، تم تطبيق سير العمل على 3,156 تقرير CTI، وتم تقييم السجلات الناتجة مقابل أكثر من 2,400 سلسلة حقيقة أرضية جمعت بشكل مستقل من عشرة سيناريوهات تقييم تكتيكات وتقنيات ومعرفة مشتركة (ATT&CK) من MITRE، مما أدى إلى متوسط معدل إصابة 99.1٪ ومتوسط معدل عدم تطابق بين IOC بلغ 0.8٪. لذلك يوثق البروتوكول تنفيذا قابلا لإعادة إنتاج الترجمة من IOC إلى regex ويحدد بشكل صريح نطاقه الحالي، وافتراضاته التشغيلية، وحالات الفشل المعروفة.

المقدمة

تستمر الجرائم الإلكترونية في فرض أعباء تشغيلية ومالية كبيرة على المؤسسات في القطاعين العام والخاص. في عام 2023، تجاوزت الخسائر المبلغ عنها بسبب الجرائم الإلكترونية في الولايات المتحدة 12.5 مليار دولار^واحد، مما يبرز حجم واستمرارية النشاط الخبيث. ضمن هذا المشهد، تعمل مراكز عمليات الأمن (SOCs) كوحدات تشغيلية رئيسية مسؤولة عن اكتشاف التهديدات وتحليلها والاستجابة لها في الوقت الفعلي.
يتم تنفيذ منطق الكشف في العديد من سير عمل SOC من خلال آليات قائمة على القواعد ضمن منصات إدارة معلومات وأحداث الأمان (SIEM)، والتي تستخدم على نطاق واسع لأنها قابلة للتفسير، وحتمية، ومتوافقة مع سير عمل SOC الحالية. من بين أنواع القواعد المختلفة، تعد قواعد SIEM القائمة على الارتباط مهمة بشكل خاص لتحديد سلوكيات الهجوم التي تمتد عبر عدة أحداث ومضيفين ونوافذ زمنية. ضمن هذه القواعد، تعمل التعبيرات المنتظمة (regexes) كبدائية قابلة لإعادة الاستخدام: حيث يقوم المحللون بتضمينها ضمن قواعد كشف أوسع تضيف قيود ميدانية، ومرشحات خاصة بالمنصة، ومنطق ارتباط الأحداث، بدلا من نشرها ككواشف مستقلة.

في الواقع، غالبا ما يبدأ محللو SOC تطوير القواعد بمؤشرات الاختراق (IOCs) المستمدة من تقارير استخبارات التهديدات السيبرانية (CTI) التي تنشرها شركات الأمن أو الباحثون المستقلون أو قواعد المعرفة العامة مثل MITRE لتكتيكات وتقنيات ومعرفة مشتركة (ATT&CK)². قد تشمل هذه السلاسل النصفية لملفات المفات، أو أجزاء سطر الأوامر، أو مفاتيح السجل، أو أي تشويشات هيكلية أخرى لوحظت أثناء الهجمات³. ترجمة مثل هذه السلاسل إلى أنماط regex المناسبة لقواعد الارتباط SIEM هي مهمة متكررة في سير عمل تأليف القواعد.

تعد هذه الخطوة العملية في الترجمة عنق زجاجة عملي. كتابة أنماط ريجيكس عامة بما يكفي لالتقاط التنوع المهم ولكنها دقيقة بما يكفي لتجنب المطابقات غير المقصودة تتطلب خبرة متخصصة؛ الأخطاء النحوية الصغيرة أو القرارات الخاطئة حول المكونات التي يجب الحفاظ عليها أو تعميمها يمكن أن تجعل قاعدة الكشف المفيدة غير فعالة. نظرا لأن هذا العمل يدوي ومتكرر ودقيق، فقد يؤخر نشر الكشف عن التهديدات الناشئة، ويتطلب مراجعة من محللين أكثر خبرة، ويساهم في عبء عمل المحللين في إعدادات SOC التشغيلية^4،5.

التحدي المركزي في ترجمة IOC إلى regex هو تحديد أي أجزاء من IOC ترمز سلوكا مستقرا وذو صلة بالمهاجم وبالتالي يجب الحفاظ عليها، وأي الأجزاء تعكس تباينا خاصا بالبيئة أو المضيف ويجب تعميمها. على سبيل المثال، يجب عادة أن تبقى جذور السجل الرسمي مثل HKEY_CLASSES_ROOT\CLSID، ومجلدات النظام مثل System32، والأسماء التنفيذية المعروفة مثل rundll32.exe صريحة، بينما عادة ما يجب تجريد مسارات ملفات المستخدم، ومعرفات الأمان الخاصة بالمضيف (SIDs)، والمعرفات الفريدة عالميا (GUIDs). القيام بذلك باستمرار عبر أنواع IOC المختلفة هو ما يجعل مهمة الترجمة غير بسيطة. طوال هذا البروتوكول، نشير إلى الأولى كمكونات محفوظة أو مجموعة أسر، والثانية بأنها مكونات مجردة أو مجموعة غير أسر.

استكشفت الأعمال السابقة الاستخراج الآلي لاستخبارات التهديدات من النصوص غير المنظمة باستخدام تقنيات معالجة اللغة الطبيعية واستخراج الكيانات ^6,7. مؤخرا، بحثت عدة دراسات في التوليد المباشر لقواعد الكشف من تقارير CTI باستخدام نماذج اللغة الكبيرة (LLMs)⁸. تظهر هذه الأساليب أن أجزاء من سير عمل تأليف القواعد يمكن أن تساعدها نماذج اللغة، لكنها عادة لا تركز على المشكلة التشغيلية المحددة لتوليد أنماط regex التي تحافظ على دلالات مجموعات الالتقاط وتظل مناسبة لنشر SIEM لاحقا. خطوط العمل التكميلية تحتوي على محتوى CTI منظم للاستخدام لاحقا بطرق مختلفة، بما في ذلك التمثيلات القائمة على الرسوم البيانية المعرفية مثل TINKER⁹ وتوليد استعلامات البحث عن السجلات المدفوعة بتقنية CTI مثل ThreatRaptor¹⁰، التي تحول CTI غير المهيكلة إلى لغات معرفة منظمة أو استعلام خاصة بالمجال بدلا من أنماط regex المخصصة للتضمين في قواعد الارتباط SIEM.

بالتوازي، استكشفت دراسات سابقة التخليق الآلي للريجيكس باستخدام طرق قائمة على الأمثلة، والترجمة العصبية، وطرق التوليد والإصلاح 11,12,13,14,15,16. ومع ذلك، فإن هذه الطرق مصممة عادة لإعدادات تعتمد على مجموعات كبيرة من الأمثلة الممثلة أو الوصف باللغة الطبيعية بدلا من سياقات الكشف المدفوعة ب IOC. في سير عمل SOC، غالبا ما تكون سلاسل IOC متناثرة، متباينة هيكليا، ومرتبطة ارتباطا وثيقا بدلالات التشغيل. هذا التفاوت يحفز سير عمل مصمم لترجمة IOC إلى regex بدلا من الادعاء بأن طرق توليد الregex الحالية غير كافية إلى حد كبير.

يركز البروتوكول المعروض هنا بشكل خاص على مرحلة الترجمة من IOC إلى regex في سير عمل اكتشاف SOC. يعامل استخراج IOC كمدخل في البداية قد ينتج عن تحليل يدوي أو أدوات آلية أو مزيج من الاثنين؛ لا يحاول البروتوكول توليد قواعد SIEM كاملة. بدلا من ذلك، يوفر إجراء منهجيا لتحويل سلاسل IOC إلى أنماط regex صالحة نحويا، وقابلة للتفسير دلاليا، ومناسبة للنشر التشغيلي. نطاق IOC الحالي مقصود: مسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر تحتوي على مكونات هيكلية مستقرة ومتغير تستفيد من تعميم الريجيكس، بينما المؤشرات الذرية مثل عناوين IP والنطاقات والتجزئات يتم تشغيلها بشكل طبيعي أكثر من خلال شروط مطابقة دقيقة أو عمليات بحث بنمط السمعة، وبالتالي تقع خارج النطاق الأساسي. ضمن هذه الحدود، يقصد البروتوكول أن يكون محمولا عبر بيئات SOC التي تشترك في تنسيقات إدخال مماثلة وشروط أدوات مسبقة.

البروتوكول

استخدم سير العمل المكون من خمس مراحل التالي لتحويل تقرير CTI إلى أنماط regex معتمدة مع مخرجات وسيطة قابلة للتتبع (انظر الشكل 1 للنظرة العامة).

1. إعداد النظام

1. تثبيت المتطلبات المسبقة.
   1. قم بتثبيت بايثون 3.8 أو أحدث، وجميع تبعيات بايثون المدرجة في requirements.txt، وقاعدة بيانات بيانية Neo4j.
      1. تأكيد الوصول إلى واجهة برمجة تطبيقات واحدة أو أكثر (APIs) لنماذج اللغة الكبيرة المختارة والتحقق من تشغيل خدمة Neo4j والوصول إليها من الجهاز المحلي.
   2. تأكد من اكتمال جدول المواد.
      1. تحقق من أن تبعيات وقت التشغيل مدرجة في الصورة، بما في ذلك إصدار مفسر بايثون، تبعيات خط الأنابيب، إصدار Neo4j، وواجهة استخراج النصوص لتنسيق المستند المحمول (PDF).
      2. تحقق من إدراج خيارات تكوين نماذج اللغة الكبيرة، بما في ذلك مزودي نماذج اللغة الكبيرة، وأسماء النماذج والإصدارات، ودرجة الحرارة، وخيارات جهد الاستدلال، وإعدادات التصويت الجماعي.
      3. تحقق من إدراج صيغ الإدخال والإخراج، بما في ذلك تنسيقات ملفات الإدخال المدعومة وصيغ التصدير المدعومة.
2. تشغيل واجهة المستخدم على الويب (UI).
   1. افتح طرفية، وانتقل إلى مجلد الجذر المرجعي-التنفيذي، وابدأ التطبيق باستخدام أمر التشغيل الموثق (في تنفيذ المرجع: cd langchain_pipeline يليه streamlit run app_v2.py).
   2. تحقق من أن التطبيق يحمل عند http://localhost:8501 وأن لوحة إعدادات الشريط الجانبي مرئية.
3. قم بتكوين مزود نموذج اللغة اللغة.
   1. في قسم تكوين نماذج اللغة الكبيرة في الشريط الجانبي، اختر مزود نماذج اللغة الكبيرة، وأدخل اسم النموذج، وقدم مفتاح واجهة برمجة التطبيقات (API) صالح.
   2. سجل المزود، اسم النموذج، إصدار النموذج، درجة الحرارة، خيارات الجهد الاستدلالي، وتاريخ الوصول لجدول المواد.
      ملاحظة. في التنفيذ المرجعي، يكون استخراج IOC بوحدة LLM واحدا افتراضيا على النموذج التجاري الأساسي المدرج في جدول المواد مع درجة الحرارة = 0.0؛ توليد ريجيكس يكون الافتراضي درجة الحرارة = 0.3.
4. تمكين التصويت الجماعي (اختياري لكنه موصى به للنتائج القابلة للتكرار).
   1. تفعيل خيار التصويت الجماعي في الشريط الجانبي للاحتفاظ فقط باللجنة الأولمبية الدولية التي تحقق الحد الأدنى من الأصوات (يوصى بالحصول على الحد الأدنى للأصوات ≥ 2).
   2. أضف نسخ إضافية من نماذج اللغة الكبيرة عن طريق تحديد المزود، اسم النموذج، مفتاح واجهة برمجة التطبيقات، وعدد تكرارات التنفيذ لكل نموذج.
      1. سجل عدد التكرارات لكل مزود والحد الأدنى المختار للأصوات.
         ملاحظة. التصويت الجماعي اختياري. عند تعطيله، يقوم خط الأنابيب باستخراج نموذج لغوي واحد ويتم تخطي مرشح الإجماع. الإعدادات الافتراضية للمجموعة هي تكرارات = 1 لكل نموذج مكون و min_votes = 2.
5. اتصل ب Neo4j.
   1. في قسم اتصال Neo4j في الشريط الجانبي، أدخل رابط الاتصال (مثل bolt://localhost:7687)، واسم المستخدم، وكلمة المرور.
   2. تأكد من أن الواجهة تبلغ عن اتصال ناجح. لا تتابع بدون اتصال نشط.
6. قم بتأمين جميع بيانات الاعتماد.
   1. عامل مفاتيح واجهة برمجة تطبيقات LLM وكلمة مرور Neo4j كبيانات اعتماد حساسة. قم بتخزينها في متغيرات البيئة أو مدير الأسرار بدلا من الملفات المصدرية أو التقارير المصدرة أو لقطات الشاشة، وتدوير أي مفتاح بسرعة إذا اشتبه في وجود تسرب.
      ملاحظة. لا يتطلب هذا البروتوكول البرمجي غطاء أبخرة كيميائي، أو خزانة سلامة حيوية، أو معدات احتواء مادية أخرى؛ يتعامل مع تقارير وبيانات اعتماد CTI السرية وفقا لسياسات أمن البيانات المؤسسية.

2. المرحلة 1: تحليل المستندات

1. الإجراءات.
   1. انتقل إلى تبويب المعالجة في الواجهة الرئيسية.
   2. رفع تقرير CTI بصيغة مدعومة (.pdf، .docx، .md، .txt، أو .html).
   3. انقر على "تشغيل المرحلة التالية" لتنفيذ المرحلة الأولى، أو "تشغيل جميع المراحل" لتنفيذ خط الأنابيب الكامل بالتسلسل.
2. أكد نقطة التفتيش في المرحلة الأولى.
   1. تأكد من عرض معاينة Markdown لمستند الإدخال.
   2. تحقق من أن مسارات الملفات، ومفاتيح السجل، وأجزاء سطر الأوامر، وحدود الأقسام تبقى سليمة في المعاينة.
   3. إذا تم اقتطاع السلاسل التقنية أو تم حذف التنسيق، قم بتصحيح الملف المصدر أو قم بمعالجة المستند مسبقا باستخدام محول خارجي قبل إعادة الرفع.

3. المرحلة 2: استخراج اللجنة الأولمبية الدولية

1. الإجراءات.
   1. أكد تكوين نموذج اللغة الكبيرة (والتصويت الجماعي، إذا كان مفعلا).
   2. انقر على "تشغيل المرحلة التالية" لتنفيذ المرحلة الثانية.
2. أكد نقطة التفتيش في المرحلة الثانية.
   1. تأكد من أن الواجهة تعرض مجموعة IOC بصيغة JavaScript Object Notation (JSON) مع ثلاثة مفاتيح على المستوى الأعلى: مسارات الملفات، أسطر الأوامر، ومفاتيح السجل.
   2. عند تفعيل التصويت الجماعي، تحقق من تسجيل عد الأصوات وبيانات النموذج المساهم لكل لجنة IOC محفوظة.
      ملاحظة. يتم إصدار نظام المرحلة الثانية الحرفية والتعليمات البشرية، إلى جانب محفزات توليد وتحسين المرحلة 5، كملف تكميلي 1 (Supplemental_File_1_Prompts.txt).

4. المرحلة 3: تحليل وتصنيف اللجنة الأولمبية الدولية

1. الإجراءات.
   1. انقر على "تشغيل المرحلة التالية" لتنفيذ المرحلة الثالثة.
2. أكد نقطة التفتيش في المرحلة الثالثة.
   1. تأكد من أن كل IOC محتفظ به مدرج مع فئة موحدة، وعلامة المصدر، ومفتاح الاستخراج الأصلي عند توفره.

5. المرحلة 4: تطبيع IOC بمساعدة Neo4j

1. الإجراءات.
   1. تأكد من أن اتصال Neo4j نشط.
   2. انقر على "تشغيل المرحلة التالية" لتنفيذ المرحلة الرابعة.
   3. فحص مخرجات التطبيع لكل IOC والتحقق من أن تسميات الاحتفاظ أو التخلص تم إنتاجها لمكونات المسار وسطر الأوامر وأن مفاتيح السجل تعطي سلسلة فرعية كانونية متجاورة.
2. أكد نقطة تفتيش المرحلة 4.
   1. تأكد من أن جداول IOC الموحدة تم إنتاجها لكل نوع من IOC (مسارات الملفات، مفاتيح السجل، مؤشرات سطر الأوامر).
   2. تحقق من أن كل إدخال يتضمن القيمة الأصلية، والقيمة المطبعة، وقائمة مكونات من أزواج العناصر/الحالة التي تحمل علامة الاحتفاظ أو التخلص منها.
      ملاحظة. مخطط Neo4j التفصيلي، استعلامات Cypher، قواعد القرار، وإجراء تطبيع مفتاح السجل مدرجة في الملف التكميلي 2؛ مثال حل وحل مقدم في نتائج التمثيل.

6. المرحلة 5: توليد وتسجيل النقاط

1. الإجراءات.
   1. انقر على "تشغيل المرحلة التالية" لتنفيذ المرحلة الخامسة. تأكد من أن كل IOC موضع طبيعي وقائمة الرموز المحظورة الخاصة به تم تقديمها لتوليد regex والتحقق الحتمي.
   2. إذا فشل المرشح في التحقق من الصحة، اسمح لحلقة التحسين بتحسين الريجيكس حتى يتم إنتاج مرشح متوافق أو الوصول إلى حد التكرار.
   3. افحص المخرجات التشخيصية، وتاريخ التحسين، وعدد التكرارات لأي IOC يتراجع معدل التوازن النهائي له من متوافق إلى أعلى تطابق جزئي (مسجل ك used_fallback = صحيح).
2. أكد نقطة تفتيش المرحلة 5.
   1. تأكد من أن السجل النهائي تم إنتاجه لكل لجنة IOC المحتفظ بها.
   2. تحقق من تسجيل نتائج المرشحين، وتاريخ التحسين، وقوائم القضايا، وعدد التكرارات.
   3. تحقق من تسجيل بيانات التليمترية لكل شركة IOC، بما في ذلك تقدير استخدام الرموز وفترة التأخير.
      ملاحظة. قواعد التحقق التفصيلية للريجيكس، وصيغة التقييم، ومعلمات التحكم في التكرار مدرجة في الملف التكميلي 2.

7. التحليلات والتحقق

1. افتح تبويب التحليلات لمراجعة توزيعات اللجنة الأولى، ونتائج التصويت الجماعي (عند تفعيلها)، وملخصات جودة الريجيكس، وإحصائيات التحسين. استخدم هذه الملخصات لاكتشاف الشذوذات مثل اختلال التوازن في الاستخراج أو تكرار فشل التحسين.

8. نتائج التصدير

1. في تبويب التصدير، اختر تنسيق التصدير (نص عادي، JSON، أو YAML) وقم بتنزيل مجموعة الريجيكس. تأكد من أن السجلات المصدرة تتضمن الدرجات وبيانات التصنيف المرتبطة.
2. قم بإنشاء وتنزيل تقرير JSON الكامل الذي يحتوي على مستندات تم تحليلها، ووحدات IOC المستخرجة، والتمثيلات المطبعة، وسجلات المرشحين، والمخرجات النهائية. احتفظ بهذا التقرير كسجل قابلية للتكرار.

9. استكشاف الأخطاء وإصلاحها

1. إذا أعادت المرحلة 1 محتوى PDF مقطوع أو فارغ، قم بمعالجة المستند مسبقا باستخدام محول خارجي أو أداة تعرف بصرية على الحروف قبل إعادة الرفع، وتأكد من أن العيوب التقنية لا تزال مرئية في معاينة ماركداون.
2. إذا أعاد المرحلة 2 عددا قليلا جدا من مراكز IOC بالإجماع، تحقق من إعدادات المزود، والنموذج، ومفتاح API، وتكرار العد، وإعدادات الأصوات الدنيا قبل تغيير العتبة. فحص المرشحين المستبعدين لتمييز الهلوسات عن التصويت الصارم المفرط.
3. إذا كانت المرحلة 4 تصنف جميع المكونات كمهملة، تحقق من اتصال Neo4j وتأكد من أن الرسم البياني يحتوي على المفردات ذات الصلة بمسار أو سجل أو واجهة سطر الأوامر (CLI) لنوع IOC الذي يتم تحليله.
4. إذا أنتجت المرحلة 5 ريجيكس يترجم لكنه يفشل في المطابقة أو التعميم بشكل مفرط، افحص سجل التحسين، وموقع فشل التشخيص، وفحوصات التعميم الزائد قبل إعادة توليد المرشح.

10. تأكيد نتائج البروتوكول النهائية.

1. تأكد من أن ملف Markdown المحلل، ومجموعة IOC (التي يتم التحقق منها بالإجماع عند تفعيل التصويت الجماعي، أو نموذج واحد عند تعطيلها)، وجدول IOC المصنف، والتمثيلات الموحدة الدولية الموحدة بالرسم البياني كلها موجودة.
2. تأكد من أن مجموعة regex المتوافقة مع SIEM، وملخصات التحليلات، وتقرير JSON الكامل جميعها موجودة، وأرشف تقرير JSON كسجل قابلية التكرار.

النتائج

يقدم هذا القسم النتائج التمثيلية التي ينتجها بروتوكول اللجنة الدولية للمعايير إلى الريجيكس ويلخص التقييم المرجعي المستخدم لتقييم قابليته التشغيلية. عالج التقييم المرجعي 3,156 تقرير CTI مرتبط بتقنيات MITRE ATT&CK، وحلل أكثر من 230,000 جملة، واستخرج أكثر من 63,000 مرشح للجنة الدولية الدولية، وقيم السجلات المولدة مقابل أكثر من 2,400 سلسلة حقيقة أرضية جمعت بشكل مستقل من عشرة سيناريوهات تقييم MITRE ATT&CK. هذه السلاسل الواقعية هي قطع هجومية مختارة من خبراء تم الإبلاغ عنها بشكل مستقل من قبل بائعي الأمن السيبراني خلال تمارين تقييم MITRE ATT&CK، وبالتالي تعكس الأنماط الهيكلية التي يوثقها المحللون والبائعون البشريون عمليا. تركز النتائج أدناه على سلوك سير العمل، وصحة الهيكل، ونتائج التقييم ذات الصلة بتحليل سجلات العمليات وسير عمل الكشف.

يقدم الشكل 1 نظرة عامة على خط الأنابيب من البداية إلى الطرف، الذي يلخص مراحل إيجاد مجموعة الالتقاط وتوليد الريجيكس التي تؤطر بقية النتائج الممثلة.

المرحلة 1: تحليل المستندات

يوضح الشكل 2 مخرجات المرحلة 1، حيث يتم تحليل تقرير CTI المدخل إلى تمثيل ماركداون موحد. عند التنفيذ الناجح، تعرض الواجهة معاينة منظمة للمستند، بما في ذلك حدود الأقسام ومؤشرات الصلة.

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

المرحلة 2: الاستخراج المعتمد على الإجماع من اللجنة الأولمبية الدولية

يوضح الشكل 3 مخرجات المرحلة الثانية، حيث يتم استخراج لكنيات IOC المرشحة باستخدام التصويت الجماعي متعدد نماذج اللغة الكبيرة. تقدم الواجهة الناتجة مجموعة IOC منسقة بتنسيق JSON، مع تعليقات مع أعداد الأصوات ونماذج المساهمة.

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

المرحلة 3: تحليل وتصنيف اللجنة الأولمبية الدولية

يلخص الجدول 2 النتائج المتوقعة، وخطوات التحقق الآلي، وفحوصات مراقبة الجودة الموجهة للمحللين لكل مرحلة من مراحل البروتوكول.

يظهر الشكل 4 مرشحي اللجنة الأولمبية الدولية الذين لم يستوفوا عتبة الإجماع خلال التصويت الجماعي في المرحلة الثانية وأن واجهة الواجهة تظهر لفحص المحللين. عادة ما تعكس هذه المرشحات هلوسات خاصة بالنموذج أو شظايا نصية غامضة. لذلك، فإن الشكل 4 والشكل 5 يتوافقان مع مخرجات مرحلة مميزة — المجموعة المهملة من المرحلة 2 والمجموعة المحتجزة من المرحلة 3 — بدلا من رؤى بديلة لنفس عملية المرحلة 3.

يعرض الشكل 5 جدول IOC المحتفظ به الذي أنتجته المرحلة 3 بعد تحليل JSON، والتصنيف القائم على القواعد، وإزالة التكرار من IOC. لكل مركز IOC محتفظ، تسجل المرحلة فئة موحدة، وعلامة المصدر، ومفتاح الاستخراج الأصلي عند توفره، قبل تمرير IOC إلى التطبيع اللاحق.

المرحلة 4: تطبيع IOC بمساعدة الرسوم البياني عبر أنواع IOC

توضح الأشكال 6، الشكل 7 والشكل 8 نتائج التطبيع التمثيلية لثلاث فئات من IOC تم تناولها في الدراسة الحالية: مسارات الملفات، مفاتيح السجل، ومؤشرات سطر الأوامر. لكل فئة، تقارن الأرقام بين اللجنة الأولية الأصلية المستخرجة من تقرير CTI والتمثيل المعياري الناتج باستخدام التحليل المدعوم بالرسم البياني.

عبر جميع أنواع الأنظمة المتروكة، يقوم البروتوكول بتفكيك كل وحدة IOC إلى مكونات دلالية ويحل العلاقات الهرمية باستخدام معرفة منظمة مشفرة في قاعدة بيانات الرسوم البيانية. في التنفيذ الحالي، يخزن Neo4j عقد المسار والسجل وCLI التي تم تطبيعها ويستخدم علاقات المجاور لاختبار ما إذا كانت المكونات تنتمي إلى سلاسل معترف بها. هذا الدور مشابه لاستخدام المعرفة المنظمة ب ATT&CK أثناء هندسة الكشف².

ومن المهم أن خطوة التطبيع هذه تسجل الأدوار الدلالية الصريحة لمكونات IOC من خلال تصنيفها كاحتفاظ أو تخلص بدلا من إزالتها بصمت من سجل التحليل. يتم إعادة بناء السلسلة الموضوعية بشكل أساسي من مكونات الاحتفاظ، بينما تبقى المكونات المهملة متاحة كبيانات وصفية لتوليد والتحقق من السجلات في المراحل النهائية.

يتم الإشارة إلى التنفيذ الصحيح لهذه المرحلة من خلال عمليات التوزيع الأولي الممنوع التي تحتفظ بسياق هيكلي ذي معنى وتظهر علامات مجموعات التقاط متسقة عبر أنواع مختلفة من المركبات البحرية. توفر المقارنة البصرية بين التمثيلات الأصلية والتمثيلات المطبرة آلية عملية لضبط الجودة للتحقق من تطبيق دقة مجموعة الالتقاط بشكل متسق ودون فقدان معلومات غير مقصود.

المرحلة 5: توليد التعبيرات المنتظمة مع اختيار القيد المساعد

يوضح الشكل 9 مخرجات المرحلة 5، حيث يولد البروتوكول تعبيرات منتظمة متوافقة هيكليا من مراكز IOC الموحدة من خلال سير عمل تحقق تكراري. يجمع التنفيذ بين طلب التوليد الأولي، وإعادة التوجيه التشخيصي عندما يفشل المرشح في مطابقة ال IOC، والتحقق الواعي بالرفض، وحلقات إعادة المحاولة المقيدة.

بالنظر إلى وجود IOC موضع طبيعي ومواصفات مكون الاحتفاظ أو التخلص المرتبطة به، يبدأ سير العمل أولا بتوليد مرشح ريجيكس أولي. ثم يتم اختبار المرشح مقابل IOC، ويعاد استدعاؤه تشخيصيا عند فشل المطابقة، ويتم التحقق من الرموز المهملة المحظورة، وتقييمه للتعميم المفرط باستخدام سلاسل سلبية عشوائية.

عندما يستوفي عدة مرشحين فحوصات التحقق الأساسية، يطبق البروتوكول آلية اختيار مساعدة قائمة على القيود للاحتفاظ بسجل ريجيكس ممثل للاستخدام في مرحلة لاحقة. يمنح التطبيق الحالي المرشحين تقييمات ب 'الدرجة = n_cg - n_wc'، حيث 'n_cg' هو عدد مكونات الاحتفاظ الممثلة و'n_wc' هو عدد الرموز المهملة أو غير المخصصة الموجودة في الريجيكس.

تعرف دالة الاختيار على النحو التالي:

النتيجة = n_cg − n_wc

هذا هو التخصص بالوزن المتساوي (α = β = 1) للشكل الأكثر عمومية: Score = α·n_cg − β·n_wc. هنا، n_cg تشير إلى عدد مكونات الاحتفاظ الممثلة وتشير n_wc إلى عدد المكونات المهملة أو الرموز الإضافية غير المبرمجة التي أعيد إدخالها بواسطة الريجيكس. يسجل التنفيذ أيضا أعداد التكرارات، وقوائم المصادر، واستهلاك الرموز المقدر، واستخدام الكاش، وقياس الكمون لكل مركز IOC. تم استخدام إعداد الوزن المتساوي كإعداد افتراضي حتمي بسيط لتنفيذ المرجع؛ ونظرا لأنها تعامل مكون الاحتفاظ المفقود ومكون التخلص المعاد إدخالها كغير مرغوب فيهما بنفس القدر، فقد تفضل أوزان أخرى في سياقات النشر حيث تحمل السلبيات الكاذبة والإيجابيات الكاذبة تكاليف تشغيلية مختلفة.

يتم اختيار الريجيكس النهائي كمرشح يحقق هذه القيود بشكل أفضل. الريجيكس التي تضع مكونات مجموعة الالتقاط المطلوبة داخل البنى الاختيارية، مثل ( ... )؟، تستبعد من الاختيار لأنها تضعف الاتساق الدلالي. تعد خطوة الاختيار هذه مساعدة لعملية التوليد وليست مقصودة أن تكون مقياسا مستقلا للجودة.

نظرة عامة على تحليلات معالجة CTI

يوفر الشكل 10 نظرة عامة على نتائج تحليل CTI عبر جميع الوثائق المعالجة. في التقييم المرجعي، أنتج استخراج IOC على 3,156 تقرير CTI أكثر من 63,000 مرشح IOC، بما في ذلك 12,195 مسار ملف، و2,302 مفتاح سجل، و10,286 مؤشر سطر أوامر، مع المرشحين المتبقيين من أنواع IOC غير مستهدفة للريجيكس.

توفر هذه العدات تأكيدا على مستوى عال بأن المؤشرات المستخرجة مركزة في الفئات الثلاث لمراكز IOC المستهدفة من قبل البروتوكول الحالي، كما تظهر أن العديد من القطع الأثرية المستخرجة لا تزال خارج نطاق توليد الريجيكس. عند إعادة إنتاج سير العمل، أبلغ عن العدد الدقيق لتقارير CTI المعالجة، وإجمالي مرشحي IOC، وعدد الفئات، والمزود، والنموذج، وإصدار النموذج، ودرجة الحرارة، وعدد التكرارات، وعتبة الإجماع المستخدمة أثناء الاستخراج.

في التقييم المرجعي، تم تقييم الريجيكس المولدة مقابل أكثر من 2,400 سلسلة حقيقة أرضية جمعت بشكل مستقل من عشرة سيناريوهات تقييم MITRE ATT&CK وحققت متوسط معدل إصابة 99.1٪ مع متوسط معدل عدم تطابق بين IOC بلغ 0.8٪. في هذه المخطوطة، يستخدم معدل عدم التوافق كمقياس لتحديد الدلالة: يحدث عدم التوافق عندما يتطابق السجل الصادر لإحدى وحدات IOC أيضا مع سلسلة حقيقة أرضية مرتبطة بمجموعة IOC مختلفة. لا ينبغي تفسير هذا الكم على أنه معدل إيجابي كاذب من البداية إلى النهاية، والذي يعتمد أيضا على منطق القواعد في المراحل النهائية وسياق النشر.

يعكس التوزيع التركيب الهيكلي لمجموعة بيانات CTI ويسمح للمستخدمين بالتحقق من توافق المؤشرات المستخرجة مع أنواع IOC المتوقعة. قد تشير الانحرافات الكبيرة عن النسب المتوقعة إلى مشاكل في التحليل أو الاستخراج في الأعلى، ويجب فحصها قبل الانتقال إلى التطبيع الأسفل وتوليد الريجيكس.

تحليل إجراءات تحسين الريجيكس

يلخص الشكل 11 الإجراءات التي تم تنفيذها أثناء توليد وتحسين التعبير المنتظم. يشمل التوزيع ثلاثة أنواع من الإجراءات: توليد الريجيكس الأولي، خطوات التحسين المدفوعة بنماذج اللغة الكبيرة (LLM)، وإعادة التوليد القائمة على إعادة المحاولة.

يمثل التحسين المدفوع بنماذج اللغة الكبيرة 51.7٪ من جميع الإجراءات التي تمت ملاحظة. يشير هذا الانتشار إلى أن التوليد الأولي وحده غالبا ما يكون غير كاف لإنتاج ريجيكس تلبي قيود مجموعة الالتقاط ومتطلبات الاستبعاد. بدلا من ذلك، يتم تطبيق التحسين التكراري بشكل نشط ومتكرر لتحسين الريجيكس المرشحة.

بدلا من عكس عدم الكفاءة، يظهر هذا التوزيع أن سير عمل التحسين هو مكون ضروري وأساسي في البروتوكول عند توليد regexs متوافقة هيكليا من مدخلات IOC معقدة.

أبلغ توصيف منفصل لقابلية التوسع على عينة عشوائية من 6,000 وحدة IOC تم إنشاؤها باستخدام نموذج اختبار قابلية التوسع (انظر جدول المواد) عن متوسط زمن تأخير يبلغ 2.95 ثانية لكل IOC ومتوسط زمن استجابة 23.18 ثانية. وفي نفس التوصيف، بلغ تجميع الريجيكس الصحيح بناء الجملة 99.56٪، وبلغ إجمالي نجاح التوليد 99.4٪، وكان متوسط تقدير استخدام الرموز حوالي 3,986 رمزا لكل شركة IOC، ويتطلب سير العمل حوالي 7.89 استدعاء LLM لكل IOC في المتوسط. كانت معدلات نجاح التمرير الأول 56.46٪ لحلقة تصحيح المطابقة و72.92٪ لحلقة التحقق غير المجموعة المختلفة. تساعد هذه القياسات في تحديد التكلفة الحاسوبية ومعدل التشغيل للاستخدام الدفعي.

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

الأدلة التشغيلية والتعامل مع الفشل. يوضح الشكل 12 هيكل ملف SIEM regex المصدر الذي ينتجه البروتوكول، إلى جانب أدلة التحقق على مستوى القواعد لأنماط مسار الملف التمثيلي، ومفتاح السجل، وسطر الأوامر. يوضح الشكل 13 التقرير الكامل لJSON المقابل، الذي يعرض جميع مخرجات المرحلة (عمليات IOC المستخرجة والتحليلية والتطبيئة مع أنماط regex المولدة وأعلام التحقق لكل IOC) وهو العنصر الأساسي الذي تستهلكه الأدوات في المراحل النهائية. يوضح الشكل 14 كيفية تعامل البروتوكول مع مدخل CTI المزعج: حيث يتم الإشارة إلى مسار ملف غير معقد ومضطرب في الفراغ الأبيض في مرحلة التحليل، ثم يتم تصحيحه، وتطبيعته إلى قالب ٪TEMP٪ القانوني، ثم تحويله إلى مترجم مطابق للملف. يكمل هذا المثال العملي الأدلة التشغيلية في الشكل 12 والشكل 13 من خلال توثيق كيفية تصرف البروتوكول عندما ينحرف النص الخام للجنة الدولية عن الشكل القانوني.

الشكل 1: البنية العامة لبروتوكول IOC-to-regex. يلخص الشكل خط الأنابيب من البداية إلى النهاية. يتم تفكيك سلاسل IOC المرشحة التي ينتجها مستخرج IOC العلوي ومقارنتها مع عقد مرجعية في رسم بياني Neo4j مليء بوثائق ويندوز (الخطوة 1)، والذي يسترجع مكونات المسار والسجل وخط الأوامر المعروفة (الخطوة 2). يتم تصنيف الشظايا المتغيرة أو الخاصة بالبيئة كمهملة واستبعادها من إعادة البناء التطبيعي أثناء الاحتفاظ بها في بيانات وصفية المكونات، مما ينتج IOC موضع طبيعي مع تسميات حفظ وتخلص على مستوى المكون (الخطوة 3). ثم تمرر هذه الوحدات الموحدة الدولية إلى مرحلة توليد regex قائمة على LLM (الخطوة 4) التي تنتج تعبيرات منتظمة مرشحة، يتم تقييمها وتحسينها بشكل تكراري مقابل قيود مجموعة الالتقاط وقواعد الرموز المهملة (الخطوة 5) قبل اختيار regex نهائي (الخطوة 6). يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 2: مخرجات تحليل المستندات المرحلة 1. مقارنة جنبا إلى جنب بين تقرير CTI الأصلي ومعاينة المستند المحلل. تعرض اللوحة اليسرى تقرير CTI الأصلي بصيغة PDF، بينما تعرض اللوحة اليمنى التمثيل الموحد لماركداون الذي يولده المحلل. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 3: استخراج اللجنة الأولمبية الدولية القائمة على الإجماع باستخدام التصويت الجماعي متعدد نماذج اللغة اللغوية الكبيرة. توضح الواجهة عملية استخراج IOC القائمة على المجموعات ونتائجها الوسيطة. يبرز المربع الأحمر مثيلات نماذج اللغة الكبيرة المكونة المشاركة في استخراج IOC، بما في ذلك المزودين المختارين وعدد عمليات الاستخراج المتكررة التي أجريت لكل نموذج. يشير المربع الأزرق إلى عتبة الإجماع التي يحددها المستخدم، والتي تحدد الحد الأدنى لعدد التكرارات المطلوبة للاحتفاظ ب IOC. بعد تجميع نتائج الاستخراج عبر جميع النماذج والتكرارات، يتم التخلص من مراكز IOC المرشحة التي تظهر مرات أقل من العتبة. يعرض الصندوق البرتقالي المجموعة النهائية من مراكز التوزيع الأولي المحتفظ بها والتي تحقق معيار الإجماع وتمرر إلى مراحل التحليل اللاحقة. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

الشكل 5: مجموعة IOC المحتفظ بها مع التصنيف الموحد. يتم عرض مرشحي IOC المحتفظ بهم بعد معالجة المرحلة 3 مع الفئات الموحدة، وعلامات المصدر، ومفاتيح الاستخراج الأصلية عند توفرها. يوفر هذا الجدول مدخلات IOC المنظمة المستخدمة في مرحلة التطبيع. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 6: تطبيع مسار الملف باستخدام التحليل المدعوم بالرسم البياني. مقارنة جنبا إلى جنب بين IOC مسار الملف الأصلي وتمثيله الطبيعي. يقوم الاستعلام المعتمد على الرسم البياني باستعلامات مكونات المسار المعروفة بالاسم المعياري ويضع علامة على كل مكون ك احتفاظ أو رفض. لذلك يمكن تمييز معرفات الأقراص وأجزاء أسماء الملفات المتغيرة كمهملة في سجل المكون بينما يتم إعادة بناء الشكل المعياري بشكل أساسي من الأجزاء الهيكلية المحجوزة المطلوبة لبناء الأنماط في المراحل النهائية. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 7: تطبيع IOC لمفاتيح السجل باستخدام التحليل المدعوم بالرسم البياني. تطبيع وحدة التوزيع المكثف لمفتاح السجل من خلال الحل المخطط بمساعدة الخطوط البيانية لهياكل السجلات الهرمية. يتم توسيع مفاتيح الجذور المختصرة إلى خلايا سجل قانونية، ويقوم المحلل باستخراج أطول سلسلة فرعية متصلة معروفة مع تخطي الحافظات الزائدة للمضيف، والقيم الشبيهة ب SID، والرموز الشبيهة ب GUID. تحتفظ سجلات الإخراج بالتسميات لكل مكون محتفظ بها وتنتج مسار سجل قانوني للمعالجة في مرحلة التنزيل. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 8: تطبيع IOC في سطر الأوامر باستخدام التحليل بمساعدة الرسوم البيانية. مقارنة بين IOC خط الأوامر الأصلي وتمثيله الطبيعي. يقوم البروتوكول بترميز سطر الأوامر مع الحفاظ على السلاسل النصية المقتبسة، ويوحد رمز الأوامر الرئيسي من خلال البحث في Neo4j عندما يكون ذلك ممكنا، ويحلل بشكل تكراري أجزاء مدمجة شبيهة بالمسار أو السجل بشكل متكرر. يتم تسمية المكونات المستقرة المتعلقة بالأوامر باسم الاحتفاظ بها، وتسمى الوسائط المتغيرة بأنها "إهراء"، ويتم إعادة بناء هيكل الأوامر النهائي من العناصر المحتفظ بها. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 9: اختيار المرشحين للتعبيرات النمطية بناء على القيود. يتم توليد عدة مرشحين للريجيكس لكل IOC تم تطبيعه باستخدام سير عمل التحقق التكراري. يتم تطبيق آلية تسجيل النقاط المدفوعة بالقيود لاختيار regex نهائي يحافظ على مكونات مجموعة الالتقاط المعينة مع تقليل السلاسل الفرعية المتغيرة غير المرغوب فيها. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 10: توزيع مراكز التوليد الأولي المستخرجة عبر تقارير CTI. ملخص نتائج استخراج IOC يظهر إجمالي عدد المؤشرات المحددة من تقارير CTI وتوزيعها عبر مسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر. يوفر هذا الرأي تحققا عالي المستوى لتغطية محتوى CTI وسلوك الاستخلاص. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 11: توزيع إجراءات التحسين أثناء توليد التعبيرات المنتظمة. تفصيل الإجراءات التي تنفذ أثناء توليد الريجيكس، بما في ذلك التوليد الأولي، والتحسين المدفوع بنماذج اللغة الكبيرة (LLM)، وإعادة التوليد المعتمدة على إعادة المحاولة. يمثل التحسين المدفوع بنماذج اللغة الكبيرة 51.7٪ من جميع الإجراءات، مما يوضح أن التحسين التكراري هو مكون أساسي في البروتوكول لإنتاج الريجيكس التي تلبي قيود مجموعة الالتقاط. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 12: ملف regex المصدر من الممثل. محتويات عينات من تصدير SIEM regex (siem_rules.txt) الذي يولده البروتوكول. كل إدخال يتضمن IOC المصدر، الفئة المستنتجة (مسار الملف، مفتاح السجل، أو سطر الأومر)، ونمط regex المعتمد. يلخص جدول التحقق المرافق السلوك المتوقع والأدلة النظامية المستخدمة لتأكيد صحة كل نوع من القاعدة. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 13: تقرير JSON الكامل للممثل. يتم إنتاج مخرجات خط الأنابيب من الطرف إلى الطرف بعد تشغيل جميع مراحل البروتوكول الخمس على تقرير CTI ممثل. يسجل مستند JSON ملف المصدر، وعدد الأقسام المحللة، ووحدات IOC المستخرجة المجمعة حسب الفئة، وسجلات المرحلة الثالثة المصنفة مع علامات المصدر، وفرق تطبيع المرحلة الرابعة، وأنماط regex للمرحلة الخامسة مع علامات التحقق لكل IOC. كما يكشف التقرير عن بيانات وصفية للنجاح والأخطاء على المستوى الأعلى التي تسمح للأدوات اللاحقة باكتشاف الأعطال الجزئية. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 14: إدخال فاشل أو مزعج: التعرف والتصحيح. مثال عملي على كيفية تحديد البروتوكول وتعافيه من مركز المراقبة الصاخب. المدخل الخام ٪T E M P٪\malware[.]يتم تمييز ملف exe لأن رمز متغير البيئة يحتوي على مسافات مدخلة وتم إزالة امتداد ملفه من العناصر. تقوم خطوة التصحيح بإزالة المساحة البيضاء المدخلة واستعادة النقطة الحرفية؛ ثم يقوم تطبيع المرحلة 4 بتوسيع ٪TEMP٪ إلى قالب دليل Windows Temp الرسمي المعتمد؛ والمرحلة 5 تولد regex يجمع ويطابق IOC المصحح المطبع. يوضح هذا المثال التعامل مع الإدخال الضوضائي الذي نوقش في النقاش. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

العنصر	النوع	القيمة / المخطط	مثال	ملاحظات
تسمية العقدة	العلامة التجارية	:P آث	ويندوز، System32، cmd.exe	يخزن مكونات مسار الملفات في ويندوز
تسمية العقدة	العلامة التجارية	:السجل	البرمجيات، مايكروسوفت، ويندوز NT	يخزن مكونات مفتاح السجل تحت خلايا الجذور
تسمية العقدة	العلامة التجارية	:CLI	powershell.exe، -ExecutionPolicy، تجاوز	تخزين رموز الأوامر والمعلمات
خاصية العقدة	الوتر	الاسم	cmd.exe	الغلاف الأصلي؛ يستخدم للعرض في المخرجات المنتظمة
خاصية العقدة	الوتر	name_lower	cmd.exe	الشكل الصغير؛ يستخدم كمفتاح بحث لجميع استعلامات MATCH
العلاقة	الحافة الموجهة	(أ)-[:التالي]->(ب)	(ويندوز)-[:NEXT]->(System32)	كلا النقطتين تحملان نفس التصنيف؛ يقوم بترميز المجاور الأصلي على أنظمة ويندوز
القيد	التفرد	n.name_lower فريد لكل علامة	-	تم تطبيقه على :P ath، :registry، :CLI
مصدر البيانات	التغطية	ويندوز 8، 10، 11	-	نظام تشغيل العميل ملء في الرسم البياني
مصدر البيانات	التغطية	ويندوز سيرفر 2012، 2016، 2019، 2022	-	نظام تشغيل الخادم ملء في الرسم البياني

الجدول 1: مخطط رسم Neo4j المستخدم لتطبيع IOC (المرحلة 4). يسرد التسميات الثلاثة للعقد (المسار، السجل، CLI)، ومخطط الخصائص المشتركة (الاسم، name_lower)، وعلاقة التجوار الموجه المستخدمة لترتيب الحواف الأصلية، وقيود التفرد، وإصدارات عميل وخادم ويندوز التي تملأ الرسم البياني.

المسرح	الإنتاج المتوقع	التحقق الآلي	مراقبة الجودة الموجهة للمحللين
المرحلة 1: تحليل المستندات	نص موحد من ماركداون، مقسم إلى 4000 حرف قبل معالجة نموذج اللغة الكبيرة.	—	الفحص البصري لمعاينة ماركداون للتأكد من أن مسارات الملفات، ومفاتيح السجل، وأجزاء سطر الأوامر، وحدود الأقسام نجت من التحليل؛ قم بتبديل الخلفية إذا تم اقتطاع السلاسل التقنية.
المرحلة 2: استخراج المركز الدولي للمحيطات	JSON مع ثلاثة مفاتيح على المستوى الأعلى (مسارات الملفات، أسطر الأوامر، مفاتيح السجل)؛ عد الأصوات لكل لجنة الأولمبية الدولية وبيانات النموذج المساهم عند تفعيل التصويت الجماعي.	يستثني مرشح عتبة الإجماع (min_votes) لجان الأولمبية الدولية التي يكون عدد أصواتها أقل من العتبة المهيأة.	فحص المرشحين المستبعدين لتمييز الهلوسات عن التصويت الصارم المفرط قبل تعديل min_votes.
المرحلة 3: تحليل وتصنيف اللجنة الأولمبية الدولية	قائمة IOC المصنفة: كل IOC مرتبط بفئة موحدة، وعلامة المصدر، ومفتاح استخراج أصلي عند توفرها.	رسم الخرائط الموحدة للفئات عبر قواعد قائمة على الريجيكس وقواعد أنماط IOC؛ (IOC، الفئة) إزالة التكرار الزوجي.	التحقق الفوري من الناتج المصنف للمرشحين الغامبين أو المزعجين (الشكل 4A).
المرحلة 4: تطبيع بمساعدة Neo4j	الشكل المعياري لكل IOC مع تسميات الاحتفاظ / التخلص على مستوى المكون.	يقوم سايفر بالاستعلامات (i)-(iii) فوق رسم بياني المرجعي لويندوز؛ المعالجة المسبقة الحتمية عندما لا يكون Neo4j متاحا.	فحص جميع الحالات المهملة لتحديد الفجوات في تغطية الرسوم البيانية؛ توسيع بيانات الرسوم البيانية مع مراجع خاصة بالبائع أو البيئة عند الحاجة.
المرحلة 5: توليد وتسجيل النقاط في الريجيكس	السجل النهائي لكل لجنة الأولمبية الدولية مع درجات المرشحين، وتاريخ التحسين، وعدد التكرارات، وبيانات التليمترية لكل لجنة الأولمبية الدولية.	اختبار المطابقة، فحوصات الجودة الثابتة، فحص الرموز المحظورة الواعية بالحدود، اختبار التعميم المفرط ضد 5 عينات سلبية حتمية؛ العودة إلى أعلى مباراة جزئية (علم used_fallback).	مراجعة تاريخ التحسين للسجلات الاحتياطية؛ فحص تشخيصي لموقع الفشل لكل وحدة IOC قبل التجديد.

الجدول 2: ملخص مخرجات المرحلة والتحقق. يربط كل مرحلة بروتوكول (1–5) بمنتجها المتوقع، وأدلة التحقق الآلي التي ينتجها خط الأنابيب (حالة تجميع regex، معدل الوصول، معدل عدم التوافق عبر IOC، عدد تكرارات التحسين)، وفحص مراقبة الجودة المقابل الذي يواجهه المحللون (مقارنة بصرية، فحص المرشحين المهجورين، ومراجعة الفئات).

الملف التكميلي 1: محفزات LLM الحرفية. النظام الحرفي والتعليمات البشرية المستخدمة في استخراج IOC المرحلة 2 وتوليد وتحسين regex في المرحلة 5. يرجى الضغط هنا لتحميل هذا الملف.

الملف التكميلي 2: تفاصيل التنفيذ للمرحلتين 4 و5. تفاصيل الخوارزميات والتنفيذ تدعم تطبيع IOC بمساعدة الرسوم البيانية في المرحلة 4 والتحقق من صحة الريجيكس والتسجيل والتكرار في المرحلة 5. يرجى الضغط هنا لتحميل هذا الملف.

المناقشة

تظل ترجمة تقارير CTI غير المنظمة إلى منطق كشف قابل للتنفيذ مهمة تستغرق وقتا طويلا وعرضة للأخطاء في سير العمل الأمني التشغيلي. بينما استكشفت الجهود السابقة الأتمتة على مستوى استخراج IOC أو توليد قواعد عالية المستوى، لا يزال الممارسون يواجهون تحديات كبيرة في تحويل سلاسل IOC المستخرجة إلى regex تكون صحيحة هيكليا، ودقيقة دلاليا، ومناسبة للاستخدام في SIEM لاحقا. يعالج البروتوكول المعروض هنا هذه الفجوة من خلال سير عمل مرحلي ينتج فيه كل مرحلة ثبوتة وسيطة محددة جيدا وتطبق التحقق الصريح قبل تمرير النتائج إلى المرحلة التالية. يوثق الشكل 14 حالة من هذه الحالات، حيث يتم تحديد مسار ملف غير معقد ومضطرب في الفراغ الأبيض، وتصحيحه، وتطبيعه، وتحويله إلى ملف تجميع؛ يتم مناقشة معالجة الإدخال الضوضاء في البروتوكول ونطاقه الحالي بشكل مشترك مع القيود الموضحة أدناه.

مساهمة مركزية لهذا البروتوكول هي تفكيكه الصريح لسير العمل إلى مراحل مع مخرجات وسيطة قابلة للفحص. تم وصف التنفيذ الآن بشكل ملموس: تحليل المستندات ينتج نصوص Markdown وأجزاء لمعالجة نماذج اللغة الكبيرة؛ يصدر استخراج IOC JSON منظم لمسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر؛ يقوم تحليل IOC القائم على القواعد بتوحيد وإزالة التكرار من القيم المستخرجة؛ يقوم التطبيع المدعوم بمساعدة Neo4j بتسمية كل مكون من مكونات IOC كأنه الاحتفاظ أو التخلص منه؛ وتوليد القواعد يطبق تصحيح الأخطاء في المطابقة، والتحقق من التجاهل، والتعميم المفرط قبل اختيار المرشح.

يعامل البروتوكول توليد التعبير العادي كمهمة بناء تكرارية بدلا من كونها مشكلة تنبؤ لمرة واحدة. يستخدم التطبيق موجه للتوليد الأولي، وتشخيصات مطابقة آلية، وحلقات تحسين محدودة، ووظيفة تقييم قائمة على المكونات للحفاظ على عناصر IOC المهمة هيكليا مع معاقبة السلاسل الفرعية المهملة أو غير المصنفة. يدعم هذا التصميم التكراري، إلى جانب المدققين الحتميين المطبقة في كل خطوة، إنتاج أنماط ريجيكس التي تبقى وفية هيكليا عبر مجموعة تقييم كبيرة وغير متجانسة. في التقييم المرجعي، تم تطبيق هذا السير على 3,156 تقرير CTI وتم تقييمه مقابل أكثر من 2,400 سلسلة مستقلة من الحقيقة الأرضية، مما أدى إلى متوسط معدل إصابة 99.1٪ ومتوسط معدل عدم تطابق عبر IOC بنسبة 0.8٪. نظرا لأن هذه السلاسل الواقعية هي قطع أثرية مختارة من قبل خبراء أبلغ عنها مزودو الأمن السيبراني خلال تمارين تقييم MITRE ATT&CK، فإن هذا التقييم يقارن ضمنيا بين مخرجات البروتوكول وأنماط IOC التي وثقها المحللون البشريون بدلا من الأنماط المولدة تلقائيا.

كما هو موضح في النتائج الممثلة، يكون التحسين التكراري مهما بشكل خاص عندما يتعامل سير العمل مع هياكل IOC المعقدة مثل مسارات الملفات المتداخلة أو سلاسل سطر الأوامر الطويلة. تشير نتائج تقييم المراجع أيضا إلى أن أكثر الحالات غير المتطابقة شيوعا تحدث عندما يستخدم المهاجمون ملفات تنفيذية أو معلمات مخصصة غير ممثلة في قاعدة بيانات الرسوم البيانية أو غير موثقة صراحة في تقارير CTI المصدر. في الاستخدام التشغيلي، يجب التعامل مع هذه الأوضاع كشروط حدودية متوقعة بدلا من أخطاء صامتة، ويجب أن تثير مراجعة تغطية الرسوم البيانية، واكتمال تقارير المصدر، وتتبع التصحيح الريجيكسي.

يمكن مقارنة البروتوكول بثلاث عائلات من الطرق البديلة. أولا، تتعلم طرق توليف الريجيكس القائمة على الأمثلة مثل TransRegex¹¹ وRegex+¹² الريجيكس من مجموعات مختارة من أمثلة السلاسل الإيجابية والسالبة. تؤدي هذه الطرق أداء جيدا عندما تتوفر مجموعات أمثلة تمثيلية لكنها أقل تطبيقا مباشرا على سياقات SOC، حيث يظهر كل IOC تم الإبلاغ عنه في CTI عادة كسلسلة تمثيلية واحدة فقط، ويكون الحد المطلوب للتعميم مدفوعا بالدلالات التشغيلية بدلا من تغطية الأمثلة. ثانيا، ^{تبحث طرق} البرمجة الجينية مثل تلك التي قدمها بارتولي وآخرون ^في فضاء السجلات من خلال مؤثرات تطوري وعادة ما تتطلب مجموعة موسومة من سلاسل المطابقة وغير المتطابقة؛ وهي مناسبة جدا لبناء أنماط الاستخراج بشكل دفعي لكنها لا تستهلك بشكل مباشر سرديات CTI غير منظمة. ثالثا، تترجم الأساليب العصبية والمعتمدة على نماذج اللغة الكبيرة^{الحديثة 15,16} أوصاف اللغة الطبيعية مباشرة إلى سلاسل ريجيكس؛ هذه الطرق قوية للمحفزات المحددة جيدا، ولكن في الاستخدام الطلقة الواحدة، قد تنتج قواعد قواعد (regex) صحيحة نحويا لكنها تفتقد مكونات مجموعة الالتقاط المطلوبة أو تعمم بشكل مفرط عبر متغيرات IOC غير مرتبطة. يكمل البروتوكول الحالي هذه الاتجاهات من خلال (1) أخذ تقارير CTI غير المنظمة بدلا من مجموعات الأمثلة المنسقة أو استعلامات اللغة الطبيعية كمدخلات، (2) تفكيك كل IOC إلى مكونات حفظ وتخلص منها عبر التطبيع بمساعدة الرسوم البيانية قبل توليد أي regex، و(3) التحقق من صحة كل regex مرشح باستخدام فحوصات مطابقة حتمية، وتجاهل، وتفحوص مفرطة على التعميم ضمن حلقة تكرارية محدودة. الهدف ليس التفوق على الطرق السابقة في معايير القياس الخاصة بهم، بل توفير خط أنابيب يمكن إعادة إنتاجه من IOC إلى regex، حيث تكون قراراته الوسيطة قابلة للفحص والتدقيق من قبل محللي SOC.

يفترض البروتوكول عدة افتراضات حول جودة تقارير CTI المدخلة. يفترض أن (i) سلاسل IOC تظهر في شكل نصي قابل للاسترداد بعد تحليل المستندات، أي مسارات الملفات، مفاتيح السجل، ومؤشرات سطر الأوامر ليست مدمجة حصريا في الصور أو لقطات الشاشة أو الترميزات المشوشة؛ (2) تكون شظايا IOC المبلغ عنها في CTI كاملة بما يكفي للحفاظ على مراسيها الهيكلية (على سبيل المثال، مفاتيح السجل تحتفظ ببادئة الخلية، ومسارات الملفات تحتفظ بمرساة دليل واحدة على الأقل يمكن التعرف عليها في رسم توثيق ويندوز، وأسطر الأوامر تحتفظ بالملف التنفيذي المستدعي أو مرجع الوحدة المعروف)؛ و(3) لم يتم اختصار أو حذف أو إعادة كتابة مراكز IOC المبلغ عنها بطرق تزيل مكونات مجموعة الالتقاط التي يعتمد عليها البروتوكول. تشمل تقارير CTI التي تحقق هذه الافتراضات معظم أوصاف تقنيات MITRE ATT&CK، وإرشادات الموردين، وكتابات الاستجابة للحوادث، ونشرات التهديدات المنسقة جيدا. التقارير التي تعتمد بشكل أساسي على لقطات الشاشة، أو قوائم IOC المختصرة بشدة والتي تفتقر إلى السياق المحيط، أو إعادة صياغة النص الحر بدون سلاسل IOC صريحة، تقع خارج نطاق التشغيل المقصود ويجب توقع أن تؤدي إلى تقليل استدعاء الاستخراج وتطبيع أقل ولاء؛ قد تستفيد هذه التقارير من معالجة الصور إلى نص أو مراجعة المحللين قبل الدخول في خط الأنابيب.

يجب أخذ عدة قيود في الاعتبار عند تطبيق هذا البروتوكول. أولا، يركز التنفيذ الحالي على مسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر بدلا من فئات IOC الأوسع مثل النطاقات، وتشنجات البريد الإلكتروني، وسلاسل المستخدم-الوكيل، أو التسلسلات السلوكية. هذا اختيار متعمد في النطاق، حيث أن المؤشرات الذرية عادة ما تخدم بشكل جيد من خلال سير العمل المطابقة الدقيقة، بينما يستهدف البروتوكول الحالي مراكز IOC ذات البنية المتغيرة التي تستفيد من تعميم الريجيكس؛ ومع ذلك، فإنه يقيد التطبيق على أنواع IOC غير الممثلة حاليا في الرسم البياني. ثانيا، تنقسم سيناريوهات الفشل الحالية إلى ثلاث فئات رئيسية: المسارات غير الأصلية أو حجج سطر الأوامر التي غائبة عن رسم نظام التشغيل، تغطية الرسم البياني غير المكتملة للأدوات أو الهياكل ذات الصلة، وعدم اكتمال مصدر CTI نفسه عندما لا يتم الإبلاغ عن أجزاء أوامر مهمة أو مقاطع cmdlet. ثالثا، يقيس مقياس عدم التوافق عبر IOC المستخدم في التقييم المرجعي الخصوصية الدلالية للريجيكس المولدة بدلا من الإيجابيات الكاذبة من طرف إلى طرف وفقا لمنطق SIEM المنشور.

قابلية التكرار تحت تغير نماذج اللغة الكبيرة وإصدار الإصدارات. نظرا لأن مراحل استخراج IOC وتوليد regex تعتمد على نقاط نهاية نماذج لغوية كبيرة تجارية، فإن مصدرين للتباين يؤثران على قابلية التكرار: تحديثات النموذج من جهة المزود مع مرور الوقت وعشوائية أخذ العينات لكل مكالمة. لتقليل الأولى، تسجل جميع الحقول المتعلقة بنماذج اللغة الكبيرة في جدول المواد معرفات النموذج الدقيقة وتاريخ الوصول المستخدم في تقييم المرجع، ويوصي البروتوكول بتثبيتها على لقطة نموذج محددة كلما عرض المزود لقطة واحدة. لتخفيف الحالة الثانية، يثبت التطبيق المرجعي درجة حرارة استخراج IOC عند 0.0 ويستخدم درجة حرارة غير صفرية فقط في مرحلة توليد الريجيكس، حيث تمتص التصويتات الجماعية والمدققون الحتميون في المرحلتين 2 و5 التغير المتبقي. عند تكرار هذه النتائج، يجب على المستخدمين تسجيل نسخة النموذج الدقيقة، وتاريخ الوصول، ودرجة الحرارة، وعتبة تصويت المجموعة المستخدمة؛ يجب توقع أن تؤدي الانحرافات الجوهرية على أي من هذه المحاور إلى تغيير معدلات الإصابة ومقاييس عدم المطابقة.

يمكن معالجة عدة أنماط فشل قابلة للاسترداد على مستوى المرحلة التي أنتجتها. فشل التحليل في المرحلة الأولى (على سبيل المثال، ملفات PDF الممسوحة ضوئيا التي تنتج Markdown فارغة أو مشوشة): معالجة الإدخال مسبقا باستخدام التعرف البصري على الحروف أو محول خارجي قبل إعادة الرفع؛ تحقق من أن عدد المقاطع المحللة وعدد الأحرف الكلي غير صفري قبل المتابعة. فشل الاستخراج في المرحلة الثانية (عدم إعادة IOCs، أو إدخالات هلوسية): زيادة عتبة التصويت الجماعي (الحد الأدنى للأصوات ≥ 2)، تمكين نماذج إضافية من النموذج، أو خفض درجة حرارة النموذج الكبير؛ تحقق من اتصال واجهة برمجة التطبيقات وأن النموذج المكون يقبل المخرجات المنسقة بتنسيق JSON. تطبيع المرحلة 4 مع تسميات التخلص بالكامل (كل مكون IOC يصنف كمهمل): توسيع رسم Neo4j المرجعي لمكونات المسار الخاصة بالبائع أو البيئة وجذور السجل؛ نصوص استيراد Cypher وقاعدة قرار الاحتفاظ والتخلص مدرجة في الملف التكميلي 2. فشل الريجيكس في المرحلة 5 (used_fallback = رفضات صحيحة أو متكررة للتخلص من التحقق): فحص حقل تاريخ التحسين لكل IOC لتحديد المدقق الفاشل؛ إذا كانت IOC تفتقر فعلا إلى مكونات الاحتفاظ المستقرة، فكر في تأليف regex يدوي لذلك IOC أو استبعاده من توليد القواعد الآلي مع الاحتفاظ به في جدول IOC المصنف لمراجعة المحللين.

تماشيا مع القيود السابقة، من الأفضل التعامل مع الريجيكس المولدة كبدائيات بحث قابلة لإعادة الاستخدام ضمن محتوى كشف SOC أوسع بدلا من كونها كواشف مكتفية ذاتيا. في البيئات التشغيلية، يمكن للمحللين دمجها مع منطق ميداني خاص بالمنصة، أو قوائم بيضاء، وفحوصات المصدر، أو شروط الارتباط لقمع التطابقات الحميدة التي تنشأ من مسارات غير معتادة لكنها غير خبيثة.

قد تشمل الأعمال المستقبلية مقارنة منهجية مع السجلات التي يكنها البشر، وتقييما أوسع عبر فئات IOC إضافية، ودراسات محللين مرتدة منظمة للمراجع، وتوسيع تغطية الرسوم البيانية للمرافق والبرامج التي ينشئها المهاجمون، وتقارير أعمق عن زمن الاستجابة والتكلفة من البداية إلى الطرف عبر إعدادات النشر. ومع ذلك، يوفر البروتوكول الحالي إطارا قابلا للتكرار وقابلا للتفسير التشغيلي للترجمة من IOC إلى REGEX يوثق نقاط قوته وحدوده الحالية.

المواد

قائمة المواد المستخدمة في هذه المقالة

الاسم	الشركة	رقم فهرسي	التعليقات
الكمبيوتر (CPU)	—	≥ 4 أنوية موصى بها	لا حاجة لوحدة معالجة رسومية
LangChain	LangChain	≥ 0.1.x	إطار عمل تنسيق LLM
LLM (استخراج IOC، نموذج واحد)	OpenAI	gpt-5.1	يُستخدم لاستخراج IOC (المرحلة 2) عندما يكون التصويت الجماعي معطلاً. درجة الحرارة = 0.0؛ max_workers = 5. تم الوصول إليه: 2025-12-15.
LLM (إنشاء التعبيرات العادية)	OpenAI	gpt-5.1	يُستخدم لإنشاء التعبيرات العادية (المرحلة 5). درجة الحرارة = 0.3 قبل التحقق المتدفق. تم الوصول إليه: 2025-12-15.
LLM (توصيف القابلية للتوسيع)	OpenAI	gpt-5.1	يُستخدم لتشغيل القابلية للتوسيع 6,000-IOC المذكور في النتائج التمثيلية. تم الوصول إليه: 2025-12-15.
الذاكرة (RAM)	—	≥ 16 جيجابايت موصى بها	مطلوبة لمعالجة المستندات
Neo4j	Neo4j, Inc.	≥ 5.x	قاعدة بيانات رسومية لتطبيع IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	واجهة Python لـ Neo4j
نظام التشغيل	Microsoft / Apple / Linux	Windows، macOS، أو Linux	دعم عبر الأنظمة الأساسية
تحليل PDF — الواجهة الخلفية الأساسية	Microsoft	MarkItDown ≥ 0.0.x	واجهة المرحلة 1 الخلفية؛ يحول المدخلات PDF/DOCX/HTML/TXT إلى Markdown. يتم تجزئة الإخراج المحلل إلى 4,000 حرف قبل معالجة LLM. تم الوصول إليه: 2025-12-15. https://github.com/microsoft/markitdown
تكوين خط الأنابيب (المرحلة 2 — استخراج IOC)	—	الافتراضات المرجعية	وضع LLM واحد: درجة الحرارة = 0.0، max_workers = 5. افتراضات وضع التصويت الجماعي: تكرار = 1 لكل نموذج مكون، min_votes = 2.
تكوين خط الأنابيب (المرحلة 5 — إنشاء التعبيرات العادية)	—	الافتراضات المرجعية	درجة حرارة الإنشاء = 0.3. التحقق: overgen_random_tests = 5 عينات سلبية عشوائية لكل IOC. حدود التكرار: max_iterations = 10، debug_loop_cap = 5، discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	بيئة تشغيل مطلوبة
محرك التعبيرات العادية	مكتبة Python القياسية	وحدة re	يُستخدم للتحقق من التعبيرات العادية واختبارها
Streamlit	Streamlit Inc.	≥ 1.25	واجهة مستخدم قائمة على الويب
مصدر كود التنفيذ المرجعي	المؤلفون / GitHub | مستودع GitHub		كود المصدر لواجهة Streamlit، خط أنابيب LangChain، التطبيع المساعد من Neo4j، إنشاء التعبيرات العادية، أدوات التحقق، وملفات التكوين المثالية. متاح في https://github.com/SOCautomatic/cti-ioc-regex-pipeline. تم الوصول إليه: 11 يونيو 2026.