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

ملخص

هنا، نقدم بروتوكولا لتحويل مؤشرات الاختراق من تقارير استخبارات التهديدات السيبرانية، ومسارات الملفات، ومفاتيح السجل، ومؤشرات سطر الأوامر إلى تعبيرات منتظمة معتمدة لقواعد كشف معلومات الأمن وإدارة الأحداث (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. هذه السلاسل الواقعية هي قطع هجومية مختارة من خبراء تم الإبلاغ عنها بشكل مستقل من قبل با...

المناقشة

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

المواد

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

الاسم	الشركة	رقم فهرسي	التعليقات
الكمبيوتر (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.